ブルーグリーン/カナリアリリース向けの Argo ロールアウト

ブルーグリーン/カナリアリリース向けの Argo ロールアウト

[[410862]]

Argo Rollouts は、Kubernetes Operator 実装であり、ブルーグリーン、カナリア、カナリア分析、実験、プログレッシブ配信機能など、Kubernetes のより高度なデプロイメント機能を提供し、クラウドネイティブのアプリケーションとサービスに対して自動化された GitOps ベースのプログレッシブ配信を可能にします。

次の機能がサポートされています:

  • ブルーグリーンアップデート戦略
  • カナリアアップデート戦略
  • より細かく重み付けされたトラフィック分割
  • 自動ロールバック
  • 手動判断
  • カスタマイズ可能な指標クエリとビジネスKPI分析
  • イングレス コントローラの統合: NGINX、ALB
  • サービス メッシュ統合: Istio、Linkerd、SMI
  • メトリクス統合: Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs、Datadog、New Relic

実施原則

Deployment オブジェクトと同様に、Argo Rollouts コントローラーは、Deployment オブジェクトと同じポッド テンプレートを使用して、Rollout リソースの spec.template で定義された ReplicaSets の作成、スケーリング、および削除を管理します。

spec.template が変更されると、新しい ReplicaSet が導入されることが Argo Rollouts コントローラーに通知されます。コントローラーは、spec.strategy フィールドの戦略を使用して、古い ReplicaSet から新しい ReplicaSet へのロールアウトをどのように進めるかを決定します。この新しいレプリカセットがスケールアップされると (オプションで分析経由)、コントローラーはそれを安定しているとマークします。

spec.template を安定した ReplicaSet から新しい ReplicaSet に移行中に別の変更が発生した場合 (つまり、リリース中にアプリケーションのバージョンが変更された場合)、以前の新しい ReplicaSet は縮小され、コントローラーは更新された spec.template フィールドを反映した ReplicasSet をリリースしようとします。

関連概念

先に進む前に、いくつかの基本的な概念を理解しましょう。

ロールアウトする

Rollout は、Kubernetes Deployment オブジェクトと同等の Kubernetes CRD リソースです。より高度なデプロイメント機能またはプログレッシブ配信機能が必要な場合に、デプロイメント オブジェクトを置き換えることを目的としています。 Rollout は、Kubernetes Deployment では提供できない機能を提供します。

  • ブルーグリーンデプロイメント
  • カナリアデプロイメント
  • 高度なトラフィックルーティングのためにIngressコントローラとサービスメッシュを統合する
  • ブルーグリーン分析とカナリア分析のためのメトリクスプロバイダーとの統合
  • 成功または失敗の指標に基づいて自動的にリリースまたはロールバックする

プログレッシブデリバリー

プログレッシブ配信は、製品のアップデートを制御された段階的な方法でリリースするプロセスであり、これによりリリースのリスクが軽減され、多くの場合、自動化とメトリック分析を組み合わせて、アップデートの自動アップグレードまたはロールバックが実行されます。

プログレッシブ デリバリーは、継続的デリバリーの進化形として説明されることが多く、CI/CD のスピードの利点をデプロイメント プロセスに拡張します。新しいバージョンを一部のユーザーに限定し、正しい動作を観察および分析し、その正確性を継続的に検証しながら徐々にトラフィックを増やします。

展開戦略

業界ではさまざまな展開戦略を説明するために一貫した用語を使用していますが、これらの戦略の実装はツールごとに異なることがよくあります。 Argo Rollouts の動作を明確にするために、以下では Argo Rollouts が提供するさまざまなデプロイメント戦略の実装について説明します。

  • RollingUpdate: 古いバージョンを新しいバージョンに徐々に置き換えます。新しいバージョンが登場すると、アプリケーションの総数を維持するために、古いバージョンは徐々に縮小されます。これはデプロイメント オブジェクトのデフォルトの戦略です。
  • 再作成: 再作成では、新しいバージョンを起動する前にアプリケーションの古いバージョンを削除します。これにより、アプリケーションの 2 つのバージョンが同時に実行されることはありませんが、デプロイメント中にダウンタイムが発生します。
  • ブルーグリーン: ブルーグリーン リリース (レッドブラックと呼ばれることもあります) は、アプリケーションの古いバージョンと新しいバージョンの両方が同時にデプロイされ、その間、アプリケーションの古いバージョンのみが実稼働トラフィックを受信するリリースです。これにより、開発者はライブ トラフィックを新しいバージョンに切り替える前に、そのバージョンに対してテストを行うことができます。

  • カナリア: カナリア リリースとは、一部のユーザーにアプリケーションの新しいバージョンを公開し、残りのトラフィックを古いバージョンに提供することを指します。新しいバージョンが正しいことが検証されると、新しいバージョンが徐々に古いバージョンに置き換えられます。 NGINX Ingress や Istio などの Ingress コントローラーとサービス メッシュにより、カナリアのトラフィック分割パターンがネイティブのものよりも複雑になる可能性があります (たとえば、非常にきめ細かいトラフィック分割を実装したり、HTTP ヘッダーに基づいて分割したりするなど)。

