クラウド コンピューティングの成功は何に左右されるのでしょうか?

クラウド コンピューティングの成功の鍵は、Infrastructure as a Service (IaaS) の概念と、ハイパーバイザーの API を通じて仮想マシンにサービスを提供する能力にあります。ハイパーバイザーを使用すると、同じ物理ハードウェア上で複数のオペレーティング システム (仮想マシンなど) をホストできます。最新のハイパーバイザーのほとんどは、Intel (x86 および x86-64)、ARM、PowerPC、MIPS などの複数の CPU アーキテクチャをエミュレートするように設計されています。クラウド コンピューティングでは、Web ベースのフロント エンドを通じて、割り当てられたすべてのコンピューティング リソースを完全に制御し、数分で新しいサーバー インスタンスを取得して起動できます。

わずか数分で単一のサーバーまたは数千のサーバー インスタンスを同時に稼働させることができると想像してください。これらはすべて Web サービス API によって制御されます。API に詳しくない方のために説明すると、API はサービス、アプリケーション、およびシステム全体を結び付けるものです。通常、API はビジネス機能やサービスを公開することで、企業や製品のパブリックな役割を果たします。クラウドの API は、ブラウザ、モバイル アプリ、またはその他のインターネット対応エンドポイントから呼び出すことができます。

同様に、デプロイされた各サーバー インスタンスを完全に制御できます。つまり、それぞれのモジュールに対してルート アクセス (コンソール出力付き) が可能であり、必要に応じてモジュールと対話することができます。同じ Web サービス API を通じて、必要なインスタンスを開始または停止できます。クラウド サービス プロバイダーは、ユーザーが (仮想) ハードウェア構成 (つまり、メモリ、CPU、ストレージ、ドライブ パーティション サイズ) を選択できるようにしています。ユーザーは、複数のオペレーティング システム (Linux ディストリビューションや Microsoft Windows Server を含む) およびソフトウェア パッケージのリストからインストールを選択することもできます。最後に、選択するリソースが増えるほど、サーバー インスタンスのコストが高くなることに注意してください。

容器

仮想マシンの実行に関しては、コンテナはほぼベアメタルです。仮想マシンのホスティングにはオーバーヘッドはほとんどまたはまったくありません。この機能は、1 つ以上のプロセスの CPU、メモリ、ディスク I/O、およびネットワークの使用を制限、考慮、および分離します。基本的に、コンテナはソフトウェア アプリケーションをオペレーティング システムから分離し、ユーザーにクリーンかつ最小限の動作環境を提供しながら、他のすべてを 1 つ以上の分離された「コンテナ」内で実行します。

この分離により、特定のコンテナで実行されているプロセスが、別のコンテナで実行されているプロセスを監視したり影響を与えたりすることが防止されます。さらに、これらのサービスはホスト コンピューターに影響を与えたり、干渉したりすることはありません。複数の物理サーバーに分散していた複数のサービスを 1 台のサーバーに統合できるという考えは、データ センターがこのテクノロジを採用する多くの理由の 1 つです。この分離アプローチにより、セキュリティ違反や侵害による損害が制限され、テクノロジのセキュリティが強化されます。侵入者がそのコンテナ内で実行されているアプリケーションのセキュリティ脆弱性を悪用することに成功した場合、侵入者の操作はそのコンテナ内の一連の操作に制限されます。

クラウド環境では、コンテナはアプリケーションを完全なオペレーティング システムから分離する (仮想化) だけでなく、必要最小限のソフトウェアとハ​​ードウェアの展開を可能にしてアプリケーションの展開を大幅に簡素化し、メンテナンス コストをさらに削減します。

サーバーレスコンピューティング

