Dewu クラウドネイティブコンテナテクノロジーの調査と実装

1. はじめに

インターネット業界の新星として、Douyin App は急速な事業発展の中でインフラ規模が拡大し続けており、効率性とコストへの重点も高まっています。クラウド ネイティブ テクノロジーにおける当社の進歩は図に示されています。全体的にペースは比較的速いです。

写真

2021年8月より、リソースの利用率向上とリソース配信効率の向上を目標に、コストをコントロールしながらクラウドネイティブ技術をベースとしたサービスシステム全体の高可用性、可観測性、高い運用保守効率の構築に着手しました。コンテナ化のプロセスでは、既存の R&D プロセスを変更せずに既存のサービスをコンテナに展開および管理する方法など、多くの課題に直面しました。コンテナ化後の効率的な運用と保守を実現する方法。さまざまなビジネスシナリオに合わせて異なるコンテナ化ソリューションを提供する方法など。さらに、技術的な手段を通じて継続的なコスト最適化を実現することが私たちの長期的な目標です。ポートレートシステム、コロケーションソリューション、スケジュール最適化などのソリューションを次々と構築し、実装してきました。この記事では、クラウドネイティブ コンテナ テクノロジーの実装を促進する上で Dewu が実践している関連ソリューションと実践を要約して整理します。ぜひ読んでコミュニケーションしてください。

2. クラウドネイティブアプリケーション管理

クラウドネイティブアプリケーション管理

コンテナとECSのリソース形式が異なるため、管理プロセスにも違いが生じます。ただし、コンテナ化によってもたらされるユーザーエクスペリエンスの違いを最小限に抑えるために、業界のコンテナアプリケーションOAMモデルの設計パターンを参照し、コンテナの関連概念を平等に保護および解釈します。たとえば、「アプリケーション クラスター」の概念は、CloneSet ワークロード (Kruise が提供する Kubernetes 拡張ワークロード) を表します。単一の Pod がアプリケーション クラスターのインスタンスとなることに同意します。 「アプリケーション ルーティング/ドメイン名構成」の概念は、Ingress/Service の設定を表します。

アプリケーション クラスターの構築 (つまり、Kubernetes ワークロード オブジェクトの構築方法) では、「構成/機能の階層化」ソリューションを設計しました。アプリケーション クラスターが属するアプリケーション、環境グループ、および環境構成を重ね合わせた後、Helm ツールを使用して Kubernetes リソース オブジェクトをレンダリングおよび生成し、コンテナー プラットフォームに送信します。

写真

CI プロセスと CD プロセスの両方で、この構成/機能の階層化アプローチが使用されます。一方では、アプリケーションが依存するミドルウェア情報の管理問題（対応するプロバイダーによって均一に管理される）を解決できます。一方、この管理アプローチでは、ミドルウェア コンポーネント/サービスをさまざまな次元で変更できるため、全体的な構成変更によってもたらされるリスクが軽減されます。

アプリケーション クラスター インスタンス内での「コラボレーター」の役割を果たすだけでなく、ECS 形式で異なるユーザーのログイン権限に対応するために Sidecar コンテナーに基づく権限管理も実行しており、一石二鳥と言えます。もちろん、コンテナ シナリオでは、異なるユーザーを定義し、異なるロールを割り当てることができますが、これは基本イメージのメンテナンスに大きく依存します。

写真

マルチクラスタ管理ソリューション

クラウド ネイティブ シナリオのソリューションは、本質的にアプリケーション クラスターに対して高い可用性を備えています。たとえば、コンテナ オーケストレーション エンジン Kubernetes は、Pod インスタンスのトポロジ分散設定、アベイラビリティ ゾーン設定、レプリカ数設定、サービス負荷分散設計をサポートしており、これらはすべてアプリケーション クラスターの高可用性を確保できます。では、単一の Kubernetes クラスターが利用できなくなった場合はどうなるのでしょうか。また、どうすれば解決できるのでしょうか。マルチクラスター管理ソリューションは、Kubernetes の可用性の問題を解決するための当社のアプローチです。

