【AWS Summit Japan 2025】公共機関におけるクラウドレジリエンス～障害からより早く回復するシステムの作り方～講演レポート

AWS Summit Japan 2025 とは？

AWS Summit Japan 2025とは、アマゾンウェブサービス（AWS）が主催する日本最大級のクラウドコンピューティングイベントです。2025年6月25日(水)と26日(木)の2日間、千葉県の幕張メッセで開催され、オンラインでのライブ配信も行われます。

このイベントは、AWSに関する最新技術やベストプラクティスの共有、情報交換を目的としており、クラウドを活用したイノベーションに興味のある全ての人を対象としています。

セッション情報

セッション名	公共機関におけるクラウドレジリエンス～障害からより早く回復するシステムの作り方～
セッション概要	デジタル社会の実現に向け、政府・地方自治体・医療・教育など様々な公共機関の重要システムがクラウド上で稼働し、国民の生活を支える基盤として日々重要度が高まっています。システム障害は国民生活に大きな影響を及ぼすため高い可用性が必要であり、障害から可能な限り早く回復するレジリエンス(回復力)を持ったシステムを構築することが重要です。本セッションでは、公共機関におけるレジリエンスライフサイクルフレームワークを始めとするレジリエンス強化の具体的な考え方について解説します。
登壇者	讃岐和広アマゾンウェブサービスジャパン合同会社パブリックセクター技術統括本部 CSM・パートナー・スケールソリューション技術本部パートナーソリューション部シニアパートナーソリューションアーキテクト

セッション詳細

本セッションでは、公共システムにおけるクラウドレジリエンスの重要性を理解し、具体的な強化方法を学ぶことを目的として、以下の流れで進行しました。

公共システムとクラウドレジリエンスの概要
レジリエンスライフサイクルフレームワークの詳細
AWSのマネージドサービスの紹介
まとめと今後の展望

公共システムとクラウドレジリエンス

公共システムは国民生活を支える重要な社会基盤であり、可用性と性能・拡張性が求められます。クラウドレジリエンスは、障害から迅速に回復する能力を持つシステムを構築するための包括的なアプローチです。

スライドのタイトル：「障害に強いシステムとは何でしょうか？」
本文：
「壊れない」システム
から
「壊れてもすぐ回復する」システムへ
左下にAWSのロゴと著作権表記あり。

「壊れない」システムから「壊れてもすぐ回復する」システムへと進化することが、現代の公共システムにおいて重要な課題となっています。

レジリエンスの構成要素

レジリエンスとは、アプリケーションがインフラストラクチャ、依存サービス、構成ミス、一時的なネットワークの問題、負荷の急上昇などに起因するシステムの中断に耐えたり、中断から回復する力を指します。

スライドのタイトル：「クラウドレジリエンスとは」
本文：
レジリエンスとは、アプリケーションがインフラストラクチャ、依存サービス、構成ミス、一時的なネットワークの問題、負荷の急上昇などに関連する中断に耐えたり、
中断から回復する能力を指す。
3つのボックスに分かれて説明あり。
1. 高可用性：
設計および運用メカニズムによる一般的な障害への耐性
2. ディザスタリカバリ：
大規模な障害が発生した場合に目標の時間内に復旧
3. 継続的なレジリエンス：
デプロイ前のテストからカオスエンジニアリングパターンへの移行
その下に「システム全体に渡るオブザーバビリティ（可観測性）」の枠。
最後に強調テキストで
「クラウドレジリエンスは、クラウド環境の特性を活かしてレジリエンスを確保すること」
左下にAWSのロゴと著作権表記あり。

レジリエンスを高めるために重要な要素は以下の通りです。

高可用性を意識した運用設計
ディザスタリカバリ環境
継続的なテストと改善
システム全体にわたるオブザーバビリティの確保

堅牢性とレジリエンスの違い

