インフラコストを10分の1削減し、タイムラグも解消　利用者急増に伴った「イベント駆動」の新システム開発

ディップ社・バックエンドエンジニアの藤中雄太氏

藤中雄太氏（以下、藤中）：「プロダクト間のデータ連携をイベント駆動で作り直した話」をお話しします。ディップ株式会社の藤中と申します。よろしくお願いいたします。

本日は、（スライドを示して）このアジェンダに沿ってお話をします。

まず、簡単に自己紹介をしたいと思います。私は、2022年3月にディップ株式会社へ入社しました。JavaやGoを主力に、バックエンドエンジニアをやっています。

従来のシステムにおけるデータ連携のかたち

藤中：今回の、「イベント駆動でシステムを作り直した話」をお話しするにあたり、まず、従来のシステムについて説明をいたします。

従来のシステムの説明をさせていただくにあたり、システムに関連する弊社の2つのサービスについて軽く説明をいたします。

弊社では、「コボット」と「バイトル」というサービスを提供しています。コボットは、履歴書の送付や面接の日程調整などを行うことができ、業務の効率化を支援しているサービスです。バイトルは、企業の採用広告を出して、採用業務の支援をしているサービスです。

今回お話をするシステムの要件は、「コボットがバイトルのデータを見たい」ということから発生しました。実はすでに、バイトルのデータにアクセスできる既存のシステムがあったため、そちらをコボットで使用することになりました。

既存のシステムが（スライドを示して）こちらです。こちらを従来のシステムとします。バイトルのデータで共有できるものだけをデータ同期バッチで5分置きに取得し、データベースに登録しています。

コボットはAPIにリクエストし、API経由でデータベースに登録されているデータを取得することでデータ連携を実現していました。

コボットの利用者増加でサーバー処理が不安定になってしまった

藤中：弊社としてはありがたいことに、コボットの利用者が急激に増加しました。ここで影響を受けたのが、従来のシステムのAPIです。

コボットの利用者増加に伴い、従来のシステムのAPIへのアクセスも急増しました。APIサーバー自体の負荷は大して問題ではなかったのですが、影響を特に受けたのがデータベースでした。データベースに高負荷がかかり、サーバー処理が不安定になるという事態が発生しました。

そこで、緊急時の対応として、データベースのレプリカを増設することで安定化させました。以上が従来のシステムについてです。

従来のシステムの課題は「コストの増加」と「タイムラグ」

藤中：次に、従来のシステムの課題についてお話しします。

（スライドを示して）こちらのとおり、2点ですね。1つ目はコストの増加です。DBサーバー増設のため、インフラのコストが従来の5倍以上に膨れ上がってしまいました。次に、以前から課題だったのですが、5分に1回データを同期しているため、連携にタイムラグがありました。

即時データが連携できる新システムの仕組み

藤中：そのため、利用者に限らず即時データが連携できる仕組みを新しく用意することになりました。これから、作成した新システムについて説明をいたします。

従来のシステムでは、コボットからリクエストをすることでバイトルのデータを取得する形式でした。新システムでは、バイトルからデータを送信する形式にしました。

それが（スライドを示して）こちらです。バイトルからデータを登録する時に通知し、それをトリガーにコボットにデータを送信する仕組みにしました。

大まかな流れを説明いたします。まず、コボットとバイトルが連携しているかを、コボットを主体としてデータとして管理し、コボットからAPIにリクエストすることで、連携の開始と解除を制御しています。連携のデータはDBで格納しているかたちですね。

バイトルの登録時にSNSに通知されたデータは、「SQS」に送信されます。SQSにデータが格納されたことをトリガーに、データ送信Lambdaが実行されます。「Lambda」は、通知されたデータがDBに登録されている連携中のデータであることを確認でき次第、コボットに送信をします。このように、イベント駆動のシステムを実現しました。

インフラのコストが10分の1削減・タイムラグも解消

藤中：では、これによって従来のシステムの課題がどうなったかをお話しします。

まず、従来のシステムはインフラコストの増加が課題になっていましたが、多数の利用者に影響されず、必要なデータのみを連携できるようになったため、システムの規模を大幅に縮小ができました。そのおかげでインフラのコストは、従来のシステムから10分の1にまで削減できました。

また、従来は5分に1回データを同期するシステムだったことから、連携にタイムラグが発生していましたが、データの登録とほぼ同時に連携ができる仕組みとなったため、タイムラグがなくなりました。これで、以前抱えていた課題をすべて解決することができた次第です。

イベント駆動に作り直して良かったこと・大変だったこと

藤中：では、イベント駆動に作り直した振り返りとして、良かったことと大変だったことをお話しします。