Kubernetes コントロール プレーンが利用できない場合、アプリケーションのリリースに影響が及び、さらに深刻な場合には、コンテナ サービスの可用性にも影響が及びます。したがって、Kubernetes の可用性を確保するためには、一方では各 Kubernetes コンポーネントの堅牢性を確保する必要があり、他方では、クラスターのサイズが大きすぎることによるシステムリスクの増大を回避するために、単一の Kubernetes クラスターのサイズを適切に制御する必要があります。私たちの解決策は、「すべての卵を 1 つのバスケットに入れるのではなく」、複数の Kubernetes をフェデレーション方式で管理し、ビジネスを異なる Kubernetes クラスターに分散することです。

フェデレーションのアイデアはKubernetesの誕生直後から議論され、徐々に設計・実装されていきました。初期のコミュニティの KubeFate V1.0 から V2.0、そしてエンタープライズ オープン ソースの Karmada と KubeAdmiral へと徐々に成熟し、実際に本番環境のシナリオに適用されました。では、クラスター フェデレーションがない場合、複数の Kubernetes クラスターを管理することはできないのでしょうか?もちろん違います。コンテナ管理および制御プラットフォームは実際にこれを実行できます。数年前は私もこれに同意していましたが、今では完全に考えが変わりました。実際の運用実装プロセスでは、if...else/switch 方式や管理における構成方式と比較して、CRD ベースの方式の方が効率的で、複数のクラスターを管理するロジックが明確であることがわかりました。

写真

写真

フェデレーションの概念を使用して複数の Kubernetes クラスターを管理する際に、Dewu は Huawei のオープンソース Karmada ソリューションを参照し、それに基づいてカスタマイズされた開発を行いました。コンテナ管理および制御プラットフォームは、アプリケーション クラスターの元の特性と構成の管理、CICD プロセスの管理、ホスト Kubernetes クラスターへのコンテナ オブジェクト管理要求の開始を担当します。ホスト Kubernetes クラスターは、PropagationPolicies を通じてメンバー Kubernetes クラスターにワークロードを分散する方法を管理し、OverridePolicies を通じて差別化された構成を管理します。単一の Kubernetes クラスターでは、バッチ リリースを使用してアプリケーション クラスターのリリースを管理しました。フェデレーション管理を導入した後、バッチ リリース ロジックをコンテナ管理レイヤーからホスト Kubernetes クラスターに移動しました。 Kubernetes Service を通じて呼び出される既存のサービスとの互換性を確保するために、メンバー Kubernetes クラスターでカスタム MCS コントローラーを使用してクラスター間でサービス/エンドポイント オブジェクトを管理し、ホスト Kubernetes レイヤーで MCS 検証機能を使用して二重検証を実行し、クラスター間でのサービスの一貫性を確保します。

3. コンテナスケジューリングの最適化とコロケーション

アプリケーションプロファイル

アプリケーション クラスター インスタンスを展開する場合、アプリケーション サービス開発者は通常、ビジネス トラフィックを伝送するときにアプリケーション クラスター自体が消費するよりも多くのリソースを申請します。これは理解できます (システムのリソース使用率が安全なレベルにあることを確認し、過負荷によってシステムが停止するのを防ぐためです)。ただし、アプリケーション クラスターのリソース使用量の適切な設定は開発者の経験に依存するため、この「程度」に対する見方は開発者によって異なり、より主観的になります。

上記の問題を解決するために、業界では通常、アプリケーション クラスターの過去のリソース使用率データを分析して、ビジネス トラフィック下でのアプリケーション クラスターの実際のリソース使用率曲線を特徴付けます。これはアプリケーションプロファイリングです。次の図は、私たちが構築したポートレート システムのアーキテクチャを示しています。このポートレート システムは、アプリケーションのポートレート分析だけでなく、ホストと Kubernetes クラスターのポートレート分析も担当し、コンテナ プラットフォーム全体のリソース管理をガイドするために使用されます。

