• Twitter
  • Facebook
  • Google+
  • RSS

GoとKinesis Data Firehoseで非同期の検索基盤を構築─モノリス化した「カオナビ」はアーキテクチャ改善にどう取り組み始めたか

多くの企業で採用されるタレントマネジメントシステムとして高いシェアを誇るカオナビでは、サービスの成長にともなうシステム開発の課題をどのように解決しているのでしょう。新たな検索基盤の構築を通して、将来を見据えたアーキテクチャ改善の取り組みや開発組織の文化までを語るエンジニアインタビューです。

モジュラモノリス&マイクロサービスでアーキテクチャを改善

社員の個性・才能を発掘し、戦略人事を加速させるタレントマネジメントシステム「カオナビ」を提供する株式会社カオナビでは、SaaS移行にあわせてクラウドを全面的に採用し、インフラの自動化などにAWSのマネージドサービスを積極活用しています。とはいえ10年近い運用で、サービス開発におけるシステムのモノリス化が課題となってきました。

こういった全社的な課題は、2020年からCTOを務める松下雅和@matsukazさんを中心にCTO室で対応しています。モノリスなシステムは、全体のモジュラモノリス化を前提に、とくにボトルネックとなる検索処理を非同期の基盤サービスとして切り出しています。

この検索基盤の設計と実装を通して、カオナビはシステムのアーキテクチャ改善をどのように進めようとしているのか。非同期である必要性や、デプロイの工夫、開発組織の文化まで含めて、CTO室の千葉峻秀さんとインフラグループの佐藤誠司さんに聞きました。

※この記事は株式会社カオナビによるSponsoredContentです。

検索エンジンの呼び出しをモノリスのシステムから分離

── システムのアーキテクチャ改善のため、まず「検索基盤」を構築されているということですが、どのような課題感があったのかを教えてください。

千葉 「カオナビ」はAWSのサービスを積極的に活用していて、検索エンジンとしてもマネージド型のAmazon CloudSearchを採用しています。このデータ処理の能力・特性が、現在のサービス要求とマッチしていない状況になりました。具体的には、1日に処理できるデータ登録の回数を超えてしまうおそれが出てきたのです。そこで検索エンジンを取り替えたい。ここが出発点です。

── 検索エンジンを変更するために、検索基盤が必要ということになったのでしょうか?

千葉 今のシステムはPHPのモノリスですが、このシステムのあちこちから直接、検索エンジンを呼び出して利用していました。この複数存在している検索エンジンへのアクセス全てを一気にリプレースすることは、リスクが高いシステム改修です。少しでも失敗があるとサービスが数日間も停止しかねません。

検索エンジンを安全に交換するにはどうするか。結論として、検索エンジンにアクセスする検索基盤をマイクロサービスとして分離し、システムからはこの基盤を利用することで、安全に交換できる仕組みを作ることでした。これによってモノリスの側もシンプルになります。

── 実際にはどのような規模感のプロジェクトだったのでしょう。チームの人数や、開発規範を教えてください。

千葉 当初は私1人で初期設計を進めました。2022年3月にカオナビに入社して、6月くらいから取り組んでいます。実装に入ってからはメインの開発者が私を含め2名、インフラ側がここにいる佐藤を含めて2名、計4人のチームでした。普通なら7〜10人で取り組む仕事かな、という規模感のプロジェクトですね。

千葉さん近影

千葉 峻秀(ちば・たかひで)@chibat_p3f

株式会社カオナビ CTO室 BERT(Back-End Re-architecturing Team)

大学在籍時からアルバイトとしてシステム開発に携わり、20年ほどのエンジニア歴で中堅SIer、Webインテグレーター、大手物件ポータル、ペット事業のスタートアップとさまざまな規模と事業領域を経験し、機能開発から設計・インフラまで幅広い業務経歴を持つ。2022年3月に現職としてカオナビに入社。

インフラの歴史をCloudFormationでコード化し参照可能に

── 佐藤さんは今回のプロジェクトに、どのタイミングで参加したのですか?

