助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30616
問題を開く
Amazon EC2インスタンス上で実行されるアプリケーションは、ユーザーが利用するスマートフォンから、HTTPベースのインタフェースを通してリアルタイムにデータを受信して処理している。このところ、データ量が増大すると高負荷によりアプリケーションが処理しきれなくなる問題が発生している。
問題を解決し、よりスケーラブルなアプリケーションにするには、どのソリューションが最も適切か。

正解

データの受信にはAmazon Kinesis Data Streamsを利用し、データの処理にはAWS Lambdaを利用する

解説

ストリーミングデータをリアルタイムで収集・処理するサービスに「Amazon Kinesis」があります。ストリーミングデータとは継続的に生成されるデータのことをいいます。例えばスマートフォンアプリなどでユーザーが生成するログや、証券取引所の株取引情報、リアルタイムチャットやオンラインゲームのデータなどが該当します。Kinesisではこのようなストリーミングデータを収集し、サンプリングや分析などの処理を通して、リアルタイムなトレンド情報をユーザーへフィードバックしたり、企業の経営戦略などに繋げることができます。
Kinesis Data Streamsは外部から送信されるストリーミングデータを収集します。センサーなどが生成したストリーミングデータをKinesis Data Streamsのストリームへ送信し、ストリーム上のデータは分析や機械学習などを行うアプリケーションがリアルタイムに読みだして処理します。

収集したデータを分析・加工するには「AWS Lambda」を利用します。Lambdaはサーバーレスでプログラムのコードを実行できるサービスです。サーバーレスとはAmazon EC2などのサーバーを必要とせず、リクエスト発生時にだけプログラムが実行されるアーキテクチャのことです。
LambdaではKinesis Data Streamと連携し、ストリーミングデータを処理できます。Lambda関数の作成時には、Kinesisのストリーミングデータを利用するテンプレートも用意されています。


以上より正解は
・データの受信にはAmazon Kinesis Data Streamsを利用し、データの処理にはAWS Lambdaを利用する
です。

その他の選択肢については以下の通りです。

・Amazon Simple Queue Service(SQS)でデータ受信と処理を行うコンポーネントを接続する。メッセージ取得時は、ロングポーリングで取得する
Amazon SQSはフルマネージドのメッセージキューイングサービスであり、サービス同士の橋渡しを担います。また、ロングポーリングとは、ポーリング(メッセージキューに対する問合せ)した際にメッセージが空である場合は一定時間待ち合わせる設定をいいます。
SQSでコンポーネント間を接続することで、高負荷のために処理しきれなくなるという問題を解消できることはありますが、ロングポーリングはAPIコール数を減らすコスト削減の設定であり、本設問の問題を解消しません。したがって、誤りです。

・データ受信にはAmazon Kinesis Data Firehoseを利用し、データの処理にはAWS Glueを使用する
Kinesis Data FirehoseはストリーミングデータをAmazon S3(ストレージ)、Amazon Redshift(データベース)、Amazon OpenSearch Service(データ分析)などのサービスへ配信するサービスです。
また、AWS Glueはデータ分析向けのETL※サービスです。
※ETL…データのExtract(抽出)・Transform(変換)・Load(書き出し)を意味する用語
Glueは、データ処理をよりスケーラブルにする場合に採用するサービスではありませんので、誤りです。

・データを受信するAmazon Simple Notification Service(SNS)のトピックを作成し、SNSからの通知をトリガーにLambda関数でデータを処理する
Amazon Simple Notification Service(SNS)はプッシュ型のメッセージングサービスです。システムの状態に変化があった際のシステム管理者への通知や不特定多数のユーザーへの定期的なメッセージ配信などを、EメールやSMS(Short Message Service)、Amazon SQS(Simple Queue Service)を通してユーザーやアプリケーションに対して通知します。
SNSは通知を行うサービスであり、本設問のケースのような大量のリアルタイム性の高いデータ処理は、Amazon Kinesis Data Streamsの方が適しているので誤りです。

参考

