組織を巻き込む大規模プラットフォーム移行戦略　〜50+サービスのマルチリージョン・マルチプロダクト化で学んだステークホルダー協働の実践〜

それでは発表させていただきます
本日は他にも魅力的なセッションがある中で
このセッションを選んでいただきありがとうございます
組織を巻き込む大規模プラットフォーム移行戦略
というタイトルで発表させていただきます
よろしくお願いします
まず自己紹介させてください
杉田俊則と申します
リガロンテクノロジーズという会社で
プラットフォームエンジニアをしています
アプリケーションプラットフォームのテックリードです
社会人大学院生として
コンピュータサイエンスを学びながら働いています
本日の資料は都市0607というXのアカウントで
既に投稿させていただいています
手元でご覧になりたい方はぜひご利用ください
当社はフォートテクノロジーの力で
安心して前進できる社会を作るというパーパスを掲げています
フォートテクノロジーを掲げ合わせて
企業の法務業務を支援するプロダクトを開発し提供しています
こちらがプロダクトのラインナップです
法務契約業務の支援を中心に
様々なプロダクトを提供しています
法務領域だけでなく
経営支援においてもプロダクトを提供しています
スライド上部の赤枠で囲われたリーガルオンは
昨年の4月にリリースされた当社の主力プロダクトです
リーガルフォース、リーガルフォースキャビネという
2つのプロダクトが支援した契約ドメインを踏襲し
法務ドメイン全般をワンストップで提供する
法務プラットフォームとして生まれました
この法務プラットフォームは
これまで国内向けに販売していましたが
ついにグローバルブランドとして生まれ変わりました
1つのプロダクトを
全世界のユーザーが活用できるようになっています
リーガルオペレーションをAIエージェントで支援する
プロフェッショナル業務特化型の
最先端AIプラットフォームとして今後も成長し
お客様の思考力、結論力、牽引力を強化してまいります
本日はこのリーガルオペレーションのリリースに向けて行った
アプリケーションプラットフォームの
マルチプロダクト、マルチリージョン化の際に学んだ
ステークホルダーとの協力のあり方についてお話していきます
リーガルオペレーションは
リーガルオペレーションをリリースしてから数ヶ月後に
要件定義や基礎設計を始めました
約1年かけてリリースに至っています
アプリケーション観点では
基本的にJPとUSでソースコードを共有するため
多言語化対応を行っています
インフラ観点では大掛かりなリアアーキテクチャ
とサービスの計画メンテナンスを伴う
移行をリリース前に先にして実行しています
アプリケーションをホストするためのインフラは
GKE Google Kubernetes Engineとクラウドサービスメッシュ
必要なマネージドサービスですね
を中心としています
リリーションごとの大まかな構成自体は
リーガルオンJPとUSとで同様の構成をとっています
GKEのフリートとサービスメッシュはJPUS共通ですが
それ以外はJPUSそれぞれゲートウェイ
GKEクラスター各種のサースデータベースなどを
分離して運用しています
アプリケーションのデプロイは
Argo CDを通じて行います
アプリケーションをホストするためのインフラが
地域ごとに分かれていたのに対し
Argo CDやGitHub、セルフホスティットランナーなど
運用に利用するクラスターは
運用効率やリソース効率を高めるために
統一しています
リーガルオンテクノロジーズでは
アクパーラというアプリケーションプラットフォームで
プラットフォームエンジニアリングを推進しています
ロゴも作ってもらってプロダクトとして育てています
今回のリーガルオンUS対応のリリースを行うにあたっては
要件を踏まえてUSだけインフラを追加するという選択肢もありました
しかしアクパーラのビジョンや方向性、方針を照らし合わせて
より先を見据えた対応を行うことにしました
JPのインフラも作り直し
データとトラフィックを移行しています
アクパーラは開発者にゴールデンパスと
元老なインフラを提供し
創造的な開発に集中できるようにする
というビジョンを掲げています
ビジョンステートメントでは
課題認識や理想とする状態、実現方法を明確化しています
ラディカルプロダクトシンキングという
プロダクトマネジメントの本があって
それを参考にチームでワークショップをしながら整理しました
ゴールデンパスとは開発ライフサイクルにおいて
標準的に利用できるツールやプロセスです
それを堅牢なインフラが下支えします
ゴールデンパスのカバレッジの向上
各ステップの開発体験の向上
インフラの安定運用
提供地域と利用プロダクト拡大を
基本方針としています
こちらがアクパーラのリアーキテクチャと
移行の全体像です
移行準備では
新しいリーガルオンJPとUSが共有する
CICDのインフラと
JPの移行先となるインフラを
大規模なリファクトリングをしながら構築しています
JP、USのインフラは
レクレーション上分離して構築する必要がある
コンポーネントが多いですが
CICDなど開発用のインフラは共有しています
構築している間も移行元の旧JPのインフラでは
各マイクロサービスのテラフォームや
Kubernetesのマニフェストの変更が入るので
差分チェックツールを使いながら
追従作業を行う必要がありました
移行の本番では
旧JPから新JPにデータとトラフィックを移行します
サービスを2日間停止し
土日で実施しました
移行後は
移行元の旧JPを破棄して
USを構築しました
マイクロサービスのインフラは
拡張性のある状態にリファクタリングしたため
プロダクトチームによる
コピー&ペーストと
パラメータ修正で
マイクロサービスの構築を実現できています
リアーキテクチャと移行を行うにあたっては
次のような課題がありました
まずはマイクロサービスの開発運用の負荷です
JPだけで50以上のマイクロサービスがあるため
US向けにそのままデプロイすると
倍のサービスを運用することになります
アプリケーションをホストするためのインフラに加えて
CICDなど開発用のインフラも考慮します
機能要件も踏まえて
JP、USで共通化するもの
分離するものを区別して
対応する必要がありました
リファクタリング移行観点では
膨大な物量のテラフォーム
Kubernetesマニフェストを準備する必要があります
次にマルチプロダクト
マルチリージョンサポートです
プロダクトラインナップでも触れたように
弊社では複数プロダクトを提供しています
旧リーガロンJPのリリース時点では
プロダクトを支えるアプリケーションプラットフォームが
単一プロダクト、単一リージョンに
フォーカスした状態でした
そのため、US展開や複数プロダクトのサポートを
見据えた拡張性を担保できるよう
抜本的に進化させる必要がありました
最後に、多様なステークホルダーの存在です
移行の影響はプロダクト全体にわたるため
各フェーズで様々なチームの力を借りる必要がありました
ここからは各フェーズに登場するステークホルダーと
どのように協力し、課題を解決していったかについてお話しします
まず、計画、設計、計画、インフラ構築フェーズからです
このフェーズでは、アクパーラのリアーキテクチャと新しくリリースする
リーガルオンUS構築の全体像を描きます
アクパーラの目指す姿を意識した上で
リーガルオンJPのインフラも作り直す意思決定を行いました
意思決定の前提として、取り売る移行手段の比較検討や
現実的な移行手段が存在するのかどうかの検討設計を済ましています
そして、JPUS共通のCICDや
JP移行先でマイクロサービスをホストするインフラなど
構築作業を開始しています
先ほどの全体像の中では、この赤枠で囲んだ部分です
全体の計画と移行先CICDとインフラの構築部分を
ここで済ましています
このフェーズの主なステークホルダーは
リアーキテクチャと移行の主体となる
リーガルオンUSプロジェクトのSREに加えて
リーガルオンUSプロジェクト全体の責任者
CTO、経理財務などプロジェクトや
組織の根本になる関係者です
各ステークホルダーと力を合わせて解決した問題について
お話していきます
まず、リーガルオンUSプロジェクトでのSREです
最初は実施主体となるメンバーの誰もに
勝ち筋が見えていませんでした
アクパーラのビジョンと現状のギャップは認識しているものの
それがあまりにも影響範囲が広くて
課題設定がチャレンジングなのか
はたまた無謀な挑戦なのかを判断しかねていました
またUS低サービス提供していたものの
プラットフォームに載っているのは
リーガルオンJPだけでした
これをUSのレギュレーションに則って
運用効率も考えつつ
どこを共通化し
どこを分離すべきかを考えるのは
とても複雑な設計作業でした
さらにGoogleクラウドの
特にGKE周りの具体的な機能レベルで
設計する知見もほとんどありませんでした
これらの課題に対し
まず取り得る選択肢の整理と議論を行いました
これによってメンバー間では困難ではあるが
短期的にも中長期的にも
単純なJPの複製ではない
リアアクティクチャと移行が最適である
というふうに腹落ちができました
どう実現するかについては
愚直にすべてのコンポーネントと
依存関係の洗い出しを行いました
叩き台は私の方で作成したものの
基本的に全員で同じミロのボードを見ながら
構築作業の全体像を描き出しました
データ移行についても
AllowedbやGCSなど
具体的なデータソースごとに
何のツールでどんな処理を行えば
実現できるのかの概要を
このタイミングで検討しています
マルチレーション展開の知見については
専門家や先人の力を借りました
Googleクラウドのエキスパートや
PDMには設計相談する時間をいただいています
クラウドネクストという
Googleクラウドのカンファレンスでは
海外展開関連のセッションを聞いて
登壇者に質問させていただきました
それらの情報を参考にしながら
設計や検証を進められました
こちらは実際にコンポーネントを
洗い出すときに利用した
Miroのページです
インフラのリポジトリだけではなくて
アプリケーションリポジトリで
必要な作業も含め
全コンポーネントを洗い出しています
これにより検討の漏れを防いだり
依存関係や各コンポーネントの
作業の重さを可視化することで
クリティカルパスの特定だったり
プロジェクトマネジメントにも
大いに役立っています
次はリーガルオンUSプロジェクトの
開発責任者とCTOです
リーガルオンUSリリース自体の
不確実性が高い中
イデアアキテクチュア移行を行うと
さらに工数が増えてしまいます
さらにリーガルオンJPの
既存価格にも影響を及ぼしてしまいます
リーガルオンUSの成功にも
資するとはいえ
プロジェクトのスコープを
大きく超えてしまっています
以上の課題に対しては
短期中長期の両観点で
事業の成功に直結するという
目線合わせを行いました
リーアーキテクチャや移行を挟んでも
リーガルオンUSのリリース目標を
達成できることや
リーアーキテクチャを通して
JPのインフラ行動を
少ない変更で
変更でほぼそのまま
USに適用できるようになる
ということで
工数面の課題もクリアできます
既存のJPの移行は
最新の注意が必要ですが
可能な限り
共通化したインフラで
リーガルオンJPを稼働させることは
リーガルオンUSリリースの
リスクを低減します
プロジェクトのスコープについては
掲げられた事業戦略を実現するための
リーアーキテクチャをやるのは
最後のチャンスであるということを
理解いただいて実施に至りました
最後は経理財務です
リーアーキテクチャの成果として
得られるのは
レギュレーション対応と
運用効率のバランスを踏まえた
各インフラコンポーネントの分離と統合です
その結果
請求アカウントがひも付く
Googleクラウドプロジェクトが
JP、USそれぞれと
1対1でひも付くものもあれば
1プロジェクト内で
JP、US両方を含むものも出てきます
そのように混在した状態では
適正に会計処理をするのは
困難な状態でした
これに対しては
処理を複雑にしてまで
達成したいことを説明した上で
合理的な会計処理ロジックを
導き出すための
前提情報として
アーキテクチャ図を見ながら議論を行いました
それにより
短期から中期で整理しておきたい
予算計上方法であったり
今後のビジネス状況を踏まえて
最終的に目指す姿を
合意することができました
最終的には
このような内容で合意しています
JP、USのコスト把握や
請求は原則分離しますが
利用割合や共通プラットフォームの
性質に鑑み
一部はJPに寄せます
状況に応じて
安分方法を今後変えて
別途変えていくという整理になりました
このフェースで得られた気づきは
次のようなものです
まず明確なビジョンを持つことの大切さです
リアーキテクチャや
移行のような大規模なプロジェクトは
単に目の前のプロスコンスだけでは
容易にやらない方向や
妥協的な方向に倒れてしまいがちです
覚悟を持って決断し
多くのステークホルダーと協力して推進するためには
ビジョンが不可欠であるというふうに感じました
一方で短期的な成果も上げなければ
中長期的な投資への信頼も得られないので
短期的な成功へのコミットも不可欠です
次に身近なメンバーもステークホルダーとなることです
大きなプロジェクトほど共通の認識を持つのが難しいので
多少非効率であっても
同じものを見ながら整理・可視化する時間は削れません
最後に自分が普段関わるのが少ない
専門性を持つメンバーと調整することもあると思います
相手から見てこちらの実現したいことが
把握しづらい部分もあると思うので
こちらもキャッチアップしながら
相手が理解しやすい情報を整理して
相互理解をできるようにします
次のフェーズはマイクロサービスの再構築です
リーガルオンJPの移行先にマイクロサービスを再構築します
ただし移行元・移行先の並存期間では
移行元に変更が加わり続けてしまうので
差分を把握して追従し続ける必要があります
全体像の中の移行準備部分です
今回はリーガルオンJPプロジェクトのSREとTPMが関係してきます
まずリーガルオンJPのSREです
リーガルオンJPのプロジェクトを進めていたSREは
JPUS共通のCICDインフラや
JP移行先のサービスインフラ構築に苦戦しており
移行先のマイクロサービスの構築まで手が回りませんでした
普段はそれぞれ別のOKRを追っていたため
十分に作業状況や設計が共有できていませんでした
その中で実質300マイクロサービスを
2週間程度で手分けして構築する必要があります
ヘルプを求めるにしても
既存のリーガルオンJPの課題を解決する方向で
参加してもらえるよう方針の明確化を行いました
設計や状況の共有も強化しています
サービス数は減らすことができないので
ツールを利用して多少は楽ができて
なおかつ移行後も均質な構成で
継続的にメンテナンスしやすい状態を目指しました
その中で行ったこととして
Kubernetesのマニフェストやテラフォームの標準を定めています
ファイルやリソースの命名から
基本まで幅広く書いています
移行先のマイクロサービスを構築しながら
改正した部分もあります
旧リーガルオンJPのリリース時は
規約を定めないまま
サービスごとにSREが分担して構築したため
人によって書き方にばらつきがある状態でした
今回のプロジェクト以前も
基本や構成を揃える試みはあったんですが
とても量が多く
稼働中のサービスに影響を与えずに
実施するのはスピードがなかなか出ませんでした
今回の再構築を機に一気に
ディファクタリングしています
移行方針を実現しやすくための
モジュールやツールも開発して活用しました
スターターキットというのを作って
マイクロサービスのインフラ構築で
共通に必要となるリソースを作成するための
テラフォームモジュールを準備しています
Kubernetesのネームスペースと
それに対応するGoogleクラウドプロジェクトや
サービスアカウント
アルゴCDアプリケーションなどのリソースを管理しています
次に紹介するKHGENというのは
サービス名などのパラメータを与えると
8割以上のユースケースをカバーする
サーバー、ワーカー、クローンジョブの3種類に分類した
ワークロードのKubernetesマリフェストを生成します
引きの要件であったり
組織のベストプラクティスの遵守が容易になりました
スターターキットとKHGENの導入で
SREの作業が効率化できただけではなくて
自律的にマイクロサービスのインフラも
各プロダクトのチームが
セルフサービスで構築する下地を
着くことができました
SREの次はテクニカルプログラムマネージャー
TPMです
弊社のTPMはマネジメントを4分類した場合の
テクニカルマネジメント
プロジェクトマネジメント
プロダクトマネジメントの3つ
ピープルマネジメント以外を担います
多様なステークホルダーと協力が必要な中
TPMの協力は不可欠でした
SREがリアーキテクチャや
移行の技術検証などに集中すべく
特にデータトラフィック移行フェーズで
鍵となるプロダクトチーム
セールスチーム
サポートチームの間に立って
調整やコミュニケーションを担ってもらいました
このフェースで得られた教訓です
USとJPのSREなど
同じプラットフォームを支えるメンバーであっても
普段マイルストーンが異なれば
情報がシンクできているとは限りません
一緒に作業を進めるタイミングでは
ドキュメントの読み合わせや
デイリーなど
短周期の会議も利用して
協力の密度を高めます
作業が切迫すると
人海戦術で切り抜けたくなる場面も出てきます
そんな局面であっても
一度立ち止まって
作業対象の量を眺め
ツール整備や
自動化の損益分岐点を
見極める必要があります
機能提供に直接かからないプロジェクトは
初期の段階では
比較的関心が集まりづらいです
プロジェクトの影響範囲が広いのであれば
積極的にTPMなど
多くのステークホルダーとの関係性が
強いロールの人に情報を伝えて
深く入ってもらうのはとても大事です
いよいよデータトラフィック移行のフェーズです
このフェーズでは
週末にサービスを止めて
データトラフィックを移行します
事前に本番と同じ手順で
リハーサルを行い
問題がないことを確認しました
全体像の中の移行の本番部分です
ステークホルダーは
プロダクトチーム
QAチーム
セールスチーム
PDM
サポートチームと多岐にわたります
プロダクトチームとのやり取りは
今回のプロジェクトで
一番反省の大きいものでした
リアーキテクチュアや移行には
なるべく巻き込まずに
機能開発に集中してほしい
というのが方針でした
一方でどうしても
個別のマイクロサービスが
DNSだったり
SaaSのWebhookだったり
インフラに深く関わっている部分は
対応していただく必要がありました
その最低限の関与で済むはずが
データトラフィック移行の
リハーサル時に
コール漏れが発覚しました
サービスのオーナーシップは
マイクロサービス分のインフラも
プロダクトチームに
渡していく準備を進めていましたが
リガルオンJPの移行先への
インフラ構築は
SREで実施していました
インフラに密に結びついている
部分の対応は
SREと同じように
検証の上
手順書を書いて
リハーサルに参加してもらっています
そこまでは良かったんです
リハーサル時に
考慮の漏れがあることが
発覚しました
リアーキテクチャ時に
GCSのバケット名を
変更したのですが
DBの中に
バケットのフルパスを保存して
ファイル参照時に
読み取るケースがあり
データを移行した先で
GCSバケットからファイルが取得できない
というようなケースがありました
これを受けて
全プロダクトチームが
開発の手を止めて
最優先で同様のケースがないかを
調査する時代になってしまいました
本番前に気づくためのリハーサルですし
より早く深く参加してもらえば
見つかったかは分かりません
それでも変に気を使ってしまったのが
あだになった感は
痛めないかなと感じています
次にQAチームです
自動テストの整備が発展途上の中
全機能のリグレッションテストが必要でした
通常の機能開発のQAは
一時ストップしていただいて
リハーサル本番を通じて
QAチームほぼ総出で対応してもらっています
最後にPDM
セールスチーム
サポートチームです
2日間にわたってサービスを停止するため
正確かつ漏れなく
顧客にメンテナンス時間を
伝えてもらう必要がありました
2日間停止する場合には
1ヶ月前の告知が必要なルールになっています
ただ作業規模的に
1ヶ月前段階では
移行日をぴったり決めることは難しかったです
一方で
移行元の変更を
移行先に追従させたり
一定期間はデプロイを止める必要があったりしたため
余裕を持たせすぎることもできないという厳しい状況でした
結果
リハーサル時の問題発覚や
QAテスト後の問題対応が間に合わず
当初の移行日から
2週間程度後ろ退出することになりました
リーガルオン前身のリーガルフォースや
リーガルフォースキャビネからの
お客様の存在を意識できて終わらず
たびたび
社内調整を強いる形で
ご迷惑をおかけしてしまいました
このフェースで得られた教訓です
特定のステークホルダーへの
過度の気遣いは問題発生時の影響を悪化させてしまいます
ステークホルダーである以上は
遠慮しすぎずリスクを共有し
共に立ち向かなければなりません
今回実施したようなサービスの前提子
データ前移行という原始的な移行手段は
おそらくもう二度と取れないと思っています
移行元移行先のデータを同期する仕組みや
移行難易度を下げるための下準備エンジニアリングを
行う必要があります
最後に外向きのスケジュール間の合意は
しなくて済むに越したことはありません
しかし不確実性が高い中で
コミットする必要がある場合は
万一変更する際のタイミング基準を決めて
あらかじめ合意しておく必要があります
最後に本日のお話のまとめです
プラットフォームの規模が大きくなると
大胆な変更の難易度が上がります
構成要素やステークホルダーが増え
複数リージョンにまたがっていくと
ある程度分離していても
共通のコンポーネントもあって
B2Bのサービスでも停止しているタイミングが
ないケースもあります
顧客数や機能次第で
リスクの強要度も下がっていきます
それであってもマイグレーション
リアーキテクチャー
デファクタリングは
強力な技術的不採の返済手段です
エレガントパズルという本でも
マイグレーションが重要なのは
技術的不採に対して意味のある
進歩を遂げるために利用できる
唯一の方法だからとまで書かれている
ことです
移行は段階的に進めるのに
こうしたことはないですが
無理になることもあります
多様なステークホルダーと協力し
やりきる覚悟を持ったときに
本セッションでお話した教訓が
参考になれば幸いです
今年の7月に開催された
Google Cloud Next 東京では
リーガルテックのグローバル展開を実現する
GKEを活用したアプリケーションプラットフォームへの進化というタイトルで
本日と同じく
リーガルオンUSリリースに向けたアプリケーションプラットフォームの
改革のお話をさせていただきました
こちらではリーアーキテクチャと
移行の技術的詳細や
本日振られなかったセキュリティマルのトピックを扱っています
また昨年11月のクラウドネイティブデイズでは
アプリケーションプラットフォーム誕生の期限のお話をしています
今回リーアーキテクチャをせざるを得なくなった課題の技術的詳細が分かるような内容になっているので
こちらもぜひよろしくお願いします
以上で発表を終わります
ご清聴いただきありがとうございました
ありがとうございました
それではこれよりQ&Aセッションに移ります
質問がある方はスクリーンに表示されています
QRコードよりお願いいたします
もしないようでしたら私から簡単な質問をさせていただきます
今回のリーアーキテクチャにおいて非常に困難な課題だったと思うんですが
その価値筋が見えてないとかイメージができないっていうステークホルダーに対して
一番聞いたデータとか数字とかってそういう感覚を持たれてたりしますか
そうですね
その価値筋が見えないというところは特に同じプロジェクトの中にいたメンバーなんですけれども
作業の全体像とそれを構成するすべての要素を洗い出して
みんなで一緒にどういう順番で進めていけば実現できるかであったり
どういう依存関係があるのでこれをやってこれをやってみたいなところを整理していく
みたいなところをみんなでやっていくっていうところが大きかったかなと思います
やっぱり経営層の方々に対しては
目の前のプロジェクトがちゃんとスケジュール通りに収まるっていうところを説明した上で
今後どういうところを目指していてそのためにはこれが必要なんですっていうところを
具体的な構成感とかを示しながらお話しするっていうところが特に大事だったんじゃないかなと思っています
ありがとうございます
他に質問ございますでしょうか
もう少しお待ちしたいと思います
この間もし登壇者様の方で何か質問いただきました
マイクロサービスごとにインフラ移行をするのではなく
プラットフォーム全体でインフラ移行をするに至った理由は何でしょうかという質問です
そうですねこれが私たちのアーキテクチャの性質によるのかなと思っているんですけども
今回移行しなければいけなかったっていうのが
もともとそのリーガルオンJP移行元のサービスのところで
Kubernetesのネームスペースに対応するGoogleクラウドのプロジェクトがあってみたいなところになったんですけども
その時のGoogleクラウドプロジェクトの命名規則が
マルチプロダクトマルチリージョンっていうのを実現できないような命名の規約になっていたっていうのが前提としてあります
それをマルチプロダクトマルチリージョンで作り直すってなった時に
その命名規約ごと作らない直さないといけない
Googleクラウドのプロジェクトの名前も変えないとちゃんと整合性取れないっていうところで
そうなった時に全部のマイクロサービスのプロジェクトのGoogleクラウドのプロジェクトの名前だったり
その前提となる土台となるインフラのところのGoogleプロジェクトの全部作り直さないといけないっていう風になったのが大きいです
部分部分でサービスごとに移行していくっていうのも考えたんですけれども
2つのインフラを準備してトラフィックを部分的に流していくっていうのが
多分実現可能じゃないこともないかもしれないんですけども
2つを併存させるっていうのが結構大変である
サービスの数も50とかありますしコストも結構それぞれかかるので
今回はサービスで停止して全部移行した方が良いのではないかっていうところで
全部移行するっていう判断になってます
ありがとうございます
追加で質問いただいておりますが
お時間が迫ってまいりましたので
こちらでセッションを終了とさせていただきます
皆様今一度盛大な拍手をお願いいたします
ありがとうございました
会場 拍手