成功に導く ハイブリッドクラウドアーキテクチャ は、ハイブリッドに組み合わせたアプリケーションをハイブリッド・インフラストラクチャ環境全体でビルド、デプロイ、管理、接続する方法に対応しています。これらのアプリケーションは、クラウドプロバイダーやお客様のデータセンター、複数の Kubernetes クラスタ、さらにはベンダー管理システム (VMS)、ベアメタル、エッジ環境上で稼働するシステムなど、複数のインフラストラクチャ拠点にまたがることになります。

アプリケーション接続性の要件により、これまで別物とされてきた概念や技術が統合されます。理想的なハイブリッドクラウドのネットワークソリューションでは、一貫性のある方法でトラフィックの問題に対応し、下層にあるグローバル・ネットワーク・インフラストラクチャや、より上層にあるアプリケーションの接続性に対する懸念を管理する必要があります。Kubernetes および Linux コンテナでは、これらのプラットフォームで実行するアプリケーションとエンドユーザー、同じプラットフォームにある他のアプリケーションサービス、このプラットフォーム以外で実行するサービスをつなぐ基盤を提供します。

しかし、ハイブリッドクラウド環境において、よりシームレスなアプリケーション接続を実現するための要件は、それだけに留まりません。アプリケーションの接続性を実現するには、アプリケーションを保護するために、アプリケーション開発者による設定が可能なサービスの分離、認可、レート制限、トラフィックポリシーが必要です。

Red Hat OpenShift (エンタープライズ Kubernetes プラットフォーム) では、アプリケーションの構築、デプロイ、および管理が大幅に単純化されています。Red Hat Advanced Cluster Management for Kubernetes は、このプラットフォームをクラスタや複数のクラウドプロバイダーにわたって拡張するために、マルチクラスタ管理の統一、ポリシーベースのガバナンス、アプリケーション・ライフサイクル管理の拡張などの機能を備えています。

この記事では、Red Hat OpenShift、Red Hat OpenShift Service Mesh および Red Hat OpenShift API Management を使用することで、ハイブリッドクラウド環境全体でアプリケーションを連携させるための包括的なソリューションを提供できる点について見ていきます。ハイブリッドクラウドプラットフォームが進化を続ける中、マルチクラスタおよびマルチクラウド・アプリケーションのデプロイメントに対して、次世代のアプリケーション接続機能を提供する機会があります。

アプリケーションの接続性について

アプリケーションには接続性が必要です。ユーザー・インタフェースやアプリケーション・プログラミング・インタフェース (API) で、エンドユーザーが直接使用するフロントエンド・アプリケーションを構築する場合でも、ユーザー向けアプリケーションをサポートする多数のバックエンドサービスのいずれかを構築する場合でも、全体的にこれまでよりも信頼性の高い接続性を提供することが重要です。

ハイブリッドクラウド環境でアプリケーション接続を検討する際に考慮すべき主な事項は以下のとおりです。

  • ユーザーへのアプリケーションサービスの接続:優れたユーザーエクスペリエンスを提供し、ビジネス要件に対応しながら、エンドユーザーがアプリケーションを利用できるようにするだけでなく、セキュリティを確保しつつ、これらのアプリケーションへのアクセスを管理するにはどうすればよいでしょうか。

  • サービス間の接続:分散化が進むアプリケーション環境において、アプリケーションを支えるすべてのバックエンドサービスを接続して、その接続のセキュリティとパフォーマンスを強化するにはどうすればよいでしょうか。

  • サードパーティが提供するサービスの接続および使用:アプリケーションの実行先を制限したり、イノベーションを 1 つのプロバイダーに限定したりすることなく、アプリケーションを主要なサードパーティ・クラウドサービス・プロバイダーのサービスと接続するにはどうすればよいでしょうか。

優れたアプリケーション体験を提供するには、上記の疑問に対応することが重要です。

Kubernetes 以外の接続性の要件

Kubernetes はクラウドネイティブ・アプリケーションをオーケストレーションして管理するプラットフォームを提供しますが、アプリケーションの接続性には追加機能が必要です。

Kubernetes アプリケーションをエンドユーザーに接続

Kubernetes のクラウドネイティブ環境では、「アプリケーション」という概念はあまり厳密に定義されていません。アプリケーションは、1 つ以上の Kubernetes サービスで構成されており、各サービスがプロキシとなり、コンテナでアプリケーションインスタンスを実行する 1 つ以上の Pod と直接やり取りをします。アプリケーションを構成する Pod またはサービスの数にかかわらず、最終的にそのアプリケーションへのアクセスをサポートする必要があります。

