はじめに
前回の記事では、非機能要求グレードを活用した要件定義について解説しました。
要件定義では、
- システムにどの程度の可用性が必要か
- 性能はどの程度必要か
- セキュリティレベルはどうするか
- バックアップや災害対策は必要か
など、「システムに求められる要求」を整理します。
しかし、要件を決めただけではシステムは構築できません。
例えば、
- 可用性レベルⅣ
- RPOは1時間
- RTOは30分
と決まっていても、
「具体的にどんなサーバ構成にするのか」
「どのように冗長化するのか」
「どのようにバックアップを取得するのか」
までは決まっていません。
そこで行うのが基本設計です。
基本設計では、要件定義で決めた内容を実現するためのシステム構成や設計方針を決定します。
この記事では、インフラエンジニアが基本設計で何を決めるのか、どのような成果物を作成するのか、そして詳細設計との違いについて詳しく解説します。
基本設計とは
基本設計とは、要件定義で決めた要求を実現するためのシステム全体の構成や設計方針を決定する工程です。
一言でいうと、
「どのようなシステム構成で要件を満たすか」を決める工程
になります。
例えば、要件定義で
- Webサーバは停止してはいけない
- 障害時は30分以内に復旧したい
という要求があった場合、
基本設計では
- Webサーバを2台構成にする
- ロードバランサを配置する
- データベースを冗長化する
- バックアップ取得方式を決める
といった設計を行います。
つまり、
要件定義が「何が必要か」を決める工程であるのに対し、
基本設計は「どう実現するか」を決める工程です。
要件定義との違い
設計経験が少ない人が最初につまずくのが、
「要件定義と基本設計の違い」
です。
簡単に整理すると次のようになります。
| 要件定義 | 基本設計 |
|---|---|
| 必要な機能・非機能を決める | 実現する構成を決める |
| 要求を整理する | システム構成を設計する |
| お客様と合意する | 開発・構築できる設計に落とし込む |
例えば、
要件定義では
「24時間365日稼働したい」
という要求が決まります。
基本設計では
「サーバを冗長化する」
「ロードバランサを導入する」
「DBはクラスタ構成にする」
という具体的な構成を決めます。
つまり、
要求を設計へ変換する工程
それが基本設計です。
基本設計で決めること
基本設計では、システム全体を構成するために必要な設計方針を決めます。
現場によって多少異なりますが、多くのプロジェクトでは次のような内容を基本設計書に記載します。
- システム構成
- 外部システムとの連携
- サーバ構成
- ソフトウェア構成
- ネットワーク構成
- サイジング
- セキュリティ
- 運用設計
- バックアップ
- 監視
- 災害対策
- OS・ミドルウェア設計方針
ここからは、それぞれについて詳しく見ていきましょう。
1. システム構成
基本設計書の中心となるのがシステム構成図です。
システム構成図には、
- Webサーバ
- APサーバ
- DBサーバ
- ストレージ
- ロードバランサ
- FW
- DNS
- 認証サーバ
など、システム全体の構成を記載します。
オンプレミスであれば物理サーバや仮想サーバを中心に、クラウドであれば仮想マシンやマネージドサービスを含めて全体像を示します。
重要なのは、詳細な設定を書くことではなく、システム全体の構成を誰でも理解できるようにすることです。
この構成図を見れば、
「どのようなサーバが存在するのか」
「どのように接続されているのか」
が把握できる状態を目指します。
2. システム連携
近年のシステムでは、単独で動作するケースは少なく、多くの外部システムと連携します。
そのため基本設計では、
- 他システムとの通信
- 利用端末との接続
- バッチ連携
- API連携
- ファイル連携
などを整理します。
例えば、
- Active Directoryとの認証連携
- SMTPサーバへのメール送信
- 他システムへのAPI通信
- ファイルサーバとのデータ連携
などです。
ここでは、
- 通信方向
- プロトコル
- ポート番号
- 接続先
なども整理しておくと、ネットワーク設計やセキュリティ設計との整合性が取りやすくなります。
3. サーバ一覧・ソフトウェア一覧
システム構成が決まったら、各サーバやソフトウェアを一覧化します。
一般的には、
サーバ一覧
- サーバ名
- ホスト名
- OS
- 用途
- 配置場所
- IPアドレス
- 冗長構成有無
などを整理します。
また、ソフトウェア一覧では、
- OS
- Webサーバ
- APサーバ
- DB
- 監視ソフト
- バックアップソフト
- ウイルス対策ソフト
などを一覧化します。
この一覧は、後続工程である詳細設計や構築時の基礎資料として利用されるため、漏れなく整理しておくことが重要です。
4. 冗長化設計
基本設計では、システムをどのように冗長化するのかを決定します。
要件定義では、
- 可用性レベルⅢ
- 24時間365日稼働
- 障害時でもサービス停止を最小限にしたい
といった要求が決まっています。
基本設計では、それらの要求を満たすために、どのような冗長構成を採用するかを設計します。
例えば、次のような内容です。
- Webサーバは2台構成にする
- ロードバランサで負荷分散を行う
- データベースはクラスタ構成にする
- ストレージは冗長化構成を採用する
- ネットワーク機器は二重化する
重要なのは、「二重化する」という結論だけでなく、障害時にどのような動作を期待するのかまで整理することです。
例えば、
- サーバ障害時は自動で切り替わるのか
- 手動で切り替えるのか
- フェイルオーバーにどの程度時間がかかるのか
- メンテナンス時もサービス停止を避けられるのか
といった観点も設計方針として記載しておくと、後続工程で認識のズレが生じにくくなります。
また、クラウド環境では、マルチAZ構成やリージョン冗長などを採用するケースもありますが、「どのサービスを利用するか」よりも、「どのような考え方で可用性を確保するか」を設計書に残すことが重要です。
5. ネットワーク構成
ネットワーク構成図は、基本設計書の中でも特に重要な成果物の一つです。
ネットワーク構成図には、サーバだけではなく、ネットワーク機器や通信経路も含めた全体像を記載します。
例えば、以下のような内容です。
- ファイアウォール
- ロードバランサ
- ルータ
- L2/L3スイッチ
- インターネット接続
- VPN
- DMZ
- 社内LAN
- クラウドネットワーク（VPCやVNetなど）
また、サーバ間の接続関係だけでなく、
- どのネットワークセグメントに配置するか
- 通信経路
- 通信方向
- ファイアウォールを経由する通信
なども整理します。
ただし、この段階では細かなルーティング設定やACLの設定値までは決めません。
基本設計では、
「どのネットワークを通るのか」
「どのように通信するのか」
という設計方針を決めることが目的です。
実際のIPアドレス設定やルーティング設定は、詳細設計で記載するケースが一般的です。
6. サイジング（CPU・メモリ・ディスク）
基本設計では、サーバのスペックも決定します。
ここでいうサイジングとは、
「どれくらいの性能が必要なのか」
を決めることです。
一般的には、
- vCPU数
- CPUコア数
- メモリ容量
- ディスク容量
- ディスク性能（SSD・HDDなど）
を整理します。
このとき重要なのは、要件定義で決めた性能要件を根拠にサイジングを行うことです。
例えば、
- 同時接続数
- 最大利用者数
- バッチ処理時間
- データ容量
- 年間データ増加量
などをもとに、必要なリソースを見積もります。
また、現時点の利用量だけでなく、将来的な拡張も考慮します。
例えば、
「サービス開始時点ではディスク使用率は30%程度だが、5年間のデータ増加を考慮し、十分な空き容量を確保する」
といった設計方針を記載しておくと、将来的な容量不足を防ぎやすくなります。
7. 名前解決（DNS）
システムでは、サーバ同士がホスト名で通信するケースが多くあります。
そのため、基本設計では名前解決方式も決定します。
例えば、
- DNSサーバを利用する
- Active DirectoryのDNSを利用する
- クラウドのDNSサービスを利用する
- hostsファイルを利用する
などです。
さらに、
- 正引き・逆引きの実施有無
- 名前解決できない場合の影響
- DNSの冗長化
- 外部DNSとの連携
なども整理しておくと、障害時の切り分けや運用設計にも役立ちます。
詳細設計では各レコード情報まで定義しますが、基本設計では「どのような仕組みで名前解決を行うか」という方針を定めることが目的です。
8. 時刻同期（NTP）
時刻同期は見落とされがちですが、システム全体の整合性を保つために欠かせない設計項目です。
時刻がずれてしまうと、
- ログの時系列が一致しない
- 障害調査が困難になる
- 認証エラーが発生する
- クラスタソフトが正常に動作しない
といった問題につながることがあります。
そのため、基本設計では、
- どのNTPサーバを利用するか
- 上位NTPサーバは何か
- 社内NTPを利用するのか
- 外部NTPを利用するのか
- 冗長構成にするか
などを決定します。
クラウド環境ではクラウドベンダーが提供する時刻同期サービスを利用することもありますが、「全サーバが同じ基準時刻を参照する」という考え方はオンプレミスと共通です。
9. 命名規則
命名規則も、基本設計で決めておくべき重要な項目です。
案件によっては軽視されることもありますが、命名ルールが統一されていないと、構築・運用・保守のすべてで混乱が生じます。
例えば、
サーバ名であれば、
- システム名
- 環境（開発・検証・本番）
- サーバ種別
- 通し番号
を組み合わせたルールを定めます。
例）
- PRD-WEB-01
- PRD-DB-01
- DEV-AP-02
同様に、
- データベース名
- インスタンス名
- ディスク名
- ネットワーク名
- バックアップジョブ名
- 監視名
などについても、一定のルールを定めておくと、設計・構築・運用時の認識合わせが容易になります。
クラウド環境では、リソース数が増えやすいため、タグやリソース名の命名規則まで含めて基本設計で定義することも少なくありません。
基本設計で重要なのは「方針」を決めること
ここまで紹介した内容を見ると、「細かい設定値まで決めるのではないか」と感じるかもしれません。
しかし、基本設計で重要なのは具体的な設定値ではなく、設計方針を決めることです。
例えば、
- CPUを8コアにする
- メモリを32GBにする
という結論だけを書くのではなく、
「性能要件を満たすため、このスペックを採用する」
という判断の根拠を残すことが重要です。
また、
- DNSはActive Directoryを利用する
- NTPは社内NTPサーバを利用する
- ネットワークは3層構成とする
など、「なぜその方式を採用するのか」を説明できる内容になっていることが望ましいでしょう。
基本設計書は、構築担当者への指示書であると同時に、設計判断の根拠を残すドキュメントでもあります。
コメント