いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！
今回は2025.04.07（月）に開催したPlatform Engineering Meetup #12へ参加しましたので、アウトプットとしてイベントレポートを執筆しました。
初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。
誤字脱字、わかりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しておりますので、誤字脱字があるかもしれません。
イベントページ
アーカイブ動画
目次
- イベント概要
- AmebaにおけるPlatform Engineeringの実践
- 複数プロダクトを支えるEKSクラスタのコスト按分
- ウォンテッドリーにおける Platform Engineering
- AWS Step Functionsで実現するジョブ基盤 〜プロダクトチームを支える基盤づくり〜
- AWSでPlatform Engineeringを実践するうえでの困りごと
- まとめ
イベント概要
このイベントは、現在急速に注目を浴びつつあるPlatform Engineeringについて、学んで、共有して、技術交流を行っていく ことを目的としています。
Platform Engineeringとは、クラウドネイティブ時代において、ソフトウェアエンジニアリング組織にセルフサービス機能を提供するためのツールチェーンやワークフローを設計・構築する技術分野です。
Gartnerが発表した2024年トップ10の戦略的テクノロジートレンドにも登場しており、5年以内にソフトウェアエンジニアリング組織の80%が採用するだろうとも予測されています。
とはいえ、こういった新しい技術分野あるあるですが、一体なにがどうなればPlatform Engineeringなのか、ぱっと分かりづらいですよね？ これまであったDevOpsなどとどう違うのか、どう関連しているのかも分かりづらいかもしれません。
そのために必要なのは、先人に学び、情報交換し、自らも発信していくという営みです。 Platform Engineering Meetupは、そんな場を作っていきたいと考えています。
交流したい人たちも、遠隔から気軽に参加したい人たちにも対応出来るよう、 ハイブリッド形式 でお届けします！ 是非ご参加ください
AmebaにおけるPlatform Engineeringの実践
登壇資料
参考サイト
- 自己紹介
- サイバーエージェント所属のエンジニアの方
- 現在SRGグループ（全社的なSRE導入サポート）に所属している
- お話しすること
- AmebaPlatform構築時の経緯・技術選定の背景・改善点など
- 技術実装の詳細についてはお話ししない予定
- Amebaプロダクトの課題
- 複雑なシステム構造のため、ドメイン知識のインプットコストが高い
- 担当者がアサインされないプロダクトがあったりした
- （個人的考察）確かに複雑化するとそうなりますよね
- Platformのコンセプト
- Kubernetes専門家でなくても環境構築可能
- KubeVelaを利用した構築
- （個人的考察）ナレッジが少ない方でも入っていける環境づくりは大切
- Kubernetes専門家でなくても環境構築可能
- 技術選定
- コンピューティング基盤
- EKS利用：Kubernetesのマネージドサービスを利用し運用工数削減
- コスト削減のためにスポットインスタンスを利用している
- Podに関してはHPAを利用してスケーリング板
- ネットワーキング
- lstioを導入している：メトリクスもいい感じに取得できる
- アプリケーション定義モデル
- Kubevela
- OAMモデルを使用して開発者のデプロイ簡素化＋拡張性を実現する
- ユーザの認知負荷を下げることができる
- （個人的考察）ラッパーツールのようなものなのかしら
- Kubevela
- テナント設計
- 環境ごとにEKSを使用している
- サービス分離を最小限にすることで担当者間での共有を容易にしている
- モニタリング
- Datadogを採用した
- メンバーの習熟度が高い
- 機能面が豊富・AWSとの連携が行いやすい
- Datadogを採用した
- コンピューティング基盤
- 自己紹介（石川さん）
- 2023年にサイバーエージェントに入社したSREの方
- Platformユーザ向けの対話体制
- 週ごとにオフィスアワーを行っている
- 半期ごとにPlatform討論会を行っている
- （個人的考察）ユーザからの声をプロダクトに反映しているのはいいですね
- ユーザからの声から見えた問題
- マニフェスト変更プロセスの利便性が低い
- ログ運用管理・ログ欠損などの課題
- 課題に対する対策
- マニフェスト変更プロセスの簡素化
- 人手による変更処理でなくGitHub Actionによる変更に修正
- 専用CLIコマンドによる変更を実装
- ログ管理の再設計
- ログ転送経路がLambdaとKDSに依存している
- Fluent Bitにより直接S3へ転送している
- S3⇒SQSを通じて非同期で処理ができる
- インシデント対応とモニタリング改善
- インシデント対応が属人化が発生している
- インシデントの優先度付けがうまく機能していない
- インシデント対応の標準化により対処した
- リリース以来の改善
- それ以外にもCI・CDに関する改善、Kubevela周りの改善も行っている
- マニフェスト変更プロセスの簡素化
- 完全なIDPへ
- 開発者が機能開発に集中できるように自動化された基盤・仕組みを実装する
- SLI/SLOを導入し継続的な改善サイクルを回していく
複数プロダクトを支えるEKSクラスタのコスト按分
参考サイト
- 自己紹介
- Sansan所属プラットフォームエンジニア
- 対応方法
- EKSでもコストタグを管理できるようにした
- Karpenterのリソース設定を行っている
- ログにもコストタグを付与して管理した
- ログのほうがコストがかかる場合もあるためつけておいた
- 財務観点でのコスト按分
- 財務のコスト管理方法に合わせることでコストタグの付与まで責務を持たせられる
- コスト管理の労力は削減できるが、最初の運用がめんどくさくなることも
- 開発者観点でのコスト按分
- 当初はKubecostを利用していたが無料版は15日間しかデータ保持ができない
- AWSからSCADが登場したため解決した
- サービスのメリット比較
- Kubecost：簡単に導入可能
- SCAD：無料で利用可能・データ保持が無制限
- サービスのデメリット比較
- Kubecost：15日間しか保持できない
- SCAD：ダッシュボードを自前で準備しないといけない
- （個人的考察）すごくわかりやすい内容ですね～
ウォンテッドリーにおける Platform Engineering
参考サイト
- 自己紹介
- ウォンテッドリー所属のエンジニア
- 今回話すことはウォンテッドリーで取り組んでいるプラットフォームエンジニアリングの話
- 開発状況
- プロダクト開発を担当しているエンジニアとして比較して少人数
- ウォンテッドリーではInfra SquadというチームでPlatform Engineeringを実践
- 目的として開発生産性と信頼の両立を目指している
- プラットフォームエンジニアリングあれこれ
- 2015年以前：インフラ作業がボトルネックになっていた
- エンジニア・サービスが増加しインフラ構築が多くなっていった
- 本来行う必要がある改善タスクがうまく行えない
- 現在：プラットフォームを通じてエンジニア自身でインフラ操作
- エンジニアにリソース管理を委譲している
- （個人的考察）役割境界があいまいになっているのね！！
- 2015年以前：インフラ作業がボトルネックになっていた
- インフラ構成の特徴
- AWSとGCのハイブリットクラウド
- EKSを中心としたマイクロサービス構成
- シンプルな構成セットを使いまわす
- （個人的考察）シンプルな構成テンプレートを作るのはわかるな
- 全マイクロサービスをK8S化させたのは2018年
- （個人的考察）2016年から実施していてもまだまたやることがあるんですね～
- 導入時
- 導入時はK8Sを利用している事例がなかった
- 新規サービスに導入して効果測定を行った
- 一番大きいマイクロサービスの移行完了は約4年かかった
- 移行後の運用を楽にするために社内の規約を作成した
- 導入時はK8Sを利用している事例がなかった
- 開発導入
- 一部のエンジニアから導入していった
- Kubeforkを使えば楽に開発できることを伝えていった
- 古い開発方法のスクリプト・ドキュメント削除対応も行っていった
- 検索・推薦についてはElasticsearchを活用した
- （個人的考察）RDSは確かに実装コスト・運用コストがかかるんですよね...
- RDB作成
- RDBをTerraformから作成する必要があった
- （個人的考察）開発ロールだとTerraformは触りづらいところはありますよね
- Terraform運用していないRDBの整理が行われておらず、データ移行問題などが発生した
- （個人的考察）分かりみが深い内容ですね...
- RDBをTerraformから作成する必要があった
- 得られた学び
- 小さく試せたものの方が最終的に利用されている確率が高い
- 移行をやりきらないことであとで困ることがある
- 導入と移行だけでなく利用させる仕組みも必要
- （個人的考察）このあたりの話は分かりみが深いですね
- 振り返ってみると改善時の効率をきっかけになった
AWS Step Functionsで実現するジョブ基盤 〜プロダクトチームを支える基盤づくり〜
- 自己紹介
- hacomono所属のエンジニアの方
- 前職では製造業を行っている
- hacomono社の状況
- 現在シリーズDの資金調達を行っている
- プラットフォーム部として各サービスやプロダクトで共通して使用される機能を提供する必要がある
- Job-managerを用いて管理している
- Job-managerとは
- ジョブ実行やSagaパターンを達成するためのジョブ管理基盤
- マイクロサービス・マルチプロダクト化していく必要がある
- 複数のAPIを決まった順序で実行する用途が増えていく
- 非同期実行・長期実行などの一貫性を保証する必要がある
- 既存ジョブ基盤の課題
- ECS Fargateで定期的に起動しRakeタスクを実行している
- シンプルな構成かつモノリスなロジックなので開発難易度は低い
- ただし、コンテナ起動時間が長くなってしまいコスト効率が悪い
- 並列実行も難しい
- Step Fuctionsを利用して並列実行できるようにした
- ECS Fargateで定期的に起動しRakeタスクを実行している
- プロダクトチームへの開発以上
- プラットフォーム運用を開発側へ委譲していった
- プロダクトチームにジョブの開発・運用を行うためのコード自動生成ツールを実装
- （個人的考察）自動生成ツールがあると引継ぎがうまい感じでできますよね
- E2Eテストについてもせいびした
- （個人的考察）E2Eテストがあると受け入れが行いやすいですよね
- 現状とこれから
- プロダクトチームへjob-managerへ普及させていっている
- そのうえで既存jobについても移行させていくことが対背うt
- リアーキテクチャ部と連携しながら普及活動を行っていく
AWSでPlatform Engineeringを実践するうえでの困りごと
登壇資料
- Platform運用上の問題に対する責務
- npmなどの管理パッケージでインストールしたアプリ：開発側
- プラットフォーム側でもログを見れるが実開発を行っているわけではないため、対処が厳しくなる
- プラットフォームの成熟度に応じてみていくことが必要
- npmなどの管理パッケージでインストールしたアプリ：開発側
- IaCのテンプレート化どこまで行っていくのか
- プラットフォーム側でどこまで抽象化させていくかがポイント
- プラットフォームの優先順位付け
- IssueとFeature Request
- レビットのドリル理論を考えると機能提供するだけで価値提供しているわけではない
- 機能追加のその先に本当のプラットフォーム提供がある
- （個人的考察）分かりみが深すぎる内容ですね！！
- プラットフォームもわかるプロダクトマネジャーがどのくらいいるのか考える日つよぐr
- IssueとFeature Request
- Platform Engineeringを自組織へインストールするのが難しい
- プロダクト開発なので最低でも専任の人員が必要となる
- トップダウン方式で進めていくことが大切
- Platform Engineeringの提供方法
- 開発者ニーズに合わせて提供方法を変えていくことが大切
- 熟練者であればテンプレートを渡す
- 任せたい人であれば必要最低限でも
- 開発者ニーズに合わせて提供方法を変えていくことが大切
- ビックバンリリース ダメ絶対
- 事前準備が大切
まとめ
プラットフォームエンジニアリングについてとっつきづらさを少し感じていましたので、本セッションを通じてどのようにプラットフォームエンジニアリングを行っていくのかをキャッチアップすることができました。
そのうえで、今回得た知見を踏まえ、自分なりのアウトプット活動を行っていきたいと思いました。
最後まで、記事をお読みいただきありがとうございました！！