Kubernetes Ingress はクラスターの外部からのルートを、クラスタ内のサービスに公開して north-south のトラフィックパターンをサポートします。Ingress はドメイン名システム (DNS) と統合し、外部からアクセス可能な URL の指定、、トラフィックの負荷分散、セキュアなソケット層/トランスポート層セキュリティ (SSL/TLS) の終了、名前ベースの仮想ホストの提供を行います。Red Hat OpenShift は、標準の Kubernetes Ingress ロードバランシングに加え、同じコンセプトの初期の実装である Red Hat OpenShift Routes をサポートしています。

アプリケーション・エンドポイントのネットワーク層へのアクセス性に加え、クライアントは API という形でアプリケーション層のコントラクトも必要とします。この API コントラクトは、Kubernetes クラスタ外のクライアントから検出でき、OpenID Connect および OAuth による承認アクセスとセキュリティ強化機能のためのセルフサービス登録をサポートする必要があります。

アプリケーション API が顧客向け製品に含まれている場合は、ビジネスへの影響を測定し、消費に見合った料金を請求するために、詳細な使用状況の分析と収益化が不可欠です。Red Hat 3scale API Management が搭載されている Red Hat OpenShift API Management は、マネージドサービスおよびオンプレミス・ソフトウェア・ソリューションの両方として、これらの機能を提供します。

Kubernetes サービスを他の Kubernetes サービスに接続

通常、フロントエンド・アプリケーションは Kubernetes にデプロイされるサービスで、Ingress 経由でエンドユーザーに公開されます。このフロントエンドサービスは、通常、Kubernetes 上で動作する他のサービスに接続する必要があります (有益なことを行うには多数のサービスに接続する必要あり)。Kubernetes サービスはこのような Pod に接続できるようにし、Kubernetes は Pod インスタンスの状態を管理しますが、信頼性を確保しながら、アプリケーションの操作を行うには、Kubernetes 以上のものが必要になります。

すべての Kubernetes クラスターでは、この East-West トラフィックパターンでサービスの実際の接続を管理するネットワークソリューションが必要です。Kubernetes Container Networking Interface (CNI) を使用すると、ユーザーは任意のソフトウェア定義ネットワーク (SDN) オプションを接続できるようになります。Red Hat OpenShift にはデフォルトの Red Hat OpenShift SDN が含まれており、またユーザーがサードパーティの認定 SDN オプションを使用できるようにします。

しかし、分散型マイクロサービスベースのアプリケーション・アーキテクチャでは、開発者およびオペレーションチームは、サービス間の通信セキュリティ体制の強化、問題の診断、および新規サービスのロールアウトの管理など、さらに踏み込んだ対応が必要になることが多くあります。Red Hat OpenShift Service Mesh は、統一された方法でマイクロサービスベースのアプリケーションを接続、管理、および監視します。

マイクロサービス・アーキテクチャは、組織内のビジネスドメインの境界を中心に形成される傾向があり、個々のマイクロサービス同士を接続するだけでなく、他にも考慮事項が出てきます。アプリケーションとドメイン境界を超えたこの接続には、セルフサービスのオンボード、使用状況の追跡、レート制限、およびカスタムポリシーなど、north-south トラフィックで使用される機能の多くが必要になります。このトラフィックは、north-south とは異なり、Kubernetes クラスタの内部ネットワークに残り、アプリケーションの API クライアントおよびプロバイダーに対して透過的である必要があります。API 管理機能とサービスメッシュを融合することで、両方の利点を獲得できます。

Kubernetes サービスを外部サービスに接続

また、ほとんどの Kubernetes アプリケーションは、Kubernetes クラスタ外で実行されるサービスを使用して機能させる必要もあります。たとえば、データセンター内のデータベースや企業資源計画 (ERP:Enterprise Resource Planning) システム、Software-as-a-Service (SaaS) アプリケーション、あるいはアプリケーションに主要な機能を追加するパブリッククラウド・プロバイダーのネイティブサービスなどが考えられます。

Kubernetes は、クラスタ内外で動作するあらゆるサービスにアプリケーションを接続するのに役立ちますが、開発者が必要なサービスをより簡単に特定してアプリケーションにすばやく接続できるようにすることが重要です。Red Hat OpenShift Service Mesh は、クラスタ内外で利用可能なサービスのカタログとして機能する API レジストリを提供します。サービスバインディングを使用して、エンドポイントとセキュアな認証情報をアプリケーション Pod に直接マッピングし、開発の負担を軽減することができます。最後に、転送 API プロキシは、経費を制御してチャージバックが可能になるように、内部アプリケーションすべての有料外部 API に対する料金の制限とアクセスの計測など、外部 API エンドポイントへの外部トラフィックのフローで、受信トラフィックと同じ制御ができるようにします。

