288-AWS SAP AWS 「理論・実践・一問道場」S3+SQS

type

status

date

slug

summary

理論

「オーバーレイ（overlay）」とは、ある画像やコンテンツの上に別の情報を重ねて表示することを指します。通常、元のコンテンツはそのまま残し、その上に新たな情報やデザイン要素を追加します。オーバーレイは、グラフィックデザイン、ビデオ編集、ウェブ開発、アプリケーションのUIなどでよく使用されます。

例えば、画像にテキストをオーバーレイすると、元の画像の上に文字が表示されます。また、ビデオに字幕をオーバーレイすることで、動画の上に字幕が重ねられ、視聴者に情報を伝えることができます。

主な利用例：

画像編集: 画像にテキストや図形を重ねて追加する。

動画編集: 動画の上にテキストやグラフィックを表示する。

ウェブデザイン: 背景画像の上にボタンやメニューを重ねて表示する。

オーバーレイを使うことで、視覚的に情報を強調したり、デザインに深みを与えることができます。

AWS における画像処理システム設計のベストプラクティス

AWS で画像処理システムを構築する場合、スケーラブルで効率的なアーキテクチャを設計することが重要です。以下では、画像のアップロード、処理、配信に関連する主要なサービスとその組み合わせを紹介します。

1. Amazon S3 (Simple Storage Service)

用途: 画像やその他の大容量データを保存するためのストレージサービスです。S3 は高い可用性と耐久性を提供し、画像ファイルの保存に最適です。

利点: オブジェクトストレージとして、データの大容量保存に適しており、アクセスが高頻度でもパフォーマンスが安定しています。

2. Amazon SQS (Simple Queue Service)

用途: 非同期処理を行う際に使用するメッセージキューサービスです。画像がアップロードされると、S3 バケットのイベント通知を受けて、SQS キューにメッセージが送信され、そのメッセージを EC2 インスタンスがポーリングして処理を行います。

利点: 高スケーラビリティ、耐障害性、バックログ処理に強みを持ちます。SQS を利用することで、処理の負荷を分散させ、システム全体の可用性を高めることができます。

3. Amazon EC2 (Elastic Compute Cloud)

用途: メッセージキューから画像処理のタスクを取得し、実際の処理を行うインスタンス群です。EC2 インスタンスは、スケールアウトやスケールインが可能で、負荷に応じて動的に調整できます。

利点: EC2 は柔軟なコンピューティング能力を提供し、特定の画像処理に適したインスタンスタイプを選択することができます。

4. Amazon CloudFront

用途: 高速なコンテンツ配信ネットワーク (CDN) サービスです。処理済み画像を世界中のユーザーに低遅延で配信するために使用します。

利点: グローバルなエッジロケーションを活用し、画像の配信を高速化することができ、ウェブサイトのパフォーマンスが向上します。

5. スケーリングのベストプラクティス

自動スケーリング: AWS では、CloudWatch メトリクスを基にして、処理リソースを動的にスケールアウトまたはスケールインできます。例えば、SQS キューの深さや EC2 の CPU 使用率を監視して、必要に応じて EC2 インスタンスの数を調整することで、コスト効率を保ちながら負荷に対応できます。

コンテナ化 (Amazon ECS / EKS): 複数の EC2 インスタンスを管理する代わりに、Amazon ECS や EKS を使ってコンテナ化されたアプリケーションをスケールする方法もあります。これにより、より効率的にリソースを管理できます。

6. イベント駆動型アーキテクチャ

S3 イベント通知: S3 に画像がアップロードされると、S3 イベント通知を利用して、画像の処理フローをトリガーできます。これにより、リアルタイムでの処理が可能となり、効率的なシステム設計が可能です。

Lambda を使った自動化: 小規模な処理であれば、AWS Lambda を使ってサーバーレスで画像処理を行うこともできます。Lambda はイベント駆動型で、自動的にスケールし、処理完了後の結果を別の S3 バケットに保存することができます。

7. データベースとメタデータ管理

DynamoDB: 画像に関連するメタデータ（例: アップロード日時、処理ステータス、ユーザー情報など）を管理するために DynamoDB を使用することができます。DynamoDB は高速でスケーラブルな NoSQL データベースであり、リアルタイムなデータの読み書きが可能です。

結論

AWS での画像処理システムの設計は、スケーラビリティ、耐障害性、パフォーマンスに重点を置いたアーキテクチャを構築することが重要です。Amazon S3 と SQS を使った非同期処理、EC2 や Lambda を使ったコンピューティング処理、CloudFront を利用したコンテンツ配信など、AWS の各サービスを適切に組み合わせることで、効率的でスケーラブルなシステムを実現できます。

実践

略

一問道場

質問 #288

ある企業が、ユーザーがランダムな写真をアップロードし、検索できるウェブベースの画像サービスを構築しています。ピーク時には、最大10,000人のユーザーが世界中から画像をアップロードする予定です。その後、ユーザーはアップロードされた画像にテキストをオーバーレイし、その画像を企業のウェブサイトに公開します。

