はじめに
LegalOn Technologiesが提供する「LegalOn: World Leading Legal AI」は、契約書ドラフト・レビューや案件の管理、法務相談まで、法務業務をワンストップで支援する革新的なサービスです。リリースから1年半、企画開始から約2年半が経った今、プロジェクト立ち上げの背景、開発の進め方、これまでの振り返りや今後の展望、さらには技術面での学びまでを、全9回にわたるブログシリーズとしてお届けしていきます。
第5回となる本記事では、「LegalOn」を支えるインフラストラクチャに焦点を当て、その設計思想、採用された技術、そしてリリース後に見えてきた課題と今後の展望について、CTO深川がStaff Platform Engineerの杉田に話を聞きました。
- 杉田寿憲：Staff Platform Engineer
開発初期の設計思想と技術選定
アプリケーション開発を止めないための工夫
深川 杉田さんには第4回の全体アーキテクチャ設計と技術選定編 でもお話いただきましたが、今回はインフラ編ということで、インフラに絞ってお話を伺っていきたいと思います。よろしくお願いします！
杉田 よろしくお願いします！
深川 ではまず最初に開発初期のインフラ設計では、特にどこに注力したんでしょうか？
杉田 アプリケーション開発が滞りなく進むよう、クリティカルパスを一通りきちんと通したことです。インフラとアプリケーション構築のどちらもゼロからのスタートだったため、アプリケーション開発をブロックしないよう、必要な構成要素を先回りして整えていきました。
たとえば、アプリケーションのテンプレートやスキーマの管理機構、開発環境、CI/CDの共通設定など、アプリケーション開発で使うであろうものから順番に用意していくようにしました。リリースのタイムラインも決まっていたので、とにかく詰まりが起きないよう注力していました。
深川 インフラがボトルネックにならないように、最初の“土台づくり”に徹したんですね。
杉田 はい、特に初期に取り組んでおいて良かったと思っているのは、将来的なマルチリージョン・マルチプロダクト展開を想定して、リポジトリの構成を初期段階で整理しておいたことです。目の前のタスクだけを見れば不要に思えるかもしれないですが、そこをやっておいたおかげで、あとからサービスを増やすときの整合性が取りやすくなりました。
深川 インフラレイヤーはアプリケーションレイヤーと比較すると一度行った意思決定の手戻りコストが大きいことが多いですからね。できる限り将来を見越した設計を行うというのはとても大事ですね。
拡張性と標準化を見据えた構成と選定
深川 インフラレイヤーの技術選定の妥当性についてはどう感じていますか？
杉田 クラウドプラットフォームをAWSとGoogle Cloudの両方からGoogle Cloudに統一したことは大きな成功点だったと思います。「LegalOn」の技術要素としてコンテナやそのエコシステムとの親和性が高く、Google Cloudからの手厚いサポートも受けられたことで、技術的な発信強化にも繋がりました。一方で、市場にはAWSユーザーが多いため、Google Cloudを初めて使う開発者へのサポートやイネーブリングは今後の課題です。
他にも様々な技術を新規採用しました。DBにAlloyDBを採用することで、ライブラリなどPostgreSQLの既存のエコシステムを活用しながら、さらなるスケーラビリティやパフォーマンスを得られています。フロントエンドとバックエンドサービス間通信ではConnectプロトコルを採用し、サービス間通信にgRPCを利用する中でスキーマ駆動の開発を維持しつつプロキシの運用コストを低減できています。
深川 AlloyDBやConnectの採用は国内でもまだあまり事例がないチャレンジングな選択でしたよね。ちなみに、AlloyDBの導入を決断するまでどのようなステップを踏んだのでしょうか？
杉田 組織のセキュリティ要件を満たせるかを確認するため、まずは権限管理など仕様のチェックを行いました。パフォーマンス面では、本番環境と同じ構成で負荷試験を実施し、定められた非機能要件のトラフィックを問題なく捌けるかどうかを検証しました。
深川 なるほど、入念な準備をされてリリースまで持っていったんですね。セキュリティの話が出ましたが、他にセキュリティ面で気をつけたことはありますか？
杉田 プルリクエスト作成時に自動でフィードバックを返せるようにしたり、セキュリティを考慮した設定でアプリケーションが作られるようにしたりと、リリースまで1年しかない限られた中でも可能な工夫を積み重ねていきました。守るべきセキュリティ要件や一般的なプラクティスをふまえてProduction readiness checklistとして整理し、現在でも改善しています。当時はSREチームが中心となってチェックすることでリリースまで漕ぎ着けました。
深川 短期的な開発スピードと、長期的な拡張性のバランスって難しいと思うんですが、なにか工夫したことはありますか？
杉田 難しいポイントでしたね。デプロイ方法を段階的に変えていったのは工夫した点の一つです。当初はアプリケーションを開発して、まずは「動く状態を作る」ことを優先していたので、プルリクエストをマージしたらデプロイされるようにするなどスピード重視で進めていました。
リリースが近づくにつれ、バージョン管理やQAの厳格化を段階的に進めていきました。デプロイ方法を変える際には、Argo CDの既存機能を使うことで大きな困難もなくシームレスに行えたと思っています。
深川 今回の構成で特にチャレンジングだった点はどこでしょうか？
杉田 短い開発期間で各チームが独立して開発・デプロイできるように、サービスの粒度を比較的小さくする構成を採用しました。各サービスをバラバラに開発することで車輪の再発明のような非効率な開発になってしまうのを防ぐため、アプリケーションテンプレートやインフラコードの作り方、デプロイ方法などを標準化し、開発ライフサイクル全体がスムーズに回るようにインフラやプラットフォームの側面から支援しました。技術的なチャレンジではありましたが、アプリケーションプラットフォームとして貢献できたのではないかと思っています。
深川 成果を上げた一方で大変だったこともあったのではないでしょうか？
杉田 大変だったことで特に印象に残っているのがサービス毎のインフラ構築です。50近いサービスそれぞれのインフラを準備する必要がありました。ヒアリングシートを用意して効率的な情報収集に努めたものの、TerraformやKubernetes manifestのモジュール化や規約整備を行っていなかったため、サービスの担当者がそれぞれ一からインフラコードを書く形になってしまいました。
深川 50個ものサービスを一つずつヒアリングしてコードを書いていく、というのはたしかに大変な作業ですもんね。
リリース後に見えてきた課題と進化
拡張性とスケーラビリティの壁
深川 リリース後、実際にユーザーに使われ始めて、当初の想定と違った点や新しく見えてきた課題はありましたか？
杉田 様々な観点での拡張性に課題を感じています。リリースに向けてはスピードが最優先だったので、立ち上げ時点では「まず動く状態にすること」に意識を集中していました。実際にサービスが育ってくると、いくつかの側面で設計が追いついていなかった部分が出てきました。
まず1つ目が「人的拡張性」です。当初、SREが各サービスのインフラ構築を一手に担っていたのですが、サービスが増えるとその体制ではスケールしなくなってしまいます。各チームの自律性を高めないといけないフェーズに入ったんだなと感じました。
2つ目は「地域的拡張性」です。「LegalOn」は日本向けを前提に作られていたため、USなど他の地域への展開を考えたときに、インフラ構成そのものが足かせになる場面が出てきました。
そして3つ目は「プロダクト的拡張性」です。元々「LegalOn」専用の設計をしていたのですが、本来は複数プロダクトにまたがって使い回せるはずのコンポーネントもあり、考慮が足りない部分もあったと思います。
深川 いずれも初期には気づきにくいけど、会社が進化していく上では避けられない課題ですね。
杉田 そうなんですよね。当時も将来的な展開は意識していましたが、どうしてもリリース優先で動いていたので、拡張性を深くまで織り込んだ設計にはなっていませんでした。振り返ると、特に「地域的拡張性」や「プロダクト的拡張性」は立ち上げ期だからこそ、あえて立ち止まって長期目線で設計しておくべきポイントもあったなと思います。
深川 とはいえ、リリースしてユーザーから評価されないことには拡張性も何もないので、当時の状況下ではできる限りはやったな、という感覚はありますね。あと単純にもうちょい時間がかかると思ってたマルチプロダクト化やマルチリージョン化がすぐに来たのは会社の進化のスピードが想像を超えてましたね。
リファクタリングと運用改善の取り組み
深川 色々課題も見えてきたということですが、そうした課題に対してはリリースしてからどのような改善を進めてきましたか？
杉田 まずはインフラ構成自体の見直しですね。マルチプロダクト・マルチリージョンへの対応ができるように、大規模なリファクタリングと移行を段階的に進めてきました。インフラはアプリケーションのように自由にリファクタリングできないという難しさがあります。たとえば、Google Cloudでは、プロジェクト名を後から変更できないという制約があります。そのため、マルチプロダクト・マルチリージョンを実現するための命名規約を定めた上で移行先のインフラとアプリケーションを構築し、全サービスのデータやトラフィックを移行する必要がありました。
深川 そういう構成の見直しって、技術的な工数もさることながら、ビジネス側とのすり合わせも大変ですよね。
杉田 ビジネスとして優先して提供すべき価値がある中で、社内の関係者との合意形成やスケジュール調整など、非技術的な部分でも苦労したところはありましたね。
深川 他にも、運用上で改善してきた点があれば教えてください。
杉田 リリースを優先することでTerraformやKubernetes manifestを通じた個別サービスのインフラ設定がサービスごとに異なるスタイルになってしまいました。これにより、リリース後にSREやプロダクトチームが運用していく上での認知負荷が大きくなったという反省点があります。インフラ設定をサービス横断的に一括更新する際に、サービス毎にインフラコードの書き方が異なれば自動化も難しく、手動更新では時間がかかり漏れも生じてしまいます。ベストプラクティスや組織の規約も一様に適用できません。記述の自由度が高く、幅広い知識を要するため、プロダクトチームが自律的に運用していくことも困難でした。
この経験を踏まえ、Terraformのユースケースに沿ったモジュール化や、Kubernetes manifestのワークロード種別に応じた生成ツールの導入 を通じて改善を図りました。個別サービスのインフラを構築するとき、サービス名やチーム名などのパラメタを入力することで、サービス共通で必要なインフラリソースが作成されます。これにより、運用負荷や新規サービス構築に必要な工数は大きく低減し、プロダクトチームによるセルフサービスも徐々に行えるようになってきました。
深川 各IaCの移行は長い闘いでしたよね…GKEの運用も継続して改善されていると聞きました。
杉田 そうですね。GKEのAutopilotを活用して最低限の運用コストで運用できているのですが、コンピューティングリソースのコストは最適化の余地が大きいです。リリース後はSpot Podや一部のQA環境を一時的に停止できる仕組みを導入し、改善しています。
これからのインフラと開発体験のビジョン
深川 リリースから1.5年たちましたが、これから先2年を見据えたインフラやプラットフォームの理想像について聞かせてもらえますか？
杉田 今後は、新しいプロダクトやサービスを立ち上げるときに、短期間かつSREチームに依存せずに完結できる状態を目指したいと考えています。現在新規サービスインフラ構築は早くて1週間、場合によっては2週間ほどかかってしまっているのですが、それを「1日以内」で、かつ必要なインフラ準備をプロダクトチームのみで終えられるようにするというのが理想です。
深川 そこまで短縮できると、開発サイドとしてはかなり助かりますよね。
杉田 そうですね。サービスの立ち上がりを早くするというのは、プロダクトの成長を加速させるうえでとても重要です。そのために、AIワークフローなどの導入も見据えていて、AIフレンドリーな開発基盤も並行して検討を進めています。
深川 運用面での改善についても取り組まれているそうですね。
杉田 はい。これまでの開発では、機能をとにかく素早く届けることが最優先だった部分もありますが、今後は信頼性の担保にもより一層注力していきます。エラーが発生したときにそれを担当するチームに通知することや、どの程度エラーを許容してビジネス価値を加速させていくのかを定量的に判断するためのSLOやSLIを定義し、オブザーバビリティツールを整備していくのは直近の課題です。
深川 そういった仕組みがあると、たとえば障害時の優先度判断や対応方針の整理もしやすくなりそうですね。
杉田 そうですね。さらに今後は「LegalOn」だけでなく、複数のプロダクトを横断して支えるプラットフォームが求められるフェーズにも入ってきています。プロダクト横断的に共通整備する部分と、プロダクトの裁量で最適化する部分をどうバランスさせながらいかに継続的に改善していくかが課題です。引き続き、開発者が創造的な開発に集中できるプラットフォームを目指します。
仲間募集！
LegalOn Technologies では、「Product Centric（全員がプロダクトの価値向上のために活動する）」 を大切にし、学ぶことに前向きで、挑戦を楽しめるエンジニアを募集しています。今回の記事で触れたような技術的な挑戦や、チームで課題を解決していくプロセスに興味を持たれた方は、ぜひ以下の採用サイトをご覧ください。皆さんのご応募をお待ちしております！
次回は、「第6回「LegalOn」誕生の裏側：フロントエンド編」をお届けいたします。
