本章では、手動作業による運用からの脱却と、本番環境への人的介入を最小化する「Zero Touch Production」（後述）の実現に向けた具体的な手法を解説する。インフラ構成を手動でなくコードで管理・自動化するIaC（Infrastructure as Code）によるインフラ管理、アプリケーションのコード変更からデプロイまでを連続して自動実行するCI/CDパイプラインによるデプロイ、インシデント対応(障害対応)の自動化、定型作業のスクリプト化などを通じて、人的ミスとセキュリティリスクを根本的に排除し、運用品質の向上を実現する。

3.1 運用のコード化・自動化の重要性

3.1.1 運用のコード化・自動化による品質向上とリスク低減

システム運用における手動作業は、どれだけ注意深く実施しても人的ミスのリスクを完全に排除できない。例えば、本番環境での設定変更作業において、手順書に基づいて慎重に作業を進めたとしても、設定値の入力ミス、作業手順の読み飛ばし、環境の取り違えなどが発生する可能性がある。また、人的ミスを低減させる方策として、詳細な手順書の準備や複数名でのダブルチェック体制を講じる場合もあるが、これらの対策には相応のコストと労力が必要となり、かつ人的ミスのリスクを完全には排除できない。

さらに、本番環境への人的介入は、セキュリティ上のリスクも伴う。運用担当者に本番環境への管理者権限を付与することは、意図しない操作による障害だけでなく、内部犯行によるデータ漏洩や不正操作といったセキュリティインシデントの可能性を高める。

これらの課題を根本的に解決するためには、運用作業を自動化し、人間が本番環境に直接介入する必要性を最小化することが重要である。具体的には、IaCやCI/CDパイプラインなどの技術を活用し、インフラ構築やアプリケーションデプロイを自動化することで、人的ミスのリスクを根本的に排除できる。自動化により、作業の品質を一定に保ちながら運用コストを適正化し、さらに本番環境への直接的な人的介入を減らすことでセキュリティリスクの低減にもつながる。

図 3-1 手動作業による運用と自動化による運用の比較

3.1.2 本章で扱う運用のコード化・自動化の領域と優先順位

本章では、本番環境に人が直接ログインすることなく運用を行う「Zero Touch Production」の実現を目指し、以下の3つの領域における自動化の具体的な手法を解説する。

自動化の3つの領域

1. インフラ、アプリケーションのデプロイ自動化（3.3節〜3.4節）
   • IaCを活用したインフラ構築の自動化により、手動作業による設定ミスを排除する。
   • CI/CDパイプラインによるアプリケーションデプロイの自動化により、リリース作業の品質と効率を向上させる。
2. インシデント対応の自動化（3.6節）
   • 自動復旧の仕組みを導入し、インシデント（障害）発生から復旧完了までの時間を短縮する。
   • 人手を介さない自動対応により、夜間・休日を含めた24時間365日の安定運用を実現する。
3. 定型作業の自動化（3.5節）
   • 日常的に発生する反復作業をスクリプト化し、作業時間の削減と品質の均一化を図る。
   • 自動化により運用担当者は、より付加価値の高い改善活動に注力できる。

取り組みの優先順位の考え方

限られたリソースで自動化に取り組む場合、以下の観点から優先順位を判断することを推奨する。

なお、以下の優先順位はあくまで一般的な目安であり、各システムの特性や組織の状況に応じて柔軟に判断することが重要である。

• 優先度A（高）：影響度が大きく、実装の難易度が比較的低いなもの
  • 人的ミスが発生した場合の影響が大きい作業
  • CSPのマネージドサービスを活用することで比較的容易に自動化できる作業
  • 例：定型的なデータベースバックアップの自動化、OSパッチ適用作業の自動化
• 優先度B（中）：効果は高いが実装に一定の工数が必要なもの
  • 頻繁に実施される作業で、自動化による工数削減効果が大きい
  • 実装には一定の工数が必要だが、投資対効果が見込める
  • 例：定型レポート作成の自動化、アプリケーションデプロイのCI/CDパイプライン整備
• 優先度C（中長期）：効果は大きいが、設計段階からの組み込みが必要なもの
  • システム全体のアーキテクチャに影響する自動化
  • 既存システムへの適用は難易度が高いが、次期更改時には検討すべき
  • 例：IaCによる全インフラ管理、オートスケーリングなど自動復旧のためのアーキテクチャ見直し

3.2 Zero Touch Productionの必要性

3.2.1 手動による本番ログイン作業の課題

システム運用において、本番サーバーログイン作業やCSP管理コンソールでの設定変更作業は、サービス停止やユーザーへの直接的な影響を伴うリスクがあり、人的ミスに起因するシステム障害やセキュリティインシデントが発生した場合の影響範囲が甚大である。あらためて、従来の手動による運用手法における主な課題を以下に示す。

人的ミスに関する課題

• 人的ミスの発生を防げない
  • 手動作業による設定変更では、誤ったコマンド実行、設定ファイルの不適切な編集、作業手順の読み飛ばしや実行順序の誤りなど、様々な人的ミスが発生する可能性がある。
  • 本番環境での人的ミスは即座にサービス停止やデータの破損につながり、復旧までの間、サービスの提供が困難となる。
  • 特に緊急時においては、時間的プレッシャーの中で不適切な判断や操作が行われやすくなる。
• 作業時間の長期化
  • 手動作業によるオペレーションでは、各工程でのコマンド実行やステータスの目視確認、手順のダブルチェックが必要となり、作業が数時間を要する場合もある。
  • このような作業時間の長期化は、システムメンテナンス時間の長期化を招き、サービスの提供時間に悪影響を及ぼす。
• 作業の属人化
  • 複雑なシステムの運用知識や作業手順が特定の担当者にのみ蓄積され、その担当者以外では適切な作業が困難になる状況が発生する。
  • 有識者の休暇や退職により、緊急時の対応が不可能となったり、作業品質が低下するリスクがある。

セキュリティに関する課題

• 過剰な権限の付与
  • 手動作業による設定変更を実施するため、運用担当者には管理者権限が付与される傾向にある。
  • 本番環境での過剰な権限付与は、ユーザーのデータへの直接アクセスや重要なシステム設定の変更が可能となるため、セキュリティインシデントが発生する可能性がある。
  • また、一度付与された権限の削除が適切に実施されない場合、業務上不要となった権限が放置されるなどして、セキュリティリスクがさらに増加する。
• 不正操作の検知の困難さ
  • 管理者権限が付与された後の不正な操作は、システムから見ると正常な作業と区別がつかない。
  • このため、悪意を持った内部関係者による破壊的なコマンドの実行や不正アクセスを検知し、防止することが難しい。

運用コストに関する課題

• 要員確保の困難さ
  • 本番環境のオペレーションでは作業者及びダブルチェック要員の確保が必要となるが、夜間や休日のオペレーションを考慮する場合、要員確保が困難となる可能性がある。

3.2.2 Zero Touch Productionの実現アプローチ

3.2.1で述べた課題に対する解決策として、IaCやCI/CDパイプライン(後述)を活用した自動化を実施する。自動化の実現により、本番サーバーログイン作業やCSP管理コンソールでの設定変更が不要となり、人的ミスや不正操作による本番環境への影響を最小限に抑えながら、安全な運用を実現することができる「Zero Touch Production」を実現するためのアプローチを本節で説明する。

検証環境と本番環境の両方での実現

Zero Touch Productionは、本番環境のみならず本番環境に適用する前にテストを行うための検証環境においても目指すべきである。その理由は以下の通りである。

• 本番作業のリハーサル
  • 検証環境は本番環境での作業手順を事前に検証する重要な役割を担っている。検証環境で手動作業を行いながら本番環境で自動化を実行すると、実際の本番作業のリハーサルにならず、本番環境で初めて自動化プロセスを実行することになる。これにより、CI/CDパイプラインや自動化作業の不具合、想定外の動作が本番環境で発見されるリスクが生じる。検証環境においても本番環境と同一の手法を採用することで、本番作業の完全なリハーサルを実現し、作業品質を担保できる。（図3-2 参照）
• 自動化の徹底
  • 検証環境で手動作業を許容した場合、本番環境でも同じ手動作業が必要になる。なぜなら、本番環境では検証環境で検証済みの手順を実行することが前提となるためである。このため、検証環境から作業の自動化を徹底することで、本番環境においても検証環境と同じ自動化手順の実行が可能となり、人的ミスに起因するシステム障害のリスクを排除できる。

図 3-2 検証環境と本番環境での同一手法の適用イメージ

自動化の実現方法

「3.1.2 本章で扱う運用のコード化・自動化の領域と優先順位」で示した3つの自動化領域に対して、以下の方法で実現する。優先度の高い領域から順に説明する。また自動化を進めてZero Touch Productionへ進化するステップのイメージを図3-3に示す。

• インフラ、アプリケーションのデプロイ自動化
  • 本番環境および検証環境におけるインフラとアプリケーションのリリース作業では、CI/CDパイプラインによる自動デプロイの仕組みを構築する。この仕組みにより、コードの変更からデプロイまで、一連のプロセスが人的介入を排除した形で実行できる。
  • 詳細は、インフラ管理については「3.3 インフラ管理のIaC（Infrastructure as Code）化」、アプリケーションデプロイについては「3.4 アプリケーションのデプロイ戦略の選択」で解説する。
