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

by yu-tani

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

谷成雄 •2014年新卒入社 •現在: Service Reliability Group (SRG) → Ameba Platform → WinTicket •直近業務で触れていたエコシステムたち Istio KEDA ArgoWorkﬂow OpenCost SRG技術記事

Slide 3

Slide 3 text

1.背景と目的 2.エコシステム導入の判断基準 3.導入したエコシステム例 4.実運用からの学び 5.まとめ

Slide 4

Slide 4 text

最初に本日お話すること • Kubernetesを利用した Platform上にエコシステムを導入する際に考えること • 実際に業務で検討・導入したエコシステムについて実例で紹介 • エコシステムの管理について本日お話しないこと • 運用中のPlatformについての細かい設計や運用について Platform Engineering Meetup #12にて発表しました

Slide 5

Slide 5 text

背景と目的

Slide 6

Slide 6 text

エコシステムとは本発表ではエコシステムを「 Kubernetesを中心とした CNCFプロジェクト群」ということで定義（CNCF Landscapeより）

Slide 7

Slide 7 text

開発を加速させるためにアプリケーション開発者の要望 • アプリケーションを柔軟にスケールさせたい • 依存関係のある Jobを実行したい • リリースを安心してできるようにカナリアリリースがしたい • CI/CDは自分の使い慣れたものを使用したい • モニタリングも使い慣れたものを使用したい • ログを独自の方式で収集したい

Slide 8

Slide 8 text

開発を加速させるために 📅 Month 1: 「依存関係のある Jobを実行したい！」 󰞵 開発者: Argo Workflow導入お願いします ✅ 導入 → 😊「思い通りに Jobが実行できる」 📅 Month 3: 「GitOpsもやりたい！」 󰞵 開発者: ArgoCD導入お願いします ✅ 導入 → 😊「自動デプロイ最高！」 📅 Month 6: 「モニタリングを充実させたい！」 󰞵 開発者: Prometheus + Grafana導入お願いします ✅ 導入 → 😊「可視化バッチリ！」

Slide 9

Slide 9 text

運用者の負荷が大きくなる 📅 アップグレード予定 : 1週間 📅 実際にかかった期間 : 2ヶ月結果: 🔥🔥🔥 2ヶ月かかったり 🔥🔥🔥 Week 1 │ Kubernetes 1.28 → 1.29 開始 │ ↓ Week 2 │ 💥 ArgoCD動かない │ ↓ Week 3 │ 💥 Prometheus互換性問題 │ ↓ Week 5 │ 💥 External Secrets APIエラー │ ↓ Week ? │ 💥 その他のエコシステム │ ↓ Week 8 │ 😭 全エコシステム調査・修正完了

Slide 10

Slide 10 text

その他にも問題が ❖ エコシステム自体への理解が必要 ➢ 実際には自分が導入してないエコシステムだが、エラーになるとPlatform運用者が呼び出され対応する ❖ エコシステムの設定不備 ➢ 設定不備によりノードの不調などによりサービス影響発生 ❖ 脆弱性対応が必要 ➢ エコシステムが増えるごとに対応の量も増えてしまう ❖ コストの増加 ➢ エコシステムを動かすにもリソースが必要になるので、手当り次第いれるとがコスト増加

Slide 11

Slide 11 text

エコシステムのメリット・デメリットメリット • 機能を実現するための豊富な選択肢 → 大抵のニーズに対応可能 • OSSなので自由度・拡張性が高い • コミュニティによる急速な進化デメリット • 選択肢が多すぎて選定が難しい • ツールが増えるほど学習・運用コスト増大 • ライフサイクルが短いエコシステムも存在している

Slide 12

Slide 12 text

エコシステム導入の判断基準

Slide 13

Slide 13 text

エコシステム導入の判断基準まず最初に導入しないで解決できる道を探る ➔ 工夫することにより要件を満たすことができないか考えるアプリの要望実現できるエコシステム Job を細かく制御したい Argo Workflows, Tekton CI/CD経由でデプロイしたい ArgoCD, Flux リソース利用を可視化したい Prometheus, Grafana 簡単な Canary リリースしたい Argo Rollouts, Istio/Linkerd Secret を安全に管理したい Vault, External Secrets Operator

