はじめに
前回の記事では、インフラエンジニアが基本設計で実施する内容について解説しました。
基本設計では、要件定義で決定した内容をもとに、システム構成やネットワーク構成、サーバ構成、冗長化方式など、「どのようなシステムを構築するか」という設計方針を決定します。
しかし、基本設計だけではシステムを構築することはできません。
例えば、「Apacheを利用する」と決まっていても、httpd.confのどの設定を変更するのか、「Rocky Linuxを採用する」と決まっていても、sysctl.confやchrony.confにどのような設定を行うのかまでは決まっていません。
これらの具体的な設定内容を決定し、構築担当者が迷わず作業できるレベルまで設計を落とし込む工程が詳細設計です。
この記事では、インフラエンジニアが詳細設計で実施する内容や基本設計との違い、そして実際の現場で最も重要な成果物の一つであるパラメータシートについて解説します。
詳細設計とは
詳細設計とは、基本設計で決定した内容を、実際に構築できるレベルまで具体化する工程です。
基本設計では、「どのようなシステム構成にするのか」「どのような方式を採用するのか」といった設計方針を決定しました。
一方、詳細設計では、「どのファイルをどのように設定するのか」「各パラメータにどの値を設定するのか」を決定します。
例えば、基本設計で「NTPによる時刻同期を行う」と決まっている場合、詳細設計では次のような内容を決定します。
- 参照するNTPサーバ
chrony.confの設定内容- 起動設定
- 同期確認方法
また、「Apacheを利用する」と決まっている場合は、
httpd.confssl.conf- VirtualHost
- ログ出力先
- KeepAlive設定
などを具体的に設計します。
つまり、詳細設計は構築担当者への作業指示書とも言える工程です。
設計書を見ながら設定すれば、誰が構築しても同じ環境になることを目指します。
基本設計との違い
詳細設計を理解する上で重要なのが、基本設計との役割の違いです。
簡単に言えば、
- 基本設計は「何を採用するか」
- 詳細設計は「どのように設定するか」
を決める工程です。
例えば、DNSを例にすると違いは分かりやすくなります。
基本設計では、
- DNSを利用する
- Active Directory DNSを採用する
- 正引き・逆引きを実施する
という方針を決定します。
一方、詳細設計では、
- ゾーン情報
- Aレコード
- PTRレコード
- CNAME
- TTL
- フォワーダ設定
など、設定内容を決定します。
Apacheでも同様です。
基本設計では「Apacheを採用する」と決めますが、詳細設計ではhttpd.confやssl.confの設定内容を決定します。
Linuxであれば、
sysctl.confsshd_configchrony.conf/etc/fstab
など、各設定ファイルの内容まで設計します。
このように、構成を決めるのが基本設計、設定値を決めるのが詳細設計と考えると理解しやすいでしょう。
詳細設計で作成する成果物
詳細設計では、多くの設計書を作成しますが、その中心となるのがパラメータシートです。
一般的なプロジェクトでは、次のようなパラメータシートを作成します。
- クラウド環境（AWS、Azureなど）
- 仮想基盤（VMwareなど）
- OS
- Webサーバ
- APサーバ
- データベース
- 監視
- バックアップ
- ジョブ管理
- セキュリティ製品
例えばAWSであれば、
- EC2
- EBS
- Security Group
- IAM
- Application Load Balancer
- Route 53
などの設定内容を整理します。
VMwareでは、
- vCPU
- メモリ
- データストア
- Port Group
- HA
- DRS
などを設計します。
OSでは、
- ホスト名
- IPアドレス
- NTP
- DNS
- カーネルパラメータ
- ユーザ
- サービス設定
などが対象になります。
プロジェクトによって対象製品は異なりますが、目的は共通しています。
誰が構築しても同じ環境を再現できるようにすることです。
詳細設計の中心となるパラメータシート
詳細設計で最も重要な成果物がパラメータシートです。
現場では設計書よりも、パラメータシートを参照する機会の方が多いと言っても過言ではありません。
構築担当者はパラメータシートを見ながら設定を行い、テスト担当者はその内容が正しく設定されているかを確認します。
さらに、障害対応や保守作業では、「現在どのような設定になっているか」を確認するためにパラメータシートが利用されます。
つまり、パラメータシートは、
- 設計資料
- 構築資料
- テスト資料
- 保守資料
という複数の役割を持っています。
そのため、設定値だけを書くだけではなく、「誰が見ても分かる設計書」であることが重要です。
デフォルト値と設定値を記載する理由
設計初心者が最も見落としやすいポイントが、デフォルト値を記載することです。
「変更した設定だけを書けばよいのではないか」と考える方も多いですが、実際の現場ではデフォルト値と設定値を並べて記載することが一般的です。
例えばApacheのKeepAliveを設定する場合、
| パラメータ | デフォルト値 | 設定値 |
|---|---|---|
| KeepAlive | On | Off |
というように記載します。
もし設定値だけを書いてしまうと、
- デフォルトから変更したのか
- 元々その値だったのか
を判断することができません。
レビュー担当者も、「どこを変更したのか」を確認するために設定ファイルを開く必要があり、レビュー効率が低下します。
また、数年後にシステム更改やバージョンアップを行う際にも、デフォルト値が記載されていれば、「当時どの設定を変更したのか」がすぐに分かります。
パラメータシートは構築時だけでなく、保守や更改でも利用されるため、変更内容が一目で分かるように作成することが重要です。
全項目を記載する理由
パラメータシートを作成する際に、もう一つ重要なのが全項目を記載することです。
設計経験が浅いと、「変更する項目だけを記載すれば十分ではないか」と考えがちです。
しかし、多くの現場では、変更する項目だけではなく、変更しない項目も含めてすべて記載します。
例えば、OSのカーネルパラメータやApacheの設定項目が数百個ある場合でも、基本的にはすべてを一覧化します。
その理由は、設計書を「システムの設定情報を管理する台帳」として利用するためです。
例えば障害調査で、
「この設定はどうなっていたか」
という確認が必要になった場合、変更項目しか記載されていない設計書では、実際のサーバへログインして設定ファイルを確認する必要があります。
一方、全項目が記載されていれば、設計書を見るだけで設定内容を確認できます。
また、レビュー時にも「記載漏れ」なのか「デフォルト値のまま」なのかを判断しやすくなり、認識違いを防ぐことができます。
一見すると手間がかかるように思えますが、構築・テスト・保守の効率を考えると、全項目を管理するメリットは非常に大きいと言えるでしょう。
前編のまとめ
詳細設計は、基本設計で決めた内容を、実際に構築できるレベルまで具体化する重要な工程です。
その中でも、パラメータシートは詳細設計の中心となる成果物であり、構築担当者だけでなく、レビュー担当者やテスト担当者、運用担当者まで多くの関係者が利用します。
また、品質の高いパラメータシートを作成するためには、
- デフォルト値と設定値を並べて記載すること
- 変更した項目だけでなく、全項目を管理すること
が重要です。
後編では、さらに実践的な内容として、単体テストを意識したパラメータシートの作り方や、レビューでよく指摘されるポイント、現場で役立つ設計のコツについて詳しく解説します。
コメント