この記事はBob Reselmanによるゲスト投稿です。

エンタープライズレベルのコンテナーオーケストレーションの分野では、Kubernetesが急速に定番のオープンソーステクノロジーになりつつあります。Kubernetesを利用すると、コンテナーを自動で大規模にデプロイできるだけでなく、コンテナーの実行に信頼性があり、フォールトトレラントであることを保証できます。

Kubernetes（省略してK8sと呼ばれることもあります）は、Googleによって開発され、2015年に正式にリリースされました。2018年には完全なオープンソースプロジェクトとしてCloud Native Computing Foundation (CNCF)に引き継がれました。Kubernetesに関する専門知識には高い需要があり、CNCFはKubernetes Administratorの認定を行っているほどです。いずれKubernetesはソフトウェア開発ライフルサイクルに携わるすべての人たち―開発者、運用担当者、テスト技術者―に影響を与えるようになるでしょう。それほどKubernetesはすごいのです。

しかしまだ経験がない場合、なぜそんなにKubernetesが騒がれているのか不思議に思うかもしれません。では、この後詳しく見ていきましょう。

Kubernetesの何がそんなにすごいのか？

Kubernetesは分散コンピューティングの根本的な問題を解決します。つまり、機能面でもリソース要件という点でも、常に変化にさらされているコンテナー化された大規模アプリケーションをインターネット上でいかに確実に実行し続けるかという問題です。Kubernetesは、物理マシンまたは仮想マシンのクラスター上で作成・実行・維持すべきコンテナー駆動アプリケーションを事前定義したステートという概念を使用して問題を解決します。

デプロイメントエンジニアはアプリケーション（サービス）のステートを作成し、Kubernetesにサブミットします。するとKubernetesがアプリケーションを作成・デプロイし、ずっと、あるいはオフラインにされるまでアプリケーションを維持します。

サンプルを例に考えてみましょう。

サブミットされた写真の周りに赤い境界線を付加する機能を持ったクラウドサービスがあるとします（図1を参照）。

さらに、サービスは後で必要になったときのために作業コピーを保存します。このサービスは1分間に10,000リクエストをサポートすることが期待されています。これはかなり重い要求です―１つの演算インスタンスで処理できる範囲を超えています。そのため、多数の演算インスタンスを用意し、それぞれで写真処理のコピーを実行する必要があります。（演算の冗長性がある状況では、通常、ロードバランサ―が多数の利用可能なインスタンスの1つにリクエストを届けます）

アプリケーション設計者は写真処理のロジックをDockerイメージに入れ、コンテナーイメージをDocker Hubなどのパブリックリポジトリに保存します。その後、イメージは独立したコンテナーとして仮想マシンにデプロイされます。

それでは、従来型のデプロイメントを行いましょう。コンテナーイメージができたら、デプロイメントエンジニアは仮想マシンのクラスターを作成し、各マシンにコンテナーをデプロイし、すべてのネットワークとロードバランスを調整します。これは、自動化していても相当に大変な作業であり、時間がかかったりエラーが起きることもあります。

次に、Kubernetesを使用した場合のアプローチを見てみましょう。

コンテナーを作成し、仮想マシンにコンテナーをデプロイし、サービスを外部のユーザーが利用できるようネットワークを設定するという時間のかかるタスクをデプロイメントエンジニアにさせる代わりに、Kubernetesを使用します。クラウドまたはデータセンターにKubernetesクラスターを用意するか、既存のKubernetesクラスターを使用します。クラスターを指定したら、一連のマニフェスト（YAMLファイル）を作成し、アプリケーションのさまざまな側面を記述します。これには特定の時点で実行する必要があるコンテナーの数や、加工した写真のコピーを保存するストレージリソースの場所、写真処理サービスへのリクエストを処理するルーティングの設定などが含まれます。

マニフェストの中には、写真処理のコンテナーをホストするポッドの構造を定義するものもあります。

ポッドとは

ポッドは1つまたはそれ以上のコンテナーをホストできるKubernetesオブジェクトです。高可用性を保証するため、デプロイメントエンジニアはKubernetesをオーケストレーションして多数のポッドのコピーをさまざまな仮想マシン上で実行します。ロードバランシングテクノロジーはKubernetesと連携してトラフィックを特定のポッドに届けます。

これらのマニフェストはアプリケーションのステートを定義します。デプロイメントエンジニアがKubernetesにマニフェストをサブミットすると、Kubernetesはクラスター内で必要な数のポッドをホストできる容量を持ったノード（仮想マシン）を探します。

KubernetesはDocker Hubなどのイメージリポジトリからダウンロードしたコンテナーイメージを使用してコンテナーを含むポッドを作成します。Kubernetesはデプロイメントマニフェストに従って必要な数のポッドを作成します。その後、指定されたノードにポッドを注入します。Kubernetesはサービスマニフェストの情報を使用して Kubernetesサービスを作成し、その背後でポッドを実行します。最後に、サービスマニフェストの記述に従ってサービスを公開します（図2を参照）。サービスが公開されると、アプリケーションは利用可能になります。

