この記事では、第2回SIG Cloud-Provider-Alibabaセミナーのライブストリームを振り返ります。ダウンロードリンクを提供し、ライブストリーム中に寄せられた質問に回答しています。

はじめに

まず、Cloud Provider SIGを紹介します。これはKubernetesのクラウドプロバイダーグループで、Kubernetesのエコシステムをすべてのクラウドプロバイダーにとってニュートラルなものにすることを目的としています。異なるクラウドプロバイダーを調整し、開発者の要求を満たすために統一された規格を使用しています。中国で初めてCloud Provider SIGに参加したクラウドプロバイダーとして、Alibaba CloudもKubernetesの標準化を推進しています。AWS、Google、Azureなどの他のクラウドプロバイダーと技術的な調整を行い、クラウドとKubernetesの接続を最適化し、異なるコンポーネントのモジュラーや標準プロトコルを統一しています。

クラウドネイティブコンピューティングの普及に伴い、Kubernetes上に展開されるアプリケーションロードが増えています。Kubernetesはクラウドネイティブコンピューティングの礎となり、ユーザーとクラウドコンピューティングの間の新しいインタラクションインターフェースとなっています。アプリケーションの基本的な依存関係の一つであるネットワークは、クラウドネイティブアプリケーションに必要な基本コンポーネントであり、また、多くの開発者がクラウドネイティブに移行する際の最大の懸念事項でもあります。ユーザーは多くのネットワーク問題を考慮しなければなりません。例えば、ポッドネットワークが元々のマシンネットワークと同じプレーン上にないこと、オーバーレイポッドネットワークがパケットカプセル化のパフォーマンスロスを引き起こすこと、Kubernetesのロードバランシングやサービスディスカバリーが十分なスケーラビリティを持たないことなどです。では、どのようにしてクラスターポッドネットワークを構築すればよいのでしょうか。

この記事では、Alibaba Cloudがどのようにしてハイパフォーマンスなクラウドネイティブ環境のポッドネットワークを設計・構築しているかを説明します。

記事は3つのパートに分かれています：

Kubernetesポッドネットワークの概要
ハイパフォーマンスでクラウドネイティブなポッドネットワークの構築
ネットワークのスケーラビリティとパフォーマンスの強化

Kubernetesポッドネットワークの概要

まず、本記事ではKubernetesポッドネットワークの基本的な概念を紹介します。

ポッドネットワークの接続性（CNI）
Kubernetesのロードバランシング（Service）
Kubernetesサービスディスカバリー(CoreDNS)

ポッドネットワークの接続性(CNI)

次の図は、Kubernetesのポッドネットワークを示しています。

ポッドのネットワーク接続性（CNI）には、次のような要素があります。

ポッドは独自のネットワークネームスペースとIPアドレスを持っています。異なるポッドのアプリケーションが、競合することなく同じポートをリッスンできます。
ポッドは、それぞれのIPアドレスを使用して相互にアクセスできます。クラスタ内のポッドは独自のIPアドレスを使用して他のネットワークにアクセスでき、ポッド間の通信、ポッドとノード間の通信、ポッドと外部ネットワーク間の通信が可能です。
これらのネットワーク機能を実現するためには、アドレスの割り当てとネットワークの接続が必要です。これらの機能は、CNIのネットワークプラグインで実装されています。

CNIとは？

Container Network Interface（CNI）は、Kubernetesがポッドのネットワークを構成するためのAPIを実装した一連のネットワークプラグインを提供します。一般的なCNIプラグインには、Terway、Flannel、Calicoなどがあります。

ポッドを作成するとき:

1、Kubeletはまず、ApiServerからのポッド作成をリッスンし、ポッドのサンドボックスを作成します。
2、次に、KubeletはCNIを通じてCNIプラグインを呼び出し、ポッドのネットワークを設定します。
3、CNIは、ポッドのネットワークネームスペースを設定し、異なるポッド間のネットワークアクセスを可能にします。

どのようにしてポッドを接続することができるか？

一般的に、ポッドはホストネットワークと同じプレーンに存在しないため、ポッド同士はどのようにして通信できるのでしょうか。一般的に、ポッドの接続には以下の2つのソリューションが使用されます。

