クラウドネイティブ: インターネット後半で知っておくべきこと

現在の急速に変化するモバイル インターネット時代では、絶えず変化する市場の需要を素早く把握し、できるだけ短い時間で独自のアプリケーションをリリースして市場を獲得することが、多くの企業にとって、激しい競争の市場で足場を築くための勝利の武器となっています。世界中のあらゆる格闘技に勝つ唯一の方法は、速さです。明らかに、従来の開発モデルでは、急速に変化する市場の需要に適応できなくなりました。このような背景から、アジャイル、リーン、DevOps といった新しい概念が生まれました。特にクラウドネイティブに代表される次世代アーキテクチャはロケットのような発展段階に入っています。コンテナ、Kubernetes、サーバーレスに代表される新しいテクノロジーが、モバイル インターネットを急速に進化させています。

クラウド ネイティブは単一のテクノロジーではなく、テクノロジーと管理方法の集合です。本稿では、クラウドネイティブアーキテクチャの実践方法を理解する前に読者が体系的な思考を身に付けられるよう、クラウドネイティブインフラストラクチャの代表的な技術と、クラウドネイティブを使用して構築されるクラウドネイティブアプリケーションの特徴について詳しく説明します。

容器

現実世界におけるコンテナ技術が貿易のグローバル化のプロセスを加速させたのと同様に、コンテナ技術の出現により、マイクロサービス アーキテクチャの下で多数のアプリケーションを展開するという問題も解決されました。コンテナ環境の自己完結型の性質により、一度構築すればどこでも実行できます。仮想マシンが解決できる問題だけでなく、高いリソース要件のために仮想マシンが解決できない問題も解決します。コンテナの主な機能には、アプリケーションの依存関係の分離、アプリケーション イメージの作成と複製、配布が容易ですぐに使用できるアプリケーションの作成、インスタンスの簡単かつ迅速な拡張のサポートなどがあります。

Docker は、人気のあるオープンソース アプリケーション コンテナ エンジンです。 Docker コンテナ化テクノロジーに基づいて、ユーザーはマイクロサービスとその必要なすべての構成、依存関係、環境変数をコンテナ イメージにパッケージ化し、Docker がインストールされた新しいサーバー ノードに簡単に移植できます。運用および保守担当者は、基盤となるオペレーティング システムを気にする必要がなく、環境を再構成する必要もありません。そのため、コンテナーは単一のマイクロサービスを展開するための最も理想的なツールとなります。

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

従来の物理サーバーや仮想マシンの展開方法では、それぞれにペットと呼ばれる独自の特性があります。ホストに展開されたアプリケーションに障害が発生した場合、問題を解決してビジネスを回復するための適切な解決策を指示する必要があります。ただし、クラウドネイティブ アーキテクチャでは、デプロイメント方法を「家畜」と呼びます。アプリケーションがデプロイされると、アプリケーション インフラストラクチャは変更されなくなります。更新が必要な場合は、パブリック イメージを変更して新しいサービスを構築し、古いサービスを直接置き換える必要があります。直接置き換えが実現できる理由は、コンテナが自己完結型の環境（アプリケーションの実行に必要な依存関係をすべて含む）を提供するため、アプリケーション側ではコンテナ内でどのような変更が行われたかを気にする必要がなく、コンテナイメージ自体を変更するだけで済むからです。そのため、クラウド対応のインフラストラクチャはいつでも交換・置き換えが可能です。これは、コンテナがクラウド時代のアプリケーション インフラストラクチャである俊敏性と一貫性の機能を備えているためです。

コンテナ オーケストレーション エンジン関連のツールには、コンテナ管理とスケジューリングの問題を解決するために使用される Kubernetes、Swarm などがあります。現在、Googleがオープンソース化したKubernetesがコンテナオーケストレーション市場を基本的に統一し、コンテナクラスタの自動展開、スケーリング、メンテナンスなどの機能を実現しています。

Kubernetes と Docker は互いに補完し合います。 Docker は Kubernetes によって内部的に使用される低レベルのコンポーネントであり、Kubernetes は Docker クラスターを効率的に管理およびスケジュールできます。

宣言型API

宣言型アプローチは命令型アプローチとは異なります。何かが到達したい目標状態をツールに記述すると、ツールは目標状態を内部的に達成する方法を計算して実装します。つまり、宣言型設計では目標状態を記述するため、実装プロセスにおける異常な状況やスケジュール設定のプロセスが大幅に簡素化されます。私たちは結果だけに集中する必要があります。どのような方法を使用しても、結果は常に私たちが定義した方向に近づきます。宣言的設計は設計コンセプトであり、システムをより堅牢にする動作モードでもあります。

マイクロサービス

マイクロサービスは、モノリシックアプリケーションと比較して、アーキテクチャを細分化することで、後期段階でのモノリシックアプリケーションの拡張の難しさや開発効率の低さなどの問題を解決します。ドメイン モデルによれば、巨大なモノリスは明確な境界を持つマイクロサービスに分割され、各サービスは独立かつ反復可能な状態に保たれます。高いサービス自律性、効率的な反復、容易な拡張、多言語プログラミングのサポートなどの利点があります。
マイクロサービスの柔軟性とアジャイル開発のメリットを享受する一方で、多くのマイクロサービスは、運用と保守、監視、展開、分散トランザクション、サービス間の呼び出しにおいて新たな課題ももたらします。

サービスメッシュ

マイクロサービス間の呼び出しを実装する方法と、中間呼び出し戦略を実行するには、サービス グリッドを使用する必要があります。現在、サービス メッシュ アーキテクチャには、侵入型と非侵入型の 2 種類があります。違いは、侵入型アーキテクチャは開発フレームワークに統合する必要があり、一部の機能を実装するには SDK を使用する必要があることです。非侵入型アーキテクチャは、展開フェーズ中にサイドカー モードでのビジネス操作と組み合わされ、ネットワーク トラフィックを引き継ぐことによって透過プロキシが実装され、一連のネットワーク ポリシーと監視が実装されます。開発者はコードを変更することなくビジネスに集中するだけで済みます。この方法はサービス メッシュによって表され、アプリケーションを軽量化します。最も人気のあるサービス メッシュ テクノロジーは、Istio、Linkerd、Dubbo Mesh などです。これらをインフラストラクチャ層に組み込むことで、ユーザーは複雑な環境と複雑な依存関係を持つアプリケーションを迅速にオーケストレーションできます。同時に、開発者はアプリケーションの監視、スケーラビリティ、サービスの検出、分散トレースなどの面倒なことにあまり気を配る必要がないため、独自のビジネス プログラム開発に集中することができます。

上記はDevOpsエンジニアのXue Lei氏のマイクロコラムからの抜粋です。クラウド ネイティブ テクノロジーを把握し、新しいテクノロジーの進歩に遅れずについていきましょう。 3元コラム「クラウドネイティブアーキテクチャ実践」を購読するにはクリックしてください！