こんにちは。
ご存知の方も多いかと思いますが、少し前に配信されたフォートナイト v32.00 リリースには安定性の問題や不具合があり、プレイヤーが UEFN と FNC のコンテンツにアクセスできなかったり、クリエイターが UEFN とクリエイターポータルを利用できなかったり、一部の機能で不具合があったりなど、重大な障害が発生しました。
32.10 でも、UEFN のコンテンツやツールが断続的にしか利用できないという状態が数時間続きました。
これらのリリースは私たちの水準を満たすものではなかったため、これらの問題を事前に見つけられなかった理由と、今後のプロセスの改善点について、開発チーム内で多くの議論が交わされました。
フォートナイトのエコシステムを急速に進化させながら、幅広い機能や体験の安定性と互換性を確保することは困難ではありますが、全力で取り組んでいく所存です。そのためには、過ちを認め、そこから学ばなければなりません。また、クリエイターの皆さんが最近経験した主な問題、その対応、実装予定の変更についても透明性を確保したいと考えています。
この理念のもと、v32 の最も深刻な問題を以下にまとめました。それぞれの概要には問題、原因、影響、およびそこから学んだことに基づき実装する変更を記載しています。
v32.00 と v32.10 の不具合は他にもありますが、問題の中でも、エコシステム全体に影響を及ぼし、Epic 内での重大インシデント対応プロセスの引き金となったものを記載しています。
問題：コンテンツサービスの悪化 (32.00 & 32.10)
コンテンツサービスは、バージョンや公開ステータスなどのメタデータを含む、FNC と UEFN で制作された全てのコンテンツを追跡する内部システムです。要するに、我々の"メタバースの索引"として機能するものであり、フォートナイトと UEFN の両方の機能にとって重要な役割を果たしています。
Epic で UEFN の利用が拡大するのに合わせ、コンテンツサービスへの依存度も高まっています。
アップデート v32.00 では、フォートナイトのクライアントとサーバーへの変更により、コンテンツサービスへのトラフィックが意図せず大幅に増加し、ある時点では通常の 10 倍の負荷がかかっていました。この急激な増加により、コンテンツサービスが負荷を処理するためにスケーリングしようとする際、エラーを発生させる問題が露呈し、その結果 UEFN と FNC の機能に関する複数の領域に影響が及びました。
サービスの再構成やスケールアップを試みましたが、失敗に終わり、クライアントやサーバーの動作をすぐに変更する方法はありませんでした。幸い、エコシステム セキュリティのチームがファイアウォールを調整し、トラフィックを管理可能なレベルまで減らすことができたので、サービスを復旧することができました。
32.10 にはクライアントとサーバーの過剰なトラフィックへの対応を盛り込みましたが、それでもリリース日に発生した自然なレベルのトラフィックにより、コンテンツサービスのパフォーマンスが再び悪化しました。今回はサービスは停止しなかったものの、クリエイター制作の島と UEFN の機能へのアクセスは、数時間にわたり不安定でした。また、この間にはフォートナイト リロードも利用できなくなっていました。
影響：11月2日の 32.00 リリース時、日本時間の午後3時から翌午前2時までの間、リロード、ジャムトラック、クリエイター制作の島など、一部のフォートナイトのコンテンツが利用できなくなっていました。
32.10 のリリース日である11月13日、クリエイター制作の島と UEFN の機能へのアクセスが、午後9時から翌午前3時までの間悪化し、島への参加成功率はおよそ 7 割に達しました。この間には、フォートナイト リロードも利用できなくなっていました。
変更点：このスケーリングの問題に対処するため、現在懸命に取り組んでおり、今年の残りの期間は問題なく利用できると考えております。
また、誤って引き起こされた問題を早期に発見するため、今後のリリースではリリース前のクライアントとサーバーのトラフィック分析を増やします。
問題：持続データの喪失 (32.00)
コンテンツサービスの機能が復旧してから間もなく、持続データを使用している何人かのクリエイターより、プレイヤーのインベントリから特定のタイプのアイテムが消えているという報告がありました。
調査の結果、フォートナイトの一部のコンテンツが今後の取り組みに向け、再編成されていたということが明らかになりました。この再編成により、ダイヤモンドなどのトラッキング対象のアイテムは新しいアセットパスを使うようになり、その結果インベントリにおいて数量がゼロの新しいアイテムとして表示されていました。Unreal Engine には移動したアセット (リダイレクタ) を取り扱うシステムがありますが、持続データのコードのバグにより、リダイレクトが適用されていませんでした。
この問題に対処するうえで、我々は 2 つの優先事項を設定しました。
- 問題を解決し、新規プレイヤーのデータ喪失を防ぐ。
- すでにこの問題の影響を受けているプレイヤーのインベントリを復元する。
最初のタスクでは、新しいサーバーの作成、テスト、および配備が必要でした。通常、これには最大で 24 時間かかりますが、さまざまな要因により、新しいサーバーは 3 日後の 11月5日(米国時間)まで配備されませんでした。主には、他の問題に対応する変更を盛り込みたいという理由でしたが、これほどの重大インシデントへの対応としては、まったく受け入れられない遅さであると認識しています。
2つ目のタスクでは、v32.00 リリース以降に島でプレイしていたプレイヤーのインベントリを復元するスクリプトを作成し、インベントリを修正する必要がありました。このような状況での復元は、島によって影響の度合いが異なるため、難しい選択でした。データを復元するか、新しいデータで続けるかは、影響と復元に要する時間によって決まります。
影響を受けたとの報告があったクリエイターには復元を提案し、日本時間の 11月7日午前4時にそれらの島のプレイヤーデータの復元を開始しました。復元作業は日本時間の 11月8日午前5時に完了しました。
変更点：アセットが削除されたときに自動で報告する機能があるため、例えば、クリエイター制作の島でアイテムが消えるなどということはありませんが、この自動化機能は、アセットの移動時には報告をしないようになっていました。機能を更新し、移動したアセットも報告されるようにする予定です。
さらに、インベントリに格納されているアイテムが、今後のフォートナイトのビルドにおいて読み込まれなかった場合に報告する自動化のオプションを検討していますが、この問題の解決は難しいため、時間を要します。
最後に、先ほども述べた通り、修正を実装したサーバーの配備にかかった時間は受け入れられるものありません。今後、このプロセスを改善していきます。
問題：クライアントの全般的な不安定化 (32.00)
全てのプラットフォームでクライアントのクラッシュが大幅に増加しているということが、すぐさま判明しました。
主な要因は、ミューテーターゾーン内での武器ダメージ無効化に関する不具合を修正するため、アップデート 32.00 で導入された変更でした。この変更により、2 つのスレッドが同時に配列にアクセスできるという競合状態が発生するようになっていたため、リスポーン時のタイミングとプレイヤーの行動によっては、クラッシュが発生する場合がありました。
このクラッシュはクライアント上で発生しており、サーバーの調整では解決できなかったため、全プラットフォームでクライアントパッチを配信する必要がありました。クライアントパッチの作成にはより時間がかかり、一部のプラットフォームでは認証が必要なため、アップデートは米国時間の 11月16日(水)まで提供できませんでした。
影響：アップデート v32.00 で、全プラットフォームのクライアントが不安定になりました。
変更点：フォートナイトの各リリースの開発時、我々は既知のクラッシュを追跡し、対処しています。長時間テストを行いましたが、我々の調査ではこのクラッシュを確認することができませんでした。原因を突き止めた後も、開発チーム内でクラッシュを再現することはできませんでした。
この「大規模での問題」という課題は新しいものではありません。例えば、0.01% の確率で起こるクラッシュが開発中に発生しない可能性は十分あります。ですが毎日 100 万人がプレイする場合、1 日あたり 10,000 回のクラッシュが発生する可能性があります。
これに対処するため、テスト中の「サニタイゼーション」ビルドの使用を増やす予定です。このビルドでは、メモリアクセスに関する問題の検出が強化されており、すぐにクラッシュを引き起こさない場合でも検出するようになっています。この方法で直近の問題が解決できたかどうかは断言できませんが、今後同様の問題が発生した場合には、高確率で防ぐことができます。
問題：プロジェクトの読み込み時にエディタがクラッシュする (32.00)
アップデート 32.00 のリリース後間もなく、プロジェクトを開こうとするとエディタがクラッシュするという報告がクリエイターの皆さんから届きました。当初、このクラッシュは当時発生していたコンテンツサービスの悪化に関連しているのではないかと考えていましたが、すぐに別の問題であるということが判明しました。
この問題はグラフィックドライバー内で発生するクラッシュが関連しており、こういった状況では原因に関する情報が限られていることが多いため、問題の原因究明は困難でした。原因の特定後、一時的な回避策として UEFN を Direct3D 11 に切り替えるよう勧告しました。
原因の根を辿っていったところ、最終的には右下の「トースト」ポップアップに大量の起動警告が表示されているプロジェクトに問題があることが判明しました。各警告メッセージのレンダリングに過剰なメモリが使われており、警告の数が多すぎるとメモリ使用量が上限を超え、クラッシュを引き起こしていました。
幸い、UEFN とフォートナイトは別々に更新できるため、翌日にはアップデートをプッシュすることができました。
口惜しいことに、これはチーム内の UEFN ユーザーが 32.00 の初期バージョンで一度経験した不具合だったのですが、開発者が再現できなかったため、問題の対処は打ち切られていました。
影響：リリース後、最初の 8 時間で UEFN において数百件のクラッシュが発生しました。
変更点：事後分析の結果、我々のワークステーションは一般的な消費者向け機器よりも、特にビデオメモリの点で、スペックが大幅に高いという点に気付きました。
これまでの互換性テストは"新しいユーザーエクスペリエンス"に重点を置いており、大規模プロジェクトで UEFN を推進することには重点を置いていませんでした。今後は、潜在的な問題をより確実に特定するため、大規模な社内プロジェクトでは、最小スペックおよび消費者向けスペックの機器でのテストを増やす予定です。
この詳細な解説で、32.00 のリリース時に発生した問題の原因について、より深く理解していただければ幸いです。プレイヤーの心を躍らせる体験を制作し、サポートするための安定した環境をクリエイターの皆さんに提供することは、我々にとって非常に重要なことです。
我々は、システムとプロセスの改善を続け、お客様が経験する問題に耳を傾け、UEFN と FNC をあらゆる人にとってより良いものにするため、我々がどんなことに取り組んでいるのかを定期的にお伝えすることに尽力してまいります。
よろしくお願いいたします。
Andrew