クラウドネイティブで MySQL の高可用性を実現するにはどうすればよいでしょうか?

現在人気のリレーショナルデータベース (RDS) である MySQL は、クラウドネイティブの波の中で依然として多くの課題に直面しています。クラウドネイティブ設計原則を使用して、サンドボックス分離とコンピューティングとデータの完全な分離を通じて、低コストでスケーラブルかつ高可用性のクラウド RDS ソリューションを実装するにはどうすればよいでしょうか。 Alibaba Cloud データベースチームの Jiang Shanbiao (Meng Yu) が、クラウドネイティブの分散型 MySQL 高可用性データベースソリューションを紹介し、主要なテクノロジを共有し、クラウドネイティブシナリオにおける従来のデータベースの開発動向を簡単に分析します。

クラウド時代の到来により、従来の業界とインターネット業界の両方でビジネスが多様化し、反復が高速化しているため、全体的なデータ量が大幅に増加しています。

過去 2 年間で、Docker + Kubernetes などのテクノロジーの台頭により、誰もがビジネスをコンテナ化に移行し、チームのテクノロジーもクラウドネイティブに向けて進化しています。初期の Kubernetes は、ステートレスで共有のないアプリケーションのデプロイメントシナリオの解決に重点を置いていました。しかし、今日のますます複雑化するアプリケーションシナリオでは、状態保存の必要性が頻繁に発生します。

Kubernetes 1.9 からは、ステートフルサービス用のリソースタイプ Statefulset が GA に入り、Kubernetes 1.14 の Local Volume や CSI などのストレージ機能も GA 段階に入りました。 Kubernetes のステートフルサービスのサポートが全面的に強化され、多くのデータストレージベースの基本ミドルウェアを Kubernetes に移行できるようになりました。

現在人気の高いオープンソースのリレーショナルデータベース (RDS) である MySQL は、信頼性、使いやすさ、豊富な機能、幅広いアプリケーションという特徴を兼ね備えており、リレーショナルデータベースの主な選択肢となっています。多くの注目を集めているものの、MySQL もクラウドネイティブの波の中で多くの課題に直面しています。クラウドネイティブ設計原則を使用して、サンドボックス分離とコンピューティングとデータの完全な分離を通じて、低コストでスケーラブルかつ高可用性のクラウド RDS ソリューションを実現するにはどうすればよいでしょうか。

この記事では、クラウドネイティブの分散型 MySQL 高可用性データベースソリューション (以下、「SlightShift MySQL 高可用性ソリューション」と呼びます) を紹介し、クラウドネイティブシナリオにおける従来のデータベースの開発動向を簡単に分析します。

1. 要求と課題

クラウドネイティブシナリオで MySQL の高可用性アーキテクチャを検討する場合、主に次の課題があります。

フェイルオーバー: プライマリデータベースがダウンした場合、クラスターはプライマリを自動的に選択して障害を迅速に転送し、転送前後のデータの一貫性を保つことができます。
アジャイルで柔軟なスケーリング: 拡張および縮小プロセス中にビジネスアクセスを中断することなく、レプリカに基づいて柔軟な水平拡張を実現します。
データセキュリティ: 障害回復とデータ移行を容易にするために、データのスケジュールされたコールドバックアップ/リアルタイムのホットバックアップを実行します。
強力なデータ一貫性: バックアップ/読み取り専用レプリカとして使用されるスレーブノードのデータは、マスターノードのデータとリアルタイムまたは半リアルタイムで一致している必要があります。

第二の目的と重要な考慮事項

LightShift MySQL 高可用性ソリューションの目標は次のとおりです。

SLA 保証: 許容される最大のサービス利用不可時間は、1 年間で 52.56 分 (99.99%) です。
フェイルオーバー: マスターデータベースで例外が発生した場合、マスターとスレーブの切り替えには 2 分もかかりません。
弾力的な拡張: 理論的には、スレーブデータベースは無限に拡張でき、スレーブデータベースの拡張に必要な時間は 2 分未満です。
コールドスタンバイリカバリ: MySQL クラスターで回復不可能な問題が発生した場合、コールドスタンバイからのリカバリには 10 分もかかりません。

上記の目標に加えて、技術アーキテクチャを設計する際には、次の重要なポイントも考慮する必要があります。

高可用性
アプリケーションアクセスコスト
リソースの使用
スケーラビリティ
保守性

