JINSで、アーキテクト/テックリードをしている佐藤(@Takuma3ato)です。
JINSでは様々なインターフェース方式でデータ連携をしており、その紹介をしています。第二弾として今回は、メッセージキューについてお話しします。前回の記事はこちら。
1.メッセージキューでの連携
これは、サービス間で非同期でデータのやり取りをしたい場合に検討する連携方式です。
連携するデータ量
「メッセージ」と呼ばれる要素に対して連携したいデータを格納し送信するが、格納できるデータ量に制限はあり、少量から中量のデータのやりとりに適する。
連携先システムへの反映速度
メッセージは「キュー」と呼ばれる仕組みでコントロールされる。この仕組みは、様々なメッセージを一時的に格納しており、その処理順番は「先入れ先出し法 (first-in-first-out (FIFO))」がある。連携先へのデータ反映速度については、キューの処理順番や、連携先でのキュー処理のタイミングによる。
連携時のエラー処理
何かしらかの理由でそのメッセージが取り込みできない場合、どのように再試行するのか、そのまま終了とするのかは取り決めによる。
他システムとの依存度合い
データを送信する側のシステムは、メッセージをキューに渡すところまでが責務であり、それ以降は、目メッセージブローカーや受信側システムの責務となり、システム間の依存は軽量である。
通信で使うネットワーク
インターネット通信、社内ネットワーク通信どちらも可能である。
2.JINSでのメッセージキュー連携
(1)どんな処理に使っているか
概要
店舗の商品棚卸作業が一つのユースケースです。
エンドユーザ(店舗スタッフ)の操作で、小さいサイズのデータを一気に多量に登録したい。しかし、それ以外にもやらなければならない作業も実施したい。これらを実現するアーキテクチャとして、今回のメッセージキューを採用しています。
(2)システム環境
構成要素
・Amazon SQS メッセージブローカーの役割
・API Gateway リクエスト認証
・ECS キューの処理
メッセージキューの仕組みは、AWSサービスのAmazon SQSを使っており、主要な設定は下記の通りです。
・タイプ 標準
・最大メッセージサイズ 256 KB
・メッセージ保持期間 14 日
・デフォルトの可視性タイムアウト 6 分
・デッドレターキュー 利用なし
デッドレターキューは、今回は利用していません。メッセージを作成するプロデューサー側が限定されており、メッセージの安定性はある程度担保されている事と、Visibility Timeout設定を有効化することで、キューの処理に失敗した場合でも次のConsumerスレッドがリカバリをするという設計にしています。デッドレターキューを用いた方策よりも実装がシンプルとなることを優先し、このような設計としています。
(3)メッセージキューの考慮事項(AWSサービス)
配信性、順序性
多量に発生するキューの処理方法として、この配信性と順序性は考慮すべき事項です。考慮する観点は以下の通りです。
配信性
そのキューの配信は、「At Least Onece」か「Exactly Once」のいずれであるか
順序性
複数のキューの順番は「FIFO(First in First out)」とする必要があるか
コスト最適化 ※これも大事
キューの数や上記の性質のいずれを選択するかでAWS利用費が変わるので、そのメッセージキューで実現したいことと費用を比較し、最適な選択肢はどれであるか
比較
Amazon SQSは、配信タイプとして2種類ありますが、特徴を比較すると以下の通りです。
| 特徴 | 標準キュー | FIFOキュー |
|---|---|---|
| スループット | 高い | 制限あり |
| 重複排除(配信性) | なし | あり |
| 順序保証(順序性) | なし | あり |
| コスト | 低い | 高い |
配信タイプは「標準」を選んでいますが、配信性については後続処理で重複メッセージ除外を担保する形を取っています。クライアントアプリ側で、リクエストにユニークなトレースIDを生成することで、重複リクエストであるかを判断できるようにしています。
今回の記事は、メッセージキュー連携にフォーカスしており詳細は書いていませんが、イベント発生時のメッセージ生成からデータ書き込みが完了するまでの間における冪等性の担保は重要な点です。また、データベースへの書き込みはデータの基本的な入出力を責務とするAPIを経由することにしていたり、キューに記載しているメッセージはイミュータブルデータとして登録処理をしているのですが、そういった話はまた別の記事で書こうと思います。
補足
今年2月のAWSアナウンスで、Amazon SQSのキューサイズが拡張されました。Pythonクライアントライブラリで、最大 2 GB のペイロードをサポートしたので、大きめのメッセージを生成できるようになったことで、メッセージキュー連携の幅が広がりました。
メンバー募集！
JINSでは様々な仲間を募集しています。ヒトが扱う様々な道具の中で、ものすごく長い間身につけているメガネというプロダクトを扱っています。自分たちで企画・デザイン・製造し、お客様に直接販売している製造小売業の会社なのですが、これからはシステム開発においても自分たちでできることをもっと増やしていき、EyesTechのリーディングカンパニーになるべく挑戦しています。JINSのロゴマークにある「!」は、ワクワクや驚きを表しています。ぜひ一緒に「新しい当たりまえ」を生み出していきませんか？
Discussion