クラウドネイティブ技術と今後の開発動向

クラウド コンピューティングは、クラウド コンピューティングとは何かという最初の議論から、クラウド コンピューティングは単に古いボトルに入った新しいワインであるかどうかという議論、クラウド インフラストラクチャ機能の構築方法に関する議論、クラウド プラットフォーム上でアプリケーションを構築する方法に至るまで、過去 10 年間にわたって発展してきました。業界がクラウド コンピューティング テクノロジーを探求し続けるにつれて、クラウド コンピューティングに対する理解と期待が高まっています。現在、ほとんどの企業はクラウド コンピューティングがもたらす競争上の優位性を実際に体験しており、社内に基本的なプライベート クラウド機能を構築したり、データ センターをパブリック クラウドに移行したりしています。アプリケーションがクラウド コンピューティング インフラストラクチャを有効活用してクラウド コンピューティングの機能を最大限に活用する方法は、現在、クラウド コンピューティング テクノロジにおける最も重要な課題です。クラウド コンピューティング プラットフォームに基づいて設計されたアプリケーションは、業界ではクラウド ネイティブ アプリケーションと呼ばれます。

1. クラウドネイティブの定義

クラウド ネイティブは、アプリケーションを構築および実行する方法であり、一連の技術システムと方法論です。クラウド ネイティブは、クラウド + ネイティブの組み合わせです。クラウドとは、アプリケーションの範囲がクラウド プラットフォームであることを意味し、ネイティブとは、アプリケーションが最初からクラウド環境を念頭に置いて設計されていることを意味します。クラウド向けに設計されており、クラウド内で最適な状態で実行され、クラウド プラットフォームの弾力性と分散性の利点を最大限に活用して発揮します。

1. クラウドネイティブの歴史

2013 年、Pivo​​tal の Matt Stine 氏は、クラウド向けに設計されたアプリケーションとクラウド上に展開される従来のアプリケーションを区別するために、クラウド ネイティブの概念を初めて提案しました。

2015 年、Matt Stine 氏は著書「Migrate to Cloud Native Architecture」の中で、クラウド ネイティブ アーキテクチャのいくつかの特徴として、12 の要素、マイクロサービス、自己アジャイル アーキテクチャ、API ベースのコラボレーション、および脆弱性の防止を定義しました。

Cloud Native Computing Foundation (CNCF) は 2015 年に設立されました。ベンダー中立の財団として、CNCF はクラウド ネイティブ アプリケーションの促進と普及に取り組んでいます。

2017 年に、Matt Stine はクラウド ネイティブ アーキテクチャの 6 つの特性として、モジュール性、可観測性、展開可能性、テスト可能性、置き換え可能性、処理可能性をまとめました。 Pivotal の最新の公式 Web サイトでは、クラウド ネイティブを DevOps + 継続的デリバリー + マイクロサービス + コンテナという 4 つの主要ポイントにまとめています。

2. CNCFによるクラウドネイティブの定義

CNCF (Cloud Native Computing Foundation) は 2015 年 7 月に設立され、Linux Foundation に所属しています。当初の目的は、クラウド コンピューティングに「クラウド ネイティブ」サービスを提供することでした。 CNCF はベンダー中立の財団として、Kubernetes、Prometheus、Envoy など、Github 上で急成長しているオープンソース テクノロジーを推進し、開発者が優れた製品をより速く、より良く構築できるように支援することに尽力しています。

CNCF の設立はクラウド コンピューティングにおける画期的な出来事であり、クラウド コンピューティング構築の焦点がインフラストラクチャ構築からアプリケーション向けのクラウド アーキテクチャに移行したことを示しています。 CNCF によるクラウド ネイティブの定義は、継続的な最適化プロセスです。現在、CNCF はクラウド ネイティブを次のように定義しています。

「クラウド ネイティブ テクノロジーにより、組織はパブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの新しい動的環境で、弾力的にスケーラブルなアプリケーションを構築および実行できるようになります。クラウド ネイティブ テクノロジーには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API が含まれます。」