• 定型作業の自動化
  • 日常的に発生する定型作業においては、作業手順のスクリプト化を推進し、CSPが提供するサーバレス実行環境やタスクスケジューリング機能を活用した自動化の仕組みを構築する。例として、データベースバックアップの自動実行、定期的なログ収集、レポート作成、データベースに対するSQL実行などが挙げられる。
  • この方法により、従来の手動作業の際に必要であった踏み台サーバーの運用が不要となり、セキュリティリスクを増加させる構成を回避できる。
  • 詳細は「3.5 定型的な作業の自動化」で解説する。
• インシデント（障害）対応の自動化
  • 障害発生時の自動復旧の仕組みを構築する。CSPが提供するオートスケーリング、ヘルスチェック連動の自動再起動、自動フェイルオーバーなどの機能を活用することで、人手を介さないインシデント（障害）対応を実現する。
  • 詳細は「3.6 障害対応の自動化とリモート化」で解説する。

図 3-3 Zero Touch Productionへの進化のイメージ

このような自動化手法により手動作業の必要性がなくなれば、運用担当者にクラウドリソースの変更操作権限を付与する必要がなくなり、意図しない変更や操作ミスを防止できる。その結果、すべての変更操作を自動化されたプロセス経由で実行することが保証され、信頼性の高いシステム運用が実現できる。

自動化における投資対効果の考慮

自動化を推進する上で、すべての作業を自動化することが常に最適とは限らない。以下のような場合には、自動化の必要性を慎重に判断することが重要である。

• 技術的な制約がある場合: 利用しているCSPやツールの制約により、自動化の実現が技術的に困難または過度に複雑になる場合は、手動作業での運用を許容することも選択肢となる。
• 実施頻度が極めて低い場合: システムのライフサイクル全体で1回程度しか実施しない作業や、年に数回程度の低頻度の作業については、自動化に要する開発・保守コストが手動作業の運用コストを上回る可能性がある。
• 一時的または試験的な作業の場合: 検証目的の一時的な環境構築や、将来的に廃止予定の機能に関する作業については、自動化への投資対効果が見込めない場合がある。

これらの判断においては、自動化に必要な開発工数、保守工数、技術的複雑性と、手動作業を継続した場合の運用コスト、人的ミスのリスク、セキュリティリスクを総合的に評価し、過度なオーバーエンジニアリングを避けつつ、適切なバランスで自動化の範囲を決定することが重要である。ただし、人的ミスが重大な影響を及ぼす可能性がある作業については、実施頻度が低い場合でも自動化を優先的に検討すべきである。

3.2.3 緊急時ログインの実装例

本番環境の運用においては、パイプラインによる運用自動化を行い、本番サーバーログインやCSP管理コンソールでの設定変更を排除することが望ましい。しかしながら、利用システムにおいてセキュリティインシデントや本番環境で重大な障害が発生し、サービスの提供に影響を及ぼす緊急事態においては、迅速なシステム復旧をするため、例外的に手動での設定変更が求められる場合がある。

このような緊急事態に対処する必要がある場合は、緊急時専用の手動による設定変更手段の用意も検討する。具体的な手段として、緊急時におけるリソースの設定変更が可能な権限を用意し、担当者に当該権限を付与することにより、本番環境の状況確認や設定変更を可能とする。付与された権限は、緊急事態の解決後または作業完了後速やかに削除を行う。

また作業後には、利用した権限の使用状況を点検・監査し、以下を確認・実施する。

• 権限の不正使用や削除漏れがないことの確認
• 権限使用の記録保管による説明責任の確保

セキュリティリスクの管理

緊急時には迅速な復旧作業が最優先事項となる一方で、権限昇格はセキュリティ上大きなリスクを伴う操作となる。このため、以下の対策を講じる。

• 本番環境での手動作業用の権限は、人的ミスによる誤った環境変更リスクを低減するため、以下の2段階の権限セットを準備することが望ましい。
  • 参照権限：状況確認用（通常はこちらを使用）
  • 管理者権限：復旧作業用（更新作業時のみ昇格）
• 少なくとも管理者権限を利用する際は、人的ミスや不正操作防止のため、(a)単独作業は行わず必ず１名以上の確認者をつけ相互確認しながら作業を実施し、(b)事前に作業手順を整理し作業者と確認者で作業内容の認識確認をしてから実施すること、を徹底する。
• 権限昇格の開始から終了に至る過程において、実行者、作業内容、実施時刻を含む全ての操作履歴を詳細に記録し、後から点検・監査できるようにする。
• 権限昇格のプロセスにおいては、担当者からのリクエストに対して承認者による承認ステップを準備する。承認体制は夜間、休日を問わず機能する必要があるため、承認者不在時のエスカレーション手順を明確に定義することが重要である。
• なお通常のオペレーション中など、権限昇格が適切でない状況における不正使用を検知するために、権限昇格を利用システムの管理者へ通知する仕組みを導入する。通知を受けた権限昇格が、承認プロセスを得ていない不正な権限昇格であった場合は、速やかに権限の無効化を行うとともに、不正使用の根本原因を分析し再発防止策を策定する。

事前準備の実施

緊急事態発生時の迅速な対応を実現するため、以下の事前準備を実施する。

• 担当者に付与する権限の事前作成
• 承認プロセスの整備（承認完了次第、直ちに利用可能な状態）
• 定期的なテストによる有効性確認

また、手動作業による設定変更プロセスが必要な場合、プロセスの定期的なテストを実施し、非常時においても迅速に権限が付与可能であることを確認する。

3.3 インフラ管理のIaC（Infrastructure as Code）化

3.3.1 IaC化の目的

IaCとは

IaC（Infrastructure as Code）は、サーバー、データベース、ネットワークなどのクラウドインフラをコードとして定義・管理する手法である。従来の手動作業やGUI操作によるインフラ構築に代わり、プログラミング言語や専用の記述言語を用いてインフラ構成を記述し、ツールによって自動的に構築・変更を実行する。

IaC導入の目的

システム運用において、IaCの導入により以下の価値を実現することを主な目的とする。

品質の向上

• 構築作業の自動化による人的ミスの排除
  • 担当者はリソース定義をコードとして記述し、実際のインフラ構築作業はIaCツールが自動実行することができる。
  • これにより、手動作業による設定ミスや手順の抜け漏れを根本的に排除できる。
• コードレビューによる事前検証
  • インフラ構成をコードとして記述することで、設計が正しく反映されているかや設定内容の妥当性を、インフラ構築作業の前に検証できる。
  • これにより、複数の担当者によるコードレビューを通じて、設定の不備を早期に発見できる。
• 静的解析による自動検証
  • IaCソースコードに対して自動解析ツールを実行することにより、セキュリティ等に関するインフラ設定の不備を自動的に検出できる。
  • これにより、人手では見落としやすい問題を自動検出するとともに、人によるレビューではアーキテクチャや実装ロジックの妥当性など、より高度な判断が必要な要素に注力できる。
• 環境間の差異の防止
  • 開発、検証、本番環境の設定を同一のコードベースで管理することで、環境間での意図しないインフラ設定の差異を防止できる。
  • 環境ごとに必要な差異（インスタンスサイズ、レプリカ数等）は、パラメータ化や条件分岐により明示的に管理される。
  • これにより、「検証環境では動作するが本番環境では動作しない」といった、意図しない環境差異に起因する問題を軽減できる。
  • 開発、検証、本番環境の設定を同一のコードベースで管理することで、環境間でインフラ設定が異なる問題を防止できる。
  • これにより、「検証環境では動作するが本番環境では動作しない」といった環境差異に起因する問題を排除できる。

運用の効率化

• バージョン管理による変更追跡
  • IaCソースコードをGit等のバージョン管理システムで管理することで、変更履歴を追跡できる。
  • これにより、いつ誰がどのような変更を行ったかを明確に記録し、問題発生時の復旧に必要となる過去のインフラ設定を容易に取得できる。
• オンデマンドな環境構築
  • 負荷テスト等の一時的な利用のため、IaCを利用して環境を作成し、利用が終わったら削除するなど、必要な時だけ環境を立ち上げることができる。
  • また災害対策として遠隔地のバックアップ環境を設ける場合に、バックアップ環境には通常リソースを配置せず、バックアップ環境に切り替える時にIaCを利用して環境を構築して切り替える運用も可能である。
  • これらにより、システムを起動し続けることによるセキュリティリスク、運用負荷、コストを低減できる。

知識の形式知化

• 設定内容とドキュメントの一体化
  • IaCソースコード自体が最新の設計書として機能する。
  • これにより、実環境とドキュメントの乖離が構造的に発生せず、常に正確な設定情報を参照できる。

IaC導入による開発プロセスと必要な要素の変化

IaCの導入は、単なるインフラ構築手法の変更ではなく、開発プロセス全体の変革を伴う。従来の手法からIaCへの移行により、必要な要素や体制も変化するため、これらを理解した上で計画的に導入することが重要である。

不要になる要素：

• パラメータシート（IaCソースコードが代替）
• 詳細な構築手順書（パイプラインが代替）
• 環境間の差分管理表（コードベースで管理）

新たに必要となる要素：

• IaCソースコード
• コーディング規約
• ブランチ戦略の定義（「別紙3-1：ブランチ戦略の検討」参照）
• CI/CDパイプライン構成（「別紙3-1：ブランチ戦略の検討」参照）
• コードレビュー記録（Git プルリクエストのレビュー履歴で対応）

