Amebaにおける Platform Engineeringの実践

by Kumo Ishikawa

Slide 1

Slide 1 text

Amebaにおける Platform Engineeringの実践谷成雄 Yu Taninari 石川雲 Kumo Ishikawa

Slide 2

Slide 2 text

谷成雄 •2014年新卒入社 •現在: Service Reliability Group (SRG) •Ameba Platform チーム •最近開発などで利用した技術: EKS GKE kubernetes on-premise Amazon Aurora Github Actions SRG技術記事

Slide 3

Slide 3 text

1.背景と課題 2.初期の構成と技術選定 3.リリース以来の改善 4.これから目指すこと

Slide 4

Slide 4 text

最初に本日お話すること AmebaPlatformを構築するに至った経緯構築する際に利用した技術の選定や背景について運用する上で出てきた改善点をいくつか紹介これから考えている施策・方向性について本日お話しできないこと技術選定や改善ステップなどの技術詳細ついての深堀り（DeepDive）どこか登壇できる場所を探しつつ発表の機会を伺う時間の都合上スキップしたスライドは後ほどSpeakerDeckで公開

Slide 5

Slide 5 text

1.背景と課題 2.初期の構成と技術選定 3.リリース以来の改善 4.これから目指すこと

Slide 6

Slide 6 text

Amebaとは？ Amebaはブログを中心としたメディアプラットフォーム

Slide 7

Slide 7 text

Ameba Platformとは？ Amebaとして統合されたアーキテクチャを軸にシステムを再構築するために作成されたPlatform

Slide 8

Slide 8 text

Amebaの課題(2019年当時) 複雑なシステム構造のため、ドメイン知識のインプットのコストが大きい組織の変化に伴いチーム構成が変化することが多く、新しく担当したサービスの開発を開始するのに多くのリードタイムが発生するチームごとに選定された様々な技術各チームごとに様々な技術が使用されており、サービス開発者や運用者に大きい負担がかかっている状況が発生している運用における責任範囲が不明瞭運用担当者が異動や退職になると、新しい担当者がアサインされず放置されてるようなサービスも発生

Slide 9

Slide 9 text

Platformのコンセプト • 利用ユーザがKubernetesに熟知する必要がない環境を提供 KubeVela(OAMの提供) • 管理された統合CI/CDの提供 GithubActionsとArgoCDを用いたマネージドの環境を提供 • 統一されたログフローの提供標準出力に出力されたログを必要なところに届けるシステムを提供 • 監視サービスの一元化 Datadogを使用したモニタリングやダッシュボードを提供 • 基本的なセキュリティの担保 KubeVelaを使用したSecurityContextやSecretsManagerの提供など

Slide 10

Slide 10 text

1.背景と課題 2.初期の構成と技術選定 3.リリース以来の改善 4.これから目指すこと

Slide 11

Slide 11 text

構成

Slide 12

Slide 12 text

技術選定: コンピューティング基盤 Kubernetes on AWS（EKS） • KubrenetesのManagedサービスを利用することにより管理者の運用負荷削減 Self-Managed-NodeGroup（当時の状況） • user_dataが流せる(社内認証によるログイン設定) • 追加のSecurity Groupが指定できる Spot Instanceの活用 • コストを抑えるためにSpot Instanceも併用 Cluster-AutoscalerとHPA • 当時のWorkerNodeのスケールサービスだとほぼ一択 • Podに関しては特殊なスケール要件がなかったのでHPAを採用

Slide 13

Slide 13 text

技術選定: ネットワーキング ● セキュリティポリシー等を簡単に適用できる ● 可観測性の確保 ○ 問題発生時にログやメトリクス、トレース情報などをもとに調査が可能出典:(アクセス日: 2025/04/03) https://istio.io/latest/docs/ops/deployment/architectu Istioの導入 ● 基本的にマイクロサービスアーキテクチャを採用しており、分散トレーシングやメトリクス収集などが容易に行える

Slide 14

Slide 14 text

技術選定: ログ管理の初期構成ログデータの流れ EKS-> ﬂuentbit-> Kinesis Data Streams →Lambda→etc… シンプルなログ体験を提供ユーザは標準出力にログを出力するだけで、必要なところに必要なログが送られる

Slide 15

Slide 15 text

