持続可能なプラットフォーム運用： エコシステム導入の判断基準と運用戦略

2025/09/18日にPlatform Engineering Kaigi 2025 | PEK2025で発表した資料

Transcript

1. 持続可能なプラットフォーム運用： エコシステム導入の判断基準と運用戦略 谷成 雄 Yu Taninari
2. 谷成 雄 •2014年新卒入社 •現在: Service Reliability Group (SRG) → Ameba Platform → WinTicket •直近業務で触れていたエコシステムたち Istio KEDA ArgoWorkflow OpenCost SRG技術記事
3. 1.背景と目的 2.エコシステム導入の判断基準 3.導入したエコシステム例 4.実運用からの学び 5.まとめ
4. 最初に 本日お話すること • Kubernetesを利用した Platform上にエコシステムを導入する際に考えること • 実際に業務で検討・導入したエコシステムについて実例で紹介 • エコシステムの管理について 本日お話しないこと • 運用中のPlatformについての細かい設計や運用について Platform Engineering Meetup #12にて発表しました
5. 背景と目的
6. エコシステムとは 本発表ではエコシステムを「 Kubernetesを中心とした CNCFプロジェクト群」ということで定義 （CNCF Landscapeより）
7. 開発を加速させるために アプリケーション開発者の要望 • アプリケーションを柔軟にスケールさせたい • 依存関係のある Jobを実行したい • リリースを安心してできるようにカナリアリリースがしたい • CI/CDは自分の使い慣れたものを使用したい • モニタリングも使い慣れたものを使用したい • ログを独自の方式で収集したい
8. 開発を加速させるために 📅 Month 1: 「依存関係のある Jobを実行したい！」 󰞵 開発者: Argo Workflow導入お願いします ✅ 導入 → 😊「思い通りに Jobが実行できる」 📅 Month 3: 「GitOpsもやりたい！」 󰞵 開発者: ArgoCD導入お願いします ✅ 導入 → 😊「自動デプロイ最高！」 📅 Month 6: 「モニタリングを充実させたい！」 󰞵 開発者: Prometheus + Grafana導入お願いします ✅ 導入 → 😊「可視化バッチリ！」
9. 運用者の負荷が大きくなる 📅 アップグレード予定 : 1週間 📅 実際にかかった期間 : 2ヶ月 結果: 🔥🔥🔥 2ヶ月かかったり 🔥🔥🔥 Week 1 │ Kubernetes 1.28 → 1.29 開始 │ ↓ Week 2 │ 💥 ArgoCD動かない │ ↓ Week 3 │ 💥 Prometheus互換性問題 │ ↓ Week 5 │ 💥 External Secrets APIエラー │ ↓ Week ? │ 💥 その他のエコシステム │ ↓ Week 8 │ 😭 全エコシステム調査・修正完了
10. その他にも問題が ❖ エコシステム自体への理解が必要 ➢ 実際には自分が導入してないエコシステムだが、エラーになるとPlatform運用者が呼び出され対 応する ❖ エコシステムの設定不備 ➢ 設定不備によりノードの不調などによりサービス影響発生 ❖ 脆弱性対応が必要 ➢ エコシステムが増えるごとに対応の量も増えてしまう ❖ コストの増加 ➢ エコシステムを動かすにもリソースが必要になるので、手当り次第いれるとがコスト増加
11. エコシステムのメリット・デメリット メリット • 機能を実現するための豊富な選択肢 → 大抵のニーズに対応可能 • OSSなので自由度・拡張性が高い • コミュニティによる急速な進化 デメリット • 選択肢が多すぎて選定が難しい • ツールが増えるほど学習・運用コスト増大 • ライフサイクルが短いエコシステムも存在している
12. エコシステム導入の 判断基準
13. エコシステム導入の判断基準 まず最初に導入しないで解決できる道を探る ➔ 工夫することにより要件を満たすことができないか考える アプリの要望 実現できるエコシステム Job を細かく制御したい Argo Workflows, Tekton CI/CD経由でデプロイしたい ArgoCD, Flux リソース利用を可視化したい Prometheus, Grafana 簡単な Canary リリースしたい Argo Rollouts, Istio/Linkerd Secret を安全に管理したい Vault, External Secrets Operator
14. エコシステム導入の判断基準 要件を突き詰めていくと意外と基本機能で事足りることがあったりする アプリの要望 標準機能での工夫例 Job を細かく制御したい backoffLimit / startingDeadlineSeconds CI/CD経由でデプロイしたい kubectl / helm を既存CI/CDに組み込み リソース利用を可視化したい kubectl top, HPA 基本メトリクス 簡単な Canary リリースしたい Service weight / Replica 数で調整 Secret を安全に管理したい at-rest encryption
15. エコシステム導入の判断基準 やりたいことが エコシステムを利用しないと実現できない場合 に導入に踏み切る アプリの要望 エコシステム導入が必要となるケース Jobを細かく制御したい 複数ステップの依存関係がある複雑なワーク フロー等 CI/CD経由でデプロイしたい GitOpsによる宣言的管理や複数環境への自 動デプロイ等 リソース利用を可視化したい アラート設定とエスカレーションや長期間のメト リクス保存等 Canaryリリースしたい 自動メトリクス分析による判定や自動ロール バック機能等 Secretを安全に管理したい 外部Key Management Service連携等
16. エコシステムの選定 では実際導入する際はどのようなことを考えて選定するのか ❖ 導入しようとしているエコシステムの成熟度を確認 https://www.cncf.io/project-metrics/
17. エコシステムの選定 CNCF Landscapeのページで詳細を確認 https://landscape.cncf.io/
18. エコシステムの選定 GitHubで開発状況を確認 • Issueの対応状況 • PRの頻度や対応状況 • リリースの頻度 など開発のアクティブ度を確認
19. エコシステムの選定 先に導入している人に確認 • 社内で他に導入事例がないか確認してみる ➔ 導入経緯のすり合わせる ➔ 実際の運用感や使用感などを確認 • 今回のようなオフラインのカンファレンスなどは チャンス ➔ コミュニティ Slackなどもあるが、オンライン上だと色々確認するのは難しい
20. エコシステム選定の例 【必須条件】 🔴 すべて満たす必要あり ✓ 成熟度: CNCF Incubating以上 OR 同等 ✓ 活動性: 過去1年以内のFeatureリリース ✓ 実績: 日本国内での導入事例 1件以上 【評価項目】 🟡 ポイント制で判定 ⭐ コミュニティ : GitHub Stars 5K以上 (2pt) ⭐ 開発活動: 月間Contributors 10名以上 (2pt) ⭐ エコシステム : 商用サポート利用可能 (1pt) ⭐ 日本語対応: ドキュメント・コミュニティ (1pt) 📊 判定基準: 必須4項目 + 評価4pt以上で採用
21. 導入したエコシステム例
22. 活動組織について（Ameba） AmebaはAmebaブログをはじめ、最新の芸能人ニュースやマンガ・占いなど生きたコンテンツ が集結した国民的メディアサービスです
23. • 競輪などの公営競技のオンライン投票サービス • 可用性・スケーラビリティへの取り組み多数 活動組織について（WINTICKET) • 「GKE」 を用いた東京 /大阪のマルチリージョン・マルチ クラスタ構成 • 「Istio」を活用したカナリアリリース • 「KEDA」によるプロダクト特性に応じた柔軟な スケーリング戦略 https://developers.cyberagent.co.jp/blog/archives/54138/ https://developers.cyberagent.co.jp/blog/archives/58729/ ブログも公開中
24. KubeVela（Ameba）
25. KubeVela KubeVelaの機能 • OAMモデルを使用して開発者のデプロイを簡素 化し、拡張性を実現するツール 導入経緯 • アプリケーション開発者の Kubernetesに対する認 知負荷を減らす • Clusterを管理する上で必要な設定を管理者側で 強制する 導入が必要な理由 • 管理者が必要な設定を自身ですぐに反映できる ようにする必要があった
26. KubeVela 導入当時を思い出して • 5年程前に導入 • 導入当時に CNCFのSandbox Projectになって勢いがあるように感じた（その後 Incubating に昇格） 不安点 • メンテ体制が大きく変わって従来開発主力の Alibaba Cloudが撤退 ◦ 開発状況が怪しい感じになってきている • 定義自体は CUE Langで書くので、管理者側の学習コストが高い
27. External Secrets（Ameba）
28. External Secrets Operator External Secrets Operatorの機能 • AWS Secrets ManagerやHashiCorp Vaultなどの外部シークレット管理システムからシーク レットを自動取得し、 KubernetesのSecretリソースとして同期・管理するオペレーター 導入当時 • Kubernetes External Secretsを利用していたが、 EOLとなる 導入経緯 • Kubernetes External Secretsのマイグレーション先として導入 • EKSを使用しているので、 SecretsをAWS Secrets Managerで管理したい
29. External Secrets Operator 不安点 • 今年8月頃にメンテナンス停止の噂が流れてきた ◦ 暫定メンテナーを確保できたのでメンテナンスが継続されそう なぜAWS Secrets Manager CSI Driverを利用してないの？ ➔ Platform構築当時はまだ AWS Secrets Manager CSI Driverの機能は存在してなかった
30. KEDA（WINTICKET）
31. KEDA KEDAの機能 • イベント駆動型のオートスケーリングを Kubernetes上で実現するエコシステム • 外部システムやイベントソースを利用して Podをゼロから動的にスケールできる 実現したかったこと • 投票集計処理などで HPAのCPUスケールでは間に合わないような処理に対して、別の指標を利用し て事前にスケールをさせたい • スケールの指標に関してはアプリケーションに手をいれることなく、元からあるメトリクスなどを利用 できると良い
32. KEDA ❖ CNCFの成熟度 ➢ Graduated ❖ Stars ➢ 9k ❖ Contributer ➢ 406 ❖ GitHubのリリース頻度 ➢ 均すと月に一度くらいにリリース ❖ 周りの声 ➢ 他の部署や他の会社の人にヒヤリング 2025年4月時点
33. 実運用からの学び
34. Design Docsを残しておく • なぜこのエコシステムを選んだか、新しい運 用担当になった人も把握できる • なぜこのエコシステムを運用しているかの 納得感 • AIに聞いても当時の気持ちなどは教えてく れない
35. システム結合密度と障害影響範囲 サービス処理や通信に関わってくるエコシス テム選定は慎重に システム結合密度の高いものエコシステム の選定は慎重に システム結合密度と障害影響範囲が小さい ところでは実験的なエコシステムを導入する のも良いかも
36. エコシステムの開発が終了すると Kubernetes自体のバージョンは上がり続けるので、開発が終了すると Kubernetesバージョン アップの際に追従できないエコシステムが使用できなくなる可能性がある AmebaのPlatformでは、hierarchical-namespaces-controllerの開発が終了してイメージの読み 取りができなくなったケースが発生（下記リンクは弊社石川の執筆したブログ） https://ca-srg.dev/1d94358b43f78002917fc30c657b53bd • 一次対応として ECRにイメージをコピーしてそちらを利用することに
37. 選定してもバージョンアップは大変 選定してもバージョンアップ作業の負荷は気になるもの エコシステムの自動バージョンアップ機能を考案中
38. 選定してもバージョンアップは大変 • ユーザがGithub Actionsを実行する • アップデートエンジンを呼び出す • マニフェストを更新し Pull Requestを作成する • 変更を見て優先順位が高いものは、高優先度の PRを作成する • 破壊的変更を検出する • ローカルKubernetesで問題ないかを Dry-Runを実施する
39. 選定してもバージョンアップは大変 Upgrade Engineの内部 Userの設定によってアップ グレードの判断を行う 各リリースソースから更新 情報を取得してマニフェスト に反映させる 結果を表示する
40. まとめ
41. まとめ • エコシステムを導入するとより多くのことができるようになるが、何でもかんでも取り入 れてしまうと運用が大変になってしまう 本日の振り返り • エコシステムを導入する際に、運用フェーズを考えてどのように選択するのが良いのか の考え方について • 運用をしている上で見えてきた課題について • 運用の工夫ポイントについて
42. 採用情報 中途採用(Ameba Platform) 中途採用(SRG)
43. ありがとうございました