BBC: エンド ツー エンドのサーバーレス アーキテクチャを使用して、ニュース記事のトラフィックの急増に対応

※この投稿は米国時間 2023 年 5 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回の投稿は、英国の国営放送局である英国放送協会（BBC）の Neil Craig 氏によるものです。同氏は BBC のデジタル配信チームの一員であり、一般向けの www bbc.co.uk や .com ウェブサイトなどのサービスを構築し、スケーリングと運用を確実に行えるようにする責任を負っています。

BBC の一般向けウェブサイトでは、世界中で 1 週間に 4 億 9,800 万人以上の成人に報道、教育、エンターテイメントに関するコンテンツを配信しています。ニュース速報は予測が極めて難しいため、予測不能なトラフィックの急増に対応して簡単にスケールできるコア コンテンツ配信プラットフォームが必要です。  

そのため、私たちは最近、Google Cloud サーバーレス プラットフォーム上にログ処理インフラストラクチャを再構築しました。Cloud Storage、Eventarc、Cloud Run、BigQuery を基盤とする新しいシステムを採用すれば、混雑する時間帯のスケールアップを心配することなく、信頼性の高い安定したサービスを提供できることがわかりました。また、以前のアーキテクチャよりも費用対効果の高い形でサービスを運用することで、ライセンス料の支払いを節約することもできます。スタックの主要なコンポーネントのスケーリングを手動で管理する必要がなくなったことで、データを作成するのではなく使用することに時間をかけられるようになりました。

ログイン時間

サイトを運営し、サービスの実行をスムーズにするために、私たちは Traffic Manager と CDN アクセスログを継続的にモニタリングしています。当社のウェブサイトは、1 日あたり 30 億行を超えるログ行を生成し、注目度の高いニュース イベント中に大量のデータバーストを処理しています。混雑する日には、1 日で 260 億行を超えるログ行に対応しています。

当初の設計では、Cloud Storage バケットにログデータを保存していました。しかし、そのデータにアクセスする必要があるたびに、大量のストレージが接続された仮想マシン（VM）にテラバイト単位のログをダウンロードし、「grep」ツールを使用してデータを検索、分析しなければなりませんでした。この工程を終えるまでに、数時間を要していました。ニュースの多い日には、タイムラグが原因でエンジニアリング チームの仕事に支障が出ていました。

ログデータの可用性を高められる効率的な方法が必要だったため、受信と同時により効率的にログを処理し、トラフィックの急増に反応する新しいシステムを設計およびデプロイし、重要な情報の適時性を大幅に改善しました。

この新しいシステムでは、引き続き Cloud Storage バケットを利用しますが、各ログを受信すると、EventArc を使用してイベントを生成します。そのイベントは、Cloud Run をトリガーして、ファイル名、接頭辞、タイプなど、ログファイルに関するさまざまな情報を検証、変換、強化してから、それを処理し、処理されたデータをストリームとして BigQuery に出力します。このイベント ドリブンな設計により、ファイルを迅速かつ頻繁に処理できます。通常、1 つのログファイルの処理には 1 秒もかかりません。システムにフィードするファイルのほとんどは 100 メガバイト未満の小さなファイルですが、大きなファイルの場合は自動的に複数のファイルに分割され、Cloud Run が自動的に追加の並列インスタンスを高速作成するため、システムをほぼ瞬時にスケールできます。

ニュース報道を提供するグローバル ウェブサイトを運営するという性質上、予測不能なトラフィックの急増が頻繁に発生します。そこから学び、必要に応じてシステムを最適化することで、大量のトラフィックを処理するシステムの能力に自信を持てるようになります。たとえば、9 月に女王の逝去が発表された頃、トラフィックが急増しました。1 分以内に、150 から 200 のコンテナ インスタンスを実行していましたが、多いときは 1,000 を超えることもありました。しかし、インフラストラクチャは正常に機能しました。サーバーレス アーキテクチャの弾力性に依存するようにログ処理システムを設計していたため、この種のスケーリングを処理できることは始めからわかっていました。

サーバーレスの選択に関する当初の懸念は費用面でした。Cloud Run を使用すると、システムに必要な数の VM を実行するよりもはるかに費用対効果が高く、ある程度のトラフィックの急増が発生しても同様の信頼度で対応できることがわかりました。

また、Cloud Run に切り替えると、VM のスケーリングやリソースの使用量の管理とモニタリングに時間を費やす必要がなくなるため、より効率的に時間を使用できます。Cloud Run を意図的に選択したのは、手動の介入なしで適切にスケールできるシステムが必要だったからです。デジタル配信チームとしての私たちの仕事は、このシステムの基盤となるコンポーネントの運用作業を行うことではありません。この点は、Google の運用の専門家チームに任せています。

システムを再構築する際に行ったもう 1 つの意識的な選択は、Google Cloud に組み込まれているサービス間認証を使用することでした。認証メカニズムを自分たちで実装して維持するのではなく、定義したサービス アカウントの OIDC トークンを作成して送信するようにクライアントサイドに指示し、クライアントを認証および承認するようにサーバーサイドに指示するシンプルな構成をいくつか追加しています。もう 1 つの例は、イベントを Cloud Run に push することです。この場合、特定の EventArc トリガーからのイベントのみを受け入れるように Cloud Run 認証を構成できるため、完全に非公開になります。

今後は、新しいシステムにより、データをより安全に活用できるようになります。たとえば、BigQuery の列ごとの権限により、承認されたユーザーに限定されている PII の共有について心配することなく、組織全体の他のエンジニアリング チームにログへのアクセスを開放できます。

私たちのチームの目標は、BBC のすべてのチームが必要なときにウェブで必要なコンテンツを取得し、信頼性と安全性を高め、スケールできるようにすることです。Google Cloud サーバーレス プロダクトのおかげで、比較的少ない労力でこうした目標を達成することができ、以前の世代のテクノロジーよりも管理が大幅に少なく済んでいます。