写真

コンテナ監視データは、Prometheus ソリューションを通じて収集および管理されます。自社開発の KubeRM サービスでは、これをデータソースとして利用し、アプリケーション ポートレート、ホスト マシン ポートレート、Kubernetes クラスター ポートレート (リソース プール ポートレート) を定期的に計算して出力します。コンテナ プラットフォームにオンライン サービスを展開する場合、ポートレート値を参照して、アプリケーション クラスターのリソース仕様を構成できます。ここでのポートレート値はポッドのリクエスト値を指し、計算式は次のとおりです。

ポッドリクエスト = 指標の定期利用率 / 安全レベル

数式中の「指標周期利用率」とは、実際の業務トラフィックにおけるリソース指標（CPU/メモリ/GPUビデオメモリ）の周期パターンを指し、ポートレートシステムによって統計的手段、AIモデルなどの方法を通じて計算および分析されます。私たちは、次の 4 つの戦略を通じてポートレートの価値を実現します。

• P3/P4 レベルのサービスの場合、プロファイル値はサービスがデプロイされたときにデフォルトで有効になります。
• P3/P4 レベルではないサービスの場合、プロファイル値がユーザーに推奨され、ユーザーは展開時にプロファイルを使用するかどうかを決定します。
• 各リソース プールに異なる有効性ポリシーを設定します (デフォルトで有効、またはユーザーが決定)。
• GPU メモリ ポートレートはデフォルトでは有効になっていませんが、ユーザーが決定することをお勧めします。

ポートレートが効果的かどうかの判断はユーザー次第ですが、どうすればユーザーが効果を感じやすくなるでしょうか?当社では差別化された課金戦略を採用しています。有効なポートレートを持つアプリケーション クラスター インスタンスは、Pod 構成のリクエスト値に応じて課金され、有効なポートレートを持たないアプリケーション クラスター インスタンスは、Pod 構成の制限値に応じて課金されます。ユーザーは、サービスの実際の状況に基づいて効果的なポートレートを選択し、コストを削減できます。プラットフォームは、ポートレートのおかげで、より多くの他のシナリオで使用するためのディスパッチ可能なリソースも取得します。

さらに、ポートレートシステムは KubeAutoScale 自動スケーラーにも接続されています。ビジネスのオフピーク期間中、自動スケーラーは、いくつかのシナリオでオンライン サービスのレプリカをスケールダウンするようにガイドされ、他のシナリオ (コロケーション タスク シナリオなど) で使用するためにより多くのリソースを解放します。これについては次の章で詳しく紹介します。

リソースの優先権

コンテナ クラスタ全体のリソース冗長性が十分でない場合、「クラスタ レベルでの合計リソースは十分であるにもかかわらず、業務 Pod をスケジュールできない」という問題が発生し、業務リリースの効率とエクスペリエンスに影響を及ぼします。

1. 大規模な業務クラスタがローリングアップデートを実行している場合、クラスタ内のコンテナインスタンスが頻繁に変更されると、解放された古いインスタンスが小規模なコンテナインスタンスによってプリエンプトされ、スケジュールが失敗する可能性が高くなります。
2. R&D スタッフは、同じ仕様を持つ 2 つのアプリケーション サービス A と B を担当しています。全体的なコストが変わらないようにするために、サービス A のインスタンスの数を減らし、サービス B のインスタンスの数を増やすことを選択します。デフォルトの Kubernetes スケジューラは、Pod の作成時間に従って新しい Pod を順番にスケジュールするため、ユーザーがサービス A のインスタンスをスケールダウンしてからサービス B のインスタンスをスケールアップすると、サービス A によって解放されたリソースが他のコンテナ インスタンスによってプリエンプトされる可能性が高くなり、サービス B のインスタンスをスケジュールできなくなります。
3. 大規模なプロモーションやフルリンクのストレステストなど、ビジネスで緊急の容量拡張が必要な​​場合、コンテナ プラットフォームはビジネス ニーズに合わせて新しいホスト ノードを拡張します。しかし、新たに拡張されたマシン リソースは、予想外に「小さくて高速な (頻繁に起動され、実行時間が短い)」タスクによって占有されてしまいます。一方では、大規模なサービスインスタンスをスケジュールすることが不可能になり、他方では、多くのリソースの断片化も引き起こします。

