AWS認定学習記録-サーバレス-SQSの概要

AWSが提供するMessage Queueサービスが今回の内容です。

公式ガイド：

Amazon SQS（サーバーレスアプリのためのメッセージキューサービス）| AWS

今回のテーマ：SQSの概要

Amazon Sinple Queue Service(SQS)

AWSが提供するプロセス間通信などのスレッド間通信に使われるコンポーネントで、
制御やデータを伝達するポーリング型キューサービスとなります。

ポーリングとは

複数のプログラム間通信に対し、一定のタイミングの問い合わせがあった場合、送受信処理を行う通信方式となります。 概略図は以下のようになります。

直接通信の場合、受信側がBusyの状態だと処理が滞る可能性があります。

いったん中継所に通信内容を貯めておいて、受信側のタイミングが良いときに受信の通信を行います。

SQS

SQSはキューをため込んでポーリング処理を実施するサービスとなります。
メッセージデータを受信側が受け取るまでの概略図は以下のようになります。

また、SQSの内訳はRequestキューとResponseキューとなり、送受信をキューイングすることができます。
概略図は以下のようになります。

SQSの特徴

フルマネージド型で提供された高可用性/高スケーラビリティ/高スループット/低コストを実現します。
項目としては以下のようなものがあります。

• 複数のサーバー/データ千tナーにメッセージを保持する高可用性構成
• 多数の送信者と受信者に対応可能なスケーラビリティの確保
• メッセージが増加しても高いスループットを維持
• 無料枠と従量課金による低コスト
• 冗長化などの可用性はAWS側のサービスで構成

また、送受信するデータは256KBまでのデータしか利用できず、60秒から14日間メッセージを保持することができます。
項目は以下のようなものがあります。

項目	概要
メッセージサイズ	メッセージの最大サイズは256KB Extended Client Libraryを利用すると2GBまでのメッセージ送受信が可能
メッセージ保持期限	削除されないメッセージはデフォルトで4日間保持 保存期間は60秒から14日間の間で変更可
In Flightメッセージ	1つのキューごとに最大120,000In Flight(受信されたメッセージ&Visibility Timeout内)メッセージ

キューのタイプ

SQSのキューメッセージの処理順序は、以下の2つの方式から選択します。

• 標準キュー(デフォルト)
• FIFO(First in First out)キュー

標準キュー(デフォルト)

標準キューは「順番通りに処理」と「1回だけのメッセージング」をなるべく早く実施する処理となります。

FIFO(First in First out)キュー

最初に入ったキューを最初に処理する順番を守るキューイングを実施する処理となります。

SQSの機能

追加機能を利用することでキューイング処理に工夫することが可能となります。 以下は追加機能の概要となります。

機能名	概要
Short Poling	キューが空の場合、即時リターンを実行
Long Poling	キューが空の場合、タイムアウトまで待ちを継続
デッドレターキュー	ずっと残ったメッセージを別キューに移動し、正常に処理できなかったメッセージを隔離
Visibility timeout	新しいメッセージを指定時間見えなくする

Visibility timeout

Visibility timeoutを設定することで、優先的に処理してほしい受信インスタンスを指定することが可能となります。 概略図は以下のようになります。

今回のテーマは以上です。

AWS認定学習記録-サーバレス-疎結合化の追求

今日から大きな単元の「サーバレス」の学習を進めていきます。

今回のテーマ：疎結合化の追求

概要

5つの設計と11のベストプラクティスの対比よりサーバレスの観点は以下のオレンジ色の箇所となります。

コンポーネントの疎結合

コンポーネント間の相互依存を減らした構成を取ることにより、1つのコンポーネント変更や障害の影響を削減します。
プログラムの考え方だと構造を分ける認識になります。
なお、関連するAWSサービスは以下のようなものがあります。

• Lambda
• SQS
• ELB
• SNS

密結合の問題

密結合した構成は障害や修正に弱く不具合が発生しやすい傾向になります。
以下は密結合の概略図となります。

また、密結合のデメリットは以下ようなものがあります。

• 1インスタンスの障害の影響が全体に影響しやすい
• 1つの修正対応で他インスタンスへの影響を多く考慮しなければならない
• 負荷対応やスケーリングも容易にできない
• システム構成の追加/変更が難しい

疎結合化のメリット

ELBやAPIなどを利用し、結合点を削減したりメッセージ結合にすることで影響を減らすことが可能となります。 以下は疎結合化した場合の概略図となります。

また、疎結合化のメリットとしては以下のようなものがあります。

