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

はいそれでは持続可能なプラットフォーム運用エコシステム導入の判断基準と運用戦略と題しましてサイバーエージェント谷成が発表させていただきます
はい名前は谷成 雄と申します 2014年新卒で入社し現在サービスリライアルPTグループという通称SRGというチームで活動しております
SRGは横断SREとしてメディア事業そしてサイバーエージェントグループへのSREを導入を促進し信頼性を高める取り組みを行っているグループとなっております
現在私はSRGとしてアメーバプラットフォームウィンチケットと関わっており直近業務で触れたエコシステムたちを以下にまとめてみました
はい本日のコンテンツなのですがまず最初に背景と目的エコシステム導入の判断基準
導入したエコシステム例実運用からの学びまとめという順番で発表させていただきます
まず最初に本日お話しすることとお話ししないことについて共有させてください
本日お話しすることはKubernetesを利用したプラットフォーム上にエコシステムを導入する際に考えることについてご共有いたします
続いて実務で導入検討したエコシステムについて実例を交えながらご紹介いたします
最後にエコシステムの管理についてご紹介いたします
本日お話ししないことなんですが運用中のプラットフォームについての細かい設計や運用については本日発表いたしません
こちらプラットフォームエンジニアリングミートアップシャープ12で発表いたしましたので興味がある方はこちらご参照いただければと思います
後ほどスライドはPDFにて公開しますのでそちらでご参照いただければと思います
ではまず最初に背景と目的について説明させていただきます
まずエコシステムの定義をさせてください
本発表ではエコシステムをKubernetesを中心としたCNCFプロジェクト群というふうに定義させていただきます
CNCFプロジェクト以外のオペレーターなどのサービスもあると思うのですが
本発表では便宜上CNCFのプロジェクト群と定義させていただきます
こちらの図はCNCFランドスケープより参照している図で一部のスクリーンショットになっているのですが
多くのエコシステムが存在していることが確認できるかと思います
開発を加速させるためにアプリケーション側の要望がいろいろ出てくる場合が発生すると思います
アプリケーションを柔軟にスケールさせたい
依存関係のあるジョブを実行したい
リソースを安心してリリースを安心してできるようにカナリアリリースがしたい
ログを独自の報酬で収集したいなどです
エコシステムを導入することでアプリケーションが開発者の要望に応えることができることが多々あります
例としては依存関係のあるジョブを実行したいというときに
アルゴワークフローの導入をお願いしますといったことで導入すると思い通りにジョブが実行できるであったり
GitOpsもやりたいというときにアルゴCDの導入をお願いしますということで
自動デプロイができて最高みたいな形でテンションが上がったりします
モニタリングを充実させたいということでプロメテウスグラファナの導入をお願いしますということで
可視化もバッチリみたいなケースも考えられるかと思います
ただたくさんのエコシステムを取り入れることでアプリケーション側の要望は応えられるのですが
それでハッピーとなればいいのですが実際はそうはならないケースが発生します
運用者の負荷がどんどん大きくなっていきます
Kubernetesのバージョンアップを例にとって考えてみます
Kubernetesだけのバージョンアップであれば
当初1週間あればバージョンアップできるかなと考えていた場合のケースをご紹介します
例えばKubernetesのバージョンアップを始めて
デブ環境でアルゴCDとかが動かない
プロメテウスの互換性に問題がある
エクスターナルシークレットAPIのエラーが発生するなど
その他のエコシステムを修正しながらアップデートをしていくと
全てのエコシステムの調査と修正の完了に
2ヶ月経ってしまったというようなことも発生し得るかと思います
Kubernetesのライフサイクル的に大体4ヶ月に一度バージョンアップするので
1人バージョンアップを専任する運用担当者みたいなのが
生まれてしまうことも考えられます
バージョンアップ以外にも問題がありまして
エコシステムが増えていくと
エコシステムに対しての勉強量が多く必要になってきて
実際には導入していないエコシステムだが
エラーになったときにプラットフォーム運用者として呼び出されて
対応しないといけないであったり
エコシステムの設定不備によりサービスに影響が発生してしまったり
脆弱性対応が必要となると
エコシステムの量によって脆弱性が出る可能性が上がってしまうので
対応が増えてしまう
コスト面も問題が感じられていて
エコシステムも動かすにはリソースが必要となるので
手当たり次第エコシステムを導入してしまうと
コストが増加することが考えられます
エコシステムの導入のメリットとデメリットについてまとめてみました
メリットとしましては機能を実現するための豊富な選択肢があって
導入することによってユーザーのニーズに大体対応可能となっております
OSSなので自由度や拡張性が高いということも考えられます
コミュニティによる急速な進化の恩恵を受けることもできます
逆にデメリットといたしまして
選択肢が多すぎて選定が難しい
ツールが増えるほど学習運用コストが増大していく
ライフサイクルが短いエコシステムも存在していまして
ライフサイクルが短いエコシステムを採用してしまうと
EOLの後にパッチを当てて運用したり置き換えたり
利用を中止したりする運用負荷が発生してしまいます
エコシステムの導入の判断基準について説明いたします
まず最初に導入しないで解決できる道を探るのが
良いのではないかなと考えております
工夫することにより要件を満たすことができないかを
まず考えてみます
例えばアプリケーションの要望として
ジョブを細かく制御したいといったときに
アルゴワークフローやテクトンを導入することで
実現できたりします
CICD経由でデプロイしたいといったときに
アルゴCDやフラックスを導入することで
実現できたりします
簡単なカナリアリリースをしたい場合は
アルゴロールアウトやイスティオリンカーDなどを
導入することで実現できたりします
しかし実際要件を詰めていくと
意外と要件としては基本機能で足りることがあったりします
例えばジョブを細かく制御したいときは
ジョブにバックオフリミッツや
スタートデッドラインセカンズなどの設定をすることで
要件を満たせたり
CICD経由でデプロイしたい場合は
KubeCTLやHelmを既存のCICDに組み込んだり
簡単なカナリアリリースをしたい場合であれば
サービスウェイトやレプリカ数を調整することで
実現できたりします
突き詰めていった結果
やりたいことがエコシステムを利用できないときに
エコシステムの導入に踏み切るのが良いかと思います
例えばどのような状況があるかといいますと
ジョブを細かく制御したいの詳細な内容に
複数ステップの依存関係がある複雑なワークフローを
実行したいなどがある場合は
エコシステムが必要になってきます
CICD経由でデプロイしたい場合は
GitOpsによる宣言的管理や複数環境への
自動デプロイなどはエコシステムが必要になります
カナリアリリースがしたい場合に
自動メトリックス分析による判定や
自動ロールバック機能は
Kubernetesの標準機能に備わっていないので
このような場合もエコシステムなどが
導入が必要となります
ではエコシステムを導入する際には
どのようにエコシステムを選定していけばいいのかについて
ご紹介させていただきます
まず最初に導入しようとしている
エコシステムの習熟度を確認するのが
良いかなと思います
こちらCNCFのページの
プロジェクトメトリックスという図を
参照しているのですが
CNCFのプロジェクトには
サンドボックス、インキュベイティング、グラチュエイテッド
という成熟度の段階が設定されており
サンドボックスはCNCF内で新しいプロジェクトや
採用実績や安定的が限定なものに関して
サンドボックスという位置づけが与えられます
ある程度採用実績と成長を示したプロジェクトに関しましては
インキュベイティングに昇格されます
最も成熟したプロジェクトで
本格的導入が多くが行われていたり
安定性が認められると
グラチュエイテッドに昇格します
こちらCNCFランドスケープのページで
詳細を確認することができます
こちらで成熟度の他にも
GitHubのスター数だったり
コントリビューター数だったり
リリースサイクルがどのようなリリースサイクルで
行われているかも確認することができるので
エコシステム選定のときには結構有用だと思います
さらにもっと詳細を突き詰めるために
GitHubでの開発状況を確認するの
しに行くのも良いかと思います
イシューの対応状況だったり
プルリクエストの頻度や対応状況
リリースの頻度など
開発のアクティブ度を確認することができます
さらにReadMeを読むことで
インストールやバージョンアップに
どれぐらいのコストがかかるのかの
見積もりなどもすることができるかなと思っております
これがすごい有効なんですけど
先に導入している人に確認するっていうのは
すごい有効だかなと思っております
社内で他に導入事例がないか確認してみて
もし導入事例などがあれば
導入経緯のすり合わせや
実際の運用感や使用感などを確認して
自分が導入するのにマッチしているかなどの
確認をすることができます
あと今回のようなオフラインカンファレンスなどは
結構チャンスかなと考えております
オフラインカンファレンスの場合
さまざまな企業さんが参加しており
いろいろなエコシステムを導入していると思いますので
詳細を確認できるチャンスかなと思っております
コミュニティスラックなどもありますが
オンライン上だといろいろ詳細まで確認するといったことは
難しいと思いますので
こういうチャンスを活用してはいかがでしょうか
それからエコシステム選定の例を
一つ持ってきてみました
これ実際使ってるっていうわけではなく
例題としてこういうものを用意させていただきました
例えば必須条件として
成熟度はCNCFインキュベーティング以上
オア同等の成熟度を満たしている
活動性としまして
過去1年間以内にフューチャーリリースがされている
実績としまして
国内で導入事例が1社以上ある
評価項目をポイント制で判定して
コミュニティがGitHubのスター数が5000以上で2ポイント
開発活動が月間コントリビューター数10名以上で2ポイント
エコシステムの商用サポート利用可能で1ポイント
日本語対応ドキュメントコミュニティなどで1ポイントで
評価基準としまして
必須4項目を満たして
評価4ポイント以上で採用みたいなガードレールを決めておくと
エコシステムを選定しやすくなるかもしれないです
では実際に導入したエコシステムの例について紹介させていただきます
その前に私が今活動している組織について紹介させてください
まずアメーバについてです
アメーバはブログをはじめ最新の芸能人ニュースや漫画占いなど
生きたコンテンツが集結した国民的メディアサービスとなっております
2024年9月に20周年を迎えました
続きましてWinチケットとなっております
Winチケットは競輪オートレースなどの公営競技オンライン投票サービスとなっております
ユーザーの金銭を扱うサービスのため
高い可用性スケーラビリティを実現する必要があり
様々な取り組みを行っております
バックエンドシステムとしましては
GoogleクラウドのKubernetesプロダクトGKE上に
東京大阪のマルチリージョンマルチクラスター構成を取っており
一層を生かした柔軟なリリース戦略や
ケダを用いた柔軟なスケーラビリティを実現しております
その他にも様々な取り組みがありますので
興味がある方はブログを参照していただければと思います
ではAmebaで導入したKubeveraについて紹介させてください
こちらKubeveraはオープンアプリケーションモデルを使用して
開発者のデプロイを簡素化し
拡張性を実現するツールとなっております
例えば右のようなマニフェストを書きますと
サービスに必要なデプロイメント
サービスコンフィグマップ
シークレットなどを展開して
デプロイした状態の時に
サービスとしても利用開始可能な状態になるような
アプリケーションとなっております
こちら導入経緯といたしまして
アプリケーション開発者のKubernetesに対する認知負荷を減らすということと
クラスターを管理する上で
必要な設定をクラスター管理者側で設定することができる
というか強制することができるというところに
メリットを感じて導入に至っております
導入が必要だった理由に関しましては
管理者側で必要な設定を自身ですぐに反映できるようにする必要があったということです
例えば運用で必要なタグを付与するときに
アプリケーション側にお願いして
アプリケーション側の設定範囲を待つみたいな状況が発生することもあると思うのですが
クベベラを使用するとクベベラ側で設定を変更してデプロイすると
全ユーザーのタグが反映されるということが実現できます
クベベラ導入当時は5年前になっており
本発表のような導入基準がなくて
どのように導入していたのかなというようなことを思い出して
ご共有いたします
当時はCNCFのちょうど導入を検討しているときに
CNCFのサンドボックスプロジェクトになって
勢いがあるように感じておりました
当時はサンドボックスプロジェクトの立ち位置も
よく分かっていなかったので採用したのですが
こんなことにその後コミュニティが活発化して
インキュベーティングに昇格しております
クベベラはまだ不安点がありまして
メンテナンス体制が大きく変わって
従来開発主力のアリババクラウドが撤退して
開発状況が怪しい感じになってきているところに
不安点をちょっと感じています
あとクベベラの定義自体はQラングを用いて書くので
管理者側の学習コストが高いというところに
課題点を感じております
続きまして一部界隈でちょっと話題になっていたのですが
エクスターナルシークレッツについて
共有させていただきます
こちらもAmebaで採用しております
エクスターナルシークレッツはこのように
サンドボックスプロジェクトとして
CNCFに採用されております
エクスターナルシークレッツは
エクスターナルシークレッツオペレーターという
オペレーターを動かすのですが
その機能としまして
AWSシークレットマネージャーや
ハッシコープのボルトなど
外部シークレット管理システムから
シークレットを取得して
Kubernetesのシークレットに
自動同期したり管理したりするような
システムとなっております
導入当時は
Kubernetesエクスターナルシークレッツというものを
利用していたのですが
EOLとなりました
こちらの導入経緯としまして
Kubernetesエクスターナルシークレッツの
マイグレーション先として
導入しております
EKSを使用しているので
シークレッツをAWSシークレットマネージャーで
管理したいというような
要望がありました
こちらも不安点がありまして
今年の8月頃に
メンテナー不在で
メンテナンス停止という
噂が流れてきたんですが
9月頃
暫定メンテナーを確保できたので
メンテナンスが継続されそうというような
雰囲気になっております
でもちょっとメンテナーの部分で
結構不安を感じております
なぜAWSシークレットマネージャーを
使いたいのに
AWSシークレットマネージャーCSドライバーを
利用しないのと思われている方が
いるかと思いますが
こちらプラットフォーム構築当時は
まだAWSシークレットマネージャーCSドライバーの
機能自体が存在していなかったので
こちらのシステムを採用しております
続きまして
ケダについて紹介させていただきます
こちらはWinTicketにて導入しております
ケダの機能について紹介いたします
イベント駆動型のオートスケーリングを
Kubernetes上で実現するエコシステムと
なっております
外部システムやイベントソースを利用して
Pod0から動的にスケーリングさせるというような
機能を持っております
実現したかったことといたしまして
投票集計処理などのHPAのCPUスケールでは
間に合わないような処理に対して
別の指標を用いて事前にスケールをさせたい
というようなことが実現したかったです
さらにこれを実現する際にスケールの指標に関しては
アプリケーションに手を入れることなく
元からあるメトリックスなどを利用できると
良いなというふうに検討しておりました
検討した結果
ケダが良さそうということで
導入を考えるきっかけになりました
ケダを導入する際なんですが
本発表のような評価塾を利用して導入することに踏み切りましたので
当時の状況を共有させていただきます
当時はもうケダはCNCFの成熟度といたしましても
グラジュエイテッドになっており
スター数9000
コントリビューター数406
GitHubのリリース頻度も
7月に1度ぐらいリリースされており
他の部署や他の会社の人に確認したところ
導入目的に沿っていることの確認だったり
昔は運用大変だったけど
成長して運用がすごい楽にできるようになったなどの
ストーリーを聞くことができたので
導入に踏み切ることができました
実運用からの学びについてご共有させていただきます
デザインドックを残しておくことは大事かなと思っております
こちら右はアメーバで使用している
デザインドックのテンプレートとなっております
デザインドックを残すことによって
なぜこのエコシステムを選んだか
新しい運用担当者が来た場合でも
すぐに把握することができます
運用の心理的安全性を確保するために
なぜこのエコシステムを運用しているかの納得感も
デザインドックから得られることができるかと思います
最近はAIに聞くと色々なことを答えてくれるんですけど
当時の気持ちはAIは答えてくれないので
このようにデザインドックに残しておくことで
当時の気持ちを共有できるかなと思います
続きましてシステム結合密度と障害影響範囲について
考えるのが重要かなと思います
右の図は今日発表したスライドに出てきた
エコシステムを
自分の頭の中にあるものをグラフ化したものです
システム結合密度が高いものに関しましては
障害影響範囲が大きくなってしまいますので
選定の時点で慎重に選ぶ必要があります
システム結合密度が高いものに関しましては
サービスを利用中止したり他のものに置き換えたりする場合に
大変な作業となってしまいますので
選定を慎重にする必要があります
システム結合密度と障害影響範囲が小さいところでは
実験的なエコシステム導入をするのも良いかもしれないです
エコシステムの開発が終了するとどうなるかということについて
説明させていただきます
エコシステムの開発が終了してしまうと
Kubernetesのバージョンは上がり続けるので
開発が終了したエコシステムが
そのバージョンに対応できなくなって
エコシステムが使用できなくなるという可能性が出てきます
例えばKubernetesが新しいAPIを作って
前のAPIをデプリケートして
それを使っているエコシステムとかは
機能が一部使えなくなったり
利用ができなくなったりしてしまいます
Amebaのプラットフォームでは
ヒレラキカルネームスペースコントローラーというものを
使用したのですが
開発が終了して
イメージの読み取りができなくなったケースが発生しました
下記のリンクは
弊社石川が当時のことを執筆したブログになるので
詳細が気になる方はこちらご参照ください
こちら一時対応として
ECRにイメージをコピーして
そちらを利用することにしております
選定してもバージョンアップ作業は
結構大変なものでして
結構運用しているとこういうことがしたいというので
基本機能では実現できないので
エコシステムを導入するというようなケースが結構増えてきます
バージョンアップはどうしても避けられないものなので
バージョンアップ機能を自動化して
楽にバージョンアップできないかなというような機能を
今考案中となっております
こちらの図はGitHub Actionsでキックすると
現在のバージョンと最新のバージョンを表示したり
それをもとにプルリクエストを作成して
プルリクエストを認証すると
バージョンアップをするというような仕組みを考案しております
最後にまとめをさせてください
本日はエコシステムを導入すると
多くのことができるようになりますが
何でもかんでも導入してしまうと
運用が大変になってしまうということを
共有させていただきました
本日の振り返りといたしまして
エコシステムを導入する際に
運用フェーズを考えて
どのように選択するのが良いかについて
共有させていただきました
運用している上で見えてきた課題について
共有させていただきました
運用の工夫ポイントについて
紹介させていただきました
はい こちら最後採用情報となっておりますので
ご興味ある方は
こちらご参照いただけると
ありがたいです
はい ご清聴ありがとうございました
素晴らしいご講演ありがとうございました
それではこれよりQ&Aセッションに移ります
早速いくつか質問いただいております
まず最初の質問です
OSSのサポートがコミュニティが主になるが
どうしているか知りたいということです
こちらいかがでしょうか
あれ ちょっと質問の意図を
あんまりうまく汲み取れていないのですが
OSSサポートコミュニティが主になるが
どうしているか知りたい
すみません ちょっと
僕の方で質問の意図をちょっと読み取れず
何か
これは想像なんですけれども
内部のプラットフォームと比べて
サポートケースを投げるところが
OSSのコミュニティになるので
そこで起きる
サポートの迅速さとかで
いろいろな課題が発生すると思うんですけど
どうしているか知りたいという意図だと
汲み取りました
なるほどです ありがとうございます
なんとなく理解することができました
そうですね
その機能に関しましては
できる範囲でプリリクスエストは出して
自分たちの思いを伝えるのですが
どうしても運用管理上
そういう日知な機能を入れるわけにはいかない
みたいなお話もありますので
まず最初に一周を投げて向こうと相談します
その実現できない場合に関しましては
別の手段を用いて
解決できないかという道を探るような形で
今のところ運用しております
はい
ありがとうございます
続いての質問です
導入中にデザインドックの内容と
若干異なる形で導入する場合は
デザインドックを合わせて更新しているのですか
将来的にデザインドックと異なる内容で
導入されている場合の認知負荷が発生した場合
どのように吸収しているか教えていただきたいです
はい ありがとうございます
すごくいい質問で
これは結構まだ私たちも課題に持っている点がありまして
デザインドックの更新をうまくできておらず
昔の導入当時の気持ちを振り返るみたいなことでしか活用できていなくて
ずれた場合を修正していくっていうのが必要かどうかは
ちょっとまだ私たちのところでは判断できていなくて
でもバージョンが見えるように更新していくのは
有効だろうなというふうには考えております
はい 以上で大丈夫でしょうか
ありがとうございます
失礼いたしました
残りのお時間も少なくなってまいりましたので
こちらを最後の質問とさせていただきます
バージョンアップの自動化をする上で
調査や検証などいろいろな障害があると思いますが
そのあたりで工夫している点などはありますか
こちら最後ちょっと発表時間に収まらなかったので
最後の機能の詳細はちょっと省いちゃったんですが
後ほどPDFの方で公開させていただこうと思います
こちらバージョンアップの自動化をする上での調査や検証などは
ある程度AIの方に任せて
それで調査した結果をプリリクエストにまとめるみたいな形で
運用の負荷を減らすような試みを
今実験的に行っているところになっております
はい
ありがとうございます
それでは以上でセッションを終了といたします
皆さまもう一度盛大な拍手をお願いいたします
会場 拍手