技術選定: CI/CD GitHub Actions（CI） • 開発にGitHubを使用しており、社内にSelfHostRunnerも存在していたため採用 ArgoCD（CD） • ArgoCDは導入と管理が容易 Bootstrapのプロセスが不要で、HA構成でも単一のYAMLファイルでデプロイ可能 • ArgoCDの優れたユーザー体験 ArgoCDのUIは速度とわかりやすさが高評価 • ArgoCDの活発なコミュニティとPlatformチームとの親和性 2020年時点で既にIncubating Projectに昇格しており、最も期待されているCDプロジェクトの一つであった社内Platformチームの技術スタック(Go言語が多い)と親和性が高く、Issueを提起しやすい環境

Slide 16

Slide 16 text

技術選定: アプリケーション定義モデル KubeVelaとは • OAMモデルを使用して開発者のデプロイを簡素化し、拡張性を実現するツール KubeVelaの選択理由 • ユーザのk8sに対する認知負荷を減らす • clusterを管理するうえで必須となる設定を管理者側として強制できる KubeVelaとCUE langについて CUE langを用いて条件文やデータ変換等を行い、必要なyaml を生成する

Slide 17

Slide 17 text

OAMとArgoCD Appの構成

Slide 18

Slide 18 text

技術選定: テナント設計サービスの分離について環境ごとにEKSを使用し、EKS内の各サービス間の接続やNamespace間のやり取りなどは特に制限しない構成（開発体験のシンプルさやメンテナンス性の向上が目的）サービスの共有オーナーシップの確保サービスの分離を最小限にすることで、担当範囲を超えて互いのサービスのサポートをしたり、障害対応などが共同でできるような環境を用意 HNC（Hierarchical Namespace Controller）とRBAC HNCはNamespaceを階層構造で管理することができ、リソースの継承と伝搬が可能RBACと組み合わせることにより、Platformチームとアプリケーション開発者が管理するリソースの分離をすることが可能

Slide 19

Slide 19 text

技術選定: モニタリング Datadogの採用 • メンバーの習熟度が高い • いろいろな機能が充実 • AWSとの連携も容易アプリケーション側のDatadogの活用 • Prometheus Endpoint (Annotation)を付与することでメトリクスを収集 • GoアプリケーションにDatadogのGo SDKを組み込むことで、アプリケーションのパフォーマンスデータ（APMデータ）をDatadogへ送信し、可視化・監視

Slide 20

Slide 20 text

初期の構成と技術選定まとめ Platform構築初期に使用した以下の技術の選定の理由について説明 • コンピューティング • ネットワーク • ログの構成 • アプリケーション定義モデル • テナント設計 • モニタリング

Slide 21

Slide 21 text

1.背景と課題 2.初期の構成と技術選定 3.リリース以来の改善 4.これから目指すこと

Slide 22

Slide 22 text

石川雲 •2023年11月中途入社 •Service Reliability Group (SRG) •Ameba Platform チーム(2023/11~現在) •担当領域: EKS Node運用(Karpenter) Security(テナント設計・ネットワーキング・Audit監視) CI/CD(ArgoCD・FluxCD・Terraform) SRG技術記事

Slide 23

Slide 23 text

Platformユーザ向けの対話体制改善活動を支える基盤週毎のオフィスアワー(Huddle): 15min ~ 30min 半期毎のPlatform討論会: 1h ~ 2h

Slide 24

Slide 24 text

ユーザの声・判明した問題 • マニフェスト変更プロセスにはさらなる利便性が求められる • ログの運用管理が大変、ログ欠損発生、ログ検索性が悪い • インシデント管理体制の欠如、属人化発生 • サービス数の増加によりCI/CDのパフォーマンスが劣化 • より厳格的なセキュリティ要件を満たすテナント設計が必要 • などなど...

Slide 25

Slide 25 text

本日はこれらの中から特に注力したいくつかの改善取り組みにフォーカスしてご紹介します

Slide 26

Slide 26 text

マニフェスト変更プロセスの簡素化課題 •Applicationの追加・変更時に、複数のリポジトリ/マニフェストを横断的に修正する必要があり、利用者にとって認知負荷が高い例: 新規App追加時に9種類のマニフェストを書かないといけない •記述ミスや変更漏れが発生しやすく、デプロイ失敗や環境不整合のリスクがあった解決 •専用CLIを開発し、必要なマニフェストを自動生成・一括更新できる仕組みに統一 •一部の人手によるマニフェスト変更処理は Github Actionsに自動化

Slide 27

Slide 27 text

マニフェスト変更プロセスの簡素化利用例 cliの利用 GHAの利用

Slide 28

Slide 28 text