Slide 14

Slide 14 text

エコシステム導入の判断基準要件を突き詰めていくと意外と基本機能で事足りることがあったりするアプリの要望標準機能での工夫例 Job を細かく制御したい backoffLimit / startingDeadlineSeconds CI/CD経由でデプロイしたい kubectl / helm を既存CI/CDに組み込みリソース利用を可視化したい kubectl top, HPA 基本メトリクス簡単な Canary リリースしたい Service weight / Replica 数で調整 Secret を安全に管理したい at-rest encryption

Slide 15

Slide 15 text

エコシステム導入の判断基準やりたいことがエコシステムを利用しないと実現できない場合に導入に踏み切るアプリの要望エコシステム導入が必要となるケース Jobを細かく制御したい複数ステップの依存関係がある複雑なワークフロー等 CI/CD経由でデプロイしたい GitOpsによる宣言的管理や複数環境への自動デプロイ等リソース利用を可視化したいアラート設定とエスカレーションや長期間のメトリクス保存等 Canaryリリースしたい自動メトリクス分析による判定や自動ロールバック機能等 Secretを安全に管理したい外部Key Management Service連携等

Slide 16

Slide 16 text

エコシステムの選定では実際導入する際はどのようなことを考えて選定するのか ❖ 導入しようとしているエコシステムの成熟度を確認 https://www.cncf.io/project-metrics/

Slide 17

Slide 17 text

エコシステムの選定 CNCF Landscapeのページで詳細を確認 https://landscape.cncf.io/

Slide 18

Slide 18 text

エコシステムの選定 GitHubで開発状況を確認 • Issueの対応状況 • PRの頻度や対応状況 • リリースの頻度など開発のアクティブ度を確認

Slide 19

Slide 19 text

エコシステムの選定先に導入している人に確認 • 社内で他に導入事例がないか確認してみる ➔ 導入経緯のすり合わせる ➔ 実際の運用感や使用感などを確認 • 今回のようなオフラインのカンファレンスなどはチャンス ➔ コミュニティ Slackなどもあるが、オンライン上だと色々確認するのは難しい

Slide 20

Slide 20 text

エコシステム選定の例【必須条件】 🔴 すべて満たす必要あり ✓ 成熟度: CNCF Incubating以上 OR 同等 ✓ 活動性: 過去1年以内のFeatureリリース ✓ 実績: 日本国内での導入事例 1件以上【評価項目】 🟡 ポイント制で判定 ⭐ コミュニティ : GitHub Stars 5K以上 (2pt) ⭐ 開発活動: 月間Contributors 10名以上 (2pt) ⭐ エコシステム : 商用サポート利用可能 (1pt) ⭐ 日本語対応: ドキュメント・コミュニティ (1pt) 📊 判定基準: 必須4項目 + 評価4pt以上で採用

Slide 21

Slide 21 text

導入したエコシステム例

Slide 22

Slide 22 text

活動組織について（Ameba） AmebaはAmebaブログをはじめ、最新の芸能人ニュースやマンガ・占いなど生きたコンテンツが集結した国民的メディアサービスです

Slide 23

Slide 23 text

• 競輪などの公営競技のオンライン投票サービス • 可用性・スケーラビリティへの取り組み多数活動組織について（WINTICKET) • 「GKE」を用いた東京 /大阪のマルチリージョン・マルチクラスタ構成 • 「Istio」を活用したカナリアリリース • 「KEDA」によるプロダクト特性に応じた柔軟なスケーリング戦略 https://developers.cyberagent.co.jp/blog/archives/54138/ https://developers.cyberagent.co.jp/blog/archives/58729/ ブログも公開中

Slide 24

Slide 24 text

KubeVela（Ameba）

Slide 25

Slide 25 text

KubeVela KubeVelaの機能 • OAMモデルを使用して開発者のデプロイを簡素化し、拡張性を実現するツール導入経緯 • アプリケーション開発者の Kubernetesに対する認知負荷を減らす • Clusterを管理する上で必要な設定を管理者側で強制する導入が必要な理由 • 管理者が必要な設定を自身ですぐに反映できるようにする必要があった

Slide 26

Slide 26 text

