はじめに
前回は、システム構成やネットワーク構成、サイジングなど、システムを構築するための基盤となる設計について解説しました。
しかし、システムは構築して終わりではありません。
本番稼働後は、毎日運用され、障害が発生すれば復旧し、OSやミドルウェアのアップデートも継続的に実施していく必要があります。
そのため、基本設計では「どのように運用していくか」という視点も非常に重要です。
ここでは、運用・保守に関する設計内容について解説します。
10. セキュリティ設計
インフラ設計において、セキュリティはシステム全体に関わる重要な設計項目です。
基本設計では、細かな設定値ではなく、「どのような考え方でシステムを保護するか」という方針を定めます。
主な設計項目は次のとおりです。
ネットワークセキュリティ
まず設計するのがネットワークレベルのセキュリティです。
例えば、
- ファイアウォールで通信を制御する
- 必要最小限のポートのみ許可する
- 管理ネットワークを業務ネットワークと分離する
- 外部公開サーバはDMZへ配置する
などを決定します。
クラウド環境でも同様に、セキュリティグループやネットワークACLなどを利用して通信を制御しますが、基本設計では「どのような考え方で通信を制限するか」を記載します。
OSセキュリティ
OSについても運用方針を整理します。
例えば、
- 不要サービスは停止する
- 不要ユーザは削除する
- パスワードポリシーを適用する
- セキュリティパッチを定期適用する
などです。
ウイルス対策
ウイルス対策ソフトについても設計対象です。
例えば、
- 全サーバへ導入する
- パターンファイルは自動更新する
- 定期スキャンを実施する
などを定めます。
暗号化
近年では暗号化も必須と言えます。
例えば、
- HTTPS通信
- SSHによる管理
- ディスク暗号化
- バックアップデータ暗号化
など、どのデータをどこまで暗号化するかを設計します。
11. ユーザ管理方針
ユーザ管理も基本設計で決める重要な項目です。
ここで決めるのは、
「誰がどの権限でシステムを利用するのか」
という考え方です。
例えば、
- 管理者
- 運用担当
- 監視担当
- 一般利用者
などの役割を定義します。
また、
- ローカルユーザを利用するか
- Active Directoryと連携するか
- クラウドIAMを利用するか
なども決定します。
さらに、
- 管理者権限は必要最小限とする
- 共通アカウントは禁止する
- 退職・異動時は速やかに削除する
など、運用ルールも合わせて設計します。
基本設計では、「どのような権限管理を行うか」という方針を定め、詳細なユーザ一覧や権限一覧は詳細設計で管理することが一般的です。
12. バックアップ・リストア設計
バックアップは、システム障害だけでなく、誤操作やランサムウェア対策としても重要な設計項目です。
基本設計では、主に次のような内容を決定します。
- 何をバックアップするか
- バックアップ方式
- バックアップ取得タイミング
- 保存期間
- 保存先
- 世代管理
- リストア方法
例えば、
- OSはイメージバックアップを取得する
- データベースは論理バックアップを取得する
- 毎日夜間にバックアップする
- 世代は30日保持する
などです。
ここで注意したいのは、バックアップだけではなく、リストアについても設計することです。
実際の障害対応では、「バックアップが取得できていたか」よりも、「正常に復元できるか」が重要になります。
そのため、
- リストア手順を作成する
- 定期的にリストア試験を実施する
といった運用方針も基本設計で整理しておくことが望ましいでしょう。
なお、ランサムウェア対策として、通常時バックアップデータはシステムから切り離されていることが重要です。
13. ログ管理
ログは、障害解析やセキュリティインシデントの調査に欠かせません。
基本設計では、
- どのログを取得するか
- 保存期間
- 保管場所
- ローテーション方法
- 集約方法
などを決定します。
対象となるログには、
- OSログ
- Webサーバログ
- アプリケーションログ
- データベースログ
- セキュリティログ
- 監査ログ
などがあります。
また、複数サーバで構成されるシステムでは、ログを一元管理するかどうかも重要な設計ポイントです。
14. 監視設計
監視設計では、
「何を監視するのか」
を決定します。
一般的には、
死活監視
サーバが稼働しているかを監視します。
リソース監視
- CPU
- メモリ
- ディスク使用率
などを監視します。
プロセス監視
Webサーバやデータベースなど、重要なサービスが停止していないかを監視します。
ログ監視
エラーログや異常終了を検知します。
ジョブ監視
定期実行ジョブの異常終了を検知します。
ここでは監視項目だけではなく、
- アラート通知先
- 通知方法
- 一次対応者
などの運用方針も整理しておくと、障害対応を円滑に進めることができます。
15. ジョブ管理
業務システムでは、多くの処理が定期ジョブとして実行されています。
例えば、
- 日次集計
- 月次処理
- バックアップ
- ファイル転送
- ログ削除
などです。
基本設計では、
- ジョブ管理ツールを利用するか
- OS標準機能を利用するか
- ジョブの実行タイミング
- 異常終了時の対応
などを決定します。
ジョブ同士の実行順序や依存関係についても、この段階で整理しておくと、後続工程がスムーズになります。
16. 災害対策（DR）
近年、多くのシステムで災害対策（DR：Disaster Recovery）が求められるようになっています。
基本設計では、
- DRサイトを構築するか
- データを遠隔地へ複製するか
- 災害時の切り替え方法
- 復旧手順の考え方
などを整理します。
ここでも重要なのは、要件定義で決めたRPO・RTOを満たせる構成になっているかです。
例えば、
「RPOは1時間」
と決まっているのであれば、
「1時間ごとにレプリケーションを実施する」
あるいは、
「リアルタイムレプリケーションを採用する」
といった設計方針を定めます。
17. OS・ミドルウェアの設計方針
最後に、OSやミドルウェアの設計方針を整理します。
ここで注意したいのは、「設定値一覧」を作ることではありません。
基本設計では、
- OSのバージョン
- ミドルウェアのバージョン
- サポート方針
- パッチ適用方針
- ライフサイクル管理
などを決定します。
例えば、
- 長期サポート版（LTS）を採用する
- サポート期限内のバージョンを利用する
- 定期メンテナンスでパッチを適用する
といった内容です。
sysctlやカーネルパラメータ、ApacheやNginxの詳細設定、データベースのチューニング値などは、構築担当者が実装できるレベルまで具体化する必要があるため、通常は詳細設計で扱います。
基本設計で意識したいこと
ここまで紹介した設計項目を見ると、「決めることが多すぎる」と感じるかもしれません。
しかし、すべてに共通する考え方があります。
それは、
「どの製品や機能を使うか」ではなく、「どのような方針でシステムを構成・運用するか」を決めることです。
例えば、「監視ツールは○○を使う」と製品名だけを書くのではなく、
- 何を監視するのか
- 異常時は誰に通知するのか
- どのような運用を想定するのか
といった設計方針まで示すことで、構築担当者や運用担当者が迷わず作業を進められる基本設計書になります。
基本設計と詳細設計の違い
基本設計と詳細設計は、どちらもシステムを構築するための設計工程ですが、目的が異なります。
基本設計の目的は、
「システム全体の構成や設計方針を決めること」
です。
一方、詳細設計の目的は、
「構築担当者が迷わず設定・構築できるレベルまで具体化すること」
です。
つまり、
基本設計は「何をどのような方針で実現するか」を決める工程、
詳細設計は「その方針をどのような設定で実装するか」を決める工程と言えます。
例えば、DNSを例にすると、
基本設計
- DNSサーバを利用する
- Active DirectoryのDNSを利用する
- 正引き・逆引きを実施する
詳細設計
- Aレコード一覧
- PTRレコード一覧
- ゾーン情報
- TTL値
- 転送設定
というように、基本設計では方式を決め、詳細設計では具体的な設定内容を定義します。
以下は、代表的な設計項目を比較したものです。
| 項目 | 基本設計 | 詳細設計 |
|---|---|---|
| システム構成 | ○ | – |
| ネットワーク構成 | 構成・方式 | IPアドレス、ルーティング、ACL |
| サーバ | 構成、役割 | ホスト名、設定値 |
| CPU・メモリ | スペック | チューニング値 |
| DNS | 利用方式 | レコード一覧 |
| NTP | 同期方式 | 設定ファイル |
| セキュリティ | 方針 | パラメータ |
| バックアップ | 取得方式 | バックアップジョブ |
| 監視 | 監視方針 | 監視項目一覧、しきい値 |
| OS | 採用方針 | sysctl設定、各OS設定 |
| Webサーバ | 採用方針 | httpd.confやnginx.conf |
| DB | 採用方針 | パラメータ設定 |
このように、「方針」と「設定値」で切り分けると分かりやすいでしょう。
もちろん、プロジェクトによっては基本設計と詳細設計を1冊にまとめるケースや、逆にさらに細かく分割するケースもあります。しかし、「方針を定める設計」と「実装するための設計」という役割の違いは、多くの現場で共通しています。
基本設計書に設定値を大量に書き込んでしまうと、変更時の修正箇所が増え、ドキュメントの保守性が低下します。
そのため、「基本設計では方針を整理し、詳細設計で具体化する」という役割分担を意識すると、読みやすく保守しやすい設計書になります。
基本設計レビューでよく指摘されるポイント
基本設計書を作成したら、レビューを実施するのが一般的です。
レビューでは誤字脱字だけでなく、設計内容の妥当性や要件との整合性も確認します。
私が現場でよく見かける指摘事項を紹介します。
① 要件との整合性が取れていない
最も多い指摘です。
例えば、
要件定義では「24時間365日稼働」となっているにもかかわらず、
基本設計では
- サーバ1台構成
- バックアップなし
となっていては、要件を満たせません。
基本設計は、要件定義の内容を具体的な構成へ落とし込む工程です。
設計内容が要件を満たしているかを常に意識しましょう。
② 設計理由が書かれていない
例えば、
「DBはクラスタ構成とする」
とだけ書かれていても、
「なぜクラスタ構成を採用したのか」
が分かりません。
レビューでは、
- 可用性要件を満たすため
- 障害時にサービス停止時間を短縮するため
など、設計判断の根拠が求められます。
すべての項目で詳しく説明する必要はありませんが、重要な設計判断については理由を残しておくと、レビューがスムーズになります。
③ 運用を考慮した設計になっていない
設計時は正常系だけに目が向きがちですが、実際の運用では障害対応や保守作業も発生します。
例えば、
- ログは十分に保存されるか
- バックアップから復元できるか
- 障害を検知できるか
- パッチ適用時の停止時間は許容範囲か
など、運用担当者の視点でも確認することが重要です。
「構築できる設計」だけでなく、「運用できる設計」になっているかを意識しましょう。
④ ドキュメント間の整合性が取れていない
設計書は1冊で完結することは少なく、多くの関連ドキュメントがあります。
そのため、
- システム構成図とサーバ一覧
- サーバ一覧とソフトウェア一覧
- ネットワーク構成図と通信一覧
- バックアップ設計と災害対策
など、複数のドキュメント間で内容が一致しているかを確認することも重要です。
レビューでは、このような整合性の確認に多くの時間を割くことも珍しくありません。
設計初心者へのアドバイス
設計経験が少ないうちは、「正しい設計」を作ろうとして手が止まってしまうことがあります。
しかし、基本設計で最も重要なのは、システム全体を俯瞰し、関係者が同じイメージを持てる設計書を作ることです。
設計書は、自分だけが理解できればよいものではありません。
構築担当者、テスト担当者、運用担当者、さらにはお客様も参照する資料です。
そのため、専門用語を並べるだけではなく、
- なぜこの構成なのか
- なぜこの方式を採用したのか
- どの要件を満たすための設計なのか
が伝わる内容を意識すると、品質の高い設計書になります。
また、レビューで多くの指摘を受けることは珍しくありません。
設計レビューは設計者を評価する場ではなく、システムの品質を高めるための場です。指摘を受けた内容を次の設計に活かすことで、設計力は着実に向上していきます。
まとめ
基本設計は、要件定義で整理した要求を、実際に構築可能なシステム構成へ落とし込む重要な工程です。
本記事では、システム構成やネットワーク、サイジング、セキュリティ、運用設計など、基本設計で検討すべき代表的な項目を紹介しました。
すべての案件で同じ内容になるわけではありませんが、多くのプロジェクトでは「システムをどのような方針で構築・運用するのか」を基本設計で整理し、その内容をもとに詳細設計や構築を進めていきます。
設計初心者の方は、個々の設定値を覚えることよりも、「なぜその構成を採用するのか」という設計の考え方を意識してみてください。
要件定義で決めた内容と基本設計を結び付けて考えられるようになると、設計書全体の整合性が取りやすくなり、より実践的な設計ができるようになります。
コメント