3フレームデザイン

この MySQL 高可用性ソリューションは、1 つのマスターと複数のスレーブのレプリケーション構造を使用します。マスター/スレーブデータレプリケーションでは、半同期レプリケーションを使用して、データの一貫性と読み取り/書き込み効率を確保します。理論上、スレーブデータベースは無限に拡張できます。

データエンジンの上位層に仲裁者が追加され、Raft 分散コンセンサスアルゴリズムを使用して自動リーダー選出とフェイルオーバーが実現されます。

ルーティング層は、SQL 要求プロキシとして ProxySQL を使用し、読み取りと書き込みの分離、負荷分散、および動的構成の検出を実現します。

監視とアラームに関しては、Prometheus-Operator ソリューションを使用して、MySQL 高可用性システム全体のリソース監視とアラームを実装します。

運用保守制御面では、Kubernetes Operator制御モデルを導入し、宣言型構成、クラスターステータス管理、On Demand（オンデマンド作成）を実現できるDB-Operatorを実装しています。さらに、データベース管理、テーブル管理、SQL クエリ、インデックスの変更、構成の変更、データのバックアップとリカバリなど、MySQL コンソールで基本的な MySQL 操作とメンテナンスを実行できます。

4つの主要技術

状態の永続性

コンテナ技術の誕生後、人々はすぐに、コンテナ技術を使用して「ステートレスアプリケーション」をカプセル化することが非常に便利であることに気付きました。しかし、コンテナを使用して「ステートフルアプリケーション」を実行したい場合、難易度は急激に増加します。

MySQL などのストレージベースの分散アプリケーションでは、マスターとスレーブの関係やマスターとスレーブの関係など、複数のインスタンス間に依存関係が存在することがよくあります。通常、各インスタンスはデータのコピーをローカルディスクに保存します。インスタンスが強制終了されると、再構築されてもインスタンスとデータ間の対応が失われ、アプリケーション障害が発生します。

インスタンス間に不平等な関係があり、インスタンスが外部データに依存しているこのようなアプリケーションは、「ステートフルアプリケーション」と呼ばれます。

Kubernetes クラスターでノードのローカルストレージリソースを使用するには、emptyDir、hostPath、Local PV など、いくつかの方法があります。このうち、emptyDir ではデータを永続化できず、hostPath 方式ではボリュームのライフサイクルを手動で管理する必要があるため、運用と保守に大きな負担がかかります。

したがって、MySQL シナリオでは、パフォーマンスと運用および保守コストを考慮して、ローカルストレージを使用する必要があります。今のところ、ローカル PV が唯一の選択肢です。

ローカル PV は、ビジネスで永続的に保存する必要があるデータをマシン上のディスクに保存します。リモートストレージと同様に、Pod のデータとライフサイクルは互いに独立しています。ビジネスポッドが削除されても、データは失われません。

同時に、リモートストレージと比較して、ローカルストレージはネットワーク IO オーバーヘッドを回避でき、読み取りおよび書き込みパフォーマンスも高いため、分散ファイルシステムや分散データベースなどの IO 要件が高いアプリケーションはローカルストレージに非常に適しています。

他の種類のストレージとは異なり、ローカル PV ローカルストレージはノードに大きく依存します。つまり、ポッドをスケジュールするときは、これらのローカル PV の容量とトポロジの要件も考慮する必要があります。

ローカル PV を使用する場合、MySQL は主に、遅延バインディングメカニズムとボリュームトポロジ対応スケジューリングの 2 つの機能を使用します。遅延バインディングメカニズムでは、MySQL Pod が PVC を使用してスケジューリングを完了するまで PVC のバインディングを延期できますが、ボリュームトポロジ対応スケジューリングでは、Kubernetes スケジューラがボリュームのトポロジ制約 (このストレージボリュームは特定の領域またはノードでのみ使用 (アクセス) できる) を認識できるため、スケジューラは Pod をスケジュールするときにこの制限を考慮する必要があります。

さらに、MySQL が使用するローカル PV は、nodeAffinity を通じて Pod を正しいノードにスケジュールする必要があります。

