世界で毎日800万人近くのプレイヤーが同時接続するという、圧倒的な人気を誇るマルチプレイヤーオンラインバトルアリーナゲーム、League of Legends。Riot Gamesが開発したLeague of Legendsは、世界でもっともプレイされているPCゲームであり、eスポーツの爆発的成長のカギともなっています。年1回開催されるLeague of Legends World Championshipでは、13の国際リーグから出場資格を得たeスポーツのチームが集結します。多数の観客数とフォロワー数を誇るeスポーツの大会であり、世界でも最大規模の、もっとも人気のあるゲーム・スポーツイベントです。
2006年に設立されたRiot Gamesのミッションは、つねに世界で最もプレイヤーに寄り添ったゲームを開発し、発表し、運営していくことです。この、プレイヤー体験を最優先するという理念が、Riot Gamesの根幹をなす原動力となっています。そして、Riot GamesがNew Relicのオブザーバビリティプラットフォームを導入した理由も、ここにあります。プレイヤー体験や、それを促進する多くのシステムやマイクロサービスへのエンドツーエンドの可視性が可能になるからです。
社内開発のツールからの脱却
「私たちが注力するのは、いかにマイクロサービスを大規模に運用するかということです」と、Riot Gamesのエンジニアリング・マネージャーのJustin Hawkins氏は話します。「具体的に言うと、私たちの仕事は、すべてのDevOpsチーム、サイト信頼性エンジニア（SRE）チーム、ネットワークオペレーティングセンター（NOC）にオブザーバビリティを提供し、彼らがプレイヤー体験の最適化のためにゲームを監視、トリアージ、運用できるようにすることです」
Riot Gamesのようなマイクロサービスのアーキテクチャーにおいて、プレイヤー体験の提供に関わるさまざまなサービスを可視化することは、それに影響を及ぼす可能性がある問題をすばやく特定するために非常に重要です。「もしプレイヤーがゲームをプレイできなければ、それは私たちにとって重大な問題です」とHawkins氏は言います。「私たちは、プレイヤー体験を実現するために完璧に連携すべきすべての構成要素によって、プレイヤー体験がいかに影響を受けるかを可視化する必要があります」。
オブザーバビリティの必要性を満たすため、Riot Gamesは、最初のゲーム開発時に独自のメトリクス、ログ、アラート機能を開発しました。これがうまく機能したのは、新たなゲームが開発ラインに乗ってくるまででした。「新たなゲームのローンチが近づくにつれ、自社開発のソリューションは規模的な限界を迎えつつありました」とHawkins氏は話します。「私たちは、自社インフラの規模拡大に投資するのか、もしくはこの問題を解決してくれる他者に任せ、自分たちはプレイヤー体験の構築に専念するかの選択を迫られました」
同時に、会社はテレメトリーデータの単一ビューも求めていました。「ツールは数多くありましたが、データを統合的に確認できる方法がありませんでした。問題をトリアージし、調査するためのさまざまに異なる方法があり、データはあちこちに散在していました。それらのすべてのデータを、どうにかして一元化したかったのです」。規模化とツールの分散の問題のいずれもを解決するため、Riot Gamesはオブザーバビリティプラットフォームをデプロイし、自社システムとその他の異なるツールを置き換えることを決めました。
We had dozens of tools, but no integrated way to view the data.
信頼できるプラットフォームのデプロイ
Justin Hawkins氏率いるRiot Developer Experience（RDX）チームは、会社中から要望を集め、業界リーダーや新技術について詳細な評価を実施し、自社システムのさらなる開発コストについても検討しました。数回にわたる概念実証の実施後、Riot Gamesは自社のオブザーバビリティの標準プラットフォームとしてNew Relicを選定し、New Relic LogsとNew Relic Metricsを社内機能と入れ替えました。社内の複数のチームがすでにNew Relic APMを使用しており、非常に使いやすいとわかっていたことも、全チームのNew Relicへの移行という決定を容易なものにしました。
「New Relicは概念実証で非常に高スコアでしたが、決め手となったのは、すでに私たちの仲間がNew Relicに慣れており、New Relic APM製品に信頼を寄せていたことでした」とHawkins氏は言います。決定後、チームは展開のプロセスを開始しました。まず、オブザーバビリティの必要性に対するソリューションを持っていない、新しいゲーム開発に携わるチームから開始し、それからレガシーのモニタリングツールを使用しているチームに展開しました。
ワークフロー改善のためのスケール化
社内で開発したシステムでは、Riot Gamesはログ機能に関して単一の共通デプロイメントを運用していました。「それは巨大なプラットフォームで、ある程度の規模では非常にうまく機能していました」とHawkins氏は言います。「しかし、たとえば『このサービスの過去24時間のログを表示して、エラーメッセージを見つけてほしい』といったクエリをチームの誰かが投げた時、もしその日のインデックスのログデータが18テラバイトあると、その他のすべてのクエリが遅延してしまっていたのです。規模の不足により、全員のワークフローが阻害されていました」
現在、New Relic LogsではログデータとNew Relicの計算リソースがチームごとにセグメント化され、すべてのクエリに対するレスポンスタイムは大幅に改善されました。「全般的なエクスペリエンスが向上しました。チームが使い慣れたツールを使いながら、応答速度はずっと早くなったからです」とHawkins氏は話します。「データ範囲がチームごとに区分され、そしてNew Relicは大規模システム向けに構築されているため、詳細なログをすばやく検索することができます」
また、Riot Gamesは、New Relic Metricsへの変更後に、メトリクスデータの規模に関する大幅な改善も実現しました。「いつでもアクセス、検索、利用ができ、システムに影響を及ぼすような拡張性の限界について心配しなくて良いメトリクスの格納庫が必要でした」とHawkins氏は話しています。
アラートをより意味のあるものに
「従来、アラートシステムを構築する際には、チームはどのメトリクスが重要かを考え、それぞれのデータセンターのベースラインを設定する必要があります」とホーキンス氏は言います。そのアラートを対応可能で意味のあるものとするためには、手動で多くの調整が必要になります。もしそれを間違えれば、まったく可視性が得られないか、チームにアラート疲れを引き起こします」。
New Relicのカスタムメトリックにより、Riot Gamesではベースライン中心のアラートを使用し、チームはサービスの健全性と不健全性の有意なバランスを確立できるようになりました。「New Relicは、これまでの実績にもとづいて、何が重要なのかの特定をサポートしてくれます」とHawkins氏は話します。
New Relicは、自社サービスのみならず、それが自社の所有・運営下にない他のサービスとどのように関わっているかの可視性も提供します。これは、解決すべき問題を解決するための、依存関係チェーンとそれに対する可視性についての話です。
可視性のその先へ
一元化されたプラットフォームを得たことで、Riot Gamesは、複数のマイクロサービスにわたるプレイヤー体験の点をつなげることができるようになりました。「New Relicは、自社サービスのみならず、それが自社の所有・運営下にない他のサービスとどのように関わっているかの可視性も提供します。これは、解決すべき問題を解決するための、依存関係チェーンとそれに対する可視性についての話です」とHawkins氏は言います。
New Relicのテクノロジーの恩恵を超えて、Hawkins氏がNew Relicと協働する隠れた価値だと考えるものがあります。「私たちをサポートしてくれるNew Relicの誰もが、親身になって私たちのフィードバックに耳を傾けてくれます。これは私たちが築き上げた素晴らしい関係性だと思っています。」と彼は言います。「会社として私たちに何が重要なのかを理解し、フィードバックを受け止め、それに結果で応えてくれる、前向きで積極的な姿勢があります。私たちはすでに、生活の質を向上させ、導入を進めるのに役立つ製品変更を実現させています」
New Relicにとって、それは私たちが築き上げた関係性でありRiot Gamesがすばらしいプレイヤー体験を提供するためのサポートは、決してゲームではないのです。