佐藤 初期のアーキテクチャが固まった後ですね。2022年8月に入社して、すぐこのプロジェクトに入りました。

千葉 そうですね。実装に移る段階だったように思います。

── プロジェクトにおけるインフラの仕事はどういったものだったのでしょう。

佐藤 AWS周りの全てです。必要なリソースが設計書に書かれていない場合には、自分で実装もしました。

── とくに気を使ったことは何でしょうか?

佐藤 Amazon IAM(Identity and Access Management)に関連する作業でしょうか。会社の権限設計方針から、インフラグループの私は管理者権限を持っているものの、千葉のような開発者に割り当てるIAMの権限については範囲が決まっています。本プロジェクトでは開発スピードが必要だったので、千葉自身がAWSリソースの作成や設定変更をしながら開発進行できるように、必要な権限を切り出す必要性がありました。

そこでセキュリティやコストを考慮しつつ、既存の環境に影響を与えてしまうといったリスクもないように、IAMの権限調整を私が引き受ける形にしました。現在もプロジェクトは進行中ですが、開発速度が落ちることもセキュリティ上の問題も起きていません。

── 新しくチャレンジしたことなどあれば教えてください。

佐藤 設計されたアーキテクチャにあわせてAWSリソースを選び、インフラを作っていきますが、開発段階にはアーキテクチャもころころと変わります。そのため構築するインフラを変更しやすく、また可視化するためにコード化したかったのでAWS CloudFormationを利用しました。

カオナビではGitLabを利用していますが、インフラに関して書いたコードやドキュメントを、構築・変更の意図などのコメントを入れながらコミットして、環境構築の履歴を残すように意識しています。これは私だけでなく私以外のインフラグループのメンバーにも、このプロジェクトのインフラ環境について歴史を参照可能にすることで、環境の理解・運用がしやすくすることを目的としています。

── 千葉さんから見てインフラの状況はどうでしたか?

千葉 佐藤が作ったインフラで凄いと感じたところは、ネットワーク通信経路まで考えられていることですね。例えば、内部のアプリケーションが必要になる通信に対して、VPC(Virtual Private Cloud)エンドポイントを利用するように設計し、通信が遅くなってしまうようなボトルネックを排除した設計を試みてます。

こういった専門分野を持ったエンジニアが社内にいると頼りになるし、チームとして強くなりますね。

佐藤さん近影

佐藤 誠司(さとう・せいじ)

株式会社カオナビ SRE部 インフラグループ

インフラエンジニアとして20年ほど経験しているうち、前職のソーシャルゲーム開発を含めてこの10年近くは大規模なクラウド環境を専門としている。2022年8月に入社し、AWSの環境構築や運用を担当。

Goによる並列処理でCloudSearchに大量データを登録

── 話を少し戻しますが、設計の段階ではどういったことを考えて進めましたか?

千葉 初期設計においては、回数が1日に1万回ほどのデータ量と登録回数に上限があり、上限に到達しそうだったので、Amazon CloudSearchのデータ登録条件を交換するまでの期間を、どれだけ引き延ばせるかが重要になりました。

この上限に達しないよう、効率よく登録するにはどうするか。これまでのように新規データが発生するたびに登録していたのでは、すぐ上限に達してしまう。そこで検索基盤では、ある程度のデータをまとめてから登録する。つまり非同期の処理に移行して、1回ごとのデータ登録を効率化しようと考えました。

── 同期から非同期へ。大きな変更ですね。

千葉 非同期で登録した方が効率的であることは分かっていました。どう非同期に登録するか、その設計には2週間ほど考え続けました。

まず、非同期処理に使えるキュー(待ち行列)を提供するサービスをいくつか調べました。使った経験があるAmazon SQSも候補でしたが、現状の開発リソースの中ではデータストリーミングサービスのAmazon Kinesis Data Firehoseに注目しました。

主にドキュメントを調査して良いと判断できたので技術選定しましたが、Firehoseを前提に非同期処理を設計してから、社内の識者に「この設計で弊社のシステムとして大丈夫か」を相談し、そのフィードバックをもとにブラッシュアップしていきました。

