プライベートクラウドとパブリッククラウド: Kubernetes がバランスをどう変えるか

今日の企業のほとんどはハイブリッド クラウド ユーザーになります。 2021 年に Statista が 750 社を対象に実施した調査では、82% の企業がハイブリッド クラウド コンピューティング戦略を採用していることがわかりました。

ただし、このハイブリッド導入の統計は、プライベート クラウドとパブリック クラウドの問題が、2 つのクラウド スタイルを組み合わせて導入することで明確に解決されることを意味するものではありません。むしろ、デプロイメント アーキテクチャは複雑で急速に進化しており、クラウド アーキテクチャを「一回限り」で決定するのは意味がないことを意味します。

実際、現在クラウド テクノロジー スタックで起こっていることは、新たな可能性を解き放つことです。パブリック クラウドの導入に向けた世界的なトレンドが何年も続いた後、これらの新しい動向によりクラウドの経済性が変わり、プライベート クラウドの概念が活性化し、パブリック クラウドを管理するための新しい戦略的オプションが提供され、エッジ、IoT、「ベア メタル クラウド」製品などの新しいベア メタル モデルが実現されています。

1. クラウドエコノミクス: v1.0

クラウド コンピューティングの導入が始まったのは、ローカル データ センターの構築と維持にコストがかかったためです。サーバーは高価で時代遅れです。施設、電力、冷却、内部ネットワーク、WAN 接続、および複数のサービス プロバイダーからのバックボーン接続が必要です。データ センターには、障害ドメインを分離し、冗長リソースを割り当てて回復力を実現する設計者がいます。

労働者はそれらを維持、操作し、保護します。フルタイムの管理者がパフォーマンス、使用効率、その他の特性を分析してから最適化するのは、多くの場合、時間がかかり、コストもかかります。企業は特定の場所に縛られたままになり、未使用の容量に対して料金を支払いながらも、予期しない需要に合わせて迅速に拡張できないという弾力性のパラドックスに陥る可能性があります。

これはほんの始まりに過ぎません。低いレベルの運用効率を実現するために、多くのユーザーは、ライセンスされたオペレーティング システムを使用して「標準」データ センター スタックを実装し続け、サーバー構成とライセンス管理用のツールを追加し、最終的にそのソリューション セットに縛られてしまいます。

次に、速度を上げて開発者とビジネス ユニットのセルフサービスを可能にするために、同様に設計されたコストベースのプライベート クラウド インフラストラクチャ サービス ソリューションを追加しました。これにより効率は向上しますが、新たなスキル要件が生まれ、新たなロックイン要因と多くの新たなコストが追加されます。

これと比較すると、パブリッククラウドも良い選択肢のように思えます。すべてが運用費用であり、物理的なデータセンターを運用するために必要な物理的な機器や直接的な諸経費や人件費は発生しません。企業は通信事業者とやり取りする必要がなく、小規模で始めて急速に成長したり、必要に応じて頻繁に規模を変更したりすることができます。

企業は、プロバイダーの地域内のどこにでもワークロードを配置し、単一のWeb UIやAPIセットを使用することができます。
必要なものをすべて設定および構成します。これは、「物理インフラストラクチャ」ステップ全体の複雑さと制限をスキップして、「サービスとしての弾力性のあるコンピューティング クラウド」部分に直接進むようなものです。

1) クラウドの複雑さのリマインダー

パブリッククラウドを使用するすべての企業は、複雑な請求書に悩まされています。クラウドの価格設定の複雑さにより、コスト削減戦略の策定と実装が困難になることもあります。

同時に、従来の考え方を採用せずにパブリック クラウドに参入する企業はほとんどありません。企業は俊敏性と回復力を獲得するために、一貫性を犠牲にすることがよくあります。同社は長年にわたり VMware 中心のインフラストラクチャをコードとして社内で構築してきましたが、現在は AWS 環境用の新しいコード ベースを作成および保守するために専門家を雇っています。

そうするためのコストは莫大で、継続的です。これにより、セキュリティホールが発生し、人為的エラーが発生する新たな機会が生じ、すべてが困難になります。