以下は、Local PV を使用した MySQL の簡単な構成例を示しています。

 ---
 APIバージョン: storage.k8s.io/v1
 種類: ストレージクラス
 メタデータ:
 作成タイムスタンプ: null
 名前: ローカルストレージ
 プロビジョナー: kubernetes.io/no-provisioner
 回収ポリシー: 削除
 ---
 APIバージョン: v1
 種類: PersistentVolumeClaim
 メタデータ:
 注釈:
 pv.kubernetes.io/コントローラーによってバインド: 「はい」
 作成タイムスタンプ: null
 ラベル:
 アプリ: わずかなシフト-mysql
 mysql-node: "true"
 名前: data-slightshift-mysql-0
 仕様:
 アクセスモード:
 -一度だけ読み書き可能
 リソース：
 リクエスト:
 ストレージ: 10Gi
 ストレージクラス名: ローカルボリュームストレージ
 ボリューム名: mysqlha-local-pv-0
 ---
 APIバージョン: v1
 種類: 永続ボリューム
 メタデータ:
 注釈:
 helm.sh/hook: 事前インストール、事前アップグレード
 helm.sh/リソースポリシー: 保持
 volume.alpha.kubernetes.io/node-affinity: '{ "requiredDuringSchedulingIgnoredDuringExecution":
 { "nodeSelectorTerms": [ { "matchExpressions": [ { "key": "kubernetes.io/hostname",
 "演算子": "In", "値": ["yz2-worker004"] } ]} ]} }'
 ラベル:
 pv-ラベル: わずかなシフト-mysql-データ-pv
 タイプ: ローカル
 名前: わずかなシフト-mysql-data-pv-0
 仕様:
 アクセスモード:
 -一度だけ読み書き可能
 容量：
 ストレージ: 500Gi
 地元：
 パス: /var/lib/ali/mysql
 persistentVolumeReclaimPolicy: 保持
 ストレージクラス名: pxc-mysql-data

以上がLocal PVの基本的な使い方です。 MySQL では、ノードの柔軟なスケーリングも考慮する必要があり、そのためには、MySQL インスタンスのスケーリングに合わせて、基盤となるストレージも動的に構成できる必要があります。解決策は 2 つあります。

LVM マネージャーは Kubernetes クラスターに導入され、DaemonSet の形式で実行されます。各ノード上のディスクの管理、ノードのディスク容量と残り容量の報告、PV の動的な作成などを担当します。ローカルストレージスケジューラスケジューリングモジュールは、ローカルストレージを使用する Pod に適したノード (十分な容量を持つ) を選択するために導入されています。

オープンソースソリューション OpenEBS を使用します。iSCSI は基盤となるストレージ機能を提供し、OpenEBS は iSCSI を管理します (現在は PV の ReadWriteOnce アクセスモードのみをサポートしています)。

自動マスター選択

SlightShift MySQL 高可用性アーキテクチャは、Raft の強力な一貫性プロトコルに基づいて、分散 MySQL 自動リーダー選出を実装します。

Raft はハートビートを使用してリーダー選出をトリガーします。 MySQL サーバーが起動すると、フォロワー状態になります。サーバーがリーダーまたは候補から有効な RPC を受信すると、フォロワー状態のままになり、リーダーは定期的にハートビートを送信して、自分がリーダーであることを示します。

フォロワーが選出タイムアウト内に通信を受信しない場合、リーダーの選出を開始します。

マスターを選択する手順は次のとおりです。

現在の用語を追加します。
候補者ステータスに変更します。
自身をマスターとして選出し、マスター選出 RPC を他のサーバーに並行して送信します。
候補ステータスは、以下の 3 つの状況が発生するまで継続されます。

候補者は次の 3 つの状況で退出します。

サーバー自体がリーダーになります。
他のサーバーはリーダーとして選出されます。
しばらくすると、どのサーバーもリーダーにはなりません。

フェイルオーバー

正常に実行されているマスタースレーブレプリケーション環境では、フェイルオーバーモジュールがクラスターの状態を監視し、マスターに障害が発生すると自動的にフェイルオーバーをトリガーします。

フェイルオーバーの最初のステップは、自動マスター選出です。自動マスター選出のロジックについては上記で紹介しました。 2 番目のステップは、データの一貫性の保証です。デッドマスターのデータが新しいマスターに同期されることの保証を最大限にする必要があります。

マスターを新しいマスターに切り替える前に、一部のスレーブが最新のリレーログイベントを受信していない可能性があります。フェイルオーバーモジュールは、最新のスレーブからのさまざまなリレーログイベントを自動的に識別し、さまざまなイベントを他のスレーブに適用して、すべてのスレーブのデータの一貫性を確保します。

