[セッションレポート] 公共機関におけるクラウドレジリエンス ~障害からより早く回復するシステムの作り方~(AWS-37)#AWSSummit

[セッションレポート] 公共機関におけるクラウドレジリエンス ~障害からより早く回復するシステムの作り方~(AWS-37)#AWSSummit

Clock Icon2025.06.29

カスタマーサクセス部 運用支援チームのいたくらです。

本記事は 2025 年 6 月 25 - 26 日の 2 日間開催された AWS Summit Japan 2025 のセッションレポートです。

セッション情報

  • セッション ID : AWS-37
  • タイトル : 公共機関におけるクラウドレジリエンス ~障害からより早く回復するシステムの作り方~
  • スピーカー : 讃岐 和広(アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 CSM・パートナー・スケールソリューション技術本部 パートナーソリューション部 シニアパートナーソリューションアーキテクト)
  • レベル : 200
  • セッション概要(引用)

    デジタル社会の実現に向け、政府・地方自治体・医療・教育など様々な公共機関の重要システムがクラウド上で稼働し、国民の生活を支える基盤として日々重要度が高まっています。システム障害は国民生活に大きな影響を及ぼすため高い可用性が必要であり、障害から可能な限り早く回復するレジリエンス(回復力)を持ったシステムを構築することが重要です。本セッションでは、公共機関におけるレジリエンスライフサイクルフレームワークを始めとするレジリエンス強化の具体的な考え方について解説します。

  • 6月26日17時 - 7月11日19時 までオンデマンド配信で視聴可能です!

セッション内容

1. 公共システムとレジリエンス

  • 「障害に強いシステム」は、「壊れない」システムから「壊れてもすぐ回復する」システムへの変革が重要になってきている
  • 2018 年に日本政府よりクラウド・バイ・デフォルト原則がガイドラインとして発表されてから 7 年が経過
    • 様々な公共システムが AWS 上で稼働、これらは国民の豊かな社会生活のために不可欠な社会基盤となっている
  • IPA 非機能要求グレードでは、「可用性」と「性能・拡張性」が公共システムにおいて特に重要視される特性として挙げられている
    • これらの特性を高める包括的なアプローチ → クラウドレジリエンス
  • クラウドレジリエンスは、インフラストラクチャ、依存サービス、負荷の急上昇などに関連する中断に耐えたり、中断から回復する能力を指す
    • クラウドレジリエンス=クラウドの特性を活かしてレジリエンスを確保すること
  • 堅牢性は「障害を防ぐ」ことを重視し、レジリエンスは「障害から回復する」ことを重視する
    1-1.jpg
    • 要件が変化する環境では、堅牢性を重視したシステムは脆くなる可能性がある
  • レジリエンス確保に向けたメンタルモデルの変化として、「障害が起きることを前提に備える」こと、そして将来的には「障害が起きても自信をもって対応できる」ようになるため、システム障害テストを通じて回復性を改善・向上させる「継続的なレジリエンス」の概念が重要になってくる
  • クラウドレジリエンスにおける責任共有モデル
    2.jpg
    • お客様と AWS で共にレジリエンスを高めることが重要

2. レジリエンスライフサイクルフレームワーク

  • AWS規範ガイダンスで紹介されている「レジリエンスライフサイクルフレームワーク」に基づき、各ステージを詳細に解説

2.1. ステージ1: 目標を設定

  • 必要なレジリエンスのレベルと測定方法を理解し、具体的な目標を設定
    • 具体的な目標値として、SLO (サービスレベル目標)、RTO (目標復旧時間)、RPO (目標復旧時点)が挙げられる
    • 公共機関における目標設定の例として、デジタル庁/総務省の「地方公共団体情報システム非機能要件の標準」が紹介された
      3.jpg
  • コンポーネント単位ではなく、サービスとしての回復性、継続性に重点を置く「サービス視点でのレジリエンス」を意識することが重要
    4-1.jpg

