King of Glory の開発における同時実行性の問題の分析

この記事では、Honor of Kings の開発における同時実行性の問題についての非常に興味深いトピックを紹介します。このような問題を解決するためのアイデアを提供できることを願っています。Honor of Kings の開発における同時実行性の問題の分析について一緒に学びましょう。キングス。

「Honor of Kings」は、膨大なユーザーベースを持ち、高い更新頻度を維持している国家レベルのモバイルゲームです。このビジネス シナリオでは、バーストが非常に頻繁になっていますが、ビジネス経験が重要であり、CDN の使用が不可欠です。同様に、ニュース速報ビデオ、大規模なライブ ブロードキャスト イベント、人気の映画やテレビ シリーズのリリース、人気のゲームやその他のアプリケーションのリリースなど、帯域幅がバーストするシナリオがよくあります。同時に、ホーム帯域幅とモバイル ネットワークの急速なアップグレードにより、バースト帯域幅はますます大きくなり、Tb レベルや 10Tb に達することもあります。ビジネスの緊急事態を迅速かつ低コストで保護する方法は、CDN にとって大きな課題となっています。

中国で最も人気のあるモバイル ゲーム「Honor of Kings」には、数億人のユーザーと数千万人の毎日のアクティブ ユーザーがいます。ビジネスの緊急事態に迅速かつ低コストで対応するにはどうすればよいでしょうか?この記事では、この問題から始まり、問題に対応する解決策について説明し、その効果を要約します。

背景

2007 年、Tencent の自社構築 CDN が開始され、最初のビジネスである Tencent.com に接続されました。これまで、CDN 帯域幅は初期の数十 Gb から現在では数十 Tb まで増加していますが、単一サービスの帯域幅もますます大きくなり、ほとんどのサービスの一定帯域幅は数百 Gb であり、一部のバースト サービスも増えています。 10TBに達します。ネットワークの急速なアップグレード、モバイル ユーザーの爆発的な増加、オンデマンドやライブ ブロードキャストなどのビデオ サービスの台頭により、ビジネス バーストがますます頻繁になり、バースト帯域幅がますます高くなり、CDN の要件が高まっています。ますます高くなってきました。

Tencent のビジネスの急成長の恩恵を受けて、自社構築された CDN は、ゲームのダウンロード、ストリーミング ビデオのアクセラレーション、春節の赤い封筒など、Tencent の社内ビジネスを継続的にサポートしてきました。2014 年、Tencent は CDN の全機能を公開し、 Tencent Cloud CDN 製品は、社内のビジネスに加えて、Kuaishou On-Demand、Douyu Live などのサードパーティ顧客とも接続し始めています。上記のサービスはすべて、緊急事態を想定しており、コスト要件が厳しいです。Tencent CDN は、ビジネスの緊急事態を低コストで実現する方法について豊富な経験を蓄積しています。次に、課題と問題点、解決策と効果を分析します。

1. 課題と問題点

以下では、事業の特徴から始まり、現在の課題と問題点を分析します。

1. ビジネスの特徴と課題

CDN の多様なシナリオには、突発的なビジネスに対する課題がたくさんあります。バースト サービスは、大容量、多様なシナリオ、および不規則性を特徴としています。

a) 大容量: ほとんどのバースト サービス帯域幅は Tb を超え、一部は 10T に達することもあります

b) 多様なシナリオ: オンデマンドでの話題のドラマやニュース速報、ゲームのライブ ブロードキャスト。 NBA/ワールドカップなどのスポーツライブブロードキャスト、コンサートなどのバラエティ番組、アプリケーションダウンロードにおけるHonor of Kingsなどのゲームダウンロード、静的Webページアクセラレーションにおけるeコマースプロモーションなど。不定期: 突発的なイベントが発生する場合があります。イベントが始まろうとしているか、ニュース速報など、すでに始まっているまではわかりません。

ボリュームが大きく、より多くのリソースを準備する必要があります。シナリオは多様であり、さまざまなリソース要件を満たす必要があるため、拡張効率に高い要件が課されます。

2. 現在の問題

突然のビジネスニーズに対応するためだけに大量のリソースを予約すると、コストがかかりすぎ、リソースの膨大な無駄が発生します。したがって、ビジネスの緊急事態に対処するためにリソースは通常再利用されます。ただし、リソースを直接再利用するには次の 2 つの問題があります:

