バックエンド テクノロジーを 5 分で学ぶ: 1 つの記事でクラウド コンピューティングとは何かを説明します。

クラウドコンピューティングとは

すでに 10 年前には、クラウド コンピューティング関連の職種が市場に数多く登場していました。当時はクラウドコンピューティング技術が最も注目されていた時期でした。 BATやHuaweiなどの企業がクラウドコンピューティングを導入し始めたため、OpenStackの研究開発、コンテナの研究開発、基盤開発などの関連職種もそれに応じて増加しました。近年、ビッグデータと AI がクラウド コンピューティングを完全に凌駕していますが、このテクノロジーは今日のテクノロジー システムにおいて依然として非常に重要な位置を占めています。では、クラウド コンピューティングとは一体何でしょうか? Baidu 百科事典の紹介によると、これはクラウド コンピューティング技術を学びたい人全員が理解する必要があることです。

IT 業界の用語であるビッグデータとは、従来のソフトウェア ツールでは一定の時間内に収集、管理、処理できないデータの集合を指します。これは、より強力な意思決定力、洞察の発見、およびプロセス最適化機能を備えた新しい処理モデルを必要とする、大規模で急成長している多様な情報資産です。 Viktor Mayer-SchönbergerとKenneth Cukierによるビッグデータ[1]では、ビッグデータとは、ランダム分析（サンプリング調査）などの近道をとらずに、すべてのデータを分析および処理に使用することを意味します。ビッグデータの 5V 特性 (IBM が提唱): 量、速度、多様性、価値、真実性。 [2]

[[359554]]

クラウドコンピューティングの歴史

物理マシン時代

クラウド コンピューティングのプロセス全体は、「長期にわたる分離は最終的に再結合につながり、長期にわたる再結合は最終的に分離につながる」という 1 つの言葉で説明できます。

クラウド コンピューティングは、実際には主にコンピューティング、ネットワーク、ストレージ、アプリケーションの 4 つの側面を解決します。最初の 3 つはリソース レベルであり、最後の 1 つはアプリケーション レベルです。

コンピューティングは CPU とメモリです。なぜでしょうか?最も単純なアルゴリズム 1+1 は、1 をメモリに格納し、CPU が加算を実行するというものです。加算が完了すると、結果 2 が再びメモリに保存されます。インターネットとは、イーサネット ケーブルを接続するだけでインターネットにアクセスできるものです。ストレージとは、次の映画を保存する場所があることを意味します。この議論では、これら 4 つの部分に焦点を当てます。原始社会では、人々が好んで使っていたデバイスは物理的なデバイスでした。

サーバーは、Dell、HP、IBM、Lenovo などの物理マシンやその他の物理サーバーです。ハードウェア機器の進歩により、物理サーバーはますます強力になっています。 64 コアと 128G メモリが一般的な構成と考えられています。ネットワークには、Cisco や Huawei などのハードウェア スイッチやルーターが使用され、1GE から 10GE まで、現在では 40GE や 100GE もあり、帯域幅はますます高くなっています。ストレージに関しては、通常のディスクを使用するものもあれば、より高速な SSD ディスクを使用するものもあります。容量は M から G までの範囲で、ディスク アレイはもちろん、ラップトップでも T まで構成できます。アプリケーションを物理マシンに直接デプロイすると、見た目もクールで贅沢な気分にもなるかもしれませんが、次のような大きな欠点があります。

手動操作とメンテナンス: サーバーにソフトウェアをインストールしても、システムが正しくインストールされない場合はどうなるでしょうか?再インストールのみ。スイッチのパラメータを設定する場合は、シリアル ポートを介してスイッチに接続して設定する必要があります。ディスクを追加する場合は、必ずディスクを購入してサーバーに接続する必要があります。これらはすべて手動で行う必要があり、おそらくコンピューター ルームが必要になります。あなたの会社は北五環路にあり、コンピュータ室は南六環路にあります。酸っぱいですね。リソースの無駄: 実際には、小さな Web サイトを展開したいだけなのに、128G のメモリを使用する必要があります。一緒に展開すると、分離の問題が発生します。分離が不十分: 同じ物理マシンに多数のアプリケーションを展開すると、メモリと CPU をめぐって競合が発生します。片方のハードドライブがいっぱいになると、もう一方は使用できなくなります。片方がカーネルをクラッシュさせると、もう一方も同時にクラッシュします。同一のアプリケーションを 2 つ展開すると、ポートが競合し、エラーが発生しやすくなります。そこで、仮想化と呼ばれる長期的な統合と分離の最初のプロセスが生まれました。いわゆる仮想化とは、現実を仮想に変えることです。

[[359555]]

仮想マシンの誕生

物理マシンは仮想マシンになります。CPU は仮想であり、メモリは仮想であり、カーネルは仮想であり、ハードディスクは仮想です。物理スイッチは仮想スイッチになります。ネットワーク カードは仮想であり、スイッチは仮想であり、帯域幅も仮想です。物理ストレージが仮想ストレージになります。複数のハードディスクが 1 つの大きなストレージに仮想化されます。仮想化は上記の 3 つの問題を非常にうまく解決します。

