AWSサービスの機能を調べる（Application Integration）
皆さんは、AWSクラウドが持つ機能を調べるとき、どうしていますか？
また、使おうと考えているサービスの仕様をどのように調べていますか？
私はこのところ、AWSサービスの機能のホントのところを確認するために、AWS公式ホームページの「AWSサービス別資料」で確認を取っています。
（資料には、SlideShare 、PDF 、Youtube があります）
ちまたのインターネットでの技術ネタを調べることも過去多かったのですが、情報の鮮度もありますし、やっぱり本家の情報がしっくりと安心できます！！
今回は、この画面の左にあるカテゴリー分けから「Application Integration」を選んだときに、各資料にはどのような情報が含まれているかを箇条書きにします。（99-99 形式の数字はページを表します）
Application Integrationカテゴリには、メッセージ管理関係の機能が入っています。
Application Integration
●●資料【1_Amazon EventBridge】
7-11Page
概念
14Page
イベントバス:デフォルト/カスタム/パートナーイベント
18Page
イベントバスの使い分け:
各AWSサービス → デフォルトイベント
他のアプリケーション → カスタムイベント
外部SaaS → パートナーイベント
19Page
EventBridgeとCloudWatch Eventsとの違い
・EventBridgeは Amazon CloudWatch Eventsから派生・独立したサービスで、
デフォルトイベントバスはその延長線上にある機能
・カスタムイベントバスやSaaS連携の機能を追加
31Page
カスタムイベント：EventBridgeのPutEvents APIを呼び出し
SaaSイベント ：送信元のSaaSアプリケーションによる
32Page
EventBridgeに直接送信されるイベント：
AWSリソースの状態変化を起点にイベントが発生する。
CloudTrail経由で送信されるイベント ：
ユーザーのAWSリソースに対する操作（＝API呼び出し）を起点にイベントが発生する。
33Page
EventBridgeにイベントを送信するサービスと機能
44-47Page
ルール・ルールのイベントパターン・ルールのスケジュール式（cron式、rate式）
49Page
ターゲットとして指定できるもの
56Page
ターゲットへのアクセス制御：リソースベースポリシー（＝ターゲット側で制御）
→Lambda, SNS, SQS, CloudWatch Logs
58Page
ターゲットへのアクセス制御：IAMポリシー（＝IAM側で制御）
→Lambda, SNS, SQS, CloudWatch Logs以外のサービスをターゲットに指定する場合
59Page
イベントバスのアクセス制御
⇒ 他のアカウント、または、AWS Organizationsにおける同一の組織からの
イベント送信をイベントバスのポリシーで許可する。
62Page： 案1：SaaSのAPIをポーリングする（EC2）
63Page： 案2：SaaSのAPIをポーリングする（Lambda）
64Page： 案3：SaaSのWebhook機能でPushしてもらう
65Page： 案4：EventBridgeのSaaS連携機能の利用 66Page：対応しているSaaSアプリケーション
69-72Page ：SaaSアプリケーションとの連携方法
75Page
クロスアカウント連携：ルールで他アカウントのイベントバスをターゲットに指定
77Page
CloudWatch Alarmのステータス変化がEventBridgeで取得可能に
78Page
ECR(Elastic Container Registry)のイベントが取得可能
79Page
コンテンツベースのフィルタリング
80-82Page
Schema Registry ：EventBridgeでやり取りされる様々なデータのスキーマを、
コンソールからまとめて参照可能
Schema Discovery：SaaSイベントやカスタムイベントがイベントバスに送信されると、
スキーマ情報を自動生成可能になった
Code Bindings ：AWS Toolkit for IntelliJ および Visual Studio Codeを用いてスキーマ定義
を取得可能。スキーマ定義を言語ごとにダウンロード可能。
84Page
Amazon EventBridgeの料金
85Page
Amazon EventBridgeの制限
●●資料【2_AmazonMQ】
メッセージ指向ミドルウェア (MoM)またはメッセージブローカーを置き換える
オープンソースメッセージブローカー向け完全マネージド型サービス
Apache ActiveMQ、RabbitMQ をサポート
●●資料【5_AmazonSQS】
23-24Page
アプリケーション連携、AWSのマネージドサービスの検討
1.ストリーミング/メッセージングの検討：
Amazon Kinesis Amazon Managed Streaming for Kafka Amazon API Gateway
2.同期/非同期方式の検討
3.Push/Pull方式検討： 非同期&Push→AmazonSNS Pull&P2P方式→AmazonSQS
Pull&P2P/PublishSubscribe方式→AmazonMQ
4.P2P/Publish Subscribe方式の検討（処理依頼先1か所？複数？）
Amazon SQSの利用ケース
ケース1 大量リクエストが一時的に発生する場合にキューで受ける
ケース2 アプリケーション間の依存関係を弱めたい場合
ケース3 重い処理が含まれていても素早く応答をしたい場合
ケース4 複数の処理を並列処理したい場合
46Page
配信方法 少なくとも１回の配信（２回以上の配信もあり得る）
・スタンダードキュー：最低1回の配信/順序はベストエフォート
・FIFOキュー：1回のみ配信/順序を保証
47Page
二回以上の配信がある場合の設計とは？
同じメッセージで処理をした場合、何回処理をしても結果が変わらない設計
Dynamo DB等を活用して処理済みであることを判定できる仕組みを導入し重複実行しない設計
47Page
キューのメッセージ取得方法
ショートポーリング方式／ロングポーリング方式
48Page
Amazon SQSでメッセージを取得する際のお作法
１．ポーリング ２．取得＆処理 ３．削除 ★キューに削除指示
54Page
可視性タイムアウトによる処理中のメッセージロック
⇒ スタンダードキューの場合は、可視性タイムアウトはメッセージを2回受信しない保証
にはなりません。
※ 障害ロック発生しても、処理が動くようにできる
55Page
遅延キューとメッセージタイマー
：メッセージをキューに送信してから一定時間後に利用可能になる（プロデューサー側の動き）
①遅延キューはキュー全体に、メッセージタイマーは特定のメッセージに対して
遅延時間を設定するもの
②両方指定された場合はメッセージタイマーの値が優先される
③ メッセージタイマーはFIFOキューは未サポート
56Page
Dead Letter Queue(DLQ)
：メッセージの滞留回避 最大受信数を設定 最大受信数を達した場合、DLQに移動
①FIFOキューで順序が変わることが許容できない場合は利用しない
②無制限に繰り返したい場合は利用しない
57Page サーバサイド暗号化を利用したメッセージの暗号化（AWS KMS）
58Page キューのアクセス制御（IAMポリシー／Amazon SQSポリシー）
59Page メッセージ属性を利用したメタ情報の格納（MAX10）（サーバサイド暗号化の対象外）
60Page キューのモニタリング（CloudWatch）
61Page
Amazon SQS/Amazon Kinesisの使い分け
Amazon Kinesis
⇒ストリーミングデータ（単発メッセージではなく関連する複数メッセージを処理するケース）
⇒①シャード内で順序保証 ②複数のConsumerで同一データを並列処理可能
Amazon SQS（スタンダードキュー／FIFO）
⇒メッセージ消費型。同一メッセージの並列処理には向かない。
64Page
Amazon SQSのご利用料金：1 つのリージョン内におけるAmazonSQSとAmazonEC2間
でのデータ転送は無料
●●資料【6_StepFunctions】
17-19Page
ステートマシンの実行方法 (呼び出し元)
ステートマシンから呼び出し可能な AWS のサービス
Activity ポーリングでStep Functionsを呼び出す ハートビート（Step Functions？APP？）
28Page
7種類の State Type
48-51Page
AWS Step Functions の主な制限
スロットリング – トークンバケットアルゴリズム
AWS Step Functions Local
Amazon Simple Workflow Service (SWF)
