10問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
無料レッスン・テストを受講するにはフリーコース(無料)に登録してください。
まず、次の操作を完了する必要があります:
正解数 0/問題数10
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【DVA-2001】ある開発者は、注文処理アプリケーションの構成を管理しています。このアプリケーションは注文確定時に AWS Lambda 関数からアカウント A のカスタムイベントバスにイベントを発行しています。現在は分析チームのアカウント B のみがこのイベントを処理していますが、新たに監査チームのアカウント C と在庫チームのアカウント D でも同じイベントを処理する必要が生じました。イベントを発行する Lambda 関数のコードと設定は変更できません。この要件を満たす方法を選択してください。
イベント発行元の Lambda を変更できないという制約は、扱いを「アカウント A のイベントバスに届いた後」に限定することを意味します。EventBridge のルールのターゲットには、同一アカウントのリソース以外に何を指定できるでしょうか。また、複数チームがそれぞれ独立に同じイベントを処理する必要がある点に注目し、1つのキューを複数アカウントで読む構成が成立するかも考えてみましょう。
【DVA-2002】ある開発者は、注文確定時にメール送信を行うアプリケーションを構築しています。Web アプリケーションは注文情報を Amazon SQS のスタンダードキューに送信し、AWS Lambda 関数がキューをイベントソースとして受信してメールを送信します。関数のタイムアウトは 60 秒に設定されており、平均処理時間は 40 秒です。運用開始後、一部の顧客に同一の注文確認メールが複数回届くという報告が発生しています。この問題に対処する方法を選択してください。
Amazon SQS のスタンダードキューが保証している配信セマンティクスは「ちょうど 1 回」でしょうか、それとも「少なくとも 1 回」でしょうか。まずここを確認してみましょう。
また、関数のタイムアウトが 60 秒で平均処理時間が 40 秒という条件のとき、キュー側のメッセージが再び他のコンシューマーから見えてしまう時間設定になっていないか注目してください。
配信側の設定変更だけで重複が根絶できるのか、受信側の処理設計にも手を入れる必要があるのか、両面から考えてみましょう。
【DVA-2003】ある開発者は、EC2 インスタンスの Auto Scaling グループと Application Load Balancer で構成された EC アプリケーションを開発しています。現在、ログイン中のユーザーのセッション情報は各 EC2 インスタンスのローカルメモリに保持されています。スケールイン時にユーザーが強制的にログアウトされる事象が発生しています。また、確定した注文データはリレーショナル形式で永続的に保存する必要があります。これらの要件を満たす構成を選択してください。
スケールインでインスタンスが終了したとき、そのインスタンス内やアタッチされたボリュームにあるセッション情報はどうなるでしょうか。全インスタンスから共通して読み書きできる場所に置く必要がある点に注目してください。
もう一つの要件は「リレーショナル形式で永続的に保存」です。グラフ、オブジェクト、キーバリューといった各データストアの中で、この条件に合致するものはどれか確認してみましょう。
【DVA-2004】ある開発者は、Application Load Balancer と Auto Scaling グループ内の Amazon EC2 インスタンスで構成される Web アプリケーションを保守しています。アプリケーションはログイン状態とショッピングカートの内容を各インスタンスのローカルディスクに保存しています。スケールイン時にユーザーがログアウトされ、カートの内容が失われる事象が発生しています。開発者はアプリケーションをステートレスに変更する必要があります。この要件を満たす方法を選択してください。(2つ選択)
スケールインでデータが失われる根本原因は、状態がインスタンスのローカルディスクにあることです。ではセッションをどこに置けば、どのインスタンスが応答しても同じ状態を読めるでしょうか。「インスタンス外部の共有ストアにセッションIDで高速アクセスできる」という条件を全選択肢に当てはめると、該当するものはいくつあるか数えてみましょう。状態を残したまま接続先を固定する案は、根本解決になるか考えてみてください。
【DVA-2005】ある開発者は、Application Load Balancer の背後にある Amazon EC2 Auto Scaling グループ上で Web アプリケーションを実行しています。セッションデータは各インスタンスのローカルディスクに保存されています。ユーザーはページ遷移のたびにログイン状態が失われると報告しています。スケールイン時にもセッションを維持する必要があります。この要件を満たす方法を選択してください。
ログイン状態がページ遷移のたびに失われるのは、リクエストが毎回同じインスタンスに届いていないためです。ではセッションデータをどこに置けば、どのインスタンスが受け取っても同じ状態を読めるでしょうか。さらに「スケールイン時にも維持する」という条件を加えると、インスタンスのライフサイクルに依存しない場所が必要になります。セッション参照は毎リクエスト発生することにも注目してください。
【DVA-2006】ある開発者は、外部の SaaS プロバイダーの API から顧客データを取得するアプリケーションを構築しています。この API は 1 日あたりのリクエスト数に上限があり、上限に達すると HTTP 429 が返されます。全件の取得には数日かかる見込みです。処理は上限に達した時点で一時停止し、翌日に中断箇所から再開する必要があります。取得状況は追跡可能でなければなりません。この要件を満たす方法を選択してください。
処理を「翌日まで一時停止」する必要があります。AWS Lambda 関数の最大実行時間は 15 分ですが、この制約の中で 24 時間待機できるでしょうか。
待機している間、どこに「どこまで取得したか」という状態を保持し、誰がその状態遷移を管理するのかを考えてみましょう。
長時間の待機とエラーに応じた分岐を宣言的に定義できるサービスに注目してください。
【DVA-2007】ある開発者は、Amazon DynamoDB のテーブルにセンサーデータを書き込むアプリケーションを AWS Lambda で実行しています。テーブルはプロビジョニングモードで作成されており、書き込みトラフィックは平常時は一定ですが、1 日に数回、数分間だけ通常の 10 倍に急増します。急増中に Lambda 関数のログに ProvisionedThroughputExceededException が記録され、一部のデータが書き込まれずに失われています。この問題を解消する方法を選択してください。(2 つ選択)
ProvisionedThroughputExceededException は「設定した容量を超えた」という意味です。まず容量そのものをどう確保するか、次に超過した瞬間のリクエストをどう救済するか、2 段階で考えてみましょう。数分間だけ 10 倍になるスパイクに、固定値のプロビジョニングで追従できるでしょうか。また、Lambda の並列度を上げることや読み取り側の仕組みを足すことが、書き込み容量の不足に効くのかにも注目してください。
【DVA-2008】ある開発者は、AWS Step Functions のステートマシンで注文処理ワークフローを構築しています。ワークフロー内のタスク状態は、外部の決済 API を呼び出す AWS Lambda 関数を実行します。この API は一時的にスロットリングエラーを返すことがあり、その場合は同じ Lambda 関数を数秒間隔で最大 3 回まで再実行し、待機時間を段階的に延ばす必要があります。この要件を満たす方法を選択してください。
「同じ Lambda 関数を最大 3 回まで再実行し、待機時間を段階的に延ばす」という要件を、どのレイヤーで実現すべきか考えてみましょう。
Step Functions のタスク状態が持つエラー処理の仕組みには 2 種類ありますが、それぞれ「同じ状態をやり直す」のか「別の状態へ逃がす」のか、役割の違いに注目してください。
また、Step Functions から Lambda を呼び出す際の呼び出しタイプが同期か非同期かも判断材料になります。
【DVA-2009】ある開発者は、AWS Step Functions のステートマシンで注文処理ワークフローを構築しています。ワークフローの中の 1 つのタスク状態は AWS Lambda 関数を呼び出して外部の決済 API を参照します。この Lambda 関数は外部 API の一時的な遅延によって States.Timeout エラーで失敗することがあります。開発者は、このタスクが失敗した場合に待機時間を段階的に延ばしながら最大 4 回まで同じタスクを再実行し、それでも失敗した場合にワークフローを失敗させたいと考えています。この要件を満たす方法を選択してください。
Step Functions のエラー処理には Retry と Catch という 2 つの異なるフィールドがあります。それぞれの役割の違いに注目してください。「同じタスクをもう一度実行する」のはどちらでしょうか。また「待機時間を段階的に延ばす」ためには IntervalSeconds と BackoffRate のようなパラメータが必要ですが、これらを受け付けるのはどのフィールドでしょうか。TimeoutSeconds が制御するのは実行時間の上限にすぎない点も併せて考えてみましょう。
【DVA-2010】ある開発者は、Amazon DynamoDB テーブルから大量の項目をまとめて読み取るアプリケーションを構築しています。アプリケーションは BatchGetItem を低レベル API で直接呼び出しています。トラフィックが増加する時間帯になると、レスポンスの UnprocessedKeys に多数のキーが含まれ、開発者のコードはそれらのキーを直ちに同じ内容で呼び出し直しています。その結果、未処理のキーがさらに増え、読み取りが完了しません。この状況を改善する最も適切な方法を選択してください。
UnprocessedKeys が返るのは、リクエストの一部がスロットリングなどで処理しきれなかったことを示すシグナルです。そこへ同じ内容を間隔なしで投げ直すと、テーブルにかかる負荷はどうなるでしょうか。再試行の「間隔」をどう制御すれば負荷が分散するかに注目してください。さらに、その制御ロジックを自分で書く必要があるのか、AWS SDK が既に何を提供しているのかも確認してみましょう。
⚠️ こちらは教材の操作/UIなど全般に対するリクエストフォームではございません。
個別の問題についての改善リクエストです。
教材全般についての改善リクエストはお問い合わせフォームよりご連絡ください。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