【Amazon Kinesis】
Amazon Kinesisはストリーミングデータをリアルタイムで収集・処理するサービスです。
ストリーミングデータとは継続的に生成されるデータのことをいいます。例えばスマートフォンアプリなどでユーザーが生成するログや、証券取引所の株取引情報、SNSやオンラインゲームのデータなどの継続的に生成されるデータが該当します。Kinesisではこのようなストリーミングデータを収集し、サンプリングや分析などの処理を通して、リアルタイムなトレンド情報をユーザーへフィードバックしたり、企業の経営戦略などに繋げることができます。なお、ストリーミングデータを処理することを「ストリーム処理」といいます。
また、その他のデータ処理方式に「バッチ処理」があります。バッチ処理はまとまったデータに対して一括で処理を行う方式です。バッチ処理は、日次、週次、月次、年次の集計処理のように特定範囲のデータに対して定期的に実行されます。
多くの企業ではストリーム処理とバッチ処理の両方を用いてシステムを構築し、柔軟なデータ解析を行っています。

【Kinesisの種類】
Kinesisには用途に応じた複数のサービスがあります。

●Kinesis Data Streams
Kinesis Data Streamsは外部から送信されるストリーミングデータを収集するサービスです。センサーなどが生成したストリーミングデータをKinesis Data Streamsのストリームへ送信し、ストリーム上のデータは分析や機械学習などを行うアプリケーションがリアルタイムに読みだして処理します。なお、収集したデータには保持期間(デフォルトで24時間、最長で1年)があります。

なお、Kinesisではストリーミングデータを生成し送信するデバイスやサービスなどを「プロデューサー」、ストリーミングデータを読みだして処理する側を「コンシューマー」と呼びます。

○Kinesis Data Streamsのアーキテクチャ

Kinesis Data Streamsでは、ストリーミングデータを「データレコード」という単位で処理します。データレコードには、データそのものに加えて「パーティションキー」「シーケンス番号」が含まれます。
・パーティションキー ... どのシャード(後述)で処理するかを決めるもの。プロデューサー側で設定する
・シーケンス番号 ... シャードごとに一意の番号。シャード内のデータレコードの順序性が保証される

データレコードは「シャード」に分散され処理されます。シャードは、ストリームで処理できるデータの容量を決めるもので、シャードが多いほど並列処理の数が増えてスループットが上がります。

●Kinesis Data Firehose
Kinesis Data FirehoseはストリーミングデータをAmazon S3(ストレージ)、Amazon Redshift(データベース)、Amazon OpenSearch Service(データ検索・分析)などへ配信するサービスです。Kinesis Data Firehoseはプロデューサーからストリーミングデータを受け取り、必要に応じてLambda関数などを呼び出した後、データ配信先へ送信します。


●Amazon Managed Service for Apache Flink(旧 Kinesis Data Analytics)
Managed Service for Apache Flinkは、Kinesis上のストリーミングデータを処理し、可視化・分析できるサービスです。処理用のテンプレートが用意されていたり、標準SQLのクエリが発行できたり、JavaやPythonなどのプログラミング言語がサポートされているなど、柔軟に処理を組み込むことができます。データをデータベースへ移行することなく処理することで、リアルタイムに結果を得ることができます。


●Kinesis Video Streams
カメラやビデオなどの動画(ビデオストリーム)を取り込むサービスです。取り込んだ動画データはアプリケーションなどによって解析や加工、再生などを行うことができます。

上に戻る

SNSが正解ではない理由

公開日 2023/04/27

問題ID : 30656にてSNSの特徴が
・イベント発生を契機に次の処理へのプッシュ通知を行えます
・メッセージフィルタリング機能がある
・はほぼ無制限にスケーリングできる

上記理由で
・リアルタイムにデータを受信して処理する
・高負荷に対応できる

と考えSNSとLambdaを利用する項目を選択しました。

確認したい内容として
元々SNSはサービスとサービス間を連携し、変更などイベントを通知するサービス。
今回ユーザーとEC2インスタンスの中のアプリとのやり取りになるので、
そもそも採用できるサービスではない、という認識でよいでしょうか。

2023/04/28 11:19

おそらくポイントは「大量」に「リアルタイム性の高いデータ」を処理するというところだと思います。
Amazon Kinesis Data Streamsはリアルタイムの大量データ処理に特化したサービスであるのに対し、Amazon SNSはメッセージング&通知機能でリアルタイム性はあるものの大量のデータ処理が得意というわけではないので、その違いかなと思いました。


コメント

c chmod007

2024/01/08 11:23

問題ID : 30656は、正直宜しくない(参考にならない)問題と思いました。 なぜなら、Amazon Kinesis Data Streamsを使ったとて、障害が解消されるとは、限らないからです。 まぁ、無料で使わせていただいているので、そういう問題もあるだろうなとみています。有料であれば「ふざけるな」ではありますが。

この返信に対して
コメントを記入できます

この投稿に対して返信しませんか?