なぜCreative ModeではPingが倍増するのか：Multiplayer Game ServerにおけるPing Optimizationのためのアーキテクチャ修正

メインのバトルロイヤルにおけるMatchmakingキューは30ms未満の極めて低いPingで動作しているにもかかわらず、プレイヤーがユーザー生成のCreativeセッションに入った途端、レイテンシが60ms以上に倍増してしまうことがあります。この「Creative Modeのレイテンシペナルティ」は、サンドボックスゲームをリリースするスタジオにとって悪名高い課題ですが、その本質はいまだ十分に理解されていません。これは、動的なServer Orchestration、動的なAsset Loading、および最適化されていないリージョン間のRoutingが直接的な原因となって発生します。これを解決するには、開発者は静的なMatchmakingアーキテクチャから、最新のMultiplayer Game ServerにおけるPing Optimization戦略へと移行する必要があります。

なぜCreative Modeでレイテンシペナルティが発生するのか

通常のMultiplayerマッチでは、Game Serverは事前にプレウォームされ、プライマリのハイクラスな地域データセンターにクラスター化されています。これらのサーバーは最適化された読み取り専用のゲームマップを実行するため、動的なActor初期化やAsset Replicationは最小限で済みます。Matchmakingアルゴリズムは同じ地域のプレイヤーをグループ化するまで待機し、選択されたサーバーがロビー内の全員に物理的に近い場所に配置されるようにします。

Creative Modeやサンドボックスモードはこのパラダイムを完全に破壊します。プレウォームされたサーバーを使用する代わりに、これらのモードではパーティーリーダーがセッションを開始した際、必要に応じてオンデマンドで専用のコンテナインスタンスをプロビジョニングします。これらのインスタンスは動的に起動されるため、Orchestratorはネットワークレイテンシよりもサーバーの可用性を優先せざるを得なくなります。

仮に最も近いプライマリデータセンターが容量の上限に達している場合、Orchestrationレイヤーはセッションをセカンダリのアベイラビリティゾーンや、より安価で遠く離れたリージョンにルーティングします。この動的なシフトにより、プレイヤーの接続パスに即座に20ms〜40msの物理的な光ファイバー伝送時間が追加されます。さらに、サンドボックス環境では、プレイヤーが数千もの動的オブジェクト、カスタムスクリプト、インタラクティブなデバイスを含むカスタムレベルを構築できます。これらのオブジェクトは膨大なReplicationオーバーヘッドを引き起こし、サーバーのメインスレッドを低速化させ、そのTick Rateを低下させます。

Tick Rateの低下が体感レイテンシに与える影響

サーバーのフレームレートが低下すると、ネットワークのReplicationループも同様に低速化します。サーバーが30HzのTick Rateをターゲットにしている場合、想定されるフレーム時間は33.3msです。もしクライアントが送信したパケットが、サーバーがTickの実行を開始した直後に到着した場合、そのパケットは次のTickが始まるまでネットワークバッファにとどまる必要があります。

最適化されていないサンドボックススクリプトによってサーバーのTick Rateが30Hzから15Hzに低下すると、フレーム時間は66.6msに膨れ上がります。この処理遅延により、クライアントのRound-Trip Time (RTT)に自動的に33.3msが上乗せされます。物理的な光ファイバーのレイテンシは変化していないにもかかわらず、クライアントのゲーム内ネットワークUIはこのローカルな処理遅延をネットワークのPingとして認識します。

さらに、ユーザー生成コンテンツ（UGC）の動的なストリーミングにより、サーバーは参加するプレイヤーに対して巨大なペイロードをシリアライズして送信することを余儀なくされます。このバースト的なネットワークトラフィックは、家庭用ルーターやネットワークインターフェースでバッファブロート（Buffer Bloat）を引き起こし、パケットのキューイングにつながります。パケットがキューで待機状態になると、レイテンシが急増し、パケットロスが増加します。

最適化されていないUGCスクリプトがCPUに過負荷をかけると、Tick Rateの低下はサーバーの完全なフリーズへと発展する可能性があります。高負荷時に深刻なレイテンシの急増が発生している場合は、当社のサーバークラッシュ修正プロトコルを参照して、Netcodeを安定させてください。

UGCロードにおけるMTUとパケットのフラグメンテーションの役割

プレイヤーがカスタムのサンドボックスマップにロードされるとき、サーバーは何百ものカスタムActorの状態をレプリケートしなければなりません。この状態同期は、標準のMaximum Transmission Unit (MTU)サイズである1500バイトを頻繁に超過します。UDPパケットがこの上限を超えると、ネットワークレイヤーはそれらを複数の小さなIPパケットに断片化（フラグメンテーション）する必要があります。

