Belong のプラットフォームエンジニアリング
ttyfkyはじめに
本記事ではプラットフォームエンジニアリングの定義について触れ、Belong での取り組みを紹介します。
プラットフォームエンジニアリングの概要
プラットフォームエンジニアリングは、DevOps の機能横断的に協力を行う考え方に基づき、 安定したソフトウェア開発プロセスをサポートするためのプラクティスと技術を扱います。
概念的には以前からあったかもしれませんが、 2022 年終わり頃から言及されるようになり、 CNCF Platforms White Paper や、 Gartner のレポート(先日日本語版もでました) で触れられています。
プラットフォームエンジニアリングでは次のものを主に扱います。
- 開発インフラストラクチャの構築と管理: 開発、テスト、本番環境を含む統一されたプラットフォームの提供
- 自動化とツールの整備: CI/CD のプロセスを自動化し、品質保証を強化
- 開発者体験の向上: 開発者が効率的に作業できるように、必要なツールとリソースを提供
Google のブログ 道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワー では次のようにプラットフォームエンジニアリングが説明されており、特にゴールデンパスの構築について触れられています。
プラットフォーム エンジニアリングとは、組織において有用な抽象化を行い、セルフサービス インフラストラクチャを構築するアプローチです。散乱したツールをまとめ、デベロッパーの生産性を高める効果があります。プラットフォーム エンジニアリングの狙いは、デベロッパーが体験する日常的な困難を解消して、行きすぎた責任共有モデルが引き起こす学習の手間を抑制することです。
ゴールデンパス
ゴールデンパスは CNCF Platforms White Paper において言及されており、 迅速なプロジェクト開発に役立つ巧みに統合されたコードと機能のテンプレート構成のことを指します。
Google のブログの例を引用しつつ説明すると、次に挙げる例のように所属チームや開発するプロダクトに依存せず共通で使われやすいリソースのテンプレート作り、 開発者が簡単に利用できるようにすることがゴールデンパス構築の目的です。
- スタートガイド
- スケルトン ソースコード
- 依存関係の管理
- CI / CD パイプライン テンプレート
- クラウド Infrastructure as Code 用テンプレート
- Kubernetes YAML ファイル
- ポリシー ガードレール
- ロギングとモニタリング計測
- リファレンスドキュメント
現代の開発者は（複数の）クラウドサービスを用い、マイクロサービスにより複数の言語や異なるスタックを利用する機会が増え、以前は存在しなかったソフトウェア開発の複雑性の増加と向き合う必要性が高まっています1。 プラットフォームエンジニアリング、特にゴールデンパスの構築は、複雑化した開発環境において、 開発チームが各ツールのプラクティスや利用方法などをそれぞれで調査・開発し何度も作り直すことを防いで認知的負荷を軽減し、開発効率を向上させることを目的としています。
Belong におけるプラットフォームエンジニアリング
Belong では、結果的にですが、プラットフォームエンジニアリングの考え方はエンジニアリングチームが立ち上がった当時から行っていました。 特に、 SRE として shigwata@ が入社した後はプラットフォームエンジニアリングの取り組みは加速的に進みました。
Belong の SRE は現在次の領域を担当しています。
- クラウド環境の管理
- Google Cloud のプラクティスの策定と運用
- アーキテクチャレビュー
- リソースの管理
- IaC の整備
- Terraform によるインフラストラクチャの管理
- Terraform のモジュールの整備
- CI/CD 環境の整備
- GitHub Actions や CircleCI を用いたビルドやデプロイのプラクティスの策定と運用
- 共通利用される Action や Orbs の構築
- 開発環境の整備
- GitHub 利用のプラクティスの策定と運用
- リポジトリの管理
- プロダクションサポートプラクティスの策定と運用
- Production Readiness Check
- SLA/SLO の策定とモニタリング・アラートの設計
- インシデント管理
- エンジニアリング生産性の取り組み
- Four Keys Metrics の計測と改善
- 開発に関わるセキュリティ・ガバナンスに関わる取り組み
- Design Docs の管理
- Secret の運用
Belong の SRE は開発に関わる様々な Toil の削減に取り組んでおり、SRE Book にでてくるような領域のみでなく、
エンジニアリング組織全体に渡って生産性を高めるような取り組みをしています。
例えば 2023 年の SRE の主要な取り組みは Service Account Key のダンロードの必要性を無くし OIDC を用いて Google Cloud のリソースにアクセスする Workload Identity Federation を全社的に導入するために
GitHub Actions の Private Action や CircleCI の Orbs を作成し各チームが簡単に利用できるようにしたことや、
Zero Touch Production 実現のための承認フローと Google Cloud に対する権限付与実行の仕組みを構築し、全社的に利用可能にしたことなどでした。
SRE はこういったプロダクトやチームを横断して共通の課題を見つけ、ゴールデンパスの構築に取り組んでいます2。
SRE と言いつつ実態は Platform Engineer じゃないかと思われるかもしれませんが、Google が class SRE implements DevOps と言うように、
SRE と DevOps は密接な関わりがあり、Platform Engineering も DevOps の考え方に基づいているため、SRE が Platform Engineering に関わるのは自然なことです。
また、Belong の SRE がこのような動きを期待される理由としては、 以前の記事 でも触れたように Belong では運用負荷を下げるためにサーバーレスプロダクトを積極的に利用しているため、
SRE としてサイト信頼性を任される役割でも、Kubernetes を運用していたりオンプレ環境でネットワークやバーチャルマシンの設定まで含めたインフラの運用をするような役回りとはタスクの負荷やフォーカスするべき部分が異なることも関係していると思います。
何れにせよ、SRE はプラットフォームエンジニアリングの取り組みをリードしており、エンジニアの生産性を向上しより良いサービスを構築するためにはなくてはならない存在です。
おわりに
本記事ではプラットフォームエンジニアリングについて説明し、Belong の SRE はプラットフォームエンジニアリングの取り組みをリードしていることを紹介しました。
プラットフォームエンジニアリングの要素はここで挙げたようなものだけでなく、フレームワークやライブラリの整備、認証基盤、ドキュメントテンプレートの提供なども含めた、開発者がセルフサービスで利用したくなるようなものを提供することだと思います。
私がある意味プロダクトマネージャーのような役割をしており専属の者はいませんが、開発者目線に立って必要なものを提供できる環境です。
このプラットフォームエンジニアリングも行う SRE は現在メンバーを募集しています。本記事で Belong に興味を持っていただけたらぜひエンジニアリングチーム紹介ページを確認していただき、カジュアル面談等お声がけいただけたら嬉しく思います。