プラットフォームエンジニアリングの取組み
みなさんこんにちは!
SOMPOシステムズのアプリケーションエンジニアです!
「プラットフォームエンジニアリング」についてご存じでしょうか?2022年頃からこのキーワードが登場し、聞いたことがある方もいるかと思いますが、昨今さらに注目されており、今後多くの企業でこの分野に対する専門組織のチームが組成されると予測されています。
技術がより高度かつブラックボックスになっていく今の時代ですが、一方で以前と比べてアプリケーション開発者自身で考えなければならないことが増えてきています。
クラウドサービスの選定、SaaSの利用検討
開発環境/アプリケーション実行環境の準備
CICDパイプライン
システムにあわせた開発言語の選定
アプリケーションのコンテナ化・・・等々
アプリケーション開発の自由度が高くなった半面、開発者の認知負荷が高くなっている現状において認知負荷を下げるための施策やPlatform作りが必要とされています。また、企業内で用意されているFoundationを利用するにあたっても企業内のルール順守や関係者が増えて「すぐに使えるようにしたいが時間がかかる」という場面に遭遇されている方も少なくないかと思います。プラットフォームエンジニアリングでは「ゴールデンパス(開発者が迷わないためのスキーム作り)」を行い、そこに用意されるプロダクトをセルフサービスで利用することで開発者の認知負荷を下げ、開発者体験を向上することが目的となっています。
プラットフォームエンジニアリングを考えてみる
社内では今後さらなるクラウド利用を促進し、クラウド上のアプリケーション開発を行うために、現状の課題やApplication Platformを整えることを集中的に考える場が必要だと思いました。そこで、社内でGCPを使用したアプリケーション開発・運用を行っているメンバーを中心にGoogle Cloudが実施している”Platform Engineering Jumpstart " に参加しました。Foundationを提供する組織(サービス提供)、横串組織(グランドデザイン)、クラウドアプリ開発経験のある組織(アプリ開発者)、今後開発案件を持つ組織(次期システム検討)といった普段の役回りや置かれている立場が様々なメンバーを集めて実施し、互いの主張や日頃見せていない悩みなども含めた議論をしました。
Day1:座学(プラットフォームエンジニアリングとは、クラウドガバナンス)、現状の課題認識合わせ、目指すべきPlatformの姿
Day2:ゴールデンパスの検討
Day3:Day1~Day2で考えたPlatformのプロトタイピング
※Google Cloudを前提としたWorkshopとなります。
Day1
Day1のテーマとしては座学と現状課題の認識合わせです。座学については一般論になりますが、現状の課題意識は以下のようなものです。
案件毎に個別に環境準備を行い、環境作りに手間と時間がかかっている
何から手を付ければいいか、社内調査・調整に時間がかかる
アプリケーションのベースやリファレンスの整備がなく、スタートダッシュができない・・・等々
これらの洗い出しや日頃の悩みも含めて共有しました。
Day2
Day2にはゴールデンパスとして企業の中で何を改善/整備するとよいのかをディスカッションしました。具体例としては以下が挙げられています。
クラウド環境の払い出しスキームの改善点(期間圧縮の焦点)
リファレンス/テンプレート
オンボーディング
環境利用の申請~利用可能な状態になるまでの期間圧縮や、環境が作られてからアプリケーションをサンプルとして動かせる状態、開発する環境がすぐに提供されるスキームについて考えています。環境が利用可能になる状態になるまで、一次受けから関連者への作業依頼等より、現状はグループ作成・アカウント作成・プロジェクト作成にリードタイムがかかります。しかし、これをIaCによる自動化やフローとして自動化できそうな箇所を簡潔にすることでアプリ開発者へより早く提供できることを考えています。また、リファレンスやテンプレートはProductを用意しセルフサービス型で利用していくことを考え、オンボーディングについてはクラウド上で開発が可能となるクラウドIDEの利用を考えています。
Day3
Day3は実際にプロトタイピングとして、Google CloudのサービスにあるCloud Workstationsの利用とCloud Workstationsのコンテナイメージとしてアプリケーションの雛型が起動時に用意されている状態を試作しました。アプリケーションの雛型はDBアクセスを行うことができるものとして用意しています。
またCloud Codeを利用することで、CloudRunへのアプリケーションデプロイをCloud Workstations内で完結することができます。複数のツールを用いることなく一貫した開発⇔デプロイ⇒テストをすることができ、開発者の生産性と開発者体験を向上することができました。
今後の課題
このような取組みは、常日頃より定期的にディスカッションを社内で行い、改善を怠らないことや、一度Productとして作られたPlatformを維持するための保守活動がいかにビジネスに寄与するのか?を測り示すことが必要になると思っています。(これが中々難しいところではあったりします)
さいごに
いかがでしたでしょうか?
DevOps、Site Reliability Engineering(SRE)と似通った取組みにも思えます。ですが、DevOpsはソフトウェアをスムーズにデリバリーしてサービス提供していくために開発と運用の壁を取り除き、それには幅広い知見と高いスキルを必要としています。プラットフォームエンジニアリングは開発者の認知負荷を下げる、いわばエキスパートでないアプリ開発者でも迅速に開発を行えることを目指しているものかと思います。SREはサイトの信頼性に着目した取組みであり、これもプラットフォームエンジニアリングとは着眼点が異なります。
プラットフォームエンジニアリングはProductを開発者ポータル(IDP)で展開しアプリ開発を盛り上げていくことも1つの活動になります。従来よりシステム開発における「学習コスト」を下げるためのインフラ整備・ガイド整備等々、開発運用の負荷軽減を取り組まれてきた企業もあるかと思います。これがより一層、ソフトウェア開発が複雑化している世界において重要視されています。開発者の開発負担を軽減すること、開発者のエクスペリエンスの向上すること、環境提供の時間を短縮しすぐに開発者が取り掛かれること、これら再現性のあるプラットフォームを作りを検討し、その企業によって今のベストプラクティスは何なのか?を考えることが重要と思います。