080-AWS SAP AWS 「理論・実践・一問道場」Kinesis+Lambda+DynamoDB

type

status

date

slug

summary

理論

1. スケーラビリティの確保

スケーラブルなアーキテクチャの構築は、負荷が増加した場合にも安定してシステムを運用するための重要な要素です。AWSでは、Amazon KinesisやAmazon DynamoDBなどのサービスが高いスケーラビリティを提供し、システムの成長に伴うデータ処理能力を効率的に拡張できます。

Kinesis Data Streamsはリアルタイムで大量のデータをストリーム形式で処理するため、IoTプラットフォームのように継続的にデータが流入するシステムに適しています。

Amazon DynamoDBは、特に大量のデータを扱う場合に最適なNoSQLデータベースです。スケーラビリティが高く、運用面での負荷が少ないため、トランザクション型のRDS MySQLに比べて、可用性と拡張性に優れています。

2. サーバーレスアーキテクチャ

AWS Lambdaなどのサーバーレス技術を活用することで、インフラの管理を最小限に抑え、必要なときにだけリソースを自動的にスケールさせることができます。これにより、コストの最適化が図れ、システムの負荷に応じて柔軟にリソースを調整できます。

AWS Lambdaは、イベント駆動型で処理を実行するため、Kinesisのデータストリームからイベントを受け取り、リアルタイムでデータ処理を行うことが可能です。

3. データ処理とストレージ

データベース選定がシステムの性能やスケーラビリティに直接影響を与えるため、ユースケースに合ったデータストレージと処理方法を選ぶことが重要です。

Amazon RDS MySQLなどのリレーショナルデータベースは、トランザクション管理や複雑なクエリに強みがありますが、スケールが求められる場合にはパフォーマンスに限界があります。
Amazon DynamoDBは、NoSQLデータベースとして、フラットなデータ構造や大量のデータを高速に読み書きできるため、大量データを効率よく処理する場合に最適です。

4. コスト効率と運用負荷の最適化

サーバーレスアーキテクチャやオートスケーリング機能（例えば、Kinesis、Lambda）は、リソースの使用量に応じて自動でスケールアップ・ダウンが可能なため、必要なときにのみリソースを消費し、コストを抑えることができます。

自動スケーリングや**コンテナサービス（Amazon ECS、EKS）**の活用は、インフラの運用負荷を削減し、コスト効率を高める手段です。

これらの知識を基に、IoTプラットフォームのようなデータ量の急激な増加に対応するためには、スケーラビリティと柔軟なデータ処理を可能にするアーキテクチャの選定が鍵となります。

この図は、Amazon Kinesis Data Analytics Studio を中心としたリアルタイムデータ分析の仕組みを表しています。以下に、主要な要素とデータの流れを説明します：

1. Amazon Kinesis Data Analytics Studio

データをリアルタイムで分析するためのプラットフォーム。

ユーザーは SQL、Python、Scala を使ってデータを分析可能。

Webクライアント からノートブック形式で操作し、結果を確認します。

2. データの流れ

データの入力元（Streaming Sources）

Amazon Kinesis Data Streams: ストリームデータをリアルタイムで送信。

Amazon Managed Streaming for Apache Kafka: Kafkaを利用したデータソース。

データの分析

データは Amazon Kinesis Data Analytics に送られ、リアルタイム分析が行われます。

AWS Glue Data Catalog を利用してデータスキーマ（データ構造）を管理し、分析を容易にします。

データの出力先（Streaming Destinations）

分析結果は再び Amazon Kinesis Data Streams または Amazon Managed Streaming for Apache Kafka に送られます。

このデータは、次のアプリケーションやシステムで利用されます。

3. 目的

この仕組みは、リアルタイムデータの処理や分析を効率化し、即座に価値のある洞察を得るために設計されています。例えば、IoTデバイスのデータ処理、ログ解析、フィナンシャルデータのリアルタイム分析などに活用されます。

まとめ

図の全体像を簡単に言うと、リアルタイムデータを収集（データストリーム）、分析（Kinesis Data Analytics）、活用（出力先）する一連のプロセスを示しています。

Kinesis

以下の表に、Amazon Kinesis Data Streams と Amazon Kinesis Data Firehose の違いを整理しました。

