こんにちは、株式会社LegalOn TechnologiesでPlatform Engineerをしている杉田（@toshi0607）です。
先日、CloudNative Days Winter 2024で「50以上のマイクロサービスを支えるアプリケーションプラットフォームの設計・構築の後悔と進化」と題し、LegalOn TechnologiesにけるPlatform Engineeringの取り組みについてお話してきました。前編では、「LegalOn Cloud」を短期間でリリースするために行った工夫と後悔を紹介しました。この記事では、Platform Engineering Advent Calendar 2024の25日目の記事として登壇内容の後半部分を書き起こします。
マルチプロダクト・リージョンを支えるプラットフォームへの進化のための取り組み
ここからはアプリケーションプラットフォームの進化のための取り組みについてお話しします。
人的拡張性の確保
まず、人的拡張性確保のための取り組みです。
プラットフォームの目指す方向性を明確にし、開発者が認知負荷低く自律的に開発できるしくみを整えています。
私たちは、アプリケーションプラットフォームのビジョンとして「開発者にゴールデンパスと堅牢なインフラを提供し、創造的な開発に集中できるようにする」を掲げました。
ビジョンステートメントでは、課題認識、課題はなぜ許容できないのか、理想とする状態、実現方法を明確化しています。『ラディカル・プロダクト・シンキング』というプロダクトマネジメントの本があり、それを参考にチームでワークショップをしながら整理しました。
ゴールデンパスとは、開発ライフサイクルにおいて標準的に利用できるツールやプロセスです。それを堅牢なインフラが下支えします。
ゴールデンパスのカバレッジの向上、各ステップの開発体験の向上、インフラの安定運用、提供地域と利用プロダクト拡大を基本方針としています。
ゴールデンパスのカバレッジ向上
ゴールデンパスは、Plan → Build → Test → Deploy → Operate のソフトウェア開発ライフサイクルにおいて、標準的に利用できるツールやプロセスを指します。
リリースに向けて開発ライフサイクルで標準的に利用できる様々なツールを開発してきましたが、課題はまだまだ山積みです。課題に応じて、継続的負荷試験環境、Feature flag、脆弱性通知など、開発者から望まれているものは多いです。
素早く、迷わず開発・運用できるように、開発基盤、プロジェクト推進、IT & Securityなど、強みの異なる関連チームと協力・分担しながら改善を進めています。
開発ライフサイクル各ステップの開発体験向上
カバレッジを広げるだけでなく、開発ライフサイクル各ステップの開発体験を向上することも重要と考えています。開発者が自律的に開発・運用できるように、ツール利用やプロセス上の課題を解決し、利用するのに必要なスキルを身につけるサポートをします。ツール開発・インフラ抽象化、ドキュメント整備、トレーニング、オフィスアワーなどにも取り組み始めています。
高信頼性インフラの安定運用
プラットフォームの直接的な顧客は開発者ですが、最終的に価値を届けたいのはプロダクトのユーザーです。土台となるインフラの開発・運用は引き続き行っています。可用性、性能・拡張性、運用・保守性、セキュリティ、レギュレーション準拠、コストなど、非機能要件 +αを担保し最適化します。
プロダクト・地域の拡大
こうして完成度を高めていくゴールデンパスや堅牢なインフラは、プロダクトやサービス提供地域が増えても、開発体験と非機能要件＋α 準拠を維持することも明確にしています。
人的拡張性の確保 ～ビジョンを実現するための原理原則～
ビジョンを達成するための原理原則も定めています。私達がサポートしていくユースケースは幅広いです。そのため、なんでも柔軟にできる状態は目指しません。
具体的には、
- 個別最適よりも全体最適
- プラットフォームのプラットフォーム
- 選択と集中
を掲げています。
個別最適よりも全体最適
まず、個別最適よりも全体最適です。
8割のユースケースをカバーするデフォルトを提供するようにします。エッジケースを無理に抽象化・標準化せず、基本要素と組み合わせて利用できるようにします。
また、同一ユースケース実現のために複数手段を提供しません。その代わり開発・サポートを集中させ、開発体験を高めます。
さらに、課題を解くべき場所を比較衡量します。同じ課題に対し、アプリケーション、インフラ、プロセス、のどこで解決するのか検討し、最適な場所で解決します。もちろん領域横断的な課題として協力して進めることもあります。同じ課題に対してバラバラに動いたり、最適ではない場所で無理やり解決しないことが大事です。
プラットフォームのプラットフォーム
つぎは、プラットフォームのプラットフォームです。
あらゆるユースケースをカバーするプラットフォームを目指しません。検索や機械学習など、専門性の高い分野については、プラットフォームインフラやコンポーネントを可能な範囲で提供します。これにより、複雑で専門性の高いサブシステムの開発と運用を担うチームの認知負荷を低減します。
選択と集中
最後は選択と集中です。
課題は日々生まれ、中長期的な課題を解くことから注意を遠ざけてしまいます。目先の問題解決も重要ですが、解決に複数のステップを要するより大きく長期的な問題を解決することにも意識を向けられるようにします。また、限られた時間の中で、解決することで大きな成果が得られる課題にフォーカスします。作らずに目的が果たせるなら作りません。
人的拡張性の確保 ～アプリケーションプラットフォームと開発者～
ここからはアプリケーションプラットフォームと開発者の関係性です。開発者がSREメンバーに依頼する構造をどう変えていくとよいでしょうか？
私達はアプリケーションプラットフォームの対象ユーザーを開発者とするプロダクトとして継続的に育てることにしました。いわゆるPlatform as a Productです。
プロダクトであるからには名前と象徴的なロゴが必要ということで、準備しました。「Akupara（アクパーラ）」と名付けました。
Akuparaのロゴは、インド神話に登場する亀の王がモチーフになっています。LegalOn Technologiesのプロダクトやプラットフォームをわけへだてなくどっしり支えるプラットフォームに思いを馳せて名付けました。ロゴは会社のロゴをベースに、亀を想起させるデザインです。社内のデザインチームに依頼して作成してもらいました。
プロダクト開発のプラクティスを生かし、周知徹底
プロダクトであるからには、プロダクト開発のプラクティスを活かします。実在する課題を最適な方法で確実に解決するために、定性的・定量的に課題を把握し、機能追加や改善を周知します。
デベロッパーサーベイに始まり、ユーザーインタビュー、課題の投稿・投票、ベータテスト、リリース、ニュースリリースというサイクルを確立していきます。
デベロッパーサーベイでは、四半期毎に開発ライフサイクル上のユースケースの実現具合の評価と課題把握を行います。また、ユーザーインタビューでは、開発者の課題を深堀りします。
課題の投稿と投票を行うしくみも準備します。デベロッパーサーベイやユーザーインタビューのようにこちらから情報を集めるだけでなく、任意のタイミングで投稿や議論ができるようにする取り組みです。
また、プラットフォームの機能公開時には、ベータテストを行います。全サービスが利用するTerraformモジュールなどは、変更の影響範囲が大きく、一度出したインターフェースとしてのvariableの破壊的変更は難しいです。そのため、最初に一部のチームに協力してもらってフィードバックを得てから全体に展開します。
最後はニュースリリースです。便利な機能が出ても認知されていないことは多いです。そのため、新しく利用できるようになったゴールデンパス、改善されたユースケース、活用事例を周知します。
ロードマップの可視化
ロードマップも示します。
- 開発ライフサイクルでサポートされるユースケースやそれを実現するアプリケーションプラットフォームの機能・ツールセット
- ユースケースの実現を阻害する課題
- 課題の優先度と解決時期
こうしたように、開発者にとってAkuparaが「自分たちの開発ライフサイクル上の課題を継続的に解決してくれるプロダクト」と期待できるようにします。
ロードマップは、現在整理しながら進めています。紫色が開発ライフサイクルの区分、青色が実現したいユースケース、緑色が利用ゴールデンパスを表します。その下に各四半期で解決される課題をユースケース別に並べています。
開発ライフサイクルを認知負荷低く、自律的に回せるようにする
プラットフォームをプロダクトとして提供することで、開発者がSRE & Platformメンバーへの依頼を介さず、開発ライフサイクルを認知負荷低く自律的に回せるようになることを期待します。
これまで、開発ライフサイクルの中にデプロイ設定やインフラ構築に関し、開発者からSREメンバーへの依頼する構造がありました。
これを開発チームがフルサイクルを担い、SRE & Platformメンバーがプラットフォームの開発・運用に一層フォーカスできる形にシフトしていきます。
インフラについては、レイヤー毎にインターフェースを設けています。
サービス共通のインフラの上に乗る個々のサービス用のテナントについては、Starter-kitというTerraform moduleを開発しています。
さらに、そのテナントで稼働するワークロードは、Kubernetes manifestを生成するツールを開発しています。
標準的なユースケースから外れるものは、素のTerraformやKustomizeで書くことが可能です。開発者によるセルフサービスといっても、開発者にすべてを公開するのではなく、抽象化されたしくみやインターフェースを提供することで認知負荷を低減します。
開発者がプラットフォームをプロダクトとして利用できるようにすることで、プロダクトチームとプラットフォームチームは次のような役割分担をします。
プロダクトチームは、自サービス固有のアプリケーションとインフラの構築、テスト、CIワークフロー設定、CD設定、トラブルシューティング、SLOの維持に責任を持ちます。
プラットフォームチームは、プロダクトチームが自律的な開発・運用を達成するためのツールセットの提供、共通インフラの運用、問題解決のサポート、信頼性を担保するためのプラクティスのイネーブルメントに責任を持ちます。
ただし、急速かつ一律セルフサービスに切り替えられるものではないと考えます。チームの状況やコンポーネントを扱う難しさに応じて段階的に変えていく予定です。
地域的拡張性の確保
つぎに、地域的拡張性の確保です。
これを実現するために、プラットフォームのビジョンに基づいた構造へ移行します。
Google Cloud Project IDとKubernetes namespaceは、国や地域を表現でき、よりサービス名にスペースを残す命名規則に変更します。これにより、サービスやプラットフォームコンポーネントのGoogle Cloud Projectは国や地域ごとに分離できます。また、Google Cloudフォルダや適用するポリシーの分離を実現しやすくなります。
ただ、言うは易しです。Google Cloud Project IDは一度決めたら変更できません。そのため、一からインフラや個別のサービスを作り直し、データとトラフィックを移行が必要です。短期的に見るとなかなか大変です。中長期的に見ると、地域的・プロダクト的な拡張性を得る恩恵は大きいと判断しました。まさに今取り組んでいます。
プロダクト的拡張性の確保
プロダクト拡張性の確保については、プロダクト横断的なコンポーネントの特定と切り出しを行います。
プラットフォームのコンポーネントをすべて洗い出し、カテゴリ分類したり、地域やプロダクトで分離すべきか共有すべきか整理したりしました。スライドのスクリーンショットは極一部で、全体では101行になりました。
これはProto管理基盤の例です。
「LegalOn Cloud」は、アプリケーションリポジトリでprotoファイルを管理し、BSRで生成コードをライブラリとしてホストするというお話をしました。しかし、周囲に目を向けてみるともう少し事情は複雑です。アプリケーションリポジトリと別のリポジトリからprotoファイルを参照したり、独自の体系で管理しているリポジトリがあります。Protoを利用するプロダクトが増えるとまた別の体系が生まれてしまい、メンテナンスや一貫性の担保が困難です。
これを防ぐため、プロダクト横断的にProtoを管理できる基盤に移行する議論を始めようとしています。
最後にまとめです。様々な工夫でリリースを乗り切り、後悔も踏まえて得た3つの教訓です。
1つ目、過渡期であっても理想とする姿を示して進む。一時的な役割分担の調整を行うにしても、DevOpsやセルフサービスなど、方向性定め、明示します。そうすると、心づもりもできて状況の変化にスムーズに対応できます。
2つ目、ハードパーツの設計は中長期を見据える。不確実性もあって難しいとは思うのですが、後から変更しづらい部分は短期スコープで意思決定しないことが重要です。一方で、移行する覚悟をするのも、ある意味プラットフォームエンジニアリングの醍醐味と言えるかもしれません。
3つ目、個別最適化にあらがう。デリバリーのスケジュールやチームの責務から、個別最適化の力学は働きやすいです。コンポーネントの特定のユースケースだけにとらわれず、全体を見据える必要があります。これらを意識できると、拡張性のあるプラットフォームがより提供しやすくなるのではないかと感じました。
ここからは宣伝です。2024年7月に開催されたGoogle Cloud Next Tokyo '24で弊社のメンバーが登壇しました。Google Cloudにフォーカスした話をしてくれているので、今日は深く触れなかったインフラ部分に興味がある方は見てみてください。
最後はGoogle Cloudさんに事例化していただいた記事です。複数プロダクトを統合してLegalOn Cloudを開発する際、なぜGoogle Cloudを選定したのかについてお話ししています。
ご清聴ありがとうございました。ご質問などあれば、@toshi0607までお願いします。
仲間募集
私たちのチームでは、一緒に働く仲間を募集しています。ご興味がある方は、以下のサイトからぜひご応募ください。皆様のご応募をお待ちしております。