送信中にフラグメントが1つでも失われると、クライアントのネットワークスタックはUDPパケット全体を破棄します。これによりパケットの再送信が発生し、深刻なジッターやプレイヤーが体感するPingのスパイクを引き起こします。Creativeのマップは非常に動的な構成要素を含んでいるため、このフラグメンテーションは静的なバトルロイヤルセッションよりもはるかに頻繁に発生します。

これを緩和するために、開発者はActorデータをより高密度にパックするカスタムのシリアライズ技術を実装すべきです。Replicationペイロードを1200バイトのしきい値未満に維持することで、IPフラグメンテーションを完全に回避できます。このシンプルな変更により、ネットワークの伝送経路が安定し、接続品質が大幅に向上します。

動的サーバールーティングとコールドスタートの仕組み

標準的なIPルーティングは静的な経路設定に依存しており、これは固定されたサーバーロケーションに対しては効果的です。しかし、サーバーインスタンスが分散型クラウド上で動的に生成される場合、標準的なユニキャストIPルーティングでは最もレイテンシの低い経路を選択できません。Creativeセッションを開始するプレイヤーは、新しく作成されたコンテナノードにバインドされた動的なユニキャストIPを取得します。

このIPは一時的なものであるため、グローバルなAnycastルーティングを利用できません。その結果、プレイヤーのパケットはパブリックインターネットを経由し、最適化されていない複数のトランジットプロバイダやローカルなISPのルーティングホップを通過する必要があります。これは、Anycast対応のエッジプロキシを経由してプレイヤーをルーティングする、メインのMatchmakingキューとは対照的です。

これらのプロキシは、最も近いPoint of Presence (PoP)でクライアントの接続を終端し、専用のプライベートバックボーンを介してGame Serverにデータを直接トンネリングします。また、動的なプロビジョニングはコールドスタートを引き起こします。サーバーコンテナの起動に時間がかかりすぎると、プレイヤーが接続エラーに遭遇する可能性があります。これを修正するには、セッション起動時のタイムアウト解消方法のガイドで詳しく説明されているように、ドライバや接続のタイムアウト問題を診断する方法を理解する必要があります。

技術的ディープバイブ：ICMPネットワークレイテンシとゲームループRTTの測定

Multiplayer Game ServerにおけるPing Optimizationを正確に実装するには、物理的なネットワーク伝送レイテンシ（ICMP/UDPのPing）と、アプリケーションレベルのRound-Trip Time (RTT)を区別する必要があります。前者は、生のネットワークパケットがサーバーを往復する時間を測定します。後者には、サーバーのフレーム処理遅延、ネットワークのシリアライズ時間、およびクライアント側の補間レイテンシが含まれます。

クライアント側のPing表示における主な課題は、パケットの送信からその応答（ACK）を受信するまでの経過時間全体を測定してしまう点です。もしサーバーがGarbage Collectionや複雑な物理演算によってCPUのボトルネックに直面している場合、ACKの送信が遅れます。クライアントはこのローカルサーバーにおける遅延とルーティングの遅延を区別できないため、ネットワークのPingが実際よりも高く報告されるという誤検出が発生します。

ネットワークドライバレベルでPing測定を実行し、それをメインゲームスレッドのTick Rateと比較することで、開発者はこれらのボトルネックを特定できます。これにより、バックエンドのOrchestrationチームは、コードを最適化すべきか、それともネットワークのルーティング経路を変更すべきかを判断できます。では、このモニタリングエージェントの実装方法を見ていきましょう。

以下のUnreal Engine互換のC++クラスは、生のネットワークPingを追跡し、それをゲームループの処理オーバーヘッドから分離する方法を示しています。この差分を計算することで、プレイヤーの高Pingの原因がネットワークルーティングの悪さにあるのか、それともサーバーのフレームレート低下にあるのかを特定できます。

// PingMonitor.h
#pragma once

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "PingMonitor.generated.h"

USTRUCT(BlueprintType)
struct FNetworkQualityStats
{
    GENERATED_BODY()

    UPROPERTY(BlueprintReadOnly, Category = "Network Quality")
    float NetworkPingMS;

    UPROPERTY(BlueprintReadOnly, Category = "Network Quality")
    float FrameProcessingDelayMS;

    UPROPERTY(BlueprintReadOnly, Category = "Network Quality")
    float TotalEffectiveRTT;

