ノー・ダウンタイム - 再来！

私は毎日ダウンタイムについて考えて、それが過ぎるのを待ち、結果を記録しています。

前回これを書いた時（その開発者ブログは読みましたか？すごく面白いですよ、保証します）、週末のトランキリティの自動リブートはおよそ4分20～40秒で、軽くお茶を飲むのに十分でした。1年半後に実施されることとなった今日の自動リブートは3分34秒で、少し急いで飲まなければなりませんでした（この開発者ブログを書きながら計りました）。2019年から導入した改善を考えれば、3分30～40秒の自動リブートのダウンタイムは今日ではかなり普通と言えるでしょう。

50～60秒の改善（2019年12月3日から2021年7月3日の間の22.5%の改善）に注目し、2026年12月19日のダウンタイム終了時間を

超科学的なグラフと共に予測することもできますが、実際はもっと複雑です。ダウンタイム中には3つの異なるアクティビティ（シャットダウン、データベースジョブ、スタートアップ）があり、それぞれにおよそ1分かかるため、約3分の（ソフトな）下限があります。根本的な変更がなされない限りこれは変わらず、そして最も根本的な変更は、やはりダウンタイムを全く発生させなくすることです。ダウンタイムが160～200秒を大幅に下回ることはないでしょう。代わりにダウンタイムの回数を減らしていき、全くなくすことが必要です。とはいえ、今回のブログでは、前回から改善されたダウンタイム削減の具体例をご紹介したいと思います。そして、次のノー・ダウンタイム実験は9月9日水曜日に予定されています。

この2回目のノー・ダウンタイム実験の目的は、少なくとも4つあります。

• 前回の実験で発見された問題の修正をライブプロダクション環境で検証
• 前回から他のコードや機能がデグレードしていないことを検証し、全般的にさらなる問題点を探す
• メモリー使用の観察
• 私たちのテクノロジープラットフォーム（これに関しては後でさらにご説明します）がダウンタイムの仮定をしていないことを検証

それで、前回はどんな発見があったのでしょうか？

まず最初に、1日のサイクルの開始を決めるイベントとしてのダウンタイムへの依存と、デイリースタートアップへの依存を発見しました。例えば、24時間以上のタイマーを完了しないストラクチャや、勢力戦争に参加していないコーポレーションなどです。私たちが見つけた問題や、皆さんから報告の上がった問題は、すべて解決しました。今回はこれらにさらなる検証をし（もちろんテストはされましたが、テスト環境はトランキリティのような規模ではありません）、このような問題をさらに発見する予定です。

また、時間の非同期（修正済みです）や、莫大なメモリーの使用（いくらか改善しました）も確認しました。

時間の非同期は既知の問題でしたが、前回は2日目の終了時にプレイヤーが気づいたかどうかを観察していました。目標とする時間差は最大±0.5秒ですが、新しいハードウェアでは、2019年の最初のノー・ダウンタイム実験時、セッション終了時の時間差は2.25秒で、

-推測通り - 2日目の終了時には4.5秒を観測しました。非同期が3秒を超えるとプレイヤーは気づき始めました。ほとんどが、モジュールのサイクル中、それぞれのソーラーシステムをホストしているクライアントとノードが大幅にずれたことによる、モジュールのラグや遅延への気づきでした。現在、時間の非同期は通常±1/100秒以内で、最大±0.5秒の範疇に十分収まっています。

トランキリティは常に大量のメモリを使用してきました。より良いパフォーマンスを実現するために、値を計算し直すのではなく、先に値を計算してデータを処理し、その結果を保存して後で参照することを常に選択してきました。例えば、2015年のBrain in a BoxとDogma Rewriteプロジェクトは、スキルとその効果（例：キャラクターの脳）の計算と保存、そして新しいソーラーシステムに入るたびに脳を再計算するのではなく、計算結果をソーラーシステム間で転送することが目的でした。さらに、星団ノードのメモリーは毎日リセットされるため、メモリーのクリーンアップはしたことがありません。これはデイリーリブートに依存しています（注意：データベースキャッシュメモリーやRedisキャッシュメモリーをクリアしているわけではありませんが、メインシミュレーションキャッシュメモリーは毎回のダウンタイムのリブートでクリアされます）。

トランキリティ星団で最もメモリー消費が激しいノードであるキャラクターサービスノードは、上記で述べた脳を（他のデータと共に）保存していますが、前回の2日目の最後にはメモリープレッシャーが75%で、これは動作許容範囲80%までギリギリでした。2019年の結果を見る限り、星団を「最初のノードでメモリを100%使用」モードで運用するならば、トランキリティを3日間（とおそらくさらに7時間）稼働させることは可能でしょう。2019年では、1日目のメモリープレッシャーは55%でしたが、最近では約35%のため、観測結果をリベースしたいのです。

ノー・ダウンタイムは長期目標であり、私たちのテクノロジーの進化はすべてこれに向かっています。私たちは数年前からEVEのマイクロサービスやメッセージバステクノロジープラットフォームに取り組んでおり、そのプラットフォームを多くの機能に使い始めました。今回は、ゲームの主要な星団でのノー・ダウンタイムにエコシステムがどう耐えるかを観察し、デイリーダウンタイムに関して仮定がされていないことを確認するのが目的です。

9月9日木曜日、2回目のノー・ダウンタイム実験の開始時にお会いしましょう。そして、前回と同じく、ビデオを近日公開します。このような大胆な行為には、たくさんの熱意と努力が必要です。