a) 再利用できるのは一部のリソースだけです: CDN ビジネスは、一般にビジネス タイプに応じてリソースの要件が異なるため、その主な理由は次のとおりです。オンデマンド サービスなど、より多くのストレージが必要です。より多くの https リクエストを伴う静的ページ クラスには、より多くの CPU リソースが必要です。この制限により、リソースが完全に活用されなくなり、リソースの準備がより困難になります。たとえば、ビデオ バーストでは主にビデオ バッファが使用されますが、ダウンロード バッファと Web ページ バッファは直接使用できないため、バッファのサイズが制限されます。同じ種類のリソースを再利用する場合でも、複数の経営リソースを調整する必要があるため、準備期間は通常 2 日を超え、一時的な緊急事態には対応できません

b) コストを削減できない: さらに、ゲームアプリケーションのダウンロードなどの突発的なサービスの場合、帯域幅のピーク時間帯は朝と昼です。このプラットフォームのリソースのみを使用すると、決済帯域幅が大幅に増加し、コストが増加します。他のサービスのオフピーク時間帯の特性を利用して、決済帯域幅を削減することはできません。

2. ソリューション

Tencent Cloud CDN は、仮想化を通じて既存のリソースを再利用して、すべてのサービスに共通のバースト プールを構築し、すべてのプラットフォームでバッファを共有します。 バースト プール内のデバイスは Docker 仮想マシンであり、各仮想マシンの仕様は異なり、ビジネスで必要な限りオンデマンドで使用できます。バースト プールの帯域幅予約は 10Tb に達し、基本的にすべてのビジネス バースト ニーズを満たすことができます。ビジネスで突然の需要が発生した場合でも、自動リスト インターフェイスを使用すると、10 TB のバースト プールを 10 分で拡張できます。

バーストプールシステムアーキテクチャ

a) バーストプール: 各プラットフォームの物理マシンの上位層で、Docker仮想マシンで構成されるリソースプールがCPU/メモリ/ディスクなどの使用を制限し、システムへの損傷を防ぎます。物理的なマシンの影響。元のビジネスは引き続き物​​理マシンにデプロイされているため、調整する必要はありません。

b) 自動化された導入および監視システム: 需要を自動的に予測し、実際のビジネス ニーズに基づいて容量を拡張できます。突然のニーズにも 10 分以内に拡張できます。オンデマンド/ダウンロード サービスの場合、ホット ファイルは自動的に配布され、ソースへの戻り帯域幅が削減されます。

c) スケジュール システム: 突然の用事が大量に発生するため、直通列車はドメイン名スケジュール システムよりも有利です。直通列車のスケジュール設定はより柔軟で、分単位のレベルまで迅速に反映されます。

仮想マシンと物理マシンはレポートエージェントとともに展開され、ビジネス情報とサーバー負荷が毎分監視シス​​テムにレポートされます。監視システムは過去の帯域幅に基づいて値を予測し、それを現在の帯域幅と比較します。現在の帯域幅が予測値の 50% を超える場合、バーストが発生していると見なされます。帯域幅の増加の割合に応じて、システムはバースト プールからの対応するデータを使用して機器を自動的に拡張します。事前に準備された予期せぬアクティビティに備えて、運用保守が帯域幅需要を指定すると、システムが自動的に機器需要を計算して容量を拡張します。

分単位で報告されるサーバー負荷情報は、監視システムがスケジュールを決定するための基礎を提供します。システムは、コンピュータ ルームの残りの帯域幅、サーバーの帯域幅、CPU、IO などの包括的な情報に基づいて、スルー トレインから仮想マシンを有効にする必要があるか無効にする必要があるかを判断します。アクセスするとき、ユーザーはまず急行列車配車システムを要求します。急行列車はスケジュール ポリシーに従って 302 アドレスを返します。302 アドレスは実際の CDN リソース アドレスです。ユーザーは 302 アドレスにジャンプし、実際のコンテンツを取得します。

2. 技術的な最適化

仮想化テクノロジーを使用してリソースを再利用するための重要な前提条件は、既存のビジネスに影響を与えないことです。これには、CPU/ディスクや帯域幅の使用状況などのリソースを十分に分離する必要があります。以下に実装プロセスにおけるいくつかの問題と解決策を示します:

