Robloxのインフラストラクチャをいかにしてより効率的かつ強靭なものにしているか

Robloxが過去16年以上にわたり成長を続ける中、数百万もの没入型3D共同体験を支える技術インフラの規模と複雑さも同様に拡大してきました。当社がサポートするマシンの数は、過去2年間で3倍以上に増加し、2021年6月30日時点の約36,000台から、現在では145,000台近くに達しています。 世界中の人々に向けたこれらの常時稼働型体験を支えるには、1,000以上の内部サービスが必要です。コストとネットワーク遅延を管理するため、当社は主にオンプレミスで稼働する、独自構築のハイブリッド型プライベートクラウドインフラストラクチャの一環として、これらのマシンを展開・管理しています。  

当社のインフラストラクチャは現在、ビジネスをRobloxの経済に依存するクリエイターを含め、世界中で7,000万人以上のデイリーアクティブユーザーを支えています。これら数百万人のユーザー全員が、極めて高いレベルの信頼性を期待しています。当社の体験は没入型であるため、サービス停止は言うまでもなく、ラグや遅延に対する許容度は極めて低いのです。 Robloxは、没入型の3D体験を通じて人々が集う、コミュニケーションとつながりのためのプラットフォームです。没入型の空間でアバターを通じてコミュニケーションをとっている場合、わずかな遅延や不具合であっても、テキストチャットや電話会議よりもはるかに目立ちやすくなります。

2021年10月、当社はシステム全体にわたるサービス停止を経験しました。当初は、あるデータセンター内の1つのコンポーネントにおける問題という小規模なものでした。しかし、調査中に事態は急速に拡大し、最終的に73時間に及ぶサービス停止に至りました。当時、当社は発生した事象の詳細と、この問題から得た初期の知見を共有しました。 それ以来、私たちはそれらの教訓を検証し、トラフィックの急激な増加、天候、ハードウェアの故障、ソフトウェアのバグ、あるいは単なる人的ミスといった要因によって、あらゆる大規模システムで発生しうる障害に対して、インフラの耐障害性を高める取り組みを進めてきました。こうした障害が発生した際、単一のコンポーネント、あるいはコンポーネント群での問題がシステム全体に波及しないようにするにはどうすればよいのでしょうか？ この2年間、私たちはこの問いに注力してきました。取り組みは現在も継続中ですが、これまでの成果はすでに現れています。例えば、2023年上半期には、2022年上半期と比較して、月間1億2500万時間のユーザー利用時間を削減できました。本日は、これまでに実施した取り組みに加え、より強靭なインフラシステムを構築するための長期的なビジョンについて共有します。

バックアップ体制の構築

大規模なインフラシステム内では、小規模な障害が1日に何度も発生します。1台のマシンに問題が生じ、運用から外さなければならない場合でも、ほとんどの企業はバックエンドサービスを複数インスタンスで運用しているため、対応可能です。つまり、1つのインスタンスが障害を起こしても、他のインスタンスがワークロードを引き継ぐのです。こうした頻繁な障害に対処するため、リクエストは通常、エラーが発生した場合に自動的に再試行されるよう設定されています。

しかし、システムやユーザーが過度に頻繁に再試行を行うと、この仕組みは課題となります。その結果、こうした小規模な障害がインフラ全体に波及し、他のサービスやシステムにまで影響を及ぼす原因となり得るからです。ネットワークやユーザーが執拗に再試行を続けると、最終的にはそのサービスのすべてのインスタンス、さらには他のシステムにまで、グローバルなレベルで過負荷を引き起こすことになります。 2021年のサービス停止は、大規模システムでは比較的よくある事象の結果でした。つまり、障害は小規模に始まり、システム全体に伝播し、すべてがダウンする前に解決するのが困難なほど急速に拡大したのです。 

障害発生当時、当社には稼働中のデータセンターが1か所（その内部のコンポーネントがバックアップとして機能）しかありませんでした。既存データセンターが障害によりダウンした場合、手動で新しいデータセンターへフェイルオーバーする機能が必要でした。 最優先事項はRobloxのバックアップ環境を確保することでした。そこで、地理的に異なる地域にある新しいデータセンターにそのバックアップ環境を構築しました。これにより、最悪のシナリオ（データセンター内のコンポーネントに障害が広まり、データセンター全体が完全に機能しなくなる事態）に対する保護が強化されました。現在、1つのデータセンターがワークロードを処理する「アクティブ」状態であり、もう1つのデータセンターはスタンバイ状態でバックアップ（パッシブ）として機能しています。 長期的な目標は、このアクティブ・パッシブ構成から、両方のデータセンターがワークロードを処理し、ロードバランサーがレイテンシ、容量、健全性に基づいてリクエストを両データセンター間で分散させるアクティブ・アクティブ構成に移行することです。これが実現すれば、Roblox全体の信頼性がさらに向上し、数時間かかるフェイルオーバーではなく、ほぼ瞬時にフェイルオーバーできるようになると期待しています。

セルラーインフラへの移行