アプリケーションの接続性の管理

先進的アプリケーションプラットフォームは通常、標準的に責務は以下のように分離されます。

  • コントロールプレーン:接続性ポリシーを設定するための管理インタフェース。たとえば、Red Hat OpenShift Management Web コンソール、Kiali Service Mesh Manager、Red Hat OpenShift API Management 管理コンソール、CLI/API などです。コントロールプレーンは、他のサービスと同じクラスタに、またはクラスタ外の管理コントロールプレーンとしてデプロイできます。

  • データプレーン:要求/応答トラフィックのサービスへのネットワークアクセス。たとえば、Kubernetes Ingress、Red Hat OpenShift Routes、Proxy、API ゲートウェイ、Istio Ingress ゲートウェイなどの中間層などです。データプレーンはコントロールプレーンとは別個にデプロイされ、通常は関連するバックエンドサービスの近くに配置するためにクラスタ上にあります。

現在、Kubernetes 上の包括的なアプリケーション接続性ソリューションには、Red Hat OpenShift Service Mesh と Red Hat OpenShift API Management テクノロジーを組み合わせた階層化アプローチが必要です。Kubenetes は、基礎となるコンテナ管理層として、下位層のネットワーク、Ingress およびデプロイされたアプリケーションコンテナへのルーティングを有効にします。Kubernetes の上の階層にある他の管理テクノロジーは、Kubernetes に依存して Ingress の解決し、充実したアプリケーション層の機能を提供します。

結果として得られるアーキテクチャでは、Kubernetes がネットワークと Ingress 機能を、Red Hat OpenShift Service Mesh が高度な east-west およびサービス内接続のポリシーを、Red HatOpenShift API Management が north-south のゲートウェイのポリシーを提供します。これらのソリューションを組み合わせると、外部サービスへのアクセスを制御する Ingress 機能も追加されます。

サービスメッシュと API ゲートウェイは、共にサービスエンドポイントへのアクセスを制御します。サービスメッシュは通常、L4/L7 層でレート制限、ルーティングルール、相互 TLS、サービスアイデンティティ、カオスエンジニアリング、Ingress ルールなどを提供します。API ゲートウェイは、L7 層でレート制限、認証、認可のセキュリティ機能を提供します。

ネットワーク接続性に関する考慮事項

各 Kubernetes デプロイメントは、個別のクラスタで構成されており、その中にはコントロールプレーンとコンテナ化されたアプリケーションを実行するためのワーカーノードのセットが含まれます。アプリケーションはコンテナイメージとしてパッケージ化され、Kubernetes クラスタのワーカーノードに配置されます。

Kubernetes は大きく分けて、ユーザーとグループパーミッション関連、分離、暗号化、Ingress/SSL 終端、シークレットおよび鍵管理、継続インテグレーション/継続デプロイメント (CI/CD) パイプライン・セキュリティおよびビルド/イメージ検証など、インフラストラクチャレベル (L1-L4) でアクセスを制御します。

サービスおよびアプリケーションの接続性に関する考慮事項

Red Hat OpenShift Service Mesh は Kubernetes を拡張し、プログラム可能なアプリケーション対応ネットワークポリシーを確立します。これらのポリシーは、アプリケーションコードを変更せずに、共通のコントロールプレーンで設定できます。強力な Envoy サービスのプロキシとサイドカーを使用することで、これらのポリシーはアプリケーション Pod を管理してデータプレーンでポリシーを適用します。Kubernetes および従来のワークロードの両方を使用する OpenShift Service Mesh は以下の機能を提供します。

  • トラフィック管理:サービス間のトラフィックフローおよび API 呼び出しを制御し、呼び出しの安定性を高め、不利な条件下でネットワークの堅牢性を維持します。

  • サービスのアイデンティティとセキュリティ:メッシュ内のサービスを検証可能な ID で指定でき、信頼性の程度が異なるネットワークで移動するサービストラフィックを保護する機能を提供します。

  • ポリシーの適用:サービス間の対話に組織のポリシーを適用し、アクセスポリシーが適用され、リソースはコンシューマー間で均等に分散されるようにします。ポリシー変更は、アプリケーションコードを変更するのではなく、メッシュを設定して行います。

  • Telemetry:サービス間の依存関係やそれらの間のトラフィックの性質やフローについて理解し、問題を素早く特定できます。

