AWS ソリューションアーキテクト アソシエイト 弾力性のある設計 問題

正解は FIFO キューのメッセージグループ ID に顧客 ID を入れる構成です。FIFO キューは、同じメッセージグループ ID の中では届いた順に処理されることを保ち、重複も取り除きます。顧客 ID をグループ ID にすれば、同じ顧客の中では順序が守られ、別の顧客のグループは並行して処理できます。標準キューでコンシューマーを増やす案は、順序と 1 回だけの処理を保証しないので要件に合いません。すべてに同じグループ ID を入れる案は、全メッセージが 1 列に並んで並行処理ができず、処理量の要件に合いません。配信遅延を付ける案は、届く時刻をずらすだけで順序を保証しないので要件に合いません。出典 https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-⁠queues-⁠understanding-⁠logic.html

正解は SNS トピックに発行し、システムごとの SQS キューを購読させる構成です。SNS は 1 つの発行を複数の購読者へ配るので、注文側はトピックに送るだけで済み、システムを足すときは購読を追加するだけです。各システム専用の SQS キューにメッセージが残るため、システムが止まっていても復旧後に処理できます。API を直接呼ぶ案は、注文側が宛先を知る密結合で、相手が止まるとイベントを失い、追加のたびに改修が要るので要件に合いません。1 つのキューを共有する案は、1 件のメッセージを 1 つのシステムしか受け取れないので要件に合いません。データベースを定期的に読む案は、本番 DB に負荷をかけ、イベント駆動の疎結合にならないので要件に合いません。出典 https://docs.aws.amazon.com/sns/latest/dg/sns-⁠sqs-⁠as-⁠subscriber.html

正解は API Gateway の WebSocket API と Lambda でサーバー側から更新を送る構成です。WebSocket API は双方向の通信で、クライアントからの問い合わせを待たずにサービス側からクライアントへデータを送れます。Lambda と組み合わせれば、サーバーを管理せずに作れます。REST API に 1 秒ごとに問い合わせる案は、要件で禁じた定期的な問い合わせそのものなので要件に合いません。EC2 と ALB の案は、接続は保てますがインスタンスの管理が必要になり、サーバーを管理しない要件に合いません。SQS から各ブラウザが受け取る案は、ブラウザが SQS を取りに行く問い合わせ型で、利用者ごとの配信にも向かないので要件に合いません。出典 https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-⁠websocket-⁠api.html

正解はインスタンスあたりのバックログを指標にし、許容値を目標にした追跡の設定です。キューの取り出し可能なメッセージ数を稼働中の台数で割った値を指標にし、1 台が待ち時間内にさばける量を目標値にすれば、溜まったジョブの量と台数の両方に比例して増減できます。CPU 使用率を目標にする案は、この処理では CPU がジョブの量に応じて上がらないため台数が増えず、要件に合いません。メッセージ数だけを見る案は、いま何台で処理しているかを考えに入れないので、台数とバックログが比例せず要件に合いません。スケジュールの案は、ジョブの量ではなく時刻で決めるため、量に比例させる要件に合いません。出典 https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-⁠using-⁠sqs-⁠queue.html

正解は AWS Transfer Family で SFTP のエンドポイントを作り、保存先を S3 にする方法です。Transfer Family は SFTP などのプロトコルでのファイル転送を完全マネージドで提供し、保存先に S3 を選べます。取引先は接続先を変えるだけで今の SFTP の送り方を続けられ、サーバーの運用も要りません。EC2 に SFTP サーバーを立てる案は、OS やソフトの運用が残るので要件に合いません。署名付き URL の案は、取引先の送り方を HTTPS に変えさせるので要件に合いません。DataSync の案は、取引先の環境にエージェントを置く必要があり、送り方を変えない要件に合いません。出典 https://docs.aws.amazon.com/transfer/latest/userguide/what-⁠is-⁠aws-⁠transfer-⁠family.html