次の優先事項は、データセンター全体が機能停止に陥る可能性を低減するため、各データセンター内に強固な「防爆壁」を構築することでした。セル（企業によってはクラスターと呼ぶこともあります）は本質的にマシンの集合体であり、これが防爆壁を構築する手段となります。冗長性を高めるため、サービスはセル内およびセル間でレプリケーションされます。最終的には、Robloxのすべてのサービスをセル内で実行し、強固な防爆壁と冗長性の両方の恩恵を受けられるようにすることを目指しています。 あるセルが機能しなくなった場合、安全に無効化することができます。セル間のレプリケーションにより、セルの修復中もサービスは稼働し続けることが可能です。場合によっては、セルの修復がセルの完全な再プロビジョニングを意味することもあります。業界全体では、個々のマシンや少数のマシンのデータを消去して再プロビジョニングすることは比較的一般的ですが、約1,400台のマシンを含むセル全体に対してこれを行うことは一般的ではありません。 

これを機能させるには、セルをほぼ均一な構成にする必要があります。そうすることで、ワークロードをあるセルから別のセルへ迅速かつ効率的に移動させることができます。サービスがセル内で実行される前に満たすべき要件をいくつか定めています。例えば、サービスはコンテナ化されている必要があります。これにより、サービスの移植性が大幅に向上し、OSレベルでの設定変更が誰によっても行われなくなるからです。 セルに関しては「インフラストラクチャ・アズ・コード」の哲学を採用しています。ソースコードリポジトリにはセル内のすべての構成要素の定義を含めており、自動化ツールを使ってゼロから素早く再構築できるようにしています。 

現在、すべてのサービスがこれらの要件を満たしているわけではありません。そのため、可能な限りサービス所有者が要件を満たせるよう支援するとともに、準備が整った際にサービスをセルへ容易に移行できる新しいツールを構築しました。 例えば、新しいデプロイツールはサービスのデプロイをセル間で自動的に「ストライピング」するため、サービス所有者はレプリケーション戦略について考慮する必要がありません。この厳格さにより、移行プロセスははるかに困難で時間がかかりますが、長期的な成果として次のようなシステムが実現します： 

• 障害の封じ込めがはるかに容易になり、他のセルへの波及を防ぐことができる； 
• インフラエンジニアはより効率的に、かつ迅速に作業を進められる； 
• 最終的にセルにデプロイされる製品レベルのサービスを構築するエンジニアは、自分のサービスがどのセルで実行されているかを知ったり、心配したりする必要がなくなります。

より大きな課題の解決

防火扉が炎の拡散を防ぐのと同様に、セルはインフラストラクチャ内の強固な防爆壁として機能し、単一のセル内で障害を引き起こしている問題を封じ込める役割を果たします。 最終的には、Robloxを構成するすべてのサービスが、セル内およびセル間で冗長化されてデプロイされることになります。この作業が完了しても、問題が広範囲に波及してセル全体が機能しなくなる可能性は残りますが、そのセルを超えて問題が伝播することは極めて困難になります。また、セル間の相互交換が可能になれば、別のセルへフェイルオーバーしてエンドユーザーへの影響を防げるため、復旧が大幅に早まります。 

ここで難しいのは、パフォーマンスと機能性を維持しつつ、エラーの伝播機会を減らすために、これらのセルを適切に分離することです。複雑なインフラシステムでは、サービス同士が通信してクエリ、情報、ワークロードなどを共有する必要があります。これらのサービスをセルに複製する際、セル間の通信をどのように管理するかを慎重に検討する必要があります。理想的な状況では、正常でないセルからのトラフィックを、他の正常なセルにリダイレクトします。 しかし、セルを不健全な状態に陥らせる「致命的なクエリ」をどのように管理すればよいのでしょうか？そのクエリを別のセルにリダイレクトすると、まさに回避しようとしているのと同じように、そのセルも不健全な状態になってしまう可能性があります。セルを不健全な状態に陥らせるトラフィックを検出して遮断しつつ、不健全なセルからの「正常な」トラフィックを転送するメカニズムを見つける必要があります。 

短期的な対策として、各コンピュートセルにコンピューティングサービスのコピーを展開し、データセンターへのリクエストの大部分を単一のセルで処理できるようにしました。また、セル間でトラフィックの負荷分散も行っています。さらに長期的な展望として、サービスメッシュで活用される次世代のサービスディスカバリプロセスの構築を開始しており、2024年の完成を目指しています。 これにより、フェイルオーバー中のセルに悪影響を及ぼさない場合にのみセル間通信を許可する、高度なポリシーを実装できるようになります。また2024年には、依存関係のあるリクエストを同一セル内のサービスバージョンに誘導する手法も導入される予定です。これにより、セル間トラフィックを最小限に抑え、結果として障害のセル間伝播リスクを低減できます。

ピーク時には、バックエンドサービストラフィックの70％以上がセル外から提供されており、セルの構築方法については多くの知見を得ていますが、2024年以降もサービスの移行を継続する中で、さらなる研究とテストが必要になると予想しています。取り組みが進むにつれ、これらの「防爆壁」はますます強固なものになっていくでしょう。