これらの技術により、フォールト トレラントで管理しやすく、監視しやすい疎結合システムの構築が可能になります。信頼性の高い自動化と組み合わせたクラウドネイティブ テクノロジーにより、エンジニアはシステムに頻繁かつ予測可能な重大な変更を加えることが容易になります。 「

CNCF のクラウド ネイティブの説明の前半では、クラウド ネイティブの定義が示され、クラウド ネイティブに関する現在のベスト テクニカル プラクティスが紹介されています。後半では、クラウドネイティブ アプリケーションの構築の目標について説明します。

CNCF は、クラウド ネイティブを構築するための関連テクノロジ スタックや、財団に関連するインキュベーション プロジェクトに関する情報も提供しています。

▲CNCF クラウドネイティブランドスケープ

3. クラウドネイティブの主要技術

CNCF は、コンテナ、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API など、クラウド ネイティブ アプリケーションの現在のベスト プラクティスであるクラウド ネイティブの主要テクノロジを定義しています。

▲クラウドネイティブ技術スタック

• 容器

コンテナ技術は軽量な仮想化技術です。オペレーティングシステムカーネルの機能により、各プロセスのリソース使用量（CPU、メモリ、ディスクI/O、ネットワークなど）が分離され、コンテナ内で実行されているプロセスが他のプロセスからある程度分離され、仮想マシン（Virtual Machine）の過剰な追加消費が回避されます。

コンテナは通常、コンテナの展開および整理機能を提供するコンテナ オーケストレーション システムと連携して動作します。コンテナ オーケストレーション システムは通常、多数のマシン (物理マシンまたは仮想マシン) をクラスターとして管理できます。設定されたポリシーを通じて、このクラスター内のマシンにコンテナをデプロイできます。複数のコンテナインスタンスをデプロイし、アプリケーションルーティングを自動的に構成できます。インフラストラクチャとコンテナを監視できます。

コンテナとコンテナ オーケストレーション テクノロジーは、クラウド ネイティブにとって非常に重要です。コンテナは、クラウド ネイティブ アプリケーション向けの軽量なオペレーティング プラットフォームを提供します。まず、従来の仮想化技術と比較して、コンテナは非常に軽量であり、数秒で展開できます。同時に、コンテナ アプリケーションは簡単に移植でき、一度構築すればどこにでも展開できます。コンテナ オーケストレーション テクノロジーは、アプリケーションに弾力的なスケーリングとフェイルオーバー機能を提供しながら、コンテナを大規模なクラスターにデプロイできるため、コンテナ上のアプリケーションの高可用性を実現できます。アプリケーション展開の自動化と迅速な展開機能を向上させます。

現在一般的なコンテナ テクノロジには、Linux Container (略して LXC) と runC があります。 runC は現在、OCI 標準に基づいてコンテナを作成および実行する、広く認知されているコンテナ実装です。 OCI (Open Container Initiative) 組織は、コンテナ形式とランタイムに関するオープンな業界標準の開発を目指しています。

現在最も主流のコンテナ オーケストレーション実装は Kubernetes です。Kubernetes は、コンテナ化されたアプリケーションを自動的にデプロイ、スケーリング、管理するためのオープン ソース システムです。アプリケーションを構成するコンテナを論理ユニットにグループ化し、管理とサービスの検出を容易にします。 Kubernetes は、Google の 15 年にわたる本番環境の運用と保守の経験に基づいており、コミュニティの優れたアイデアとプラクティスも取り入れています。現在、ほとんどの商用およびオープンソースのコンテナ プラットフォームは Kubernetes をベースにしています。

• 不変のインフラストラクチャ

従来の運用および保守インフラストラクチャでは、通常、1 台または複数のサーバーを申請する必要があります。運用保守担当者は、ソフトウェア バイナリ パッケージをサーバーにインストールし、SSH またはエージェントを通じて環境を構成します。バージョンアップグレードやパラメータ変更などの変更が必要な場合は、サーバーごとに構成ファイルを調整し、新しいコードを既存のサーバーに直接展開する必要があります。これらのサーバーによってホストされるアプリケーションとパラメータは変更できるため、変更可能なインフラストラクチャとなります。この運用・保守方法は「Snowflake Server」とも呼ばれます。サーバーは雪の結晶のようなもので、それぞれがユニークで異なります。

