初めに

AWS Architect Blog 「Modernized Database Queuing using Amazon SQS and AWS Services」（投稿日：2021/12/17 著者：Scott Wainner, Harpreet Virk）を日本語で要点をまとめてみました。AWS のドキュメントを日本語でも読める、理解できるようにするのが目的です。

原文はこちらです。

SQS と AWS サービスを使った最新のデータベースキューイング

初めに

非同期通信を必要とするアプリケーションでは、デフォルトのメッセージストレージ機構として RDBMS を使用することが多い。しかし、メッセージの量、複雑さ、サイズの増大は、データベース固有の機能と競合する。RDBMS はメッセージ配信のボトルネックとなる
RDBMS は、メッセージ・メタデータのソース、ルーティングロジックの実行、メッセージディスポジションの保存において、中心的な役割を果たす
- メッセージのルーティングとは
  - メッセージをどこに送るのかという経路を指定すること
- メッセージディスポジションとは
  - メッセージの配信状態のこと
このブログでは SQS や他の AWS サービスを使ってメッセージ処理をオフロードし、RDBMS のパフォーマンスの制約を緩和する方法を紹介する

キューイングシステムを備えた RDB

Oracleなどの商用データベースは Advanced Queuing (AQ) メカニズムを提供
SQL Serverはキューイング用の Service Broker をサポート
データベースに格納されたメッセージは、多くの場合、メッセージの抽出、変換、ロード（ETL）のシーケンスを使用して複数回処理される。その後、メッセージは、多くの場合データベースにも格納されているロジックに基づいて、一連の受信者に配信されるようにルーティングされる

画像引用元：「Modernized Database Queuing using Amazon SQS and AWS Services, Figure 1. A relational database serving as a message queue.」

問題とソリューション

メタデータ処理

背景と問題

メッセージはペイロード（メッセージの内容）とメッセージの属性を記述したメタデータから構成される
メタデータはメッセージの処理中に繰り返し変換を必要とする場合がある。このため、読み取り、変換、書き込みの一連の処理が非効率的になる。特に、メッセージの属性が複数の変換を受け、それがメタデータに反映される必要がある場合、非効率となる。メタデータの読み書きを繰り返すと、データベースのIOPSを消費し、データベースを垂直方向に拡張（CPUとメモリを増設）することが必要になる

ソリューション

メッセージ管理プロセスをデータベースの外部に置く
最終的なメッセージの処分を書き込む以外は、データベースと対話することなくメタデータを操作する
Lambda のような機能を通じてアプリケーションロジックを適用し、メッセージメタデータを変換することができる

サイズの大きいメッセージ処理

背景と問題

メッセージには、ペイロードに格納しなければならない大きなバイナリオブジェクトが含まれていることがある
大きなバイナリオブジェクトをRDBMSに格納・操作するのはコストがかかる

※ サイズの大きいメッセージをここでは LOB（Large Object）と呼ぶ

ソリューション

データベースの外部で、S3 などのグローバルアドレスで指定可能なオブジェクトストレージに格納する
データベースに格納されるのは、オブジェクトへのポインタのみにする

ファンアウト（同じメッセージを複数の受信者に配布すること）

背景と問題

複数の受信者を必要とするメッセージは、各受信者用に複製されたメッセージのコピーを必要とする場合、データベースへの書き込みと読み出しが複数回発生し、非効率的となる

ソリューション

メッセージの複製は、データベースの外側で行う

メッセージのキューイング

背景と問題

メッセージは多くの場合、配信処理に成功するまでデータベースに保管される
もしメッセージがデータベースから読み込まれ、配信不可能と判断された場合、そのメッセージは後の試みが成功するまでそこに保管される
メッセージ配信プロセスが動作しない場合、配信に失敗した同じメッセージに対して繰り返しメッセージの読み取りが処理され、データベースに対するバックプレッシャーが発生する可能性がある
- バックプレッシャーとは
  - サーバーが完全に圧倒され使用できなくなるのを防ぐためのアクション
  - たとえば、サーバー上のシステムリソース使用率レベルが高すぎると判断した場合、サーバーは新しいメッセージの受け入れを遅くする
  - リソースの使用率が悪化すると、サーバーは新しいメッセージの受信を停止して既存のすべてのメッセージの処理に専念し、送信メッセージの処理も停止する
  - システムリソース使用率が許容レベルに戻った場合、サーバーは、新しいメッセージを受け入れて送信メッセージを処理することで、通常の操作を再開する

ソリューション

SQS や MQ は効率的なメッセージ再試行メカニズムを提供するので、これによりデータベースからの反復読み込みを減らすことができる

メッセージのスケジューリング

背景と問題

メッセージ配信を開始するために、トリガーメカニズムを使用することがよくある
メッセージ配信は、配信のための同期されたポイントを必要とする場合があり、一度に多くのメッセージを処理することで、スケジュールされた間隔で作業のスパイクを引き起こす可能性がある

ソリューション

EventBridge のようなシステムでイベントシグナルを生成し、メッセージの送信を調整することができる

メッセージのディスポジション

背景と問題

データベースはメッセージの送信状態のログシステムとして使用されることがよくある
メッセージのメタデータはメッセージディスポジションで更新されるが、メッセージはアーティファクトとしてデータベースに残っている

ソリューション

メッセージディスポジションの記録として、CloudWatch を利用した最適化手法がある

最新のキューイングアーキテクチャ

メッセージキューをデータベースから切り離す
- データベースの可用性が向上する
- メッセージキューのスケーラビリティが高まる
- データベースの費用対効果が高まる
- バックプレッシャーの緩和
Amazon S3、AWS Lambda、Amazon Message Queue、Amazon SQS、Amazon SNS、Amazon EventBridge、Amazon CloudWatch などのサービスを疎結合で使用
疎結合アーキテクチャにより、各機能コンポーネントは、メッセージキュー管理に必要な他の機能から独立して垂直方向および水平方向に拡張することができる

画像引用元：「Modernized Database Queuing using Amazon SQS and AWS Services, Figure 2. Modernized queuing architecture using Amazon SQS」

メッセージキューにAmazon SQSを、メッセージのルーティング、変換、およびディスポジション管理にAWS Lambdaを使用したメッセージキューアーキテクチャ
ETL プロセスは Lambda で処理され、LOB は S3 に保存する
メッセージのファンアウト配信は SNS によって処理され、キューの状態は CloudWatch と EventBridge によって監視・管理する

まとめ

RDBMS は、メッセージ・メタデータのソース、ルーティングロジックの実行、メッセージディスポジションの保存において、引き続き中心的な役割を果たす
SQSは、メッセージに関連するデータベースのキュー管理タスクをオフロードする
Lambdaは、メッセージの変換、メッセージのキューイング、メッセージの送信を、大規模かつフォールトトレラントで、効率的なメッセージ配信を実行する

参考記事