必要な体制整備：

• 複数名によるコードレビュー体制（「3.3.4 IaCのコードレビューとチーム構成」参照）
• Gitリポジトリとパイプラインの管理体制
• IaCツールやGitに関する技術習得

IaC導入により、パラメータシートや手順書の作成・管理が不要になる一方、上記の新しい要素や体制整備が必要となる。トータルでは作業の効率化と品質向上が実現されるが、移行期には学習コストや体制構築のための投資が必要となることを理解しておくべきである。

3.3.2 パラメータシート運用からの脱却

インフラの設定値について、パラメータシートを使った管理・運用の代わりに、IaCを活用することが望ましい。

パラメータシート運用とは、ExcelやWordファイルにインフラの設定値を記載し、これを基に手動作業でインフラ設定を実施する方法である。この方法では、インフラ設定を実施する担当者が正確に作業を行う必要があり、また、パラメータシートと実際の設定値が乖離しないよう継続的に管理する必要がある。

パラメータシートではなく、IaCでインフラの設定値を管理することにより、以下のメリットが得られる。

• 設定の自動実行による人的ミスの排除
  • IaCソースコードを実行するだけでインフラの設定が完了するため、手作業による入力ミスが発生しない。
  • 同じIaCソースコードからは常に同一の結果が得られる(冪等性の確保)。
• 実環境とドキュメント内容の一致
  • IaCソースコード自体が最新の設計書として機能する。
  • パラメータシート運用で発生しがちな実環境とドキュメントの乖離が構造的に発生しない。
• 環境構築の迅速化と効率化
  • パラメータシートによる手作業では、構築に時間がかかり人的リソースも必要となる。
  • IaCでは数分〜数十分で環境を自動構築できる。
  • 作業時間のばらつきを排除し、構築時間を予測可能にする。
• バージョン管理システムとの統合
  • Git等を用いることで、変更差分、変更者、変更理由を自動的に記録できる。
  • ブランチ機能により並行開発や実験的な変更が容易になる。
  • 過去の任意のバージョンへのロールバックが可能。

IaCによる設定値管理

IaCで設定値を管理する場合、設定値の性質に応じて適切な管理方法を選択することが必要である。表3-1に、IaCの場合の設定値の管理方法の例を示す。

表 3-1 IaCの場合の設定値の管理方法の例

ソースコード内記述における明示性の判断

IaCツール、特にAWS CDKのようなプログラマブルなツールでは、コードの抽象度により設定の明示性が変わる。高レベルの抽象化(例のL2/L3コンストラクト)を使用する場合、多くの設定がプラットフォームの合理的なデフォルト値として暗黙的に適用される。この時に暗黙的に適用される設定は管理すべきか否かと言う論点がある。

結論としては、プラットフォームが提供するデフォルト値はベストプラクティスに基づいて設計されているため、パラメータシートで管理していた全ての設定項目をIaCコード内で明示的に記述する必要はない。明示的に管理すべきは、システムの機能・非機能要件に直結する設定、セキュリティ要件、コンプライアンス要件、組織ポリシー、またはやコストに大きく影響する設定に留め、それ以外はプラットフォームに委ねることが望ましい。

IaC利用においても文書化が必要な設計情報

一方で、IaCソースコードでは技術的な構成は表現できるが、設定値を選択した設計根拠や背景、制約事項は表現が困難である。また、他システムとの連携仕様や依存関係、運用上の注意事項なども同様である。また、ネットワークのIPアドレス範囲のように、組織全体で採番して管理する必要がある設定値については、IaCソースコード内でのみ管理することは難しい場合がある。

これらの設計情報は、情報の性質と粒度に応じて階層的に管理する。表3-2に、IaCの場合の設計情報の管理の例を示す。

表 3-2 IaCの場合の設計情報の管理の例

3.3.3 IaCで管理する対象範囲の選定

利用システムが使用する全リソースをIaCで管理することが原則として望ましい。部分的なIaC導入では手動作業を完全に排除できず、人的ミスのリスクが残存する。リソースの変更頻度が低い場合でも、IaCで管理せず手動作業を許容すると、自動化と手動作業が混在し、運用の複雑性が増大する。一貫したIaC管理により、運用プロセスの標準化と品質向上を実現できる。

ただし、技術的制約により例外的な対応が必要な場合もある。例えば、IaCツールはCSPの全サービスに対応しているとは限らない。また、SaaSサービスなど、利用CSPと異なるサービスとの連携設定や、複数サービスを跨ぐ設定は、IaCツールでは不向きな場合がある。このようなケースで無理にIaCでの管理を試みると、実装者以外が理解できず属人化し、結果として技術負債となるリスクがある。このようなケースは例外として、CSPが提供するコマンドライン操作ツール（CLI）を利用したスクリプトによるコード化を実施する。スクリプト化が困難な場合は、事前に手順書を用意し手動作業を行うことも検討する。

なお、手動作業を行う場合は、画面操作（GUI）よりもコマンド操作（CLI/CUI）が望ましい。画面操作は、サービス提供者による画面変更により手順書通りに操作できなくなるリスクがあり、また複数の画面遷移やボタンクリックなど多様な操作が介在するため人的ミスが発生しやすい。たとえば画面遷移のボタンのように誤認し、クリックしたことで機能を有効化するような誤操作が考えられる。一方、コマンド操作であれば、手順書に記載されたコマンド文をコピー&ペーストすることで入力ミスを軽減できる。

たとえば画面遷移のボタンのように誤認し、クリックしたことで機能を有効化するような誤操作が考えられる。

図 3-4 リソース管理方式のディシジョンツリー

リソースの管理における注意事項

• ステートフルなリソースの適切な管理
  • ステートフルなリソース（データベース、ストレージ等）をIaCで管理する場合は、リソースの削除防止の設定を検討することが望ましい。IaCによるリソース管理では、IaCソースコードの変更がどのリソースの削除につながるかが直感的に分かりにくい場合があり、削除操作を見逃すリスクがある。IaCツールには環境削除時にリソースを保持する設定が用意されており、削除されると業務に影響が生じる可能性があるデータを保持するリソースについては、保持設定を適用することでリスクを回避できる。
• 定期的な運用作業が必要なリソースの適切な管理
  • データベースエンジンのバージョンアップなど定期的な運用作業が必要なリソースについては、IaCソースコードとの整合性を保つための対応が重要である。さらに、データベースに対してマネージドサービスの自動パッチ適用機能が実施されると、IaCソースコードで定義されたバージョンと実際のリソースの状態に差異が生じる。この差異を放置すると、次回のIaCソースコードのデプロイ時に意図しないリソースの再作成や設定変更が発生し、サービス停止やデータ損失のリスクが生じる可能性がある。このようなリスクを回避するため、以下の手順で対応することが重要である。
    1. IaCツールのドキュメントで設定変更時の影響（リソースの再作成が発生するか、リソースの一時的な利用不可が発生か、等）を確認する。
    2. 検証環境でIaCソースコードのデプロイのテストを実施し、データ損失等を伴う変更がないことを確認する。
    3. 検証環境での確認完了後、本番環境への適用を行う。

3.3.4 IaCのコードレビューとチーム構成

IaCの導入により、インフラ設定を「実装→コードレビュー→適用」というソフトウェア開発と同様のプロセスで管理できるようになる。これにより、アプリケーション開発で実施されているコードレビュー等の品質向上の取り組みを、インフラ構築においても実施できるようになる。

この品質向上の取り組みを実現するには、複数人から構成されるチーム体制とレビュープロセスの整備が必要である。本節では、効果的なコードレビュー体制を構築するための要点を説明する。

手動構築とIaC管理によるレビューアプローチの違い

従来の手動によるインフラ設定作業においても、設計書のレビューやパラメータシートの確認、作業後の環境精査といった品質管理プロセスは存在し、安定したサービス提供を支えてきた。しかし、設計書やパラメータシートのレビューと実際の構築作業の間には、手動作業による設計と実装の乖離という課題があった。設計書で正しい設定が記載されていても、手動作業での転記ミスや入力ミス、環境の取り違えなど、人的ミスにより意図しない設定が適用される可能性がある。

IaCではインフラ設定をソースコードとして記述するため、設定内容を適用する前に静的解析やコードレビューで技術的な妥当性を直接チェックできる。従来の設計書レビューが「設計の意図」を確認するものであったのに対し、IaCのコードレビューでは「実際に適用される設定そのもの」を確認できる。これにより、設計から実装への転記プロセスで発生する人的ミスを根本的に排除できる。また、IaCソースコードは常に実環境と同期しているため、ドキュメントと実態の乖離も原理的に発生しない。

チーム体制の構築

コードレビューを実施するためには、実装者とレビュアーの役割を考慮した複数人から構成されるチーム体制が必要である。最小構成としては、IaCコードを記述し実装内容を説明する責任を持つ実装者と、実装内容を確認し問題点を指摘する責任を持つレビュアーの2つの役割が必要となる。

チーム構成を検討する際には、一人のレビュアーのみに依存すると、その担当者の不在時にレビューが滞るため、少なくとも2名以上のレビュアーを確保し相互にレビューできる体制を整えることが望ましい。また、特定の担当者にのみIaCのスキルが集中すると属人化のリスクが高まるため、ペアプログラミングやモブプログラミングの実施、定期的なナレッジシェアリングセッション、コードレビューを通じた相互学習などにより、チーム全体のスキル向上を図ることが重要である。

