Lambda のタイムアウト上限を超える処理のリファクタリング
ある医用画像 SaaS 事業者は、Amazon S3 バケットにアップロードされた画像をダウンロードして変換し、変換後の画像を別の S3 バケットへ保存したうえで、Amazon DynamoDB テーブル上の画像メタデータを更新するアプリケーションを運用しています。このアプリケーションは Python で書かれ、AWS Lambda 関数として実行されており、新しい画像が S3 にアップロードされたときに呼び出されます。長らく問題なく稼働していましたが、取り扱う画像の解像度が大幅に上がったことで、Lambda 関数がタイムアウトエラーで失敗することが頻発するようになりました。関数のタイムアウトはすでに設定可能な最大値になっています。ソリューションアーキテクトは、呼び出しの失敗を防ぐためにアーキテクチャをリファクタリングする必要がありますが、同社は基盤となるインフラストラクチャの管理を望んでいません。これらの要件を満たす手順の組み合わせはどれですか。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: A、B）
AWS Lambda には 1 回の呼び出しあたり最大 15 分という実行時間の上限があり、これは設定で緩和できません。1 枚あたりの処理時間がこの上限を超えるようになった以上、実行時間に制限のないコンピューティング基盤へ処理を移すことが唯一の恒久的な解決策です。同時に「インフラストラクチャを管理したくない」という条件があるため、サーバーレスのコンテナ実行環境である AWS Fargate が適合します。したがって、まずアプリケーションコードをコンテナイメージとしてビルドし Amazon ECR に発行し (選択肢 A)、次に Fargate 互換のタスク定義を作成して、S3 のアップロードイベントで起動される軽量な Lambda 関数から ECS タスクを実行する (選択肢 B) という組み合わせが正解になります。イベント受信は短時間で終わるため Lambda のままで問題なく、重い変換処理だけが時間制限のない Fargate タスクへ移ります。選択肢 C は誤りで、Step Functions の Parallel ステートは複数の分岐を並行実行するだけであり、1 枚の画像処理そのものが 15 分を超える事実は変わりません。プロビジョニング済み同時実行数もコールドスタート対策であってタイムアウトには無関係です。選択肢 D は誤りで、EC2 互換タイプのタスク定義では ECS コンテナインスタンスとして EC2 を自社で用意・パッチ適用・スケーリングする必要があり、インフラを管理したくないという要件に反します。選択肢 E も誤りです。ストレージを EFS に、メタデータを RDS に置き換えても Lambda の 15 分という実行時間上限は変わらず、タイムアウトの根本原因を解消できないうえ、DynamoDB から RDS への移行という不要な変更まで発生します。
共有静的コンテンツと読み取り集中データベースのスケーラビリティ改善
大規模商業施設向けの照明・電力最適化サービスを提供する事業者が、システムを AWS へ移設しました。現在はアプリケーションが Application Load Balancer (ALB) の背後にある 3 台の Amazon EC2 インスタンスで動作し、館内のフロア構成データやセンサー計測値は別の EC2 インスタンス上の PostgreSQL に格納されています。処理の大半は計測値の読み取りと集計です。フロアマップや照明器具の配置図といった静的コンテンツは各 EC2 インスタンスにアタッチされた Amazon Elastic Block Store (Amazon EBS) ボリュームから配信されており、テナント入れ替えや設備更新のたびに全ボリュームへ手作業で同期しています。利用は季節と時間帯で大きく変動し、夏季の日中や年末商戦のピークにはセンサーデータを処理しきれず、分析ではデータベースの読み取りが追いつかないことが判明しました。信頼性とスケーラビリティを高めるうえで最適なソリューションはどれですか。
解説を読む（正解: C）
この構成には、静的コンテンツを各インスタンスのブロックストレージに複製している点と、単一 EC2 上のデータベースが読み取りのボトルネックかつ単一障害点になっている点という 2 つの弱点があります。Amazon EFS は複数のコンピューティングリソースから同時にマウントできる共有ファイルシステムで、複数 AZ に冗長化されて自動的に容量が伸縮するため、コンテンツを 1 箇所に置くだけで全タスクへ即時反映され、手作業の同期が不要になります。アプリケーション本体は ECS on Fargate でコンテナ化し、Application Auto Scaling で需要に応じてタスク数を増減させ、ALB のターゲットグループへ登録すれば、季節変動に自動追随する構成になります。データベースは Aurora PostgreSQL Serverless v2 に移行してライター容量を自動伸縮させつつ、リーダーノードを追加して読み取り集中型の分析処理を分散させることで、ピーク時の読み取り不足と可用性の両方に対応できます。したがって C が正解です。A は Lambda 関数が EBS ボリュームをマウントできないという時点で成立せず、RDS マルチ AZ のスタンバイは通常時に読み取りを処理しないため読み取り不足も解消しません。B は Step Functions を ALB のターゲットに指定できないため成立しません。D は EBS が原則として単一のコンピューティングリソースにアタッチされるブロックストレージであり、Fargate タスク群で共有する用途には適さず、さらに RDS マルチ AZ 配置は可用性向上策であって読み取りスケーリング手段ではないため、判明しているボトルネックを解消できません。
定期実行される短時間バッチ処理の実行基盤選択
ある損害保険会社が、契約データを集計する独自の ETL アプリケーションを Amazon EC2 の Linux インスタンス上で稼働させています。このアプリケーションはベンダーから提供された Linux バイナリで、ソースコードを変更することはできません。処理はステートレスかつシングルスレッドで、約 2 GB のメモリを使用し、CPU 使用率が非常に高くなります。ジョブは 4 時間ごとに起動され、実行時間は最長で 20 分ほどです。ソリューションアーキテクトは、待機時間の費用とサーバー運用の負担を減らすためにアーキテクチャを見直したいと考えています。どの戦略を採用すべきですか。
解説を読む（正解: D）
実行時間が短く、決まった間隔でのみ動く処理をサーバーの常時起動で賄うと、待機時間の費用と OS 運用の負担が無駄になります。AWS Fargate はコンテナイメージを渡すだけでサーバーを管理せずにタスクを実行でき、実行時間に応じた課金となるため、4 時間ごとに最長 20 分だけ動くステートレスな処理に適しています。ソースコードを変更できない Linux バイナリでも、そのままコンテナイメージへ同梱すれば動作し、必要な 2 GB のメモリと CPU もタスク定義で指定できます。起動契機としては Amazon EventBridge のスケジュールルールから Amazon ECS のタスクを直接ターゲットにできるため、別途スケジューラーを運用する必要もありません。AWS Lambda は 1 回の呼び出しが最長 15 分に制限されるため、最長 20 分かかる処理を完走させられません。AWS Batch でも実行自体は可能ですが、AWS Step Functions のステートマシン自体には定期実行を開始する機能がなく、結局 EventBridge などのスケジューラーが別途必要になるうえ、単一の小さなジョブのためにジョブキューやコンピューティング環境を用意するのは過剰です。Amazon EC2 スポットインスタンスは中断される可能性があり、AWS CodeDeploy はアプリケーションのデプロイを担うサービスであって定期実行のスケジューラーではないため、いずれも適切ではありません。