不変のインフラストラクチャは、サーバーがデプロイされた後に変更されることのない従来の運用とは異なります。バージョンアップやパラメータ設定など、何らかのアップデートが必要な場合は、古いサーバーを置き換える新しいサーバーを構築する必要があります。不変のインフラストラクチャでは、サーバー ビルドは通常、イメージの形式で提供され、すべての変更はイメージに対応します。不変インフラストラクチャは「Phoenix Server」とも呼ばれます。サーバーは、灰から生まれ変わることができる不死鳥のようでなければなりません。

不変インフラストラクチャの利点には、インフラストラクチャの一貫性と信頼性の向上、およびよりシンプルで予測可能な展開プロセスなどがあります。これにより、構成のドリフト、クラスター構成の一貫性、環境のレプリケーションの問題など、変更可能なインフラストラクチャにおける一般的な問題が軽減または排除されます。

不変インフラストラクチャの実装の 1 つは、よく知られている Docker です。 Docker はコンテナ テクノロジーとしてよく知られています。実際、Docker はコンテナ パッケージング テクノロジを提供します。 Docker のコアコンセプトは不変のインフラストラクチャです。 Docker は、イメージ (Docker イメージ) または Dockerfile を通じてソフトウェアを配信します。新しいバージョンがリリースされるたびに、オペレーティング環境全体が再構築され、各更新はイメージの新しいバージョンになります。 Docker は、コンテナの軽量なデプロイメントを活用することで最大のメリットを実現できます。

• マイクロサービス

需要が増加し続けると、モノリシック アプリケーションは、小さな変更ごとにアプリケーション全体の再展開が必要になったり、小さなモジュールのコード欠陥によってすべてのビジネスが利用できなくなるなど、多くの問題に直面する可能性があります。マイクロサービスは、明確に定義された API を介して通信する小さな独立したサービスでビジネス アプリケーションを構成することで、これらの問題に対処するアーキテクチャ パターンです。これらのサービスは、小規模な独立したチームによって提供されます。マイクロサービス アーキテクチャにより、アプリケーションの拡張が容易になり、開発が高速化されるため、イノベーションが加速し、新機能の市場投入までの時間が短縮されます。

アプリケーションを小さな独立してデプロイ可能なサービスに分割するマイクロサービスは、コンテナに自然に適合します。クラウド上のアプリケーションには、フェイルオーバー、柔軟なスケーリング、高速な起動と停止が必要であり、これらはマイクロサービス アプリケーションの設計要件でもあります。コンテナとコンテナオーケストレーション技術の発展は、マイクロサービスの開発を大きく促進したと言えます。逆に、マイクロサービスアプリケーションの開発はコンテナ技術の推進も促進しました。

マイクロサービスは分散システムであるため、分散システムの設計は複雑です。マイクロサービス システム設計の複雑さを解決するために、さまざまなマイクロサービス ガバナンス フレームワークが登場しました。より人気のあるものには、Spring Cloud、Dubbo、Istio などがあります。

Spring Cloud は、優れたオープンソースのマイクロサービス プロジェクトに基づいたマイクロサービス ガバナンス パッケージの完全なセットです。さまざまなソリューションとオープンソース コンポーネントを選択できます。より完全なソリューションは、Spring Cloud Netflix です。 Spring Cloud は現在、世界で最も広く使用されているマイクロサービス ガバナンス フレームワークです。既存の Spring エコシステムを活用し、SpringBoot とシームレスに連携できます。

Dubbo は、中国の Alibaba が提供するオープンソースのサービス ガバナンス プロジェクトであり、Spring とも統合されています。多くの国内インターネット企業がマイクロサービス フレームワークとして Dubbo を選択しています。

Istio はオープンソースのサービス メッシュ プロジェクトであり、次の章で紹介します。

• サービスメッシュ