コードレビューの実施

IaCソースコードに対するレビューは、ツールによる自動レビューと人によるレビューの2つで構成される。またGitリポジトリを活用することで、ツールによる自動レビューと人によるレビューを統合的に進めることも可能である。

• (1) ツールによる自動レビュー
  • ツールによる自動レビューでは、静的解析ツールを活用してセキュリティリスク（ストレージのパブリック公開、過度に緩いファイアウォールルール等）、ベストプラクティスからの逸脱（命名規則違反、非推奨リソースの使用等）、設定の整合性（リソース間の依存関係の矛盾、必須パラメータの欠落等）を自動的に検出する。これらを人手で網羅的にチェックすることは難しいが、ツールによる自動化により一貫した品質基準を維持できる。
• (2) 人によるレビュー
  • 人によるレビューでは、自動チェックでは判断できない観点を確認する。IaCが従来の設計書と同様に「要件を満たすシステムをどのように構築するか」を記述したものであることから、確認すべき内容も本質的には同じである。具体的には、要件との整合性、システム全体の設計方針との矛盾がないか、将来の変更や保守の容易性、コストへの影響といった観点でレビューを行う。
• (3) Gitリポジトリでのレビュープロセス統合
  • これらのレビューは、Gitリポジトリの機能を活用して統合的に実施することが望ましい。具体的には、Gitリポジトリのプルリクエスト作成時にパイプラインを実行するようにし、そのパイプラインの中で静的解析ツールを自動実行し静的解析ツールで問題が生じない場合のみプルリクエストのマージを許可する運用にする。さらにレビュアーは、静的解析の結果を確認した上で、人による判断が必要な観点に集中してレビューでを行う。静的解析で検出された問題と人によるレビューで指摘された問題の両方が対応済みになってからソースコードをマージするプロセスにより、反映漏れを防ぐことができる。

コーディング規約の策定

IaCソースコードの品質向上のために、アプリケーション開発と同様のコーディング規約を策定することが望ましい。コーディング規約として、変数や関数の命名方法、コメントの書き方、ファイルの構成などのルールを定めておくことで、IaCソースコードの可読性が向上し、コードレビュー時の問題の摘出を容易にする。策定したコーディング規約については、静的解析ツールやリンターで機械的にチェック可能な項目は自動化し、目視確認が必要な項目はチェックリスト化することで実効性を確保する。また、運用の中で見つかった課題に応じて規約を定期的に見直すことも重要である。

3.3.5 IaCの活用レベルとデプロイ方式

IaCの活用とデプロイ方式は、成熟度に応じた段階的な導入も考えられる。本節では、それぞれのレベルの特徴と、目指すべき方向性を説明する。

図 3-5 IaC活用レベルとデプロイ方式の概要

レベル1：初期構築のみIaCを活用（選択すべきでない）

初期構築時のみIaCで環境を構築し、その後の構成変更は手動で実施する方式である。

この方式は選択すべきでない。 初期構築後に発生する構成変更を手動で実施すると、その変更内容がIaCソースコードに反映されないため、ドキュメント（IaCソースコード）と実環境が乖離する。一度乖離が発生すると、IaCソースコードは実環境の状態を正確に表さなくなり、設計書としての価値が失われる。また、手動変更では人的ミスのリスクが残存し、IaC導入の主要な目的である品質向上の効果が得られない。

IaCを導入する場合は、レベル2以上を選択しなければならない。 新規にシステムを構築する場合は、当初からレベル３を目指すことが望ましい。

レベル2：継続的にIaCを活用、手動デプロイ

初期構築およびその後の全ての構成変更をIaCで管理し、デプロイは手動で実施する方式である。

この方式では、全ての構成変更がIaCソースコードとして記述されるため、ドキュメントと実環境の同期が保たれる。IaCソースコードを参照すれば、常に最新の環境構成を把握できる。また、3.3.6節で説明したコードレビューを通じて、構成変更の妥当性を事前に確認できる。

ただし、デプロイを手動で実施するため、次の課題が残る。一つ目の課題は、デプロイ時の手動作業により、実行コマンドの入力ミスやデプロイ対象環境の取り違えなど、人的ミスが発生する可能性がある。二つ目の課題として、デプロイを実施する担当者には環境への変更権限が必要となり、誤操作や不正操作のセキュリティリスクが存在する。

レベル2は、IaCを段階的に導入する際の現実的なステップとして有効である。しかし、最終的にはレベル3を目指すべきである。

レベル3：CI/CDパイプラインによる自動デプロイ（推奨）

IaCソースコードのデプロイをCI/CDパイプラインで完全自動化する方式である。本ガイドが推奨する方式であり、Zero Touch Productionの実現につながる。

この方式では、デプロイに関わる全ての手順（ソースコード取得、静的解析、差分確認、デプロイ実行等）がパイプラインにより自動実行される。これにより、次に示す３つの利点が得られる。一つ目に、デプロイ時の人的ミスが根本的に排除され、常に同じ品質でデプロイが実行される。二つ目に、デプロイを実施する担当者に環境への変更権限を付与する必要がなくなり、セキュリティリスクが大幅に低減される。三つ目に、全てのデプロイがパイプラインを経由するため、いつ誰がどのような変更を行ったかの記録が自動的に残り、監査性が向上する。

新規にシステムを構築する場合は、当初からレベル3を目指すことが望ましい。既存システムにおいても、レベル2からレベル3への段階的移行が可能であり、その具体的な方法は3.3.12節で説明する。

本章では、以降の節でレベル3の実現に必要な要素（パイプラインの構築、パイプラインのツール選定、ブランチ戦略等）を解説する。

3.3.6 IaCツールとCI/CDパイプライン実装の検討ポイント

ここまでの考え方や方式選定を踏まえた、IaCツールとCI/CDパイプラインの実装における検討ポイントを「別紙3-1 IaCツールとCI/CDパイプライン実装の検討ポイント」にまとめている。

IaCツールとCI/CDパイプライン実装時の参考としていただきたい。

3.4 アプリケーションのデプロイ戦略の選択

3.4.1 デプロイパターンの種類と選択指針

システム更新時のデプロイ戦略は、ダウンタイムと実装の難易度のバランスを考慮して適切に選択する必要がある。

以下では代表的なデプロイ戦略における、デプロイの流れ、メリット、デメリットを紹介する。図では、V1が現バージョン、V2が新バージョンを表し、現バージョンが新バージョンに置き換わるまでの流れを表している。また、トラフィックの振り分けの一例として、ロードバランサーを使用している。

① In-Placeデプロイメント

図 3-6 In-Placeデプロイメントの流れ

• 既存環境を直接更新する最もシンプルな方式
• デプロイの流れ
  • 1. V1を停止
  • 2. 同じ環境にV2をデプロイ
  • 3. V2でサービス再開
• メリット
  • 実装と運用がシンプル
    • 追加のインフラ構成が不要で、既存環境のみを更新
    • 複雑なトラフィック制御やルーティング設定が不要
  • コスト効率が良い
    • 追加のインフラリソースが不要
    • 環境の二重管理が発生しない
  • デプロイ速度が速い
    • 単一環境での直接更新のため処理が少ない
    • 同期や切り替えの待機時間が不要
• デメリット
  • サービス停止が避けられない
    • 既存環境を直接更新し、並行運用できる環境がないため、更新中はサービスが停止
  • ロールバックが困難
    • 元の状態に戻すには以前のバージョンの再度デプロイまたはバックアップからのリストアが必要
    • 単一環境での直接更新のため、以前のバージョンが残っていないと、問題発生時の復旧に時間がかかる
  • リスクが高い
    • 全てのサーバーに対して同時にデプロイを行うため、新バージョンにバグやパフォーマンス問題が存在した場合、それを限定的な環境に抑えることができず、全サーバーが影響を受けてしまう

② ローリングデプロイメント

図 3-7 ローリングデプロイメントの流れ

• 実行中のインスタンスを段階的に更新していく方式
• デプロイの流れ
  • 1. V1の1台目を停止してV2をデプロイ、残り2台はV1で継続稼働
  • 2. V1の2台目を停止してV2をデプロイ、V2が2台、V1が1台で稼働
  • 3. V1の3台目を停止してV2をデプロイ、全台でV2稼働
• メリット
  • 完全停止を回避可能
    • 常に一定数のインスタンスがサービスを提供
    • 段階的な更新による安全性確保
  • 制御の柔軟性
    • 更新するインスタンス数を調整可能
    • サービス影響を考慮した展開速度の調整
• デメリット
  • キャパシティ低下
    • 更新中のインスタンスはサービスを提供できないため、全体の処理能力が一時的に減少
  • 実装と運用の複雑性
    • 更新中は新旧バージョンが同時稼働するため、アプリケーションの互換性確保が必要。
    • 新旧バージョンの環境分離がないため、どのインスタンスがどのバージョンかを常に把握しておき、エラー発生時やロールバック実行時に該当インスタンスを特定する必要がある。
  • デプロイ時間
    • 段階的な更新のため完了までに時間がかかる
    • 各段階での健全性確認が必要

③ Blue/Greenデプロイメント

図 3-8 Blue/Greenデプロイメントの流れ

