大規模プラットフォームの信頼性確保
スケーラブルな分散プラットフォームを運用するには、顧客が必要な時に必要なものを確実に提供できるよう、信頼性を確保する取り組みが不可欠です。 特にRobloxのような大規模なプラットフォームでは、依存関係はかなり複雑になり得ます。信頼性の高いサービスを構築するということは、依存関係の複雑さや状態にかかわらず、どのサービスも中断されない（すなわち高可用性）、バグなく動作する（すなわち高品質）、そしてエラーが発生しない（すなわち耐障害性）ことを意味します。
信頼性が重要な理由
当社アカウント・アイデンティティチームは、構築したコンプライアンスサービスがプラットフォームの中核コンポーネントであるため、信頼性のさらなる向上に取り組んでいます。コンプライアンスの欠如は深刻な結果を招く可能性があります。Robloxの自然な運用を阻害することによるコストは非常に高く、障害後の復旧には追加のリソースが必要となり、ユーザー体験も低下してしまいます。
信頼性に対する一般的なアプローチは、主に可用性に焦点を当てていますが、場合によっては用語が混同され、誤用されることもあります。可用性の測定の多くは、単にサービスが稼働しているかどうかを評価するにとどまり、パーティション耐性や一貫性といった側面は、見落とされたり誤解されたりすることがあります。
CAP定理によれば、いかなる分散システムもこれら3つの側面のうち2つしか保証できないため、当社のコンプライアンスサービスは、高可用性とパーティション耐性を実現するために、ある程度の整合性を犠牲にしています。とはいえ、当社のサービスが犠牲にした部分はごくわずかで、後述する合理的なアーキテクチャ変更により、良好な整合性を実現する仕組みを見出しました。
信頼性を高めるプロセスは反復的なものであり、インシデントが発生する前に欠陥を予防・発見・検知・修正するため、綿密な測定と継続的な作業が密接に連携しています。当社のチームは、以下の実践に大きな価値を見出しました：
- 適切な測定 - 品質が顧客にどのように提供されるか、また依存関係がどのように品質を当社にもたらすかについて、包括的な可観測性を構築する。
- 先を見越した対応 - アーキテクチャレビューや依存関係のリスク評価などの活動を実施する。
- 是正の優先化 - 当社のサービスおよび関連する依存関係におけるインシデント報告の解決に、より高い注意を払う。
より高い信頼性を構築するには、品質重視の文化が不可欠です。私たちのチームはすでにパフォーマンス主導型開発に注力しており、プロセスの成功はその定着にかかっていることを理解していました。チームはこのプロセスを全面的に採用し、これらの実践を標準として適用しました。以下の図は、このプロセスの構成要素を示しています：
適切な測定の力
指標についてさらに深く掘り下げる前に、サービスレベル測定に関して簡単に説明しておきます。
- SLO（サービスレベル目標）とは、私たちのチームが目指す信頼性の目標値（例：99.999%）のことです。
- SLI（サービスレベル指標）とは、特定の期間における達成された信頼性（例：昨年2月の99.975%）のことです。
- SLA（サービスレベル契約）とは、特定の期間において提供することが合意され、またユーザーから期待される信頼性（例：週あたり 99.99%）のことです。
SLIは、可用性（未処理または欠落したレスポンスがないこと）、障害耐性（サービスエラーがないこと）、および達成された品質（予期せぬエラーがないこと）を反映すべきです。したがって、我々はSLIを、サービスに送信されたリクエスト総数に対する成功レスポンスの「成功率」と定義しました。成功レスポンスとは、時間通りかつ適切な形式で送信されたリクエストであり、接続エラー、サービスエラー、または予期せぬエラーが発生しなかったことを意味します。
このSLI、すなわち成功率は、利用者（クライアント）の視点から収集されます。その目的は、利用者に提供される実際のエンドツーエンドの体験を測定し、SLAが確実に満たされていると確信できるようにすることです。そうしなければ、クライアントとの接続に関わるインフラ上の懸念をすべて無視した、誤った信頼性の感覚を生み出してしまうことになります。利用者向けSLIと同様に、潜在的なリスクを追跡するために依存関係SLIも収集しています。 実際には、すべての依存関係SLIはサービスSLAと整合している必要があり、それらとは直接的な依存関係にあります。一方が失敗すれば、すべてが失敗したことを意味します。また、サービス自体（すなわちサーバー）からのメトリクスも追跡・報告していますが、これは高信頼性を実現するための実用的な情報源ではありません。
SLIに加え、すべてのビルドでは、CIワークフローによって報告される品質メトリクスが収集されます。この取り組みは、品質ゲート（コードカバレッジなど）を厳格に適用し、コーディング標準への準拠や静的コード解析といったその他の有意義なメトリクスを報告するのに役立ちます。このトピックについては、以前の記事「パフォーマンス主導のマイクロサービス構築」で取り上げました。 信頼性について語る際、品質への綿密な配慮は大きな意味を持ちます。なぜなら、優れたスコアを達成するために投資すればするほど、悪条件下でもシステムが故障しないという確信が深まるからです。
私たちのチームには2つのダッシュボードがあります。1つは、コンシューマーSLIと依存関係SLIの両方に関するすべての可視性を提供します。もう1つは、すべての品質メトリクスを表示します。現在、これらすべてを単一のダッシュボードに統合する作業を進めており、私たちが重視するすべての側面がまとめられ、任意の期間でレポートできるようになる予定です。
障害の予見
アーキテクチャレビューの実施は、信頼性を確保するための基本です。まず、冗長性が確保されているか、また依存関係がダウンした際にサービスが存続できる手段があるかを判断します。 一般的なレプリケーションの概念に加え、当社のサービスのほとんどは、改良されたデュアルキャッシュハイドレーション技術、デュアルリカバリ戦略（フェイルオーバーローカルキューなど）、またはデータ損失対策（トランザクションサポートなど）を採用しています。これらのトピックは別のブログ記事に値するほど広範ですが、最終的には、災害シナリオを考慮し、パフォーマンスへの悪影響を最小限に抑えるアイデアを実装することが最善の推奨策です。
もう一つ予見すべき重要な側面は、接続性を向上させるあらゆる要素です。つまり、クライアントに対して低遅延を積極的に追求し、キャッシュ制御技術、サイドカー、そしてタイムアウト、サーキットブレーカー、リトライに関する高性能なポリシーを活用して、非常に高いトラフィックに備えることです。 これらの実践は、キャッシュ、ストア、キュー、およびHTTPやgRPCにおける相互依存するクライアントを含む、あらゆるクライアントに適用されます。また、サービスからの正常信号を改善し、ヘルスチェックがすべてのコンテナオーケストレーションにおいて重要な役割を果たすことを理解することも意味します。当社のサービスのほとんどは、ヘルスチェックのフィードバックの一環として、状態悪化時のシグナルを改善しており、正常信号を送信する前にすべての重要なコンポーネントが機能していることを確認しています。
サービスをクリティカルな部分と非クリティカルな部分に分解することは、最も重要な機能に焦点を当てる上で有用であることが実証されています。以前は管理専用エンドポイントを同じサービス内に配置していましたが、使用頻度は低かったものの、全体的なレイテンシ指標に影響を与えていました。これらを独立したサービスに移行したことで、あらゆる指標が好転しました。
依存関係リスク評価は、依存関係に潜む潜在的な問題を特定するための重要なツールです。つまり、SLI（サービスレベル指標）が低い依存関係を特定し、SLA（サービスレベル契約）の整合性を求めます。これらの依存関係は統合段階において特別な注意を要するため、新しい依存関係が当社の計画に十分対応できる成熟度にあるかどうかをベンチマークし、テストするために追加の時間を割いています。その好例が、Roblox Storage-as-a-Serviceの早期導入です。 このサービスとの統合には、バグチケットの登録や、発見事項やフィードバックを共有するための定期的な同期ミーティングが必要でした。これらの作業にはすべて「reliability」タグを付与し、その発生源と優先度を迅速に特定できるようにしています。新しい依存関係が利用可能であると確信できるまで、特性評価を頻繁に行いました。この追加作業により、共通の目標に向かって協力し合うことで、私たちが提供することを期待する信頼性のレベルまで依存関係を引き上げることができました。
混沌に構造をもたらす
インシデントの発生は決して望ましいことではありません。しかし、発生した際には、信頼性を高めるために収集し、学ぶべき有意義な情報が得られます。私たちのチームには、一般的な全社的なレポートとは別に作成されるチーム独自のインシデントレポートがあり、影響の規模に関わらずすべてのインシデントに焦点を当てています。 私たちは根本原因を特定し、将来的にそれを軽減するためのすべての作業に優先順位を付けます。このレポートの一環として、優先度の高い依存関係インシデントの修正のために他チームを招き入れ、適切な解決策をフォローアップし、振り返りを行い、私たちにも当てはまる可能性のあるパターンを探します。
チームはサービスごとに「月次信頼性レポート」を作成しており、これにはここで説明したすべてのSLI、信頼性問題により作成されたチケット、および当該サービスに関連するインシデントが含まれます。私たちはこうしたレポートの作成に慣れ親しんでいるため、次の自然なステップとして、データの抽出を自動化しようとしています。この定期的な活動を行うことは重要であり、開発において信頼性が常に追跡され、考慮されていることを再認識させるものとなります。
当社の監視システムには、カスタムメトリクスや改良されたアラート機能が組み込まれており、既知の問題や予期される問題が発生した際に、可能な限り迅速に通知を受け取れるようになっています。誤検知を含むすべてのアラートは、毎週レビューされています。現時点では、アラートがトリガーされた際やエラーが発生した際にユーザーがどのような状況になるかを理解し、全員が適切な対応を取れるよう、すべてのドキュメントを整備することが重要です（例えば、プレイブックや統合ガイドラインを整合させ、頻繁に更新しています）。
結局のところ、より高い信頼性を達成する上で最も重要かつ決定的な要因は、組織文化への「品質」の浸透です。日々の業務にこれらの実践を取り入れた結果、すでに成果が出始めていることが確認できます。 私たちのチームは信頼性にこだわり、それが私たちの最も重要な成果です。潜在的な欠陥が及ぼしうる影響や、それがいつ発生しうるかについての認識を高めました。これらの実践を導入したサービスは、一貫してSLO（サービスレベル目標）とSLA（サービスレベル契約）を達成しています。私たちの取り組みを追跡するのに役立つ信頼性レポートは、チームが成し遂げた成果の証であり、他のチームに情報を提供し、影響を与えるための貴重な教訓となっています。このようにして、信頼性の文化はプラットフォームのあらゆる構成要素に浸透しています。
信頼性を高める道のりは容易ではありませんが、人々のつながりのあり方を再定義する、信頼されるプラットフォームを構築したいのであれば、それは不可欠なものです。
アルベルトは、Robloxのアカウント・アイデンティティチームに所属するプリンシパル・ソフトウェア・エンジニアです。ゲーム業界に長く携わり、多くのAAA級ゲームタイトルやソーシャルメディアプラットフォームの開発に携わってきました。特に、高いスケーラビリティを持つアーキテクチャの構築に注力してきました。現在は、ベストプラクティスを適用することで、Robloxの成長と成熟を支援しています。