プロキシ層に関しては、ProxySQL は MySQL インスタンスの読み取り/書き込み構成をリアルタイムで検出します。 MySQL インスタンスの読み取り/書き込み構成が変更されると、ProxySQL は MySQL インスタンスの読み取り/書き込みグループ化構成を自動的に調整し、最終的にはフェイルオーバー後に読み取り/書き込み分離が正しく実行されるようにします。

LightShift MySQL 自動フェイルオーバーの手順は次のとおりです。

HA-Manager はマスターサーバーとの異常な接続を検出し、フェイルオーバーを開始します。
スプリットブレインを回避するために、Dead Master をシャットダウンしてみてください (この手順はオプションです)。
最新のデータスレーブの end_log_pos を取得し、デッドマスターから bin-log を同期して、最終的にすべてのスレーブの end_log_pos が一貫していることを確認します。
ラフト分散アルゴリズムを使用して新しいマスターを選出します。
マスターを新しいマスターに切り替えます。
ProxySQL コードサービスをコールバックし、Dead Master 構成を削除します。
ProxySQL ゲートウェイは、各 MySQL インスタンスの読み取り/書き込み構成の変更を検出し、読み取り/書き込み分離構成を調整します。
切り替え結果を通知します（電子メール、DingTalk グループロボット）。

SlightShift MySQL は数秒でフェイルオーバーを実現できます。ホスト障害の検出には 5 ～ 10 秒、差分リレーログの適用には 5 ～ 10 秒かかり、その後新しいマスターに登録されます。通常、ダウンタイムの合計は 10 ～ 30 秒です。さらに、新しいマスターとして選出される各スレーブの優先順位は構成ファイルで構成できるため、複数のコンピュータルームに MySQL を展開するシナリオでは非常に実用的です。

自動障害回復

ダウンしたマスターノードが復元されると、次のようになります。

復元されたノードが Mysql Pod を再作成してクラスターに参加すると、Sentinel は新しい Pod をスレーブとして構成し、現在のマスター Mysql のログファイルと位置を取得して、新しく追加されたスレーブのデータを同期します。
Mysql Pod がまだ存在し、復元されたノードで使用可能な場合、Sentinel はラベル master を持つ 2 つの Pod を見つけます。 Sentinel は、停止中に選択された新しいマスターを引き続き使用し、復元されたマスターを強制的にスレーブに設定し、読み取り専用モードを有効にします。

ダウンしたスレーブノードが復元されると、次のようになります。

リカバリノードが MySQL Pod を再作成してクラスターに参加すると、Sentinel は新しい Pod をスレーブとして構成し、現在のマスター MySQL のログファイルと位置を取得して、新しく追加されたスレーブのデータを同期します。
Mysql Pod がまだ存在し、復元されたノードで使用可能な場合、スケジューラは何も操作を実行せず、proxysql-service は新しく追加されたスレーブを検出し、それをエンドポイントリストに追加します。

状態管理

状態管理は新しいトピックではありません。一貫した状態を集中システムに配布し、分散システムが常に期待される状態に収束することを保証します。これは集中型システムの基礎の 1 つです。

MySQL サービスは、マスターノードと、マスターからデータを非同期的に複製する複数のスレーブノードで構成されます。これは、1 つのマスターと複数のスレーブのレプリケーションモデルです。このうち、マスターノードはユーザーの読み取りおよび書き込み要求を処理するために使用でき、スレーブノードはユーザーの読み取り要求を処理するためにのみ使用できます。

このようなステートフルサービスを展開するには、StatefulSet に加えて、ConfigMap、Headless Service、ClusterIP Service など、他の多くの種類の k8s リソースオブジェクトも必要です。これらの間の連携により、MySQL などのステートフルサービスを k8s 上で実行できるようになります。

MySQL クラスターでは、マスターに障害が発生し、クラスターがフェイルオーバーを実行したときに、状態転送が最も頻繁に発生します。マスターに障害が発生すると、マスター選択ロジックが自動的にトリガーされます。マスターの選出が完了すると、新しいマスターが読み取りおよび書き込みサービスを正常に提供できるようになるまでフェイルオーバーが実行されます。フェイルオーバープロセスには時間がかかり、フェイルオーバープロセス中は MySQL サービスは書き込み不可の状態になります。