ビジネス接続性に関する考慮事項

API はビジネス機能にインタフェースを提供し、利用者が制御された方法でサービスにアクセスできるようにします。ビジネス中心のコンストラクトである API は、サービスプロバイダーとサービスコンシューマー間のコントラクトとして機能します。マイクロサービスやクラウドネイティブ開発のコンテキストでは、API は正式な API コントラクトでパッケージされた Kubernetes サービスとして定義でき、ビジネスドメイン間や外部コンシューマーによるアクセスを可能にします。

Red Hat OpenShift API Management は、Kubernetes クラスタのサービスに対するビジネスポリシーを提供し、セキュリティ面で考慮します。

  • API レート制御:設定されたユーザー/アカウントプランの制限を使用して API URL パスごとの制限を有効にして、API に到達する要求の数を制限します。

  • 認証:要求側を一意に識別し、認証されたアカウントへのアクセスのみを許可するメカニズムを提供します。この認証は、要求側のアイデンティティに基づいて行われます。OpenShift API Management は、OAuth 2.0 をベースとした API (ユーザー) キー、アプリケーション ID およびアプリケーションキーの組み合わせ、または OpenID Connect (OIDC) 認証の使用をサポートします。

  • 認可:ロールに基づいてユーザー/アカウントアクセスを制御する方法を提供します。このアクセスは、認証以外に、ユーザーのプロファイルを確認し、ユーザーまたはグループが要求したリソースにアクセスできるかどうかを判断します。これは、ユーザーやアカウントを特定のプランに割り当てて OpenShift API Management で設定します。OIDC でセキュリティ保護されたサービスに対して、ID プロバイダーが共有する JWT (JSON Web Token) を検査し、ロールチェックポリシーを適用して、詳細にわたるアクセス制御を行うことができます。

Red Hat とのアプリケーションの接続性

Red Hat は、Kubernetes 環境で動作する分散型サービスのアプリケーション接続性を確保するために包括的なソリューションスタックを提供します。

Red Hat solution stack

Red Hat OpenShift

Kubernetes は単体のオープンソースプロジェクトとしても効果的なコンテナ管理ツールですが、企業向けハイブリッドクラウド・プラットフォームとしての全機能は、補完的なクラウドネイティブツールのエコシステムと統合して初めて実現されます。

Red Hat OpenShift は、プラットフォームに依存しない、開発者のエクスペリエンスとアプリケーションセキュリティに焦点を当てた、ハイブリッドクラウド環境向けのエンタープライズ Kubernetes プラットフォームです。OpenShift エコシステムには、開発者環境、アプリケーションサービス、ソフトウェア定義ネットワーク、ストレージ、モニタリング、サードパーティのインテグレーション、仮想化、セキュリティ機能、およびクラスタ管理のための強力なツールが含まれます。

OpenShift は、クラウド環境で動作するモダナイズされた既存のクラウドネイティブ・アプリケーション向けに一貫したアプリケーション・プラットフォームと、全インフラストラクチャに共通する抽象化層を提供します。

Red Hat OpenShift Service Mesh

Red Hat は OpenShift にサービスメッシュ機能を搭載しており、OpenShift Operator を使用してインストールすることで、デプロイメントがよりシンプルになります。Red Hat OpenShift Service Mesh は、オープンソースプロジェクトのセットに基づいて、複数のオープンソーステクノロジーを統合し、設定、可観測性、および管理の統合コントロールプレーンを提供します。これには、以下が含まれます。

  • Istio:サービス間のトラフィックを統合して管理するオープンソースプロジェクト。

  • Jaeger:サービス間の移動時に要求を追跡する、オープンな分散型トレースシステム。

  • Kiali:設定の表示、トラフィックの監視およびトレースの分析向けのオープンソースプロジェクト。

  • Envoy:オープンソースプロジェクトのエッジ環境およびサービスプロキシ。トラフィックがサービス間を流れるようにするための汎用データプレーン。

OpenShift Service Mesh は、同じクラスタまたは複数のクラスタにまたがる複数のサービスメッシュとのフェデレーションをサポートします。Istio ゲートウェイは、スタンドアロンの envoy プロキシを使用して、メッシュとの間のトラフィックを管理します。Kubernetes Ingress とは異なり、Istio ゲートウェイは公開するポート、TLS 設定など、仮想サービスにバインドするようにレイヤー 4-6 負荷分散プロパティを設定します。これにより、Istio メッシュ内の他のデータプレーントラフィックと同様にゲートウェイトラフィックおよびアプリケーション・レイヤー・ポリシーを管理できます。