上記は、2 つのステージ (トラフィックの 10% と 33% が新しいバージョンに送られる) を持つカナリアを示しています。 Argo Rollouts を使用すると、実際の使用状況に基づいてステージ数とトラフィックの割合を正確に定義できます。

シナリオ

  1. ユーザーは、新しいバージョンが本番環境で提供される前に、その機能の最終テストを実行したいと考えています。 Argo Rollouts では、BlueGreen ポリシーを通じて、ユーザーがプレビュー サービスとアクティブ サービスを指定できるようになります。ロールアウトでは、プレビュー サービスが新しいバージョンにトラフィックを送信するように構成され、アクティブ サービスは引き続き本番トラフィックを受信します。要件が満たされると、プレビュー サービスを新しいライブ サービスに昇格できます。
  2. 新しいバージョンがライブ トラフィックの受信を開始する前に、共通の一連の手順を事前に実行する必要があります。 BlueGreen ポリシーを使用すると、ユーザーはアクティブなサービスからのトラフィックを受信せずに新しいバージョンを起動できます。これらの手順が完了すると、トラフィックを新しいバージョンに切り替えることができます。
  3. ユーザーは、数時間以内に本番トラフィックのごく一部をアプリケーションの新しいバージョンに提供したいと考えています。その後、新しいバージョンをスケールダウンし、いくつかのメトリックを確認して、新しいバージョンが古いバージョンと比較してパフォーマンスの問題があるかどうかを判断し、新しいバージョンに切り替えるかどうかを決定します。カナリア戦略を使用すると、ロールアウトは新しいバージョンのレプリカセットをスケールアップして、指定された割合のトラフィックを受信し、指定された時間待機してから割合を 0 に戻し、ユーザーが満足するまで待ってから、すべてのトラフィックを処理するために再度リリースすることができます。
  4. ユーザーは、まずライブ トラフィックの一部を新しいバージョンに割り当て、しばらく待ってから新しいバージョンにさらに多くのトラフィックを割り当てることで、新しいバージョンへの実稼働トラフィックを徐々に増やしたいと考えています。最終的には、新しいバージョンがすべての本番トラフィックを受信することになります。カナリア戦略では、ユーザーは新しいバージョンに与えたい割合と、割合間の待機時間を指定します。
  5. ユーザーは、デプロイメントで通常のローリング アップデート戦略を使用したいと考えています。ユーザーが手順なしでカナリア戦略を使用する場合、ロールアウトでは maxSurge と最大非可用性値を使用して新しいバージョンにロールアウトします。

建築

以下は、Argo Rollouts によって管理されるデプロイメントのすべてのコンポーネントを示しています。

Argoロールアウトアーキテクチャ

ロールアウトコントローラ

これは、クラスターのイベントを監視し、ロールアウト タイプのリソースが変更されたときに反応するメイン コントローラーです。コントローラーはロールアウトのすべての詳細を読み取り、クラスターをロールアウト定義で説明されているのと同じ状態にします。

Argo Rollouts は、通常のデプロイメント リソースに加えられた変更を改ざんしたり、それに応答したりしないことに注意してください。つまり、他の方法を使用してアプリケーションをデプロイするクラスターに Argo Rollouts をインストールできます。

ロールアウトリソース

Rollout リソースは、Argo Rollouts によって導入および管理されるカスタム Kubernetes リソースです。基本的にはネイティブの Kubernetes Deployment リソースと互換性がありますが、カナリアやブルー/グリーン デプロイメントなどのより高度なデプロイメント方法を制御するための追加フィールドがあります。