フェイルオーバー中、Dead Master インスタンスは k8s クラスターによって自動的にプルアップされます。引き上げられた後、デッドマスターは自分が正当なマスターであると考えるようになります。これにより、クラスター内に 2 つのマスターが同時に存在することになります。書き込み要求は 2 つのマスターノードにランダムに割り当てられる可能性があり、スプリットブレインの問題が発生します。

このシナリオのスプリットブレイン問題を解決するために、InitContainer メカニズムを導入しました。このメカニズムは、Sentinel と組み合わせることで、問題をうまく解決できます。

InitContainer は、その名前が示すように、コンテナが起動されると、準備作業を完了するために 1 つ以上のコンテナが起動されます。 InitContainer が複数ある場合は、指定された順序で実行されます。すべての InitContainers が実行されるまで、メインコンテナーは起動されません。

各 MySQL インスタンスに InitContainer を追加しました。 Dead Master が k8s によって自動的にプルアップされた後、InitContainer はクラスターがフェイルオーバー段階にあるかどうかを自動的に検出します。フェイルオーバー段階にある場合は、フェイルオーバーが終了するまでスリープポーリング状態になります。

フェイルオーバーが終了すると、Sentinel は Dead Master がプルアップされたことを検出し、Dead Master を New Master のスレーブノードとして自動的に設定します。これにより、完全なフェイルオーバープロセスが完了し、クラスター内のブレインスプリットの問題が回避されます。

宣言型操作

k8s を使用する場合、通常はアプリケーション管理のニーズを満たすために k8s のリソースを使用します。

Deployment や StatefulSet などのワークロードを通じてサービスをデプロイします。
Service と Ingress を通じてサービスへのアクセスを管理します。
ConfigMap と Secrets を通じてサービス構成を管理します。
等

上記のリソースはユーザーの期待を表しています。 kube-controller-mananger のコントローラーは、リソースイベントをリッスンし、対応するアクションを実行してユーザーの期待を実現します。

この操作モードは、アプリケーション管理に非常に便利です。ユーザーは、従来の HTTP API や RPC 呼び出しなどの使用方法を気にすることなく、宣言的な方法でアプリケーションを管理できます。

コントローラーは、ユーザーの期待が満たされるようにさまざまなメカニズムを使用します。たとえば、オブジェクトの現在の状態がユーザーの期待を満たしていることを確認するためにオブジェクトの状態を継続的に検出するこの操作および保守モードは、宣言型の操作および保守と呼ばれます。

しかし、k8s が提供する基本的な型のみを使用すると、MySQL などの複雑なアプリケーションの運用および保守コストは依然として非常に高くなります。宣言型の運用保守モデルを MySQL アプリケーションに拡張できれば、MySQL アプリケーションの導入と運用保守のコストが大幅に削減されます。

この問題を解決するために、slightshift-mysql-operator が誕生しました。

slightshift-mysql-operator は基本的にリソース + コントローラーです。

リソース

カスタムリソース定義 (CRD) は、ユーザーがサービスに対する期待を記述するための宣言的な方法を提供します。

コントローラ

リソースにおけるユーザーの期待を満たします。

slightshift-mysql-operator は、k8s の既存の概念を組み合わせることで、MySQL の導入と保守のコストを大幅に削減します。

ユーザーは、デプロイメントと同様の方法でMySQLの要件を説明します。

MySQL アプリケーションを k8s にデプロイする手順は、k8s 公式リソースの場合と同じです。

slightshift-mysql-operatorのコントローラーはイベントリクエストをリッスンして処理します

リソースイベントをリッスンします。
さまざまなタイプのイベント (ADD/UPDATE/DELETE) に対応するアクションを実行します。
オブジェクトの状態を継続的に検出してアクションを実行し、ユーザーの期待に応えるようにサービス状態を制御します。

slightshift-mysql-operator の設計コンセプトは次のとおりです。

宣言型構成: 可読性と運用・保守効率を向上させ、運用・保守コストを削減します。
最終的な一貫性: 最終的な一貫性を実現するためにクラスターの状態を動的に調整します。

slightshift-mysql-operator は、Kubernetes クラスターでの MySQL アプリケーションの使用と管理にかかるコストを大幅に削減します。ユーザーは宣言型 CR を通じてアプリケーションを作成でき、ベンダーはアプリケーション管理の専門知識をカプセル化して、ユーザーに対して透過的にすることができます。