● 単一マシンの負荷を正確に制御: 過剰な負荷はサービスの品質に影響を与えるため、単一マシンの負荷は正確に制御される必要があります。

解決策:

a) クォータ システム: 特急列車にはクォータ システムがあり、各仮想マシンが使用できるリソース (CPU/IO や帯域幅など) が制限されます。監視システムで報告される情報をクォータ システムと組み合わせることで、サーバーの負荷を分単位で指定された範囲に確実に制限できます。

b) 一部のリクエストは 302 を返します。CPU/帯域幅/IO などを制限した後、アプリケーションはホスト マシンの現在の負荷に基づいてリクエストをリアルタイムで処理するかどうかを決定できます。負荷が制限内であれば直接処理され、負荷が制限を超えた場合には 302 が返されるため、ユーザーは通過列車の配車アドレスにジャンプできます。これにより、サービスに影響を与えることなく負荷を正確に制御できます。可能な限りの品質。プログラム レベルでの負荷のリアルタイム制御は、クォータ システムを効果的に補完します。

c) ネットワーク カード フロー制御: 極端な場合、ビジネス帯域幅が設定されたしきい値を超えると、仮想ネットワーク カードはマザー マシンへの影響を避けるために積極的にパケットをドロップします。

● ディスク サイズの制限: Docker は、ext3/ext4 ファイル システムのファイル/ディレクトリ レベルでディスク サイズを制限できません。

解決策:

Tencent Cloud CDN ビジネスは基本的に ext3/ext4 ファイル システムを使用するため、この場合 Docker はユーザーまたはユーザー グループに基づいてディスクを制限することしかできませんが、既存のネットワーク サービスはルート環境に直接存在します。以下を使用します。ここでは、ループ デバイスを使用してディスク サイズ制限の問題を解決します。仮想マシンのバースト サービスは、ループ デバイスにマウントされたディレクトリを使用します。これにより、ディスク サイズが間接的に制限され、過剰なディスクの使用が他のサービスに影響を与えるのを防ぐことができます。

● CPU バインド: デフォルトでは、すべての CPU がバインドされます。一部の単一 CPU の負荷が高くなると、マザー マシンのビジネスに影響します。

解決策:

頻繁な調整やグリッチデータの影響を避けるために、システムの単一 CPU 負荷を 1 分ごとに収集します。平均値は 15 分です。最後に、負荷の低いいくつかのコアが選択され、構成ファイル cpuset.cpus を通じて動的にバインドされ、ホスト マシンのビジネスに対する仮想マシンの影響を最小限に抑え、リソースを最大限に活用します。

バースト プールがオンラインになった後、キング オブ グローリーのダウンロード、NBA ライブ ブロードキャスト、KPL/LPL ゲーム ライブ ブロードキャストなど、多くの大規模なバースト イベントを効率的にサポートし、2,000 万元のコストを節約しました。バッファを共有することにより、バースト プールを構築すると、バースト機能が大幅に向上し、コストが削減されます。

概要

Tencent Cloud CDN は、Docker テクノロジーを使用してリソースを再利用し、Tb レベルのバースト プールを構築します。ライブ ブロードキャスト、オンデマンド、静的などのさまざまなビジネス バーストをサポートし、ビジネス バーストのニーズを自動的に検出して対応します。 10 分以内にリソース拡張が完了し、迅速なリリースと低コストが特徴です。リソースの再利用により、リソースの使用率が向上し、サービスに巨大なバースト プールが提供されます。ただし、これには、サーバーのリアルタイム監視とタイムリーなスケジューリングが必要であることに注意してください。また、さまざまなサービスのチューニングを容易にするためのコンテナ分離に基づくカーネル パラメータなど、改善の余地がある領域もいくつかあります。また、一部のビジネス クライアントは 302 ジャンプをサポートしておらず、スケジューリング システムはドメイン名スケジューリングをサポートする必要があります。

関連する推奨事項:

Web 開発における高同時実行の問題の解決

高同時実行下での PHP と Redis を使用したスナップアップおよびフラッシュ セール関数の例の詳細な説明

PHP 読み取りのための高同時実行ソリューションの概要-書き込みファイルの競合

以上がKing of Glory の開発における同時実行性の問題の分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。