• 新旧環境を並行して用意し、切り替えを行う方式
• デプロイの流れ
  • 1. Green環境にV2をデプロイ
  • 2. ロードバランサーやDNSでトラフィックをBlue環境からGreen環境に切り替え
  • 3. Blue環境のV1を停止
• メリット
  • 最小限のダウンタイム
    • 完全な新環境構築後の切り替えが容易
    • DNS切り替えやロードバランサーの設定変更のみ必要
  • 容易なロールバック
    • 旧環境が維持されているため即時切り戻し可能
    • 全トラフィックを新環境に向けるため、ロードバランサーやDNSレベルでの切り替えポイントが明確
• デメリット
  • 実装と運用の複雑性
    • 旧環境、新環境それぞれでサーバー環境の構築が必要となり、かつ一時的にこれらの複数環境を同時に維持する必要がある。
    • 振り分け先となるグループを旧環境、新環境に用意し、環境間のトラフィックを切り替えるルーティング制御の仕組みを実装する必要がある。
    • 切り戻しを考慮した上で、切り替えや旧環境を停止するタイミングの見極めが必要。
  • データ同期の複雑さ
    • データベースのテーブル構造やカラム定義の変更に伴い、新環境にもデータベースを用意する場合、旧環境から新環境へデータを引き継ぐ必要があり、データ移行や同期が必要
  • インフラ追加コストの発生
    • 一時的に既存環境と新環境を並行稼働させるため、その分インフラで追加コストが生じる。

④ カナリアデプロイメント

図 3-9 カナリアデプロイメントの流れ

• 一部のユーザーのみに新環境を提供し、段階的に展開する方式
• デプロイの流れ
  • 1. V2を少数デプロイし、トラフィックの10%をロードバランサーの重み付けルーティングを使用し、V2に振り分け
  • 2. 問題なければV2への割合を20%→50%→80%と段階的に増加
  • 3. 最終的に100%のトラフィックをV2で処理し、V1を停止
  • ※上記で記載しているトラフィックの割合は一例である
• メリット
  • 最小限のダウンタイム
    • 既存環境を維持したまま新環境へ段階的に移行するため、サービス停止なしでのデプロイが可能
  • 段階的な展開による安全性
    • 影響範囲を制御可能
    • 実環境での検証が可能
  • フィードバックの早期取得
    • 本番トラフィックでの検証
    • ユーザー反応の測定が可能
• デメリット
  • インフラ追加コストの発生
    • 既存環境を維持した上での新環境の追加構築
    • トラフィック振り分けの仕組みなどトラフィック制御のための追加設定が必要
  • 実装と運用の複雑性
    • トラフィック制御ロジックが必要
    • ユーザー振り分けの仕組みが必要
    • 複数バージョンの長期並行運用
  • 高度な監視要件
    • バージョン別の詳細な監視が必要
    • 複数バージョンが同時稼働するため、問題の特定が困難
    • メトリクスの収集と分析が複雑

デプロイ戦略の選択

各デプロイ戦略の選択は、以下の選択基準を考慮して判断する。

表 3-3 デプロイ戦略ごとの選択基準

利用システムは、上記の特徴と選択基準を参考にして、要件に最適なデプロイ戦略を選択すること。なお、システムの進化に応じて、より高度なデプロイ戦略への移行を検討することも推奨される。

3.4.2 デプロイのロールバック手法

問題発生時に迅速なロールバックを実施するため、事前定義した監視条件に基づくロールバックプロセスの自動化を検討する。ロールバックプロセスには、ロールバックの必要性を検知するための監視、ロールバックを実施するかの判断、そしてロールバックの実行という3つの要素が含まれる。

3つの要素のうち、自動化を優先して検討すべきは監視と実行の2つとなる。ロールバックを実施するかどうかについては、状況の重大性や影響範囲を考慮した上で、担当者の確認を追加で必要とすることが望ましい。これは意図しないロールバックが自動的に実行されることを防ぐ目的である。なお、ロールバックを最小限に抑えるためにも、テスト環境において十分な検証を実施することが重要である。

監視では、アプリケーションの応答時間の悪化やAPIのエラーレート上昇など、ユーザーに影響が出やすいメトリクスを収集する。これらを監視条件として設定することで、意図しない状況の発生を検知する。これらのメトリクスを用いて、ロールバック実施の具体的な閾値や判断基準を事前に定義する。

次に、ロールバックの実装方式としては、以下のパターンが考えられる。

表 3-4 ロールバックの実装方式

また、ロールバックの実行については、デプロイ戦略ごとに適用可能な方法が異なるため、デプロイ戦略の選択の際には、ロールバックをどのように実行するかも含めた判断が必要である。システム更新後は、新環境の安定稼働が確認されるまでの期間、旧環境の維持やソースコードなど関連する成果物（コンテナイメージ、設定ファイル等）を適切に保管・管理しておく必要がある。これにより、問題発生時の迅速なロールバック対応が可能となる。

以下にデプロイ戦略ごとのロールバック方法を例示する。

• ①In-Placeデプロイメント
  • 既存環境で直接アプリケーションを更新するため、ロールバックは前バージョンを再デプロイすることで実現する。デプロイ時と同様、ダウンタイムが発生する。
• ②ローリングデプロイメント
  • 複数のインスタンスを順次更新するため、ロールバックは更新済みインスタンスを前バージョンに順次戻すことで実現する。
• ③Blue/Greenデプロイメント
  • 旧環境（Blue）と同一構成の新環境（Green）を用意し、トラフィックを切り替えるため、ロールバックはトラフィックルーティングを旧環境に戻すことで瞬時に実現する。DNS切り替えやロードバランサー設定変更により、数秒から数分でロールバックが完了する。
• ④カナリアデプロイメント
  • 新バージョンへのトラフィック割合を段階的に増加させるため、ロールバックは新バージョンへのトラフィック割合を0%に戻すことで実現する。問題検知時点でのトラフィック割合に応じて影響範囲が限定されるため、リスクを軽減できる。

3.5 定型的な作業の自動化

3.5.1 反復的な手動作業を削減することの重要性

運用を自動化するにあたり、反復的な手動作業の削減は、人的ミスの削減とセキュリティリスク削減に直結する重要な取り組みである。一度の自動化によりこれら手動作業を継続的に代替できることから費用対効果が高く、また一定品質での実行を確保できる利点がある。

具体的に、一定期間内で定期的かつ頻繁に実施される作業については、自動化検討の対象とする。自動化の開発に必要な投資工数と、手動作業を継続した場合の累積運用工数を比較し、投資対効果が見込める作業を特定し、自動化に取り組む。特に、作業頻度が高く人的ミスのリスクが大きい定型作業については、最優先で自動化に取り組むものとする。

自動化範囲の拡大を継続的に取り組んでいくにあたり、自動化のプログラムや仕組みを改善したり他チームに展開利用したりすることが重要である。そのため、作成したソースコード（IaC含む）には、処理の概要と目的、システム構成図、実行手順と前提条件、設定値の説明、トラブルシューティング情報、保守・更新履歴を含むREADMEを作成すること。このような体系的なドキュメント整備により、異なる運用事業者に変わっても、自動化の引き継ぎが容易となり、さらなる改善や機能拡張を円滑に進めることが可能となる。

3.5.2 自動化可能な運用業務の特定

手動作業の記録と分析を通じて、システム運用の自動化の範囲を継続的に拡大させることが重要である。なぜなら、自動化による運用の標準化と効率化は、サービス品質の向上につながるためである。

これを実現するためには、まず現状の手動作業の実態を定量的に把握し、自動化による改善効果を評価する必要がある。同時に、手動作業に起因する人的ミスの分析と、自動化によって新たに発生する可能性のあるエラーへの対策も検討する。このように、運用効率と品質の両面から継続的な改善を進めることで、より効果的なシステム運用の実現が可能となる。

そのため、本番環境および検証環境において手動作業が発生した場合、以下の項目について詳細な記録を行うことが望ましい。

• 作業実施日時
• 作業内容
• 手動作業が必要となった理由
• 今後作業を自動化できるかどうか

記録管理を行う理由として、本番環境および検証環境の両方でZero Touch Productionを前提としているため、例外的に発生する手動作業を特定し、それらを自動化することでさらなる効率化を実現できることが挙げられる。また作業を自動化する際は、人的ミスによる影響度や自動化に必要な工数を考慮した上で、優先順位を付けて進めることを検討する。このように、手動作業の記録と分析を通じて、システム運用の自動化の範囲を継続的に拡大させることが重要である。なお、本番環境でのZero Touch Productionの仕組みは事前に検証環境でのテストを必須とすることから、検証環境の作業においても同様のアプローチを適用することが求められる。

3.6 障害対応の自動化とリモート化

3.6.1 従来の障害対応の課題と段階的な対応アプローチ

従来の障害対応の課題

従来の運用体制では、障害が発生すると運用保守担当者が通報を受け取り、運用拠点に駆けつけて障害対応を実施する。求められるサービスレベルが高い場合は、24時間365日のシステム監視体制が敷かれるが、監視/運用オペレーター要員が実施できるのは限られた定型作業であることが多く、多くの場合で運用保守担当者（または開発担当者）にエスカレーションを行い、エスカレーションを受けた担当者の拠点で障害対応を実施している。この従来型の障害対応の課題としては以下のものが挙げられる。

対応速度の問題

