SRE文化の導入とプラットフォームの信頼性向上の取り組み

SRE文化の導入とプラットフォームの 信頼性向上の取り組み 株式会社 CAM / 株式会社サイバーエージェント 岡麦 SRE NEXT 2024

プロフィール 岡麦 - 2022年度新卒入社 株式会社サイバーエージェン ト/株式会社 CAMへ出向 - 社内プラットフォームの運用・保守をメインとして活 動 @mugiokax #Kubernetes #Istio #Datadog @mugioka

会社紹介 株式会社 CAM 2025年で設立 25周年 サイバーエージェントで最初にできた子会社 エンタメコンテンツ、ビジネスバラエティメディア、ライフ スタイルメディアを主軸に 30サービス以上を開発・運用 エンジニアは 約60名

本セッションで話すこと 「高品質なサービスを、より早くユーザーに提供」 し、開発者によるビジネスインパクトを最大化する ために、「Fensi Platform」 という独自のマルチテナ ント型プラットフォームを構築しています 20以上のサービスがプラットフォーム上で稼働

本セッションで話すこと マルチテナントってやっぱり難しい 1. プラットフォームの信頼性・全体最適 2. 突発的な負荷が発生するサービスの信頼 性・個別最適 これらをコントロールしながら、円滑なサービス開 発が行える必要がある

本セッションで話すこと 開発者、ビジネス職の方を巻き込みながら 二つの軸となる信頼性のコントロールに取り組ん でいる事例を紹介します

1.Fensi Platform の信頼性 2.突発的な負荷が発生するサービスの信頼性 3.開発スピードを落とさず信頼性をコントロールする 4.終わりに

Fensi Platform の信頼性

マルチテナント型プラットフォームの課題 複数のサービスをプラットフォーム上で同時に支えるということは... 「1つのサービスが過負荷になっても、他のサービスの信頼性はコントロールし全体最適化を 行える必要がある」 先行チケット販売やグッズ販売などが定期的に発生するファンビジネスでは、これが難しい...

負荷試験で浮き彫りになる課題 ファンクラブサイトのイベントに備えて負荷試験 を実施 複数のサービスが依存している決済サーバー が不安定 になる 芋づる式に、他のサーバーも不安定になる プラットフォームで稼働している全サービスの 様々な機能が不安定 に...

負荷試験から学んだ大切なこと 常に「最悪の状態」を想定 し、それに対する対 応を考えておくことで自分達で信頼性をコント ロールできるようにしておく必要がある 複数のサービスを同時に支えるプラットフォー ムの場合は、特に「全体最適化」 に気を配り続 ける必要がある

学びをシステムに反映する Envoy Global rate limiting を活用したテナントご との流量制限 「過負荷状態」 を想定した信頼性のコントロー ル プラットフォームで稼働しているサービス全体 の信頼性のコントロール 、影響範囲の極小化 ＝ 全体最適化 https://developers.cyberagent.co.jp/blog/archives/41989/

• https://developers.cyberagent.co.jp/blog/archives/41989/

ガードレールと信頼性のコントロール ガードレールを整備することで、信頼性のコント ロールが行える場所を増やす - Rate Limiting Circuit Breaker WAF 様々な場所で蛇口を閉められる = 信頼性のコ ントロールがしやすくなる

突発的な負荷が発生するサー ビスの信頼性

全体最適化と個別最適化 「最悪の状態」 を想定した「信頼性のコントロール」 を行うことによって「全体最適化」 は行える ようになったが ファンクラブサイトを利用しているユーザーから見たときに流量制限がされている状態は「信 頼性が高い」と言えるのか 理想は「最悪の状態」を想定しつつも、流量制限が行われず、サービスに要求されたユーザー のニーズに応えられる こと つまり、「全体最適化」 が行えるプラットフォーム上で「個別最適化」 も行える必要がある

信頼性はシステムだけでコントロールできない ファンクラブサイトの様な、ある特定のイベントの 時だけ「リクエスト数が x00倍になる」 ようなサー ビスの信頼性はシステムだけでコントロールで きるのか？ システムを構築して、放置しとけばよしなにユー ザーのニーズに対応してくれるのか？ オートスケーリング？ サーバーレス？ FaaS？

信頼性はシステムだけでコントロールできない 「リクエスト数が x00倍になる」 様な状況下では 「適切な負荷の見積もり」 「サーバーの事前スケールアップ・アウト」 などを「人」が行う必要がある

連携して信頼性をコントロールする ビジネス職 の方はよりユーザーのニーズを把握し、イベントに対するユーザーの動向に詳しい 開発者はサービスのドメインに詳しい SRE はプラットフォームのキャパシティに詳しい それぞれの強み を生かし、協調する ことで「突発的負荷」が発生するファンクラブサイトの様な サービスの「個別最適化」 を行う

すとふぁみの事例 突発的負荷が発生するイベントへの対応 1. 2. 3. 4. イベント情報の記入 ビジネス職 キャパシティプランニング SRE/開発者 イベント仕様の擦り合わせ ビジネス職 /SRE/開発者 イベントの実施

すとふぁみの事例 ~ イベント情報の記入 キャパシティプランニングに必要な情報を集め る 「イベントの時間帯や告知方式」 「予想されるユーザーの流入数」

すとふぁみの事例 ~ キャパシティプランニング ユーザーのニーズに応えるために、負荷試験 や過去のイベントの振り返りを行う 「想定されるリクエスト数を捌けるスペックの 見積り」 「パフォーマンスチューニング」 「Istio Fault Injection を活用した異常ケースの 観測」

