SQS の使い方を わかっていなかった nakanoshima.dev #34 - 開発しくじり先生 LT会 2023/09/21 株式会社インゲージ 永田　兆 

自己紹介 ● 永田　兆（ながた　きざし） ● @kizashi1122 ● 2014年よりインゲージ社（創業メンバー） ○ 創業時よりCTO ○ Re:lation（次のページ）の開発 ○ バックエンドやインフラを担当 2 

サービス紹介 

Re:lation では非同期処理が多い 4 

非同期処理 5 ECS ECS Elasticache (Redis) ● Rails を使ってるので非同期処理といえば ActiveJob （バックエンドは Sidekiq） ● Rails で閉じているのであればこれが便利で楽 

非同期処理 6 ECS ECS SQS Lambda ● S3 の PUT タイミングでSQSにメッセージをおくることができる ● Lambda から ECS にコミュニケーションをとるのであればSQSが楽 ● エンキュー側とデキュー側で言語が分かれるのであればSQSが楽 Send （enqueue） Receive （dequeue） S3 

最初の構成 7 ECS ECS SQS ● ほぼリアルタイムにさばけている 

最初の構成（ユーザ数増） 8 ECS ECS SQS ● エンキュー＞＞デキューとなる。 ● キュー内にメッセージが滞留することが多くなる。 ● 処理が追いつかない。遅延。対策せねば。 

9 ここでしくじった 当時、しっかりとSQSを理解できていなかった 

実際にとった対策 10 ECS ECS SQS ● 2つめのキューを作成した ● エンキュー側はリクエストに応じて複数キューにメッセージを振り分けた ● 遅延問題は解消はした ECS SQS 

さらに増えた 11 ECS ECS SQS ECS SQS ECS SQS ECS 

何が問題なのか ● 負荷が増えるたびに以下の作業とデプロイが必要になる ○ キュー増設 ○ エンキュー側のプログラム修正 ○ デキュー側のプログラム追加 ● 負荷が少ないときにリソースが無駄になる ● デキューサイドが 1 タスクなので耐障害性がさがる 12 

現在 13 ECS SQS ECS ● キューは 1 つでデキューするタスクを増やした ● これらのタスクは同一なので（同じタスク定義）なのでスケール可能 ● SQS上のメッセージ数をトラッキングしてデキュー側のタスクをオートスケールし ている CloudWatch 

14 インゲージではエンジニアを募集しています！