KubeVela 導入当時を思い出して • 5年程前に導入 • 導入当時に CNCFのSandbox Projectになって勢いがあるように感じた（その後 Incubating に昇格）不安点 ● メンテ体制が大きく変わって従来開発主力の Alibaba Cloudが撤退 ○ 開発状況が怪しい感じになってきている ● 定義自体は CUE Langで書くので、管理者側の学習コストが高い

Slide 27

Slide 27 text

External Secrets（Ameba）

Slide 28

Slide 28 text

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で管理したい

Slide 29

Slide 29 text

External Secrets Operator 不安点 ● 今年8月頃にメンテナンス停止の噂が流れてきた ○ 暫定メンテナーを確保できたのでメンテナンスが継続されそうなぜAWS Secrets Manager CSI Driverを利用してないの？ ➔ Platform構築当時はまだ AWS Secrets Manager CSI Driverの機能は存在してなかった

Slide 30

Slide 30 text

KEDA（WINTICKET）

Slide 31

Slide 31 text

KEDA KEDAの機能 • イベント駆動型のオートスケーリングを Kubernetes上で実現するエコシステム • 外部システムやイベントソースを利用して Podをゼロから動的にスケールできる実現したかったこと • 投票集計処理などで HPAのCPUスケールでは間に合わないような処理に対して、別の指標を利用して事前にスケールをさせたい • スケールの指標に関してはアプリケーションに手をいれることなく、元からあるメトリクスなどを利用できると良い

Slide 32

Slide 32 text

KEDA ❖ CNCFの成熟度 ➢ Graduated ❖ Stars ➢ 9k ❖ Contributer ➢ 406 ❖ GitHubのリリース頻度 ➢ 均すと月に一度くらいにリリース ❖ 周りの声 ➢ 他の部署や他の会社の人にヒヤリング 2025年4月時点

Slide 33

Slide 33 text

実運用からの学び

Slide 34

Slide 34 text

Design Docsを残しておく • なぜこのエコシステムを選んだか、新しい運用担当になった人も把握できる • なぜこのエコシステムを運用しているかの納得感 • AIに聞いても当時の気持ちなどは教えてくれない

Slide 35

Slide 35 text

システム結合密度と障害影響範囲サービス処理や通信に関わってくるエコシステム選定は慎重にシステム結合密度の高いものエコシステムの選定は慎重にシステム結合密度と障害影響範囲が小さいところでは実験的なエコシステムを導入するのも良いかも

Slide 36

Slide 36 text

エコシステムの開発が終了すると Kubernetes自体のバージョンは上がり続けるので、開発が終了すると Kubernetesバージョンアップの際に追従できないエコシステムが使用できなくなる可能性がある AmebaのPlatformでは、hierarchical-namespaces-controllerの開発が終了してイメージの読み取りができなくなったケースが発生（下記リンクは弊社石川の執筆したブログ） https://ca-srg.dev/1d94358b43f78002917fc30c657b53bd • 一次対応として ECRにイメージをコピーしてそちらを利用することに

Slide 37

Slide 37 text

選定してもバージョンアップは大変選定してもバージョンアップ作業の負荷は気になるものエコシステムの自動バージョンアップ機能を考案中

Slide 38

Slide 38 text

選定してもバージョンアップは大変 • ユーザがGithub Actionsを実行する • アップデートエンジンを呼び出す • マニフェストを更新し Pull Requestを作成する • 変更を見て優先順位が高いものは、高優先度の PRを作成する • 破壊的変更を検出する • ローカルKubernetesで問題ないかを Dry-Runを実施する

Slide 39

Slide 39 text

選定してもバージョンアップは大変 Upgrade Engineの内部 Userの設定によってアップグレードの判断を行う各リリースソースから更新情報を取得してマニフェストに反映させる結果を表示する

Slide 40

Slide 40 text

まとめ

Slide 41

Slide 41 text

まとめ • エコシステムを導入するとより多くのことができるようになるが、何でもかんでも取り入れてしまうと運用が大変になってしまう本日の振り返り • エコシステムを導入する際に、運用フェーズを考えてどのように選択するのが良いのかの考え方について • 運用をしている上で見えてきた課題について • 運用の工夫ポイントについて