• 4 min read

サイト信頼性のベスト プラクティスを活用して Xbox ゲーム ストリーミングを構築する

先月、Microsoft のいくつかのチームが DevOps をどのように導入したかについてのストーリーを通じ、Microsoft での DevOps への道のりについてお伝えしました。

先月、Microsoft のいくつかのチームが DevOps をどのように導入したかについてのストーリーを通じ、Microsoft での DevOps への道のりについてお伝えしました。このシリーズの次のストーリーとして、1 つのチームが従来の運用の役割からサイト信頼性エンジニアリング (SRE) の役割に移行したことをご紹介したいと思います。これは、Xbox 信頼性エンジニアリングおよび運用 (xREO) チームのストーリーです。

この移行は簡単ではありませんでした。しかし、Microsoft がクラウド ゲーム ストリーミングを通じ、ゲーマーがどこでも Xbox ゲームをプレイできるようにすると決めたとき (Project xCloud)、これは必須不可欠なものになりました。最先端のテクノロジをトップレベルのカスタマー エクスペリエンスで実現するために、チームは仕事のやり方を再定義する必要がありました。それには、開発チームとのコラボレーションの強化、自動化への投資、アプリケーション ライフサイクルの初期段階での関与が含まれます。このブログでは、その過程でチームによって収集された、重要な学びの一部を確認します。チームの完全なストーリーを詳しく確認するには、xREO チームの道のりをご覧ください。

安定したゲームプレイに対する要件と共同作業に対するニーズ

ゲーム ストリーミング セッションを成功させるには、安定したエクスペリエンスが不可欠です。ゲーマーがクラウドからストリーミングされたゲームを確実に利用できるようにするには、近くのコンソールで実行されているように感じられるようにする必要があります。つまりこれは、エンド ユーザーに近い多数のデータセンターで実行される、グローバルに分散されたクラウド ソリューションを作成する必要があることを意味します。Azure のグローバル インフラストラクチャがこれを可能にします。しかし、多数の Azure リージョン上で実行されているシステムの運用は、大きな課題を伴います。

このテクノロジの設計と構築を開始した Xbox 開発者は、このシステムをただ構築して、運用担当者に "丸投げすればいい" わけではないことを理解していました。運用環境での運用を考慮してシステムの設計を始めることができるよう、両方のチームがアプリケーションのライフサイクル全体を通じて共同作業する必要がありました。

クラウドからストリーミングされたレーシング ゲームを示すモバイル デバイス

運用を念頭に置いたクラウド ソリューションの設計

多くの大規模な組織では、開発チームと運用チームが縦割りで作業していることがよくあります。システムを計画および構築するときに、開発者が運用を考慮しているとは限りません。一方で運用チームは、運用環境でコードをデプロイして運用している場合でも、コードを触る権限は与えられていません。SRE アプローチを採用すると、システムの信頼性がアプリケーション ライフサイクル全体に組み込まれ、運用環境でシステムを運用するチームは、計画段階での貴重な貢献者になります。新しいアプローチでは、設計フェーズで xREO チームに関与してもらうことで共同作業の環境が築かれ、技術的な選択とシステムの設計を共同で行うことができるため、規模に必要とされる要件で運用することができました。

コンテナーを活用して所有権を明確に定義する

開発チームと xREO チームが共同で行った最初の技術的な決定の 1 つは、コンテナー テクノロジを利用したマイクロサービス アーキテクチャを実装することでした。これにより、開発チームはチームが所有している .NET Core マイクロサービスをコンテナー化し、コンテナーが実行され xREO チームが所有していたクラウド インフラストラクチャから依存関係を取り去ることができました。

両チームが早期に決定したもう 1 つの技術的な事項は、基になるコンテナー オーケストレーション プラットフォームとして Kubernetes を使用することでした。これにより xREO チームは、Kubernetes クラスターを簡単にデプロイすることができるマネージド Kubernetes クラウド プラットフォームである Azure Kubernetes Service (AKS) を活用できるようになりました。複数の Azure リージョンにわたって複数のクラスターを実行するときにチームが直面する、運用の手間が大幅に軽減されました。このようなことを共同で選択することによって、所有権が明確になりました。開発者はコンテナー内部のすべてを担当し、xREO チームはこれらのコンテナーをホストできるようにするクラウド インフラストラクチャを構成する AKS クラスターとその他の Azure サービスを担当します。各チームは、運用環境におけるそれぞれの部品のデプロイ、監視、運用を担当します。

このような種類のアプローチでは、アカウンタビリティが明確になり、運用環境でのインシデント管理が簡単になります。というのも、インフラストラクチャとアプリケーション ロジックにコードの依存関係がある場合、問題が起こった時にそれを解きほどくのには非常に困難を伴うからです。

ノート PC の前で会議室に座っている xREO チームの 2 人のメンバー。

インフラストラクチャの自動化によるスケーリング

もう 1 つのベスト プラクティスとして、xREO チームはインフラストラクチャの自動化に投資しました。各 Azure リージョンの複数のクラウド サービスを手動でデプロイすることは、スケーラブルではなく、時間がかかりすぎていました。チームでは "コードとしてのインフラストラクチャ" (IaC) と呼ばれるプラクティスを採用し、Azure Resource Manager テンプレートを使用して、複数の Azure リージョンへのデプロイを最小限の作業で行うことができるようにするクラウド環境の宣言型定義を作成しました。

インフラストラクチャをコードとして管理することで、継続的インテグレーションと継続的デリバリー (CI/CD) を使用してそれをデプロイし、新しい Azure リソースを既存のデータ センターにデプロイしたり、インフラストラクチャ定義を更新したり、必要に応じて新しい Azure リージョンをオンラインに切り替えたりするプロセスをさらに自動化することもできます。IaC と CI/CD の両方を使用すると、チームは無駄が多く反復的な日常作業を回避して、手動で手順を行うことにより発生する人的エラーのほとんどのリスクを取り除くことができます。チームは、手動による作業やチェックリストに時間を費やすのではなく、プラットフォームとその回復性をさらに強化することに専念できます。

サイト信頼性エンジニアリングを実行に移す 

xREO チームの道のりは、ゲーマーに最高のカスタマー エクスペリエンスを届けるというニーズに対応することから始まりました。これは、最先端のイノベーションを通じた新しいエクスペリエンスで顧客を満足させたいと願うチームが、ソフトウェアの設計、作成、運用の方法を進化させる必要があることを示す優れた例です。アプローチを運用にシフトし、開発チームと緊密に連携して作業することが、xREO チームにとっての真の変革となりました。

この新しい考え方を採り入れることで、チームはさらに優れた回復力を維持し、システムをさらに拡張することができ、すべてのゲーマーがクラウド ゲーム ストリーミングを利用できるようになりました。

関連資料