前述したように、Docker と Kubernetes はアプリケーションのデプロイ、スケジュール、更新の問題を解決しました。ただし、分散システムであるマイクロサービス アプリケーションでは、サービス検出、障害ヒューズ、負荷分散など、多くの実行時の問題を処理する必要があります。これらの問題を解決するために、業界ではマイクロサービス ガバナンス フレームワークが徐々に開発されてきました。初期のマイクロサービス ガバナンスは、Spring Cloud や Dubbo などの開発フレームワークに基づいていました。これらの開発フレームワークは、マイクロサービスの実行時の問題を非常にうまく解決しますが、開発言語のロックイン、アプリケーションへの侵入性、開発と運用の責任の不明確さなどの欠点があります。このような環境でサービス メッシュが登場しました。

サービス メッシュは、マイクロサービス アプリケーション内の内部サービス間トラフィックを制御および監視するために使用されるソフトウェア インフラストラクチャ レイヤーです。これは通常、アプリケーション コードと一緒にデプロイされ、ネットワーク プロキシとして機能する「データ プレーン」と、それらのプロキシと対話する「コントロール プレーン」の形式をとります。このモデルでは、サービス メッシュはビジネス開発者に対して透過的であり、プラットフォーム オペレーターはビジネスを気にすることなくアプリケーションを効果的に運用および保守できるため、アプリケーションの信頼性、セキュリティ、可視性が確保されます。さらに、サービス グリッドは、ビジネス アプリケーション開発プロセスへの侵入を最小限に抑え、すべての言語に適しています。

サービス メッシュにとって最も重要なオープン ソース プロジェクトは Istio です。 Istio は、マイクロサービス アプリケーションのさまざまなニーズを満たすために、Kubernetes 環境に基づく完全なソリューションを提供します。 Istio は、Kubernetes の Pod を通じて各マイクロサービス インスタンスにサイドカーを挿入し、ビジネス インスタンスのすべての外部トラフィックをプロキシします。これにより、サービス登録の検出、構成管理、回路遮断、リンク追跡など、マイクロサービス ガバナンス フレームワークに必要な動作の洞察と運用制御機能が実現されます。柔軟なグレースケールリリース戦略構成も提供できます。

• 宣言型API

宣言型 API の反対は命令型 API です。命令型 API は各操作ステップを提供し、ターゲット システムはその手順に従って実行するだけで済みます。ターゲット システムは結果を呼び出し元に返し、呼び出し元は結果を処理します。宣言型 API は最終状態を提供し、ターゲット システムは要件を満たすためにリソースを操作し、呼び出し元が介入する必要はありません。

宣言型 API の利点は、分散システム間の配信が簡素化されることです。プロセスの詳細については心配する必要はありません。宣言型アプローチにより、ユーザーの作業負荷が大幅に軽減され、開発効率が大幅に向上します。これは、宣言型アプローチによって必要なコードを簡素化し、開発者の作業を軽減できるためです。開発に命令型のアプローチを使用すると、構成はより柔軟になりますが、作業量が増えます。

宣言型 API の優れた例は Kubernetes です。 K8s を操作するために使用される yml ファイルはすべて宣言型です。 Terraform など、デプロイメント用の宣言型 API を備えたオープンソース プロジェクトもいくつかあります。

2. クラウドネイティブの開発動向

1. 運用保守が衰退し、サービスメッシュが主流となり、サーバーレスが徐々に推進される

クラウドコンピューティングの発展方向の一つは、運用・保守を分散化し、業務に関係のない管理機能や運用・保守作業をできるだけインフラ側に移し、アプリケーションが業務機能の開発・運用に集中できるようにすることです。この傾向の進化は、クラウド コンピューティングの開発方向に影響を与えています。仮想化から始まり、IaaS、PaaSへと、アプリケーションシステムの運用保守責任の一部をプラットフォームの運用保守に引き継ぐプロセスです。

▲運用・保守機能は下方にシフト

PaaS は、クラウド アプリケーション用の実行コンテナを提供し、アプリケーションの展開とランタイム管理の問題を解決します。ただし、特にマイクロサービス アプリケーションの場合、アプリケーションには依然として多くの運用と保守の作業が残っています。サービスの公開と認識、マルチインスタンス アプリケーションの負荷分散、サービス障害の検出と分離、グレースケール リリース戦略など、解決する必要がある問題は数多くあります。これらは PaaS レベルでは解決できず、通常は開発フレームワーク (前述のマイクロサービス ガバナンス フレームワーク) によって解決されます。