正解は SQS のイベントソースマッピングの最大同時実行数を 2⁠0 にする設定です。最大同時実行数は、SQS のイベントソースが起動できる関数の同時実行の数に上限を設ける設定です。上限に達している間、メッセージはキューに残り、空きができたら処理されるので、データベースへの同時接続を 2⁠0 までに抑えられます。バッチサイズを 1 にする案は、1 回に渡す件数が減るだけで同時に動く数は抑えられないので要件に合いません。可視性タイムアウトを長くする案は、処理中のメッセージが再び見えるまでの時間を変えるだけで、同時実行は抑えないので要件に合いません。メモリを減らす案は、性能を落とすだけで同時実行の数は変わらないので要件に合いません。出典 https://docs.aws.amazon.com/lambda/latest/dg/services-⁠sqs-⁠scaling.html

正解は Amazon FSx for Windows File Server でファイル共有を作る方法です。FSx for Windows File Server は Windows Server の上に作られたフルマネージドのファイルストレージで、業界標準の SMB プロトコルと Windows のファイルシステムの機能に対応し、Active Directory と組み合わせたアクセス権も使えます。アプリが前提にする SMB の共有をそのまま用意できます。EFS の案は NFS でのアクセスで、SMB を前提にしたアプリには合いません。EBS を 1 台に付けて共有する案は、その EC2 が自前のファイルサーバーになり、AWS が管理する要件に合いません。S3 の API を使う案は、アプリの改修が必要になるので要件に合いません。出典 https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-⁠is.html

正解は DynamoDB Streams を有効にし、Lambda のトリガーで反映する構成です。DynamoDB Streams はテーブルの項目の変更を記録し、Lambda をトリガーとしてつなぐと、変更に反応して自動でコードが動きます。書き込むアプリには手を入れずに、変更をほぼ即時に検索インデックスへ流せます。5 分ごとのスキャンは、反映が数秒以内にならず、毎回テーブル全体を読むので要件に合いません。アプリに SQS への送信を足す案は、コードを変えられないという制約に反するので要件に合いません。毎日のエクスポートは、反映が 1 日遅れるので要件に合いません。出典 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.html

正解は Amazon EKS でクラスターを作り、今のマニフェストを適用する方法です。EKS はフルマネージドの Kubernetes サービスで、コントロールプレーンの運用を AWS に任せながら、Kubernetes の API と既存のマニフェスト、Helm、kubectl をそのまま使えます。ECS のタスク定義に書き直す案は、マニフェストと運用の道具を捨てることになり要件に合いません。EC2 に自分で構築する案は、コントロールプレーンを自分たちで運用することになり要件に合いません。Elastic Beanstalk の案は、Kubernetes のマニフェストや Helm を使えないので要件に合いません。出典 https://docs.aws.amazon.com/eks/latest/userguide/what-⁠is-⁠eks.html

正解は Aurora Auto Scaling のポリシーで Aurora レプリカを増減させる方法です。Aurora Auto Scaling は、接続数や負荷に応じて DB クラスターの Aurora レプリカ (リーダーのインスタンス) の数を動的に調整します。リーダーエンドポイントは増えたレプリカにも振り分けるので、アプリを変えずに読み取りの増減へ追従できます。ライターを大きくする案は、垂直スケールで台数は変わらず、普段も大きな費用を払い続けるうえ増減の要件に合いません。別リージョンのレプリカ 1 台は、台数が固定で負荷に合わせて増減しないので要件に合いません。決まった時刻に増減する案は、予測できない時刻の急増に追従できないので要件に合いません。出典 https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html

正解は CloudFront のディストリビューションを置き、エッジでキャッシュする方法です。CloudFront は世界中のエッジロケーションからコンテンツを配信し、エッジにキャッシュがあればそこからすぐに返します。キャッシュにないときだけオリジンへ取りに行くので、同じファイルへの要求が急増してもエッジで受け止められ、元の EC2 へ届く要求が減ります。インスタンスタイプを大きくする案は、急増のたびの要求がすべて EC2 に届くままで、上限を少し上げるだけなので要件に合いません。台数を増やして ALB で振り分ける案は、台数を増やさないという条件に反するので要件に合いません。加重ルーティングの案は、振り分けの割合を決めるだけで、すべての要求が EC2 に届くことは変わらないので要件に合いません。出典 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html