• 耐障害性が高まる
• 負荷対応やスケーリングが容易
• システム構成の追加/変更が容易

疎結合化のサービス概要

サーバレス化をするサービスやメッセージング処理をするサービスを利用し疎結合化を行います。
以下はAWSサービスとその概要になります。

AWSサービス	概要
ELB	サーバー間のトラフィック調整と連携をELBを起点することで疎結合化を実現する
SQS	SQSのキューイングによる通信でインスタンス間連携を結ぶことで疎結合化を実現
SNS	SNSのアプリケーション間通信でインスタンス間連携を結ぶことで疎結合化を実現
Lambda	サーバーインスタンスではなくLambdaによるトリガー処理を連携することで疎結合化を実現

通信系サービスによる疎結合

サーバー間の連携を直接結んで連携すると密結合となってしまいます。
概略図としては以下のようになります。

そのため、サーバー間の連携をメッセージング処理を結ぶことで疎結合化を実現します。
概略図としては以下のようになります。

疎結合化設計

疎結合化設計にはサーバーレス/キューイング通信/マネージド型サービスの利用を組み合わせて設計を行います。
以下は密結合タイプの設計パターンと疎結合化向けの設計パターンになります。

密結合タイプの設計パターン

• ユーザー認証/管理をバックエンドサーバーで処理
• 通常のEC2インスタンスでアプリケーションを構成
• アプリケーション間で直接通信
• 静的WEBシステムをEC2インスタンスEBSに保存

疎結合化向けの設計パターン

• ユーザー認証/管理をIAMなどのマネージド型サービスを利用
• なるべくLambdaなどサーバレスでアプリケーションを構成
• アプリケーション間はSQSなどMQ(message Queueing)通信で連携
• 静的WEBシステムをVPC外部のS3に保存

今回のテーマは以上です。

AWS認定学習記録-キャッシュの活用-小テスト

キャッシュの活用は、「ElastiCacheの概要/ハンズオン」、「CloudFrontの概要/ハンズオン」の4単元となります。
ハンズオン系の手順まとめは別途執筆します。

今回のテーマ：キャッシュの活用-小テスト

問題1：

ElastiCache for Memcachedの特徴として間違っている内容は何か

回答：

シングルスレッドで動作するインメモリキャッシュDBであり、すべてのデータ操作は排他的である。

解説：

Redisの特徴となります。

問題2：

A社は一部データ処理のキャッシュによる高速化を検討しています。
単純なデータトランザクション処理を行っており、需要の増減に応じてノード追加と削除が必要となります。
Redisとmemcachedのどちらにを選択するべきでしょうか。

回答：

memcachedを選択します。

解説：

シンプルなデータ型でオーケストレーションを利用したい場合はmemcachedを選択します。
Redis 用 Amazon ElastiCache以下のように複雑なトランザクションや分析処理の場合選択します。

• キャッシング
• チャット/メッセージング
• ゲーミングリーダーボード
• 地理空間
• 機械学習
• メディアストリーミング
• キュー
• リアルタイム分析
• セッションストア

問題3：

CloudFrontについて間違っている内容を選択してください。

回答：

リージョナルエッジキャッシュの選択機能が追加された。

解説：

AWS側が管理するサービスとしてキャッシュ機能が追加されましたが、ユーザー側で選択する内容ではありません。

問題4：

CloudFrontの導入方法について正しい内容を選択してください。

回答：

AWS上でWEBシステムを構築していればそのまま利用可能となります。

解説：

既存のAWS上のアーキテクチャに即座に追加することが可能です。

問題5：

CloudFrontの配信設定について間違っている内容を選択してください。

回答：

HTTPプロトコルを利用したWEB配信をする際は、RTMP Distributionを選択する。

解説：

HTTPプロトコルを利用したWEB配信をする際はWEB Distributionを選択します。
また、RTMP Distributionは2020年に廃止されました。

今回のテーマは以上です。

AWS認定学習記録-キャッシュの活用-CloudFrontの概要

ハンズオンは進めず次の単元の学習となります。

今回のテーマ：CloudFrontの概要

概要

CloudFrontとはAWSが提供するCDN(Content Delivery Network)サービスです。
CDNとはWEBコンテンツ配信処理(画像や動画など)を高速化するためのサービスとなります。

導入前後のイメージや導入後のメリットは以下のようになります。

また、大規模なアクセスを世界中にあるエッジのキャパシティを活用し、効率的かつ高速にコンテンツ配信が可能なサービスとなります。
ポイントとしては以下項目などがあります。