    FNetworkQualityStats()
        : NetworkPingMS(0.0f)
        , FrameProcessingDelayMS(0.0f)
        , TotalEffectiveRTT(0.0f)
    {}
};

UCLASS()
class MULTIPLAYERGAME_API APingMonitor : public AActor
{
    GENERATED_BODY()

public:
    APingMonitor();

protected:
    virtual void BeginPlay() override;

public:
    virtual void Tick(float DeltaTime) override;

    UFUNCTION(BlueprintCallable, Category = "Network Quality")
    FNetworkQualityStats GetCurrentNetworkStats() const;

private:
    float LastPingTime;
    float HeartbeatInterval;
    float ServerTickRate;
    
    TMap<int32, double> SentHeartbeats;
    int32 HeartbeatSequenceId;
    FNetworkQualityStats CachedStats;

    void SendHeartbeat();
    void HandleHeartbeatAck(int32 SequenceId);
};

// PingMonitor.cpp
#include "PingMonitor.h"
#include "GameFramework/PlayerController.h"
#include "Engine/World.h"

APingMonitor::APingMonitor()
    : HeartbeatInterval(1.0f)
    , ServerTickRate(30.0f)
    , HeartbeatSequenceId(0)
{
    PrimaryActorTick.bCanEverTick = true;
    PrimaryActorTick.TickInterval = 0.1f;
}

void APingMonitor::BeginPlay()
{
    Super::BeginPlay();
    LastPingTime = GetWorld()->GetTimeSeconds();
}

void APingMonitor::Tick(float DeltaTime)
{
    Super::Tick(DeltaTime);

    float CurrentTime = GetWorld()->GetTimeSeconds();
    if (CurrentTime - LastPingTime >= HeartbeatInterval)
    {
        SendHeartbeat();
        LastPingTime = CurrentTime;
    }
}

void APingMonitor::SendHeartbeat()
{
    HeartbeatSequenceId++;
    double SendTimeStamp = FPlatformTime::Seconds();
    SentHeartbeats.Add(HeartbeatSequenceId, SendTimeStamp);
}

void APingMonitor::HandleHeartbeatAck(int32 SequenceId)
{
    if (SentHeartbeats.Contains(SequenceId))
    {
        double SendTime = SentHeartbeats[SequenceId];
        double ReceiveTime = FPlatformTime::Seconds();
        float RTT = static_cast<float>((ReceiveTime - SendTime) * 1000.0);

        float FrameTimeMS = GetWorld()->GetDeltaSeconds() * 1000.0f;
        float ExpectedTickTimeMS = 1000.0f / ServerTickRate;
        float ProcessingDelay = FMath::Max(0.0f, FrameTimeMS - ExpectedTickTimeMS);

        CachedStats.NetworkPingMS = RTT - ProcessingDelay;
        CachedStats.FrameProcessingDelayMS = ProcessingDelay;
        CachedStats.TotalEffectiveRTT = RTT;

        SentHeartbeats.Remove(SequenceId);

        UE_LOG(LogNet, Log, TEXT("RTT: %.2fms | NetPing: %.2fms | FrameDelay: %.2fms"),
            CachedStats.TotalEffectiveRTT, CachedStats.NetworkPingMS, CachedStats.FrameProcessingDelayMS);
    }
}

FNetworkQualityStats APingMonitor::GetCurrentNetworkStats() const
{
    return CachedStats;
}

このクラスは、サーバーTickの実際のDelta TimeとターゲットのTick Rateを比較することによって FrameProcessingDelayMS を計算します。処理遅延が大きい場合、開発者はネットワークプロバイダーを疑うのではなく、サーバー側のスクリプト実行を最適化すべきだと判断できます。テストサーバーでこのシステムを実行することにより、ネットワーク品質のメトリクスをリアルタイムで追跡できます。

低レイテンシな動的Orchestratorの構築

Creative Modeのレイテンシペナルティを手動で解決するには、サーバーのOrchestrationレイヤーを再設計する必要があります。一般的なアーキテクチャは、地理的に分散されたプレウォーム、Anycastを利用したエッジルーティング、および徹底したアセット削減の3つの柱に依存しています。

第一に、Kubernetes上のAgonesなどのツールを使用して、プレウォームオーケストレーターを実装します。コンテナをゼロから起動する代わりに、世界8〜12のグローバルリージョンにわたって、アイドル状態のウォームサーバーインスタンスの小規模なプールを維持します。Matchmakingシステムは常にプレイヤー密度を監視し、ピーク時にプレイヤーが遠方のリージョンにルーティングされるのを防ぐために、これらのプールを動的にスケールさせる必要があります。