正解は Kinesis Data Streams に利用者 ID の分割キーで入れ、保持を 3 日以上にする構成です。Kinesis Data Streams は 1 つのストリームを複数のアプリがそれぞれ独立して読めます。分割キーで同じ利用者の記録が同じシャードに入り、シャードの中では順番が保たれます。保持期間は既定の 2⁠4 時間から延ばせるので、3 日分を読み直せます。SQS 標準キューの案は、1 件を 1 つのアプリしか受け取れず、受信して消したら読み直せないので要件に合いません。SNS の案は、配った記録を保持しないため過去分を読み直せないので要件に合いません。FIFO キューを送り分ける案は、処理後に消えるメッセージを読み直せず、送る側も 3 つの宛先を知る必要があるので要件に合いません。出典 https://docs.aws.amazon.com/streams/latest/dev/key-⁠concepts.html

正解は Step Functions の標準ワークフローで、タスクトークンを使って承認を待つ構成です。標準ワークフローはコールバックの型に対応し、タスクトークンを外へ渡して、そのトークンが返るまで流れを止めておけます。担当者の操作を受けた仕組みが SendTaskSuccess か SendTaskFailure でトークンを返すと続きが進み、待つ間は計算資源を動かしません。Lambda の中で待ち続ける案は、待つ間ずっと関数を動かし、1 回の実行時間にも上限があるので要件に合いません。Express ワークフローの案は、要求と応答の型しか使えず、トークンを返すまで待つ型に対応しないので要件に合いません。EC2 で 1 分ごとに確かめる案は、計算資源を動かし続け、状態の管理も散らばるので要件に合いません。出典 https://docs.aws.amazon.com/step-⁠functions/latest/dg/connect-⁠to-⁠resource.html

正解は CloudFront のオリジングループに東京と大阪の S3 を入れ、東京を主にする構成です。オリジングループは主と副の 2 つのオリジンを持ち、主が使えないときや、障害を示す特定の HTTP ステータスを返したときに、CloudFront が副のオリジンへ切り替えて取りに行きます。GET や HEAD の要求が対象なので静的サイトに向き、DNS を変えずに同じディストリビューションの中で切り替わります。Route 5⁠3 のフェイルオーバーの案は、DNS の切り替えに頼るので要件に合いません。バージョニングの案は、誤った上書きからの復元の仕組みで、東京の障害時に別のリージョンから返せないので要件に合いません。パスで半分ずつ分ける案は、障害時の切り替えにならないので要件に合いません。出典 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html

正解は RDS Proxy を置き、Lambda の接続先をプロキシのエンドポイントに変える方法です。RDS Proxy は接続プールを持ってデータベースの接続を使い回し、急な接続の増加ではすぐに渡せない接続を待たせるので、データベースを接続で溢れさせません。さらにフェイルオーバーのときはアプリの接続を保ったまま待機側へつなぎ直すので、切断の影響を減らせます。リードレプリカの案は、書き込みを伴う販売処理の接続は振り分けられないので要件に合いません。ElastiCache の案は、読み取りの結果を置くもので接続の急増やフェイルオーバーの切断は解決せず、アプリの改修も大きいので要件に合いません。インスタンスクラスを大きくする案は、変えないという制約に反するので要件に合いません。出典 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-⁠proxy.html

正解はレイテンシーベースのルーティングで 2 つのレコードを作り、ヘルスチェックを付ける設定です。レイテンシーベースのルーティングは、利用者にとって遅延の最も小さいリージョンのレコードを返します。フェイルオーバー以外のルーティングにヘルスチェックを組み合わせると、すべてのレコードを使うアクティブアクティブの形になり、不健全になったリージョンのレコードは返さなくなります。フェイルオーバールーティングの案は、平常時はプライマリだけを使うアクティブパッシブで、両方で常に処理する要件に合いません。位置情報でヘルスチェックなしの案は、障害のリージョンへも向け続けるので要件に合いません。シンプルルーティングの案は、ヘルスチェックを付けられず遅延も考えないので要件に合いません。出典 https://docs.aws.amazon.com/Route5⁠3/latest/DeveloperGuide/dns-⁠failover-⁠types.html

