転職サービスミイダスの機能改善に伴うバックエンドアーキテクチャと性能改善への挑戦
ミイダスでは2022年の11月末から12月初旬に「ニューワールド」プロジェクトのリリースを行いました。「ニューワールド」は、転職サービス「ミイダス」での活動をさらに効率的にするための機能改善プロジェクトです。このプロジェクトに伴い、バックエンドの構成も大きく変え、サービス全体の性能改善にも取り組みました。そのプロジェクトの全貌についてリードを担当した末廣に話を聞きました。
ーー 自己紹介をお願いします。
末廣と申します。2018年からミイダスに参画しており、現在は約4年8ヶ月が経過しています。主にバックエンドの新規開発やリファクタリングを担当しています。
入社後は、SREチームやユーザーメインの施策のバックエンド担当、企業側のバックエンド担当など、多様なプロジェクトに参加してきました。ほとんどの場合、サービスの裏側に関わる業務を担当しています。
以前はユーザーチームに所属していましたが、ニューワールドが始まると同時に新しいチームが作られ、そこに配属されることになりました。
そして昨年の11月末から12月初旬、ニューワールドのリリースを迎えることができました。
ーー ニューワールドのプロジェクトについて詳細を教えてください。
ニューワールドの詳細を理解するためにはミイダスを立ち上げた背景から説明した方が理解しやすいと思うので、先に立ち上げ当時のサービス思想を説明します。代表取締役である後藤が転職エージェントを経験したことで、エージェントなどが介入する採用活動は、主に書類上のマッチングだけでスカウトメールを大量に送信するので非効率で生産性が低いと考えていました。この課題を解決するために面接確約オファーのみが送信できるサービス、ミイダスが誕生しました。
ミイダスは、面接確約オファーのみが行えることにより、効率的な採用活動を可能にしました。
しかし、その思想はミイダスを運営し、データを分析している中で少しずつ変わり、面接確約ではないオファーが悪いのではなく、オファーや応募にあたって書類選考の通過率が分からないことが採用プロセスを非効率にしているのであるという考えに至りました。
今回のニューワールドの大きなポイントは、面接確約以外の公開された求人全般をユーザーが閲覧可能にしたことです。また、求人上の経験やスキル、求職者の希望といった情報を元にマッチングをすることに加え、その会社に入った時にどの程度活躍できそうかといった「活躍可能性」の情報を表示できるようになりました。
このようなサービス思想転換がニューワールドの大きなポイントとなっていますが、開発的には、求人情報を閲覧可能にすることが最も大きな変革点だったと思います。
サービス仕様の大転換に伴い、バックエンドの構成を整理・変更し、それに伴い結果的にサービス全体の性能が改善されることも想定していました。
ーー 今回のプロジェクトの開発はいつ頃から始まっていたのでしょうか？
実はこのプロジェクトに取り組むために、数年前から準備をしていました。
プロジェクトが本格的に走り出したのは、2022年5月から6月頃です。そこから11月まで開発チーム全員で取り組んでいましたね。
チームは、バックエンドが6人、フロントエンドが6人で構成されました。
ーー チームの役割分担について教えてください。
バックエンドやフロントエンド、それぞれのチームの中でもさらに役割を採用側/求職側で分担していました。このプロジェクトでは、「オファー」と呼ばれる機能を削除し、リアルタイムに近い状態で求職者情報と求人情報のマッチングのロジックを実装する必要がありました。そして、マッチングロジックは企業側から見る視点とユーザー側から見る視点で逆のロジックになっています。
そのため、企業側から見たマッチングロジックを担当するメンバー、ユーザー側から見たマッチングロジックを実装するメンバーなど役割を分けていました。
また、削除した「オファー」に関連するAPIやバッチの修正も必要であり、チーム全員で随時対応していました。
フロントエンドではバックエンドの再構築に伴い、URLのパスの箇所を修正やモデル整理をしながら並行して、ユーザーインターフェースの変更やNext.jsフレームワークに移植する作業も行っていました。
UI上はあまり変わらないのですが、フロントエンドの裏側も大幅に変わったことで、かなりの工数が必要でした。これらの変更はミイダス2.0と呼ばれている基盤刷新のプロジェクトで、ニューワールドと並列して動いていました。ニューワールドとミイダス2.0の対応でかなりハードな開発だったと思います。
ミイダス2.0のプロジェクトについてはこちらをご覧ください。
ミイダスのフロントエンドをNext.jsに移行した背景と課題
私は明確にリーダーと言う役割を担っているわけではないですが、長年の所属経験から、CTOの磯崎さんと一緒に仕様の見直しや改善案の話し合いをすることが多かったです。
方針の決定については磯崎さんが担当していましたが、大まかな仕様は既に決まっていたため、私は新アーキテクチャに沿ったコードやテーブルレベルでのドメインモデルの再設計等の役割を担当していました。
チーム全体では、開発を進めながら毎朝ミーティングを行い、進捗状況を確認していました。影響範囲が大きいため、重要な箇所を洗い出し、さらに細かく分割して進めていきました。その後、朝会などで進捗状況を共有しながら、開発を進めていくというスタイルでした。
ーー プロジェクト進行において大変だったことを教えてください。
この「オファーテーブル」の大部分がミイダスの根幹ロジックに関わっていたため、それを無くす作業は影響箇所が多いため本当に大変でした。修正している最中にオファーに関連する新規機能の追加も入っているので、ニューワールドの仕様に即して修正するにはどう仕様を再構成するべきかといった部分も考える必要がありました。また、古いアーキテクチャではSQLを使ってマッチングを実現していたのですが、それをGoに載せ替えることになりました。それだけでも数万行のコードが必要だったので、複雑さは勿論ですが、単純に実装量の多さにも苦労しました。
また、今回は新しい技術にも挑戦しました。例えば、バックエンド間の通信にgRPCを使ったり、複数のコンテナを通して並列処理を行う等です。そのためデータによってはgRPCの制約に引っかかりエラーが発生したり、並列処理中のデータに不整合が発生する等、これまで経験しなかった問題が発生しました。
そして、アーキテクチャ的にはDB分割、個別サービス毎のデプロイを想定した構成にしたため、全体を把握し、設計することが大変になりました。そのため、ドメインモデルの設計はメンバー間だけでなく、アーキテクトやドメインエキスパートの方とこまめに設計レビューを行ってもらいました。その結果、1つ1つの処理は見通しが良くはなったものの、全体把握をすることは難しく、インフラ側もかなり複雑化し、その整理と調整に苦労しました。
ーー 逆にうまくいった部分についても教えてください。
先にも述べた様に、複数のコンテナによる分散処理は想定以上に上手く動きました。おかげで以前のピーク値（平均レスポンス時間が最も長いときで1-1.5秒ほど）から、レスポンス時間が3分の1(0.3–0.5秒ほど)に改善されました。また、数十時間かかっていたバッチも数分から数時間に高速化されるなど、多くのパフォーマンス改善がありました。
また「オファーテーブル」をなくす作業について大変な点で紹介しましたが、関連テーブルもレコード数が数千万から億オーダーに達するテーブルが複数存在しました。転職ユーザーがオファーの一覧を見たいと要求した場合、そのユーザーIDから送信されたオファーを100億行の中から検索する必要がありました。
この検索処理は求人票の一覧を開くたびに実行され、アクセスピーク時はユーザー側の画面の読み込みに時間がかかり、UX低下につながっていました。現在は想像以上に軽快に動作しているので、読み込み時間待ちによる離脱の心配はほぼありません。
分析基盤への同期処理に関しても改善が見られました。ミイダスでは分析基盤として、Redshiftを使用しているのですが、「オファーテーブル」が巨大過ぎて、AuroraからRedshiftへの同期が追いつかないという問題もありました。オファーテーブルが無くなったことで分析チームが同期の待ち時間なく、新しいデータで分析出来るようになりました。
また、AWSのDocumentDBというデータベースをキャッシュとして使用していましたが、アーキテクチャの変更によりDB負荷が減り、キャッシュが不要になりました。また、多くのバックエンドメンバーがRDBを好んでいるという理由や、運用コスト的な面もあり、使用しなくなったことで、構成を少しシンプルにすることができました。
他にもCPUの使用率が大幅に下がったため、レスポンスの時間を概ね維持しつつ、インスタンスサイズを半分にすることができました。ミイダスでは、最も大きなAuroraのインスタンスを使用していたため、そのコスト削減が課題となっていました。正確なコストについては把握していませんが、サイズを半分にできたことで大きな改善になったと聞いています。
本来の目的を達成したことに加え、副次的に多くの良い結果が出たこともあり、これはかなり素晴らしいことだと思います。この点においては、ミイダスのエンジニアたちが頑張った結果ですね。特に、gRPCをほとんど誰も触ったことがなかった状態からPoCを経て、無事リリースし、運用に乗せることができてよかったです。
ーー リリース後の効果や影響についてはいかがでしょうか？
色々ユーザーのアクションの数値は上がりましたが、副作用もあると思いますし、元々のKPIと意味合いが変わってしまったので、注視する必要があります。
開発環境に関しては、ニューワールドに関わっていないエンジニアからは、構成が複雑になって分かりにくいという意見がありましたが、それは今後サービスを分割していく構想があり、それに伴いアーキテクチャの変更を行ったことでの不可避の複雑さだと思います。これらのプロジェクトに関わっていないメンバーには、なぜそのような設計になっているのか理解しきれない部分があるのは重々承知なので、適宜知識を共有していますが、ドキュメント化が足りていないと思っています。
ーー 今の課題と今後の目標について教えてください。
個人的に改善したいなと思っている課題としては例えば、非効率的なバッチ処理が存在しているので、バッチのフローを整理して見通しを良くしたいですね。古いバッチになるほど、歴代の仕様変更に依り、複雑さ、奇怪さが増してしまっているため、整理してメンテナンスしやすい状態にしたいと考えています。
また、デプロイの高速化も目標の一つです。現在は本番環境にリリースするのに15分ほどかかっているため、それを半分以下に短縮したいと考えています。さらに、企業側と転職ユーザー側で同じデプロイジョブに依存しているため、片方のサービスにしか影響の無い修正であっても同時にデプロイする必要があり、デプロイ時間の増加に繋がっています。そのため、サービスを分割して片方だけでもデプロイできるようにもしたいです。CD側の改善を進めて開発の高速化もしたいので、これからやっていくことは沢山ありますね。
ーー まだまだこれから更に良くなっていくということですね。本日はありがとうございました！
ミイダス Techについて
ミイダスでは、様々な技術イベントを開催しています。connpassやYouTubeチャンネルでミイダスグループのメンバーになった方には、最新の開催情報やアーカイブの公開情報が届きますのでぜひご登録をお願いいたします。
イベントページ：https://miidas-tech.connpass.com/
Twitter：https://twitter.com/miidas_tech
この記事が気に入ったらサポートをしてみませんか？