パケットのカプセル化：ポッド間の通信パケットをホスト間のパケットにカプセル化します。
ルーティング：ポッド間の通信パケットは、ルーティングテーブルを介して、対応するノードに転送されます。

Kubernetesネットワークロードバランシング（サービス）について

なぜKubernetes Serviceが必要なのか？

Kubernetes Serviceが必要な理由は以下の通りです。

Podはライフサイクルが短く、IPアドレスが変更可能なため、固定のアクセス方法が必要です。
Deployment内のPodグループには、統一されたアクセスエントリが必要であり、ロードバランシングが必要です。

Kubernetesサービス

Kubernetes Serviceオブジェクトが作成されると、固定のService IPアドレスが割り当てられます。
labelSelectorを使用してポッドのグループを選択し、選択されたポッドのグループのIPアドレスとポートに対してService IPアドレスとポートでロードバランシングを行うことができます。
これにより、ポッドのグループに対して固定のアクセスエントリとロードバランシングが行われます。

Kubernetes LoadBalancerサービス

Kubernetesサービスディスカバリー(DNS)

固定IPアドレスのアクセス方法を提供しているにも関わらず、ネームスペースやクラスターごとにIPアドレスが異なるサービスがあります。このような場合、どのようにしてアクセスエントリを統一するのでしょうか。
クラスタ内のCoreDNSは、Service名をServiceのIPアドレスに自動的に変換し、異なる展開環境でも同じアクセスエントリが実装されるようにしています。

高性能なクラウドネイティブポッドネットワークの構築

クラウドネイティブなポッドネットワークとは？

クラウドのIaaS層のネットワークは、すでに仮想化されています。ポッドでさらにネットワークの仮想化を行うと、パフォーマンスの低下が大きくなります。

クラウドネイティブなコンテナネットワークは、クラウド上のネイティブなクラウドリソースを利用してポッドネットワークを構成します。

ポッドとノードは同じネットワークプレーンにあり、同じネットワークステータスを持っています。
ポッドネットワークは、クラウド製品とシームレスに統合することができます。
パケットのカプセル化やルーティングを必要とせず、ポッドネットワークは仮想マシンと同等のネットワークパフォーマンスを提供します。

CNIは、クラウドネットワークのオープンAPIを呼び出して、ネットワークリソースを割り当てます。

一般に、ネットワークリソースとは、ポッドが配置されているノードにバインドされたエラスティック・ネットワーク・インターフェース（ENI）とENIセカンダリIPアドレスのことです。
ネットワーク・リソースが割り当てられると、CNIプラグインはホスト内のポッドのサンドボックスにリソースを割り当てます。

ポッドネットワークは、VPCの第一級オブジェクトとなります。そのため、クラウドネイティブなポッドネットワークを使用すると、以下のようなメリットがあります。

ポッドと仮想マシンが同じネットワーク層にあるため、クラウドネイティブなビジネスの移行が容易になります。
ポッドに割り当てられたネットワークデバイスは、パケットのカプセル化やルーティングに依存せずに通信に使用できます。
クラスタ内のノード数は、ルーティングテーブルやカプセル化FDBテーブルのクォータによって制限されません。
ポッドに対してオーバーレイCIDRブロックを計画する必要はありません。異なるクラスターのポッドは、セキュリティグループが開かれている場合に限り、相互に通信することができます。
ポッドは、ノード上のポートフォワーディングを必要とせずに LoadBalancer のバックエンドにマウントできます。
NAT ゲートウェイは、ポッドに対して SNAT を実行することができ、ノード上のポッドに対して SNAT を実行する必要はありません。ポッドは自分のIPアドレスを使用してVPCリソースにアクセスするため、監査が容易になります。ポッドが外部ネットワークにアクセスする際、conntrack（接続追跡）のSNATに依存しないため、障害発生率が低下します。

クラウドネイティブなリソースを使ってポッドネットワークを構築するには？

IaaS層のネットワークリソース（Alibaba Cloudを例に挙げています。)

ENI：IaaS層の仮想化されたENIは、動的に割り当てられ、VMにバインドされます。通常、バインドできるENIの数はPCI-Eによって制限されています。
ENIのセカンダリIPアドレス：通常、ENIはセカンダリIPアドレスとして数十個のVPC IPアドレスにバインドされます。

