はじめに
インフラ構築の各フェーズ（非機能要件定義・基本設計・詳細設計）で考えることのメモです。 要するに非機能要求グレードの抜粋。
非機能要件定義
非機能要件定義項目
| 大項目 | 中項目 | 小項目 | 小項目説明 | 例 |
|---|---|---|---|---|
| 可用性 | 継続性 | 運用スケジュール | システムの稼働時間や停止運用に関する情報。 |
運用時間: 24/365 計画停止: 計画停止有り |
| 業務継続性 | 可用性を保証するにあたり、要求される業務の範囲とその条件。 |
対象業務範囲: 全ての業務 サービス切替時間: 10分 業務継続の要求度: 障害時の業務停止を許容する |
||
| 目標復旧水準 | 業務停止を伴う障害が発生した際、何をどこまで、どれ位で復旧させるかの目標。 |
RPO（目標復旧地点）: 前日時点（日次バックアップからの復旧） RTO（目標復旧時間）: 12時間以内 RLO（目標復旧レベル）: 全ての業務 |
||
| 稼働率 | 明示された利用条件の下で、システムが要求されたサービスを提供できる割合。 明示された利用条件とは、運用スケジュールや、目標復旧水準により定義された業務が稼働している条件を指す。その稼働時間の中で、サービス中断が発生した時間により稼働率を求める。 |
99.9% ただし、システムメンテナンスによる停止時間はこの稼働率には含まないこととする |
||
| 災害対策 | 災害対策 | リージョン内レベルまでの対策を実施する。 ※リージョン単位の障害の際は、システム全停止となる。（データはS3にて担保） |
||
| 性能・拡張性 | 業務処理量 | 通常時の業務量 | 性能・拡張性に影響を与える業務量。 該当システムの稼働時を想定し、合意する。 それぞれのメトリクスに於いて、単一の値だけでなく、前提となる時間帯や季節の特性なども考慮する。 |
ユーザ数: 100人 同時アクセス数: 50人 データ量: 500k/1画面 オンラインリクエスト数: 10画面/時間 バッチ処理件数: 50万件/日 |
| 業務量増大度 | システム稼動開始からライフサイクル終了までの間で、開始時点と業務量が最大になる時点の業務量の倍率。 必要に応じ、開始日の平均値や、開始後の定常状態との比較を行う場合もある。 |
ユーザ数: 2倍 同時アクセス数: 2倍 データ量: 2倍 オンラインリクエスト数: 2倍 バッチ処理件数: 2倍 |
||
| 保管期間 | システムが参照するデータのうち、OSやミドルウェアのログなどのシステム基盤が利用するデータに対する保管が必要な期間。 必要に応じて、データの種別毎に定める。 保管対象のデータを選択する際には、対象範囲についても決めておく。 |
アプリログ: 3ヶ月 操作（監査）ログ: 1年 |
||
| 性能目標値 | オンラインレスポンス | オンラインシステム利用時に要求されるレスポンス。 システム化する対象業務の特性をふまえ、どの程度のレスポンスが必要かについて確認する。ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に順守率を決める。具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。（例：Webシステムの参照系/更新系/一覧系など） |
3秒 | |
| バッチレスポンス（ターンアラウンドタイム） | バッチシステム利用時に要求されるレスポンス。 システム化する対象業務の特性をふまえ、どの程度のレスポンス（ターンアラウンドタイム）が必要かについて確認する。更に、ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に順守率を決める、具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。 （例：日次処理/月次処理/年次処理など） |
バッチウィンドウ（22:00-6:00）内におさまること | ||
| オンラインスループット | オンラインシステム利用時に要求されるスループット。 システム化する対象業務の特性をふまえ、単位時間にどれだけの量の作業ができるかを確認する。更に、ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に処理余裕率を決める、具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。 （例：データエントリ件数/時間、頁めくり回数/分、TPSなど） |
10TPS | ||
| バッチスループット | バッチシステム利用時に要求されるスループット。 システム化する対象業務の特性をふまえ、どの程度のスループットを確保すべきか確認する。更に、ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に処理余裕率を決める。具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。 （例：人事異動情報一括更新処理、一括メール送信処理など） |
バッチウィンドウ（22:00-6:00）内におさまること | ||
| リソース拡張性 | リソース拡張方式 | システム停止を伴わずにリソースの自動拡張が可能。 | ||
| 運用・保守性 | 通常運用 | 運用時間 | システム運用を行う時間。利用者やシステム管理者に対してサービスを提供するために、システムを稼動させ、オンライン処理やバッチ処理を実行している時間帯のこと。 |
|
| バックアップ | システムが利用するデータのバックアップに関する項目。 |
アプリログ: 3ヶ月 操作（監査）ログ: 1年 |
||
| 運用監視 | システム全体、あるいはそれを構成するハードウェア・ソフトウェア（業務アプリケーションを含む）に対する監視に関する項目。 セキュリティ監視については本項目には含めない。「E.7.1 不正監視」で別途検討すること。 |
監視情報: 死活監視、ログ監視、性能監視 監視感覚: リアルタイム監視（分間隔） |
||
| 時刻同期 | システムを構成する機器の時刻同期に関する項目。 |
|||
| 保守運用 | 計画停止 | 点検作業や領域拡張、デフラグ、マスターデータのメンテナンス等、システムの保守作業の実施を目的とした、事前計画済みのサービス停止に関する項目。 |
||
| サポート体制 | サポート体制 | マルチベンダのサポート契約を行う（一部対象外を許容） | ||
| その他の運用管理方針 | サービスデスク | ユーザの問合せに対して単一の窓口機能を提供するかどうかに関する項目。 |
新規にサービスデスクを設置する | |
| 移行性 | 移行性要件は、現時点で移行予定がないため、考慮不要とする。 | |||
| セキュリティ | 前提条件・制約条件 | 情報セキュリティに関するコンプライアンス | 順守すべき情報セキュリティに関する組織規程やルール、法令、ガイドライン等が存在するかどうかを確認するための項目。 なお、順守すべき規程等が存在する場合は、規定されている内容と矛盾が生じないよう対策を検討する。 例） ・国内/海外の法律 ・資格認証 ・ガイドライン ・その他ルール |
インターネットへの公開は行わない※1 個人情報は保持しない |
| アクセス・利用制限 | 認証機能 | 資産を利用する主体（利用者や機器等）を識別するための認証を実施するか、また、どの程度実施するのかを確認するための項目。 複数回の認証を実施することにより、抑止効果を高めることができる。 なお、認証するための方式としては、ID/パスワードによる認証や、ICカード等を用いた認証等がある。 |
1回 複数方式/複数回 |
|
| データの秘匿 | データ暗号化 | 機密性のあるデータを、伝送時や蓄積時に秘匿するための暗号化を実施するかを確認するための項目。 |
蓄積データ暗号化 個人情報を持たないシステムであるため、蓄積データの暗号化は実施しない。 通信経路暗号化 閉域網であり、保護すべきデータ内容と処理のオーバーヘッドを鑑みて暗号化は実施しない。 |
|
| 不正追跡・監視 | 不正監視 | 不正行為を検知するために、それらの不正について監視する範囲や、監視の記録を保存する量や期間を確認するための項目。 なお、どのようなログを取得する必要があるかは、実現するシステムやサービスに応じて決定する必要がある。 また、ログを取得する場合には、不正監視対象と併せて、取得したログのうち、確認する範囲を定める必要がある。 |
構成要素別（サーバ、DB、アプリケーション）に監査ログを取得し、不正操作発生時にいつ、どこから、誰が、どうしたかを追跡できるようにする。 | |
| マルウェア対策 | マルウェア対策 | マルウェア（ウィルス、ワーム、ボット等）の感染を防止する、マルウェア対策の実施範囲やチェックタイミングを確認するための項目。 対策を実施する場合には、ウィルス定義ファイルの更新方法やタイミングについても検討し、常に最新の状態となるようにする必要がある。 |
システム構成にIaaSや物理サーバなどのOSを含む場合は、マルウェア対策ソフトをインストールする。外部のマネージドサービス(PaaSなど)を利用する場合は、その限りではない。 | |
| システム環境・エコロジー |
要確認ポイント
- 関連する既存システムの構成
- OS・利用サービスの指定
- NWアクセス経路のフィジビリティ確認（プロトコルも合わせて）
- 運用アクセス含め
- レスポンスタイム、バッチウィンドウの制約
- 外部サービスの利用制限
- ライセンス購入の考え方
- クラウドの契約
- インフラ費用の目処感
- 構成管理ツールの指定
- セキュリティポリシーの有無
- クラウド利用可否、暗号化等
- セキュリティツールの指定
- 監視ツールの指定
- デプロイツールの指定
- バックアップ・リストア・改廃ツールの指定
- BCPの要否
- 運用保守ベンダの指定、関連ベンダ
基本設計
基本設計書目次
- システム化方針
- SPOF、マネージド、開発スピードと保守、OSS、既存
- 全体システム俯瞰
- （環境定義）
- アーキテクチャ構成
- ネットワーク構成
- 外部との通信、VPC設計
- ハードウェア構成
- ソフトウェア構成
- アプリケーション、FW/ライブラリ、実行環境（言語、OS）、実行リソース
- （クライアント構成）
- バージョン想定
- 処理方式概要
- フローチャート
- 配置場所、トリガ
- シーケンス
- フローチャート
- 製品・技術要素選定根拠
- メリデメ、経緯
- 費用試算
詳細設計
詳細設計フェーズタスク
- アプリ環境（AWS）
- アプリ環境（サーバ）
- 運用環境（踏み台）
- 運用環境（デプロイ）
- 運用環境（監視）
- 運用環境（バックアップ・リストア・改廃）
- 運用環境（セキュリティ）
詳細設計フェーズ成果物
- インフラ設計方針書
- パラメータシート
- 監視設定一覧
- バックアップ・リスト・改廃一覧
- ログ改廃設定書
- DR手順書
- デプロイ手順書
- リモート接続手順書
- 運用設計書
- 運用作業手順書
詳細設計ポイント
- 命名規則
- IPレンジ設計
- コンテナIMMUTABLE設定
- ロードバランサのスティッキーセッション、タイムアウト、sorryページへの振り分け、ALB/CLB/ELBの選定（クライアント認証など）
- 証明書、ドメイン
- DBメンテナンスウィンドウ、バックアップウィンドウ
- デプロイ方式。瞬断が許されるか。
- OS su,sudoコマンド制限、パスワードログイン禁止、時刻同期、swap