障害が発生すると運用保守担当者に向けて通報がされるが、勤務時間以外では電話やメール、Slack等コミュニケーションツールに即座に反応できないケースや、駆けつけに時間を要するケースが存在する。

夜間や休日は対応できる人員が限られ、その人員においてもシステムの構成要素全てに精通している訳ではないため、即座に障害に対応することが困難なケースが存在する。

人的ミスの問題

通常の監視・運用オペレーターができる作業は、手順書が用意されている決まった作業だけである。それ以外のイレギュラーな作業は、運用保守の担当者が対応する。

障害が起きたときの緊急対応はイレギュラーな作業なので、参考になる手順があっても、そのまま使えない。状況に合わせて内容を変更したり、新しく手順を作る必要がある。このような緊急時には、手順を十分にテストする時間がなく、現場で対応できる運用保守担当者がチェックするだけで作業を進めることになる。そのため、そのシステム特有の注意点をすべて確認しきれない場合がある。

また、重大な障害の場合は、緊急事態のプレッシャーに加えて、深夜や休日の対応、長時間の作業による疲れなどが重なり、普段なら起こらないようなミスが発生することがある。

コストの問題

24時間365日のシステム監視体制が敷かれるケースでは、要員は複数人を交代制で配置するため、要員数も多く費用としても高額となる。また非定型作業を行う運用保守担当者は高スキル者である必要があり、通報がある時間帯は待機し駆けつけが発生した場合には対応作業実施するための体制確保費用が発生する。

事象の非インシデント化アプローチの概要

これらの課題を解決するため、本ガイドでは、段階的な対応アプローチ を提案する。このアプローチは、システムの信頼性設計およびリリース後の本番運用の全体を俯瞰し、2.1.1で定義した「事象」「インシデント」「非インシデント」の概念に基づき、事象をできる限り信頼性設計段階で組み込み「非インシデント」として吸収し、それでも対応が必要な「インシデント」には迅速に対処する仕組みを3つの層で構成するものである。

図 3-10 段階的な対応アプローチの概要

第1層：予防的設計による事象の回避（非インシデント化）
設計段階で冗長化やスケーラビリティを組み込むことで、障害や異常の発生そのものを未然に防ぐ。この層は、システムアーキテクチャとして実装される。

第2層：自動検知と自動復旧（非インシデント化）
第1層で防ぎきれなかった事象に対して、自動的に検知し復旧する。オートスケールや自動再起動などにより、人的介入なしで事象を非インシデント化する。

第3層：人的介入が必要な対応（インシデント対応）
第1層・第2層で対応できなかった事象に対して、職員と事業者が協働して対応する。2章で説明したインシデント対応プロセスを実行する。

このアプローチは、2.1.1で定義した「事象」「インシデント」「非インシデント」の概念と対応している。第1層と第2層は事象を「非インシデント」として吸収し、第3層は「インシデント」への対応を担う。

3.6.2 信頼性設計と自動復旧の考え方（第1層・第2層）

サービスの信頼性やユーザー体験を主眼に、ユーザーのリクエストに適切にレスポンスを返すことが重要である。これを実現するためには、設計段階で信頼性を高めるよう作り込み、テスト段階で動作を検証し、運用段階で継続的に改善するという一貫したアプローチが必要となる。

本節では、信頼性設計として、第1層（予防的設計）と第2層（自動復旧）について、各段階で考慮すべき観点を示す。

ライフサイクル全体を通じた取り組み

信頼性の高いシステムを実現するためには、以下の視点を設計・テスト・運用の全段階で持ち続けることが重要である。

• ユーザー影響の最小化: 障害が発生しても、ユーザーへの影響を最小限に抑える
• 人的介入の削減: 自動的に対応できる範囲を広げ、人的ミスのリスクを減らす
• 継続的な改善: 運用実績を分析し、設計やパラメータを継続的に改善する

各段階では以下の取り組みを通じてシステムの信頼性の作り込みを行う。

• 設計段階：冗長化、自動復旧、データ保護などの仕組みを作り込む
• テスト段階：負荷テストや障害テストで設計の妥当性を検証
• 運用段階：実運用データに基づいて評価・改善し、設計にフィードバック

信頼性設計: 予防的設計の評価観点（第1層）

(1) 冗長化とスケーラビリティ

システムの可用性を確保するためには、SPOF（Single Point of Failure、単一障害点）を排除し、適切な冗長化設計を行うことが基本となる。冗長化設計では、各コンポーネントについて利用するサービスや機能が対応している場合は、異なる耐障害性ゾーン（AWSとAzureではAvailability Zone、Oracle Cloud InfrastructureではAvailability Domain/Fault Domain、Google CloudとさくらクラウドではZone、と呼ぶ）またはリージョンに分散配置されているかを確認する。これにより、特定のデータセンターや物理的な場所での障害がシステム全体に波及することを防ぐことができる。
また、負荷増加に対する対応方針を明確にしておくことも重要である。オートスケールを導入する場合には、スケールアウトとスケールインの閾値が適切に設定されているか、スケールアウトの上限が適切かを確認する。

(2) データ保護

サービスの信頼性を支える重要な要素として、データの保護がある。CSPが提供するマネージドサービスを活用した自動バックアップ体制の構築が不可欠である。従来のオンプレミス環境ではバックアップソフトウェアやジョブで実現していたが、クラウドではマネージドサービスを活用することで、暗号化やレプリケーション、ストレージの耐久性などのメリットを活かして容易に実現でき、費用や作業工数の削減が可能となる。

データ保護の設計では、自動バックアップが適切に設定されているか、　遠隔地保管の要件がある場合や遠隔地への自動レプリケーション構成やバックアップを遠隔地に保管する運用が実施されているか、RPO（Recovery Point Objective、目標復旧時点）とRTO（Recovery Time Objective、目標復旧時間）の要件を達成可能な設計となっているかを確認する。また、バックアップからの復旧手順を定期的にテストすることで、実際の障害時に確実に復旧できることを検証する。

なお、CSPが公表している耐久性のSLAは、満たされなくても返金処理されるだけであり、消失したデータが復旧する訳ではない。この点を踏まえ、重要なデータについては複数のバックアップ世代の保持、遠隔地へのレプリケーション、場合によっては複数のストレージサービスへの分散保管などを検討する必要がある。

(3) 障害影響の局所化

1つのコンポーネントの障害がシステム全体に波及することを防ぐため、障害影響を局所化する設計が重要である。サーキットブレーカーパターンを実装することで、障害が発生したコンポーネントへのリクエストを一時的に遮断し、障害の連鎖を防ぐことができる。また、サービス間を非同期通信で疎結合にすることで、一方のサービスの障害が他方に即座に影響することを回避できる。

タイムアウト設定も重要な要素である。適切なタイムアウト値を設定することで、応答の遅延が発生した際に無期限に待機することなく、早期にエラーを検知して別の処理経路に切り替えることができる。ただし、タイムアウト値が短すぎると正常な処理でもタイムアウトが発生してしまうため、システムの特性や要件に応じて適切な値を設定する必要がある。

これらの設計により、カスケード障害と呼ばれる連鎖的な障害の拡大を防止し、部分的な障害が発生してもシステム全体としてはサービスを継続できる状態を維持する。障害影響の局所化設計の有効性は、「3.6.4 システムの信頼性検証」で説明するカスケード障害テストを通じて検証することが望ましい。

信頼性設計: 自動復旧の実装パターン（第2層）

第2層では、第1層で防ぎきれなかった事象に対して、人的介入なしに自動的に検知し復旧する仕組みを実装する。負荷急増やアプリケーション異常、データベース障害などに自動的に対応することで、ユーザーへの影響を最小限に抑え、サービス提供品質の向上につながる。本節では、代表的な自動復旧のパターンとその実装時の考慮点を説明する。

(1) 負荷急増への対応：オートスケール

予期せぬ負荷急増に対しては、オートスケールによる自動的なリソース追加が有効である。CSPが提供する仕組みを活用してダイナミックにリソースを追加することで、負荷急増によるレスポンス低下や接続エラーを自動的に解消できる。オートスケールでは、CPU使用率やメモリ使用率、リクエスト数などのメトリクスを監視し、設定した閾値を超えた場合に自動的にサーバーインスタンスを追加する。負荷が低下した際には、逆にインスタンスを削減することで、コストの最適化も実現できる。

ただし、オートスケールの実装にあたってはいくつかの考慮点がある。DoS攻撃などにより異常なリクエスト増加が発生した場合、過剰にリソースがプロビジョニングされ、想定外のコストが発生する可能性がある。これを防ぐため、オートスケールには上限値を設定するか、コスト監視とアラート機能を組み合わせて異常なコスト増加を早期に検知する仕組みを整える必要がある。

また、すべてのシステムでオートスケールが必要という訳ではない。負荷の変動が少ないシステムや稼働期間が短いシステム、トラフィックパターンが予測可能なシステムでは、適切にサイジングされた固定的なリソース構成の方が運用がシンプルになる場合もある。システムの特性や要件に応じて、オートスケール導入の要否を判断することが重要である。

(2) アプリケーション異常への対応：ヘルスチェック連動の自動再起動

アプリケーションのハング状態やメモリ不足による応答停止に対しては、ヘルスチェック連動の自動再起動が有効である。ロードバランサーやコンテナオーケストレーションツールが提供するヘルスチェック機能を活用し、アプリケーションが正常に応答しない状態を検知した際に、自動的に再起動することで人的介入なしに復旧できる。