• 210以上のエッジロケーションによる高性能な分散配信
• 高いパフォーマンス
• AWS WAF/AWS Certificate Managerとの連携やDDoS対策によるセキュリティ機能
• オリジンに対し、Header/Cookie/Query Stringsによるフォワード指定で、動的なページ配信が可能

アーキテクチャの変化

従来はユーザーに近い位置にあるエッジロケーションから配信するシンプルな構成となります。
概要図は以下のようになります。

現在は、「リージョナルエッジキャッシュ」が追加されより効率的な配信を可能とする構成となります。
概要図は以下のようになります。

グローバルエッジネットワーク

AWSならではのグローバルに配信ネットワークが構築が可能です。

Distribution設定

CloudFrontの配信設定を実施して、各ドメインにて利用します。 ポイントは以下のような項目があります。

• 各配信先となるドメインに割り当てるCloudFrontを設定
• マネージメントコンソールやAPIにより作成
• WEB DistributionとRTMP Distributionを選択
• 使用量が最大40Gbps/100,000RPS超は上限緩和申請が必要
• 独自ドメインの指定可能

設定する際の留意事項は以下のような項目があります。

• コンテンツオリジン設定：CloudFrontの配信ファイルの取得先設定
• アクセス制限：ファイルアクセスの許可設定
• セキュリティ設定：アクセス時にHTTPSの使用の要否
• Cookieまたはクエリ文字列転送設定：オリジンへのCookie/クエリ文字列転送の要否を設定
• 地域制限：特定の国のユーザーからアクセス拒否設定
• アクセスログ設定：アクセスログを作成要否の設定

WEB Distribution/RTMP Distributionの違い

Adobeメディアを利用する場合：RTMPDistribution
通常：WEB Distribution
このように使用判断を行いますが、各々の機能概要を以下に記載します。

WEB Distribution

• 通常のHTTPプロトコルを利用したWEB配信をする際に利用
• HTTP1.0/HTTP1.1/HTTP2に対応
• オリジンはS3バケット/MediaPackageチャンネル/HTTPサーバーを設定
• Apple HTTP Live Streaming(HLS)やMicrosoft Smooth Streamingなど様々な形式のビデオオンデマンド

RTMP Distribution

• RTMP配信形式の際に利用
• Adobe Media Server/Adobe Real-Time Messaging Protocol(RTMP)を使用し、メディアファイルをストリーミング
• S3バケットをオリジン設定
• クライアントはメディアファイル/メディアプレイヤーを使用(JW Player、Flowplayer、Adobe Flash)

Gzip圧縮機能

エッジロケーション側でコンテンツとGzip圧縮し高速で配信が可能です。

キャッシュコントロール機能

キャッシュコントロールによりキャッシュヒット率を上昇させ効率的なキャッシュ活用を可能とします。
ポイントは以下の2項目となります。

パラメーター値の完全一致

• URLとフォワードオプション機能(heade/Cookie/Query String)のパラメータ値の完全一致キャッシュが指定される仕組み
• 単一ファイルのキャッシュは最大20GB
• GET/HEAD/OPTIONリクエストを対象

キャッシュ無効化

• キャッシュが期限切れになる前に無効化することが可能
• 必要のないキャッシュを無効化することで効率的な利用を可能
• コンテンツ毎に最大3,000個まで無効化パスを指定可能
• ワイルドカードを利用し最大15個まで無効化パスリクエストが指定可能

セキュリティ機能

CloudFrontでは様々なセキュリティ設定を行うことで、セキュアなコンテンツ配信が可能となります。
ポイントとしては以下のようなものがあります。

• SSL証明書を設定し、コンテンツ配信時のHTTPS対応
• HTTPS化することによりビューワーとオリジン配信時の暗号化通信が可能
• オリジンカスタムヘッダーによる通信制限が可能
• AWS WAFによるファイアーウォール機能と連携
• AWS WAFを使用することにより、ディストビューションに対するWEBリクエスト許可/拒否が可能
• AWS WAFを使用することにより、Referre制限によるリンク参照禁止も可能
• Amazon S3バケットからの配信の際、OAIとCloudFrontを指すカスタムドメインによってアクセス制限が可能
• AWS ShieldによるDDoS対応が可能(標準で有効化され使用可能)
• 署名付きURL/Cookieによる有効期間を設定
• GEOリストリクションによる地域情報でアクセス判定し制限が可能

CloudFrontの利用設計

