Hello!! Amazon SQS

1.4K Views

January 27, 24

スライド概要

profile-image

name: - いけだしんのすけ work: - インフラ・情シス like: - バイク - 読書 - 映画 - アニメ - ゲーム

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

Hello!! Amazon SQS

2.

自己紹介 name: いけだしんのすけ X: @orc_jj like: - バイク - 読書 - 映画 - アニメ - ゲーム work: - インフラ ・ SRE 🐣 certification: - AWS Solutions Architect Associate - Azure Solutions Architect Expert - Azure Administrator Associate - Azure Developer Associate 好きなAWSサービス AWS CDK

3.

キューを使ったメッセージング コンポーネント間の結合を弱める事で影響範囲を限定的にし、柔軟な アーキテクチャとするためにはコネクターとなるものが必要。 コンポーネント1 コンポーネント1 コンポーネント2 コンポーネント2 コンポーネント間の コネクターが 必要 影響範囲 コンポーネント3 コンポーネント3 コンポーネント4 影響範囲 コンポーネント4 キューを使ったメッ セージングサービス の仕組みが疎結合の 役割を果たす。

4.

非同期処理の構成 プロデューサー プロデューサー アプリケーションA アプリケーションA キューがサービス 停止すること は...? アプリケーションAがキュー にメッセージを送信 メッセージ メッセージ メッセージをキューイング キューのメッセージを取得 して処理を実行 アプリケーションB コンシューマ 今は無理。後でやります。 アプリケーションB コンシューマ

5.

Amazon Simple Queue Service の特徴 ● 高可用性 ○ 複数のデータセンター・サーバーに全メッセージを重複して保持する 「分散キュー」 ● スケーラブル ○ 標準キューでは1秒あたりほぼ無制限のTPSをサポート ○ FIFOキューではバッチ処理なしで1秒あたり300メッセージをサポート ● フルマネージドで従量課金性 ○ 無料枠 + 従量課金 ● メッセージ ○ 最大256KBまで (text, xml, json …)

6.

去年の年末に、あるある課題に遭遇 地元の友だち達とLINEメッセージで約束 してたけど、約束を忘れてる人多いな... リマインドして上げたほうが良いんだろう けど自分自身も忘れているからなあ... リマインダーをつくってあげよう! • ランニングコストは安くしたい。 • もしリマインドが失敗した場合のリトライはちゃんとしたい。 • 早く作りたい。

7.

僕たちにはSQSがあるじゃないか!

8.

作ってみた 1️⃣ WebHookAPIはコンテナ化 ※もともとECSで動かそうとしていたものを Web Adapter機能を使いLambdaで利用。 自然言語からリマインダーの登録できるよう に。 2️⃣ LINEのLIFF画面から登録済みタスクを確 認・削除できるようにAPI GW → Dynamo → GET・DELETE 2️⃣ 3️⃣ Event Bridgeは1分毎のCron式。 1️⃣ 4️⃣ リマインドするデータをクエリ→SQSへ。 5️⃣ SQSをポーリングしてLINEのプッ シュメッセージ送信 6️⃣ リトライが設定回数超過したら DLQへ移動 3️⃣ 4️⃣ 5️⃣ 6️⃣ 7️⃣ 7️⃣ DLQにメッセージが入ったら CloudWatchAram → Slackに連絡

9.

標準/FIFOの違い スループット 標準キュー FIFOキュー ほぼ無制限 1秒あたり最大 300件の送信、受信、削除を サポート (デフォルト・バッチ処理なしで) https://aws.amazon.com/jp/sqs/features/ 配信方式 少なくとも1回の配信 ※2回以上の配信もありえるので処理が終わ っている事を確認するロジックが必要。 (冪等性の確保 - DynamoDBを活用して受け 取ったメッセージが処理済みかどうかを確 認するなど。) 1回のみ配信 配信順序 順序が変わることもある 順序を保つ 利用料金 100万件を超えた場合は100万件ごとに 0.40ドル 100万件を超えた場合は100万件ごとに0.50 ドル

10.

可視性タイムアウト SQSの可視性タイムアウトの期間中は、他のコ ンシューマから同じメッセージは取得されな い。 コンシューマ コンシューマ コンシューマ そのメッセージが適切に処理の完了がされなけ ればキューからは削除されず、可視性タイムア ウト後に再度コンシューマによる処理が開始さ れる。 可視性タイムアウト期間 メッセージ メッセージ キュー