他のケースでは、企業はパブリック クラウドに進出する際に、「標準 OS」および「標準 IaaS」運用モデルを採用し、従来のコスト構造を維持するための取り組みを強化することで一貫性を維持しようとする場合があります。あるいは、逆の方向に進み、パブリック クラウドの Web UI と API によって駆動されるプライベート クラウド ソリューションを購入して一貫性を確保し、多様なスキルの必要性を減らすこともできますが、その代償としてロックインが増大します。

2. クラウドエコノミクス: バージョン 2.0

ただし、Kubernetes をこの組み合わせに投入すると、いくつかの点が変わります。

1) Kubernetes は Linux カーネル以外のものには焦点を当てていません。現在、適切に設計された Kubernetes を実行するために、実際のボックスや仮想ボックス、Linux バリアントを調整するには、通常、適切なリソース構成のみが必要です (ボックスには、そのジョブを安全に実行するための十分なコア/RAM/ストレージ/ネットワーク + セキュリティが必要です)。

2) 一貫性のある Kubernetes により、基本的なワークロードと構成の移植性が実現します。ワークロードに特定のハードウェア要件がない限り (ほとんどの場合はそうではありません)、企業は Linux Spin X で開発されたワークロードがどこの Linux X マシンでも実行できると期待できます。

論理的に自己相似な Kubernetes クラスターにデプロイされたコンテナと構成についても同様です。これは事実ではありません。人々はさまざまなクラスターを構築または取得し、それらをより大きなアーキテクチャに組み込んでソフトウェア配信を高速化しようとしたり、CI 自動化やその他のツールを使用したり、増分を隠すために手作業を行ったりします。

3) 極端な場合を除き、Kubernetes は、人間が常に注意を払うことなく、複雑で扱いにくいアプリケーションをスムーズに実行し続けることができます。結局のところ、それがそのように設計されたものなのです。企業は、アプリケーションや操作をオフラインにすることなく、スタック内のすべてのものに対してローリング アップデートを実行することもできます。

4) Kubernetes を使用すると、企業はカスタム機能を追加して複雑なシステム状態を監視および維持し、宣言型構成の変更に応じてシステムを新しい状態に収束させることができます。これらの機能は、Kubernetes がスタック内に存在する場所から上位と下位の両方で機能します。

したがって、Kubernetes オペレーターや同様の構造を使用して、アプリケーション (上位) と、物理ホスト、仮想ホスト、仮想ネットワーク、クラウド サービスなどの基盤となるインフラストラクチャ (下位) を管理できます。

5) Kubernetes は、アプリケーションに多数のサービスを提供するように構成および拡張できます。ストレージ、DNS など、アプリケーションに必要なものは何でも、Kubernetes はワークロードに代わってサービスを提供し、オーケストレーションすることができます。それが Kubernetes が設計された目的です。

6) Kubernetes は非常に速く拡張できます。ノードの起動に必要な時間を除いて、最新の Kubernetes ディストリビューションは、わずか数分で任意の数のノードに拡張できます。

7) Kubernetes は非常に細分化できます。最新の Kubernetes ディストリビューションでは、開発者が単一のデスクトップ コンテナーまたは 2 台の Raspberry Pi 上でコントローラーとワーカーを起動できるようになります。同じディストリビューションで、50/100/500 ノードのクラスターを同様に実行できるはずです。

長年のユーザーのほとんどが気づいているように、有機的な「多数のクラスターと 1 つの巨大なクラスター」モデルは、いくつかの理由から最適に機能します。ただし、本当のメリットは、「多数の小さなクラスター」が自己一貫性を持ち、ライフサイクルを集中管理できる場合にのみ得られます。

Kubernetes のスーパーパワーは、重要な点でゲームを変えます。企業がKubernetesを導入、拡張、管理できれば
クラウドの完全なライフサイクルがあれば、それを活用してパブリック クラウドとプライベート クラウドのインフラストラクチャを構築し、コストとオーバーヘッドを積極的に最適化し、Kubernetes の下にあるすべてのものをコモディティとして扱うことができます。

