1. その他の定義
1.1. 回復力（弾力性）、および信頼性のコンポーネント
1.1.1. 回復力
1.1.2. その他
1.1.2.1. 運用上の優秀性
1.1.2.2. セキュリティ
1.1.2.3. パフォーマンス効率
1.1.2.4. コスト最適化
1.2. 可用性
1.2.1. リクエストに基づいて可用性を測定する
1.2.2. ハードな依存関係を持つ可用性を計算する
1.2.3. 冗長コンポーネントの可用性を計算する
1.2.4. 依存するシステムの可用性を計算する
1.2.5. 可用性のコスト
1.3. 目標復旧時間（RTO）と目標復旧時点（RPO）
1.3.1. RTO
1.3.2. RPO
2. ワークロードのアーキテクチャ
2.1. REL 3. お客様のワークロードサービスアーキテクチャを設計する
2.1.1. ワークロードをセグメント化する方法を選択する
2.1.1.1. モノリシックアーキテクチャを避ける
2.1.1.2. SOAもしくはマイクロサービスを選択
2.1.1.3. Microservice Trade-Offs
2.1.2. 特定のビジネスドメインと機能に重点を置いたサービスを構築する
2.1.2.1. ドメイン駆動設計を使用してモデル化
2.1.2.2. bliki: BoundedContext
2.1.3. APIごとにサービス契約を提供する
2.1.3.1. 組織のスケーリングが向上
2.1.3.2. 要件を満たしている限りいつでもデプロイ可能
2.1.3.3. 要件を満たしている限り必要なテクノロジースタックを使用可能
2.1.3.4. API Gateway
2.2. REL 4. 障害を防ぐために分散システムでの操作を設計する
2.2.1. 必要な分散システムの種類を特定する
2.2.1.1. 分散システムの課題
2.2.2. 疎結合の依存関係を実装する
2.2.2.1. キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサー
2.2.3. すべての応答に冪等生を持たせる
2.2.3.1. べき等性を持たせる
2.2.4. 動作を継続的に行う
2.2.4.1. 例）ヘルスチェックシステムが、監視下サーバの状態にかかわらず同じサイズのペイロードを送信する
2.3. REL 5. 障害を軽減または耐えるために分散システムでの操作を設計する
2.3.1. 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する
2.3.1.1. 依存関係の呼び出しが失敗した場合に静的応答を返す
2.3.2. スロットルリクエスト
2.3.2.1. 予想外の需要の増加に対応するための軽減パターン
2.3.3. 再試行呼び出しを制御および制限する
2.3.3.1. 間隔を徐々に長くして再試行するようにする
2.3.3.2. Exponential Backoff And Jitter | Amazon Web Services
2.3.4. すぐに失敗し、キューを制限する
2.3.4.1. リクエストに関連づけられたリソースの迅速な解放
2.3.5. クライアントタイムアウトを設定する
2.3.5.1. 接続タイムアウトと要求タイムアウト
2.3.5.2. ジッターを伴うタイムアウト、再試行、およびバックオフ
2.3.6. 可能な場合はサービスをステートレスにする
2.3.6.1. ElastiCache、DynamoDB
2.3.6.2. Lambda、Fargate
2.3.7. 緊急レバーを実装する
2.3.7.1. ヒント
2.3.7.1.1. レバーがアクティブになったら実行数を減らす
2.3.7.1.2. シンプルに保ち、バイモーダルな動作を避ける
2.3.7.1.3. 定期的にテストする
2.3.7.2. 緊急レバーではないアクション
2.3.7.2.1. 要領を追加する
2.3.7.2.2. クライアントに呼び出しを減らすよう依頼する
2.3.7.2.3. コードを変更してリリースする
3. 基盤
3.1. REL 1. Serviice Quotas の管理と制約
3.1.1. サービスクォータと制約を認識する
3.1.1.1. ドキュメント、制限ダッシュボード
3.1.2. アカウントおよびリージョンをまたいでクォータを管理する
3.1.2.1. 非実働環境でもクォータを管理
3.1.3. アーキテクチャを通じて、固定サービスクォータと制約に対応する
3.1.3.1. 上限緩和できないものを把握する
3.1.4. クォータをモニタリングおよび管理する
3.1.4.1. CloudWatchアラーム、TrustedAdvisor
3.1.5. クォータ管理を自動化する
3.1.5.1. Service Quotas API、構成管理DB
3.1.6. フェールオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
3.1.6.1. フェールオーバー時に必要なリソース数を考慮
3.2. REL 2. ネットワークトポロジを計画する
3.2.1. ワークロードのパブリックエンドポイントに可用性が高いネットワーク接続を使用する
3.2.1.1. CDN、API Gateway、ELB、リバースプロキシ
3.2.1.2. Route 53、Global Accelerator、CloudFront
3.2.2. クラウド環境とオンプレミス環境のプライベートネットワーク間の冗長構成をプロビジョニングする
3.2.2.1. Direct Connect、サイト間VPN
3.2.2.2. Direct Connect Resiliency Toolkit
3.2.3. 拡張や可用性のために割り当てるIPサブネットを確保する
3.2.3.1. リージョンごとに複数定義
3.2.3.2. VPC内で複数のAZにまたがるサブネットを確保
3.2.3.3. 将来の拡張を見越してスペースを確保
3.2.3.4. 一時的なフリートのニーズを考慮
3.2.3.5. 使用できないIPアドレスを把握
3.2.4. 多対多メッシュよりもハブアンドスポークトポロジを優先する
3.2.4.1. Transit Gatewayの活用
3.2.5. 接続されているすべてのプライベートアドレス空間において、重複しないプライベートIPアドレス範囲を指定する
3.2.5.1. IP重複を避ける
4. 設計の原則
4.1. 障害から自動的に復旧する
4.2. 復旧手順をテストする
4.3. 水平方向にスケールしてワークロード全体の可用性を高める
4.4. キャパシティーを推測することをやめる
4.5. オートメーションで変更を管理する
5. 可用性に対するニーズの理解
5.1. データプレーン
5.1.1. リアルタイムサービスの提供
5.1.1.1. 例）EC2インスタンス
5.2. コントロールプレーン
5.2.1. 環境の構成に使用
5.2.1.1. 例）EC2インスタンスの新規作成
6. 変更の管理
6.1. REL 6. ワークロードリソースをモニタリングする
6.1.1. 生成 - ワークロードのすべてのコンポーネントをモニタリングする
6.1.1.1. フロントエンド、ビジネスロジック、ストレージ層
6.1.1.2. CloudWatch、カスタムメトリクス、Logs、CloudTrail
6.1.1.3. CloudWatch synthetic、X-Ray
6.1.2. 集計 - メトリクスを定義して計算する
6.1.2.1. CloudWatch、S3、メトリクスフィルター
6.1.3. リアルタイムの処理とアラームの発行 - 通知を送信する
6.1.3.1. SNSによる通知
6.1.4. リアルタイムの処理とアラームの発行 - 対応を自動化する
6.1.4.1. SQS、Lambda、Config、Automation
6.1.5. ストレージと分析
6.1.5.1. CloudWatch Logs Insights、Athena
6.1.5.2. サードパーティツーつ
6.1.5.3. ライフサイクル
6.1.6. 定期的にレビューを実施する
6.1.6.1. CloudWatch Logs、CloudWatch Logs Insights
6.1.6.2. Config、CloudTrail
6.1.7. システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする
6.1.7.1. X-Ray
6.2. REL 7. 需要の変化に適応するようにワークロードを設計する
6.2.1. リソースの取得またはスケーリング時に自動化を使用する
6.2.1.1. マネージドサービスの使用、AWS AutoScaling
6.2.2. Amazon CloudFront または信頼できるコンテンツ配信ネットワークを設定して使用します
6.2.3. ワークロードの障害を検知した時にリソースを取得する
6.2.3.1. ヘルスチェックの設定、手動または自動でのスケーリング
6.2.4. ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得する
6.2.4.1. New – Predictive Scaling for EC2, Powered by Machine Learning | Amazon Web Services
6.2.5. ワークロードの負荷テストを実施する
6.2.5.1. 持続的な負荷テスト、テスト環境のセットアップ
6.3. REL 8. 変更を実装する
6.3.1. デプロイなどの標準的なアクティビティにランブックを使用する
6.3.1.1. デプロイ時におけるロールバックの安全性の確保
6.3.2. デプロイの一部として機能テストを統合する
6.3.2.1. 自動デプロイメントの一部として機能テストを実行
6.3.3. デプロイの一部として回復力テストを統合する
6.3.3.1. ステージングでのゲームデーの実施
6.3.4. イミュータブルなインフラストラクチャを使用してデプロイする
6.3.4.1. カナリアデプロイ、Blue/Greenデプロイ
6.3.4.2. 利点
6.3.4.2.1. 構成のずれの削減、簡素化された展開
6.3.4.2.2. 信頼性の高いアトミックデプロイメント、迅速なロールバックおよびリカバリプロセス
6.3.4.2.3. 一貫性のあるテストおよびデバッグ環境、スケーラビリティの向上
6.3.4.2.4. 簡素化されたツールチェーン、セキュリティの強化
6.3.5. 自動化を使用して変更をデプロイする
6.3.5.1. デプロイとパッチ適用を自動化
6.3.5.2. もっとも困難な手順にこそ自動化を適用
6.3.6. リスクを最小限に抑えるための別のデプロイパターン
6.3.6.1. 機能フラグ
6.3.6.1.1. Feature Toggles (aka Feature Flags)
6.3.6.2. 障害を分離するためのゾーンでのデプロイ
6.3.6.2.1. アベイラビリティーゾーンを使用した静的安定性
6.3.6.3. 運用状況レビュー（ORR）
6.3.6.3.1. 運用上の優秀性の柱
6.3.6.3.2. 最初の本番使用前、およびその後定期的に実施
7. 障害の管理
7.1. REL 9. データをバックアップする
7.1.1. バックアップする必要があるすべてのデータを特定してバックアップするか、ソースからデータを再現する
7.1.1.1. S3へのバックアップ、各種バックアップ機能の活用
7.1.1.2. オンプレからS3へのバックアップ、データウェアハウスへのロード
7.1.2. バックアップを保護し、暗号化する
7.1.2.1. AWS KMS
7.1.3. データバックアップを自動的に実行する
7.1.3.1. 各種バックアップ機能、Data Lifecycle Manager、AWS Backup
7.1.4. データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する
7.1.4.1. RTO、RPOの確認
7.1.4.2. ポイントインタイムリカバリ
7.2. REL 10. 障害部分を切り離してワークロードを保護する
7.2.1. 複数の場所にワークロードをデプロイする
7.2.1.1. AZ
7.2.1.1.1. マルチAZ構成
7.2.1.2. AWS ローカルゾーン
7.2.1.2.1. AWS Local Zones (レイテンシーに敏感なアプリケーションをエンドユーザーの近くで実行) | AWS
7.2.1.3. Amazon Global Edge Network
7.2.1.3.1. CloudFront、Global Accelerator
7.2.1.4. リージョン
7.2.1.4.1. DR計画
7.2.1.4.2. クロスリージョンのレプリケーション機能
7.2.1.4.3. CloudFormationによるデプロイ
7.2.1.4.4. Route 53とGlobal Accelerator
7.2.1.5. オンプレミス
7.2.1.5.1. ハイブリッド構成
7.2.1.5.2. Outposts
7.2.2. 単一のロケーションに制約されるコンポーネントのリカバリを自動化する
7.2.2.1. 例）EMR、Redshift
7.2.3. バルクヘッドアーキテクチャを使用する
7.2.3.1. 障害発生時の影響範囲を限定的にする
7.2.3.2. セルベースのアーキテクチャ
7.2.3.3. Shuffle Sharding: Massive and Magical Fault Isolation | Amazon Web Services
7.3. REL 11. コンポーネントの障害に耐えられるようにワークロードを設計する
7.3.1. ワークロードのすべてのコンポーネントをモニタリングしてエラーを検知する
7.3.1.1. ビジネス価値に基づいてKPIを監視
7.3.2. 正常なリソースにフェイルオーバーする
7.3.2.1. ELB、Auto Scaling
7.3.2.2. Route 53 と Global Accelerator
7.3.2.3. 複数AZにデプロイされるサービス
7.3.2.4. 複数のレプリカに永続的に保存された後にのリクエストを確認するデータストア
7.3.3. すべてのレイヤーの修復を自動化する
7.3.3.1. 再起動
7.3.3.1.1. ステートレス
7.3.3.2. ネットワーク要求を再開
7.3.3.2.1. 指数バックオフとジッター
7.3.3.3. Event Bridge、Auto Scaling
7.3.4. 静的安定性を使用してバイモーダル動作を防止する
7.3.4.1. バイモーダルとは、通常時と障害時で異なる動作を示すこと
7.3.4.2. コンピューティングデプロイメントの静的安定性
7.3.4.3. ネットワークのタイムアウトによるシステム全体の設定状態の再読み込みを避ける
7.3.4.4. 障害発生時にワークロードキャッシュをバイパスできるようにする
7.3.5. イベントが可用性に影響する場合に通知を送信する
7.3.5.1. CloudWatchアラーム
7.4. REL 12. 信頼性をテストする
7.4.1. プレイブックを使用して失敗を調査する
7.4.1.1. プレイブック＝調査プロセスの文書化
7.4.1.2. プレイブックのブラッシュアップ
7.4.2. インシデント後の分析を実行する
7.4.2.1. 要因と予防措置の項目を特定
7.4.2.2. 再発防止
7.4.3. 機能要件をテストする
7.4.3.1. 単体テスト、統合テスト
7.4.3.2. CodePipeline、合成トランザクションテスト
7.4.4. スケーリングおよびパフォーマンス要件をテストする
7.4.4.1. 基本リソース、スケーリング設定、サービスクォータ、復元力の設計を負荷テスト下で確認
7.4.5. カオスエンジニアリングを使用して回復力をテストする
7.4.5.1. PRINCIPLES OF CHAOS ENGINEERING - Principles of chaos engineering
7.4.5.2. サードパーティツール
7.4.5.2.1. Netflix/chaosmonkey
7.4.5.2.2. Chaos Toolkit
7.4.5.2.3. Shopify/toxiproxy
7.4.5.2.4. Gremlin: Build reliable systems
7.4.5.3. Level 300: Testing for Resiliency of EC2, RDS, and AZ :: AWS Well-Architected Labs
7.4.5.4. Injecting Chaos to Amazon EC2 using AWS System Manager
7.4.6. 定期的にゲームデーを実施する
7.4.6.1. 障害またはイベントをシミュレートしてシステム、プロセス、チームの応答をテスト
7.4.6.2. 全員が総力を挙げた取りくみ、エンジニアと運用当社に通知しプレイブックを用意
7.4.6.3. 本番環境で実施
7.5. REL 13. 災害対策（DR）を計画する
7.5.1. ダウンタイムやデータ消失に関する復旧目標を定義する
7.5.1.1. RTOとRPO
7.5.2. 復旧目標を満たすため、定義された復旧戦略を活用する
7.5.2.1. バックアップと復元
7.5.2.1.1. RPOは時間単位、RTOは24時間以内
7.5.2.1.2. データとアプリケーションをDRリージョンにバックアップしておく
7.5.2.2. パイロットライト
7.5.2.2.1. 分単位のRPO、時間単位のRTO
7.5.2.2.2. DRリージョンでコア要素の縮小バージョンを稼働、必要時にすべてをデプロイ
7.5.2.3. ウォームスタンバイ
7.5.2.3.1. 秒単位のRPO、分単位のRTO
7.5.2.3.2. DRリージョンで縮小バージョンを稼働、必要時にスケール
7.5.2.4. マルチリージョンのアクティブ/アクティブ
7.5.2.4.1. RTOはゼロまたは秒単位、RTOは秒単位
7.5.2.4.2. マルチリージョンでデプロイ、Route53やGlobal Acceleratorでルーティング
7.5.3. 災害対策の実装をテストし、検証する
7.5.3.1. 定期的に行い、RTOとRPOを満たすか確認
7.5.4. DRサイトまたはリージョンでの設定ドリフトを管理する
7.5.4.1. Config、Systems Managerオートメーション
7.5.5. 復旧を自動化する
7.5.5.1. ELB、Auto Scaling
7.5.5.2. Route 53、Global Accelerator
7.5.5.3. CloudEndure Disaster Recovery (高速で自動化された災害対策) | AWS
8. 可用性目標の実装例
8.1. 単一リージョンのシナリオ
8.1.1. 99%のシナリオ
8.1.2. 99.9％のシナリオ
8.1.3. 99.99%のシナリオ
8.2. 複数リージョンのシナリオ
8.2.1. 可用性が99.95%で復旧時間が5~30分
8.2.2. 99.999%以上のシナリオで、復旧時間が一分未満