MMORPGサーバーのメンテナンス

ほとんどのmmorpgゲームには、いくつかの定期的なサーバーメンテナンスがあり、一部は毎日、一部は週に1回行われているようです。彼らが実際にやらなければならないことは何ですか、なぜそれが必要ですか？

そのようなプロジェクトから始める場合、これを避けるために何ができますか？

私は、彼らが彼らのコードの最新バージョンを展開しているのではないかと疑っています。それは、彼らがアプリケーションを再起動することを必要とします その観点から見ると、これはStackOverflowの問題であり、ServerFaultの問題ではありません。

ホットパッチシステムを作成することは可能だと思いますが、必然的に非常に複雑になります。私の理解では、MMOサーバーの「アプリケーション」はいくつかの異なるコンポーネントで構成されています。

• ログインサーバー -認証を処理し、ゲームプレイサーバー間の「ハブ」として機能します。クライアントがゲーム内に入ると、クライアントはログインサーバーと対話しなくなります。このようなシステムでは、ゲームプレイを妨げることなくパッチを適用してログインサーバーを再起動できます（ただし、ユーザーがログインできない期間があります）。

• ゲームプレイサーバー -論理的に独立したユニット（「ワールド」など）にグループ化されたマシンのクラスター。各ゲームプレイクラスターは、ある種の内部通信プロトコルを使用して互いに状態を対応させると想定されています。おそらく、各クラスターに一度にパッチを適用する必要があります。これを行う1つの方法は、ウォームフェールオーバーにパッチを適用することです。次に、両方のことができるようにする必要があります

  1. クライアントにウォームフェールオーバーに接続し、古いクラスターから切断するように通知します。
  2. すべてのクライアントが転送している間、フェールオーバーと古いアプリケーションサーバーの間で状態を同期させます。

• データベースサーバー -RDBMSなどのある種の永続データストア。データストアに頻繁に変更を加えないことを願っています。おそらく、各ゲームプレイサーバー/クラスターには独立したデータストアがあります。ウォームフェールオーバーで同じトリックを使用できる可能性があります（ゲームプレイサーバーに切断し、古いデータベースとフェールオーバーデータベースが同期するのを待ってから、フェールオーバーに再接続するように指示します）。

上記のすべてのケースは、すでに複雑なシステムに信じられないほどの複雑さを追加し、コードの障害がデータの損失や破損を引き起こす可能性のある場所をもたらします。

別の解決策は、100％の稼働率を実現するように設計され、実行中のコードをホットパッチする機能が組み込まれている言語を使用することです。Erlangは良い選択です（ホットパッチの例）。Javaにも同様の機能があります。

このようなものを実際に実行した経験は他にありませんか？ええ

コードとシステムの両方をつなぐ理由はいくつかあります。まず、現在の「大きな」MMOエンジンのほとんどは数年前にプログラミングされており、それ以降のグラフィックスおよびテクノロジのアップグレードにもかかわらず、これらのシステムの多くは2000年頃に書かれた方法に依存します。たとえば、Eve-Onlineは依然として1つの巨大なMicrosoft SQL Serverインスタンスで実行されているため、ハードウェアをアップグレードすることで常にそれを引き出しようとしています。

WoWとEVEが開始されてからの改善の例は、GoogleのMapReduce（およびそのオープンソース実装であるHadoop）、非常に高速な肯定応答処理キューサービス（Amazon SQS）、およびその他の「クラウド」指向のテクノロジー。

私はEVEで最も経験が豊富です（私はBattleaxesの男よりもレーザーの男です）。これらの例のいくつかは、よりEVE指向です。

システムの理由に関する限り：

• 物理ノードは一貫して失敗します。ノードに障害が発生すると、通常、そのアクティビティは任意の数の手段を使用して他の場所に移行されます。ただし、ノードはできるだけ早くサービスに戻す必要があります。EVEの場合、スタックレス処理言語と仮想サーバーの両方を使用します。Blizzardのアーキテクチャがどのようなものかわかりません。
• データベースの一貫性をチェックし、ログをフラッシュし、インデックスとデータキャッシュを再構築する必要があります。これは、「ライブ」データベースインスタンスが1つしかないEVEのようなシステムでは特に重要です。
• オペレーティングシステムのパッチは、他の場所への移行作業が多すぎることなくノードを再起動できるときに適用する必要があります。移行では、オンライン処理専用のネットワークリソースを大量に使用します。
• RDBMSベースのMMOには、データのロックと参照整合性に関する大きな問題があります。ダウンタイムは、アクティビティログから古いロックと整合性の破損をクリーンアップするために使用されます。
• ほとんどのゲームは、米国東海岸と西海岸など、使用頻度の高い地域で静的または半静的な情報（以下の要約データのキャッシュを参照）のために地理的に配置されたデータキャッシュを実装しています。これらのキャッシュは、ダウンタイム中に手動で更新されます。

ソフトウェアの理由に関する限り：