第二に、Game Serverの前段にエッジプロキシのネットワークを配置します。これらのプロキシは、Anycast IPルーティングを使用して、最も近いネットワークエッジでクライアントのUDP接続を受け入れる必要があります。その後、プロキシは専用の低レイテンシプライベートバックボーン（AWS Global Acceleratorなど）を介して、実際のサーバーコンテナにゲームトラフィックをトンネリングします。これにより、オンデマンドのユニキャスト接続を悩ませる、最適化されていないパブリックなルーティング経路をバイパスできます。

第三に、サーバービルドを最適化します。高解像度のテクスチャ、オーディオファイル、スケルタルメッシュなど、不要なクライアント側アセットをDedicated Serverビルドからすべて削除します。これにより、コンテナイメージのサイズを数ギガバイトから200MB未満に削減し、コンテナのプル時間を短縮できます。これにより、プレウォームされた容量が枯渇した場合でも、コールドスタートを500ms未満で完了させることが可能になります。

horizOnによるエッジルーティングとホスティングの合理化

Anycastエッジルーティングを備えた地理的に分散されたオーケストレーターを構築・維持するには、専任 of インフラ運用チームと、数千ドルに及ぶクラウドインフラのオーバーヘッドが必要になります。これは複雑なエンジニアリング作業であり、ゲームプレイ開発に費やすべき貴重な時間を奪ってしまいます。ここで、インディーや中規模のスタジオ向けにターンキーソリューションを提供するのがhorizOnです。

カスタムのLoad Balancerを開発したり、マルチクラウドにまたがるKubernetesクラスターを管理したりする代わりに、サーバービルドをプラットフォームにデプロイするだけで済みます。horizOnの1秒未満のコンテナ起動時間と内蔵のエッジデータベースを活用することで、コールドスタートのタイムアウトやルーティングの非効率性を排除できます。これにより、プレイヤーは通常のMatchmakingロビーと同様の低レイテンシで、クリエイティブなサンドボックスセッションを楽しむことができます。

Multiplayer Game ServerのPing Optimizationにおける4つのベストプラクティス

クリエイティブなゲームモードにおいてレイテンシを低く、Tick Rateを安定させたい場合は、以下の4つの実証済みの戦略を導入してください。

1. Replication Interleavingの積極的な実装: コスメティックアイテムや遠方のサンドボックスの装飾品など、重要度の低いActorのアップデートをグループ化し、毎フレームではなく3〜4フレームごとにレプリケートします。これにより、ネットワークのペイロードサイズが削減され、クライアントのルーターでのバッファブロートを防ぎます。
2. UGCのTickバジェットの制限: ユーザー生成スクリプトに対して厳格な実行制限を課します。プレイヤーのカスタムアイランドにおけるスクリプトの実行時間が1フレームあたり5msを超える場合、優先度の低いスクリプトをスロットルまたは無効化し、サーバーのTick Rateが30Hzを下回らないように保護します。
3. エッジベースの接続ハンドシェイクの使用: プレイヤーをGame Serverにルーティングする前に、最も近いエッジPoPでプレイヤー認証とセッショントークンを検証します。これにより、悪意のある認証リクエストがサーバーのCPUサイクルを消費し、アクティブなプレイヤーのパケットキュー遅延を引き引起こすのを防ぎます。
4. Dynamic Tick-Rate Scalingの導入: クリエイティブサーバーがアイドル状態、またはプレイヤーが1人しかいない場合は、Tick Rateを10Hzに下げてCPUリソースを節約します。他のプレイヤーがセッションに参加した瞬間にTick Rateを動的に30Hzまたは60Hzにスケールアップし、アクティブなMultiplayerゲームプレイ中に応答性の高い体験を確保します。

結論と次のステップ

Creative Modeにおけるレイテンシペナルティを解決するには、サーバーのフレーム時間を最適化して処理遅延を排除することと、パブリックインターネットではなく専用のネットワークバックボーンを介してトラフィックをルーティングすることの、二角的なアプローチが必要です。

Multiplayerインフラを最適化する準備はできましたか？ 次のビルドをhorizOnにデプロイして、自動化されたエッジルーティングと、グローバルに分散された低レイテンシのGame Serverを利用しましょう。あるいは、APIドキュメントを参照して、エッジネットワークデータベースをBackendアーキテクチャに統合する方法についての詳細を確認してください。

---

Source: Higher ping especially in creative