上記の問題を解決するために、スケジューラ内のリソース事前占有スケジューリング プラグインをカスタマイズして実装し (CRD を使用してリソース事前占有の期待値を定義し、スケジューリングの決定に影響を与える)、ユーザー エクスペリエンスとスケジューリングの効率を向上させました。

写真

写真

バランスのとれたスケジュール

クラスター内のノードの水位をより適切にバランスさせ、ノードの過熱を回避し、断片化されたリソースを最小限に抑えるために、Kubernetes が提供するスケジューラ拡張フレームワークに基づいて、複数のスケジューリング プラグインをカスタマイズして実装しました。

• CoolDownHotNode プラグイン: ホット ノードを回避するために、最近ポッドをスケジュールしたノードの優先度を下げます。
• HybridUnschedulable プラグイン: 弾性リソースを使用するポッドが特定のノードにスケジュールされるのを防ぎます。
• NodeBalance プラグイン: 各ノード上の CPU 要求値とイメージの比率を調整し、各ノードの CPU 使用率を調整するために使用されます。
• NodeInfoRt プラグイン: プロファイル スコアリング データとリアルタイム スコアリング データに基づいて Pod のスケジューリングを最適化します。

リアルタイムミキシング

今年1月からオフラインコロケーションの導入を開始しました。目標の最初のフェーズは、オンライン サービスを Flink タスクと共存させることです。コロケーションに Flink タスクを選択する理由は、それが永続的なオフライン タスクであるという点でオンライン サービスに似ているためです。起動後は、特別な事情がない限り、通常はオフラインになりません。この機能により、コンテナ クラスターのスケジュール設定の頻度とポッドの変更の度合いが軽減され、安定性への課題とコロケーションの全体的なリスクが軽減されます。

コロケーションがないと、クラスターの全体的な使用率は低くなります。プロファイリング機能は、ユーザーがサービス インスタンスのリソース仕様を可能な限り合理的に設定するのに役立ちますが、コンテナー プラットフォームにとってはまだ非常に受動的です。したがって、コロケーションに使用できるリソースを活用するために、さまざまなレベルのサービスに対して異なるコア バインディング戦略を設定します。次の表に示すように、P0〜P4 の範囲とオフライン タスクに適用可能な 4 つのアプリケーション タイプ (LSX、LSR、LS、BE) が定義されています。コア バインディング戦略は、完全なコア バインディングから部分的なコア バインディング、そして完全な共有までの範囲にわたります。

写真

オフライン タスク (Flink タスク) は BE タイプに属します。使用できるリソースは、ホストマシンのすべての CPU コアから個別に割り当てられた専用 CPU コアの一部と、LS の共有 CPU コア、および LSR および LS タイプのアプリケーションによって共有される一部の CPU コアです。

写真

LSX、LSR、および LS タイプのアプリケーション サービスのコンテナー インスタンスはすべて、Kubernetes ネイティブ リソースの CPU/メモリ リソースの使用に適用されます。 BE タイプのタスクでは、カスタム リソース BE-CPU/BE-Memory リソースの使用を申請する必要があります。

写真