手動操作とメンテナンス: 仮想マシンの作成と削除はリモートで操作できます。仮想マシンが破損した場合、数分で削除して再構築できます。仮想ネットワークの構成もリモートで操作できます。ネットワーク カードの作成と帯域幅の割り当てはすべて、インターフェイスを呼び出すことによって実行できます。リソースの無駄: 仮想化後、リソースを非常に小さく割り当てることができます。たとえば、1 つの CPU、1 G のメモリ、1 M の帯域幅、1 G のハードディスクをすべて仮想化できます。分離が不十分: 各仮想マシンには独立した CPU、メモリ、ハードディスク、ネットワーク カードがあり、異なる仮想マシン内のアプリケーションは互いに干渉しません。ただし、仮想化には次のような欠点があります。仮想化ソフトウェアを使用して仮想マシンを作成する場合、仮想マシンを配置するマシン、ハードディスクを配置するストレージ デバイス、ネットワークの VLAN ID、特定の帯域幅構成をすべて手動で指定する必要があります。そのため、仮想化のみを使用する運用および保守エンジニアは、マシンの数と各マシンにどの仮想マシンが展開されているかを示す Excel スプレッドシートを持っていることがよくあります。したがって、仮想化クラスターの数は、一般的にそれほど多くありません。

仮想化の段階では、基本的なコンピューティング、ネットワーク、ストレージの仮想化を実現できる VMware がリーダーです。

もちろん、この世界にはクローズド ソースとオープン ソースがあり、Windows と Linux、Apple と Andord、VMware、Xen、KVM が存在します。オープンソースの仮想化に関しては、Citrix が Xen で優れた成果を上げ、その後 Redhat が KVM に多大な努力を払いました。

ネットワーク仮想化には Openvswitch があり、コマンドを使用してブリッジやネットワーク カードを作成したり、VLAN を設定したり、帯域幅を設定したりできます。

ストレージ仮想化では、ローカル ディスク用に LVM があり、複数のハード ディスクを 1 つの大きなディスクに変換し、その一部をユーザー用に切り取ることができます。

仮想化段階で残された問題を解決するために、分離と再統合のプロセスが開始されました。これを比喩的にプロセス プーリングと呼ぶことができます。これは、仮想化によってリソースが非常に細かいカテゴリに分割されていることを意味します。しかし、このような細かいリソースを Excel で管理するにはコストがかかりすぎます。ユーザーがリソースを指定する代わりに、必要なときに自動的に選択できるようにするための大きなプールを作成できますか?このステージの重要なポイントは、スケジューラです。

[[359556]]

パブリッククラウドとプライベートクラウド

つまり、VMware には独自の vcloud があります。

そこで、Xen と KVM をベースにしたプライベート クラウド プラットフォームである CloudStack は、後に Citrix に買収され、オープンソース化されました。

これらのプライベートクラウドプラットフォームがユーザーのデータセンターで非常に高い価格で販売され、多額の利益を上げます。 AWSやGoogleなど他の企業も他の選択肢を提供し始めており、パブリッククラウド分野への進出を模索し始めています。

AWS はもともと Xen テクノロジーに基づいて仮想化され、最終的にパブリック クラウド プラットフォームを形成しました。おそらく AWS は当初、自社の e コマース収益のすべてをプライベート クラウド ベンダーに渡すことを望まなかったため、まずは自社のクラウド プラットフォームで自社のビジネスをサポートしたのでしょう。このプロセスで、AWS は自社のクラウド コンピューティング プラットフォームを真剣に活用し、パブリック クラウド プラットフォームをリソース構成に優しいものにするのではなく、アプリケーションの展開に優しいものにし、最終的に成功を収めました。

よく見ると、プライベート クラウドとパブリック クラウドは類似のテクノロジを使用していますが、製品設計の点ではまったく異なるものであることがわかります。プライベートクラウドベンダーとパブリッククラウドベンダーも同様の技術を持っていますが、製品の運用においてはまったく異なる遺伝子を持っています。

プライベート クラウド ベンダーはすべてリソースを販売しているため、プライベート クラウド プラットフォームを販売する場合は、コンピューティング、ネットワーク、ストレージ デバイスも販売することがよくあります。プライベート クラウド ベンダーは、製品設計において、顧客がほとんど使用しないコンピューティング、ネットワーク、ストレージの技術的パラメータを長く詳細に強調することがよくあります。これは、これらのパラメータを使用して競合他社とのベンチマーク プロセスで優位に立つことができるためです。プライベートクラウドベンダーは自社で大規模なアプリケーションを保有することはほとんどないため、自社が構築するプラットフォームは他社が使用するためのものであり、自社で大規模に使用することはありません。その結果、それらの製品はリソースを中心に展開されることが多く、アプリケーションの展開には適していません。

パブリック クラウド ベンダーは、独自の大規模なアプリケーションを展開する必要があることが多いため、その製品設計では、一般的なアプリケーションの展開に必要なモジュールをコンポーネントとして提供できます。ユーザーは、ビルディングブロックのように、独自のアプリケーションに適したアーキテクチャを組み立てることができます。パブリック クラウド ベンダーは、オープン ソースであるかどうか、さまざまな仮想化プラットフォーム、さまざまなサーバー デバイス、ネットワーク デバイス、ストレージ デバイスと互換性があるかどうかなど、さまざまな技術パラメータの比較について心配する必要はありません。顧客がアプリケーションを展開するのに便利である限り、私が何を使用するかはあなたには関係ありません。

