目次
1.はじめに
2.基本設計フェーズ
3.詳細設計フェーズ
1.はじめに
前回の続きで「1〜2年目のインフラエンジニア」の方や「インフラ案件を初めてやるよ！」という方向けに記事を書いていこうと思います！
自己紹介、記事掲載の背景等は前回の記事に記載していますので、よければ参照ください。
前回の記事はこちら↓
https://qiita.com/takuya_tsurumi/items/bebde1ab1fa1987bfcd0
今回は基本設計・詳細設計編です！
2.基本設計フェーズ
基本設計フェーズでは、
「要件定義書を元に全体構成を設計」し、基本設計書を作成します。
ここで思い出していただきたいことが1つあります！
要件定義フェーズで決定した機能要件・非機能要件です。それぞれの要件を元にシステム構成を決定していきます。(イメージ図はAWSだったらという想定で記載していきます。)
機能要件
システムを使用していく上で以下のことを考慮し、通信要件を決定します。
・どのサーバや端末と疎通が必要か
・必要なポートやプロトコルは何か
例えば、OSのセキュリティパッチインストールなど(yum update や Windows Update)で、インターネットとの疎通が必要である場合は、NAT(*1)サーバやProxy(*2)サーバを構築することを考慮するか、直接インターネットへ疎通可能な仕組みを構築するかのどちらかです。
AWSの場合、NATゲートウェイというサービスがあるため、簡単にインターネットとの疎通をとる仕組みを構築できます。
図1.1.インターネット疎通のための構成例(左:NAT、右:直接)
また、サーバがデータセンターにあり、社内の環境と疎通が必要なケースでは、専用線をひくことが多いです。
ライフサイクル対応の場合、すでに専用線がひかれている事の方が多いのであまり考慮する必要はないかと思います。
AWSの場合、DirectConnectというサービスを利用すれば実現可能です。
図1.2.DirectConnect疎通イメージ
非機能要件
可用性要件
構築するシステムが24時間365日運用したいという要件があれば、障害に耐えるために、サーバを複数台構成にする必要があります。また、大規模災害時にもサービスを停止させたくないという場合は、東日本に1拠点、西日本に1拠点など、複数の拠点を設ける必要があります。
逆に、内部向けのシステムで、1年間に数日程度停止可能なサービスであればサーバは１台構成で問題ありません。
性能・拡張性
どの程度のアクセス数があるのか、使用するデータ量はどの程度であるのかを想定しサーバの性能(CPUやメモリ、ストレージの容量等)を決めます。データ量が増える想定であれば、ストレージの拡張ができるよう、拡張を考慮した設計をします。
ただ、運用を始めてみないと、性能過不足の判断は難しいので、ライフサイクル対応の案件である場合、今動いているサーバのスペックで満足なのか、スペックを上げる必要があるのかを考え、決定すれば問題ありません。
運用・保守性
バックアップ構成
バックアップの頻度や種類(*3)拠点数を考慮し決めていきます。
例えば、障害発生時に前日の状態に戻したいという場合は、毎日バックアップをとる必要があリます。また、サーバが複数の拠点にある場合、バックアップの同期の仕組みを構築します。
(*3)バックアップの種類は以下参照
https://www.miraclelinux.com/product-service/mss/basic/knowledge/backup-type
監視
監視の種類(*4)を決定します。
ライフサイクル対応の場合、既存の監視システムをそのまま引用することを考慮しておけば問題ないかと思います。
(*4)監視の種類は以下参照
https://boxil.jp/mag/a2622/
マニュアル
誰がどのような運用をするのか想定し、誰でも運用できるマニュアルを作成する計画を立てます。
前回の記事で紹介した「ODSC」の「D」に当たる部分でもあります。
移行性
移行のスケジュールや方針を決めます。
移行は段階的に行っていくのか、それともシステムを一旦停止し、一斉に実施するのかどちらかを決めます。
セキュリティ
不特定多数の方々にサービスが提供される場合、個人情報のデータを暗号化したり、不正アクセス対策だったりのセキュリティを決めます。
AWSの場合、ストレージの暗号化もサービスとして存在し、またWebサーバの場合、SSL証明書(*5)を取得できるサービス(ACM)やWAF(*6)のサービスがあり、セキュリティ対策も容易に実現可能です。
(*5)HTTPS通信を可能にするための証明書。詳細は以下参照。
https://cspssl.jp/guide/certificate.php
(*6)Web Application Firewallの略。詳細は以下参照。
https://ds-b.jp/ds/publics/index/262/
環境・エコロジー
法律や条例などによる制限がないかの確認、耐震のある設備であるかどうかを確認します。
上記の内容を元にシステム構成図等を作成し、基本設計書に反映します。
基本設計書と同じタイミングでテスト計画や移行計画も立てますが、次回以降の記事で詳細を記載します。
この作成した基本設計書を詳細設計フェーズに繋げます。
3.詳細設計フェーズ
詳細設計フェーズでは、
「基本設計書をインプット情報に各コンポーネントの詳細な設定値の設計」を行い、詳細設計書を作成します。
この詳細設計書があれば次フェーズの構築が誰でもできるようなものを作成します。
このパラメータの粒度がどのくらいか、今回はWindows Server 2016のパラメータを例に挙げてみたいと思います。
例えばホスト名について。
以下の画面のコンピューター名の設定を変更することで、ホスト名を指定することができます。
図3.1.ホスト名変更画面
このコンピューター名を例えば、"WIN0001"とする場合、詳細設計書には、
「コンピューター名 ： WIN0001」
というように記載します。
この粒度で基本設計で決めた構成を実現できるよう、全てのパラメータを決定し、詳細設計書に反映します。
全パラメータが詳細設計書に反映できたら、次の構築フェーズに繋げていきます。
構築フェーズ以降はまた次回、Windows Serverの設定について触れながら書いていこうと思います。
それではまた次回！！