スライドのタイトル：「レジリエンス確保に向けたメンタルモデルの変化」
表形式で3つの列に分かれている。
列の見出しは「堅牢性」「レジリエンス」「継続的なレジリエンス」行の見出しは「メンタルモデル」「方針」「対策例」
内容は以下の通り。
【メンタルモデル】
堅牢性：障害を起こさない
レジリエンス：障害が起きることを前提に備える継続的なレジリエンス：障害が起きても自信をもって対応できる
【方針】
堅牢性：システム障害の防止
レジリエンス：システム障害からの早期回復
継続的なレジリエンス：システム障害テストで回復性を改善・向上
【対策例】
堅牢性：冗長性、監視
レジリエンス：冗長性、監視、自動修復
継続的なレジリエンス：冗長性、監視、自動修復、カオス・エンジニアリング
スライド下部に「これまで」から「これから」への矢印あり。
参考文献としてNassim Nicholas Talebの著書とGartnerブログのリンクが記載。
左下にAWSのロゴと著作権表記あり。

堅牢性は障害を防ぐ予防的アプローチであるのに対し、レジリエンスは障害から回復する適応的アプローチです。

デジタル社会の進化に伴い、公共システムにおいても稼働中に要件が変化していくケースが増加しています。堅牢性だけでは対応が難しい状況が増え、レジリエンスの重要性はさらに高まっています。

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

レジリエンスライフサイクルフレームワークとは、AWSが開発したフレームワークで、以下の5つのステージを通じてレジリエンスを向上させます。

1. 目標を設定

スライドのタイトル：「サービス視点でのレジリエンスを意識する」
サブタイトル：「コンポーネントの単位ではなく、サービスとしての回復性、継続性に重点を置く」（オレンジ色の下線付き）
内容は以下の通り。
・「可用性」の観点
- サーバー障害やDB障害がサービスに影響を与えなければよい
・Webサーバーが4台中2台障害になっても、サービスに影響ないアーキテクチャ
・バックエンドのアプリケーションに障害が発生しても、メッセージキューでタスクを非同期に格納、バックエンド復旧後に処理して解消
・「性能・拡張性」の観点
- スパイクが発生してもサービスに影響を与えなければよい
・Virtual Waiting Room、メッセージキューによる非同期処理
左下にAWSのロゴと著作権表記あり。

必要なレジリエンスのレベルと測定方法を理解し目標を設定します。アプリケーションのどの部分にどの程度のレジリエンスレベルが必要なのか確認し、RTO（目標復旧時間）/RPO（目標復旧時点）/SLO（サービスレベル目標）等の測定可能な目標を設定します。サービスの信頼性と性能に関する測定可能な目標値であるSLOは、利用者の体験に直結するので最も重要です。

2. 設計と実装

設定した目標に従い、システムがどのように障害を起こす可能性があるか理解し、迅速に回復するための技術的方式を決定し実装します。期待されるレジリエンス特性として、タイムリーな実行、正確な実行、障害の分離、十分なキャパシティ、冗長性が挙げられます。ただし、これらを高める際にはコストや複雑性などのトレードオフを考慮する必要があります。

スライドのタイトル：「静的安定性を確保した構成例」
左側にAWSのリージョンと3つのアベイラビリティゾーン（Availability Zone A、B、C）が示された図。
Elastic Load Balancingが上部にあり、3つのゾーンにトラフィックを分散。
各ゾーンに50%の負荷が割り当てられているが、Availability Zone Cには赤いバツ印が付いている。
右側にテキスト：
構成例：
3つのアベイラビリティゾーンにおいて、残りの2つのAZがワークロード負荷の100%を処理できるように、十分なEC2キャパシティーをあらかじめプロビジョニングしておく
AZに障害が発生した場合でも、
回復手法としてインスタンス起動に依存しない（＝コントロールプレーンに依存しない）よう、あらかじめインスタンス容量を確保しておく
（この部分はオレンジ色と青色の強調あり）
左下にAWSのロゴと著作権表記あり。

さらに、静的安定性の概念を取り入れることが重要です。静的安定性とは、システムが静的な状態で動作し、依存関係に障害が発生したり利用できなくなったりした場合でも変更を加える必要なく、通常通り動作し続けることができる性質を指します。これにより、ミッションクリティカルな重要業務においても高い可用性を確保することが可能です。

3. 評価とテスト

カオスエンジニアリング（未知の事象）についてのスライド。
以下をシミュレートするイベントを注入：
・ハードウェア障害（サーバの停止など）
・不正な応答などのソフトウェア障害
・トラフィックの急増やスケーリングイベントなど、障害以外のイベント
・クラウド外の障害
・定常状態を乱す可能性のあるあらゆるイベント
右上に爆弾のイラストが描かれている。
画面左下にAWSのロゴと著作権表示あり。