Kubernetes のデバイス プラグイン メカニズムに基づいて、Kube-Agent コンポーネントを開発し、実装しました。このコンポーネントは、クラスター内のすべてのノードに Damonset モードでデプロイされます。一方では、カスタム戦略に従って（Kubelet コンポーネントを介して間接的に）このノード上の利用可能な BE リソースを API サーバーに報告する役割を担い、他方では、CPU コア バインディング操作を実行する役割を担います。コロケーションが進むにつれて、このコンポーネントもより多くの作業を引き受けるようになります (たとえば、CPU コンピューティング電力抑制操作、動的パラメータ調整操作、VPA 操作の実行など)。

オフラインコロケーション

コロケーションの最初のフェーズでは、CPU コア パーティショニング戦略を使用して、アプリケーション レベルのパーティショニングに基づいてコロケーションを実装します。 CPU コアの観点から見ると、CPU コア分割戦略が採用された後、各 CPU コアには独自の負荷割り当てがあります。十分に活用できるかどうかは、割り当てられた業務の特性によって異なります。しかし、マシン全体の利用率（あるいはクラスター全体の利用率）という観点から見ると、まだ改善の余地は大きいと言えます。コロケーションの第 2 フェーズでは、BE リソースを 2 度目に過剰販売し、別の新しいカスタム リソース (OT リソース) を割り当てて使用することを検討しました。 OT リソースを使用するタスクは、バインドされたコアを排他的に占有するのではなく、BE リソースに割り当てられたすべての CPU コアを共有します。

写真

OT リソースを使用して、AI トレーニング タスクとその他のデータ処理タスクを同じ場所に配置します。トレーニング タスクがオンライン サービスに与える影響を排除するために、次の戦略を採用しています。

• プラグインをスケジュールすることで、ホスト マシンの安全レベルを設定し、ノードの過熱を防ぎます。
• 優先度の競合は CPU グループ ID を通じて実行され、オフライン タスクのスケジュール優先度がオンライン サービスの優先度よりも確実に低くなるようにします。
• オンライン サービスのディスク IO に影響を与えないように、オフライン タスクを個別にマウントします。
• 夜間には、KubeAutoScaler を使用してオンライン サービスを弾力的にスケールダウンし、メモリのアイドル レートを比例して増加させて、オフライン タスクに十分なメモリ リソースが確保されるようにします。

弾性スケーリング

• HPA: 水平ポッド自動スケーリング、ポッドレプリカの水平拡張と縮小。
• VPA: 垂直ポッド自動スケーリング、ポッド仕様の垂直拡張と縮小。

Kubernetes は、リソース オブジェクト Horizo​​ntalPodautoScalers を通じてワークロードの水平スケーリングをサポートします。以前のバージョンでは、リソース インジケーターとして CPU とメモリのみがサポートされていましたが、新しいバージョンではカスタム インジケーターもサポートされます。 VPA のニーズに対して、Pod インスタンスのリソース仕様を調整すると、ホストマシン上のリソース台帳の管理と監視が伴い、さらに Pod の再構築/コンテナの再起動も伴うため、比較的影響が大きく、コミュニティで議論が続いているため、現時点では Kubernetes レベルでは比較的安定して利用可能な機能がありません。ただし、企業も VPA を試すことに熱心であり、独自のカスタマイズされた VPA ソリューションを設計するでしょう。この記事で説明したアプリケーション ポートレート機能は、VPA ソリューションを検討するための最初のステップです。

さらに、ビジネスのクラウドネイティブ変革をサポートする実際のプロセスでは、サービス リソース使用率指標を使用してビジネスがサービス インスタンスのレプリカの数を調整する決定を下す方法と比較して、スケジュールされたスケーリングによって R&D 担当者の自信を高めることができることがわかりました。 R&D 部門の同僚は、担当するビジネス サービスのトラフィック特性に基づいて、サービス インスタンスのスケジュールされたスケーリングを設定できます。

エラスティック スケーリング シナリオのすべての要件を満たすために、HPA、VPA、スケジュールされたスケーリングなどのエラスティック スケーリング ポリシー構成を統一的に管理する KubeAutoScaler コンポーネントを設計および実装しました。さらに、前述したように、このコンポーネントはポートレート システムと連携して、コロケーション シナリオで夜間にトラフィックの少ないサービスをスケールダウンし、オフライン タスクに使用できるリソースを増やします。

