IBM Developer Japan Webサイトは2021年3月15日をもって終了となり、日本語コンテンツの一部は、オープンソースとして、提供予定です。 URLはこちら

コンテナ・オーケストレーションとは何か

コンテナ・オーケストレーションとは?それが必要な理由とは?

こんにちは、IBM CloudのSai Vennamです。今回はコンテナ・オーケストレーションについてお話しましょう。

これまでにコンテナ化テクノロジーやオーケストレーション・プラットフォームとしてのKubernetesについてお話してきましたが、少し戻って、そもそもなぜコンテナ・オーケストレーションが必要なのかお話しましょう。

ビデオをお楽しみください。

3

つのコンテナ化されたマイクロサービスを使用した例

例を使ってご説明しましょう。コンテナ化された3つの異なるマイクロサービスがあるとします。フロントエンド、バックエンド、データベース・アクセス・サービス、

Video–Container Orchestration Explained-2

これら3つのサービスは連携して動作し、エンド・ユーザーが使用できるように公開されます。

開発者はこのレイアウトに焦点を当てます。開発者はエンド・ユーザーを考慮します。エンド・ユーザーがフロントエンドのアプリケーションにアクセスし、フロントエンドはバックエンドに処理を依頼し、バックエンドはデータベース・サービスを使ってデータを保管します。開発者が終始注目するのはこのレイヤーです。