項目	Amazon Kinesis Data Streams	Amazon Kinesis Data Firehose
主な用途	リアルタイムデータ処理やストリーミングアプリケーション向け	バッチ処理やデータ配信向け
リアルタイム性	高い（低遅延でデータを処理）	比較的低い（バッファリング後に配信）
データ保持期間	最長 7日間（デフォルトは24時間）	データ保持なし、処理後すぐに送信
ターゲット（送信先）	任意のコンシューマーアプリケーション、Kinesis Data Analyticsなど	S3、Redshift、Elasticsearch、Splunkなど、あらかじめ定義された宛先
データ処理	アプリケーションでカスタム処理可能	簡単な事前処理（Lambdaによる変換、圧縮）が可能
バッファリング	なし（データが即時処理される）	データを一定間隔またはサイズでバッファリングして送信
ユースケース例	ログ解析、IoTデータ処理、リアルタイムモニタリング	データウェアハウスへのロード、アーカイブデータの保存

ポイントまとめ

Kinesis Data Streams はリアルタイム性と柔軟なデータ処理が求められる場合に最適。

Kinesis Data Firehose はシンプルなデータ配信やバッチ処理を求める場合に最適。

どちらを使用するかは、リアルタイム性の要件や送信先の形式によって選ぶと良いです！

実践

一問道場

ある企業がAWS上でIoTプラットフォームを運用しています。さまざまな場所に設置されたIoTセンサーが、同社のNode.js APIサーバー（Amazon EC2インスタンスで、Application Load Balancerの背後に配置）にデータを送信し、そのデータはAmazon RDS MySQL DBインスタンス（4TBのGeneral Purpose SSDボリュームを使用）に保存されています。センサーの数は増加しており、今後も大幅に増加する見込みです。APIサーバーは常にオーバーロードしており、RDSのメトリクスは高い書き込みレイテンシーを示しています。

次のうち、プラットフォームを効率的にコスト管理しながら成長させ、新たなセンサーが導入されても問題を永続的に解決できる手段として適切なものはどれですか？（2つ選んでください。）

A. MySQLのGeneral Purpose SSDストレージを6TBにサイズ変更して、ボリュームのIOPSを改善する。

B. データベース層をRDS MySQL DBインスタンスからAmazon Auroraに変更し、リードレプリカを追加する。

C. Amazon Kinesis Data StreamsとAWS Lambdaを活用して、生データの取り込みと処理を行う。

D. AWS X-Rayを使用してアプリケーションの問題を分析・デバッグし、負荷に対応するためにAPIサーバーを追加する。

E. データベース層をRDS MySQL DBインスタンスからAmazon DynamoDBに変更する。

解説

選択肢 C と E の組み合わせを正解と考える理由について

C. Amazon Kinesis Data StreamsとAWS Lambdaを活用して、生データの取り込みと処理を行う。

理由: Amazon Kinesis Data Streamsは、リアルタイムで大量のデータを取り込むために使用され、AWS Lambdaを組み合わせることで、データ処理をサーバーレスで行うことができます。これにより、IoTセンサーから送られる膨大なデータの取り込みと処理を効率的にスケールさせることができ、APIサーバーやデータベースの負荷を軽減できます。特に、データ処理のスピードやスケーラビリティを向上させることができるため、成長するセンサー数にも対応可能です。

E. データベース層をAmazon DynamoDBに変更し、RDS MySQL DBインスタンスを置き換える。

理由: RDS MySQLは、トランザクション型のデータベースには限界がありますが、Amazon DynamoDBはNoSQL型のデータベースであり、非常に高いスケーラビリティを提供します。これにより、センサーから送られる大量のデータを効率的に扱うことができ、スケールの問題が解決されます。特に、IoTデータのようにアクセスパターンが予測できない場合には、DynamoDBは優れた選択肢です。

これらの選択肢は、以下の理由から適切です。

Kinesis と Lambda を活用することで、データのリアルタイム処理が可能となり、システム全体のパフォーマンスを最適化できます。

DynamoDB を利用することで、NoSQLの特性を活かし、スケーラビリティを確保し、RDS MySQLのスケーリング制限を回避できます。

まとめ：

C と E の組み合わせが、プラットフォームを効率的にスケールさせ、成長に合わせて柔軟に対応できるため、正しい選択肢と言えます。