すとふぁみの事例 ~ イベント仕様の擦り合わせ 過負荷に陥ってしまった場合、プラットフォームの「全体最適化」を行うために「流量制限」を行 うことへの合意 過負荷に陥らせない ために、「告知方法の変更」 や「ユーザーの導線の分散」 を行うことがで きないかの相談

すとふぁみの事例 ~ イベントの実施 イベントがうまく行けば大ハッピー うまくいかなかったパターンでも「信頼性をコントロール」できる様に想定 をしておく 「データストアが過負荷になってしまった」 「サイトの機能がほとんど使えなくなってしまった」

組織として信頼性に向き合う 様々な職種の方と連携し 「プラットフォーム特有のこと」 「サービス特有のこと」 などを理解してもらうことで「組織として信頼性に向き合い」 より「ユーザーのニーズを満たす サービス」 を提供していく

開発スピードを落とさず信頼 性をコントロールする

開発スピードと信頼性はトレードオフ？ 開発スピードが上がる = リリース数が増える リリース数が増える = 信頼性に影響をきたしやすくなる 信頼性の維持に固執 = リリースにより慎重になる リリースにより慎重になる = 新しい価値をユーザーに届ける開発スピードが低下する 開発スピードが上がり、リリース数が増え、信頼性に影響をきたしやすくなっても ロールしたい 信頼性はコント

開発スピードと信頼性をトレードオフにしない 「開発スピード」が上がりリリースが増える ほど、「信頼性」は低下 しやすくなる 逆に「信頼性」のコントロールを意識しすぎる と、「開発スピード」は低下 し新しい価値をより早 くユーザーに届けることが難しくなる 一定の「信頼性」を保ちつつ、「開発スピード」を向上させられるシステム・仕組みを構築すること で、トレードオフとなる両者のバランスをうまく取りたい

使いやすい負荷試験環境 「central-load-testing」 サービス横断で使用できるChatOps 型負荷試験環境 「使いやすさに特化」 「システムのキャパシティを見積もることに専念」 「ナレッジの蓄積による属人性の排除」 「負荷試験の敷居を下げる」-> 適切なキャパシティプランニングが高頻度で行える様に なる https://cam-inc.co.jp/p/techblog/717710149145330844 https://cadc.cyberagent.co.jp/2023/sessions/sre-eng/

• https://cam-inc.co.jp/p/techblog/717710149145330844
• https://cadc.cyberagent.co.jp/2023/sessions/sre-eng/

高い可観測性 Datadog/Istio を活用 「APM を活用した一気通貫のトレーシング」 「Istio を活用したマイクロサービスごとのメトリクス」 「MongoDB スロークエリの可視化」

GitOps による運用高度化 Argo CD を活用 「オペレーションミスの削減」 「安全で早いロールバック」 「インフラ構築のセルフサービス化」

継続的に信頼性をコントロールしていく SREと開発者の連携を深めるための、週次定例を実施 「インシデントの振り返り」 「各種 EOL 対応の方針決め」 「メトリクスを眺める・改善タスクの起票とアサイン」

今後の展望と課題 開発スピードと信頼性をトレードオフにせず、継続的にコントロールしていくための土台作りはしてきたが課題もある 「無限に続いてしまう改善作業」 信頼性が定量化されていない ため、「信頼性のコントロール」と「新規機能開発」どちらを優先すべきかの 意思決定が人に依 存してしまう

信頼性を定量化し、意思決定に活用する クリティカルユーザージャーニーを定義し、信頼性を定量化することで、 今やるべきことに注力したい 「レイテンシが 10ms 悪化しているが、 SLO 違反していないので 新規機能開発に注力 」 「エラーバジェットを使い果たしてしまったので、 信頼性のコントロールに注力 」 定量化された適切な信頼性を維持 しつつ、高頻度でユーザーに新しい価値を届けられる意思決定

終わりに

まとめ プラットフォーム上で多数のサービスを同時に支える際の、信頼性のコントロールは「全体最 適化」、「個別最適化」どちらも大切 システムでコントロールしきれない 信頼性を組織で協調しコントロールする 「開発スピード」と「信頼性」をトレードオフにしない ためのシステム・仕組みを構築することが 大切

SRE Technology Map 弊社の SRE チームの取り組みや事業部ごとの体制、カルチャーについて網羅的にまとめてます https://www.cyberagent.co.jp/techinfo/info/detail/id=28998

• https://www.cyberagent.co.jp/techinfo/info/detail/id=28998

採用 新卒採用、中途採用（事業部ごと）、実施しています！！ 興味がある方はぜひエントリーを！！ 新卒 https://www.cyberagent.co.jp/careers/students/tech/jobs/detail/id=27087 中途 https://www.r-agent.com/kensaku/kyujin/20240405-089-01-045.html https://hrmos.co/pages/cyberagent-group/jobs/2004419278284361758 https://www.green-japan.com/company/126/job/174675 https://hrmos.co/pages/cyberagent-group/jobs/0000663

• https://www.cyberagent.co.jp/careers/students/tech/jobs/detail/id=27087
• https://www.r-agent.com/kensaku/kyujin/20240405-089-01-045.html
• https://hrmos.co/pages/cyberagent-group/jobs/2004419278284361758
• https://www.green-japan.com/company/126/job/174675
• https://hrmos.co/pages/cyberagent-group/jobs/0000663

ご清聴ありがとうございました