ビジネス機能の提供はビジネス開発チームの価値を反映するものであるため、ビジネス開発チームはビジネス機能の実現に注力し、非機能要件はプラットフォームで処理する必要があります。この需要に基づいて、サービス グリッドが登場しました。マイクロサービス ガバナンスの問題は、サービス グリッドによって統一的に運用および管理できるため、ビジネス アプリケーションはビジネス機能の実現にのみ集中する必要があります。

サービス メッシュの登場後も、ビジネス アプリケーションのライフ サイクルはアプリケーションによって維持および保証される必要があります。これは徐々にサーバーレスの概念へと進化しました。サーバーレスとは​​サーバーが存在しないという意味ではありませんが、開発チームはサーバーの外観を気にしません。開発チームは、必要な実行インスタンスを取得するためにビジネス コードを送信するだけで済みます。アプリケーション開発チームの場合、サーバーは存在しません。

現在の業界の技術動向から判断すると、ServiceMesh のコンセプトはほとんどの大手クラウド企業に受け入れられており、ServiceMesh が批判されてきたパフォーマンスの問題も徐々に解決されつつあります。今年はさらに多くのマイクロサービス アプリケーションがこの基本機能を採用すると予想されます。サーバーレスは、フルマネージド サービスや FaaS (Function as a Service) を含め、まだ開発の初期段階にあります。完全に管理されたサービスは、パブリック クラウドで徐々に成熟してきました。ハイブリッドクラウドの普及に伴い、フルマネージドサービスが徐々に発展していきます。 FaaS は開発モードの変更を伴うため、既存の開発モデルを置き換えるには時間がかかります。ただし、適切なアプリケーション シナリオによっては、アプリケーションがますます増えることになります。

2. ソフトウェアとハ​​ードウェアを組み合わせて仮想化のパフォーマンス問題を解決する

クラウド コンピューティングの発展に伴い、コンピューティング仮想化からストレージ仮想化、ネットワーク仮想化に至るまで、仮想化テクノロジがますます使用されるようになっています。仮想化技術は多くの利点をもたらします。仮想化はインフラストラクチャ サービスの基盤です。仮想化により、コードとしてのインフラストラクチャを実現でき、リソースの管理性と自動化が大幅に向上します。しかし、仮想化によって、パフォーマンスの低下とソフトウェア プロセス間の相互影響という別の問題が発生します。

パフォーマンスが低下すると、実際のビジネス消費量よりも多くのリソースが必要となり、サーバー リソースのコストが増加します。プロセス間の相互影響により、クラウド プラットフォーム全体のパフォーマンスに問題が生じます。ネットワーク仮想化とストレージ仮想化の両方で、ネットワーク トラフィックと IO を処理するためにソフトウェア プロセスを使用する必要があります。分散型の高可用性を実現し、パケット転送を削減するために、基本的な SDN および SDS プロセスは通常、アプリケーション プロセスと同じクラスターに展開されます。その結果、一部の SDN および SDS 管理プロセスが配置されているサービスがさまざまな理由で CPU またはメモリを過剰に占有し、ネットワークおよび IO 要求をタイムリーに処理できなくなり、クラウド プラットフォーム全体のパフォーマンスが低下する可能性があります。

これら 2 つの問題を解決する 1 つの解決策は、ソフトウェアとハ​​ードウェアを組み合わせることです。スケジュール管理、ネットワーク仮想スイッチ、ストレージ仮想ストレージ ゲートウェイなどのクラウド プラットフォームの管理プロセスは、オペレーティング システム プロセスから分離され、特別に設計されたサーバー ボード上で実行されます。これらのボードは特別に設計されており、通常はプログラム可能なカスタマイズされたチップ (FPGA) が含まれています。これにより、管理プロセスとビジネス プロセスを分離して相互影響を回避しながら、仮想化の利点を維持できます。同時に、カスタマイズされたチップ（FPGA など）を介した処理により、パフォーマンスが大幅に向上し、仮想化による損失が大幅に削減されます。