OpenStackの誕生

もちろん、パブリッククラウド企業第1位のAWSは好調だが、第2位のRackspaceはそれほど好調ではない。そうです、インターネット業界では、基本的に市場を独占している企業は 1 社だけです。 2位はどうやって復活できるのか？オープンソースは、業界全体がこのクラウド プラットフォーム上で連携するための優れた方法です。兄弟よ、一緒にやりましょう。そこで、Rackspace は NASA と協力してオープンソースのクラウド プラットフォーム OpenStack を作成しました。 OpenStackは現在AWSと似たような発展を遂げており、OpenStackのモジュール構成からはクラウドコンピューティングのプーリング方式が見て取れます。

OpenStack にはどのようなコンポーネントが含まれていますか?

コンピューティング プーリング モジュール Nova: OpenStack のコンピューティング仮想化では主に KVM が使用されますが、仮想マシンを起動するためにどの物理マシンを使用するかは nova-scheduler によって異なります。

ネットワーク プーリング モジュール Neutron: OpenStack のネットワーク仮想化では主に Openvswitch が使用されます。ただし、Openvswitch の仮想ネットワーク、仮想ネットワーク カード、VLAN、帯域幅の各構成については、クラスターにログインして構成する必要はありません。 Neutron は SDN を通じて構成できます。

ストレージ プーリング モジュール Cinder: OpenStack のストレージ仮想化。ローカル ディスクを使用する場合は、LVM に基づきます。 LVM に割り当てられたディスクはスケジューラによっても使用されます。その後、複数のマシンのハードディスクをプールするために Ceph が開発されました。スケジューリングプロセスは Ceph レイヤーで完了しました。

OpenStack の登場により、すべてのプライベート クラウド ベンダーが熱狂しました。 VMware はプライベート クラウド市場であまりにも多くの利益を上げており、それに対抗できる対応するプラットフォームがなかったため、彼らはただ黙って見守ることしかできなかったことが判明しました。既成のフレームワークと独自のハードウェア機器が存在する今、想像できるすべての IT 大手がコミュニティに参加し、OpenStack を自社製品として開発し、ハードウェア機器とともにプライベート クラウド市場に参入しています。

NetEase はこの機会を逃すことなく、独自の OpenStack クラスターを立ち上げました。 NetEase Hive は OpenStack をベースに独自に IaaS サービスを開発しました。コンピューティング仮想化の面では、KVM イメージのカスタマイズや仮想マシンの起動プロセスの最適化などの改善により、数秒で仮想マシンを起動できるようになりました。ネットワーク仮想化に関しては、SDN と Openvswitch テクノロジーにより、仮想マシン間の高性能な相互アクセスが実現されます。ストレージ仮想化に関しては、Ceph ストレージを最適化することで高性能なクラウド ディスクを実現します。

しかし、NetEase はプライベート クラウド市場に急いで参入することはなく、代わりに OpenStack を使用して独自のアプリケーションをサポートしました。そうです、これがインターネットの考え方です。リソースレベルの弾力性だけでは不十分です。アプリケーションの展開に適したコンポーネントを開発することも必要です。例えば、データベース、負荷分散、キャッシュなど、これらはすべてアプリケーションの展開に不可欠であり、大規模アプリケーションの実践を通じて磨かれたNetEaseの製品でもあります。これらのコンポーネントは PaaS と呼ばれます。

[[359557]]

IAASからPAASへ

これまで、IaaS レイヤー (Infrastructure as a Service) について、基本的にはコンピューティング、ネットワーク、ストレージについてお話ししてきました。ここで、アプリケーション層について説明します。

IaaS の定義は比較的明確ですが、PaaS の定義はそれほど明確ではありません。データベース、負荷分散、キャッシュを PaaS サービスと見なす人もいれば、ビッグデータの Hadoop や Spark プラットフォームを PaaS サービスと見なす人もいます。また、Puppet、Chef、Ansible などのアプリケーションのインストールと管理を PaaS サービスと見なす人もいます。

実際、PaaS は主にアプリケーション層を管理するために使用されます。私はそれを 2 つの部分にまとめます。1 つは、Puppet、Chef、Ansible、Cloud Foundry など、スクリプトを通じてデプロイできる独自のアプリケーションを自動的にデプロイする必要があるという部分です。もう 1 つは、データベース、キャッシュ、ビッグ データ プラットフォームなど、複雑と思われる一般的なアプリケーションを展開する必要がなく、クラウド プラットフォーム上でワンクリックで取得できることです。

自動的に展開されるか、展開されないかのいずれかです。一般的に言えば、アプリケーション層についてのみ心配する必要があります。これがPaaSの役割です。もちろん、デプロイメントがまったく必要なく、ワンクリックですべてを取得できればベストなので、パブリッククラウドプラットフォームでは、一般的なサービスをPaaSプラットフォーム化しました。他のアプリケーションについては、自分で開発し、自分以外には誰も知らないため、ツールを使用して自動的にデプロイすることができます。