Red Hat OpenShift API Management

Red Hat OpenShift API Management は、OpenShift のマネージドクラウドサービスとして利用できます。OpenShift API Management は、オープンソースの 3scale API Management および Keycloak プロジェクトをベースにしています。OpenShift API Management は API ビジネスモデルを使用することで、以下を行います。

  • ライフサイクル全体で API をデプロイ、監視、および管理する。

  • 環境のセキュリティと使用状況を制御するポリシーを作成する。

  • カスタムコードを必要とせずに宣言的なポリシーで既存のアイデンティティ管理システムを使用する。

  • API の正常性および使用状況に関する洞察を得る。

  • 内部または外部デベロッパーポータルに公開して API を検出し、共有する。

OpenShift API Management には、API の設定および管理向けの統合コントロールプレーンが含まれており、1 つまたは複数のクラスタにデプロイできます。OpenShift API Management は、API エンドポイントと合わせてデプロイできる NGINX ベースのゲートウェイのセットが同梱されており、サービスに対するコンシューマートラフィックのデータプレーンプロキシ機能やポリシー適用機能を提供します。

OpenShift API Management は、サービスメッシュ・マイクロサービス・アーキテクチャとの連携を強化するために、3scale API Management の設定をサービスメッシュに注入する WebAssembly (Wasm) 拡張を提供します。3scale API Management Wasm 拡張は、OpenShift API Management コントロールプレーンの接続、API サービスとポリシーの定義を可能にするだけでなく、3scale API Management 拡張を使用して OpenShift API Management に対するトラフィックを認可および報告するデータプレーンのトラフィックに対応できるようにします。

概要

Kubernetes 環境で実行されているアプリケーションには、ネットワークやアプリケーションの懸念事項を考慮した包括的な接続性ソリューションが必要です。マイクロサービス・アーキテクチャ、API 中心の開発およびデプロイメントを、さまざまなクラウドおよびデータセンター・インフラストラクチャで使用するには、Kubernetes クラスタ外にあるサービスおよびサービス通信が必要です。そのため、テクノロジースタックでは、あらゆる接続性の懸念事項 (north/south および east/west) を管理する必要があります。

OpenShift API Management および OpenShift Service Mesh は、Kubernetes プラットフォームで包括的なアプリケーション接続を提供します。OpenShift、OpenShift Service Mesh、および OpenShift API Management は適切に統合されており、クラウド・ネイティブ・アプリケーション内で適切に階層化を行い、開発者に向けて包括的な接続性を提供します。

アプリケーションの接続性は複数のネットワークやアプリケーションの境界をまたぐので、クラスタとクラウド環境との間の境界線はあいまいです。マルチクラスタ環境およびクラウド環境全体で透過的な方法でアプリケーションの接続性に対応する必要があります。

現在のテクノロジーを基盤として構築する場合に、既存のアプリケーションのアクセス制御やネットワークのルールの採用、サービスの依存関係の解決、監査可能性や可観測性機能の確保を実現しつつ、複数のクラウド環境およびクラスタ間を移動するアプリケーションをシームレスに連結するにどうすればいいのでしょうか?開発者向けに接続性を単純化するには、アプリケーションコードを変更せずに、プラットフォーム別に宣言的なポリシーや設定を適用することができます。

次の記事 では、マルチクラウドおよびマルチクラスタ環境でのアプリケーションの接続性管理を可能にする、技術スタックの進化について説明します。


About the authors

Satya Jayanti leads product strategy and delivery for application connectivity to containerized multicloud applications. He has over two decades of experience in enterprise integration, Java, middleware and application development. Jayanti is passionate about technology, and loves sharing his knowledge through webinars, workshops and in conferences.

Read full bio

Joe O'Reilly is a technology specialist with over 20 years experience in the software industry. He heads up Cloud Application Services Product Management with a focus on Data streaming & eventing Infrastructure, Application Connectivity and Developer Services.

Read full bio

Bilgin Ibryam is a product manager and a former architect at Red Hat. He is a regular blogger, open source evangelist, speaker, and the author of Camel Design Patterns and co-author of Kubernetes Patterns books. He has over a decade of experience in designing and building scalable and resilient distributed systems. Follow him @bibryam for regular updates on these topics.

Read full bio