この仕組みを効果的に機能させるためには、アプリケーション側での考慮が必要となる。アプリケーションは再起動による影響を最小化するよう、開発段階から以下の特性を持つように設計する必要がある。まず、永続化すべきデータはアプリケーションプロセス内に保持せず、キャッシュサービスやデータベースに保存する。次に、処理の再実行を行なっても冪等性が保たれるよう実装する。これにより、再起動が発生しても、処理中のデータが失われることなく、また重複処理による問題も発生しない。

ヘルスチェックの設定も重要な要素である。ヘルスチェックの間隔が長すぎると異常の検知が遅れ、短すぎると一時的な負荷増加を異常と誤検知してしまう。また、連続して何回失敗した場合に異常と判断するかの閾値設定も、システムの特性に応じて調整する必要がある。これらの設定値は、3.6.4節で説明する障害テストを通じて検証し、最適な値を見つけることが望ましい。

(3) データベース障害への対応：自動フェイルオーバー

データベース障害に対しては、自動フェイルオーバーによる迅速な復旧が重要である。CSPが提供するマネージドデータベースサービスは、スタンバイノードやリードレプリカを活用した自動フェイルオーバー機能を備えており、プライマリデータベースの障害を検知した際に人的介入なしで自動的にスタンバイノードに切り替える。

自動フェイルオーバーの構成では、同期レプリケーションと非同期レプリケーションの選択が重要となる。同期レプリケーションはデータの整合性を完全に保証できるが、レプリケーションのオーバーヘッドにより書き込み性能に影響が出る。非同期レプリケーションは性能への影響が少ないが、フェイルオーバー時に直近の更新データが失われる可能性がある。システムのRPO要件と性能要件のバランスを考慮して、適切なレプリケーション方式を選択する必要がある。

また、フェイルオーバー後の動作も考慮すべき点である。フェイルオーバーにより新しいプライマリとなったノードは、元のプライマリと同等の性能を持つ必要がある。スタンバイノードのスペックが不足している場合、フェイルオーバー後に性能劣化が発生し、結果としてユーザーに影響を与える可能性がある。さらに、フェイルオーバー後の元のプライマリノードの扱いや、フェイルバックの方針についても事前に決定しておくことが望ましい。

さらにデータベースにアクセスを行うアプリケーションもDB接続の自動復旧やDBクエリーの自動再実行の実装を行う必要がある。これらアプリケーションの自動再実行まで揃えて初めてデータベース障害に対する人的介入なしの自動復旧が実現する

自動対応の監視と定期分析

自動復旧の仕組みを導入した後も、その動作状況を継続的に監視し分析することが重要である。自動化された対応は人的介入なしで実行されるため、問題が発生していても気づきにくいという特性がある。そのため、自動対応が適切に機能しているか、また過度に実行されていないかを定期的に確認する必要がある。

ただし、運用リソースの制約がある場合は、インシデント発生時の振り返り（2.4節）の中で自動対応の動作状況も併せて確認する形でも対応可能である。

連続実行の検知と通報

自動復旧処理が繰り返し実行される状況は、根本的な問題が解決されていないことを示している。例えば、ヘルスチェック連動の自動再起動が短時間に連続して発生する場合、アプリケーションに深刻な問題が存在する可能性がある。このような状況を放置すると、自動復旧のループに陥りシステムが不安定な状態に陥る。

そのため、自動復旧処理が一定期間内に複数回実行された場合には、運用担当者へアラートを発報する仕組みを整える必要がある。また、必要に応じて、一定時間内の実行回数が閾値を超えた場合には自動復旧処理を一時的に停止し、人的介入を促す実装も検討する。

定期的な分析と改善

自動対応の実行履歴を定期的に分析することで、システムの潜在的な問題や改善機会を発見できる。分析では、リソースのサイジングや台数が適切か、オートスケールの閾値設定が妥当か、スケールアウトとスケールインを繰り返す等の過度な自動対応が発生していないかを確認する。

特に注意すべきは、自動的に削減されないリソースの増加である。例えば、データベースのストレージ容量は多くの場合自動的に拡張されるが縮小されないため、一時的な負荷増加後も拡張された容量のまま維持される。このような状況を定期的に確認し、プロビジョニングされているリソースが過剰となっていないかを評価する。分析結果から得られた改善点は、2章で説明したポストモーテムプロセスと同様に、技術的な恒久対策として設計やパラメータの見直しにつなげる。

設計の妥当性評価方法

信頼性設計の妥当性を評価するためには、体系的な手法を活用することが重要である。本節では、設計段階での障害モード分析、テスト段階での検証戦略、運用段階での継続的評価という3つのフェーズにおける評価手法を説明する。これらの手法は、ウォーターフォール型の開発プロセスだけでなく、アジャイル開発やDevOpsなど、どのような開発スタイルでも適用可能である。

FMEAによる体系的な信頼性設計の評価

FMEA（Failure Mode and Effects Analysis：故障モード影響解析）は、システムに発生しうる障害モードを体系的に洗い出し、その影響度と発生頻度を評価する手法である。設計段階でFMEAを実施することで、優先的に対策すべき障害モードを特定し、第1層（予防的設計）と第2層（自動復旧）の設計に反映できる。

FMEAの実施では、まずシステムを構成要素に分解し、各構成要素について発生しうる障害モード（故障パターン）を列挙する。次に、各障害モードがユーザーやサービスに与える影響を分析し、影響度、発生頻度、検知難易度の3つの観点から評価する。この評価結果に基づいて優先度を決定し、優先度の高い障害モードへの対策を設計に組み込む。

例えば、Webサーバーのインスタンス停止という障害モードに対しては、影響度が高く発生頻度も中程度と評価されるため、冗長化設計と自動復旧の両方を実装する。一方、ロードバランサーのヘルスチェック誤検知は影響度が比較的低く発生頻度も低いため、ヘルスチェックの閾値調整で対応するといった判断ができる。

V字モデルに基づくテスト戦略

IPAのソフトウェア開発標準プロセスで示されるV字モデルの考え方を活用し、設計段階で作り込んだ信頼性をテスト段階で検証する。V字モデルでは、各設計段階に対応するテスト段階を定義し、設計で意図した内容がテストで検証されることを確保する。

信頼性設計においても、この考え方を適用する。例えば、基本設計で定義した冗長化設計は、システムテストにおいて一部のサーバーを停止させてもサービスが継続することを確認する。詳細設計で定義した自動復旧の仕組みは、結合テストにおいてヘルスチェックと連動した自動再起動が正しく動作することを検証する。このように、設計とテストの対応関係を明確にすることで、FMEAで特定した重要な障害モードへの対策が、テストで漏れなく検証されることを確保できる。

図 3-11 V字モデルに基づく信頼性設計とテストの対応

なお、V字モデルの考え方は、スクラム開発などのアジャイル開発においても同様に適用できる。スクラム開発では、各スプリントで機能を設計・実装する際に、その機能に対する信頼性設計（冗長化、自動復旧等）とテストケースを同時に定義する。スプリント内で設計とテストの対応関係を
明確にすることで、短いサイクルの中でも信頼性を作り込み、検証することができる。

継続的な評価と改善

設計段階とテスト段階での評価に加えて、運用段階でも継続的に評価と改善を行う。運用段階での評価手法として、自動復旧の動作ログを定期的に分析し、本節で説明した自動対応の監視を実施する。また、3.6.4節で説明する障害対応訓練を通じて、設計した信頼性の仕組みが実際の運用で有効に機能することを検証する。さらに、四半期毎を目安とした定期的な設計レビューを実施し、運用実績やシステムを取り巻く環境の変化に応じて設計の見直しを行う。

運用で発見された課題は、2章で説明したポストモーテムプロセスを通じて分析し、次の設計改善にフィードバックする。改善の優先順位は、影響度と発生頻度のマトリクスで評価し、影響度が大きく頻度が高いものから段階的に取り組む。このように、設計・テスト・運用の各段階で一貫した評価を行い、継続的な改善サイクルを回すことで、システムの信頼性を段階的に向上させることができる。

3.6.3 人的介入が必要な対応の準備（第3層）

第1層・第2層で対応できないインシデントに備え、人が迅速かつ適切に対応できる体制を整えておく必要がある。本節では、リモート対応体制の構築、緊急時のアクセス管理、CSPサポートとの連携について説明する。なお、詳細なインシデント対応プロセスについては「2章 インシデント対応と振り返り」を参照されたい。

リモート対応体制の構築

職員と事業者が、物理的に離れた異なる拠点で業務に携わるケースは多くあると考える。その状況下において、緊急対応が求められる場合に備えて、職員と事業者の間で役割分担を明確に定義し、リモートでの対応体制とツールを整備することが不可欠である。技術的復旧作業を担う事業者と業務影響判断を担う職員の間で情報共有プロセスに不備があると、障害発生時に復旧作業の開始が遅延し、停止時間の長期化を招くことになる。

そのため、事前にエスカレーション手順を定義するとともに、障害の影響範囲や復旧見込み時間をリアルタイムに情報共有する仕組みを構築する必要がある。また、事業者が独自判断で実施可能な復旧作業の範囲と職員の承認が必要な作業の境界を明確にしておくことで、緊急時の承認プロセス遅延と重要作業の無断実施による二次被害リスクを回避できる。なお、リモート対応の具体的な範囲（特定拠点のみからのアクセスか、テレワーク環境等も含むか）は、システムのセキュリティ要件などに応じて判断する。