弾性スケーリング ソリューションは、特にテスト環境において、GPU サービス シナリオで多くのリソースの無駄を回避するのに役立ちます。図に示すように、サービス トラフィックを収集するために、Queue-Proxy という名前のサイドカー コンテナーを GPU サービスに挿入しました。トラフィックが特定のしきい値を下回ると、インスタンスの数も比例して削減されます。トラフィックが 0 の状態が一定期間続くと、完全にゼロになります。コールド スタート中、リクエストは Activator を通過し、Activator は KubeAutoScaler にサービスをスケールアップするよう通知します。このメカニズムは、運用環境の一部のサービスでも有効になっていますが、トラフィックのピークが低い期間に完全にゼロになることはなく、最小限の数のレプリカが維持されます。

写真

4. コンテナリソースとコスト管理の最適化

全体的なリソース使用率をより向上させ、インフラストラクチャ コストを削減するために、長い実装サイクルと高度な複雑性を伴う技術的ソリューションと比較して、ガバナンス メソッドは、特にアプリケーション サービスのコンテナー化された展開変換の後期段階で、より短い期間で良好な結果を達成できることがよくあります。当社は、以下の 5 つのガバナンス実践を通じて、大幅なコスト削減効果を達成しました。

モデルの置き換え

歴史的な理由により、当社のモデル推論サービスでは当初、より大きなビデオメモリとより優れた GPU コンピューティング能力を備え、トレーニング シナリオに適した V100 モデルを使用していました。ただし、推論シナリオでは少しやり過ぎです。モデルを比較・分析した結果、コスト効率の高いA10モデルを選択しました。推論サービス全体のコストは約 20% 削減されました。さらに、A10 モデルの CPU アーキテクチャがアップグレードされたため、フロントエンドとバックエンドの処理に対する要求が高い推論サービスの安定性とパフォーマンスが向上しました。 V100 から A10 に切り替える場合、一部のモデル サービスでは CUDA の下位バージョンが使用される可能性がありますが、A10 カードの計算能力には上位バージョンの CUDA が必要であるため、主な作業は基本イメージの置き換えです。さらに、2 枚のカードの GPU コンピューティング能力が異なるため、交換後に推論結果をオンラインにする前に比較して検証する必要があります。トラフィック再生の考え方に基づいて、企業がスイッチングテストを実行できるように AB 実験機能を設計しました。

写真

CPUコンピューティングリソースを使用するシナリオでは、一般的なコンピューティングパワー要件があり、CPU命令セットに特別な要件がなく、シングルコア/マルチコアパフォーマンスの要件がないサービスで使用されるモデルをIntelからAMDに切り替え、全体のコストを約14％削減しました。

リソースプール管理

コンテナ化の初期段階では、ビジネス側が主導権を握っていることは認めざるを得ません。ビジネス側は、安定性とリソース供給を考慮して、コンテナ プラットフォームが独自にクラスターまたはリソース プールを構築することを要求し、コンテナ プラットフォームもこれらの要求を満たすために広範な管理を選択します。コンテナ化が進むにつれて、ビジネスの信頼が高まり、コンテナ プラットフォームによるリソースの制御が強化されます。リソース管理を統合し、全体的なリソース割り当て率を向上させるために、以下のアクションを段階的に実行します。

