クエーサーのご紹介
2021年9月14日(木)は、EVE Online にとって1つの時代の終わりを意味していただけでなく、大きなチャンスに手を伸ばすことができるようになった重要なターニングポイントでもありました。新規プレイヤー体験のリニューアルやスキルプランといった華々しいアップデートに隠れていますが、EVE Onlineが今後どうなっていくのかに関連する根本的な変更が行われていたのです。
前回ネットワーク層に根本的な変更を加えたのは、CCPがIOCPの実装系である『CarbonIO』を導入した2011年に遡ります。悪名高き後の時間拡張システムの土台となったのがこの変更です。CarbonIO上で起きている問題に関する考察は、『プロジェクト・サンギン』というタイトルの走り書きから始まりました。EVEの最適化は例外なく、Pythonのグローバルインタプリタロック (GIL) との慎重な調整に行き当たります。簡単に言うと、Pythonは一度に1つのことしかできないのです。EVEがStackless Pythonを採用したのも、StacklessIOに続いてCarbonIOを通じてIOCPを実装したのも、あるいは時間拡張システムに協調方式を使用したのも、すべてはニューエデンは生きているという感覚を維持するためのものです。もし何かしようと思いつく度に、GILのご機嫌伺いをする必要がなくなったらどうなるでしょうか?ハードウェア業界は、プロセッサー毎のクロック数ではなくコア数が急増していますが、その流れに乗ることができたらどんなに良いことでしょう。
この手のテーマに関して、プロジェクト・サンギンとは関係ない実験も数多く行われてきましたが、その中で最も知名度が高いのがEVE: Aether Warsです。その目的は、EVE Onlineの通信モデルではなく、シミュレーションモデルの抜本的変更でした。プロジェクト・サンギンは対照的に、EVEの難解な機能の数々を構成する、派手さに欠ける細かな要素をターゲットとしていました。ニューエデンがTo Doリストにある全ての項目の心配をする必要がある設計ではなかったら、同じ宙域にいる9,000人近いプレイヤーをよりスムーズにシミュレートすることができたでしょう。そこで、プロジェクト・サンギンは2つの結論にたどり着きました。すなわち、GILの回避とより多くのレーザーを処理できるような環境の整備です。
プロジェクト・サンギンの最初の成果が、2016年に行われたESIとEVE Portalの導入でした。これらのプロジェクトを通じて、EVE Onlineのサーバーアーキテクチャ内に新たな枠組みが形成されました。それがメッセージバスです。この新たな逃げ道も、やはりGILに関連したボトルネックに遭遇しましたが、中でも特に影響が深刻な部分が明らかとなりました。すなわち、メッセージルーティング、シリアル化、そして送信です。1,000隻の艦船の真っ只中で1隻の船がレーザーを発射すると、1,000個のメッセージが発生することになり、しかもそのメッセージは世界中に瞬時に送る必要があります。つまり、シミュレーションモデルはそのメッセージのコピーを1,000箇所の送信先にアドレス指定(メッセージルーティング)し、データをワイヤーフォーマットに変換(シリアル化)した上でそのデータをネットワークを通じて送る(送信)ことになります。CarbonIOは、GILによる制限を受けつつ、ほとんどのケースにおいてそういった個々の問題に対処できていました。CarbonIOは長きにわたってEVE Onlineに貢献してきましたが、インターネットの変化は目まぐるしく、2011年以降多くの変化がありました。
新たなエコシステムの中で様式は日々進化しており、このパラダイムシフトを活用する場合、さらに標準的なプロトコルが必要なのは明らかでした。gRPCの統合をすれば、プロトコルバッファー(gRPCのメッセージ規格)による超高速なシリアル化を、メッセージバスのメッセージルーティング能力に結びつけることができるようになります。依然として、送信のためにGILを使ってデータをスケジューリングする必要はあるものの、これにより別々のスレッドで高水準なバッファリングを行えるようになります。これは、中間点で行う必要があるメモリーコピーを除き、全ての送信、シリアル化、メッセージルーティングをGILに関係なく行えるようになることを意味します。これ以上ないほどの高速化と言えるでしょう。
![](http://images.contentful.com/7lhcm73ukv5p/2qUtR4Gaxi3tcX54Qk1rX9/20020463bd360d14f21828c840e8f0d0/Picture1.png)
もっとレーザーを!
ニューエデンに接続できるAPIは今後どうなるのでしょうか?ESIの構築が始まるのと同時にKubernetesなどのよりクラウドネイティブな技術が採用されるようになると、その情報を要約するためにシンプルな並行プリミティブが必要になり、Goへの移行が一層進みました。こういった技術が独自のエコシステムに集積されるにつれて、ニューエデンと現代的な水準で連携する新たな能力を活用できる機能を構築する取り組みが始まりました。すでに多数の機能がリリースされています。
![](http://images.contentful.com/7lhcm73ukv5p/7ewb7Pq017sQzNbSOb5Qnx/aa87b30e9e43a78f8c6fdd6109ed2c31/Picture4.png)
![](http://images.ctfassets.net/7lhcm73ukv5p/5IMpLuJaOr66ddzrtrdloe/9d3f2595bf3e2ea697d8f56dbe2f74f6/Picture2.png)
![](http://images.ctfassets.net/7lhcm73ukv5p/5QeAp1aZkb6NCTKFS4V5UL/f37b83ccbedfef5ff8e731a90abf0ab2/Picture3.png)
![](http://images.ctfassets.net/7lhcm73ukv5p/5SU2jiB8eW8Ye7VKXWBF2b/e5a4a80a6e8a57051d64853bd7995bd9/Picture5.png)
第一弾はアクティビティトラッカーです。この機能はAPIに接続されており、ニューエデンの活動をモニタリングすることで皆さんの活躍を完ぺきに把握しています。各カプセラの活動を予測し、ニューエデンを一層楽しめる要素をご紹介するチャンス機能も取り組みの成果の1つです。メッセージバスは、アビサル プルービンググラウンドのリーダーボードにも使われています。私たちは、こういった機能を備えたメッセージングアーキテクチャを活用できるエコシステムを開発チームに提供することに尽力していますが、デスクトップクライアント上での機能には差があるのが現状です。
スキルプランのリリースまで、各機能はCarbonIOを通じてトランキリティにデータを『密輸』している状態でした。スキルプランの操作はgRPCを通じて通信しているだけでなく、トランキリティとそのデータベースと一切接点を持っていないため、『密輸』状態を脱しています。
![](http://images.contentful.com/7lhcm73ukv5p/5s2QiQ1wWJEu8kdq5UjAbB/f1907c444c6e0fa828aa2203f4ce5479/Picture6.png)
トランキリティとそのデータベースを経由しないことがなぜそんなに重要なのか。それを説明するには、まず失敗の話をする必要があります。私たちは新たな方法を模索する中で、ニューエデンのデータを取得するための様々な新技術や新ツールを発見しました。そんなコンセプトの1つが、新たに見つけたお気に入りツールであるHoneycomb.ioを使った分散型トレースです。(取り組みの詳細についてはこちらで視聴できます。)Honeycomb.ioなどの新ツールを使えば、スキルプランがリリースされた際に何が起きていたか手に取るように把握できました。
![](http://images.contentful.com/7lhcm73ukv5p/2RY4hg2TdNoaha3YgYBR9H/9cfa904e3f2ca6453888670f015c92cb/Picture7.png)
改善の余地があるものの、全般的にパフォーマンスは上々と言えるでしょう。
![](http://images.contentful.com/7lhcm73ukv5p/2WAW1vbv9KNbUr3nzrI5N7/9ca8d2e57851f85d5dcf9eb105300c6f/Picture8.png)
その後の翌日の朝、なぜか一時的にパフォーマンスが激しく悪化しました。
![](http://images.contentful.com/7lhcm73ukv5p/6k8aye5ZSJ58SHpJxZwTub/8dd8d35f3d1425185a74ca85a231d0e1/Picture9.png)
メッセージを1つ送るのに、まさかの500kミリ秒、つまり8分20秒もかかっていたのです。詳細を語るには、ファンフェスのコラボビールとホワイトボードが必要になります。この障害で重要なのは、トランキリティがダウンせず、数千人のプレイヤーが切断されることもなく、ほとんどのプレイヤーは影響を受けなかった(大多数のメッセージはグラフの最下部に集中しているのが見て取れます)という点です。これは、私たちが従来的な意味でのトランキリティとの通信を全く行っていないことが理由です。CarbonIOから従来のプロキシ、そこからサーバーノード、その次にデータベースという流れは過去の物となっています。代わりにトランキリティはより重要な処理に集中し、EVEのデスクトップクライアントはgRPCを通じ、スキルプランサービスが自前のデータベースで運用されている新たなエコシステムと通信しています。
![](http://images.contentful.com/7lhcm73ukv5p/6dtEIV0AkbP3I6l1FhABMM/004f56990d9327b80a98cce6a1847cbf/Picture10.png)
覚えている方もいるかもしれませんが、私たちは先日、トランキリティのノーダウンタイム実験のために火山からエネルギーを吸い上げました。新しいエコシステムの非常に魅力的な特徴の1つが、ダウンタイムが不要という点です。スキルプランは、トランキリティをダウンさせることなく復旧できました。サーバーだけでなく、クライアントにもパッチを配布する必要がありませんでした。
以上、簡単ではありますが、プロジェクト・サンギンがEVEの新たな技術基盤であるクエーサーになるまでの過程をご紹介しました。こうしてご紹介したのは、今が名前を付けるのに適切なタイミングだと考えたからです。名前を付けた方が分かりやすく話題にしやすいのに加えて、EVEの技術的進歩の近況と、それがEVEが前途有望な30周年目を迎えるための準備にどう関係してくるかを皆さんに知っていただくのがより簡単になります。また現在のクアドラントはGatewayという名前で、gRPCゲートウェイの直接利用の始まりを告げているように見えるので、そういう意味でも良いタイミングでした。
ちなみに、どちらも宇宙関連の言葉です。とても良い響きだと思っています。
次なる計画
多くの古いサービスを改修し、開発環境を整える取り組みは今後も継続して行いますが、これには2つの方向性があります。1つはスキルプラン以上の要素を扱えるようにするという点でクエーサーの基礎的な機能を充実させる方向性。もう1つは旧式化したシステムを標準的なレベルに引き上げ、開発ペースを早めるという方向性です。
一般的なカプセラへの影響としては、より多くの媒体で、より強力な機能を使う機会が増える、とお考え下さい。
クエーサーを通じてシミュレーションデータを公開するというアイデアも出ていますが、結論を出すには少々時間がかかるかもしれません。