ソリューションアーキテクトは、どの設計を実装すべきですか？

A. アップロードされた画像をAmazon Elastic File System（Amazon EFS）に保存します。各画像に関するアプリケーションのログ情報をAmazon CloudWatch Logsに送信します。CloudWatch Logsを使用して処理が必要な画像を特定するAmazon EC2インスタンスのフリートを作成します。処理された画像は、Amazon EFS内の別のディレクトリに配置します。Amazon CloudFrontを有効にし、そのオリジンをEC2インスタンスの1つに設定します。

B. アップロードされた画像をAmazon S3バケットに保存し、S3バケットのイベント通知を設定して、メッセージをAmazon Simple Notification Service（Amazon SNS）に送信します。SNSからメッセージを取得して画像を処理するAmazon EC2インスタンスのフリートを、アプリケーションロードバランサー（ALB）の背後に作成します。処理後の画像をAmazon Elastic File System（Amazon EFS）に保存します。SNSメッセージのボリュームに対してCloudWatchメトリクスを使用し、EC2インスタンスをスケールアウトします。Amazon CloudFrontを有効にし、そのオリジンをALBに設定します。

C. アップロードされた画像をAmazon S3バケットに保存し、S3バケットのイベント通知を設定して、Amazon Simple Queue Service（Amazon SQS）キューにメッセージを送信します。SQSキューからメッセージを取得して画像を処理し、別のS3バケットに配置するAmazon EC2インスタンスのフリートを作成します。キューの深さに対してCloudWatchメトリクスを使用してEC2インスタンスをスケールアウトします。Amazon CloudFrontを有効にし、そのオリジンを処理された画像を含むS3バケットに設定します。

D. アップロードされた画像を、Amazon EC2 Spotインスタンスのフリートにマウントされた共有Amazon Elastic Block Store（Amazon EBS）ボリュームに保存します。各アップロード画像とその処理状況に関する情報を含むAmazon DynamoDBテーブルを作成します。Amazon EventBridgeルールを使用してEC2インスタンスをスケールアウトします。Amazon CloudFrontを有効にし、そのオリジンをEC2インスタンスのフリートの前に配置されたElastic Load Balancerに設定します。

解説

この問題では、画像のアップロード、処理、公開のプロセスを効率化するために、AWSのサービスを適切に組み合わせてスケーラブルで高性能なアーキテクチャを構築する方法を選択する必要があります。

選択肢ごとの解説:

A. Amazon EFS と CloudWatch Logs を使用

問題点: Amazon EFS はファイルシステムのため、主にストレージとして使用されますが、画像処理においてはあまりスケーラブルで効率的ではありません。また、CloudWatch Logs を使って画像処理をトリガーするのは不適切です。

評価: このアーキテクチャは、スケーラビリティや効率の観点から最適ではなく、特に画像処理のために EC2 インスタンスをトリガーする方法としては不十分です。

B. Amazon S3 と Amazon SNS を使用

問題点: S3 バケットでアップロードされた画像を SNS に通知し、その後 EC2 インスタンスで画像を処理するというアーキテクチャは、確かにスケーラブルではありますが、処理後の画像を EFS に保存するという点が効率的ではありません。EFS は通常、複数の EC2 インスタンスからアクセスするためのファイルシステムに適していますが、画像データに関しては S3 の方がより適切です。

評価: SNS を使って処理フローをスケールする設計自体は良いものの、S3 に保存された画像を EFS に保存することには改善の余地があります。

C. Amazon S3 と Amazon SQS を使用

正解: S3 は画像の保存に最適で、SQS を使用して処理のトリガーを効率的に管理できます。また、EC2 インスタンスが SQS キューからメッセージを取得して画像を処理し、処理された画像を別の S3 バケットに格納するのは、分散システムにおいて効率的でスケーラブルな方法です。さらに、CloudFront を使って処理後の画像を配信することで、パフォーマンスが向上します。

評価: S3 + SQS の組み合わせは非常にスケーラブルで、AWS のサービスを効果的に利用したアーキテクチャです。特に、画像処理の際に EC2 インスタンスをスケールアウトするために CloudWatch メトリクスを使用できる点も優れています。

D. Amazon EBS と DynamoDB を使用

問題点: EBS はブロックストレージであり、EC2 インスタンスにマウントして使用するため、大規模なストレージ処理には不向きです。画像のような大容量データを扱うには、Amazon S3 の方が適しています。また、DynamoDB で処理状況を管理する点も過剰な実装になります。

評価: EBS はスケーラビリティの観点で効果的ではなく、画像処理における最適な選択肢ではありません。

結論:

C の選択肢が最適です。Amazon S3 を使った画像の保存、Amazon SQS を使った非同期処理、そして CloudFront による高速なコンテンツ配信が、スケーラブルで高パフォーマンスなソリューションを提供します。