• 冗長性制御: ビジネスリリースは周期的であり、リリースサイクルに基づいてコンテナプラットフォームによって管理されるリソースの冗長性を動的に調整します。日々の反復的な開発を確実に行いながら、冗長性を可能な限り削減します。
• クラスターの統合: Kubernetes クラスターの計画を統一し、地域 (上海、杭州、北京など)、ネットワーク環境の種類 (テスト、プレリリース、本番)、ビジネス モデル (通常のビジネス、ミドルウェア、インフラストラクチャ、管理および制御クラスターなど) などの次元に基づいて議論および決定し、不要なクラスターを削除します。
• リソース プールのマージとマシン モデルの調整: 同様のリソース需要特性 (コンピューティング タイプやメモリ タイプなど) を持つリソース プールをマージし、適切なマシン モデルを選択します。ビジネス部門と連携して、使用率の低い小さなリソース プールを削除または統合します。
• デフラグ: スケジューリング中に断片化を可能な限り回避するためにスケジューラの最適化のみに依存すると、パワーが制限されます。さらに、オンライン サービスの変更頻度は一般的に低いです。再スケジュールが行われない場合、長期間にわたってクラスター内に大量の断片化が蓄積されます。そのため、マルチレプリカ アプリケーション クラスターの場合、堅牢な正常なシャットダウン メカニズムに基づいて、いくつかのデフラグ タスク (Pod フリー スケジューリングの再構築、再スケジュール、ホスト マシンの再配置など) を適切に実行し、リソースの断片化を効果的に削減しました。

ワークロード仕様管理

ユーザー定義のワークロード仕様も、クラウド ネイティブ シナリオでは一般的な方法です。この一見ユーザーフレンドリーなアプローチは、コンテナ プラットフォームにいくつかの課題をもたらします。ユーザーの仕様設定の自由度に制限がない場合、非常に無理な仕様設定（例：6C120G、20C4G）が出現し、スケジュールの断片化を引き起こし、コスト分担計算基準の統一が困難になる可能性があります。

仕様問題を解決するために、オンライン サービスのリソース仕様を制限しました。ユーザーが任意に指定することはできません。代わりに、プラットフォームはユーザーが選択できる仕様のリストを提供します。仕様リストは、リソースプールの設計とビジネスシナリオの設定に分けられます。タスクベースのワークロードの場合、異なる CPU:メモリ比率に対応する 3 種類の CPU リソース仕様 (通常、コンピューティング、メモリ) を定義します。特別なタスク要件を満たすために、リソース仕様で CPU: メモリの範囲について合意しました。 GPU を使用するタスクの場合、各 GPU カードの CPU/メモリ/ビデオメモリの仕様が異なるため、GPU カードごとに CU 単位を定義します。ユーザーは、対応する CU を選択し、CU 数量を入力するだけです。仕様が合意された後、仕様適用とコスト分担の合理性を確保するために、仕様ごとに異なる請求を行いました。仕様の定義および課金基準については、以下の表をご覧ください。

写真

自作製品

Dewu のインフラストラクチャはクラウド上にあるため、ビジネス開発の過程で、一部のサービス機能にクラウド製品を直接使用します。アルゴリズム側のモデルトレーニングタスクには、当初はクラウド製品を使用していました。コンテナ化の進展に伴い、当社が独自に構築した AI プラットフォーム (KubeAI プラットフォーム) が徐々にモデルのトレーニング タスクを引き継ぎ、トレーニング タスクのコストが大幅に削減されました。

独自の KubeAI プラットフォームを構築することで、トレーニング、オンライン サービス、その他のオフライン タスク シナリオに使用されるリソースを統一された管理システムに統合し、グローバルな視点でリソースを合理的にスケジュールして割り当て、AI モデルのトレーニング シナリオに利用可能なリソースをより多く取得することが容易になりました。この記事のセクション 2.5 では、コロケーションを使用して、トレーニング タスク用のオンライン サービス リソースを提供しました。現在、コロケーションは正常に動作しています。

写真

マルチクラウド戦略