ログ管理の再設計課題 • ログ転送経路がLambdaとKDSに依存し、ログの可用性と耐障害性に課題 • OpenSearchに全ログを格納できず、ログ検索性が低下解決 • Fluent Bit によりログを直接 S3 へ転送 • 必要な転送処理のみ S3 -> SQS -> Lambda で非同期実行する構成へ移行 • Athena を導入し、S3 上のログに対するクエリベースの検索を実現

Slide 29

Slide 29 text

旧・ログ構成図ログ管理の再設計

Slide 30

Slide 30 text

ログ管理の再設計新・ログ構成図

Slide 31

Slide 31 text

インシデント対応とモニタリングの改善背景 • アラート対応が属人化し、再発・対応の遅延・ナレッジが継承されないなどが発生 • アラートとインシデント設定がGUI操作中心、設定の属人化 • インシデントの緊急度や影響と最終的解決を定量的に判断・評価しづらい状況、たまに放置主な取り組み 1. インシデント対応の標準化: インシデントコマンダー制度の導入トリアージ基準の策定 2. ツールによるプロセスの一元化、宣言的管理の実現 Datadog Incident+Slackによるインシデント管理の統一 Datadog Operator によるモニタリング設定の宣言的管理 3. インシデント対応などモニタリングの改善 Incident Metricsダッシュボードによる分析と継続的改善

Slide 32

Slide 32 text

リリース以来の改善まとめ • Platform改善のための対話体制 • 以下の改善にフォーカスして紹介マニフェスト変更プロセスの簡素化: より利便性の高いセルフサービス環境の提供ログ管理の再設計: より安価で管理しやすい設計への移行インシデント対応とモニタリングの改善: より効率的なインシデント対応体制などの整備その他の改善: PDF版/SpeakerDeck版でご参照ください CI/CDの高速化・パフォーマンス最適化 Post Release Workﬂowの開発 AWS/EKSにおけるマルチテナント対応 Nodeスケジューリング最適化 Podリソース使用最適化

Slide 33

Slide 33 text

インシデントマネジメント課題 • アラート対応が放置・属人化し、同様のインシデントが再発 • 対応フローが明確でなく、解決までに時間を要する • 過去のインシデント履歴や対処内容が整理されておらず、ナレッジが継承されにくい解決 • Datadog Incident を中核に据え、発生〜対応〜振り返りまでのプロセスを一元管理 • 統一されたインシデント対応フローを整備し、全チームでの共通運用を徹底 • トリアージ基準とインシデントコマンダーの役割を明確化し、対応の迅速化と属人化の防止を実現

Slide 34

Slide 34 text

モニタリングの改善課題 • アラート条件や通知設定がGUI操作中心、設定の属人化 • チーム構成が変わるたびに過去の運用知見が失われる • インシデントに対し、定量的評価ができず、緊急性の高い恒久対策が後回しにされる傾向解決 • Datadog Operator導入、モニタリング設定の宣言的管理を実現 • Embedded SREを各チームに配置し、プラクティス支援 • Incident Metrics ダッシュボードの整備、改善活動を追える状態に

Slide 35

Slide 35 text

CI/CDの進化イメージタグ更新自動化 FluxCD Image Automation (FluxCD+ArgoCD併用) Terraform CI高速化 Git差分のみTerraform Apply 実行時間平均70%削減 CDパフォーマンス最適化 ArgoCD/FluxCD シャーディング同期間隔やキャッシュ設定など、各種パラメータ調整 Post Release Workﬂow KubeVela Application Workﬂow導入 ArgoCD同期後、任意のリソースに任意のオペレーションが実行可能に

Slide 36

Slide 36 text

CI/CDの進化: イメージタグ更新課題 • イメージのタグ更新は手動で行っており、更新漏れや人為的ミスのリスクが高い • 既存の ArgoCD Image Updaterでは一部要件を満たせず、利用できない解決 • FluxCD の ImageUpdateAutomation機能を活用し、イメージのタグ更新を完全自動化 (FluxCDとArgoCD併用)

Slide 37

Slide 37 text

CI/CDの進化: イメージタグ更新

Slide 38

Slide 38 text

CI/CDの進化: Terraform高速化課題 • リソース数の増加により、Terraform 実行時間が 15〜30 分以上に肥大化 • 全体Apply運用のため、変更差分が見えづらく、意図しない影響のリスクがあった解決 • Git差分があったModuleのみを対象にApplyを実行する方式に切り替え • 全体Applyは定期実行＋確認フェーズを設けて、安全性と効率性を両立 • 実行時間を平均70%削減した

Slide 39

Slide 39 text