クラウド ネイティブ コンピューティングまたはサーバーレス コンピューティングは、アプリケーションの展開および管理方法を説明する最新のトレンド用語です。考え方はシンプルです。各アプリケーションまたはプロセスは独自のコンテナにパッケージ化され、コンテナはノードのクラスター全体で動的にオーケストレーション (つまり、スケジュールおよび管理) されます。このアプローチにより、アプリケーションは物理ハードウェアやオペレーティング システムの依存関係から解放され、データ センター内のどこでも実行できる独自の自己完結型サンドボックス環境に移行します。クラウド ネイティブ アプローチは、アプリケーション配信のさまざまなコンポーネントを分離することです。

これはクラウドで他のコンテナを実行するのと同じように聞こえるかもしれませんが、クラウド ネイティブ コンピューティングのユニークな点は、そのコンテナの管理について心配する必要がないことです (つまり、オーバーヘッドが少なくなります)。この技術は開発者から隠されています。コードをアップロードするだけで、指定されたトリガーが有効になると、API ゲートウェイ (サービス プロバイダーによって管理) がそのトリガーを処理するために意図された方法でコードをデプロイします。

最初に思い浮かぶのは、Amazon の AWS Lambda です。また、このモデルでは、プロビジョニングまたは管理する物理サーバーや仮想サーバーは存在しません。安定状態または実稼働状態であると仮定すると、コードをアップロードするだけで、コードは分離されたコンテナ化された環境にデプロイされます。 Lambda の場合、Amazon は開発者がイベント駆動型アプリケーション コードをアップロードし、数ミリ秒以内にイベント (Web サイトのクリックなど) に応答するためのフレームワークを提供します。大量のコードを実行するためのすべてのライブラリと依存関係は、コンテナー内で利用できます。

アプリケーションタイプのイベントトリガーに関しては、Amazon は、Web サイトの訪問やクリック、API ゲートウェイへの REST HTTP リクエスト、IoT デバイスのセンサー読み取り、さらには S3 バケットへの写真のアップロードなどのシナリオを実装できます。

では、これらのコンポーネントはどのように組み合わされるのでしょうか?まず、ユーザーはウェブサイトまたはモバイルデバイス上のアプリを通じてサービスにアクセスします。 Web サーバーとそれが依存するさまざまなコンポーネントは、ローカルで管理されるコンテナーまたは仮想マシンから提供される場合があります。 Web サーバーまたはモバイルアプリで特定の機能が必要な場合、AWS Identity and Access Management (IAM) サービスなどのサードパーティの認証サービスにアクセスして、API Gateway の外部でホストされているサーバーレス機能にアクセスするために必要な適切な認証情報を取得します。これらの関数はトリガーされると、必要なアクションを実行し、Web サーバーまたはモバイル アプリケーションによって要求されたコンテンツを返します。

安全性

プライベート クラウドとオンプレミス ソリューションは、パブリック クラウドよりも安全であると考えられることがよくありますが、最近の調査ではそうではないことが示されています。パブリック クラウド サービス プロバイダーは、セキュリティの脆弱性を制限するために、セキュリティの専門家に相談したり、ソフトウェア フレームワークを更新したりするために、より多くの時間とリソースを費やしています。これは事実かもしれませんが、パブリック クラウド サービスを活用する際の本当のセキュリティ上の課題は、それを安全な方法で使用することです。企業組織にとって、これはベストプラクティスを適用して安全なクラウドを導入し、ロックインを最小限に抑え、可用性と稼働時間を最大化することを意味します。

すでに ID と認証の方法について説明しましたが、これは公開されているサービスではますます重要になる機能です。これらの認証サービスにより、ユーザーはプロバイダーからのクラウド サービスへのアクセスを管理できます。たとえば、AWS には IAM と呼ばれるものがあります。 IAM を使用すると、さまざまな AWS リソースまたは特定の AWS サービス API へのアクセスを許可/拒否する権限を持つ AWS ユーザー/グループを作成および管理できるようになります。より大規模な（さらにはより小規模な）展開の場合、この権限フレームワークにより、クラウドを構成するさまざまなコンポーネントへのグローバル アクセスが簡素化されます。これは通常、大手プロバイダーが提供する無料サービスです。