PaaS の最大の利点は、アプリケーション層の弾力的なスケーリングを実現できることです。たとえば、ダブルイレブンショッピングフェスティバルでは、10 個のノードを 100 個のノードに変換する必要があります。物理デバイスを使用する場合、さらに 90 台のマシンを購入するには遅すぎます。リソースの弾力性を実現するには、IaaS のみを使用するだけでは不十分です。さらに 90 台の仮想マシンを作成しても、空になります。運用・保守担当者は、依然としてそれらを 1 つずつ展開する必要があります。したがって、PaaS を利用できるのは素晴らしいことです。仮想マシンが起動すると、自動展開スクリプトがすぐに実行され、アプリケーションがインストールされます。アプリケーションは 90 台のマシンに自動的にインストールできるため、真の弾力的なスケーリングが実現します。

もちろん、この展開方法にも問題があります。 Puppet、Chef、Ansible がインストール スクリプトをどれだけ抽象化しても、それらは依然としてスクリプトに基づいています。ただし、ファイル パス、ファイル権限、依存パッケージ、アプリケーション環境、Tomcat、PHP、Apache などのソフトウェア バージョン、JDK、Python などのバージョン、一部のシステム ソフトウェアがインストールされているかどうか、使用されているポートなど、アプリケーション環境は大きく異なります。これらすべてが原因で、スクリプトが正常に実行されない可能性があります。そのため、スクリプトを一度作成すると、すぐにコピーできるようですが、環境が少し変わると、スクリプトを修正し、テストし、再度デバッグする必要があります。たとえば、データセンターで作成されたスクリプトは、AWS に移動すると直接動作しない可能性があります。 AWS 上でデバッグできたとしても、Google Cloud に移行すると再び問題が発生する可能性があります。

コンテナの誕生

そこでコンテナが誕生しました。 Container は Container であり、Container の別の意味は container です。実際、コンテナのアイデアは、ソフトウェア配信用のコンテナに変えることです。コンテナの特徴は、包装と規格です。コンテナのない時代を想像してみてください。商品を A から B に輸送する場合、3 つのドックを通過し、船を 3 回乗り換える必要があります。そのたびに、商品を船から降ろして、食堂に置かなければなりませんでした。そして、船を乗り換えるときには、再び整理し直さなければなりません。したがって、コンテナがない場合、乗組員は出発前に数日間陸上に滞在することができました。しかし、コンテナであれば、すべての商品が一緒に梱包され、コンテナのサイズもすべて同じなので、船を乗り換えるたびに、一度に 1 つの箱を移動するだけで済み、数時間で完了します。乗組員はもはや長い休息のために上陸することはできない。つまり、A はプログラマー、B はユーザー、商品はコードと動作環境、中央の 3 つのドックは開発、テスト、オンラインであると想像してください。

コードが次の環境で実行されると仮定します。

1. Ubuntu オペレーティングシステム

2. ユーザーhadoopを作成する

3. JDK 1.7をダウンロードしてディレクトリに解凍する

4. このディレクトリをJAVA_HOMEとPATH環境変数に追加します。

5. 環境変数のエクスポートを、hadoopユーザーのホームディレクトリの.bashrcファイルに配置する

6. Tomcat 7をダウンロードして解凍する

7. tomcatのwebappパスの下にwarファイルを配置します。

8. tomcatの起動パラメータを変更し、Javaヒープサイズを1024Mに設定します。

シンプルな Java ウェブサイトの場合、非常に多くの点を考慮する必要があります。パッケージ化しないと、開発環境、テスト環境、本番環境のそれぞれで環境の整合性をチェックして確保したり、環境を再構築したりする必要があり、毎回商品を解体して再インストールするのと同じくらい面倒です。開発環境では JDK 1.8 を使用し、オンライン環境では JDK 1.7 を使用する、または開発環境では root ユーザーを使用するが、オンライン環境では hadoop ユーザーを使用する必要があるなど、途中でちょっとした間違いがあると、プログラムが失敗する可能性があります。

コンテナはどのようにアプリケーションをパッケージ化するのでしょうか?コンテナについてはまだ学ぶ必要があります。まず、荷物が互いに干渉せず、互いに隔離され、積み下ろしが便利になるように、荷物を密封するための密閉環境が必要です。幸いなことに、Ubuntu の lxc テクノロジーは長い間これを実現してきました。ここでは主に 2 つのテクノロジが使用されます。 1 つは、名前空間と呼ばれる一見分離されたテクノロジーです。つまり、各名前空間内のアプリケーションは、異なる IP アドレス、ユーザー スペース、プロセス番号などを参照します。もう 1 つは、cgroup と呼ばれる分離されたテクノロジーです。つまり、マシン全体には大量の CPU とメモリがありますが、アプリケーションはそれらの一部しか使用できません。

これら2つの技術でコンテナの鉄箱を溶接しました。次のステップは、中に何を入れるかを決めることです。最も単純かつ最も残酷な方法は、上記のリストにあるものをすべてコンテナに入れることです。しかし、これは大きすぎます。仮想マシンイメージはこのようになっているため、数十 GB になることがあります。他に何もインストールせずに単純な Ubuntu オペレーティング システムをインストールすると、サイズが非常に大きくなります。これは実際には船をコンテナに入れるのと同じです。答えはもちろん「ノー」です。