キャッシュ対象を決定した上で、キャッシュ時間やセキュリティ制限を設計します。
利用設計時のポイントは以下のようなものがあります。

キャッシュ対象の設定

コンテンツ利用データ分析などを実施し、静的コンテンツ/動的コンテンツへのキャッシュ対象URLを設定します。

TTLの設定

変更が反映されるまでの時間を考慮し、キャッシュ時間(TTL)を決定します。

その他設定

セキュリティ対応などその他設定事項の要否を選定します。(SSL認証の有無/HTTPSの有無など)

今回のテーマは以上です。

AWS認定学習記録-キャッシュの活用-ElastiCacheの概要

今回からは新しい単元の「キャッシュの活用」を進めます。
ハンズオンは動画視聴かかるく操作するため詳細手順は試験終わってから執筆予定です。

今回のテーマ：ElastiCache

概要

AWSの5つの設計原則と11のベストプラクティスに対しElastiCacheを活用する範囲は、以下のようにオレンジ色の範囲となります。

キャッシュの利用

繰り返し取り出すデータやコンテンツについてはキャッシュを利用する構成を活用します。
AWSで使用する関連サービスは以下となります。

• CloudFront
• ElastiCache
• S3

インメモリキャッシュ

インメモリキャッシュは「メモリ＋キャッシュ」の構造を取りElastiCacheで採用されます。

メモリとは

データを保存するHWであり、メモリ型DBを採用することでRead/Writeなどの処理を高速化します。

データを保存するHW

PCなどの機器でデータを保存するためHWはメモリとHDDに保管します。

メモリ型DB

メモリ型DBは、データをメモリ上で動作させるとディスク上で動作する場合を比較し、大幅に高速処理が可能です。
ElastiCacheはメモリ型DBを採用してます。

キャッシュとは

一度アクセスしたデータを保存し、次回アクセス時に高速でアクセスできるようにする仕組みとなります。
データが保管された領域から取得する場合、レイテンシーが増大しDB自身のHW使用量が増加するため、キャッシュを採用します。
動作イメージは以下のようなものになります。

インメモリキャッシュとは

メモリを活用し高速にキャッシュへのアクセスを可能にしたデータベースの仕組みとなります。

ElastiCache

分散インメモリキャッシュサービスの構築・管理及びスケーリングを容易に実施することができるサービスとなります。
要点は以下のようになります。

• キャッシュクラスタを数クリックで起動
• フルマネージド型でモニタリング、自動障害検出、復旧、拡張、パッチ適用、バックアップに対応し高可用性を実現
• 広く利用される2種類のエンジンmemcached/redisから選択可能

Redis/Mencachedの違い

オープンソースのRedisとMemcachedの違いは以下のようになります。
シンプルに利用する場合はMemcachedを採用し、それ以外はRedisを利用することが多いです。
また、RDBへアクセスする際の負荷分散に特化した場合、Memcachedを採用を検討します。

Redis

• 高速に値をRead/Writeできるインメモリ型DB
• シングルスレッドで動作するインメモリキャッシュDBで全てのデータ操作は排他的
• スナップショットが可能
• データを永続化可能
• 複雑なデータ型が必要あり
• インメモリデータセットをソートまたはランク付けが必要あり
• 読込処理の負荷に対し、リードレプリカにレプリケートが必要あり
• pub/sub機能が必要あり(メッセージング処理)
• 自動的なF/Oが必要あり
• キーストアの永続性が必要あり
• バックアップと復元の機能が必要あり
• 複数のデータベースをサポートする必要あり

Menchached

• 高速に値をRead/Writeできるインメモリキャッシュ型DB
• マルチスレッドで動作するインメモリキャッシュDB
• スナップショットは不可
• データを永続化不可
• フェイルオーバーや復元は不可
• シンプルなデータ側が必要あり
• 複数のコアまたはスレッドを持つ大きなノードを実行する必要あり
• システムでの需要増減に応じ、スケールイン/アウトする機能が必要あり
• データベースなどのオブジェクトキャッシュが必要あり
• キーストアの永続性は必要なし
• バックアップと復元機能は必要なし
• 複数のデータベースを利用不可

ElastiCache with Redis

位置情報クエリ/Luaスクリプトによる操作やpub/subモデルを活用可能となります。

Lua(ルア)スクリプト

• 移植性が高く、高速な実行速度などの特徴があるスクリプト言語

位置情報クエリ

• 緯度・経度などの位置情報をクエリ処理することが可能
• 検索距離や検索範囲の指定可能

pub/subモデルの利用