クラウドユーザーとして、マルチクラウド戦略は私たちの長期的な目標です。複数のクラウド間で交渉力を獲得し、コンプライアンス要件を満たし、より十分なリソース供給を獲得します。特に今年 4 月以降、GPT/AIGC の発生や政策的要因により、単一のクラウド プロバイダーの GPU リソースが不足し、事業展開に支障をきたす状況となっていました。当社は、事業の正常な運営を確保するために、速やかにマルチクラウド戦略を採用し、GPU 事業をさまざまなクラウド プロバイダーに分散しました。もちろん、マルチクラウドアクセスは一朝一夕で実現できるものではなく、ビジネスシナリオに応じて段階的に推進していく必要があります。時間がかかり、困難です。以下の問題を考慮する必要があります。

• ビジネスを整理し、マルチクラウドに適したビジネス シナリオを見つけるか、複数のクラウド間での柔軟な移行に適したビジネス シナリオを見つけます。
• 異なるクラウド プロバイダーのデータ センターは異なるリージョンにある可能性があるため、リージョン間のサービス アクセスとミドルウェアの依存関係の問題を考慮する必要があります。
• クラウド プロバイダー間のデータ アクセスと転送の問題には、専用回線の構築とコストの問題が伴います。

5. クラウドネイティブAIシナリオ構築

クラウドネイティブ コンテナ テクノロジーの実装により、あらゆるシナリオがカバーされ、一般的なサービス、ミドルウェア製品、特殊なビジネス シナリオでクラウドネイティブ テクノロジーの大きな利点を活用できるようになると期待しています。現在、MySQL、Redis、Miluvs、ElasticSearch などの製品はすでにコンテナ化を推進しています。当社は、KubeAI プラットフォームの構築を通じて、クラウドネイティブ AI シナリオの構築を継続的に進めています。

写真

KubeAIはDewuのAIプラットフォームです。これは、Dewuの事業全体にクラウドネイティブコンテナ技術を実装しながら、AIモデルの研究と生産の反復の過程で、会社のさまざまなビジネス領域のニーズを収集して探索することで、徐々に構築してきたクラウドネイティブAIプラットフォームです。 KubeAI はモデルをメインラインとして、モデル開発からモデルトレーニング、推論 (モデル) サービス管理、モデルバージョンの継続的な反復まで、ライフサイクル全体にわたってソリューションを提供します。さらに、AIGCの急速な発展に伴い、社内のAI支援生産ニーズを調査した上でAIGC/GPTサービスを開始し、Dewuの豊富なビジネスシナリオにGAI機能を提供し、ビジネス成果の向上に貢献しました。これまでに、KubeAI プラットフォーム関連のソリューションに関する記事をいくつか公開しました。ぜひ読んで、ご意見を交換してください。ここでは詳細には触れません。

• IoTクラウドネイティブAIプラットフォームKubeAIの実装プロセスを理解する
• Dewu AI プラットフォーム - KubeAI 推論トレーニング エンジンの設計と実践
• Dewu 大規模モデルプラットフォーム、ビジネス成果の向上の実践
• GPU推論サービスのパフォーマンス最適化

VI.見通し

Dewu におけるクラウドネイティブ コンテナ テクノロジーの実装は比較的速く、そのビジネス範囲も非常に広範囲です。 2年間の実践を経て、リソース管理システム、予算/コスト管理メカニズム、アプリケーションサービスリリースプロセス、AIアルゴリズムなどの管理システムとビジネスシナリオに完全に浸透しました。次：

• コンテナ化の面では、インフラのリソース効率をさらに向上させるため、ミドルウェア製品のコンテナ化を継続的に推進してまいります。
• 当社は、コロケーション ソリューションを継続的に統合し、リソース効率をさらに向上させるために、弾力的な容量やスケジュールの最適化などのソリューションを検討していきます。
• 安定性の観点から、コンテナプラットフォーム/Kubernetes自体の安定性構造に焦点を合わせ、リスクを防ぎ、ビジネスの円滑な動作を確保します。
• 複数のクラウドに迅速にアクセスし、ビジネスシナリオと一緒に複数のクラウドをすばやく切り替える機能を調べて、コンテナインフラストラクチャを柔軟に切り替え、ビジネススケールが成長し続けるにつれてロックソリッドのままであることを確認します。