したがって、オペレーティング システムを除けば、残りすべてを合わせても数百 MB しか占有せず、はるかに軽量です。したがって、サーバー上のコンテナはオペレーティング システム カーネルを共有し、異なるマシン間でのコンテナの移行ではカーネルは転送されません。このため、コンテナは軽量の仮想マシンであると多くの人が主張しています。それは無駄な光ではありません。当然のことながら、その絶縁特性は劣っています。 1 つのコンテナが船の漏れの原因になった場合、すべてのコンテナが一緒に沈没します。

除外する必要があるもう 1 つのものは、アプリケーションの実行時にローカルに生成され保存されるデータです。これらのデータのほとんどは、データベース ファイルやテキスト ファイルなどのファイルの形式で存在します。これらのファイルは、アプリケーションの実行に伴って大きくなります。これらのデータもコンテナ内に配置すると、コンテナが非常に大きくなり、異なる環境でのコンテナの移行に影響を及ぼします。さらに、このデータを開発環境、テスト環境、オンライン環境間で移行しても意味がありません。実稼働環境ではテスト環境のファイルを使用できないため、このデータはコンテナ外のストレージ デバイスに保存されることがよくあります。これが、コンテナがステートレスと呼ばれる理由です。

この時点でコンテナは溶接され、貨物が積み込まれました。次のステップは、どの船でも輸送できるようにコンテナを標準化することです。ここでの標準は、1 つはイメージであり、もう 1 つはコンテナの動作環境です。いわゆるミラーリングとは、溶接した瞬間のコンテナの状態を保存することであり、孫悟空が言ったように、コンテナの内部はその瞬間に固定され、その瞬間の状態が一連のファイルに保存されます。これらのファイルのフォーマットは標準的であり、誰でもそれを見て、その時点で凍結された瞬間を復元することができます。イメージをランタイムに復元するプロセスは、イメージファイルを読み込んでその時点のプロセスを復元することであり、コンテナを実行するプロセスです。よく知られている Docker の他に、コンテナ イメージを実行できる AppC や Mesos Container などのコンテナもあります。したがって、コンテナは Docker と同じではありません。

つまり、コンテナは軽量で、分離性が低く、ステートレスに適しており、イメージ標準に基づいてホストや環境間で自由に移行できます。

コンテナを使用すると、PaaS レイヤーでのユーザー アプリケーションの自動展開が高速かつスムーズになります。コンテナは 2 つの点で高速です。まず、仮想マシンを起動する場合、最初にオペレーティング システムを起動する必要がありますが、コンテナーはカーネルを共有するため、オペレーティング システムを起動する必要はありません。 2 つ目は、仮想マシンの起動後にスクリプトを使用してアプリケーションをインストールすることです。アプリケーションはすでにイメージにパッケージ化されているため、コンテナーはアプリケーションをインストールする必要はありません。したがって、仮想マシンの起動時間は分単位ですが、コンテナの起動時間は秒単位になります。コンテナは本当に魔法のようです。実際のところ、それはまったく魔法ではありません。 1 つ目は、怠けて仕事量を減らすこと、2 つ目は、仕事を前もって終わらせることです。

コンテナはすぐに起動するため、時間がかかりすぎるため、アプリケーションを展開するために小さな仮想マシンを作成しないことがよくあります。代わりに、大規模な仮想マシンを作成し、その大規模な仮想マシン内でコンテナを分割します。異なるユーザーが大規模な仮想マシンを共有しないため、オペレーティング システム カーネルの分離を実現できます。

これは、物事が集まって最終的に分離する別のプロセスです。 IaaS レイヤーの仮想マシン プールは、より細かい粒度のコンテナ プールに分割されます。

コンテナは粒度が細かく、管理がより難しく、手動で処理するのが難しいほどです。物理マシンが 100 台あるとします。規模としてはそれほど大きくありません。 Excel による手動管理も問題ありません。しかし、1 台のマシンで 10 台の仮想マシンを開くと、仮想マシンの数は 1,000 台となり、手動での管理は既に非常に困難です。しかし、1 つの仮想マシンで 10 個のコンテナを開くと、コンテナの数は 10,000 個になります。手動での操作とメンテナンスという考えを完全にあきらめましたか?

したがって、コンテナ レベルでの管理プラットフォームは新たな課題であり、キーワードは自動化です。

自己検出: コンテナは仮想マシンのように相互に構成され、IP アドレスを記憶してから相互に構成できますか?コンテナが多数ある場合、仮想マシンがクラッシュして再起動したり、IP が変更されたりしたときに、どの構成を変更する必要があるかをどのように覚えておくのでしょうか?リストの長さは少なくとも数万行です。したがって、コンテナ間の構成は名前を通じて行われます。コンテナがどのマシンで実行されていても、名前は変更されずにアクセスできます。自己修復: コンテナがハングしたり、プロセスがクラッシュしたりした場合、仮想マシンのようにログインしてプロセスの状態を確認し、異常であれば再起動できますか? Wantai Docker にログインしようとしています。したがって、コンテナ プロセスがハングした場合、コンテナは自動的にハングし、その後自動的に再起動します。自動スケーリング: コンテナのパフォーマンスが不十分な場合、手動でスケーリングまたはデプロイする必要がありますか?もちろん、それは自動的に行われなければなりません。コンテナ管理プラットフォームがあれば、それは長期的な分離と再統合のもう一つの事例となるでしょう。

