「サーバーを高性能にすれば、止まらなくなると思っていました。それではだめなのですか」
「暗号化も大切なので、信頼性のための取り組みだと思って選んでしまいます」
AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 CLF）では、Well-Architected フレームワークの信頼性の柱の設計原則を、問題文の困りごとから見分ける問題がよく出ます。「故障で止まる」という困りごとに、どの設計原則が当たるのかを答えます。
この記事は、CLF の練習問題を1問ずつ解説する連載の第8問です。問題は筆者が試験の範囲に合わせて作ったもので、実際の試験の問題ではありません。まず自分で答えを選んでから、解説を読んでください。
▶ この回の内容は、YouTube の動画（約5分）でも見られます（記事の最後にも埋め込んであります）。
問題
ある企業は、オンライン予約システムを AWS で運用しています。夜間に1台のサーバーが故障したとき、担当者が対応するまで予約を受け付けられない状態が何度か起きました。AWS Well-Architected フレームワークの信頼性の柱の設計原則に沿った改善はどれですか。（2つ選択）
- A. 故障に備えて、より高性能な1台のサーバーに置き換える
- B. 保管中と転送中のデータを暗号化する
- C. 障害を検知したら、自動で復旧する仕組みを用意する
- D. 1台の大きなサーバーを複数の小さなサーバーに置き換え、リクエストを分散する
- E. 本番に近い環境で障害を起こすのは危険なため、復旧手順のテストは行わない
答えを2つ決めたら、下を開いてください。
正解を見る（クリックで開きます）
正解：C と D
C は「障害から自動的に復旧する」、D は「水平方向にスケールして、ワークロード全体の可用性を高める」という、信頼性の柱の設計原則です。どちらも、担当者の対応を待たずに予約を受け付け続けるための改善です。
正解は C と D
正解は C と D です。
- C：障害から自動的に復旧する、という設計原則
- D：水平方向にスケールして、ワークロード全体の可用性を高める、という設計原則
どちらも、担当者を待たずに、予約を受け付け続けるための改善です。ここから、選択肢を1つずつ見ていきます。
選択肢ごとの解説
A：高性能な1台でも単一障害点（誤り）
図の左のように、サーバーを高性能な1台に置き換えるのは、垂直方向のスケールです。性能は上がりますが、サーバーは1台のままです。図の右のように、その1台が故障すれば、やはり予約を受け付けられません。そこが止まると全体が止まる単一障害点が、残ったままです。
B：暗号化はセキュリティの柱（誤り）
保管中と転送中のデータを暗号化するのは、データを守るための取り組みです。これは、セキュリティの柱の設計原則「保管中と転送中のデータを保護する」にあたります。
大切なことですが、サーバーの故障で予約が止まる、という今回の問題は解決しません。柱の違いで見分けましょう。
C：障害から自動的に復旧する（正解）
信頼性の柱の障害から自動的に復旧する、という設計原則です。
例えば、Amazon CloudWatch で監視し、しきい値を超えたら、自動で復旧の処理を動かします。EC2 Auto Scaling は、異常なインスタンスを、自動で新しいものに入れ替えます。夜間でも、担当者の対応を待たずに復旧できます。
D：水平方向にスケールする（正解）
水平方向にスケールして、ワークロード全体の可用性を高める、という設計原則です。
図の右のように、1台の大きなサーバーを、複数の小さなサーバーに置き換えます。リクエストは、Elastic Load Balancing で振り分けます。1台が故障しても、残りのサーバーで予約を受け付けられます。
E：復旧手順はテストする（誤り）
信頼性の柱の設計原則は、復旧手順をテストするです。「テストを行わない」は逆の説明です。
クラウドでは、障害を模擬して、復旧の手順が働くかを、前もって確かめられます。本番で障害が起きる前に、手順の不備を見つけて直せます。
信頼性の柱の5つの設計原則
信頼性の柱の5つの設計原則を整理しておきます。今回の正解は、表の1つ目と3つ目でした。「容量の推測をやめる」は、需要に合わせてリソースを自動で増減する、という考え方です。
| 設計原則 | 中身の例 |
|---|---|
| 障害から自動的に復旧する | 監視し、しきい値を超えたら自動で復旧する |
| リカバリ（復旧）手順をテストする | 障害を模擬して、復旧の手順を確かめる |
| 水平方向にスケールして ワークロード全体の可用性を高める | 大きな1台を、小さな複数台に分けて分散する |
| 容量（キャパシティ）の推測をやめる | 需要を監視し、リソースを自動で増減する |
| 変更を自動化で管理する | インフラの変更を、自動化で行う |
ポイント
- 「担当者が対応するまで止まる」→ 障害から自動的に復旧する
- 1台を大きくするのではなく、小さく分けて分散（水平方向のスケール）
- 暗号化は セキュリティの柱。復旧手順は テストする
Well-Architected の6つの柱と、故障に備えた設計・水平方向のスケールの考え方は、講座の記事で詳しく解説しています。
講座の全14回は、連載の入口のページから順に読めます。
動画で見る
この回の内容を、YouTube の動画（約5分）でも解説しています。
連載の全回は、YouTube の再生リスト「CLF-C02 試験対策問題」にまとめています。
連載「CLF-C02 試験対策問題」
全回の目次と、読む順番・目的別の読み方は、CLF-C02 試験対策問題の入口のページにまとめています。
- 第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）
- 第2問 数分でグローバルに展開（世界同時公開と低い遅延）
- 第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）
- 第4問 クラウドの俊敏性（数分で作成・すぐに削除）
- 第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）
- 第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）
- 第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）
- 第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）（この記事）
- 第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）
- 第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）
- 第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）
- 第12問 移行のビジネスケース（Migration Evaluator）
- 第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）
- 第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）
- 第15問 ファイルの移行（AWS DataSync）
- 第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）
- 第17問 適切なサイズ設定（CPU は余り、メモリが不足）
- 第18問 責任共有モデル（Lambda と RDS）
- 第19問 最小権限の原則（IAM のポリシーと SCP）
- 第20問 責任共有モデル（EC2 と S3、AWS の責任）
- 第21問 共有統制の例（責任共有モデルの IT 統制）
- 第22問 コンプライアンスの資料と契約（AWS Artifact）
- 第23問 脅威の検出（Amazon GuardDuty）
- 第24問 脆弱性の継続的なスキャン（Amazon Inspector）
- 第25問 S3 の機密データの検出（Amazon Macie）
- 第26問 S3 の保管時の暗号化とキーの管理
- 第27問 だれが操作したかを調べる（AWS CloudTrail）
- 第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）
- 第29問 EC2 のアプリケーションに権限を与える（IAM ロール）
- 第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）
- 第31問 社員に一時的な認証情報を発行するサービス（AWS STS）
- 第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）
- 第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）
- 第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）
- 第35問 追加料金なしの DDoS 保護（AWS Shield Standard）
- 第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）
- 第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）
- 第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）
- 第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）
- 第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）
- 第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）
- 第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）
- 第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）
- 第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）
- 第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）
- 第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）
- 第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）
- 第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）
- 第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）
- 第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）
コメント