!Video–Container Orchestration Explained-3](https://developer.ibm.com/developer/default/videos/new-builders-container-orchestration/images/fig02.jpg)

オーケストレーション・レイヤー

この下にオーケストレーション・レイヤーがあります。マスターとも言います。今回はKubernetesを例に使用しましょう。コンピューター・リソース上で実行される様々なアプリケーションを管理するマスター・ノードのようなものがここにあります。

Video–Container Orchestration Explained-4

しかし繰り返しになりますが、このレイアウトで開発者が注目しているのはこのスタックだけです。開発者は、特定のコンテナと、そこで実行される内容に注目します。

開発者の視点から個々のコンテナを見る

コンテナ内にはいくつか重要事項があります。アプリケーション、オペレーティング・システム、依存関係、ユーザー定義物などで、これらがすべてコンテナに含まれています。

Video–Container Orchestration Explained-5

運用チームの視点

運用チームはもっと大きな視点で見ています。スタック全体を見ているのです。運用チームには注意を向けなければならないものが沢山ありますが、こちらのレイアウトで、チームが複数サービスから成るアプリケーションをデプロイする方法を説明しましょう。

Video–Container Orchestration Explained-6

アプリケーションのデプロイ

まずデプロイについて説明しましょう。

Video–Container Orchestration Explained-7

これを見るとこちらと似ていますが、大きな違いは、コンテナでなく、実際のコンピューター・リソースである点です。VMやKubernetesの世界では、ワーカー・ノードと呼ばれます。これら1つ1つが実際のコンピューティングを行うワーカー・ノードです。8GBのRAMの4vCPU(仮想CPU)などが、ここにある各ボックスに該当します。

Video–Container Orchestration Explained-8

オーケストレーション・プラットフォームを使って最初に行うのは、アプリケーションをデプロイすることです。単一ノードで始めるとしましょう。これはマスターです。単一ノードに3つの異なるマイクロサービスを1つずつデプロイします。フロントエンド、バックエンド、データベース・アクセス・サービスです

ワーカー・ノードで使える十分なコンピューティング・リソースを取り込み済みであると仮定します。

Video–Container Orchestration Explained-9

アプリケーションのスケーリング

ではマスターにワーカー・ノードを追加して、アプリケーションのスケジューリングとスケーリングを行っていきましょう。これが次の部分です。オーケストレーション・プラットフォームで2番目に行うのは、アプリケーションをスケールアウトすることです。

Video–Container Orchestration Explained-10

例えばフロントエンドを2倍にスケールアウトするとします。バックエンドは3倍に、データベース・アクセス・サービスも3倍にスケールアウトするとしましょう。

Video–Container Orchestration Explained-11

オーケストレーション・プラットフォームは、個々のマイクロサービスやコンテナを完全にスケジューリングして、コンピューター・リソースを最大限に活用できるようにします。オーケストレーション・プラットフォームの重要な機能の1つが、スケジューリングです。

Kubernetesの優位性:デプロイ、開発、モニタリング

Kubernetesの3大メリットと言えば、デプロイ、開発の簡素化、モニタリング・ツールの提供です。これについて説明していきましょう。

Video–Container Orchestration Explained-00

ネットワーキング

次にネットワーキング、つまり他の人がこれらのサービスにアクセスできるようにする方法について説明します。これがオーケストレーション・プラットフォームで行える3番目のことです。それぞれのコンテナを代表するサービスのようなものを作ることもここに含まれます。

Video–Container Orchestration Explained-12

このようなことを任せられるオーケストレーション・プラットフォームがないと、自分でロード・バランサーを作らなければなりません。さらにサービスやサービス・ディスカバリーも自分で管理しなければならないでしょう。これらのサービスは相互にやり取りする際に、異なる各コンテナのIPアドレスを検索して解決したり、正しく実行されているかどうか確認したりすることはありません このようなシステム相互の管理は、オーケストレーション・プラットフォームの仕事です。

Video–Container Orchestration Explained-13

これによって、各サービスへのアクセスを単一のアクセス・ポイントとして公開することができるのです。こちらと同じく、エンド・ユーザーがフロントエンドのアプリケーションにアクセスすると、オーケストレーション・プラットフォームがそのサービスを公開します。その際にこれらのサービスは外部に公開されずに、フロントエンドはバックエンドに、バックエンドはデータベースにアクセスできます。これがオーケストレーション・プラットフォームの3つ目の機能です。

Video–Container Orchestration Explained-14

洞察

最後に強調しておきたいのが洞察です。実稼働環境でのアプリケーションの使用において、洞察は非常に重要です。

Video–Container Orchestration Explained-15

開発者が注目するのはアプリケーションであると述べましたが、ポッドの1つが停止してしまったとしましょう。オーケストレーション・プラットフォームは即座に別のポッドを起動して、それがサービス範囲に含まれるように設定します。これが自動で行われます。

Video–Container Orchestration Explained-16

加えて、オーケストレーション・プラットフォームにはいくつものプラグ可能なポイントがあります。ユーザーはPrometheusやIstioのような主要なオープン・ソース・テクノロジーを使用して、直接プラットフォームに接続し、ロギングやアナリティクスなどを実行する機能を公開できます。さらに、サービス・メッシュ全体を見渡せるような優れた機能もあります。

サービス・メッシュ全体を見る

ご使用のマイクロサービスがどのようにやり取りするのか確認してみるとよいでしょう。この例はかなり単純なものですが、練習としてこれを見ていきましょう。

エンド・ユーザーがフロントエンドのアプリケーションにアクセスします。他にもデータベースとバックエンドの2つのサービスがあります。.

Video–Container Orchestration Explained-17

これはとても単純なサービス・メッシュの例で、サービスは3つしかありません。しかし、各サービスがどのようにやり取りするのか確認しておくことはとても有用です。ユーザーがフロントエンドにアクセスして、フロントエンドがバックエンドに、バックエンドがデータベースにアクセスします。

Video–Container Orchestration Explained-18

運用チームは、フロントエンドが直接データベース・サービスにアクセスする場合もあることに気付きます。その頻度も把握できます。サービス・メッシュのような機能を使うと、毎秒ごとのオペレーションなどに関する洞察を得られます。

例えば、フロントエンドへの要求が5件/秒、バックエンドへの要求が8件/秒、データベース・サービスへの要求が3件/秒あります。ところがフロントエンドからデータベース・サービスへの要求が0.5件/秒あります。運用チームは、要求を調べ、個々のサービスを通してトレースすることにより、ここに問題があると特定しました。

Video–Container Orchestration Explained-19

これは、IstioとKiali(重要なサービス・メッシュ機能を持つツール)などを活用して実行中のサービスに関する洞察を得る方法を示す簡単な例です。

オーケストレーション・プラットフォームにはサポートが必要な機能が多くあります。運用チームやサイト信頼性エンジニア(SRE)などの役割が登場しているのはそのためです。実稼働環境でアプリケーションを実行する際に考慮すべき事柄が多いため、このような役割が増えつつあります。開発者の見ている世界はとても特別で、このコンテナ内に焦点を絞っているのです。

最後までご覧いただき、ありがとうございました。

Sai Vennam Developer Advocate—IBM Cloud Kubernetes Service