• イベントを起こす側：pubとイベント処理を行う側：subを分離するモデル
• メッセージ処理やイベント処理で活用

ユースケース

データアクセスを高速にしたいケースがあればキャッシュの活用を検討します。
検討項目として下記のようなものが挙げられます。

• セッション管理
• IoT処理とストリーム分析
• メタデータ蓄積
• ソーシャルメディアのデータ処理/分析
• pub/sub処理
• DBキャッシュ処理

検討例としては以下のようなものがあります。

また、アプリケーションでデータの即時反映が必要なケースで活用します。
検討項目として下記のようなものが挙げられます。

• ユーザーのマッチング処理
• レコメンデーションの結果処理
• 画像データの高速表示
• ゲームイベント終了時のランキング表示

ユースケース(基本構成)

ElastiCacheを活用したシンプルなアーキテクチャは以下のようになります。

ユースケース(キャットアプリ)

ElastiCacheのpub/sub機能を活用したキャットアプリを構成する場合は以下のようになります。

今回のテーマは以上です。

AWS認定学習記録-データベース-小テスト

先に単元の小テストを実施します。

今回のテーマ：データベース-小テスト

設問1：

次のAWSデータベース・ストレージサービスのうちで、
データレイクを構築する際にデータ蓄積用に利用すべきサービスを選択してください。

回答：

S3

解説：

• データを大量に蓄積する際はS3を中核にしデータレーク構成を構築
• 大量アクセスが必要なデータはDynamoDBなどのデータベースが必要

設問2：

A社はAWSを利用して高速のデータ検索機能を構築していきたいと考えています。
どのデータベースを選択するべきでしょうか。

回答：

Elasticsearch

解説：

• Elasticsearchはデータ検索専用で優れたデータベースソフト

設問3：

B社はアプリケーションサービスの中で、
1つの情報から関連する情報をマッピング表示させることで、
情報を関連付けて表示させるサービスを検討しています。
どのデータベースを選択すれば良いでしょうか。

回答：

Neputune

解説：

• NeputuneはグラフDBを提供し、グラフDBを利用すればデータ間のマッピングによる検索処理が可能

設問4：

C社はIoTデータをKinesisでストリーム処理した後に、
ビッグデータ解析用向けのデータとして蓄積したいと考えています。
どのデータベースにデータを蓄積すれば良いか選択してください。

回答：

DynamoDB

解説：

• ビッグデータ解析を目的とした場合に高速処理が可能なDynamoDBに予めデータを保持が効率的

設問5：

D社はゲームシステムの高速トランザクション処理を実現したいと考えています。
ゲームに係るリアルタイム処理データをどのデータベースサービスを利用して処理するべきか選択してください。

回答：

ElastiCache

解説：

• 高速にリアルタイム処理が必要な場合はElastiCacheなどのインメモリキャッシュを利用してデータ処理を高速化

設問6：

E社は社内システムのAWSへの移行を計画しています。
E社のシステムはグローバルに利用されており大規模な業務システムに対してSQL型のRDBを利用しています。
移行におけるデータベース選択として間違っているものを選択してください。

回答：

RDSを利用し、既に利用しているMySQLを使ってすぐに移行を実施する。

解説：

• 現行システムが同じMySQLを使用中でもRDSとのGAP分析や検討が必要

設問7：

DynamoDBのデータ整合性モデルの正しいものを選択してください。

回答：

Read処理は強い整合モデルも可能

解説：

• デフォルトは結果整合性モデルですが、オプション機能で強い整合性モデルも利用可能

設問8：

DynamoDBの設定で正しい内容を選択してください。

回答：

利用負荷があらかじめ予測できる場合、プロビジョンドスループットを選択する。

解説：

• 利用負荷があらかじめ予測できる場合はプロビジョンドスループットを選択することが最適

設問9：

次のうちDynamoDBを利用すべきではないユースケースを選択してください。

回答：

銀行の振込処理

解説：

• DynamoDBはJOIN／TRANSACTION／COMMIT／ROLLBACKが必要な複雑な処理には不向き

設問10：

DynamoDBによるクロスリージョンレプリケーションについて正しい内容を選択してください。

回答：

DynamoDB Streamsを有効化する必要がある。

解説：

• クロスリージョンレプリケーションを利用する際は、DynamoDB Streamsを有効化

設問11：

次のうちDynamoDB Streamsについて間違っている内容を選択してください。

回答：

シリアライズされた順番通りに必ず実行される

解説：

• 特定のハッシュキーに基づいた変更は正しい順番で保存
• ハッシュキーが異なる場合は受信した順番が前後する可能性あり