── システム的にどういった点が変更されたのでしょう。

千葉 検索基盤ではデータをまとめてからAmazon CloudSearchに登録するので、そのままだとメインシステムの登録機能からは、登録されるまで「返信がないまま止まっている」ように見えます。そこで、登録の依頼がくるとまずレスポンスを返し、登録は後から実施することで非同期の処理になります。

── システムの開発言語はPHPですが、検索基盤ではどの言語を選定したのですか?

千葉 Goを採用しました。理由の1つは、並列処理です。データ登録にあたり大量のデータを処理しなくてはいけません。そこで重要なのが並列処理です。100万件を1個ずつ処理するより、10分割して並列に取り組んだ方が速い。その点、Goは並列処理を記述しやすい言語です。

もう1つの理由は起動時間の短さ。Goで作ったアプリケーションはデータ容量がすごく小さい。デプロイするサーバーを立ち上げるときに高速で立ち上がります。今回のシステムはサーバー台数を減らしたり増やしたりが多く、頻繁なデプロイが発生するので、この点は重要でした。

この2点が採用の要因としては大きかったですね。並列処理への対応ではJavaもいい言語ですが、立ち上げてすぐ動く点ではGoが優れていました。

── 言語はどのように選定したのでしょう。

千葉 私が好きな技術書に、アンクル・ボブの『Clean Architecture』があります。開発言語やDBMS(データベース管理システム)の選定は、一番最後に決めた方がいいと書いてあります。この考え方が好きなので、開発言語として当社がメインで使っているPHPとGoを並べて、「このデータ量に対してこの処理をするなら」という理由でGoを選びました。

LambdaとKinesis Data Firehoseでマネージドな非同期を

── プロジェクトの現在の状況を教えてください。

千葉 今は、検索基盤の第1段階のリリース直前です。開発は全て終わり、テストの最中です。インフラから何から変わる状況なので、手でテストしながらしっかり確かめています。リリースできてから、自動デプロイと自動テストを仕組み化していきます。

── 今回のリリースで、検索基盤はどのくらい整備されることになるのでしょう。

千葉 第1段階の一番の目的は、検索エンジンへのデータ登録をモノリスから切り離すことで、登録機能を検索基盤の側に持ってきました。AWSのサービスを大々的に使って非同期処理を作り込みましたが、これは初めてに近いプロジェクトでした。

── 具体的にどういった点に初めてチャレンジしたのでしょう。

千葉 Amazon Kinesis Data Firehoseを本格的にプロダクトに組み込んで使うのは、初めてでした。非同期処理の途中でデータをいったん排出して、保存する場所にはS3を使いました。まとまったデータをAWS LambdaでCloudSearchに登録していく(下の構成図を参照)。設計も、実装・動作も複雑です。クラウドのリソースを設定してもらったり、動作させたりするところは苦労がありました。

── 予定通りに進んだでしょうか?

千葉 基本的には、当初の設計通りに進めました。途中で必要ないことが分かった機能、例えば「データ変換」などですが、それは省略してシンプルに磨き上げていきました。

── 初めて触るのに近いプロダクトもあったということですが、プロダクト選定はうまくいったと考えていますか?

千葉 いまのところ成功です。Firehoseにはデータをまとめる機能が付いています。これを使わないと自分達でキューを用意して構築しないといけませんが、それでは1年以上はかかってしまう。Firehoseを使ったおかげでうまくいきました。

ただ、設定を手探りでするのは難しい。そこで佐藤に相談したところ、環境をコード化し、PoC(実証)環境をさくっと作り込んでくれました。佐藤の専門性が高いからこそ出来上がった環境です。

佐藤 初めて触るプロダクトはAWSのマネージドサービスが多いため、クォータ、スロットルなどを監視してアラーティングする設計にしていて、サービスへの影響がでないように準備しています。

千葉 私がシステムアーキテクトの立場、佐藤がインフラエンジニアの立場で、お互い手を組んで目指すところに向かって進むことができました。