現在、主要なパブリック クラウド ベンダーはすべて、独自のパブリック クラウド アプリケーションに関連製品を持っています。

3. コンテナと仮想マシンのさらなる統合

コンテナと仮想マシンの利点と欠点は、コンテナ技術が誕生した当初から議論されてきました。コンテナは軽量で、パッケージ化機能が優れており、展開も簡単です。特にKubernetesの登場以降は、仮想マシンに取って代わる可能性が高まっています。しかし、重いアプリケーション（リレーショナル データベース、ビッグ データなど）の処理に関しては、コンテナー テクノロジはやや不十分であるように思われます。さらに、コンテナ テクノロジは、リソースの分離とセキュリティの点でまだ仮想マシンのレベルに達していないため、多くのシナリオでは仮想マシンが依然として重要な役割を果たしています。

このような状況において、コンテナ技術と仮想化技術の統合を実現し、両者の強みをいかに発揮させるかが、クラウドコンピューティングにおける開発課題となっています。現在、主なテクノロジの種類は 3 つあります。1 つはコンテナ仮想マシンのハイブリッド展開です。 1 つは軽量仮想マシンです。そして最後は安全なコンテナです。

コンテナと仮想マシンの混合デプロイメント。コンテナや仮想マシンのオーケストレーション エンジンを変更することで、一連の API を通じてコン​​テナや仮想マシンのデプロイメントをサポートすると同時に、仮想化層とコンテナ間のネットワークを開き、より効率的な相互アクセスを可能にすることができます。これは、一部の従来の仮想化ベンダーの現在の実践です。現在、より成熟した実装としては、Redhad の Kubevirt が含まれます。

軽量の仮想マシン。仮想マシンイメージが大きすぎる、起動が遅い、大量のリソースを消費するなどの問題を解決するために、業界では軽量の仮想マシンソリューションが提案されています。軽量仮想マシンは、合理化された独自のライブラリ オペレーティング システム (LibraryOS) を使用します。これは、高級言語を使用してコンパイルでき、商用クラウド プラットフォーム仮想マシン ハイパーバイザー上で直接実行できます。コンテナ技術と比較すると、多くの利点があります。仮想マシンに匹敵する分離機能を備えているだけでなく、起動時間が速く、攻撃対象領域も小さくなります。軽量仮想マシンは独自のオペレーティング システムを使用するため、言語サポートと互換性は他のソリューションに比べて劣ります。 Unikernel、Drawbridge、MirageOS、HaLVM など、軽量の仮想マシン テクノロジが数多く利用可能です。

セキュア コンテナー、またはサンドボックス コンテナー。コンテナの分離の弱点を解決するために、セキュア コンテナはコンテナ操作用のサンドボックスを提供します。サンドボックスで実行されるアプリケーションには独自のカーネルと仮想デバイスがあり、これらはホストや他のサンドボックスとは区別されます。セキュア コンテナの利点は、現在のコンテナ イメージと互換性があり、コンテナ オーケストレーション Kubernetes に大きな変更を加えずに直接適用できることです。欠点は、パフォーマンスと柔軟性がいくらか犠牲になることです。現在、セキュア コンテナのオープン ソース プロジェクトには、Kata コンテナと Google の gVisor が含まれます。

セキュア コンテナと軽量仮想マシンの実装には重複する部分もありますが、どちらの方向に進むにせよ、仮想マシンとコンテナを統合するという一般的な方向に向かっています。目標は、コンテナの軽量、高速配信、柔軟なスケジュール機能を活用しながら、ビジネス アプリケーションの分離とセキュリティを強化することです。

III.概要

クラウド ネイティブ テクノロジーは、現在の技術段階におけるエンタープライズ IT システムに最適なモデルの集合です。クラウドネイティブのテクノロジーと設計パターンに従うことで、企業はクラウド コンピューティング プラットフォームの利点を最大限に活用しながら、開発効率への影響を最小限に抑え、安定した効率的なシステムを実現できます。テクノロジーは常に進化しており、クラウドネイティブ テクノロジーも継続的な更新と反復のプロセスです。対応する開発習慣や方法もそれに応じて変化します。