Argo Rollouts コントローラーは、Rollout リソースの変更にのみ反応し、通常の Deployment リソースに対しては何も行いません。そのため、Argo Rollouts を使用して Deployment を管理する場合は、Deployment を Rollouts に移行する必要があります。

古いレプリカセットと新しいレプリカセット

これらは標準の Kubernetes ReplicaSet リソースのインスタンスであり、Argo Rollouts はアプリケーションに属するさまざまなバージョンを追跡するために、追加のメタデータを追加します。

また、ロールアウトに参加しているレプリカセットはコントローラーによって完全に自動的に管理されるため、外部ツールで改ざんしてはならないことにも注意してください。

イングレス/サービス

ユーザー トラフィックがクラスターに入ると、適切なバージョンにリダイレクトされます。 Argo Rollouts は標準の Kubernetes サービス リソースを使用しますが、いくつかの追加のメタデータを使用します。

Argo Rollouts はネットワーク構成において非常に柔軟です。まず、ロールアウト中にさまざまなサービスを使用できます。これは、新しいバージョンのみ、古いバージョンのみ、または両方に適用できます。特に Canary デプロイメントの場合、Argo Rollouts は、ポッドの数に基づく単純な構成ではなく、特定の割合でトラフィックを分割するための複数のサービス メッシュおよび Ingress ソリューションをサポートします。

分析と分析実行

分析は、ロールアウトをメトリック プロバイダーに接続し、ロールアウトが成功したかどうかを判断する特定のメトリックの特定のしきい値を定義するカスタム Kubernetes リソースです。分析ごとに、1 つ以上のインジケーター クエリとその予想される結果を定義できます。インジケータクエリが正常であれば、ロールアウトは引き続き動作します。インジケータが失敗を示した場合、自動的にロールバックされます。インジケータが成功/失敗の回答を提供できない場合、リリースは中断されます。

分析は、クエリするメトリックの単なるテンプレートです。ロールアウトに添付された実際の結果は AnalysisRun カスタム リソースであり、特定のロールアウトで分析を定義したり、クラスター上でグローバルに分析を定義して複数のロールアウトで共有したりできます。

ロールアウトでの分析とメトリックの使用は完全にオプションであり、API または CLI を介して手動でリリースを一時停止および促進したり、他の外部メソッド (スモーク テストなど) を使用したりできます。 Argo Rollouts のメトリクス ソリューションのみを使用する必要はなく、ロールアウトで自動 (分析ベース) のステップと手動のステップを組み合わせることもできます。

メトリックに加えて、Kubernetes ジョブを実行したり、Webhook を実行したりして、リリースの成功を判断することもできます。

メトリックプロバイダー

Argo Rollouts には、リリースを自動的に昇格またはロールバックするために分析リソースで使用できる、いくつかの一般的なメトリック プロバイダーとのネイティブ統合が含まれています。

CLI と UI (図示せず)

ロールアウトは、Argo Rollouts CLI または統合 UI を使用して表示および管理することもできます (どちらもオプション)。

インストール

次のコマンドを使用して Argo Rollouts をインストールするだけです。

  1.  ➜ ~ kubectl名前空間 argo-rolloutsを作成します
  2. ➜ ~ kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/download/v1.0.2/install.yaml

ここで argo-rollouts という名前空間が作成され、その下で Argo Rollouts コントローラーが実行されます。

  1.  ➜ ~ kubectl get pods -n argo-rollouts
  2. 名前準備完了 ステータス 再起動 年齢
  3. argo-rollouts-6fdcf89f7c-7z2mh 1/1 実行中 0 58秒

さらに、コマンドライン管理とビジュアルリリースに非常に便利な kubectl プラグインをインストールすることもできます。

私たちは Mac を使用しているので、次のコマンドを使用して直接インストールできます。

  1.  ➜ ~ brew install argoproj/tap/kubectl-argo-rollouts

もちろん手動でインストールすることもできます。 curl を使用して Argo Rollouts kubectl プラグインをインストールします。

  1.  ➜ ~curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.0.2/kubectl-argo-rollouts-darwin-amd64

次に、kubectl-argo-rollouts バイナリ実行権限を付与します。

  1.  ➜ ~ chmod +x ./kubectl-argo-rollouts-darwin-amd64

バイナリを PATH に移動します。

  1.  ➜ ~ sudo mv ./kubectl-argo-rollouts-darwin-amd64 /usr/ local /bin/kubectl-argo-rollouts