ENIまたはENIのセカンダリIPアドレスは、クラウドネイティブなポッドネットワークを実装するためにポッドに割り当てられます。

ポッドネットワークリソース管理

クラウドリソースとポッドの迅速なスケーリングのギャップを解決する方法。

ポッドの起動は数秒で完了します。しかし、IaaSレイヤーの操作や呼び出しには、通常10秒程度の時間が必要です。
ポッドは頻繁にスケールイン、スケールアウトされます。しかし、クラウド製品のAPIには、通常、厳しいスロットリングが実装されています。

Terwayでは、リソースをキャッシュし、起動を高速化するために、組み込み型のリソースプールを使用しています。

リソースプールは、ポッドに割り当てられた使用中およびアイドル状態のリソースを記録します。
ポッドが解放された後も、リソースはリソースプールに保持され、次回の起動を迅速に行うことができます。
また、リソースプールには最小レベルと最大レベルがあります。アイドルリソースの数が最小レベルよりも少ない場合は、APIを呼び出してリソースを補い、事前にロードしておくことで、大量のポッドを作成したときに必要なAPI呼び出し回数を減らすことができ、アイドルリソースの数が最大レベルよりも高い場合は、APIが呼び出されて余剰リソースが解放されます。

次の図のように、同時進行するポッドネットワークのリソースの設定、呼び出し、一括申請が可能です。

また、十分なIPアドレスを確保するためにポッド用のvSwitchをどのように選択するか、競合を最小限に抑えるために各ノードのENIのキュー数と割り込み数をどのようにバランスさせるかなど、他にも多くのリソース管理ポリシーを検討する必要があります。

詳細については、Terwayのドキュメントやコードを確認してください。

ポッドの接続方法

排他的なENIモード
このモードはCNIで実装されています。

1、Terwayのリソースマネージャーは、ポッドが配置されているノードにENIをバインドします。
2、Terway CNIはENIをポッドのネットワークネームスペースに追加します。
3、Terway CNIはENIに対してIPアドレスやルートなどのネットワークデータを設定します。

この方式には、以下のような特徴・メリットがあります。

ポッドネットワークがホストネットワークスタックを経由しない。
ECSサーバーと同等の性能を発揮し、性能低下がない。
ポッドはENIやDPDKなどを利用してアプリケーションを高速化する。

シェアードENIモード

このモードはCNIに実装されています。

1、申請されたIPアドレスの数と既存のENIに基づいて、Terwayのリソースマネージャーは、ENIを申請するか、セカンダリIPアドレスを申請するかを決定します。
2、Terway CNIは、ENI上にIPVLANのサブインターフェイスを作成します。
3、Terway CNIは、IPVLANサブインターフェイスをポッドネットワークの名前空間に入れます。
4、Terway CNIはポッドネットワークネームスペースのIPアドレスとルーティング情報を設定します。

この方式には、以下のような特徴・利点があります。

IPVLANネットワークの一部だけが、iptablesやルーティングテーブルを経由せずにネットワークスタックを通過する。パフォーマンスの低下が少ない。
1つのENIで通常10～20個のセカンダリIPアドレスをサポート。展開密度を気にする必要はありません。

性能比較

TCP_RR、UDP、PPS、帯域幅、レイテンシーのいずれも、一般的なフランネル社のVXLANソリューションのオーバーレイネットワークよりも優れています。
専用のENIモードでは、PPSや帯域幅のロスなく、マシンのネットワークリソースをフルに活用できます。このモードは、ハイパフォーマンスコンピューティングやゲームのシナリオに適しています。

Kubernetesネットワークのスケーラビリティとパフォーマンスの向上

Kubernetesサービスのパフォーマンスとスケーラビリティの問題

デフォルトでは、Kubernetes Serviceはkube-proxyを実装しており、iptablesを使用してService IPアドレスとロードバランシングを設定しています。

ロードバランシング時のiptablesのリンクが長い。その結果、ネットワークのレイテンシーが大幅に増加します。IPVSモードでもiptablesを呼び出す必要があります。
スケーラビリティの悪さ：iptablesのルールはフルモードで同期されます。サービスやポッドの数が多くなると、毎回ルールの同期に1s程度かかり、データリンクのパフォーマンスが大幅に低下します。