CI/CDの進化: CD最適化課題 • 監視対象リソースの増加により、ArgoCD の同期処理が遅延 • FluxCD の安定性が低下し、イメージ自動更新が断続的に停止解決 • ArgoCD・FluxCD をシャーディング構成に分割し、処理の並列化と負荷分散を実現 • 同期間隔やキャッシュ設定など、各種パラメータを最適化し、リソース消費を削減 • 結果として、同期・更新の安定性が向上し、安定した運用が可能に

Slide 40

Slide 40 text

CI/CDの進化: Post Release 課題 • Jenkins では対応できていたが、EKS + ArgoCD 移行後に制約が増加 • ArgoCDの同期後に何かを実行したい処理が実現しづらい • ArgoCD の Resource Hook はリソース単位での制御ができず、細かいタイミング制御が不可能解決 • KubeVela Application Workﬂowの導入により、Application単位でPost Release処理を定義可能に • GitHub Actions 実行・外部リソース確認なども可能 • PostReleaseの処理も同一Manifestで管理可能、運用の一貫性がある

Slide 41

Slide 41 text

CI/CDの進化: Post Release

Slide 42

Slide 42 text

KubeVela 継続利用と今後の方針課題 • 主要開発元(Alibaba Cloud)が2023年から開発中止、継続性に不安 • 複数環境に対応する Cuelang テンプレートが難読化し、保守負担増加 • 社内で十分にメンテナンスできる体制がない検討 •KubeVelaを代替可能なプロダクトは存在せず、引き続き利用を継続(2025/4時点) •将来的な選択肢として、KubeVela 本体へのコントリビュートを検討中

Slide 43

Slide 43 text

その他の改善マルチテナント対応: 通信制御・権限分離を実現 • 通信制御：Security Groups for Pod、NetworkPolicy導入 • 権限分離：ResourceTagベースのIAM ABAC、Kubernetes RBACの見直し Node最適化: Karpenter導入 • Podの要求に応じて、適切なインスタンスタイプを動的に割り当て • 使用率の低いNodeを自動削除し、コストを大幅削減 Pod 最適化: Cloudnatix導入 • Prod以外へVPA AutoPilot機能導入

Slide 44

Slide 44 text

マルチテナント化への移行課題 • EKS Pod間、PodとAWSリソース間の通信制御と権限分離がない • セキュリティ要件が高い認証・決済系サービスが移設できない解決 1. 通信制御 • PodとAWSリソース間: Security Groups for Pod • Pod間: Network Policy 2. 権限分離 • AWS: IAM ResourceTag ABAC導入 • EKS: Kubernetes RBAC見直し

Slide 45

Slide 45 text

Node最適化ツールの導入問題 • Cluster Autoscalerでは、インスタンスタイプの最適化ができず、過剰なリソースとコストが発生 • Nodeの起動に時間がかかり、スケジューリングの遅延が発生することも解決 • Karpenterに移行し、Podのリソース要求に応じて最適なNodeを起動 • インスタンスタイプを動的に選定し、コスト効率の良い構成を自動で実現 • 使用率の低いノードは自動で削除、クラスタ全体のコストを削減

Slide 46

Slide 46 text

1.背景と課題 2.初期の構成と技術選定 3.リリース以来の改善 4.これから目指すこと

Slide 47

Slide 47 text

完全なIDPへ IDP(Internal Developer Platform ): 開発者が機能開発に集中できるよう、共通化・自動化された基盤や仕組みを提供するもの現時点で実現できていること • 標準化されたテンプレートとCI/CDの提供 • 迷わないオンボーディング体験の整備 • Platform / 開発チーム間の明確な責任分離これから目指していくこと • トイルの解消による開発者・運用者のペインを減らすこと • より柔軟で直感的な利用者セルフサービス体験を強化すること • プラットフォーム全体の状態と価値を、定量的に可視化・改善すること

Slide 48

Slide 48 text

SLI/SLOの導入「Platform 」は見えないプロダクト、価値を定量的に示すことが難しい • どのような指標が意味があるのか、利用者視点での SLI 設計を検討している段階 • SLIの例セルフサービス機能の利用率デプロイ成功率デプロイ所要時間 • 利用者視点の SLO を設定し、期待水準を明確化 • 定量的なデータに基づいた改善サイクルを回していける理想

Slide 49

Slide 49 text

まとめ

Slide 50

Slide 50 text

まとめ • AmebaのPlatform構築のきっかけや初期の技術選定について • Platform運用における問題と改善点について • これから目指しているPlatformの形について