その他AWSサービス
SQS（Simple Queue Service）
SQSは情報の発信元であるプロデューサーと、それを受け取るコンシューマーといったメッセージキューサービスです。
メッセージ:
プロデューサーからコンシューマーへのデータの受け渡しはメッセージを通じて行われます。
キュー:
メッセージが蓄積される場所で、これを利用してシステムの疎結合設計を実現できます。メッセージが蓄積される場所を指して溜め場と呼びます。
ポーリング:
コンシューマーがメッセージを受け取るために要求と受信を繰り返す方法で、受け取るタイミングは受け取り側が制御します。
キューの種類
スタンダードキュー:
メッセージ配信回数は1回以上。
順序が変わる可能性があります。
アプリケーションの設計によってはメッセージが重複する可能性があります。
FIFOキュー:
1回のみメッセージが配信されます。
メッセージの順序が保証されますが、スループットに制限があります。
| 特徴 | スタンダードキュー | FIFOキュー |
|---|---|---|
| メッセージ配信回数 | 1回以上 | 1回のみ |
| メッセージ順序 | 順序が変わる可能性がある | メッセージの順序が保証される |
| スループット制限 | 制限なし | あり（FIFOキューごとに制限がある） |
| メッセージ重複 | アプリケーションの設計により重複する可能性 | 重複しない |
| 使用ケース | 順序が重要でない場合や高いスループットが必要な場合 | メッセージの順序が重要で、順序保証が必要な場合 |
その他の概念
デッドレターキュー (DLQ):
キューが失敗したときに、そのメッセージをDLQに移動させる仕組みです。失敗したメッセージを蓄積することで障害の早期発見が可能です。
遅延キュー、メッセージタイマー:
メッセージがキューに入ってから指定の期間が経過するまで、コンシューマーがそのメッセージを取得できないようにすることができます。
ポーリングの種類:
ショートポーリング:
コンシューマーの要求をすぐにメッセージに返します。
ロングポーリング:
要求があっても一定期間待機があり、メッセージが到着するまで待機します。
SNS（Simple Notification Service）
SNSは発信元であるパブリッシャー（例: EC2、EventBridge）から、受信者であるサブスクライバー（例: Kinesis、Lambda、Mobile Client）に向けてメッセージを効率的に送信するサービスです。
SNSトピック:
SNSメッセージングモデルの中心であり、パブリッシャーがメッセージをトピックに発行し、サブスクライバーがそのトピックからメッセージを受け取ります。このモデルでは、送信者と受信者はお互いに知識を持たず、非常に疎結合です。
Pub/Subメッセージングモデル:
パブリッシャーとサブスクライバーが直接通信するのではなく、中間にトピックを介してメッセージが伝播します。これにより、システムの部品が互いに依存しないような設計が可能となります。
例: CloudWatchアラームの通知:
- CloudWatchアラームが発生した場合、SNSがそのアラームに応じたトピックにメッセージを発行します。
- このメッセージは、メール通知やSlack通知などのサブスクライバーにプッシュベースで配信されます。
- パブリッシャーとサブスクライバーは、アプリケーションやサービスの範囲を超えて疎結合で連携できます。
EventBridge
EventBridgeはサーバーレスのイベントバス型サービスであり、様々なイベントソースからの情報をもとに、状態変化に応じてAWSサービスなどの実行を行うことができるサービスです。
イベントとは？
イベントはJSON形式で表現され、例えばEC2の状態変化などがその中に記載されています。これにより、例えばEC2の起動や停止などのイベントをリアルタイムに検知できます。
https://dev.classmethod.jp/articles/cross-account-delivery-of-eventbridge-event-buts/
イベントバスの種類
AWSサービスのイベント:
AWSの各サービスが発行するイベントを捉え、それに対するターゲットの実行が可能です。
カスタムアプリケーションのイベント:
独自のアプリケーションが発行するイベントをEventBridgeで取り扱えます。
SaaSアプリケーションのイベント:
サードパーティのSaaSアプリケーションが発行するイベントもEventBridgeで統合できます。
アーカイブと再生
EventBridgeは発行されたイベントをアーカイブして保存することができ、過去のイベントを確認したり、特定のルールに基づいて再処理することが可能です。
定期実行
EventBridgeではcron式やrate式を使用して、定期的にイベントを発火させることができます。これにより、定期実行が必要なバッチ処理やリマインダーなどを簡単に実現できます。
Amazon Redshift
Amazon Redshiftはデータウェアハウスサービスであり、主にOLAP（Online Analytical Processing）の用途に特化しています。
OLTP と OLAP
OLTP（Online Transaction Processing）:
主要なビジネスや業務のトランザクション処理を担当します。
例えば、RDSやDynamoDBなどがOLTPに該当し、短く単純なクエリを発行します。
OLAP（Online Analytical Processing）:
Amazon RedshiftやEMRなどがOLAPに該当します。
ビジネスの意思決定など分析用途に利用され、データソースはOLTPから取得します。通常、長大で複雑なクエリを実行します。
https://aws.amazon.com/jp/compare/the-difference-between-olap-and-oltp/
例
Amazon Redshiftでは、RDSからデータをコピーし、そこで分析用のSQLクエリを発行する形式が一般的です。これにより、Quicksightなどの可視化ツールを用いてデータを分析しやすくなります。
Redshift Spectrum
Redshift Spectrumは、S3に直接SQLクエリを実行できる機能です。S3バケット内のデータに対して直接クエリを発行し、大規模で複雑なクエリに対応します。ただし、単純なクエリの場合はAmazon Athenaなどが適しています。
構成要素
リーダーノード:
クライアントからのクエリを受け付け、クエリの最適な実行計画を生成します。
コンピュートノード:
クエリを実際に実行するコンピューティングの部分です。
実際にはEC2で稼働しています。
Amazon Kinesis
Amazon Kinesisは継続的に発生するデータを収集、処理、分析するためのサービスです。主なコンポーネントとしては、Kinesis Data Stream、Kinesis Data Firehose、Kinesis Data Analytics、および Kinesis Video Streams があります。
Kinesis Data Stream
Kinesis Data Streamはデータをリアルタイムで取り込み、24時間から7日間までの間にわたってデータを保存できるサービスです。
プロデューサーとコンシューマー:
データを送信する側をプロデューサー、受信する側をコンシューマーと呼びます。
https://docs.aws.amazon.com/ja_jp/streams/latest/dev/key-concepts.html
Kinesis Data Streamの構成:
- データはKinesis Data Streamエンドポイントに向かって送信されます。
- データはシャードと呼ばれる領域に一時的に保存され、負荷に応じてシャードを増減できます。
^ シャードの集まりをデータストリームと呼びます。
KPL（Kinesis Producer Library）と KCL（Kinesis Client Library）:
- プロデューサー側でKPLを利用してデータの送信を行います。
- コンシューマー側ではKCLを使用してデータを取得し、処理します。
Kinesis Data Firehose
Kinesis Data Firehoseは、データをS3、RedShiftなどの分析ツールに格納するためのサービスです。
データ配信:
エージェントがインストールされた場所からKinesis Data Firehoseエンドポイントへデータが送信されます。
データはKinesis内のデリバリーストリームを通り、ほぼリアルタイムで配信され、60秒以内には目的地に到達します。
Kinesis Data Analytics
Kinesis Data Analyticsは、SQLクエリを使用してリアルタイムでデータを分析するためのサービスです。
Kinesis Video Streams
Kinesis Video Streamsは、ストリーミング動画を処理、分析するためのサービスです。
Amazon API Gateway
Amazon API GatewayはAPIを作成し、管理するためのサービスであり、異なるバックエンドサービス（例: Lambda、ALB、Kinesis）との連携を容易にします。
設計例
API Gatewayを使用してAWSで構築されたREST API通信を行う際、API Gatewayを利用してバックエンドのLambdaやALB、Kinesisなどと連携が可能です。
デプロイタイプ
エッジ最適化APIエンドポイント:
CloudFrontを通じて通信を受けます。
レイテンシーが低くなります。
リージョンAPIエンドポイント:
クライアントから直接API Gatewayを叩きます。
プライベートAPIエンドポイント:
Direct ConnectやVPC内から、またはセキュアな接続が必要な場合に使用します。
リクエストとレスポンス
Method リクエスト:
クライアントのリクエストを受け取り、APIキーの有無を確認できます。
Integration リクエスト:
バックエンドとの接続情報を指定し、データの受け渡し方法などを定義します。
Integration レスポンス:
バックエンドからのレスポンスを受け取り、どのように処理するかを指定します。
Method レスポンス:
最終的にクライアントに返す値やHTTPステータスコードを定義します。
プロキシ統合
プロキシ統合を有効にすると、統合リクエストと統合レスポンスの設定が不要になり、シンプルにAPI Gatewayをバックエンドとして利用できます。
キャッシュ
API Gatewayはエンドポイントからの通信を一時的にキャッシュできます。このキャッシュはAPI Cacheに保持され、ステージを分けて運用することができます。
使用量プランとAPIキー
使用量プラン:
プレミアムプランやスタンダードプランなどがあり、利用シナリオに応じて選択できます。
プレミアムプランでは高品質なサービスを提供するために、レート制限を調整し、スロットリングを設定できます。
APIキー:
利用者を判別するためにAPIキーが使用されます。
レート制限、クォータ、APIステージなどを設定して制限をかけることができます。
スロットリング
リクエスト制限があり、上限を超えると429番エラーになってしまう
それぞれのステージに上限を設定できる
バックアップ戦略
パイロットライト
パイロットライト戦略では、別の環境をバックアップ環境として構築しておきます。障害が発生した際には、スタンバイ環境に手動で切り替えたり、Auroraをプライマリに昇格させたり、EC2を起動させたりすることが求められます。障害が発生してから手動で対応するため、比較的少ないコストで済みます。
ウォームスタンバイ
ウォームスタンバイ戦略では、別の環境に最低限必要なリソースを構築しておきます。環境の切り替えが迅速に行え、すぐにアプリを利用できるようになります。障害が発生した場合、スタンバイ環境に環境を切り替え、データの同期など最低限の作業を行います。リソースが既に存在するため、トラフィックに応じてスケールアウトなども容易です。
アクティブアクティブ
アクティブアクティブ戦略では、複数のアクティブ環境を同時に稼働させます。コストは単純に2倍かかりますが、常に同じ数の台数で稼働しています。障害が発生した場合は、障害に備えた環境にDNSのトラフィックを切り替えるだけで対応できます。障害発生時のダウンタイムが最小限に抑えられますが、コストは高くなります。
Discussion