NetworkPolicyのパフォーマンスとスケーラビリティに関する問題

KubernetesのNetworkPolicyは、ポッド間の通信を許可するかどうかを制御します。現在、主流のNetworkPolicyコンポーネントはiptablesをベースに実装されていますが、iptablesのスケーラビリティの問題もあります。

iptablesのマッチングは、パフォーマンスとスケーラビリティが低い。
iptablesの更新が遅い。

サービスとNetworkPolicyのスケーラビリティを加速するためにeBPFの使用：

eBPFは、最新のLinuxバージョンで提供されているプログラム可能なインターフェイスです。
eBPFのプログラムは、tc-ebpfを使用してENIに注入されます。
eBPFは、ネットワークリンクの長さと複雑さを大幅に削減するために使用されます。

前述の図のように、tcツールを使用してeBPFプログラムをポッドのENIに注入すると、ServiceとNetworkPolicyがENIで解決できます。そして、ネットワーク要求はENIに送られます。これにより、ネットワークの複雑さが大幅に軽減されます。

各ノードはServiceとNetworkPolicyを聞くためにeBPFエージェントを実行し、ポッドのENIのingressとegressのルールが設定されています。
egress eBPFプログラムは、Kubernetes ServiceのIPアドレスへのリクエストを判定し、バックエンドのエンドポイント間で負荷を分散します。
ingress eBPFプログラムは、NetworkPolicyルールに基づいて送信元IPアドレスを計算し、リクエストを送信するかどうかを判断します。

注）ポッドENIのBPFルールを設定するために、ノード上のBPFエージェントとしてCiliumを使用しています。Terway関連の適応については、こちらのサイトをご覧ください。

性能比較

eBPFによるリンクの簡略化後は、iptablesを使用した場合に比べて32%、IPVSモードに比べて62%と大幅に性能が向上しています。
eBPFのプログラミングにより、サービス数を5000まで増やしても、パフォーマンスの低下はほとんどありません。しかし、サービス数を5000に増やした場合、iptablesモードでは61%の性能低下が見られます。

KubernetesのCoreDNSのパフォーマンスとスケーラビリティに関する問題

Kubernetesのポッドは、DNSドメイン名を解決する際に多くの検索を行う必要があります。前述の図のように、ポッドがaliyun.comをリクエストすると、以下のDNS設定を順に解決していきます。

aliyun.com.kube-system.svc.cluster.local -> NXDOMAIN
aliyun.com.svc.cluster.local -> NXDOMAIN
aliyun.com.cluster.local -> NXDOMAIN
aliyun.com -> 1.1.1.1

CoreDNSはノードに集中的に配置されます。ポッドがCoreDNSにアクセスする際、解決リンクが長すぎるため、UDPが使用されます。その結果、失敗率が高くなってしまいます。

AutoPathを使用してポッド内のDNSクエリを大幅に削減

クライアントサイドの検索をサーバーサイドの検索に変更します。

ポッドがドメイン名の解決のためにCoreDNSに要求を送信するとき：

CoreDNSは、送信元IPアドレスに基づいてポッド情報を照会します。
その後、CoreDNSはポッドの名前空間情報に基づいて、ポッドがアクセスしたいサービスを見つけて返します。
クライアントのリクエスト数は4つから1つに減ります。これにより、CoreDNS のリクエストが 75% 削減され、故障率が低下します。

各ノードで`node-local-dns`を使用

node-local-dnsは、ポッドからのDNSクエリをインターセプトします。
node-local-dnsは、外部ドメイン名のリクエストが中央のCoreDNSに送信されないように、外部ドメイン名のトラフィックを分散します。
中間リンクでは、より安定したTCP解決方法を使用します。
ノードはDNSの解決結果をキャッシュするため、中央のCoreDNSに送信されるリクエストは少なくなります。

ExternalDNSはAlibaba Cloudのドメイン名解決サービスを使用します。

クラウドネイティブなDNS解決の際、ポッドはPrivateZoneにカスタムDNS機能を要求します。
ExternalDNSは、サービスとポッドの作成をリッスンした後、PrivateZoneでドメイン名解決を構成します。
ネイティブECSと同じDNS解決のパフォーマンスを提供します。