11.

遅延キューとメッセージタイマー メッセージをキューに送信してから指定し た時間後に利用可能になる機能。どちらも 最大15分。 • 遅延キューは「キュー全体」に対して 設定するもの。 • メッセージタイマーは「特定のメッセ ージ」に対して設定するもの。※FIFO は未サポート • 両方設定された場合は「メッセージタ イマー」が優先 • 可視性タイムアウトは受信後。これら は受信前の設定。 プロデューサ ー コンシューマ コンシューマ 可視性タイ ムアウト 遅延キュー キュー メッセージ メッセージタイマー メッセージ

12.

DLQとリドライブ機能 なんらかの不具合が発生し、正常終了できないメッセージを保持期間より前に分離先へ移動させる事で滞留を防ぐ。 ‘DLQの再処理’ から元のキューへ戻す(リドライブ)が可能。 元に戻す先のキューを指定 最大受信数を指定し、超えた場合はDLQへ移動。 移動先のDLQへCloudWatchアラームを設定し、 Slackへ通知。

13.

他... ● メッセージ受信待機時間の設定 ○ 0秒 → ショートポーリング : 即応等。分散されたサーバーの 中からサンプリングされるので取得できない事もある。 ○ 1秒 ~ 20秒 → ロングポーリング : 指定した時間メッセージの 受領を待つ。全てのサーバーをクエリしメッセージを取得。 ● メッセージ暗号化 ○ キュー内に保存されたメッセージをKMSにより暗号化 ● メッセージ属性 ○ メッセージにメタデータ等を保持させる ○ 最大10個 (最大256kbの制限に含む) ○ メッセージ属性は暗号化できない

14.

監視メトリクス ApproximateAgeOfOldestMessage キュー内の削除されていない最も古いメッセージについて、そのメッセージがキューに入れられてから経過し たおおよその時間。 ApproximateNumberOfMessagesDelayed キュー内のメッセージのうち、遅延していて直ちに読み取ることができないメッセージの数。 ApproximateNumberOfMessagesNotVisible 送信中のメッセージの数。メッセージは、クライアントに送信されたものの、まだ削除されていないか、また は可視性ウィンドウの終了前である場合に、送信中とみなされます。 ApproximateNumberOfMessagesVisible 処理するメッセージの数。(アクティブなメッセージの数) NumberOfEmptyReceives メッセージを返さなかった ReceiveMessage API 呼び出しの数。 NumberOfMessagesDeleted キューから削除されたメッセージの数。 NumberOfMessagesReceived ReceiveMessage アクションの呼び出しによって返されたメッセージの数。 NumberOfMessagesSent キューに追加されたメッセージの数。 SentMessageSize キューに追加されたメッセージのサイズ。

15.

やってみて... ● CDK × Lambda でさくさく作れた。 ● SQS×Lambdaとの組み合わせはメッセージの受信処理が簡単。 ○ メッセージの削除が不要 ■ Lambda関数の処理が正常に終了すると自動的に削除してくれる ○ バッチサイズ (デフォルト10) ■ 例えば 5だと → 1回のLambda実行中に5のメッセージを処理する。 ■ 5つのメッセージの内、3番目のメッセージが処理に失敗すると正常処理され たメッセージ含む5つのメッセージがキューに返されてしまう。 ○ ソースキューの可視性タイムアウトは、関数で設定したタイムアウトの少なくと も6倍に設定する。 ■ 可視性タイムアウトを関数のタイムアウトよりも多く、バッファをもたせる 事で重複処理のリスクを減らす事が目的。 https://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-lambda-function-trigger.html https://aws.amazon.com/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/

16.

今後の改善点 ● Step Functionsを使う。 ● メッセージタイマーを使えば1分毎ではなく15分毎にでき たかも。

17.

まとめ ● SQSを使うハードルは非常に低い。 ● その処理は同期?非同期?ストリーミング?Pub/Sub? を決める事で何を選択すべきか自ずと決まる。 ● キューの種類と設定による動作の違いは先に理解してお くと良い。

18.

ご清聴有難うございました。