プラグインが正常にインストールされたことを確認するには、次のコマンドを実行します。

  1.  ➜ ~ kubectl argo ロールアウト バージョン
  2. kubectl-argo-rollouts: v1.0.2+7a23fe5
  3.   ビルド日: 2021-06-15T19:36:10Z
  4.   GitCommit: 7a23fe5dbf78181248c48af8e5224246434e7f99
  5.   GitTreeState: クリーン
  6.   Goバージョン: go1.16.3
  7.   コンパイラ: gc
  8.   プラットフォーム: darwin/amd64

使用

次に、いくつかの簡単な例を使用して、Rollout の展開、アップグレード、リリース、中断を説明し、Rollout のさまざまな機能を紹介します。

1. ロールアウトを展開する

まず、ロールアウト リソースとリソース用の Kubernetes サービス オブジェクトをデプロイします。この例のロールアウトでは、カナリア更新戦略を採用し、トラフィックの 20% をカナリアに送信し、その後手動で解放し、最後にアップグレードの残りの時間中にトラフィックを徐々に自動的に増加させます。この戦略は、次のロールアウトで説明できます。

  1.  # 基本的なロールアウト.yaml
  2.  apiバージョン: argoproj.io/v1alpha1
  3. 種類: ロールアウト
  4. メタデータ:
  5. 名前: ロールアウトデモ
  6. 仕様:
  7.   replicas: 5 # 5つのレプリカを定義する
  8.   戦略: #アップグレード戦略を定義する
  9.     canary: # カナリアリリース
  10.       ステップ: # リズムをリリース
  11.       - 重みを設定: 20
  12.       - pause: {} # 常に一時停止します
  13.       - 重みを設定: 40
  14.       - 一時停止: {期間: 10}
  15.       - 重みを設定: 60
  16.       - 一時停止: {期間: 10}
  17.       - 重みの設定: 80
  18.       - 一時停止: {期間: 10}
  19.   リビジョンヒストリー制限: 2 # 次の部分は実際にはデプロイメントと互換性があります
  20.   セレクタ：
  21.     一致ラベル:
  22.       アプリ: ロールアウトデモ
  23.   テンプレート：
  24.     メタデータ:
  25.       ラベル:
  26.         アプリ: ロールアウトデモ
  27.     仕様:
  28.       コンテナ:
  29.       -名前: ロールアウトデモ
  30.         画像: argoproj/rollouts-demo:blue
  31.         ポート:
  32.         -名前: http
  33.           コンテナポート: 8080
  34.           プロトコル: TCP
  35.         リソース：
  36.           リクエスト:
  37.             メモリ: 32Mi
  38.             CPU: 5m

以下に示すように、サービス リソース オブジェクトも含まれます。

  1.  # 基本サービス.yaml
  2.  APIバージョン: v1
  3. 種類: サービス
  4. メタデータ:
  5. 名前: ロールアウトデモ
  6. 仕様:
  7.   ポート:
  8.   - ポート: 80
  9.     ターゲットポート: http
  10.     プロトコル: TCP
  11. 名前: http
  12.   セレクタ：
  13.     アプリ: ロールアウトデモ

上記の 2 つのリソース オブジェクトを直接作成します。

  1.  ➜ ~ kubectl apply -f basic-rollout.yaml
  2.  ➜ ~ kubectl apply -f 基本サービス.yaml

ロールアウトの最初の作成では、アップグレードがまだ行われていないため、レプリカがすぐに 100% にスケーリングされます (カナリア アップグレードの手順、分析などはスキップされます)。

Argo Rollouts kubectl プラグインを使用すると、Rollout と関連リソース オブジェクトを視覚化し、リアルタイムのステータスの変化を表示できます。デプロイメント プロセス中にロールアウトを監視するには、プラグインの get rollout --watch コマンドを実行します。次に例を示します。

  1.  ➜ ~ kubectl argo rollouts get rollouts-demo --watch  

2. アップデートのロールアウト

展開が完了しました。次に、更新する必要があります。デプロイメントと同様に、Pod テンプレート フィールドに変更を加えると、新しいバージョン (ReplicaSet) がデプロイされます。ロールアウトを更新するには、通常、コンテナ イメージのバージョンを変更してから、kubectl apply を実行する必要があります。利便性のために、ロールアウト プラグインは別の set image コマンドも提供します。たとえば、ここでは次のコマンドを実行して、上記のロールアウトをコンテナの黄色バージョンで更新します。

  1.  ➜ ~ kubectl argo rollouts set image rollouts-demo \
  2.   ロールアウトデモ=argoproj/ロールアウトデモ:黄色

