Social Databank Advent Calendar 2024 の 25 日目です。
はじめに
色々なことを勉強したりアウトプットしたりしている新卒 1 年目のひよこです。最近は AWS 周りのサービスを勉強して軽く組み立てたので、いい感じに分かりやすくシェアできたら嬉しいです。（大したことじゃないけど。。。）
今回のメインキャラクターは SQS, API Gateway, Lambda と DynamoDB なので、これらのサービスを説明した後に、どのようなものを作ったのかを話していきたいと思います。
SQS
SQS(Simple Queue Service)は完全マネージド型のメッセージキューイングサービスです。
SQS の存在で、アプリケーションやシステム間で非同期にメッセージを送受信することが簡単にできます。
意外とピンと来ないかもしれませんが、普段皆がよく行く郵便局をイメージしてみましょう。
手紙を郵便局に一時的に預けた後に、それを別の人に渡して処理してもらいます。
SQS はその郵便局の役割を担っており、待ち行列（キュー）にメッセージが一時的に保存された後に、それを別のアプリケーションやプロセスに渡して処理してもらう形です。
SQS の設定について
SQS の保存タイプは独特で、2つの種類があります。
Standard Queue:
1 秒間に大量なメッセージを入力、出力、削除できる無制限のスループットを有しています。そのため、大規模な処理が必要とする際にとても向いています。しかし、速度が速い分に順序が保証されません。また、サーバや DB に送信する際にはあくまで「少なくとも 1 回は必ず処理しますよ」ということで、重複して処理を行う可能性もあります。
FIFO Queue:
処理速度が Standard Queue より遅く、最大 1 秒は約 3000 件のみ処理可能です。その反面に、メッセージの順序が守られ、必ず 1 回のみ処理を行うことが可能です。
そして、保存されるメッセージの TTL（生存時間）を設定したり、可視性タイムアウトを使用することで1回扱ったメッセージに対してある一定時間の間は操作できないものとしたりする設定があります。これらの制御はとても便利で開発する際に余計なことを考えなくて済みます。（Redis の TTL 設定は基本的にないし、並列処理を考えるときに可視性タイムアウトみたいな動きを自分で作らないといけなくて、とても大変だった思いが。。。）
DynamoDB
DynamoDB は NoSQL データベースの1つであります。RDB(リレーショナルデータベース)とは大きく違う点をわかりやすく言えば、RDB はテーブル同士の結び付きが得意としていて、NoSQL データベースはそのことができないがデータの格納と読み出しを高速的に行うことが得意としています。
DynamoDB の設定について
DynamoDB を作る際に、プライマリキーは必ず必要とします。基本的に String 型または Number 型の指定が一般的で、このキーの指定によりどのアイテムを取得するのかを決まります。また、ソートキーやセカンダリインデックスも存在していますが、必須条件ではないのでここでは割愛します。
API Gateway
API Gateway は API の作成や管理などを簡単に行えるサービスです。
あまり運用をしたことがなくて大した説明はできないが、自分が触っている中で API Gateway を経由したら次のような処理を行う際にはとても便利に扱えます。
↓↓↓ ↓↓↓
「クライアントからのリクエストを受け取る → バックエンド側にリクエストを渡す → バックエンドからレスポンスを受け取る → クライアントに受け取ったレスポンスを返す」
開発の中で必ず API と出会すことになるから、これだけ覚えていれば後々楽になるのではないでしょうか。
Lambda
Lambda は最高です！
アプリケーションを作る際に、もし Lambda を使用しない場合では、EC2 インスタンスの立ち上げや環境構築などのめんどくさいことをやらなければいけなくなります。
しかし、小さいアプリケーションであれば、Lambda に関数単位のコードをアップロードするだけで、そのコードをトリガーとして自動的に実行してくれる最高なサーバレスを実現するサービスです。
実際作ってみた設計
最近は API 連携のことを仕事で任されたので、そのアーキテクチャを用いて説明します。
（具体的な設定方法は少し省きます）
ステップ１ 保存場所を作ろう〜
まず、前提としては SQS と DynamoDB を作成します。
SQS の詳細設定はもしこだわりがなければそのままの設定でも大丈夫です。
DynamoDB も基本的にそうですが、パーティションキーは文字列型を推奨します！
なぜかと言いますと、ここで自分がある落とし穴に落ちてしまったからです。
DynamoDB が取り扱える数値の有効桁数は 38 桁です。が！私は主に JavaScript をコーディングしているので、JS の Number 型の最大値は 9007199254740992 である。。。
16 桁じゃないか！！！！
そのため、Number 型 で DynamoDB に保存しようとしたときに、プライマリキーが 16 桁を超えてしまうと JS のせいでバグってしまいます。。。😓
ステップ２ API 連携じゃ〜
そのあとは API Gateway の作成です。どのタイプの API タイプでも自由だが、今回利用したのは REST API です。特に深い理由はないけど、一番多機能なので選びました w
API の中にも色々と設定をしなければいけないが、クライアントからのデータを受け取るためには POST メソッドを用意しなければいけません。そのため、「リソース」の管理画面上からメソッドを作成します。
今回は SQS を使いますので、統合タイプに「AWS のサービス」、サービスを SQS を選びます。他にも「パスオーバーライド」や「ロール」の設定を書かなければいけませんが、省きます。 😁
その後にステージを作成したらその URL をクライアントに提供すれば連携完了！
ステップ 3 Lambda の作成よん〜
Lambda の作成もとりあえずデフォルトで大丈夫です！
管理画面上に「トリガー」を先ほどの SQS を選んだら、実行したいコードソースを書けば終わりです。
環境構築ほぼなくて、最高だ！！！！！
出来上がり！
これらの設定をすれば、先ほどのアーキテクチャの図のように動きます。
クライアントから API Gateway を通して、データを SQS にキューとして一時保存されます。それをトリガーに、Lambda がそれを検知して、SQS の中身を dynamoDB に保存させます。
設定はちょっと複雑だけど、案外シンプルでしょう？
終わり
今回説明した設計はあらゆる所で応用できます。チャットアプリも使えるし、注文システムとかにも全然使用可能です。一見複雑そうな設計であっても1回やれば実は超絶簡単です！
これが社内にパパッと構築できれば、昇進昇給間違いなし 😎
Discussion