正解はスプレッドプレイスメントグループに 3 台を起動する方法です。スプレッドプレイスメントグループは、各インスタンスを別々のハードウェアに置くもので、互いに離しておくべき少数の重要なインスタンスに勧められています。ラックごとに電源とネットワークが分かれるので、同じ機器の故障で同時に止まる危険を下げられます。クラスタープレイスメントグループの案は、低遅延のために近くへまとめて置くもので、同時に止まる危険が上がるので要件に合いません。1 台の Dedicated Host にまとめる案は、同じ物理サーバーに載るので要件に合いません。1 台にまとめる案は、単一障害点を作るので要件に合いません。出典 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-⁠strategies.html

正解は構成を CloudFormation のテンプレートに書き、両方のリージョンでスタックを作る方法です。CloudFormation では、必要な AWS のリソースとその設定をテンプレートに書き、スタックとして作成すると、Auto Scaling グループ、ロードバランサー、データベースなどをまとめて用意できます。一度書いたテンプレートを複数のリージョンで使い回せるので、同じ構成を一貫して繰り返し作れ、変更もテンプレートの更新として残せます。AMI をコピーする案は、インスタンスの中身は運べても VPC や ALB や RDS の構成は作れないので要件に合いません。手順書を細かくする案は、手作業が残り、漏れや食い違いを防ぎきれないので要件に合いません。Config のルールの案は、食い違いを見つけるだけで、同じ構成を作ったり反映したりはしないので要件に合いません。出典 https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html

正解は新しい AMI の起動テンプレートを作り、インスタンスの更新で入れ替える方法です。インスタンスの更新は、Auto Scaling グループのインスタンスを新しい設定のものへ置き換える機能で、新しい AMI を入れた起動テンプレートを作ってから実行すると、変更を全台へ順に展開できます。稼働中のインスタンスを書き換えずに作り直すので、設定の食い違いもなくなります。Run Command で当てる案は、稼働中のインスタンスを直接書き換えるので要件に合いません。1 台から AMI を作って手で同じ作業を繰り返す案も、各台をその場で書き換えるので要件に合いません。希望台数を 0 にする案は、全台が止まって台数を保てないので要件に合いません。出典 https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-⁠instance-⁠refresh.html

正解は待機側のリージョンで、本番の規模に合わせたクォータの引き上げを先に申請しておく方法です。サービスクォータは平常時の使用量だけで決めず、AZ やリージョンの障害で切り替えたときの最大の使用量まで余裕を持たせておく必要があります。待機側は平常時に台数が少ないため、上限が本番の規模に足りないことがあり、切り替えの前に引き上げておかないと起動に失敗します。本番リージョンで申請する案は、起動に失敗したのは待機側なので要件に合いません。最大台数だけを変える案は、グループの設定を変えてもクォータの上限は変わらないので要件に合いません。大きなタイプに変える案は、必要な計算資源の総量は変わらず、上限に当たる問題を解かないので要件に合いません。出典 https://docs.aws.amazon.com/wellarchitected/latest/reliability-⁠pillar/rel_manage_service_limits_suff_buffer_limits.html

正解は Amazon Comprehend の事前学習済みのモデルで文章を分析する方法です。Comprehend は自然言語処理で文書の中の実体、主要な語句、言語、感情などを見つけ出すサービスです。事前学習済みのモデルを使うので、学習用のデータを用意したりモデルを作ったりする必要がなく、マネージドなサービスとして量の増加にも基盤の運用なしで対応できます。Polly の案は、文章を音声に変えるサービスで、感情や語句を自動で取り出さないので要件に合いません。EC2 で自分たちで学習させる案は、モデルの作成と基盤の運用が残るので要件に合いません。Translate の案は、翻訳はできても感情や語句の取り出しは人手になり、自動で取り出す要件に合いません。出典 https://docs.aws.amazon.com/comprehend/latest/dg/what-⁠is.html