ロールアウト更新中、コントローラはロールアウト更新戦略で定義された手順を実行します。この例のロールアウトでは、カナリアに 20% のトラフィック ウェイトを設定し、ユーザーがリリースをキャンセルまたは昇格するまでロールアウトを一時停止します。画像を更新した後、一時停止状態になるまでロールアウトを再度確認します。

  1.  ➜ ~ kubectl argo rollouts get rollouts-demo --watch  

デモ ロールアウトが 2 番目のステップに到達すると、ロールアウトが一時停止され、5 つのレプリカのうち 1 つがポッドの新しいバージョンを実行しているのに対し、残りの 4 つは古いバージョンをまだ実行していることがプラグインからわかります。これは、setWeight: 20 ステップで定義された 20% のカナリア ウェイトに相当します。

3. ロールアウトを促進する

上記の更新後、ロールアウトは一時停止状態になり、ロールアウトが期間のない一時停止ステップに達すると、再開/昇格されるまで一時停止状態のままになります。ロールアウトを手動で次のステップに切り替えるには、プラグインのプロモーション コマンドを実行します。

  1.  ➜ ~ kubectl argo ロールアウト プロモーション ロールアウト デモ

切り替え後、Rollout は残りの手順を引き続き実行します。私たちの場合、残りの手順は完全に自動化されているため、Rollout は最終的に新しいバージョンに完全に移行するまで手順を完了します。すべてのステップが完了するまで、ロールアウトを再度監視します。

  1.  ➜ ~ kubectl argo rollouts get rollouts-demo --watch  

  • prove コマンドは、残りのすべてのステップと分析をスキップする --full フラグもサポートしています。

安定バージョンが ReplicaSet リビジョン:2 に切り替わったことがわかります。カナリア分析の失敗によって自動的に、またはユーザーによって手動で更新が中止された場合、Rollout は安定バージョンにフォールバックします。

4. 割り込みロールアウト

次に、更新中にロールアウトを手動で中止する方法を学びましょう。まず、set image コマンドを使用してコンテナの新しい red バージョンをデプロイし、ロールアウトが再び一時停止ステップに到達するまで待機します。

  1.  ➜ ~ kubectl argo rollouts set image rollouts-demo \
  2.   ロールアウトデモ=argoproj/ロールアウトデモ:red

今回は、ロールアウトを次のステップに切り替えるのではなく、更新を中止して安定バージョンに戻します。プラグインには、更新プロセス中にいつでもロールアウトを手動で中止するための中止コマンドも用意されています。

  1.  ➜ ~ kubectl argo ロールアウトを中止する ロールアウトデモ

ロールが中止されると、レプリカセットの安定バージョン (この場合は黄色のバージョン) がスケールアップされ、他のバージョンはスケールダウンされます。レプリカセットの安定バージョンが実行中で正常であっても、期待されるバージョン (赤色のバージョン) が実際に実行されているバージョンではないため、ロールアウト全体は依然として劣化していると見なされます。


Rollout が壊れたバージョンではなく再び正常なバージョンと見なされるためには、目的の状態を以前の安定したバージョンに戻す必要があります。この場合は、以前の黄色のイメージを使用して、set image コマンドを再実行するだけです。

  1.  ➜ ~ kubectl argo rollouts set image rollouts-demo \
  2.   ロールアウトデモ=argoproj/ロールアウトデモ:黄色

このコマンドを実行すると、ロールアウトがすぐに正常になり、新しいレプリカセットを作成するアクティビティがないことがわかります。

ロールアウトがまだ期待された状態に達していない場合 (中止された、または更新中だったなど)、リソース マニフェストの安定したバージョンが再適用されると、ロールアウトはこれが更新ではなくロールバックであることを検出し、分析と手順をスキップして安定したレプリカセットをすぐにデプロイします。

