マルチクラウド クラスターを使用してアプリの導入時間を月に数百時間短縮する方法

アプリケーションの現状

今日のソフトウェア導入環境では、マイクロサービスが標準となっています。アプリケーションをさまざまなサービスに分けてしまうと、組織が導入するアプリケーションの数が増えてしまいます。通常、その数は何百倍、何千倍にもなります。100個のアプリケーションであれば、何千ものマイクロサービスになってしまうことも少なくありません。

最終的な目標は、アプリケーションや新機能を迅速にエンドユーザーやお客様に提供することです。

課題は、いかにして導入速度に影響を与えずに、何千ものサービスを継続的に導入するかということです。

今日、その答えの一部は導入にKubernetesを使用することです。Kubernetesは、マイクロサービス ベース アプリケーションの大規模な導入において事実上の標準となっています。これによって再現性、拡張性、そして最も重要な導入速度が向上するため、エンドユーザーに迅速に機能を提供できます。

マイクロサービスの導入規模を拡大している組織は、複数のKubernetesクラスターの運用を検討しています。多くの場合、これらの複数のクラスターは異なる場所で運用されます。こういった場所は、支店や小売店のサイト、異なるクラウド プロバイダー、その両方が混在している場所となることがほとんどです。

規模が大きくなるほど困難になる

複数のKubernetesクラスターでアプリケーションの導入を高速かつ大規模に管理することは困難です。現在、各アプリケーションは複数のサービスで構成されています。これには複数のアプリケーション、サービス、サイト、Kubernetesクラスターが含まれています。

これは、アーキテクチャ的には単一のクラウド プロバイダーやアプリケーションに特化した複雑な構築・導入パイプラインになる場合が多くあります。カスタムメイドは脆弱であることもあり、アプリケーションの導入中に壊れてしまう傾向があります。

大規模な導入

現在は、複数のアプリケーションやサービスを分散した場所にまたがって導入する機能があります。つまり、複数のKubernetesクラスターにアプリケーションを迅速に導入する機能です。これにより、導入時間が短縮されて複雑さが解消され、迅速に新しい機能を提供できるため、最終的にエンドユーザーの満足度が向上することになります。

アプリケーション開発者としては、複数のKubernetesクラスターを単一の実体として扱うことができるようになりました。つまり、単一の「仮想の」Kubernetesクラスターにアプリケーションを導入すると、実際には複数のクラスターにアプリケーションを導入していることになります。これらの複数のクラスターは、隣り合っていることも世界の反対側にあることもあります。

複数の場所にアプリケーションを導入できるようになったことで、導入管理や導入速度も大幅に変わりました。カスタムメイドで脆弱な導入パイプラインを操作したり、クラウド プロバイダーごとの微妙な違いに悩んだりする必要はもうありません。

標準的な導入アプローチを採用したことで、迅速にアプリケーションを導入してエンドユーザーやお客様に機能を提供できるようになりました。

すべてネイティブ

開発者から見た最大の利点は、ネイティブ ツールを使用してアプリケーションをKubernetesに導入できることです。熟知した導入方法やツールを使用して複数のクラスターに導入でき、開発者側で何か特別なものは必要はありません。

技術的な面では、Kubernetesのネイティブ構造である両方のラベルを使用して導入する機能と、導入先のサイトを1つ以上選択できる機能があります。また、kubectlコマンドのようなKubernetesのネイティブ ツールや、標準化されたKubernetesの導入ファイルやマニフェストも使用できます。これは、Kubernetesと対話する標準的な方法です。これにより、使い慣れたツールを使用して簡単に導入でき、さらに複数のクラスターや場所に迅速に導入できるという利点があります。

大きな特徴は、Kubernetesのラベルを使用して、導入先として1つまたは複数のクラスターを簡単に選択できることです。ラベルとはKubernetesのネイティブ構造で、これによりアプリケーションに「タグ」を付けることができます。アプリケーションに「タグ」やラベルを付けることで、1つまたは複数のKubernetesクラスターの場所を指定できます。

まとめ

F5のVolterraプラットフォームを使用し、複数の場所で大規模にアプリケーションを導入することで、開発者の日常的な負担が軽減されます。Kubernetesのネイティブ構造を使用してアプリケーションを導入できることで、時間を節約し、アプリケーションを必要としているユーザーの元に迅速に提供できます。

監視とポリシーを一元化し、簡単に分散導入できるため、開発者のオーバーヘッドが解消されます。

つまり、継続的導入の速さとは、アプリケーションや機能をより迅速にお客様に提供することを意味するのです。