── 今後の開発予定を教えてください。

千葉 第2段階では登録だけでなく、検索機能を検索基盤に持たせます。これで検索機能が完全にモノリスから切り離されるので、第3段階で検索エンジンを交換します。

システム構成図

▲システム構成図

社内にはチャンスと「ネタ」がいくつもある

── 働き方などもお聞きしたいのですが、それぞれの所属組織について教えてください。

千葉 私が所属するCTO室は、2022年4月に発足しました。今回の検索基盤第1段階の開発期間は約7カ月でしたが、システムの改善は長期間にわたるのでもっと長期にわたる取り組みもあり、プロダクトの事情に合わせるのが難しい場合が出てきます。長期の取り組みが可能な組織として作られたのが、CTO室です。

佐藤 私がいるインフラグループの役割は、サービスを動かすインフラの管理です。ただし今回の検索基盤改善はいつもと毛色が変わっていて、私は千葉のバックアップをする役目、開発が進みやすくなるように進める役目です。

── システム全体としては、技術的にどのような取り組みを進めていますか?

千葉 システムが長期間にわたり開発されてきたことで、不具合であったり、ビジネス規模に見合わない部分だったりが出ています。そこを整理して、これからモジュラモノリスにしていこうとしています。そこに至る過程として、検索基盤を切り出した方が開発しやすくなるというのが今回のプロジェクトで、まだその第一段階です。

エンジニアとして見ると、これはちょうどシステムが切り替わるタイミングですから、チャンスがたくさんある状況だと言えます。力があるエンジニアが力を発揮でき、新しい技術を学びたい人にも良い環境です。チャンスがあり、ネタがある。エンジニアには楽園のようなところかもしれません。

── カオナビでソフトウェアを開発することの特色があれば教えていただけますか?

千葉 カオナビの開発文化は、私がこれまで働いてきた会社とけっこう違いますね。週に1回、全社のスプリントレビューを行うなど、ビジネスと開発がしっかり話し合いながら事業を進めています。全社一丸となって、という感じです。

佐藤 インフラエンジニアの視点から見ると、自由度が高いですね。使うツールやAWSリソースの裁量が私たちに任されています。といっても放任されているわけではなく、ちゃんとレビューもしてくれます。

全体としてエンジニアリングする楽しさがあるというか、相談できる仲間も多い。技術的に悩んだりつらかったりするときにSlackの自分のチャンネルに書いておくと、コメントを残してくれる人もいたりします。リモートの割にコミュニケーションが多いなと思います。

千葉 みんな協力してくれる気持ちが強いですね。リモートについてはテキストコミュニケーションが多くなりがちなので、ビデオ会議やSlackのハドルはよく使うようにしています。CTO室でも週に2回、コーヒーブレイクといってオンラインで集まって話しています。チーム外のエンジニアにも、Slackで「今の時間ならCTO室のメンバーがいるので、話したい方はどうぞ」と案内しています。

また2週間に1回、全社のメンバーが発表する「カタリバ」という取り組みをしています。CTO室からも技術的な話を積極的に展開しています。

佐藤 技術的にもCTO室から全社への波及効果もかなりあるように思いますね。

── システムのリニューアルという大きな変化にともない、実践的な学びを得たいエンジニアには最適な職場かもしれないですね。本日はありがとうございました。

カオナビではエンジニアを積極募集しています!

カオナビのエンジニア組織では、一緒に挑戦できる仲間を募集しています。

記事で紹介したバックエンド・インフラ領域にご興味ある方は、以下リンクよりご応募ください。

「まずは話を聞いてみたい」という方は、カジュアル面談やオンラインイベントにご参加ください!

未来での“はたらく”を形にしたkaonavi Town

カオナビが考える「未来での“はたらく”」を街という形で可視化した、ブランディング施策「kaonavi Town」プロジェクト。

ご興味のある方は、こちらよりご覧ください!

[SponsoredContent] 企画・制作:はてな
取材・構成:星 暁雄
撮影:小野 奈那子