上記の例のロールアウトでは、トラフィックを制御するために Ingress コントローラまたはサービス メッシュは使用されません。代わりに、通常の Kubernetes サービスを使用して、新しいレプリカと古いレプリカの数の比率に基づいて、おおよそのカナリア ウェイトを実装します。したがって、このロールアウトには、5 つのポッドのうち 1 つをスケーリングして新しいバージョンを実行することによって、最小の重みを 20% しか達成できないという制限があります。よりきめ細かいカナリアを実装するには、Ingress コントローラーまたはサービス メッシュが必要です。これについては、サービス メッシュの以降の学習で紹介します。

ダッシュボード

Argo Rollouts Kubectl プラグインは、ロールアウトを視覚化するためのローカル ダッシュボードを提供します。

ダッシュボードを起動するには、Rollouts リソース オブジェクトを含む名前空間で kubectl argo rollouts dashboard コマンドを実行し、localhost:3100 にアクセスします。

「ロールアウト」をクリックすると詳細ページに移動し、ロールアウトの構成情報を確認したり、再起動、リブート、中断などの一般的な操作を UI インターフェイスで直接実行したりできます。

<<:  フォレスターの最新データフロー分析レポート：アリババクラウドが強力なパフォーマンスを発揮する企業として選出

>>:  Springboot2.x AOPはキャッシュロックと分散ロックを実装します

推薦する

誰もが悲観的だったクラウドコンピューティングがなぜ復活したのか？それは「貧しい人々」のために発明されたからです

2020 年、AWS の年間収益は 450 億米ドルを超え、収益成長と営業利益率は 30% を超えま...

vpsace-2g メモリ/100g ハードディスク (SSD キャッシュ)/2T トラフィック/月額 7 ドル

vpsace は 2011 年に設立されました。サーバーの構成は、Intel Xeon E3-124...

SEOポータルサイトの道を歩む初心者ウェブマスター向けに書かれた記事

過去数年間を振り返ると、苦味、無力感、興奮に満ちていました。人々は落ち込み、途方に暮れましたが、同時...

百度は独創性に注意を払うべきだと言っている

百度の最近の動向は誰もが知っています。インターネットの将来において、百度は独創性にもっと注意を払うで...

クラウド データ ウェアハウス Snowflake、Panoply、Repods の包括的な比較

【51CTO.com クイック翻訳】はじめにSnowflake、Panoply、Repods は、管...

trentahost-49 USD/E3-1230/32 GB RAM/500 GB HDD/10 TB フロー/IPMI/ポートランド

Trentahostは2009年に事業を開始し、ドメイン名、仮想ホスティング（配信を含む）、ゲームホ...

#11.11# arkecx: クラウド サーバー $11.11/年、1G メモリ/1 コア/25g SSD/1T トラフィック/1G 帯域幅、香港、日本、韓国、シンガポール、マレーシア、タイ、ベトナム、フィリピンなどに 28 のデータ センター。

Zenlayer 傘下のクラウド サーバー ブランドである Arkecx では、毎年恒例のダブル 1...

トップレベルのウェブサイト外部リンクを作成する方法（パート 1）

ウェブサイトの外部リンクを構築することは、SEO 最適化に必要なタスクの 1 つです。ウェブマスター...

ユーザーの検索行動とキーワード分析（パート3）

2 番目の記事では、ロングテールキーワードの方がコンバージョン率が高いことをようやく説明しました。し...

ローカルポータル：10年間の努力を経て、O2Oの責任を引き受けることができるか？

東洋の文化は非常に独特で、すべての中国人は故郷を愛する心を持っています。私たちはどこにいても、いつも...

非採用広告が地元の人材ネットワークで重要な位置を占めている

従来の人材紹介サイトには広告が溢れています。経営者は、自社の成長に貢献できる人材を採用するために多額...

alphavps: (ブルガリア) 大容量ハードディスクを備えた安価な VPS。バックアップデータの保存に最適

安価な大容量ハードドライブ VPS 業者 alphavps をお勧めします。2003 年に設立された...

亥年には、エッジコンピューティングとモノのインターネットが大きな注目を集めると聞きました。

エッジ コンピューティングは、インテリジェントな相互接続サービスをローカルに提供し、デジタル変革プロ...

Woquブランドが経験を共有し、Woquアパートメントの成功した製品デザインの秘密を明らかにする

2018年最もホットなプロジェクト：テレマーケティングロボットがあなたの参加を待っていますWoquブ...

【2017年最新版】モバイルインターネット業界の専門用語を完全網羅！

StarNet の以前の生徒からのフィードバックに基づいて、同様によく使用される単語をいくつか追加し...