ここからが本当にすごい部分です。いったんアプリケーションをデプロイすると、Kubernetesは内部的なエラーが発生した場合にもアプリケーションの状態が維持されることを保証します。ノードがオフラインになると、Kubernetesは壊れたノードから別の健全なノードにポッドを移動します。ポッド自体が止まったときは、ポッドを補充します。何らかの理由でクラスター全体が飛んだ場合も、新しいクラスターに再度マニフェストを適用するだけで、アプリケーションは元の状態に復元されます。また、クラスター内でローリングアップデートを適用してポッドの任意のコンテナーを変更できます。アップデートで何かがうまくいかなかった場合はロールバックが可能です。

このように、Kubernetesはデフォルトで高いレベルの自動化を提供します。必要なのはアプリケーションのステートを定義することだけで、あとはKubernetesがやってくれます。

ただし、Kubernetesの背後にある全体的な概念がシンプルだからと言って、Kubernetesを利用するのが易しいというわけではありません。Kubernetesをマスターするには時間がかかります。マニフェストを作成するには、Kubernetesの詳細をいろいろと知っていなければなりません。ネットワークやアクセスの設定にはつまずきの原因が山ほどあります。さらに、重大なセキュリティ上の懸念に対応する必要もあります。また、Kubernetesのメリットをフルに享受するには、企業のソフトウェア開発ライフサイクルの一部のプロセスを変更する必要もあるかもしれません。それにはパフォーマンステストのアプローチも含まれます。

それでも、IT部門が奮起してKubernetesを運用し始めると、高い柔軟性と回復性が得られ、かなりの労力が節約されます。ただし、繰り返しますが、自分が何をしているかを理解していなければなりません。

Kubernetesがパフォーマンステストに与える影響

おそらく、テスト技術者にとってパフォーマンステストのやり方が一番大きく変わる点は、Kubernetesの下で実行されるアプリケーションは分散化され一時的なものであるという性質を考慮に入れる必要があることでしょう。忘れないでください、Kubernetesはステートを保証しますが、いつどこでステートが実現されるかは、ほとんどの場合、Kubernetes任せです。特に指定しないかぎりは、アプリケーションポッドの場所は、Kubernetesクラスター内でいつでも変わる可能性があります（Kubernetesにはpod affinityと呼ばれるメカニズムがあり、特定のポッドを特定のノードに割り当てることができますが、これはデフォルトの設定ではありません）。

たとえばパブリックURLに対するリクエストおよびレスポンス時間を計測するなど、クラスターの外側でパフォーマンスを計測することは、依然としてそれほど難しくはありませんが、クラスター内部で起きていることを把握するとなると、もっと複雑になります。内部的なパフォーマンスを詳しく把握するには、システムモニター、ログ、分散追跡ツールなどを利用してデータを収集する必要があります。テスト中にクラスター内で実行されている複数のノードやコンテナーにわたる実行時データを集約することは、パフォーマンスを確認するうえで一般的なテクニックです。

そのためパフォーマンステスターはHeapster、Prometheus、Grafana、InfluxDB、CAdvisorなどの基本的なモニタリングツールに関して実務的能力を持っている必要があります。これらのツールはクラスターを監視して継続的な動作状況をレポートするほか、危険な状況についても通知します。これらのツールやツールがレポートする情報を活用できることは、テスト技術者にとって必須の能力です。そうでなければ、先が見えないまま飛んでいくようなものです。実際、インターネット上で人間とコンピューターの間ではなくマシン間で行われるアクティビティが増えるにつれて、クラスター全体のマシン監視はテスト対象システムのパフォーマンスを確認するための主要な手段になるでしょう。

Kubernetesがますます広範囲の企業に取り入れられるにしたがって、パフォーマンステストは単にURLをひととおり実行することから、一時的に動作するマシンからなるクラスターに対してさまざまなアクティビティを呼び出し、クラスターの外部または内部のさまざまなタイプの結果を解析することへと発展します。パフォーマンステストへのアプローチが根本的に変化するのです。

まとめ

現在の広い採用状況を考えると、Kubernetesは今後も長い間ITシーン全体に影響を与え続けるだろうと予想されます。テスト技術者もその影響から逃れられません。現実として、KubernetesがIT全体に広がっていくだろうという観測が有力である以上、テスト技術者はKubernetesの下で動作するアプリケーションをテストする方法について、新たに検討する必要があるでしょう。

Kubernetesを扱うには、分散コンピューティングに対して今までとは異なるアプローチが必要です。Kubernetesの基本を理解することは、テスト担当者も含め、Kubernetesに関わるすべての人にとって重要です。Kubernetesに対応したパフォーマンステストプラクティスを採用し、組織のニーズに応え続けることは多くのIT部門にとって困難な課題になるでしょう。しかし、Kubernetesが企業の技術基盤にもたらす利点とコスト削減効果を考えれば、挑戦する価値のある課題です。

筆者のBob Reselmanについて:全国的に著名なソフトウェア開発者、システムアーキテクト、業界アナリスト、テクニカルライター/ジャーナリスト。コンピュータープログラミングに関する書籍のほか、ソフトウェア開発テクノロジーおよびテクニック、ソフトウェア開発カルチャーに関する記事を多数執筆。元Cap GeminiのPrincipal ConsultantおよびコンピューターメーカーGatewayのPlatform Architect。ロサンゼルス在住。現在は、ソフトウェア開発およびテスト活動のかたわら、自動化が雇用に与える影響に関する書籍を執筆中。連絡はLinkedInwww.linkedin.com/in/bobreselmanまで。

（この記事は、開発元Gurock社の Blog 「Kubernetes: Why It Matters for Performance Testing」2019年3月12日の翻訳記事です。）