[[359558]]

コンテナ管理プラットフォーム

現在普及しているコンテナ管理プラットフォームには、主に 3 つの考え方があります。

1 つは Kubernetes で、これを Duan Yu タイプと呼んでいます。 Duan Yu (Kubernetes) の父親 (Borg) は王族 (Google) 出身の武術の専門家であり、Dali と呼ばれる大きな王国を管理していました (Borg は Google のデータセンターのコンテナ管理プラットフォームです)。 Duan Yu は Dali Duanshi の子孫として優れた武術の遺伝子を持っており (Kubernetes の概念設計は比較的完成しています)、多くの達人や優れた武術環境に囲まれています (Kubernetes のエコシステムは活発で人気があります)。段羽の武術は、デビュー当時の父親ほど優れているわけではないが、周囲の達人から学び続ける限り、彼の武術は急速に向上することができる。

1 つは Mesos で、これを Qiao Feng タイプと呼んでいます。喬鋒（メソス）の主なカンフーである十八龍鎮掌（メソスの派遣機能）は、武術の世界では独特であり、他のギャングには存在しません。さらに、Qiao Feng は多数の Beggars' Gang も管理していました (Mesos は Twitter のコンテナ クラスターを管理していました)。その後、喬鋒は乞食宗を離れ、世界でもユニークな人物となった（Mesosの創設者はMesosphereという会社を設立した）。喬鋒の長所は、彼の十八龍鎮掌（メソ）が乞食宗で使用される十八龍鎮掌と同じであることです。段羽が父親から学んだ武術と比べると、はるかに成熟している。しかし、欠点は、十八龍鎮掌が少数の乞食宗の指導者の手にしかなく（メソスコミュニティは依然としてメソスフィアによって支配されている）、他の乞食宗の兄弟は遠くから喬峰を賞賛することしかできず、お互いから学ぶことができない（コミュニティの人気が十分ではない）ことです。

1つはSwarmで、Murong型と呼んでいます。慕容一族（SwarmはDocker一族のクラスター管理ソフトウェア）の個々のスキルは非常に優れています（Dockerはコンテナの事実上の標準と言えます）が、Duan YuとQiao Fengが管理できる組織の規模がどんどん大きくなり、天下統一の潮流があるのを見て、彼らは本当に嫉妬し、自分たちの慕容鮮卑帝国（Swarmコンテナクラスター管理ソフトウェアを立ち上げる）を作りたいと思うようになりました。しかし、優れた個人スキルは、強力な組織能力（Swarm のクラスター管理能力）を意味するわけではありません。幸いなことに、慕容一家は段宇と喬峰の組織管理経験から学び、さまざまな企業から学び、知っている限り他の人に還元することができます。その結果、Murong 氏の組織力 (Swarm は以前のクラスター管理のアイデアを数多く活用しています) は徐々に成熟しつつあります。

[[359559]]

クラウドコンピューティングのコアテクノロジーは何ですか?

クラウド コンピューティングは、データと処理能力を中心とした集中的なコンピューティング モデルです。複数のICT技術を統合し、従来の技術の「スムーズな進化」の産物です。その中で、仮想化技術、分散データストレージ技術、プログラミングモデル、大規模データ管理技術、分散リソース管理、情報セキュリティ、クラウドコンピューティングプラットフォーム管理技術、グリーン省エネ技術が最も重要です。

1. 仮想化技術

仮想化は、クラウド コンピューティングの最も重要なコア テクノロジーの 1 つです。クラウドコンピューティングサービスのためのインフラストラクチャサポートを提供し、クラウドコンピューティングに向けたICTサービスの急速な発展の主な原動力となっています。仮想化技術がなければ、クラウド コンピューティング サービスの実装と成功はあり得なかったと言えます。クラウド コンピューティング アプリケーションがますます活発になるにつれ、仮想化テクノロジに対する業界の注目は新たなレベルに達しました。同時に、私たちの調査では、多くの人がクラウド コンピューティングと仮想化について誤解しており、クラウド コンピューティングは仮想化であると考えていることがわかりました。実際にはそうではありません。仮想化はクラウド コンピューティングの重要な部分ですが、すべてではありません。

技術的に言えば、仮想化とは、ソフトウェアでコンピューターのハードウェアをエミュレートし、仮想リソースを使用してユーザーにサービスを提供するコンピューティング形式です。コンピュータリソースを合理的に割り当てて、より効率的にサービスを提供することを目的としています。アプリケーション システムのハードウェア間の物理的な区分を解消し、動的なアーキテクチャと物理リソースの集中管理および使用を実現します。仮想化の最大の利点は、システムの弾力性と柔軟性を高め、コストを削減し、サービスを改善し、リソースの利用効率を高めることです。

表現の観点から見ると、仮想化は 2 つのアプリケーション モードに分けられます。 1 つは、強力なサーバーを複数の独立した小さなサーバーに仮想化し、さまざまなユーザーにサービスを提供することです。 2 つ目は、複数のサーバーを 1 つの強力なサーバーに仮想化して、特定の機能を実行することです。これら 2 つのモードの中核となるのは、統合管理、リソースの動的な割り当て、およびリソース使用率の向上です。クラウド コンピューティングでは、両方のモデルが比較的幅広い用途に使用されています。