概要

Alibaba Cloudがハイパフォーマンスでクラウドネイティブなポッドネットワークを設計・構築する方法を紹介しました。クラウドネイティブな開発により、より多くの種類のアプリケーションロードがKubernetes上で実行され、より多くのクラウドサービスがポッドシナリオに統合されていきます。今後、より多くの機能やアプリケーションシナリオが、高性能でクラウドネイティブなポッドネットワークでインキュベートされていくと考えています。

このテーマにご興味のある方は是非ご参加ください。

プロジェクトアドレス： https://github.com/AliyunContainerService/terway

Q&A

Q1：podネットワークの名前空間を作成する際、vethペアはpodネットワークの名前空間とホストの接続に使用されますか？

A1:

Shared ENI mode：カーネル3.10では、互換性を確保するためにvethペアが名前空間の接続に使用されています。Alibaba Cloudで使用されているaliyunlinux2カーネル4.19などの4.xカーネルバージョンでは、IPVLANが名前空間の接続に使用されます。
Exclusive ENI mode：ENIはポッドの名前空間に移動し、ホストとポッドの名前空間を接続する必要はありません。

Q2：ポッドのIPアドレスが固定されていない場合、セキュリティ監査はどのように行われるのでしょうか？

A2:

ポッドのIPアドレスは、宣言期間中は変更されません。IPアドレスが割り当てられたポッドは、Kubernetesのイベントで確認できます。
TerwayのNetworkPolicy実装では、ポッドはラベルで識別されます。ポッドが再構築されると、ラベルで作成されたポッドのIPアドレスは動的に更新されます。
Terwayがポッドに設定するIPアドレスは、比較的固定されています。例えば，Statefulsetアプリケーションがノード上で更新されると，TerwayはポッドのIPアドレスを一定期間予約し，ポッドが再起動されたときにすぐに使用できるようにします。IPアドレスは、更新プロセスの間も変更されません。

Q3：IPVLANはカーネルへの要求が高いのでしょうか？

A3: はい。Alibaba Cloudではaliyunlinux2カーネル4.19を使用することができます。それ以前のバージョンのカーネルでは、TerwayはENI上でセカンダリIPアドレスを共有するためのvethペア＋ポリシールーティング方式もサポートしています。ただし、性能は低いかもしれません。

Q4: eBPFをポッドで起動した場合、ポッドの起動速度に影響はありますか? また、eBPFをpodで展開する場合、どのくらいの時間がかかりますか？

A4：eBPFのプログラムコードはそれほど大きくありません。現状では、全体のデプロイ時間が数百ミリ秒増加します。

Q5：IPv6はサポートされていますか？その実装上の問題点は？カーネルや kube-proxy のコードに問題はありませんか？

A5: 現在、IPv6アドレスはLoadBalancerを通して公開することができます。ただし、IPv6アドレスはLoadBalancer内でIPv4アドレスに変換されます。現在、ポッドはIPv6アドレスをサポートしていません。IPv6アドレスは、Kubernetes 1.16以降のkube-proxyからサポートされます。我々はこの問題を積極的に追跡しており、今年中にAlibaba Cloud IaaSと一緒にネイティブポッドのIPv4/IPv6デュアルスタックを実装する予定です。

Q6: CoreDNSの解決要求のたびに、アクセスされたサービスを取得するためにソースIPアドレスが使用されます。アクセスされたサービスを取得するためにKubernetesのAPIが呼び出されますか？これはAPIの負担を増やすことになりませんか？

A6：いいえ、上記のような構造になっています。CoreDNS AutoPathは、APIサーバからのポッドやサービスの変更をwatch&list mechanismを使ってリッスンし、ローカルキャッシュを更新しています。

Q7: Kubernetes Serviceのリクエストはポーリングモードでポッド群に送られますか？また、各ポッドへのリクエストの確率は同じですか？

A7: はい。確率は同じです。ロードバランシングで使われるラウンドロビンアルゴリズムに似ています。

Q8: IPVLANとeBPFは，後続のカーネルバージョンでのみサポートされているようです。ホスト側のカーネルに要求があるのでしょうか？