設問12：

DynamoDBにおいてデータにインデックスを付けたいケースにおいて、
次のうち正しい内容を選択してください。

回答：

GSIはハッシュキーテーブルおよび複合キーテーブルのどちらにも設定可能である。

解説：

• GSIはハッシュキーテーブルおよび複合キーテーブルのどちらでも設定可能

設問13：

DynamoDBの設定手順として正しい内容を選択してください。

回答：

テーブル作成→項目→属性の順に設定する。

解説：

• テーブル作成→項目→属性と設定

設問14：

DynamoDB Accelerator(DAX)について正しい内容を選択してください。

回答：

マルチAZのDAXクラスターは1秒間に数百万件のリクエストを処理できる。

解説：

• インメモリ型のキャッシュ高速化を実現
• DAXクラスターは1秒間に数百万件のリクエストを処理可能

設問15：

次のうちAuroraについて正しい内容を選択してください。

回答：

マルチAZに跨って仮想ボリュームを構成している

解説：

• Auroraは標準的な構成でマルチAZに跨って仮想ボリュームを構成

設問16：

次のうちAuroraの特徴について間違っている内容を選択してください。

回答：

最大5台のリードレプリカを利用した高速読込が可能

解説：

• 最大15台のリードレプリカを利用した高速読込が可能

設問17：

次のうちAuroraの特徴について間違っている内容を選択してください。

回答：

レプリカはマルチAZに読込専用のみを作成

解説：

• マルチマスター機能によって別AZにWriteのレプリカを生成

設問18：

EFSについて間違っているものを選択してください。

回答：

EFSへのEC2インスタンスからのアクセス制御はマウントターゲットによって設定

解説：

• EFSへのEC2インスタンスからマウントターゲットを通ってアクセス
• アクセス制御はSGによって実施

設問19：

次のうちKinesisの特徴として間違っている内容を選択してください。

回答：

Amazon Kinesis Data Firehoseはストリームデータを蓄積

解説：

• Amazon Kinesis Data Firehoseはデータ蓄積に向けてS3などに対しデータ変換や配信を行う

設問20：

Amazon Kinesis Data Analyticsの利用方法について間違っている内容を選択してください。

回答：

東京リージョンで利用不可

解説：

• 2019年5月より東京リージョンでも利用可能

今回のテーマは以上です。

AWS認定学習記録-データベース-Kinesisの概要

机上カリキュラムはこの回と小テストがデータベース編の残りとなります。

今回のテーマ：Kinesisの概要

概要

Kinesisはストリームデータを収集・処理するためのフルマネージドサービスで主に3つのサービスで構成されます。

Amazon Kinesis Data Streams

ストリームデータを処理するアプリケーションを構築するサービスとなります。
概略図は以下のようになります。

ストリーミング処理はシャードという単位で分散させ実行するため高速処理が可能となります。
また、shardにインスタンスを割りあえてを行い処理を実行させます。
概略図は以下のようになります。

Kinesis Streamsのデータ提供側(プロデゥーサー)とデータ利用側(コンシューマー)に様々なサービスが利用可能となります。 概略図は以下のようになります。

Kinesis Streamsは以下の関連機能を活用しストリーミング処理アプリケーションを構築します。

サービス名	概要
Amazon Kinesis Agent	Kinesisサービスにデータを収集し取り込むOSSのスタンドアロンJavaアプリケーション
Amazon Kinesis Producer Library(KPL)	Kinesis Streamsにデータを送信するOSSの補助ライブラリ
Fluent plugin for Amazon Kinesis	Kinesis StreamsとKinesis Firehoseにイベントを送信するOSSのFluentd出力プラグインでログ収集を実施する
Amazon Kinesis Data Generator(KDG)	Kinesis Data Generator(KDG)を利用しKinesis StreamsまたはKinesis Firehoseにテストデータを送信する
Amazon Kinesis Client Library(KCL)	KCLを利用しKinesisアプリケーションを作成する。OSSのクライアントライブラリで、EC2インスタンスなどにデプロイし利用する。

Amazon Kinesis Data Firehose

ストリームデータをS3やRedshiftなどへ簡単に配信します。
また、各種DBに配信・蓄積するための処理を実施し、Lambdaと連携するとETLとしても機能します。
概略図は以下のようになります。

Amazon Kinesis Data Analytics

ストリームデータを標準的なSQLクエリでリアルタイムに可視化・分析します。 概略図は以下のようになります。

今回のテーマは以上です。