施設園芸向けの環境モニタリングサービスを提供する企業が、自社データセンターの複数サーバーでバックエンドを運用しています。センサーデータの収集と分析ロジックは複数の機能を持つ REST API として公開されており、ハウスごとの計測値は中央のストレージに蓄積されています。バックエンドはリクエストのスロットリングと本番トラフィックおよび検証用トラフィックの区別のために異なる API キーを使い分けています。日中と夜間で負荷が大きく変動し、日中のピーク時には容量が不足する一方、夜間は大量のサーバーが遊んでいます。また計測値の参照に遅延が生じ、警報の通知が遅れる事象も起きています。経営層は、負荷変動に自動で追従し、低レイテンシーでデータを参照でき、かつ既存の REST の API モデルを変更せずに移行できるクラウドアーキテクチャを求めています。この要件を満たすソリューションはどれですか。
解説を読む（正解: B）
Amazon API Gateway の REST API は、API キーと使用量プランを組み合わせることでクライアントごとのスロットリングとクォータを設定でき、本番用と検証用でキーを分ける既存の運用をそのまま持ち込めます。バックエンドを AWS Lambda にすれば、リクエスト数に応じて実行環境が自動的にスケールし、夜間のアイドル分に課金されません。Amazon DynamoDB のオンデマンドキャパシティモードは、トラフィックの増減に合わせてスループットを自動調整しつつ 1 桁ミリ秒台の応答を返すため、参照遅延の解消に適しています。選択肢 B はこの 3 つを組み合わせており、API モデルを変えずに伸縮性と低レイテンシーを実現します。選択肢 A は Network Load Balancer が L4 のロードバランサーであるため API キーによる認可やスロットリングを自前で実装する必要があり、EC2 のキャパシティ計画も残ります。選択肢 C の Application Load Balancer は Lambda をターゲットにできますが、API キーと使用量プランに相当する機能をネイティブに備えていないため、レート制限の仕組みを別途構築しなければなりません。選択肢 D の AWS AppSync は GraphQL 向けのマネージドサービスであり、クライアントとスキーマの作り直しが必要になるため「既存の API モデルを変更しない」という要件に反します。
ある農業テック企業は、全国の圃場に設置したスマートセンサーからのデータを AWS 上で処理しています。センサーは Application Load Balancer の背後にある Amazon EC2 上の API サーバーへデータを送信し、受け取ったデータは 4 TB の汎用 SSD (gp3) ボリュームを使う Amazon RDS for PostgreSQL DB インスタンスに書き込まれます。導入済みセンサーの台数はここ 1 年で数倍になり、来年度はさらに大幅に増える計画です。現在、API サーバーは常時過負荷の状態にあり、RDS のメトリクスでは書き込みレイテンシーの上昇が継続的に観測されています。費用対効果を保ちながら問題を恒久的に解消し、センサーの増設に合わせて拡張できるようにする方法はどれですか。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: C、E）
大量のデバイスから絶え間なくデータが届く IoT の取り込み経路では、同期的にリクエストを受けてリレーショナルデータベースへ直接書き込む構成は、デバイス数の増加に対して線形にスケールできません。Amazon Kinesis Data Streams を前段に置くと、取り込みをシャード単位で水平に拡張でき、書き込みのバーストをストリームがバッファとして吸収するため、下流の処理がスパイクの影響を受けにくくなります。ストリームから AWS Lambda を起動すればサーバー管理なしでレコードをバッチ処理でき、常時過負荷の EC2 API サーバー群も不要になります。加えて、時系列的に追記され続けるセンサーデータはキーとタイムスタンプによる書き込みと検索が中心であり、Amazon DynamoDB のようにパーティション単位で自動的に分散するキーバリューストアの方が、単一ライターに制約されるリレーショナルエンジンより書き込みスループットを素直に拡張できます。したがって選択肢 C と E の組み合わせが恒久的な解決になります。選択肢 A は誤りで、ボリューム容量と IOPS を増やしても単一インスタンスの書き込み能力という上限は残り、センサー増設のたびに同じ問題が再発する対症療法にすぎません。選択肢 B も誤りです。Aurora のリードレプリカは読み取りをスケールしますが、書き込みは依然としてライターインスタンス 1 台に集約されるため、観測されている書き込みレイテンシーの根本原因を解消できません。選択肢 D は誤りで、X-Ray は可視化とデバッグには有用なものの、API サーバーを増やすだけではデータベース側の書き込み限界に対処できず、常時稼働インスタンスの増加によりコスト効率も悪化します。