ABEMA の信頼性を支える Dark Canary リリースの導入

本記事は、CyberAgent Group SRE Advent Calendar 2025 18日目の記事になります。

はじめに

ABEMA SRE チームでエンジニアリングマネージャーをしているの宮﨑（@zakimiiiii）です。
また、サイバーエージェント全体では Developer Experts 制度における、 SRE 分野の NextExperts を担っています。

これまで WINTICKET、ジャンプTOON から「DarkCanary」の導入に関する記事が公開されてきました。

この度 ABEMA のバックエンドにおいても DarkCanary リリースを導入しました。
ABEMA のバックエンドはマイクロサービスアーキテクチャを採用しており、 GKE を用いた大規模なシステムとなっています。
このようなシステムにおいて DarkCanary を導入するに至った背景、実現方法、使い方についてご紹介します。

前提

DarkCanary 環境とは

DarkCanary 環境とは、特定の条件下においてアクセス可能なクローズドなテスト環境です。
通常のリクエストは到達しないため、ユーザーには影響を与えずに実際のインフラや設定を利用したまま動作検証が可能になります。

導入の背景

マージするまで動作確認ができない

ABEMA は大規模なマイクロサービスとなっています。そのため、ローカル環境で同様の環境を用意して動作確認することは難しいです。
また、トランクベース開発を採用していることから dev 環境にデプロイするには一度マージしなければならず、そのタイミングで本番にもリリースがされます。このことから、意図せず不具合が本番に出てしまったり、修正する際には再度 PR 作ってマージしてデプロイするまで待たなければならない、といった課題がありました。

本番のユーザー情報ではないと確認ができない

レコメンド機能のように、十分なデータがある環境でなければ正しく動作を確認できない API があります。
こちらについても本番環境に出してみるまで動作確認ができないという課題がありました。

基盤システムの活用拡大

SRE NEXT 2025 「ABEMAの本番環境負荷試験への挑戦」で発表したマルチテナント技術は、本番負荷試験以外でも利用できることを想定して汎用的に構築しました。
前述した課題を受けて、DarkCanary 環境を導入することによる効果が大きいと考え、マルチテナント技術をベースとした DarkCanary 環境を実現しました。

実現方法

ABEMA の GKE クラスターではサービスメッシュを利用しています。マルチテナントは、Istio の VirtualService を利用して実現されており、特定の HTTP ヘッダーによるダイナミックルーティングが行われています。
このベースとなる基盤に対して、 GitHub PR からマルチテナントを起動をキックするサーバーを構築し、 DarkCanary を実現しています。

全体アーキテクチャ図

全体のアーキテクチャ図です。

マルチテナント

DarkCanary の基盤となる技術のアーキテクチャ図です。
自作のカスタムオペレータで実現されています。主な動きとしては、カスタムリソースを元にアプリケーションのコピーを行い、コピーしたアプリケーションへのルーティングを VirtualService に書き込んでいます。
DarkCanary を実現するにあたり、カスタムオペレータの重要な機能として、パッチ機能があります。カスタムリソースの設定次第で、コピーしたアプリケーションに対してパッチを当てることができる機能となっており、DarkCanary 用のイメージはパッチ機能を使って反映させています。

その他マルチテナントに関する部分については、SRE NEXT 2025 「ABEMAの本番環境負荷試験への挑戦」をご確認ください。

GitHub PR からマルチテナントの起動

GitHub PR からマルチテナントを起動する部分のアーキテクチャです。
開発者の利便性を考えて GitHub PR のコメントを起点として、 DarkCanary を立ち上げる仕様となっています。 GitHub と Tenant Custom Operator を繋ぐ役割として、新規に DarkCanary Server を構築しました。
GitHub → DarkCanary Server → Tenant Custom Operator の流れを簡単に説明します。

ABEMA エンジニアは GitHub PR に特定のコメントを記述します。
PR のコメントを起点として GitHub Actions が起動し、 DarkCanary Server へリクエストします。
- ABEMA のバックエンドはモノレポを採用しています。PR の差分をもとに、影響を受けるマイクロサービスを判別しています。対象のマイクロサービスのイメージをビルドして、 Artifact Registry へプッシュします。
- リクエストボディに対象のマイクロサービスとイメージタグを含めて、 DarkCanary Server へリクエストします。
- GitHub から DarkCanary Server 間は IAP による認証が行われています。
DarkCanary Server はリクエストを受けて、対象のマイクロサービスの k8s リソースを取得し、カスタムリソースを apply します。
カスタムリソースを作成する際に、 Deployment のイメージタグをリクエストボディに含まれているイメージタグにパッチします。
カスタムリソースの apply により Tenant Custom Operator はテナントアプリケーションを構築します。

使い方

ABEMA の DarkCanary では、GitHub PR へのコメントを起点としています。開発者の実際の使い方について説明します。

DarkCanary リリースの流れ

PR へのコメント

PR に特定のコメントをすることで、DarkCanary リリース用の GitHub Actions が起動し、デプロイが開始されます。
デプロイ完了後にコメントでフィードバックが返却されます。

起動完了コメント — DarkCanary デプロイ実行時、完了時にPRに付与されるコメント

PR マージ／クローズ

PR をマージまたはクローズしたときに GitHub Actions が起動し DarkCanary の削除を行います。
削除においても同様で GitHub → DarkCanary Server → Tenant Custom Operator の順に実行され削除されます。

発展した使われ方

DarkCanary はバックエンドをスコープとした仕組みでした。 API の挙動を知るだけではれば十分ですが、実際の画面上でどのような挙動になるかまで把握するのは難しいです。
バックエンドチームの山﨑(@oNqNu)が、 Web チームに所属していた知見を活かし、 Web 環境に対して DarkCanary へ簡単にリクエストできる仕組みを構築してくれました。

以下の画像のように、 Web のデバッグ設定ページから DarkCanary 向けのドメインを設定できるようにすることで、 DarkCanary とフロントエンドの繋ぎ込みを実現しています。

フロントエンドと DarkCanary がつながることによって、エンジニアだけではなく、番組の編成を担うチームも事前に挙動を確認することができる効果がありました。

今後の展望

Gateway API

現在 ABEMA では Ingress を利用しています。 Ingress ではヘッダーベースルーティングをすることができません。そのため、 DarkCanary では Ingress 自体も複製するということを行なっています。
Ingress の立ち上げが必要な DarkCanary を立ち上げる場合、 DNS に対するレコードの登録で非常に時間がかかってしまっています。
ABEMA では Gateway API への移行が進んでいます。 Gateway API の HTTPRoute を利用した、ヘッダーベースルーティングによって DarkCanary 立ち上げまでの時間短縮を行なっていきたいです。

マルチリージョン対応

クラウドプラットフォームチームでは、 ABEMA のマルチリージョン対応を進めています。現在ではマルチテナント基盤の設計がシングルリージョンのみに対応しています。 ABEMA の今後を踏まえ、マルチリージョン対応を行なっていきたいです。

Platform Engineeringの視点から見るAmeba Platformのこれまでとこの先