FISによる障害注入実験（前記事）で弱点が見つかったら、次はその弱点を実際にリファクタリングで解消していく段階に進みます。本記事ではその代表的な手法を解説します。

SAA レベル：基礎概念

単一障害点（SPOF）とは

システム内の1つのコンポーネントが停止すると、システム全体が停止してしまう箇所
代表例: 単一AZのみで稼働するデータベース、単一インスタンスのアプリケーションサーバー

SAA 試験のポイント

高可用性設計の第一歩は、アーキテクチャ図の中からSPOFをすべて洗い出すことです。マルチAZ化、Auto Scalingの導入など、基本的な冗長化手法の適用がSAAレベルの対応になります。

SAP レベル：高度な設計シナリオ

段階的なSPOF除去のアプローチ

SAP 試験のポイント

既存の稼働中システムをリファクタリングする際、一度にすべてを作り替えるのはリスクが高すぎます。SAPレベルでは、影響範囲とビジネスリスクの大きい箇所から段階的に着手するアプローチが問われます。例えば、まずステートレスなアプリケーション層をマルチAZ化・Auto Scaling化し、その後でよりリスクの高いデータベース層のマルチAZ/リードレプリカ化に着手する、という優先順位です。

リファクタリング優先順位（一般的な例）
1. ステートレスなアプリケーション層のマルチAZ化・Auto Scaling導入
2. ロードバランサーの導入（単一エンドポイント依存の解消）
3. データベース層のマルチAZ化
4. 依存する外部サービスの単一障害点の洗い出しと代替経路の検討

疎結合化による障害波及防止

SAP 試験のポイント

密結合なアーキテクチャ（サービスAがサービスBを同期的に直接呼び出す構成）では、サービスBの障害がサービスA、さらにはシステム全体に波及します。SAPレベルでは、SQS/SNS/EventBridgeを介した非同期化によってサービス間を疎結合にリファクタリングし、一部のサービス障害がシステム全体を停止させない設計への移行が問われます（2-2の疎結合アーキテクチャ記事とも直結する論点）。

設計上の落とし穴

「マイクロサービス化・非同期化すれば自動的にレジリエンスが向上する」という単純化は誤りです。非同期化しても、下流サービスの障害でキューにメッセージが滞留し続け、最終的にキューが溢れるといった新たな障害モードが生まれる可能性があります。SAPでは、DLQ（Dead Letter Queue）の設定や、キューの滞留を監視するアラーム設計まで含めた、包括的なリファクタリングが問われます。

ステートレス化とセッション外部化

アプリケーションサーバーがセッション情報をローカルに保持していると、そのインスタンスの障害でユーザーのセッションが失われる
セッション情報をElastiCacheやDynamoDBといった外部ストアに移すことで、どのインスタンスが応答してもユーザー体験が損なわれないステートレスなアーキテクチャへリファクタリングできる

依存関係のヘルスチェックの見直し

リファクタリング後は、ロードバランサーやRoute 53のヘルスチェックエンドポイントが、新しいアーキテクチャの実際の健全性（下流の疎結合化されたキューの滞留状況等）を正しく反映しているか、あわせて見直す必要がある

まとめ

SAA: SPOFの概念、基本的な冗長化手法（マルチAZ、Auto Scaling）を理解する。
SAP: リスクに応じた段階的なリファクタリングの優先順位付け、疎結合化に伴う新たな障害モード（キュー滞留等）への対策ができる。

次は サーキットブレーカー・リトライ設計を見ていきましょう。