正解はインスタンスの自動復旧を有効にし、システムの状態チェックの失敗で復旧させる方法です。EC2 の自動復旧は、土台のハードウェアやソフトウェアの問題でインスタンスが使えなくなったとき、自動で可用性を取り戻す仕組みです。復旧したインスタンスはインスタンス ID とプライベート IP アドレス、Elastic IP アドレスなどを保つので、ライセンスの結び付きを壊しません。Auto Scaling グループの案は、新しいインスタンスに置き換えるため ID と IP が変わり要件に合いません。2 台目を置く案は、2 台以上では動かせないという制約に反するので要件に合いません。AMI から起動し直す案は、人の操作が要り、ID も変わるので要件に合いません。出典 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-⁠instance-⁠recover.html

正解は Amazon Polly で文章を自然な音声に変換する方法です。Polly は文章を自然な音声に変えるクラウドのサービスで、複数の言語と多くの声を備えています。AWS が用意した音声を使うので、モデルを作ったり学習させたりする必要がなく、マネージドなサービスとして大量の要求にも基盤の運用なしで対応できます。Transcribe の案は、音声を文章に変える音声認識のサービスで、向きが逆なので要件に合いません。Comprehend の案は、文章から語句や感情を取り出すサービスで、音声は作らないので要件に合いません。EC2 にライブラリを入れる案は、サーバーと基盤の運用が残り、量の増加にも自分で備える必要があるので要件に合いません。出典 https://docs.aws.amazon.com/polly/latest/dg/what-⁠is.html

正解は Regional のファイルシステムを作り、各 AZ にマウントターゲットを置く方法です。EFS の Regional のファイルシステムは、同じリージョンの地理的に離れた複数の AZ にデータを冗長に保存するので、1 つ以上の AZ が使えなくなってもデータを使い続けられます。One Zone をどこからもマウントする案は、データが 1 つの AZ だけにあり、その AZ が失われるとデータを失うおそれがあるので要件に合いません。One Zone を AZ ごとに分ける案は、各 AZ の中身が別々になり共有にならず、AZ が失われればそこのデータを失うので要件に合いません。インスタンスストアの案は、インスタンスを止めると消える一時的な記憶域なので要件に合いません。出典 https://docs.aws.amazon.com/efs/latest/ug/features.html

正解は目標復旧時点 (RPO) です。RPO は、最後のデータの復旧点からの経過時間として、許容できる最大の値を表し、障害が起きたときにどこまでのデータの損失を受け入れるかを決めます。組織が業務への影響から定めます。目標復旧時間 (RTO) は、サービスが止まってから再開するまでに許容できる最大の遅れを表すもので、データの損失の量ではないので問いに合いません。平均故障間隔 (MTBF) は、故障と故障の間の平均の時間で、損失の許容量ではないので問いに合いません。サービスレベル合意 (SLA) は、提供者と利用者の間で品質を約束する取り決めで、災害時に許容するデータの損失を表す指標ではないので問いに合いません。出典 https://docs.aws.amazon.com/whitepapers/latest/disaster-⁠recovery-⁠workloads-⁠on-⁠aws/business-⁠continuity-⁠plan-⁠bcp.html

正解はマルチ AZ の DB クラスターとしてデプロイし、リーダーで読み取りを受ける構成です。マルチ AZ の DB クラスターは、同じリージョンの 3 つの AZ に書き込み用のインスタンス 1 台と読み取り可能なリーダー 2 台を置き、リーダーが読み取りを受けつつ、書き込み用のインスタンスの障害時には自動のフェイルオーバー先になります。マルチ AZ の DB インスタンスの案は、スタンバイが読み取りを受けられないので要件に合いません。シングル AZ とリードレプリカの案は、昇格が手作業で自動の切り替えにならないので要件に合いません。Aurora PostgreSQL へ移す案は、RDS for PostgreSQL のまま使い続けるという制約に反するので要件に合いません。出典 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-⁠az-⁠db-⁠clusters-⁠concepts.html