• ゲームでは、操作時に多くのOLTP（オンライントランザクション処理）を使用します。これは、データベースに対する読み取り/書き込みの種類です。ただし、過去3年間の粉砕で特定の獣を何匹殺したかのような要約レポートが必要な場合があります。これは、巨大なデータセットの多くの行に基づいた概要情報を含むOLAPレポート（Online Analytical Processing）で処理するのが最適です。実際には、ゲームは、OLAPを使用してキャッシュを構築するシステムを実装して、読み取りが必要なクエリの数を制限します。つまり、特定の日付の時点で合計を構築し、質問をすると、行を読み取ります特定の日付以降の期間を要約するOLTPストアから。2つをマージすると、実際に自分の人生がどれほど価値のないものになっているかを定量化できます。
• 前述のホットパッチは、ソフトウェアの問題と見なされますが、ソフトウェア開発者はシステムの問題と見なされます。;）
• アイテムのストアを補充する-イブでは、小惑星帯は毎晩更新され、特定の複合体もリサイクルされます。これはオンラインである程度行うことができますが、一部のアルゴリズムは複雑すぎて、前日の経済活動を要約している間にデータベースを少しひざまずかせるため、オフラインモードで行う必要があります。

閉ループと開ループの両方で経済を運営することは、MMOオペレーターにとって1つの問題です-もし私を信じないなら、ゲーム経済について書かれた学術論文のいくつかと、Ultima Onlineのような古いゲームの研究のいくつかを読んでください比較的原始的な経済がありました。オープンループを補充し、不正行為やその他のマイナスの経済活動を特定するために必要な分析は、データのスナップショットを使用してオフラインで行う必要があります。これは、データベースが完全にロックされているときにのみ取得できます。

ご存知のように、イブのメンテナンスは、プライマリデータセンターがあるイギリスの正午に行われます。

Blizzard（あなたが質問を投稿しているのは火曜日の朝であることを考えると）がメンテナンスのために見積もる合計時間はクラスター全体の時間だと思います。すべてのサーバーが処理にかかる時間はかかりません。

個々のサーバーをより迅速に復旧させることは可能かもしれませんが、それは、スケジュールの早い段階でレルムが落ちたプレイヤーに対する不利な叫びを違法にするでしょう。そのため、すべての作業が完了するまで、すべてを停止します。数百のレルムで作業するため、おそらく多くの作業を並行して行いますが、オンラインに戻す前に最終チェックをシリアル化します。ハードウェアのアップグレードを実行している場合、これはおそらく多くのデータセンターでシリアル化されています。

メンテナンスを実行する理由については、一部はパフォーマンスの再起動にすぎない可能性があります。そのような再起動が必要なければ素晴らしいことですが、そうすることのコスト対そうしないことの影響は、ここで彼らの選択を指示するかもしれません。

プロセスをクラスター化してローリングメンテナンスを実行できない理由を見ると、WoWインフラストラクチャについてほとんど知らない人は、複数のマシンが各領域にサービスを提供することを示唆していますなど）、状態共有アクティブ-アクティブプロセスのセットアップを使用しません。ライブ状態の共有はなく、データベースを介した永続データのみが共有されます。

最終的に、大規模な加入者ベースにステートフルオンラインサービスを提供する仕組みは、Webサイトまたはその他の従来のインターネットベースのサービスについて話すときに支持するベストプラクティスのいくつかに挑戦します。

EvE Onlineの最近の長時間のダウンタイムの一部は、より高速なSANなどの新しいハードウェアのインストールに関するものでした。新しいドライブに新しいファイルグループを作成し、メインドライブを空にすることで、技術的に大量のデータを移動できますが、I / Oが一定であるためにパフォーマンスが低下する期間が長くなります。そこで、彼らは 1.1TBのデータベースを切り離し、一度に移動することを選択しました。

この質問に対する答えも、特定のアプリケーションに依存しています。たとえば、特定のスターシステムを処理するサーバーは、ゲームプレイを中断せずにホットスワップできないため、ダウンタイムを使用して、より強力なサーバーを潜在的なホットスポットに再割り当てします。さらに、スターシステムの所有権の計算（主権）が計算されます。これは数十の異なる変数に依存し、それらはすべてプレイヤーのアクションに応じて変化します。言うまでもなく、ライブで実行すると、過度のロックやその他の同時実行の問題が発生する可能性があります。しかし、それらに対処することは、stackoverflowに任せるのが最善です。

おそらく、DBスキーマの大きな変更など、クラスタリング/負荷分散を介して対処できない何か。

最近のトピックで、Linuxサーバーを再起動する頻度について、別の良い点が言及されました。これは、再起動時または（主要な）構成変更後にすべてが正しく起動することを確認します。

ハードウェアの単純なアップグレード（またはハードウェアの交換）も、MMORPGゲームによって「サーバーメンテナンス」として表示されます。とても些細なことですが、しばしばそれを忘れます。

ホットコードのアップグレードと配布をサポートするMMOアーキテクチャをErlangに実装しました。たとえば、ハードウェアのアップグレードが必要な場合、オブジェクトを（リアルタイムで）他のマシンに転送できる場合、1つの「GamePlayサーバー」を任意の数のマシンで実行できます。これにより、ダウンタイムなしでソフトウェアハードウェアをアップグレードできます。

私のサイトはhttp://www.next-gen.ccで確認できます。

また、メンテナンス時間枠により、ハードウェアの定期的な交換が可能になり、コンポーネントが故障しないことを保証できます。