実装したワークロードをテストし、結果を評価します。カオスエンジニアリングを活用して未知の事象に対応する手法が有効です。AWS Resilience Hub の AWS Fault Injection Serviceを利用して、障害注入を実行し、システムの回復力を検証・改善します。

4. 運用

「どのようなデータを収集すべきか？障害を検出、調査、解決するために」というタイトルのスライド。
左から順に3つのカテゴリがアイコン付きで説明されている。
1. カスタマーエクスペリエンスを測定するメトリクス
- ユーザ体験がどう変化しているか？
- 例：E2Eのレイテンシー
- アイコンは人とノートパソコンのシンプルな線画。
2. 影響範囲や大きさを測定するメトリクス
- どれくらいの数のユーザーに影響を及ぼしているか？
- 例：影響を受けたトラフィック／ユーザー数
- アイコンは歯車2つと警告マークの三角形。
3. 運用の健全性を測定するメトリクス
- ワークロードは安定しているか？ユーザー影響が出ている原因は何か？
- 例：オペレーターの稼働割合、チケットの対応率
- アイコンは上昇グラフの棒グラフ。
画面左下にAWSのロゴと著作権表示あり。

アプリケーションを本番環境にデプロイし、カスタマーエクスペリエンスを管理します。障害を検出、調査、解決するために収集すべきデータとして、カスタマーエクスペリエンスを測定するメトリクス、影響範囲やその大きさを測定するメトリクス、運用の健全性を測定するメトリクスが挙げられます。

「Amazon CloudWatch Synthetics」についてのスライド。
左上にAmazon CloudWatchのロゴ。
中央にSyntheticsのアイコンがあり、そこから下にAlarmのアイコン、右にWebsiteのアイコンへ矢印が伸びている。
左のオレンジの吹き出しに「『Canary』を定義して、ヘッドレスブラウザが監視対象にアクセス」と記載。
中央のテキストは以下の通り：
「Syntheticsが一定間隔でエンドポイントに対しトラフィックを送信（外形監視）
サービスの健全性をチェック」右のWebsiteアイコンには赤いバツ印が重なっている。
画面左下にAWSのロゴと著作権表示あり。

Amazon CloudWatch Syntheticsは、ウェブサイト、API、その他のエンドポイントを監視するためのフルマネージドサービスです。実際のユーザ行動をシミュレートするCanaryと呼ばれる定義を行うことで、アプリケーションの可用性や性能を継続的に検証します。一定間隔でエンドポイントに対してトラフィックを送信する外形監視を構築でき、人間が気づくよりも早い段階で障害を検出することが可能です。

5. 対応と学習

「AWS Systems Manager Incident Manager」についてのスライド。
サブタイトルは「インシデント対応を一元管理し、迅速な問題解決を支援するサービス」。
左側に「インシデント」アイコンがあり、そこからAmazon EventBridge（ルールターゲット）とAmazon CloudWatch（Alarmアクション）に矢印が伸びている。
運用担当者への手動呼出しも示されている。
中央に「対応プラン」ボックスがあり、Runbook、Chatチャネル、エンゲージメントの3項目が記載。
対応プランからIncident Managerに矢印が伸び、Incident Manager内には「インシデント」情報が赤枠で囲まれており、タイムライン、影響/状態、エンゲージメント状況、関連メトリクス、Runbook実行状況、関連項目が示されている。
インシデント情報は「分析」へつながり、Systems Manager Automationへ矢印が伸びている。
下部には「エスカレーションプラン」があり、Stage1はメール、Stage2はSMS、Stage3は電話で通知する流れが示されている。
右側にはAWS Chatbotのアイコンがあり、Slack、Teams、Amazon Chimeと連携している。
画面左下にAWSのロゴと著作権表示あり。

インシデントに適切に対応し、経験から最大量の学習を得ます。インシデント後の分析を通じて、問題の根本原因を特定し、改善策を見つけ、再発防止のためのアクションアイテムを特定・追跡します。AWS Systems Manager Incident Managerを活用して、インシデント対応を一元管理し、継続的な改善を行います。