2.2. ステージ2: 設計と実装

  • 障害モードを予測し、設計の選択肢を特定して実装
    • 具体的には「設定した目標に従い、システムがどのように障害を起こす可能性があるかを理解し、迅速に回復するための技術的方式を決定し実装する」
  • ミッションクリティカルな重要業務における設計ポイント
    • AWS Well-Architected フレームワークの6本の柱の一つである「信頼性」のベストプラクティスである「REL11-BP05 静的安定性を使用してバイモーダル動作を防止する」と「REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する」が特に重要
  • 「静的安定性」とは、システムが静的な状態で動作し、依存関係に障害が発生したり利用できなくなったりしたときに変更を加える必要なく、通常どおり動作し続けることができる性質
    • AWS インフラストラクチャにおける障害分離境界として、「リージョン」、「アベイラビリティゾーン」、「AWS Local Zones」、「AWS Outposts」、「Point of Presence」といった物理的な分離と、「コントロールプレーン」、「データプレーン」といった論理的な分離が存在
      5.jpg
    • AWS のサービスは、コントロールプレーンの障害時でもデータプレーンは安定して動作するよう設計されている=利用者に影響が出ないようになっている
    • 静的安定性を確保した構成例として、3 つのアベイラビリティゾーンにおいて、残りの 2 つの AZ がワークロード負荷の 100% を処理できるよう、十分な EC2 キャパシティをあらかじめプロビジョニングしておくことで、障害回復時にインスタンス起動に依存しない(=コントロールプレーンに依存しない)設計が紹介された
      6.jpg
    • ただし、すべての業務で静的安定性を確保するとコスト面で見合わないため、重要業務においてサービスレベル目標に合わせて静的安定性の確保を検討することが現実的

2.3. ステージ3: 評価とテスト

  • 実装したワークロードをテストし、結果を評価するアクティビティを実装
    • 具体的には「システムの回復力を確認するためのテスト手法を特定し、結果を評価する」
  • 従来の「ユニットテスト」、「インテグレーションテスト」などの既知の事象に対するテストに加えて、「カオスエンジニアリング」といった未知の事象に対するテストが重要
    • カオスエンジニアリングは、ハードウェア障害、クラウド外の障害、定常状態を乱す可能性のあるあらゆるイベントをシミュレートするイベントを注入することで、未知の事象に対するシステムの回復力を確認する手法
  • AWS Fault Injection Service は、障害注入を実行・管理するためのフルマネージドサービス
    • AZ 停電シナリオなどをシミュレート可能
      7.jpg

2.4. ステージ4: 運用

  • アプリケーションを本番環境にデプロイし、カスタマーエクスペリエンスを管理
    • 具体的には「システムが回復力を維持および改善するための運用プラクティスを特定する」
  • 障害を検出、調査、解決するために収集すべきデータ
    • カスタマーエクスペリエンスを測定するメトリクス
    • 影響範囲や大きさを測定するメトリクス
    • 運用の健全性を測定するメトリクス
  • Amazon CloudWatch Syntheticsは、一定間隔でエンドポイントに対しトラフィックを送信(外形監視)することで、サービスの健全性をチェック可能
    8.jpg

2.5. ステージ5: 対応と学習

  • インシデントに適切に対応し、経験から最大量の学習を得る
    • 具体的には「実際のインシデントから学び、システムとプロセスの両面でレジリエンスを継続的に強化する方法を特定する」
  • Correction of Error (COE) プロセス
    • 図のようなサイクルを回してレジリエンスを継続的に強化する
      9.jpg
  • AWS Systems Manager Incident Manager は、インシデント対応を一元管理し、迅速な問題解決を支援
    • さらに分析フェーズでは COE プロセスに基づくテンプレートも利用可能

3. 継続的なレジリエンス確保に向けたアクション

  • 人とテクノロジーが常に変化しているため、それに合わせてレジリエンスも変化させながら適応させていく必要がある
  • AWS Resilience Hub は、AWS 上のアプリケーションの回復力の定義・検証・追跡を一元化するサービス
    • AWS Resilience Hub を活用した改善サイクルを通じて継続的なトラッキングを実施し、さらに AWS サービスを組み合わせることで継続的なクラウドレジリエンスの確保が可能
      10.jpg

感想

「障害からより早く回復するシステムの作り方」というタイトルが気になり聴講しました。
印象的だったのは AWS Fault Injection Service を活用したカオスエンジニアリングです。AZ 停電シナリオなど実際の障害を安全に再現できる機能は実際に試したみたいと思いました。
また、AWS Resilience Hub によるアプリケーションの回復力の定義・検証・追跡の一元化は、継続的なレジリエンス確保のためにはとても便利なツールだと思いました。
これらのサービスを組み合わせることで、「障害が起きることを前提に備える」というメンタルモデルへの変化が進むと感じましたし、「壊れてもすぐ回復する」レジリエントなアーキテクチャの実現が現実的になると感じました。
今後ミッションクリティカルなシステム等に携わる機会があれば、これらのサービスを活用していきたいと思います。

以上、本レポートが参考になりましたら幸いです。
ご覧いただきありがとうございました。

アノテーション株式会社について

アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。
サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.