AIAI Agent Dev Labaiagentdev-lab.com
3分適性診断 →
無料で学習を始める／ログイン無料で始める
メニュー

DVA-C03 · LESSON 1

AWS サービスによる開発30% · 3項目

SDK の一時エラーは上限付きバックオフで扱います。SQS の再配送を前提に注文 ID の条件付き書き込みで重複を防ぎます。DynamoDB はアクセスパターンからキーと索引を選び、Query と Scan の違いを確認します。

1.1イベントとデータ操作を正しく実装する

イベントとデータ操作を正しく実装する

概念

SDK の一時エラーは上限付きバックオフで扱います。SQS の再配送を前提に注文 ID の条件付き書き込みで重複を防ぎます。DynamoDB はアクセスパターンからキーと索引を選び、Query と Scan の違いを確認します。

仕組み・手順

  1. 要件と成功条件を先に書き出す。
  2. 検証環境で操作し、成功・失敗の証跡を残す。
  3. 結果を確認してから、下の分野別練習で判断を確かめる。

業務での例

重複する注文イベントを投入し、保存件数と再試行後の結果を確認する。

紛らわしい点・試験の注意

ミニクイズ

Q1. EC2 で動く Web アプリを Auto Scaling で水平スケーリングしたい。ログイン状態がサーバーのメモリに保存されているため、台数が変わるとログアウトされてしまう。最も適切な対策はどれか。

  1. セッション情報を ElastiCache や DynamoDB に保存して、サーバーをステートレスにする
  2. 利用者にログイン状態を保存しないよう、ブラウザの設定変更を依頼する
  3. ALB のヘルスチェックを無効にして、Auto Scaling でサーバーが入れ替わらないように固定する
  4. Auto Scaling をやめて、最も大きなインスタンス1台で運用する
答えと解説を見る

正解：A　セッション情報を ElastiCache や DynamoDB に保存して、サーバーをステートレスにする

セッションを外部のデータストアに置くと、どのサーバーでも同じセッションを扱えるため、台数を自由に増減できる。スティッキーセッションは一時的な回避策にとどまる。

Q2. 画像のアップロードを受け付ける API で、サムネイル作成に時間がかかり、応答がタイムアウトする。最も適切な改善策はどれか。

  1. API のタイムアウトを1時間に延ばし、利用者に待ってもらう
  2. 受け付けたらすぐに応答し、サムネイル作成は SQS などで非同期に処理する
  3. サムネイル作成をやめて、元の画像をそのまま表示する
  4. API サーバーを最も大きなインスタンスタイプに変更して、サムネイル作成の同期処理を続ける
答えと解説を見る

正解：B　受け付けたらすぐに応答し、サムネイル作成は SQS などで非同期に処理する

時間のかかる処理は受付と切り離して非同期にすると、応答が速くなり、処理側も独立してスケールできる。

参考リンク

1.2スケーラブルで疎結合なアーキテクチャを設計する

概念

疎結合は、構成要素の間に SQS（キュー）・SNS（通知）・EventBridge（イベント）を挟み、一方の遅延や障害が他方に波及しないようにする設計です。処理はステートレスにしてセッションを ElastiCache や DynamoDB に置き、Auto Scaling で水平に拡張します。サーバーレス（Lambda・API Gateway・Step Functions）や、コンテナ（ECS・EKS・Fargate）も選択肢です。

仕組み・手順

  1. 同期の呼び出しを、必要に応じて SQS を挟んだ非同期の処理にする
  2. 1 つのイベントを複数の処理に配るときは SNS から複数の SQS へ（ファンアウト）
  3. アプリをステートレスにして、セッションを外部に置く
  4. SQS のキューの長さなどを指標に Auto Scaling する
  5. 複数の手順は Step Functions で制御し、失敗時の再試行を定義する

業務での例

注文を SNS に発行し、在庫・請求・通知の各 SQS にファンアウトして、各処理を独立に拡張する。請求の処理が停止しても注文はキューに残る。

紛らわしい点・試験の注意

ミニクイズ

Q1. キューを使った非同期処理を設計している。Amazon SQS の説明として誤っているものを選べ。

  1. メッセージは受信者が削除するまで、保持期間の間キューに残る
  2. 送り側と受け側の処理速度の違いを吸収し、疎結合にできる
  3. デッドレターキューで、処理に失敗し続けるメッセージを退避できる
  4. 標準キューは、メッセージが送信された順序を常に厳密に保証する
答えと解説を見る

正解：D　標準キューは、メッセージが送信された順序を常に厳密に保証する

標準キューはベストエフォートの順序で、厳密な順序が必要なら FIFO キューを使う。

Q2. サーバーレスで処理を作る。Lambda の制約や課金の説明のうち、誤っているものはどれか。

  1. S3、SQS、EventBridge など、さまざまなサービスのイベントをきっかけに実行できる
  2. 実行回数と実行時間（メモリ量に応じた単価）で課金される
  3. 1回の実行時間に上限はなく、数時間のバッチもそのまま実行できる
  4. VPC 内のリソースにアクセスするように設定できる
答えと解説を見る

正解：C　1回の実行時間に上限はなく、数時間のバッチもそのまま実行できる

Lambda の最大実行時間は15分。長時間の処理は Step Functions で分割するか、ECS/Fargate や AWS Batch を使う。

参考リンク

1.3高性能なデータベースのソリューションを決める

概念

読み取りの拡張は RDS・Aurora のリードレプリカ（Aurora は最大 15）、頻繁な読み取りのキャッシュは ElastiCache（Redis・Memcached）、DynamoDB のマイクロ秒の読み取りは DAX です。接続数の急増には RDS Proxy、予測できない負荷には Aurora Serverless v2、大規模なキーバリューは DynamoDB のパーティションキーの設計が性能を左右します。

仕組み・手順

  1. 読み取りと書き込みの比率、レイテンシの要件を確認する
  2. 読み取りが多いならリードレプリカかキャッシュを使う
  3. Lambda からの大量の接続は RDS Proxy でプールする
  4. DynamoDB はアクセスが偏らないパーティションキーを選び、必要なら DAX を加える
  5. グローバルな低遅延の読み取りは Aurora Global Database や DynamoDB グローバルテーブル

業務での例

商品の詳細ページの読み取りが DB の負荷の 9 割を占めるため、ElastiCache に結果をキャッシュし、在庫の更新はプライマリへ書き込む。

紛らわしい点・試験の注意

ミニクイズ

Q1. DynamoDB に注文 ID が未登録の場合だけ注文を作成したい。何を使うか。

  1. TTL の削除時刻で重複を判定
  2. ConditionExpression の条件付き書き込み
  3. 読み取り後の無条件 PutItem
  4. Scan の結果件数で存在を判定
答えと解説を見る

正解：B　ConditionExpression の条件付き書き込み

存在確認と書き込みを原子的に条件評価し、競合による重複を防ぎます。

Q2. DynamoDB の性能を改善したい。パーティションキーの顧客 ID 以外に、注文日で検索したい。現在はテーブル全体をスキャンしていて遅い。最も適したものはどれか。

  1. オンデマンドキャパシティモード
  2. DynamoDB Streams
  3. グローバルセカンダリインデックス（GSI）
  4. DynamoDB Accelerator（DAX）
答えと解説を見る

正解：C　グローバルセカンダリインデックス（GSI）

GSI は別のパーティションキー・ソートキーでの検索を可能にし、スキャンを避けられる。

参考リンク

レッスンは当サイトがAWS 認定の公式ページと公式試験ガイドをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。

ご利用上の注意（非公式・独自問題・合格保証なし）