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 に移行しました。Web 層は Application Load Balancer (ALB) の背後にある 2 台の Amazon EC2 インスタンスで動作し、商品データは別の EC2 インスタンス上でセルフマネージドの MySQL に保存されています。アプリケーションのデータベース利用は圧倒的に読み取りが多く、商品画像などの静的コンテンツは各 EC2 インスタンスにアタッチされた Amazon EBS ボリュームから読み込むため、更新のたびに全ボリュームへコピーする運用が必要です。トラフィックは時間帯で大きく変動し、ピーク時にはリクエストを処理しきれません。トレースの結果、ピーク時の読み取り負荷にデータベースが追随できていないことが判明しました。アプリケーションの信頼性を最も高めるソリューションはどれですか。
解説を読む（正解: C）
この構成には信頼性を損なう要因が 3 つあります。第一に固定 2 台の Web 層がピークを吸収できないこと、第二に静的コンテンツを EBS ボリュームへ複製する運用が整合性と手作業のリスクを生むこと、第三にセルフマネージドの MySQL が単一障害点かつ読み取りのボトルネックになっていることです。正解の選択肢はこの 3 点を同時に解消します。アプリケーションをコンテナ化して Fargate 上の ECS サービスとして動かせば、サーバーの管理を排したうえで Application Auto Scaling により負荷に応じてタスク数を増減できます。静的コンテンツを Amazon EFS に集約すれば、複数のコンテナが同一のファイルシステムを同時にマウントでき、更新のたびに各ボリュームへコピーする必要がなくなり、EFS 自体も複数アベイラビリティーゾーンにデータを保持します。データベースは Aurora MySQL Serverless v2 へ移行しリーダーインスタンスを追加することで、読み取りをリーダーへ分散しつつ容量を自動でスケールでき、ライターに障害が起きてもリーダーへ昇格できます。A は Lambda 関数に EBS ボリュームをアタッチできないため技術的に成立せず、静的コンテンツの共有問題も解決しません。B は Step Functions ステートマシンを ALB のターゲットにできない点で成立しません (ALB のターゲットタイプは instance、ip、lambda のみです)。D は EBS ボリュームを単一のボリュームとして複数の Fargate タスクから共有マウントできないため誤りで、静的コンテンツの共有という中心的な課題が未解決のまま残ります。
レガシー Java アプリのコンテナ化とサーバー管理の排除
精密機器を扱う商社が、自社データセンターの仮想マシン上で Java (Tomcat) 製の受発注管理システムを運用しています。このシステムは営業、購買、物流の各部門が利用し、社内の在庫システムや会計システムとも連携しているため依存関係が複雑です。アプリケーションの動作自体は安定しており、当面は大きな機能追加の予定はありませんが、OS のパッチ適用やハードウェア更改といったサーバー保守の負担をなくしたいと考えています。会社はこのシステムを AWS へ移行し、サーバー管理のオーバーヘッドを最小限にしたいと考えています。コード変更を最小限に抑えながら要件を満たすソリューションはどれですか。
解説を読む（正解: B）
7R の移行戦略のうち、コードをほとんど変更せずに運用負荷を下げたい場合に有効なのがリプラットフォーム、すなわちコンテナ化です。AWS App2Container はオンプレミスや EC2 上で稼働している Java および .NET アプリケーションを分析し、Dockerfile とコンテナイメージ、さらに Amazon ECS や Amazon EKS 向けのデプロイ成果物までを自動生成するツールで、アプリケーションの書き換えをほとんど伴わずにコンテナへ移行できます。正解の選択肢は、App2Container で生成したイメージを Amazon ECR に保存し、AWS Fargate 上の Amazon ECS で実行するため、EC2 インスタンスの構築、パッチ適用、スケーリングといったサーバー保守が完全に不要になります。既存の HTTP ベースのクライアントは Application Load Balancer 経由でこれまでと同じように接続でき、ECS タスク実行ロールに ECR からのイメージ取得を許可するという構成も正しい設計です。Amazon EKS のマネージドノードグループを使う選択肢は、ワーカーノードの OS やアドオンの管理が残るうえ、Kubernetes の運用習熟という新たな負担が生じるため、管理オーバーヘッドを最小にするという要件に反します。アプリケーションを AWS Lambda 上のコンテナとして動かす 2 つの選択肢は、最大 15 分の実行時間やイメージサイズの制約があり、常駐型でステートフルな Tomcat アプリケーションをイベント駆動モデルに合わせて作り替える大幅な改修が必要になるため、コード変更を最小限にするという要件を満たしません。