A8: はい。Alibaba Cloudではaliyunlinux2 kernel 4.19が使用できます。それ以前のカーネルバージョンでは、TerwayはENI上でセカンダリIPアドレスを共有するためのvethペア＋ポリシールーティング方式もサポートしています。ただし、性能は低いかもしれません。

Q9: CiliumはどのようにしてIPアドレスを管理、割り当てているのでしょうか？他のCNIプラグインはIPアドレスプールを管理していますか？

A9: Ciliumには、IPアドレスを割り当てる2つの方法があります。ホストローカル：各ノードをセグメント化して、順次割り当てます。CRD-バックエンド：IPAMプラグインでIPアドレスを割り当てることができます。TerwayのCiliumは、ネットワークポリシーやサービスハイジャック、ロードバランシングを行うだけで、IPアドレスの割り当てや設定は行っていませんでした。

Q10: CiliumはBPFをpodのvethではなく、ホストのvethに注入しますか？何か変更を加えたのでしょうか？

A10: はい。Ciliumはpodのpeer vethを変更します。テストの結果，IPVLANのパフォーマンスはvethよりも優れていることがわかりました。Terwayでは、IPVLANを使用することで、peer vethを使用しない高性能なネットワークを実現しています。適応のための改造については、こちらのサイトをご覧ください。なお、TerwayではCiliumをNetworkPolicyとServiceのハイジャックとロードバランシングにのみ使用しています。

Q11：Terwayプラグインを使用した後、ポッドがサービスのクラスタIPアドレスにアクセスする方法を教えてください。

A11: ポッドのENIに組み込まれたeBPFプログラムは、サービスのIPアドレスをバックエンドのポッドにロードするために使用されます。

Q12：アリババクラウドのサービスメッシュの計画について教えてください。

A12：アリババクラウドでは、Alibaba Cloud Service Mesh（ASM）という製品を提供しています。その後の開発では、使いやすさ、パフォーマンス、グローバルクロスリージョンの統合されたクラウド、エッジ、ターミナルの接続に焦点を当てていきます。

Q13：ノードのネットワーク接続後にポッドのIPアドレスを再利用した場合、ARPキャッシュに影響はありますか？また、ノードレベルの障害が発生した場合、IPアドレスの競合は発生しますか？

A13: まず、クラウドネットワークにはARPの問題はありません。一般的にIaaSのレイヤーにはレイヤー3フォワーディングが採用されています。ローカルでIPVLANを使用していてもARP問題は発生しません。Macvlanを使用している場合、ARPキャッシュが影響を受けます。IPコンフリクトが発生するかどうかは、IP管理ポリシーによります。現在のTerwayのソリューションでは、IPAMが直接IaaS IPAMを呼び出すため、この問題はありません。ポッドネットワークをオフラインで自分で構築する場合は、この問題を回避するために、DHCP戦略または静的IPアドレスの割り当てを検討してください。

Q14: eBPFでリンクを簡略化したところ、iptablesに比べて31%、IPVSに比べて62%と大幅に性能が向上しました。IPVSに比べて性能向上が顕著なのはなぜでしょうか？主に線形マッチングとiptablesの更新最適化のためだとしたら？

A14：ここでの比較は、1つのサービスに基づいており、リンク簡素化の影響に関するものです。iptablesモードでは、DNATにはNATテーブルが使われ、フォワード処理のみが行われます。IPVSモードでは、入力と出力が関係します。したがって、単一のサービスの場合にはiptablesの方が良いかもしれません。しかし、iptablesの線形マッチングでは、多くのサービスが関係する場合には、大幅なパフォーマンスの低下を招きます。例えば、5,000個のサービスがある場合は、IPVSの方が優れています。

Q15: このネットワークソリューションを使用せず、大規模サービス利用がパフォーマンスに影響すると考えた場合、他に良いソリューションはありますか？

A15: kube-proxy IPVSモードでは、大規模サービス利用時のパフォーマンス低下は最小限に抑えられます。ただし、非常に長いリンクが導入されるため、レイテンシーが多少増加します。

著者について

XihengはAlibaba Cloudのテクニカルエキスパートであり、Alibaba CloudのオープンソースCNIプラグインTerwayプロジェクトのメンテナでもあります。また、Container Service for Kubernetes（ACK）のネットワーク設計とR&Dを担当しています。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