Skip to content

導入

Red Hat OpenShift クラスタは、多くの場合、クラスタを所有する単一のテナント(または、顧客)のワークロードをホストするために使用されます。しかし、異なるテナントの複数のワークロードを同じクラスターで実行することもできます。この場合、それらのワークロードを互いに隔離して、テナント同士が干渉しないようにする必要があります。この記事では、OpenShiftでワークロードを分離して、複数のテナントで使用できるようにする方法を説明します。

マルチテナンシーとは?

ソフトウェアのマルチテナンシーとは、1つのソフトウェアインスタンスが複数のユーザーやグループ(テナントとも呼ばれる)にサービスを提供するソフトウェアアーキテクチャのことです。<!--EM: wikipediaの定義をそのままコピーしたくなかったので、これを言い換えました-それは良いものですが。また、最初の文で "tenants "を定義したかったのです。

多くの場合、既存のソフトウェアソリューションは、単一のテナントのために設計されています。このような場合、各テナント用にソフトウェアの個別のインスタンスをプロビジョニングし、各テナントを分離することで、マルチテナンシーを実現することができます。テナントとは、単一のユーザー、ユーザーグループ、または組織のことです。

マルチテナンシーでは、テナントのデータのプライバシーとセキュリティを保護するために、すべてのテナントを互いに分離し、見えないようにする必要があります。

ワークロードを共有するメリット

多くの企業では、人事部や財務部などの異なる部署が、共有のソフトウェアやハードウェア上で動作する独自のワークロードを使用しています。例えば、ある企業では、複数の部門がWebSphere Application ServerとDB2サーバー上でワークロードを実行しているかもしれません。

ワークロードごとに専用のハードウェアとソフトウェアを用意するのは、コストがかかり、メンテナンスも難しく、現実的ではありません。

共有コンピューティング環境では、複数のワークロードが容量を共有します。そのため、ワークロードは必要なときに容量を獲得し、不要なときに容量を解放することができます。これが可能なのは、企業では、すべてのアプリケーションの使用状況が、1日、1ヶ月、1年と異なる時間帯に変化するからです。

サービスがマルチテナントでない場合、各テナントには独自のサービス・インスタンスが必要になります。マルチテナントのために、それらのインスタンスをどのようにして互いに分離することができますか?いくつかの選択肢があります。

2.2.複数のクラスター -- サービス・インスタンス間の隔離を最も効果的に行うには、それぞれを別のクラスターに配置します。それぞれのクラスターは、別のハードウェア、別のネットワーク、さらには何千マイルも離れた別のデータセンターや地域にインストールすることができます。しかし、サービスインスタンスごとに別のクラスターを用意すると、利用率が極端に低くなり、管理するクラスターの数も多くなるため、コストがかかるというデメリットがあります。

3.3. 単一の共有クラスター -- より経済的で実用的な方法は、複数のサービスインスタンスを同じクラスター内に配置することです。複数のクラスターに比べて、単一のクラスターはコストが低く、管理が容易で、利用率も高い。しかし、クラスター内のワークロードは同じリソースやネットワークを共有しているため、その分離には限界があります。クラスタ内のワークロード間のコンテナによる隔離は、単一のテナントや互いに信頼し合う複数のテナントには適していますが、一方のテナントが他方のテナントのワークロードの存在を知らないようにすべき複数のテナントには十分ではありません。

では、クラスターは複数のワークロードを扱うことができます。どのようにしてそれらを分離できるのでしょうか?

OpenShiftでのワークロードの分離

OpenShiftでアイソレーションがどのように機能するかを理解するために、まずはOpenShiftがどのように設定されているかを簡単におさらいしましょう。 OpenShiftのクラスタは、Kubernetesのnamespacesをベースにしたprojectの集まりです。プロジェクトは仮想クラスタのようなもので、他のプロジェクトのリソースと論理的に分離されており、複数のプロジェクトは単一の物理クラスタ内の複数の仮想クラスタのように動作します。

プロジェクトにはいくつかの利点があります。

  1. 名前の範囲 -- 各プロジェクトは独自の名前の範囲を持っているので、同じ種類の2つのリソースが別々のプロジェクトにある限り、同じ固有の名前を持つことができます。

  2. ユーザーコミュニティ -- プロジェクトにアクセスできるクラスタユーザー(アプリケーション開発者やデプロイメント担当者など)は、クラスタのRBACによって制御されます。これにより、クラスタ管理者は、異なるチームのユーザを異なるプロジェクトに配置することで、同じクラスタ内の異なるプロジェクトを容易に分離することができます。

  3. リソース制限 -- クラスタ管理者は、各プロジェクトにリソース制限を設定することができます。この方法では、プロジェクトがクラスタのリソースを使いすぎることはないので、各プロジェクトはある程度のリソースを確保する必要があります。

  4. 設定範囲 -- クラスタの設定の一部は、プロジェクトごとに指定することができます。通常はクラスタ全体に適用される設定をプロジェクトに適用することで、プロジェクトを独立して設定することができます。

プロジェクトはリソースをグループ化しますが、デフォルトではワークロードを分離しません。しかし、ワークロードを分離するようにプロジェクトを構成することができます。テナントごとにプロジェクトを作成し、それぞれのプロジェクトを分離するように設定すると、あるプロジェクトのテナントのワークロードは、別のプロジェクトのテナントのワークロードから分離されます。

クラスタ管理者は、プロジェクトの分離を主に2つの側面から設定します。

  1. ネットワークの分離

  2. リソースの分離

これらの点について、もう少し詳しく見てみましょう。

ネットワークの分離

Kubernetesのネットワークポリシーを使用してOpenShiftプロジェクトを設定し、そのポッドと他のプロジェクトのポッドの間のネットワーク接続を防止します。事実上、あるプロジェクトのポッドは、ネットワーク上の他のプロジェクトのポッドを見ることができません。あたかもネットワーク上に存在しないかのようです。これにより、プロジェクト内のポッド間ではネットワークトラフィックが許可され、異なるプロジェクト内のポッド間では許可されないようにして、プロジェクト間のネットワーク分離を実現します。

プロジェクトにネットワークポリシーを適用してネットワークアイソレーションを実現する方法をご紹介します。Read the tutorialをご覧ください。

リソースの分離

マルチテナント環境では、あるテナントのワークロードのリソース使用量が、他のテナントのワークロードのパフォーマンスやリソースの可用性に影響を与えてはいけません。OpenShift プロジェクトでは、CPU やメモリなどの計算リソースにリソースクォータを設定することができます。これにより、あるテナントのプロジェクトのワークロードがリソースの上限を超えないようにして、他のテナントのプロジェクトで実行されているワークロードのためにリソースを確保することができます。

プロジェクトのCPUとメモリのリソースクォータを設定し、テナント間のリソースアイソレーションを実現する方法をご紹介します。チュートリアルを読む .

まとめ

本記事では、アプリケーションのマルチテナント展開の必要性とメリットをご紹介しました。OpenShift プロジェクトを使用してテナントを分離し、ネットワークポリシーとリソースクォータを使用してマルチテナンシーのためのアイソレーションを実現することで、コンテナ環境でのマルチテナンシーを実現することができます。

関連リソース