slightshift-mysql-operator は、アーキテクチャレベルで階層化設計を使用してアーキテクチャの複雑さを簡素化し、複数の MySQL クラスタインスタンス間の相互干渉を最小限に抑え、各インスタンスの自律性を実現します。

展開構造を次の図に示します。

バックアップと復元

データのセキュリティを確保するには、極端なケース (クラスターのクラッシュ) でもユーザーデータを復元できるように、データを定期的にバックアップする必要があります。

Cronjob 経由で MySQL データをバックアップします。

Kubernetes クラスターに Cronjob を作成し、定期的にデータをバックアップします。
バックアップデータにはタイムスタンプが付けられ、オブジェクトストレージサーバー (Ceph、Minio) にアップロードされます。

ジョブを作成して MySQL からデータを回復します。

クラスター内にリカバリジョブを作成します。ジョブは、SNAP_SHOT に基づいてストレージサーバー (OSS、Minio) からバックアップデータを取得します。
ジョブはデータを MySQL マスターインスタンスに復元し、スレーブインスタンスはデータ同期を完了します。

5つの技術進化

進化することによってのみ、私たちは食物連鎖の頂点に立つことができるのです。

Gartner のレポートによると、データベースクラウドプラットフォームの市場シェアは今後 5 年間で 2 倍になり、ユーザーの 70% が dbPaaS データベースクラウドプラットフォームを使い始めることになります。したがって、データベースクラウドプラットフォームのさまざまなアプリケーションのニーズを満たし、プライベートクラウド展開における多数の異なるタイプのデータストレージ製品の運用上の複雑さを軽減するために、データベースアーキテクチャの進化は、今後 10 年間のデータベース変革の主な方向性の 1 つになります。

クラウドネイティブデータベースは、データベースの将来の開発にとって重要な方向性です。クラウドネイティブデータベースアーキテクチャも、クラウド化の要件に応じて反復する必要があります。今後も、需要の変化に応じてクラウドネイティブデータベースアーキテクチャの進化は続いていきます。

6. 今後の見通し

ミドルウェアは、上位のビジネスシステムを構築するための基礎および中核技術として、高い信頼性、高い拡張性、強力な専門性という特徴を備えています。

今後は、ミドルウェアのこうした特性により、クラウドネイティブミドルウェアは標準化、構築、疎結合、プラットフォーム化の方向へ発展していくでしょう。プラットフォーム化により、ビジネスの変化に迅速に対応し、ビジネスの水平展開のための集中型の技術ソリューションを提供できるようになります。

最終的には、基本的なミドルウェアの展開、構成、アップグレード、スケーリング、トラブルシューティングなどの自動化機能をカバーする、エンタープライズレベルのクラウドネイティブミドルウェア PaaS プラットフォームを構築したいと考えています。

まず、ミドルウェアプラットフォームについての私の理解についてお話しします。ミドルウェアプラットフォームは、一連のミドルウェアソリューションを備えたオープンテクノロジープラットフォームである必要があります。これは、複雑で絶えず変化する上位レベルのビジネス領域に安定した信頼性の高いコンピューティングおよびストレージサービスを提供することを目的とした、完全で実績のあるオープンなコンポーネント化されたソリューションです。

プラットフォームベースの製品の開発の歴史は、プラットフォームとして始まったわけではありません。むしろ、まずビジネスニーズがあり、実際のビジネスニーズを解決するために、特定の分野の知識が蓄積され、その分野の専門家が生まれ、最終的にプラットフォームが変革されます。言い換えれば、プラットフォームは継続的な蓄積のプロセスであり、自然なプロセスでもあります。

企業情報プラットフォームを構築する過程で、ミドルウェアプラットフォームを効果的、合理的、標準化して使用し、上位の業務システムを迅速に構築することで、企業が需要の変化にタイムリーに対応し、企業の集中管理を形成し、企業の中核的な強みを強化して持続可能な競争優位性を獲得するための強力な保証を提供できます。

【この記事は51CTOコラムニスト「アリババオフィシャルテクノロジー」によるオリジナル記事です。転載については原著者にお問い合わせください。

この著者の他の記事を読むにはここをクリックしてください

<<: フォグコンピューティングが IoT の課題を解決する方法

>>: 誰かがテンセントミーティングの計算をしたところ、5か月で714億元の社会コストが節約されたことが判明した。