2. 分散データストレージ技術

クラウド コンピューティングのもう 1 つの大きな利点は、膨大な量のデータを迅速かつ効率的に処理できることです。これは、今日のデータ爆発の世界では非常に重要です。高いデータ信頼性を確保するために、クラウド コンピューティングでは通常、分散ストレージ テクノロジを採用して、データをさまざまな物理デバイスに保存します。このモデルは、ハードウェア機器の制限を取り除くだけでなく、拡張性も向上し、ユーザーのニーズの変化に迅速に対応できます。

分散ストレージは、従来のネットワーク ストレージとまったく同じではありません。従来のネットワーク ストレージ システムでは、集中型ストレージ サーバーを使用してすべてのデータを保存します。ストレージ サーバーはシステム パフォーマンスのボトルネックとなり、大規模ストレージ アプリケーションのニーズを満たすことができなくなります。分散ネットワーク ストレージ システムは、スケーラブルなシステム構造を採用し、複数のストレージ サーバーを使用してストレージ負荷を分散し、ロケーション サーバーを使用してストレージ情報を検索します。システムの信頼性、可用性、アクセス効率が向上するだけでなく、拡張も容易になります。

現在のクラウド コンピューティング分野では、Google の GFS と Hadoop が開発したオープン ソース システム HDFS の 2 つが、最も人気のあるクラウド コンピューティング分散ストレージ システムです。

GFS（Googleファイルシステム）テクノロジー：Googleの非オープンソースGFS（Googleファイルシステム）クラウドコンピューティングプラットフォームは、多数のユーザーのニーズを満たし、並行して多数のユーザーにサービスを提供します。これにより、クラウドコンピューティングデータストレージテクノロジーには、スループットが高く、伝送速度が高くなります。

HDFS（Hadoop分散ファイルシステム）テクノロジー：YahooやIntelを含むほとんどのICTベンダーは、クラウドプランでHDFSデータストレージテクノロジーを使用しています。将来の開発は、超大規模なスケールデータストレージ、データ暗号化とセキュリティ保証、およびI/Oレートの継続的な改善に焦点を当てます。

3。プログラミングモード

基本的に、クラウドコンピューティングは、同時処理をサポートするマルチユーザーのマルチタスクシステムです。効率、シンプルさ、速度がそのコア概念です。これは、低コストで優れたユーザーエクスペリエンスを確保しながら、強力なサーバーコンピューティングリソースをエンドユーザーに便利に配布することを目的としています。このプロセスでは、プログラミングモードの選択が重要です。分散並列プログラミングモデルは、クラウドコンピューティングプロジェクトで広く採用されます。

分散型並列プログラミングモデルを作成する当初の意図は、ソフトウェアとハ​​ードウェアリソースをより効率的に利用して、ユーザーがアプリケーションまたはサービスをより迅速かつ簡単に使用できるようにすることです。分散型並列プログラミングモデルでは、バックグラウンドでの複雑なタスク処理とリソーススケジューリングがユーザーに対して透明であるため、ユーザーエクスペリエンスを大幅に改善できます。 MapReduceは、クラウドコンピューティングにおける現在の主流の並列プログラミングモデルの1つです。 MapReduceモードは、タスクを自動的に複数のサブタスクに分割し、マップの2つのステップを介して大規模コンピューティングノードのタスクの高さと分布を実現します。

MapReduceは、Googleが開発したJava、Python、およびC ++プログラミングモデルです。これは、主に大規模なデータセット（1TBを超える）の並行コンピューティングに使用されます。 MapReduceモデルのアイデアは、問題を分解してマップに実行して減らすことです。まず、データはマッププログラムを介して無関係なブロックにカットされ、処理のために多数のコンピューターに分散（スケジュール）されて分散コンピューティングの効果を実現します。その後、結果は要約され、Reduceプログラムを介して出力されます。

4。大規模なデータ管理

大量のデータを処理することは、クラウドコンピューティングの大きな利点です。それに対処する方法には多くの側面が関係するため、効率的なデータ処理テクノロジーは、クラウドコンピューティングの不可欠なコアテクノロジーの1つでもあります。クラウドコンピューティングの場合、データ管理は大きな課題に直面しています。クラウドコンピューティングは、データストレージとアクセスを確保するだけでなく、膨大な量のデータで特定の検索と分析を実行することもできます。クラウドコンピューティングには、膨大な量の分散データを処理および分析する必要があるため、データ管理技術は大量のデータを効率的に管理できる必要があります。

GoogleのBT（Bigtable）データ管理技術とHadoopチームが開発したオープンソースデータ管理モジュールHBaseは、業界の典型的な大規模なデータ管理テクノロジーです。

BT（BigTable）データ管理テクノロジー：Bigtableは、非関連データベース、分散、永続的なストレージ、多次元ソートマップです。 Bigtableは、GFS、スケジューラ、ロックサービス、MapReduceに構築されています。従来のリレーショナルデータベースとは異なり、すべてのデータをオブジェクトとして扱い、大規模な構造化データの分散ストレージのための巨大なテーブルを形成します。 BigTableは、PBレベルのデータを確実に処理するように設計されており、数千のマシンに展開できます。