常時稼働インフラの移行

Robloxは世界中のユーザーをサポートするグローバルプラットフォームであるため、利用の少ない時間帯や「ダウンタイム」を利用してサービスを移行することはできません。そのため、すべてのマシンをセルに移行し、各セル内でサービスを実行できるようにするプロセスは、さらに複雑なものとなっています。 稼働中のマシンやそれらを支えるサービスを移行する間も、継続してサポートされなければならない常時稼働のエクスペリエンスが数百万件存在します。このプロセスを開始した当初、これらのワークロードを移行するために利用可能な、何万台もの未使用のマシンが手元にあるわけではありませんでした。 

しかし、将来の成長を見越して購入していた少数の予備マシンは保有していました。まず、それらのマシンを使用して新しいセルを構築し、そこにワークロードを移行しました。 私たちは信頼性と同様に効率性も重視しているため、「予備」のマシンが尽きた後も、新たにマシンを購入するのではなく、移行済みのマシンを初期化して再プロビジョニングすることで、さらに多くのセルを構築しました。その後、それらの再プロビジョニングされたマシンにワークロードを移行し、このプロセスを最初から繰り返しました。 このプロセスは複雑です。マシンが置き換えられ、セル構築用に空きになる際、その空き状況は理想的かつ整然とした形では発生しません。マシンはデータホール全体に物理的に分散しているため、断片的な形でプロビジョニングせざるを得ず、ハードウェアの配置を大規模な物理的障害ドメインと整合させるために、ハードウェアレベルのデフラグ処理が必要となります。 

インフラエンジニアリングチームの一部は、レガシー環境（いわゆる「セル導入前」環境）から既存のワークロードをセルへ移行することに注力しています。この作業は、数千もの異なるインフラサービスと数千ものバックエンドサービスを、新しく構築されたセルへ移行し終えるまで続きます。いくつかの複雑な要因があるため、この作業には来年いっぱい、場合によっては2025年までかかる見込みです。第一に、この作業には堅牢なツールの構築が必要です。 例えば、新しいセルをデプロイする際、ユーザーに影響を与えることなく、多数のサービスを自動的に再バランス調整するためのツールが必要です。また、当社のインフラに関する前提に基づいて構築されたサービスも存在します。セルへの移行に伴い将来変更される可能性のある要素に依存しないよう、これらのサービスを修正する必要があります。 さらに、セルラーアーキテクチャではうまく機能しない既知の設計パターンを検索する仕組みと、移行される各サービスに対する体系的なテストプロセスの両方を導入しました。これらのプロセスにより、サービスがセルと互換性がないことに起因するユーザーへの影響を未然に防ぐことができます。

現在、約3万台のマシンがセルによって管理されています。これは全サーバー群のほんの一部に過ぎませんが、これまでのところ移行は非常に順調に進んでおり、プレイヤーへの悪影響は一切ありません。 私たちの最終目標は、システムが毎月99.99％のユーザー稼働率を達成することです。これは、利用時間の0.01％以下しか中断させないことを意味します。業界全体としてダウンタイムを完全に排除することは不可能ですが、私たちの目標は、Robloxのダウンタイムを、ほとんど気づかれないレベルまで低減することです。

スケールに伴う将来への備え

初期の取り組みは成功を収めていますが、セルに関する作業はまだ道半ばです。Robloxが拡大を続ける中、当社はこの技術やその他の技術を通じて、システムの効率性と耐障害性の向上に引き続き取り組んでいきます。その過程で、プラットフォームは問題に対する耐性をますます高め、発生する問題も、プラットフォーム上のユーザーにとって目立ちにくく、影響も徐々に小さくなっていくはずです。

要約すると、これまでに私たちは以下のことを達成しました： 

• 第2のデータセンターを構築し、アクティブ／パッシブ構成の確立に成功しました。 
• アクティブおよびパッシブデータセンター内にセルを構築し、バックエンドサービストラフィックの70％以上をこれらのセルへ移行することに成功しました。
• 残りのインフラの移行を進めるにあたり、すべてのセルを統一された状態に保つために従うべき要件とベストプラクティスを策定しました。 
• セル間の「防爆壁」を強化する継続的なプロセスを開始しました。 

これらのセル間の互換性が高まるにつれ、セル間の干渉は減少します。これにより、監視やトラブルシューティングの自動化、さらにはワークロードの自動移行に至るまで、非常に興味深い可能性が開かれます。 

9月には、データセンター全体でアクティブ/アクティブ構成の実験も開始しました。これは、信頼性を向上させ、フェイルオーバー時間を最小限に抑えるためにテストしているもう一つの仕組みです。これらの実験により、完全なアクティブ/アクティブ構成を目指す上で再検討が必要な、主にデータアクセスに関するいくつかのシステム設計パターンが特定されました。全体として、実験は十分な成果を上げたため、限られた数のユーザーからのトラフィックに対して実験を継続しています。