こんにちは。2022年4月からShowcase Gigに新卒入社した寺田です。 5月上旬からプラットフォーム開発チームにjoinし、早くも半年以上が経過しました！ 今回は、その半年のうちに主体となって取り組んだ、webhook改善プロジェクトについて書きます！

そもそもの課題

1. 同期処理でwebhook通知を通知先コンポーネントに送っているため、通知先の数に比例してレイテンシが悪化する

2. いらない通知であっても、とりあえずすべての通知先に通知している

サービスが小規模の時は間に合っていましたが、規模が大きくなっていくにつれ1の課題が浮き彫りになってきました。 また2の課題は外部システムと連携する際に、不要な情報を渡してしまう恐れがあります。

非同期webhookの設計

Amazon SQSを用いて非同期webhookの設計をしました。重要視したのは責務の分離です。 SQSのようなキューイングサービスはシステムどうしを疎結合にしてくれます。 Producerは「通知が生成されたら全通知先に通知をする」という責務から「通知が生成されたら、キューに入れる」だけの責務になり、 「全通知先に通知する」という責務から開放されました。つまり、非同期化され1の課題が解決できそうです。

「全通知先に通知する」を誰の責務にするかですが、 新たにWorkerを用意し彼の責務にしました。理由はSubscriberに大きな修正を加えたくなかったからです。 Publisherの修正のみでどうにかならないかを優先して設計しました(後述しますがこの考え方は失敗でした)。

まだ2の課題が解決できていません。「通知によって通知先を振り分ける」という責務は Producer、Workerどちらに持たせれば良いでしょうか。 Producerは基盤システムのため、他システムから依存されるシステムであり、通知先という概念を持ちたくありません。Workerはすでに「通知する」というシンプルな責務があります。 そこで、振り分けを責務として持つRouterを用意することにしました。 結果、構成はこのようになりました[^さらっと書きましたが、ここに至るまでに試行錯誤を繰り返し、レビューも多くの方にしていただきました]。

新たな課題

設計した構成はSQSが組み込まれているため、別の課題が生まれました。 3. 同じ通知が複数飛んだらどうなるの？ 4. 通知の順序保証はどうなるの？

Producer側の修正のみで完結させようと固執してしまった結果、 SQSをスループットが悪いFIFOキューにしてしまい、 さらにWorkerを増やしてもスケールしないという問題点が見つかりました。

最終的には通知先側に3の課題の複数通知の対応と4の課題の順序不整合の対応をお願いすることになりました。

余談ですが弊社では、「Learning Domain-Driven Design」の輪読会を行っており、イベント駆動アーキテクチャの章にはこんなことが書いてありました。

3, 4の課題はまさにこれでした。

まとめ

設計に絶対的な正解はなく、実現したいことを実現する方法は何通りも考えられる上で一番良いであろう選択をする、ということを学びました。 その選択を誤ったり何度も失敗しましたが、それも含めてたくさんの経験ができました。まだまだ改善の伸びしろが山ほどあるのでこれからも取り組んでいきたいです。

弊社Showcase Gigは新卒にもチャレンジさせてもらえるいい環境です！

終わりに

Showcase Gigでは、一緒に働く仲間を探しています！

もっと知りたいという方は以下の採用ページもぜひご覧になってください。