良かったことは、今回追加したSNSによる通知トリガーを、ほかのプロダクトでも使用できるようになったことです。これによって、バイトルへの改修なしにほかのプロダクトでもデータの登録とほぼ同時に連携などの処理を実行することが可能になりました。

次に大変だったことですね。1つ目に、従来のシステムでは、コボットからバイトルにデータを取得する形式だったため、バイトルの改修はほぼ不要だったのですが、バイトルにデータ登録がされた時にSNSに通知する必要があったため、バイトルにも改修が必要になり、改修範囲が広範囲になってしまったことです。

一般的ですが、対応としてプロジェクト管理ツールでチーム間のタスク管理を行い、リリースまでどうにかたどり着くことができました。

2つ目は、今回の話から少しそれるのですが、CI/CDの設計に手間取ってしまったことです。今回はLambdaがシステムのメイン部分ということで、LambdaのCI/CDも充実させたいとなったのですが、LambdaのCI/CDについての知見が少なく、設計に手間取ってしまいました。こちらについては話がそれてしまうため、今回は割愛します。

有志でテックブログを運営中

藤中：システムをイベント駆動にした話は以上です。最後に2つ宣伝をさせてください。弊社のエンジニアが有志でテックブログをやっています。「dip テックブログ」で検索をしてもらうか、QRコードを読み込んでもらえば参照いただけると思います。今回お話しした内容も載っているので、よろしければぜひご覧ください。

また、弊社は絶賛エンジニアを募集中です。（スライドの）右のQRコードから求人ページにアクセスできます。カジュアル面談などもやっているので、興味のある方はお気軽に申し込んでいただけると幸いです。以上で発表を終わります。ご清聴ありがとうございました。

Lambdaのスロットル制限に対する懸念はなかったのか？

司会者：ありがとうございました。「Slido」に質問が来ているので、ちょっと読み上げてみたいと思います。

1つ目です。「バイトル側、登録側のほうで大量のデータが登録された場合、同じ時間にその登録が行われると、Lambdaのスロットル制限にかかりそうですが、そのあたりの懸念はなかったのでしょうか？」と来ています。

藤中：ありがとうございます。そうですね、イベント駆動でスロットル制限、高負荷がかかってしまうのではないかということですが、その懸念はもちろんしています。

事前に、バイトルで1日に登録されるデータの総量を計算して、その約2倍の負荷がかかった場合、きちんと流しきれるかなどを計算をして、問題がなかったためリリースまで進めたというかたちですね。

司会者：ありがとうございます。

コボットにしわ寄せがいくこともなかった

司会者：もう1つです。「DB負荷が高かったとのことでしたが、アーキテクチャ変更後にコボットにしわ寄せがいくことはなかったのでしょうか？」と来ています。

藤中：ありがとうございます。そうですね、アーキテクチャ変更後にコボットにしわ寄せがいくことは、特にはありませんでした。コボットからもバイトルにデータを取得するために空振りでもAPIを叩いていたため、今回、必要なデータだけが送信される仕組みになりました。そのためコボットでも負荷軽減が見られているのが現状です。

司会者：ありがとうございます。

Lambdaを使うことに悩みはあったのか？

司会者：続いて、「LambdaとDB間にはプロキシを噛ませているのでしょうか？」あと、「Lambdaを使うことによる悩みはありましたか？」という質問です。

藤中：まず、LambdaとDBの間にはプロキシを噛ませていません。

現状、Lambdaの実行時間で課題は見られていない状況なので、プロキシは噛ませず、そのまま処理をさせています。

Lambdaを使用することによる悩みですが、現状はあまりありません。なにかあったらその機会に課題として発表ができればなと思います。

司会者：ありがとうございました。

LambdaのCI/CDはどのようにしたのか？

司会者：「YouTube」にコメントがあったみたいなので、読み上げたいと思います。「LambdaのCI/CDをどのようにしたのか気になります」というコメントが来ています。

藤中：LambdaのCI/CDについてですが、一般的には「CloudFormation」を使用したデプロイがメインかとは思いますが、弊社では「CodeBuild」によるデプロイを行っています。

「CodePipeline」でデプロイ全体を管理していて、その中で、CodeBuildでLambdaに資産のデプロイをしています。そしてLambdaにデプロイした資産は、そのまますぐに切り替えるかたちにはせず、「CodeDeploy」によってLambdaのバージョンもエイリアスに対して切り替えるというかたちにしていて、エイリアスを本番のものとして動かしている形式にしています。

司会者：藤中さん、どうもありがとうございました。

藤中：ありがとうございました。