オープンソースのデータ管理モジュールHBase：HBaseは、ApacheのHadoopプロジェクトのサブプロジェクトであり、分散型の列指向のオープンソースデータベースとして配置されています。 HBaseは、一般的なリレーショナルデータベースとは異なります。これは、非構造化データの保存に適したデータベースです。もう1つの違いは、Rowベースのモデルではなく、HBaseのカラムベースです。信頼性の高い分散ストレージシステムとして、HBaseはパフォーマンスとスケーラビリティの点でうまく機能します。 HBaseテクノロジーを使用して、安価なPCサーバーに大規模な構造化されたストレージクラスターを構築できます。

5。分散リソース管理

クラウドコンピューティングは、分散型ストレージテクノロジーを使用してデータを保存するため、分散リソース管理技術を導入することは自然です。マルチノードの同時実行環境では、各ノードのステータスを同期させる必要があり、単一のノードが失敗した場合、システムは他のノードが影響を受けないように効果的なメカニズムを必要とします。分散リソース管理システムはまさにそのようなテクノロジーであり、システムステータスを確保するための鍵です。

さらに、クラウドコンピューティングシステムによって処理されるリソースは、多くの場合、数百のサーバーから数万のサーバーまで非常に大きく、複数の領域にまたがる可能性があります。また、クラウドプラットフォームで実行されている数千のアプリケーションもあります。これらのリソースを効果的に管理し、それらがサービスを提供することを通常、強力な技術サポートが必要になることを確認する方法。したがって、分散型リソース管理技術の重要性を想像することができます。

世界中の主要なクラウドコンピューティングソリューション/サービスプロバイダーは、関連技術の研究開発を積極的に実施しています。その中で、Googleが内部で使用するボルグテクノロジーは、業界で非常に賞賛されています。さらに、Microsoft、IBM、Oracle/Sunなどのクラウドコンピューティングの巨人は、対応するソリューションを提案しています。

6。情報セキュリティ

調査データは、セキュリティがクラウドコンピューティングの開発を妨げる主な理由の1つになったことを示しています。データは、クラウドコンピューティングをすでに使用している組織の32％のICT管理と、クラウドコンピューティングをまだ使用していない組織の45％が、クラウドセキュリティをさらにクラウド展開の最大の障害と見なしていることを示しています。したがって、クラウドコンピューティングの長期的な安定性と急速な発展を確保するために、セキュリティは対処する必要がある最初の問題です。

実際、クラウドコンピューティングセキュリティは新しい問題ではありません。同じ問題が従来のインターネットに存在します。セキュリティの問題がより顕著になったのは、クラウドコンピューティングの出現後になって初めてです。クラウドコンピューティングシステムでは、セキュリティには、ネットワークセキュリティ、サーバーセキュリティ、ソフトウェアセキュリティ、システムセキュリティなど、多くの側面が含まれます。したがって、一部のアナリストは、クラウドセキュリティ業界の開発が従来のセキュリティ技術を新しい段階にもたらすと考えています。

現在、ソフトウェアセキュリティベンダーとハードウェアセキュリティベンダーの両方が、クラウドコンピューティングセキュリティ製品とソリューションを積極的に開発しています。従来のウイルス対策ソフトウェアベンダー、ソフトウェアおよびハードウェアファイアウォールベンダー、IDS/IPSベンダーなど、あらゆるレベルのセキュリティベンダーがクラウドセキュリティフィールドに参加しました。近い将来、クラウドセキュリティの問題は十分に解決されると思います。

7。クラウドコンピューティングプラットフォーム管理

クラウドコンピューティングリソースの規模は非常に大きく、さまざまな場所に多数のサーバーが配布され、数百のアプリケーションが同時に実行されています。これらのサーバーを効果的に管理し、システム全体が途切れないサービスを提供する方法は大きな課題です。クラウドコンピューティングシステムのプラットフォーム管理テクノロジーは、多数のサーバーリソースを効率的に割り当てる機能を備えている必要があります。その中で、クラウドコンピューティングプラットフォーム管理テクノロジーの鍵は、新しいサービスを簡単に展開および起動し、システム障害を迅速に発見および回復し、自動化とインテリジェントな手段を通じて大規模システムの信頼できる操作を実現することです。

プロバイダーの場合、クラウドコンピューティングには、パブリッククラウド、プライベートクラウド、ハイブリッドクラウド、つまり3つの展開モデルがあります。 3つのモードには、プラットフォーム管理の要件が非常に異なります。ユーザーの場合、ICTリソース共有、システム効率の要件、およびICTコスト投資予算を制御することにより、企業が必要とするクラウドコンピューティングシステムの規模と管理性も非常に異なります。したがって、クラウドコンピューティングプラットフォーム管理ソリューションは、カスタマイズされたニーズをさらに考慮し、さまざまなシナリオのアプリケーション要件を満たすことができるはずです。

Google、IBM、Microsoft、Oracle/Sunなどを含む多くのメーカーは、クラウドコンピューティングプラットフォーム管理ソリューションを開始しました。これらのソリューションは、企業がインフラストラクチャの統合、統一された管理、統一された割り当て、統一展開、統一された監視、エンタープライズハードウェアおよびソフトウェアリソースの統一バックアップを達成し、アプリケーションのリソースの排他性を破り、エンタープライズクラウドコンピューティングプラットフォームの価値を完全に活用できるようにすることができます。