本日はスタートアップを支えるデータ基盤の裏側について発表していきますが、まずは弊社の製品のSalesMarkerについて紹介します。
皆さんは自社の課題を解決するツールを導入したい時は何を行うでしょうか。
エンジニアであれば、自社のサービスをオンプレからクラウドに移行したいと思った際に、どのようなクラウドサービスがあるのか、AWSやGCPと比べて何が違うのかといったことをインターネット上で検索すると思います。
実際にいろんな人に聞いてみても、Web上で検索した経験がある人は100%でした。 現代はインターネットがベースの社会なので、購買プロセスの約60パーセントがWeb上で完了している背景があります。 なので、何かを買ったり導入したりする前は必ずネット上で何かしらの購買検討が進んでいます。
我々が提供するSalesMarkerは企業を人の集合体だと見立てます。そして、この企業に属する人達がインターネット上でどういうものを検索して、どういう記事を見て、どういう行動を起こしているのかを分析して、この企業が今抱えているであろう課題や興味・関心の分野を特定してビジネスに応用するビジネスモデルを扱っております。
事業開始の当初から500万件の法人データと370万件の人物データ、プラス50億レコードのインテントデータを分析しないと実現できないようなビジネスモデルだったので、創業当初から大きなデータを継続的に扱ってきた背景があります。
データに関するアーキテクチャの変遷
急成長の裏側でデータに関するアーキテクチャは結構変遷していまして、全部で6段階のフェーズがありました。
まずフェーズ1は創業当初です。要件としては、インテントデータと呼ばれるデータを分析した結果を法人データと掛け合わせてお客様に表示するという簡単なものでした。 なので、データ構造はできるだけシンプルにして、Amazon Auroraを使いました。
しかし、サービス開発2か月後に急に法人データを部分検索したいという要望があり、さらに大量の検索を行う必要が出てきました。なぜなら、お客様のデータと突合してしまうので大量に名寄せを走らせる必要があったからです。
法人データは500万件あるので、MySQLではかなり負荷が高いような状態になってしまいました。この解決策として、OpenSearchという検索エンジンを導入することで解決しました。 こちらがフェーズ2でした。
さらに2ヶ月後には、法人データだけでは課題解決に至らず、部署や人物データを導入する必要が出てきました。こちらがフェーズ3になります。当初は1つの法人インデックスでの設計だったので、この中に入れ込むことがかなり難しくてどうしようという感じでした。
また、ビジネス的な統合を考えると開発期間が2週間しか無かった状況でインデックスを増やすという決断に至りました。
なので、フェーズ3としては、
- インテントデータ×法人データ
- インテントデータ×部署データ
- インテントデータ×人物データ
が別々のインデックスに存在しているというデータ構造になりました。
ただ、OpenSearchではインデックスが分かれると基本的に結合できないデータ構造になっています。
お客様から法人データ・部署データ・人物データを横断して、さらに部分検索してインテントデータを組み合わせた結果が見たいという要望がありましたが、3つのインデックス構造である以上、その要望に合わせた検索ができません。頑張ればできますが、非常に効率が悪い状態になってしまいます。こちらがフェーズ4です。
解決方法としては、思い切ってリデザインしました。新しいインデックスを設定して、一定冗長化させることで横断検索が可能なシステム構造に変更しました。
しかし、ビジネスモデルとしては元々インテントデータがかなり蓄積されていて、過去のデータもなかなか削除できない状態でした。この解決の段階がフェーズ5になります。
そのため、インテントデータが2億を超えた時から、過去データを検索するオペレーションが入った時に著しくパフォーマンスが落ちてしまったんです。
そこでAmazonのAthenaを導入して、定期的に古いデータをアーカイブする仕組みを作ってHot/Coldのデータの振り分けを実施しました。HotのデータはOpenSearchで検索して、ColdのデータはAthenaから検索するという形になりました。
続いてフェーズ6ですが、先ほどのデータとユーザーデータを掛け合わせて調べたいというニーズへの対応について、データの検索エンジンへの同期頻度が日毎だったので難しい設定になっていたんですね。
ここは本当にシンプルに、リアルタイムにOpenSearchに同期することで解決いたしました。
以上、6回の大きなデータ構造の変化を遂げております。 時間軸は、2022年3月サービス開始当初のフェーズ1から、 5月・10月と2回ありまして、2023年に関しては2回の大きな変更と、2024年に入って大きな1回の変更がありました。
スタートアップだったので、全ての変更は2〜3週間以内で行うような必要があったんですね。非常に早い意思決定を求められる環境で、同時に新規機能の開発も止められる状況ではありませんでした。
したがって、常にエンジニアの数は不足していて顧客数は逆に増え続けるので、必須開発要件も増えてきておりました。
どうすれば負債を避けた設計にできたのか？
先ほどのような難しい背景もありつつ、サービス開始から要件が大幅に変わって短期間での修正が求められていたので、完全に負債を避けることは不可能だったのではないかと思っております。
ただ良かった点としては、要件が変わった時点でコードベースで無理に対応せずにアーキテクチャレベルで素早く変更したので、大きな負債は作らずに済みました。
もし開発当初からOpenSearchなどの検索エンジンを導入せずにAuroraの検索で無理に進めていたら、全ての検索がAuroraに依存してしまって、大きな負債になっていた可能性が高いと考えております。
仮にもう一回やるのであれば、半年後に確実に起こることを常に思い浮かべながら設計することが大事だと思いました。
たとえば事業計画書通りに事業が進んでいく場合は、顧客数やデータ、エンプラのユーザーがこれだけ増えることは容易に想像できていました。
そのため、顧客データとの連携等はその時点で想像できたはずですが、当初はデータ設計する時にそこまで至りませんでした。もう少し長期的な視点を持ちながら設計していけば、先ほどの6つのフェーズのうち1つか2つは圧縮できて、よりお客様のためになる機能開発に時間を当てられましたね。
やはりデータやコードの特性を理解して、ボトルネックがある場合はシステムレベルで負債返済に取り組み、特に構造レベルのボトルネックがある場合は、コードレベルで無理して頑張らないことが大事だと思います。
逆に、変数に関しては無理に考える必要はないですね。たとえば、新しいデータと連携する可能性や新たな機能開発で既存のコードでは対応できなくなる可能性などですね。
事業開発計画に入っていなくて我々でコントロール不可能な部分に関しては、深く考えると開発の速度が落ちてしまうので、無理に開発する必要はないと考えています。
いかに素早くアジャイル開発を回していくかがスタートアップにとって大事です。
視聴者からの質問に答える質疑応答タイムへ
――ここからは、視聴者の方からの質問に回答していきます。まず1つ目は、「データ構造の負債を解消するために専用のメンバーを配置しているのでしょうか、それとも開発メンバーが機能アップデートと並行して進めているのでしょうか」という質問です。陳さんからご共有いただけますか。
陳：我々は全て同じメンバーがやっています。なぜなら、ここを分けると背景がわからないメンバーも入ってきてしまうからですね。 基本的に解消する際は短期間で皆で一緒にやり切るという形で進めています。
――続いてtocknさん、お願いします。
tockn：弊社も同じで、特に負債解消の専門チームは置いていません。プロダクトを開発するメンバーが解消しています。クォーターの最初の2週間は非機能系の改善に当てるといった改善ウィークも設けたりして、色んな方法でプロダクト開発と共に並行できる施策を練っている感じですね。
――続いて大島さん、お願いします。
大島：Nayoseチームは歴史が長くて大きいチームになっていて、その結果システムとしても大きくなってしまいました。そのため、チームを分割してより改善しやすくなる構造にしています。
――続いて森山さん、お願いします。
森山：弊社も機能アップデートと並行してやっていますね。 開発を進めるか、負債を解消するかを天秤にかけていて、場合によっては負債の解消を優先しています。
――最後に弓場さんはお願いします。
弓場：フツパーもチームを分けてはいなくて、開発メンバーが担う体制で今はやっています。
――続けて、「どれぐらいの時間をかけて負債を解消してきましたか」とのことですが、陳さんからお願いできますか？
陳：基本的には2〜3週間でやりきることを徹底しています。 何か構造に問題が発覚した場合は一旦開発を止めて2〜3週間で全部やりきって、無理にその先に進まないという判断をしてきました。 短期間で細かく、問題があるところだけ集中的にアタックする形ですね。
――続いてtocknさん、お願いします。
tockn：先ほどの回答と被りますが、改善ウィークみたいな形で1週間〜2週間を改善の期間に当てていますね。あとは、クォーター単位でプロダクトや非機能系の開発も含めて何をやるのかを整理する段階で期間を当てはめたりしています。
――続いて大島さん、お願いします。
大島：細かいところは2週間くらいの短期間でやって、 どうしても歴史的経緯で大規模改修が必要なタイミングであれば半年〜1年ぐらいかけて、現在動いてるものをリプレイスする形です。
――続いて森山さん、お願いします。
森山：大体メンバーは複数人いるので、一人が負債回収して、もう一人は機能開発という感じでやっていましたね。負債回収をやると大体1ヶ月ぐらいかかります。それぐらいで今回の課題などは対応していました。
――続いて弓場さん、お願いします。
弓場：今回発表したデータベースの移行に関してはいきなり全部を変えるのではなくて、ステップを区切って1ヶ月単位で行いました。
――本日のイベントはこちらで終了とさせていただきます。 登壇者の皆さん、視聴者の皆さんありがとうございました。