リモート対応に必要なツールとして、リモート会議システム、チャットツール、リアルタイム編集可能なドキュメント共有ツールを整備する。これらのツールの具体的な活用方法については2.3節を参照されたい。加えて、夜間・休日を含む24時間365日の対応が必要な場合には、オンコール体制を整備し、連絡可能な担当者を常に確保しておく必要がある。

緊急時アクセスの管理

通常の運用ではZero Touch Productionを維持しつつ、緊急時のみ例外的に本番環境への権限昇格を許可する仕組みを整える。権限昇格には申請・承認プロセスを設け、操作ログの自動記録とアラート発報により不正使用を検知する。作業完了後は速やかに権限を削除し、定期的な権限棚卸しにより権限の放置を防ぐ。具体的な実装方法と運用上の注意点については3.2.3節を参照されたい。

CSPサポートとの連携

複雑な障害や未経験の事象に対しては、CSPの技術サポートとの連携が有効である。事前にサポートプランを選択し、エスカレーション手順を確立しておくことで、緊急時に迅速にサポートを受けられる体制を整える。サポートケースの起票時には、障害の状況、影響範囲、実施済みの対応を正確に伝えることが重要である。また、サポートとの協働復旧における役割分担を明確にし、効率的な問題解決を図る。過去のサポートケースは記録として保管し、同様の障害が発生した際の参考情報として活用する。

3.6.4 システムの信頼性検証

検証の目的と2つの観点

第1層・第2層で設計した信頼性の仕組みが実際に機能することを、テスト段階および運用段階で継続的に検証する必要がある。検証には大きく分けて以下の2つの観点がある。

• システムの機能検証(障害テスト): これは冗長化や自動復旧といった自動化機能が設計・設定通りに動作することを確認するものであり、主に障害テストや負荷テストを通じて実施する。
• 人の対応力検証(障害訓練): これは自動化機能だけでは対応できない事象に対して、運用者が適切に対応できることを確認するものであり、障害対応訓練を通じて実施する。

本節では、これら2つの観点から、システムの信頼性を継続的に検証する方法を説明する。

システムの機能検証（障害テスト）

障害対応における自動化機能は設計・設定のみでは運用中の正常動作を保証できない。そのため、実際にシステム上で負荷や擬似的な障害を発生させ、自動化機能が設計通りに動作することを検証する必要がある。これらのテストはシステムリリース前のテスト段階で実施するとともに、運用段階においても必要に応じ実施し、システムの変更や環境の変化に応じて継続的に動作を確認する。

(1)負荷テスト

負荷テストは、オートスケール機能が実際の負荷パターンにおいて適切に機能することを検証するために実施する。段階的に負荷を増加させながらリソース使用率の閾値を確認する段階的負荷増加テスト、急激な負荷変動に対する対応を確認するスパイクテスト、長時間高負荷での安定性を確認する持続負荷テストなどがある。

これらのテストは、システムリリース前のテスト段階で必ず実施するとともに、運用段階においても必要に応じ実施することが望ましい。特に大規模な設計変更を行った後や、トラフィックパターンに変化が見られた場合には、システムの性能設計の妥当性やオートスケール動作の再検証を実施する必要がある。テスト結果から得られる性能特性やボトルネック情報を蓄積し、システムのキャパシティプランニングやパラメータ調整に活用する。

(2)障害テスト

障害テストは、計画的に障害を発生させることで、自動復旧機能の動作を検証するものである。サーバーインスタンスを停止して自動復旧やフェイルオーバーの動作を確認するテスト、ネットワークを分断して冗長化経路の動作を確認するテスト、データベース接続を切断して接続プールやリトライ機能を確認するテスト、災害対策構成を採用している場合の本番環境から災害対策環境への切り替えおよび切り戻しテストなどがある。

障害テストで行うテスト項目は、V字モデルに基づき設計する。具体的には、3.6.2で説明した設計の妥当性評価で整理したFMEAの故障モードを元にテスト項目を作成し、それぞれのテスト結果がFMEAで机上評価した結果と比較して妥当なものであるかを評価するとよい。

これらのテストもシステムリリース前に実施するとともに、運用段階でも定期的な実施が望ましい（例えば、年に1-2回の定期実施など）。また、自動復旧機能に関する設計変更やパラメータ変更を行った場合には、その都度動作を検証する必要がある。テスト実施時には、各テストシナリオの結果を体系的に文書化し、自動復旧の所要時間、ログの記録状況、アラートの発報タイミングなどを確認する。

(3)カスケード障害テスト

カスケード障害テストは、1つのシステムやコンポーネントの障害が連鎖的に他のコンポーネントに波及するシナリオを検証するものである。実際の障害では予想外の連鎖が発生する可能性があるため、事前に障害の連鎖パターンを把握しておくことが重要となる。

このテストでは、特定のコンポーネントに障害を発生させ、その影響がどのように拡がるかを観察する。サーキットブレーカーやタイムアウト設定などの障害の局所化設計が適切に機能し、障害の連鎖を食い止められるかを確認する。カスケード障害テストは影響範囲が大きくなる可能性があるため、検証環境で十分に検証した上で、本番環境での実施可否を慎重に判断する必要がある。

人の対応力検証（障害対応訓練）

(1) 障害対応訓練の目的

障害の規模や種類によっては自動化機能だけでは対応できない可能性がある。そのため、運用者の介入が必要となる境界を確認し、その際の対応手順を整備するとともに、定期的に訓練を行い体験しておくことが必要である。障害対応訓練は、運用者が適切に対応できる能力を持つことを確認するとともに、対応手順の実効性を検証し、ノウハウの共有や手順の形式知化を進めることを目的とする。

(2) 訓練の種類

障害対応訓練には、難易度や実施環境に応じて複数の種類がある。

机上訓練は、障害シナリオに基づいて討議形式で実施するものである。対応手順を机上でレビューし、役割分担や連絡体制を確認する。実際にシステムを操作することなく実施できるため、頻繁に実施しやすく、四半期毎の実施が望ましい。特に新しい担当者が加わった場合や、対応手順に変更があった場合には、速やかに机上訓練を実施することが望ましい。

実機訓練は、検証環境で実際に障害を発生させ、手順書に基づいて復旧作業を実施するものである。手順書の記載内容が実際の作業で実行可能かを確認するとともに、作業に要する時間を計測することでRTO（目標復旧時間）の達成可能性を評価できる。実機訓練は半期毎の実施が望ましい。

総合演習は、本番相当の環境で複数の障害を組み合わせた総合的な演習を実施するものである。職員と事業者が協働してインシデント対応を行い、2章で説明したリアルタイム情報共有やチーム連携が実際に機能することを確認する。総合演習は最も実践的な訓練形式であるが、準備や実施に要する工数も大きいため、年1回以上の実施が望ましい。

(3) 訓練シナリオの設定

訓練シナリオは、自動化機能では対応できない事象を中心に設定する。全Webサーバーが同時に停止した場合の手動での緊急復旧、自動フェイルオーバーが失敗した場合の手動フェイルオーバー、データベースが完全に障害となった場合のバックアップからの復旧、複数のコンポーネントで障害が連鎖的に発生した場合の対応などが代表的なシナリオとなる。

シナリオ設定においては、過去に発生したインシデントや、FMEAで特定した重要な障害モードを参考にすることが効果的である。また、訓練を繰り返す中で、対応が困難だった事象や所要時間が長かった作業については、シナリオとして取り入れ、改善の効果を確認する。

検証結果の活用

(1)システム機能検証の結果活用

障害テストや負荷テストで得られた結果は、自動化機能の動作ログとともに詳細に分析する。設計やパラメータの妥当性を評価し、問題が発見された場合は設計にフィードバックして改善を行う。

例えば、オートスケールの発動タイミングが遅くユーザーに影響が出た場合には閾値を見直す、自動復旧に想定以上の時間を要した場合にはヘルスチェックの間隔を調整する、といった改善を実施する。また、テスト結果から得られる性能特性やボトルネック情報を蓄積し、システム全体の信頼性向上に活用する。

(2) 障害対応訓練の結果活用

障害対応訓練で得られた結果は、対応手順の実効性を評価するために活用する。訓練で手順書の記載が不明確だった箇所、想定していた作業時間を大幅に超過した作業、担当者間の連携がスムーズでなかった場面などを特定し、手順書やドキュメントを更新する。

また、訓練で計測した所要時間を記録し、RTO達成の可能性を評価する。もしRTOの達成が困難であることが判明した場合には、対応手順の効率化や自動化の範囲拡大、場合によってはRTO自体の見直しを検討する必要がある。訓練を通じて得られたノウハウは形式知化して共有し、チーム全体の対応力向上につなげる。

(3) 継続的改善への反映

障害テストと障害対応訓練の両方で発見された課題は、2章で説明したポストモーテムプロセスを通じて分析し、改善につなげる。第1層の設計に問題があれば設計を見直し、第2層の自動復旧機能に改善の余地があれば実装やパラメータを調整し、第3層の対応手順に課題があれば手順書を更新する。このように、検証結果を継続的な改善サイクルに組み込むことで、システムの信頼性を段階的に向上させることができる。