はじめに
インフラ設計のセオリー --要件定義から運用・保守まで全展開
をよんでみたのでメモしました
インフラ設計まとめ
- インフラエンジニアは主に要件定義の非機能要件を考える必要があり、お客さんと合意をとる必要もある。
- 定義された非機能要件を実現させるためにインフラ設計を考える。
- インフラ基本設計では具体的な製品、OSを用いて非機能要件の実現の具体的な方法を考える
- インフラ詳細設計ではサーバーパラメータシートなど、作業者が作業をできる粒度で情報を落とし込む
要件とは
必要な条件
システムインフラの役目
- 安定したサービス
- いつでも使える
- 障害に備えた仕組み作り
- サービスを継続できること
- 十分な性能
- ストレスを感じさせない性能
- 将来への拡張性
- 将来の需要に対応できる拡張性
- 安全な環境作り
- セキュリティ
システムインフラには以上の役目を果たす必要があり、実現させるための項目として非機能要件がある
要件定義
- 要件定義は機能要件と非機能要件から構成している
- 実装しなければいけない機能(機能要件)、達成しなければいけない性能(非機能要件)などを決めていく
- システム導入に必要な費用を算出するための資料
機能要件と非機能要件
機能要件
- 業務要件
- どの機能(業務)をシステムとして実装するか
- 業務を動かすためのアプリケーション機能やデータそのものの要求を示す。
機能要件は主にアプリケーションエンジニアが担当
非機能要件
- システム要件
- 要件が具体的な数値として提示しにくいなどの側面あり、発注者と受注者との行き違いがある
インフラエンジニアが主に要件定義すべき範囲は非機能要件
非機能要求に対する要件定義するためのツール
- 発注者と受注者との行き違い防止のため、非機能要求グレードと呼ばれるツールがある
非機能要求グレード
有名IT企業が集結して作成されたもので以下の非機能要求項目を定義している
- 可用性
- システムの壊れにくさ、信頼性
- 性能・拡張性
- システムに求める性能と、将来への拡張
- リソース不足時に容易に拡張可能か
- 運用・保守性
- バックアップによるデータ保護や問題発生時の対応レベル
- 移行性
- 現行システム資産を開発システムへ移行する手段や計画
- セキュリティ
- システムの安全性の要件
- 環境・エコロジー
- システムの設置環境への要求
インフラとしては以上の項目に対して要件(条件)をお客さんと定義して、それを実現させるためのインフラ設計をする必要がある
非機能要求項目
非機能要求項目に対してお客さんと話して、各項目の要件を決定する。各項目の値の要求が高い、低いなどはアプリケーションの利用者に対するサービスレベルで決まる
可用性
以下にサービスを停止させないようにするか、影響範囲を極小化させるか
以下の4つから構成
- 継続性
- 耐久障害性
- 災害対策
- 回復性
継続性
稼働率を定義する項目
システムの稼働率を定義する項目
- 継続する必要のある対象範囲はどの範囲までか
- 想定障害時における切り替え許容時間
- どの業務までを復旧対象とするか
- どの時点のデータまでを保証するか
- リストア時における業務復旧時間はどのくらいか
- 大規模災害時における業務再開目標はどのくらいか
上記項目について対象範囲と数値として稼働率などを定義する
耐障害性
- 機器やコンポーネント(HDD、電源、FANなど)をどのレベルまで冗長化するか
- 予算との関係でどの範囲をどこまで手厚い厚生で準備するか
回復性
システム障害などにより、バックアップからの回復手段や
性能・拡張性
- レスポンス、スループットを定義
- ピーク時の性能を定義
- 同時接続ユーザー数
- データ量
- バッチ処理件数
拡張性の予測を謝ると、システムの買い替え、再構築といった大掛かりな作業コストが発生するリスクを生む
運用・保守性
運用
- 運用体制
- ユーザアカウント管理
- 稼働率統計運用
- SLAやインシデントなどの月次、定期報告など
- 通常運用時間
- システムの利用時間
- 監視運用
- どの範囲をどのレベルまで
- バックアップ/リストア運用
- 何を、どこに、世代 - PRO(目標復旧時点)、災害や障害が起こった時にどの地点まで戻せていればよいのか
保守
- パッチ適用方針
- セキュリティパッチのみか
- パッチ適用タイミング
- 機器の保守契約
- HWベンダとの保守契約は24時間/365日必要なのか？
- 故障時はどの程度の時間で復旧を目指すのか？
- 機器の保守期間はどれくらい必要か
障害時運用
- 復旧方法や代替業務運用の範囲
- 異常検知時の対応
- 保守員の駆けつけ到着時間など
移行性
- 現行システムから新システムへのデータ移行に関する要求を定義
- 新規システムだけの場合は定義不要
セキュリティ
システムの安全性確保のための要件定義
一般的なセキュリティ対策要件
- 脆弱性対策
- アクセス制限
- システムへのログイン、など
- データ暗号化
- マルウェア対策
- リアルタイムスキャン
- 定期フルタイムスキャン
- 不正監視
- ログの取得、保管、監視間隔を定義
- ネットワーク対策
- FW導入、通信制御
要件の実現 = システムインフラの設計を考える
- 以上の要件に対して、システムインフラをどのように構成にすれば要件を満たすことができるのかを具体的に考える必要がある
- 基本設計は要件定義をインプットとして、論理的に具体化したもの
- 詳細設計は基本設計をインプットとして、OSやミドルウェアなどのパラメータ定義、システムを構築する担当が滞りなく作業ができるように具体的に落とし込む
インフラの設計
可用性設計(耐障害性設計)
- 単一障害点の排除 = ネットワーク機器、サーバーの冗長化
どのような冗長化があるか
サーバー内ハードウェアの冗長化
電源ユニットの冗長化
電源ユニットが2つなら電源系統も2つ用意する
NICの冗長化
- フォールトトレランス(アクティブ/スタンバイ)
- 可用性の向上
- ロードバランシング
- セッションごとに仕様するNICを分散
- 可用性、性能も向上 そのぶん設計や構成が複雑になりがち
- LAG
- 複数の物理NICを一つの論理的なNICにみせる。IPアドレスひとつ。可用性、性能も向上
- スイッチにまたがって設定できない
- 複数のスイッチにまたがる場合は、スタック構成のスイッチが必要
ハードディスクの冗長化
- Raid1
- ミラーリング
- Raid1+0
- ミラーリング + ストライピング
- 冗長化 + io性能向上
- Raid5
- 最低３本から
- 1本故障しても、パリティ情報から復元できる
- Raid6
- Raid5のパリティを冗長化
- 同時に２本故障しても耐えられる
サーバーの冗長化
- クラスタリングで実現
- 並列クラスタ
- 同じ機能・役割を持ったサーバーを複数台用意
- ロードバランサで負荷分散させる
- HAクラスタ
- アクティブ・スタンバイ構成
仮想化製品でのHAクラスタ
-
vmware のHAクラスタ
- 仮想ディスクを共有ディスクに配置するので、複数の物理サーバから共有できるようになるので、ある物理ホストで障害が起きても、別の物理サーバー上で起動して継続できる
性能・拡張性
前提となる情報
- システム利用ユーザー数
- 同時アクセス数
- データの量、保管期間
- レスポンスタイム目標値
- スループット目標値
上記を事前に見積もって安全率をかける値を使用する。1.2~1.5程度の値を使用。
CPU、メモリ、ディスク容量など
運用・保守設計
- システムとして何時から何時までサービスを提供するのか？
- バックアップはどのような内容をどの程度の頻度で取得し、どれくらいの時間保管すればいいのか？
- システムバックアップ、データのバックアップ、監査ログバックアップ
- ユーザーと「障害発生時にどのポイントまで復旧できることを要件とするか」
- システムの監視は？
- ログ、リソース、など
- メンテナンスなどのシステムを停止する場合の「システム停止時間」はいつどのような時間帯になるのか？
- 運用はどのようなサポート体制で実施していくのか？
- 緊急連絡先、対応時間帯の定義など
セキュリティ設計
セキュリティ要件
- 識別と認証
- 暗号化
- 通信制御
- 監視・監査
- セキュリティリスク
- ウイルス・マルウェア対sカウ
識別と認証
- ユーザーID管理
- 複数回失敗時のロック
- 適切な権限のふるまいとアクセスできる範囲の限定
- 認証
- 電子証明書。サーバー証明書、クライアント証明書の適切な利用
- ワンタイムパスワード
暗号化
- PC
- 持ち出し禁止の徹底
- 機密データは暗号化、
- だれでも触れる端末に重要データを置かないルール
- 電子メールの暗号化、電子署名 電子メール対策
- ネットワーク
通信制御
- FWによるアクセス制御
- WAFによるL7レベルでのアクセス制御
- IDS、IPSの設置
ウイルス・マルウェア対策
- OSのアップデート
- ウイルス・マルウェア対策ソフトの導入
- 定期的なスキャン実行
SLA(Service Level Agreement)
インフラを設計する場合、システム全体で提供されるサービスについてのサービス・レベルも考える必要があり、クライアントと合意が必要。
https://www.hitachi-systems.com/report/outsourcing/column8-2.html
http://www.city.nara.lg.jp/www/contents/1559882815241/files/14hp_SLAyokyu.pdf
様々なSLA項目がある
SLAの運用
定期的に SLA 項目を測定し、報告を行う。測定値が設定値を下回る場合は、プロセスの見直しを行い、運用改善を実施する。