当サイトのクッキーについて IBM のWeb サイトは正常に機能するためにいくつかの Cookie を必要とします(必須)。 このほか、サイト使用状況の分析、ユーザー・エクスペリエンスの向上、広告宣伝のために、お客様の同意を得て、その他の Cookie を使用することがあります。 詳細については、オプションをご確認ください。 IBMのWebサイトにアクセスすることにより、IBMのプライバシー・ステートメントに記載されているように情報を処理することに同意するものとします。 円滑なナビゲーションのため、お客様の Cookie 設定は、 ここに記載されている IBM Web ドメイン間で共有されます。
IBM Cloud Blog
分散クラウド vs. ハイブリッド・クラウド vs.マルチクラウド vs エッジ・コンピューティング (Part 2)
2020年10月22日
カテゴリー IBM Cloud Blog | IBM Cloud チュートリアル
記事をシェアする:
この投稿は、2020年10月14日に、米国 IBM Cloud Blog に掲載されたブログ(英語)の抄訳です。
このブログは、重要なクラウド・コンピューティングのアーキテクチャーを検証するシリーズ(2部構成)の第2部です。
前回(シリーズの第1部)のブログでは、以下の3つのクラウド・コンピューティング・アーキテクチャーを比較しました。
- ハイブリッド・クラウド
- マルチクラウド
- 分散クラウド
一般的に、これらの3つは、お客様がクラウド移行への足掛かりとなるものです。分散クラウドの持つ柔軟性と一貫性を活用することは、ハイブリッド・ラウドとマルチクラウド を利用する上で、ごく自然な歩みであると言えるでしょう。分散クラウドを構築することで、エッジの活用によるさらなる効率化を実現することができます。
次のステップ: エッジ・コンピューティング
エッジコンピューティング は、ハイブリッド・クラウドやマルチクラウド環境に適合するとともに、分散クラウド環境において強化されています。基本的に、エッジコンピューティングは、データが作られる場所の近くにあるサーバーを稼動するということを指します。
エッジコンピューティングを理解するために、データが作られるもととなる場所を検討してみましょう。データは主にクラウド(アプリケーションが運用ツールや分析ツールなどどともに実行されているクラウド)にありますが、実際のデータはユーザーがデバイスを操作することによって作られます。例えば、スマートフォンでアプリをクリックするといった簡単な操作を実行しているときに、データが作られています。
エッジ・コンピューティングについて、動画でもう少し詳しくみてみることにしましょう:
動画(10分39秒,日本語字幕版)を見る:
エッジ・デバイスとエッジ・サーバーの連携方法
エッジ・コンピューティングの推進により、エッジ・デバイスはすでに広く利用され、増加し続けています。その規模感を把握するために、ある配送会社の経営者が従業員と一緒に倉庫をいって、以下のようなデバイスを使用していることを考えてみましょう。
- 出荷機器のモニター
- カメラのモニター
- 携帯電話
こうしたエッジ・デバイスは、すべて、デジタルでアクセス可能なデータを収集しています。エッジ・デバイスは、エッジ・コンピューティング用に設計されたエッジ・サーバーとは異なります。この例では、エッジ・サーバーは倉庫にあり、エッジ・デバイスからデータを収集して処理します。
データをクラウドに転送して処理してからエッジ・デバイスに戻すかわりに、エッジ・サーバーを活用することにより、以下のようなメリットがあります:
- データが作成されたところでデータを計算処理できる
- 全体的に遅延時間を削減できる
- 分散処理が可能になる
こうした理由から、エッジ・コンピューティングは電気通信会社の多くの経営幹部にも注目されています。なぜなら、計算処理の多くは、携帯電話の中継等のように、エッジで行う必要があるからです。エッジデバイスからすべてのデータを生成する倉庫の例では、その倉庫内で実行されているエッジ・サーバーにKubernetesクラスターを設置できます。
エッジ・コンピューティングにおける分散クラウドの役割
複数の倉庫と数百万にも及ぶエッジ・デバイスを活用して、配送会社が急速にビジネスを拡大しているケースを考えてみましょう。それぞれの倉庫には、それぞれエッジ・サーバーがあります。これらのサーバーとデバイスを個別に運用保守するにはどうしたらよいでしょうか。運用管理にとってその業務は決して簡単なことではありません。特に、規模が大きくなるにつれ、個人所有あるいは個人管理のクラスターも設置されるようなケースはなおさらです。
分散クラウドを利用すると、単一のコントロール・プレーンで、KubernetesやRedHat OpenShiftなどのコンテナ・ベースのプラットフォーム間で、一貫性を保つことができるようになります。たとえば、エッジのVMホストなどのリソースを登録してから、一元化された運用環境を利用して、Kubernetesクラスターをオンデマンドで展開することができます。
エッジ・コンピューティングの場合にはこれは非常に助かります。インフラストラクチャーが複数の「エッジ」に「分散」している場合でも、増え続けるエッジ環境を単一のコントロール・プレーンから管理できます。倉庫に配置されているサーバーは、クラウドベースのKubernetesクラスターと同様に、一貫した運用を実現できます。
その一貫性が、分散クラウドをエッジ・コンピューティングに組み込む大きな理由です。もちろん、分散クラウドを使わないでもエッジ・コンピューティングを実行することはできますが、かなりのオーバーヘッドがかかるため、大きな代償を払うことになるでしょう。
分散クラウドは、エッジ・コンピューティングだけでなく、ハイブリッド・クラウド、マルチクラウド 、またその両方にも理想的な環境といえます。
このブログは、重要なクラウド・コンピューティングのアーキテクチャーを検証するブログシリーズの第2部です。シリーズの第1部もあわせてご活用いただけますと幸いです。
分散クラウドについて詳しくは
分散クラウドについてさらに詳しいことは、こちらもご参照いただけますと幸いです。
分散クラウドに対するご質問やご相談がございましたら、ぜひ公式サイト(こちら)からお寄せください。
翻訳:IBM Cloud Blog Japan 編集部
*このブログは、2020/10/14に発行された”IBM Cloud Blog “Distributed Cloud vs. Hybrid Cloud vs. Multicloud vs. Edge Computing (Part 2)”(英語)の抄訳です。
More IBM Cloud Blog stories
Red Hat OpenShift on IBM Cloudで OpenShift v4.4 をご利用いただけます
IBM Cloud News, IBM Cloud アップデート情報, IBM Cloud チュートリアル
この投稿は、2020年7月22日に、米国 IBM Cloud Announcementに掲載されたブログの抄訳です。 OpenShift v4.4には、多くのエキサイティングな新機能があります Red H ...続きを読む