1) クラウド運用コストを削減します。初期のユーザー実験では、このアプローチによりプライベート クラウド運用の総コストを迅速に削減できることが示されています。クベネフィット
中心となるインフラストラクチャは主に自ら考え、オペレーターは「上向き」にワークロードを最適化し、「下向き」にホスト、オペレーティング システム、その他のサポート サービスとレイヤーを管理します。これにより、プライベート クラウドの実行は、特に規模が大きくなるにつれて、コストとリスクが大幅に低減されます。

2) ホスト/ゲスト オペレーティング システムのライセンスおよびサポート コストを削減します。 Kubernetes は Linux カーネルと CPU をある程度考慮しますが、それ以外についてはあまり考慮しません。 Kubernetes 中心のインフラストラクチャは、基盤となる高価な「エンタープライズ」 Linux から実際には恩恵を受けません。

エンタープライズ Linux スピンによって提供される特殊な暗号化 (FIPS など) などの機能は、コンテナー ランタイムや Kubernetes ディストリビューションに急速に導入されつつあります。 Kubernetes 自体を有効にして生のベアメタル インフラストラクチャを管理できるため、サーバー プール管理ソリューションの重要性は低くなります。

3) ハードウェアコストを削減します。たとえば、コンテナと Kubernetes によってワークロードの移動と再構築が容易になったこともあり、より安価な ARM64 CPU への世界的な移行が加速しています。

ある意味、パフォーマンス重視の（コストやエネルギーなどに対する）ハードウェア開発は、特にパブリック クラウドでは停滞する可能性もあります。パブリック クラウドでは、ハードウェアを「ダウンサイジング」する経済性がスケール プロバイダーにとって非常に魅力的です。同時に、規制、管轄、主権上の理由、そして接続性の観点から、場所がより重要であると言えるでしょう。

これはプライベートクラウド事業者にとって朗報です。集中型のコンピューティング/ストレージ/ネットワークの構築は、今日ではかつてないほど安価になっています。データ センター自体は変化しており、より小型になり、消費電力と冷却の使用量が少なくなり、より多くの場所に分散され、エッジに向かってマイクロ施設クラスターへと移行しています。

4) プライベート IaaS クラウドを実行するための新しい、より安価な方法。 Kubernetes 中心のインフラストラクチャは、複雑で重要なソフトウェアを堅牢かつ柔軟に、低い運用コストで実行するのに最適です。

たとえば、ベアメタル サーバーのプールでは、パフォーマンスを犠牲にすることなく、オープン ソースのインフラストラクチャ サービスである OpenStack の基盤レイヤーとして Kubernetes を実行でき、弾力性の向上、シームレスな更新、簡単なスケーリングを実現しながら、従来の仮想マシン、ネットワーク、ストレージを強力にサポートできます。

5) 自動化コストを削減します。アプリケーションの開発、テスト、ステージング、本番環境への配信のための安全で信頼性が高く、高性能なツールチェーンを構築することは、顧客を満足させ、ビジネス リスクを軽減するために不可欠です。

一貫性のある Kubernetes クラスター モデル (異なるプライベート クラウド インフラストラクチャとパブリック クラウド インフラストラクチャではなく) が目標である場合は、これを 1 回だけ実行し、その後は最終的な利益に重要な部分を改善することに時間を費やす必要があります。

3. どこでも一貫したKubernetes

Kubernetes を「インフラストラクチャ」として使用するための基本的な要件は、企業が一貫した Kubernetes クラスター モデルのライフサイクルをどこにでも展開、監視、管理できることです。

これにより、Kubernetes レイヤーをターゲットとするアプリケーション、構成、CI/CD、運用の自動化が、サーバールームのブレードで実行されているクラスターをターゲットとする場合でも、AWS インスタンスで実行されているクラスターをターゲットとする場合でも、同じように機能するようになります。

これは、誰かがこの機能を有効にして、Kubernetes がさまざまな基盤インフラストラクチャをプロアクティブにスムーズに管理できるようにしていることを意味します。