ホスト型コントロールプレーンを備えた Red Hat OpenShift Service on AWS の提供を開始

Red Hat は、Red Hat OpenShift Service on AWS (ROSA) により、AWS のスケールでアプリケーションをより迅速に構築およびデプロイするためのターンキー型のアプリケーション・プラットフォームを開発しました。これにより、ユーザーはインフラストラクチャの管理から解放され、イノベーションに集中できるようになります。ROSA の次なる進化として、ホスト型コントロールプレーンがサービスの一環として一般提供開始となります (12 月 4 日提供開始予定)。

ホスト型コントロールプレーンを備えた ROSA は HyperShift プロジェクトに基づいており、分離された可用性の高いコントロールプレーンを ROSA サービスの AWS アカウント内で提供します。コントロールプレーンの所有権を顧客から切り離すことで、ユーザーは ROSA ですでに得ているメリットに加えてさらなる運用効率と大幅なコスト削減を実現できます。

コントロールプレーンのホスティングと管理を顧客の個別アカウントではなく ROSA サービスの AWS アカウントで行うことで、より効果的かつ効率的なリソースの利用と、以下が可能になります。

総所有コスト (TCO) の最適化

Red Hat が実施した調査によると、ホスト型コントロールプレーンを備えた ROSA をデプロイした場合、ユーザー自身のクラウドアカウントでコントロールプレーンをホスティングした場合と比較して、平均で 5 倍のコスト削減が可能になります。また、クラスタをより迅速かつ容易にスピンアップおよび使用しないときに破棄できるため、さらなるコスト削減を推進できます。

ホスト型コントロールプレーンはまた、一元的な年額課金に対してより高い柔軟性と可搬性を提供するため、顧客はノードタイプ間の変更をより容易に行うことができます。全体のフットプリントも小さくなり、最小ノードは 7 つから 2 つとなりました。

運用効率の向上

ホスト型コントロールプレーンによってプロビジョニングが最適化され、より効率的になるため、アプリケーションのデプロイを開始するまでの時間が短縮されます。また、ワークロードのスケジューリングはワーカーノードを待つだけでよいので、構築とデプロイのプロセスが単純化および高速化されます。ホスト型コントロールプレーンを備えた ROSA では、コントロールプレーンの自動スケーリングの必要性もなくなります。これは、ROSA サービスの AWS アカウントで自動的に管理され、コストと時間の影響が抽象化されるためです。

信頼性とレジリエンシー (回復力) の向上

コントロールプレーンのインフラストラクチャ管理をエンドユーザーからオフロードすることで、AWS 管理者の操作対象はワークロードのみになり、コントロールプレーン・アーティファクトの操作はしないので、クラウドリソースを誤って削除することがなくなります。これにより、コントロールプレーンとワークロード間の所有モデルと依存関係が単純化されます。ユーザーは、コントロールプレーンとワーカーノードを個別に選択的にアップグレードできるため、制御性と柔軟性が向上します。

アーキテクチャの改善

マネージドサービス向けに構築された ROSA の最新版は、組織が ROSA クラスタを大規模にデプロイおよび管理する方法にパラダイムシフトをもたらします。この改善されたアーキテクチャには、前述したあらゆるビジネス上のメリットのほかに、技術的なメリットも多数あります。

ホスト型コントロールプレーンを備えた ROSA は、組織と開発者が次のことを実行するのを可能にします。

• アプリケーションを単一のアベイラビリティゾーン (AZ)、2 つの AZ、またはリージョン内のすべての AZ に展開できます。コントロールプレーンは常に複数の AZ に分散されているので、可用性を気にする必要はありません。
• 各クラスタ専用の分離されたコントロールプレーンを迅速にプロビジョニングし、オプションで AWS VPC 内の専用の AWS PrivateLink エンドポイントを通じて公開または非公開で利用できます。

クラスタおよびクラウド管理者にも、ホスト型コントロールプレーン・アーキテクチャを備えた ROSA による以下のようなメリットがあります。

• さまざまなリソースがクラスタ境界の範囲外に移動され、ROSA CLI または OpenShift Cluster Manager (OCM) を通じてプロビジョニングされた信頼できる唯一の情報源を使用するようになります。
  • すべてのマシン API は、MachinePool オブジェクトとして ROSA CLI または OCM を通じて外部で管理されます。
  • ノード API リソースは、既存のノードにラベルを付けたりテイントしたりする機能を含め、クラスタ内で引き続き利用可能です。
  • OAuth コンポーネントもクラスタ内部で公開されなくなります。
• コントロールプレーンがワークロードから切り離され、セキュリティ境界が強化されます。
• AWS が承認および公開した管理ポリシーを利用した、削減された AWS ポリシー権限セットにより、タグベースの権限適用を有効にすることで、前提条件の複雑性が軽減され、デフォルトでセキュリティが強化されます。
• コントロールプレーンとワーカーノードのアップグレードが分離されるので、ワーカーノードに影響を与えることなく、セキュリティを重視した一貫したコントロールプレーンのアップグレード頻度が可能になり、アプリケーション開発者はノードのアップグレード時期について追加の時間と柔軟性を得ることができます。

コントロールプレーンとワーカーノードの分離により、AWS PrivateLink エンドポイントは、AWS アカウントから内部ネットワーク・ロードバランサーへの一方向の通信を提供します。各ワーカーノードの kubelet は、ロードバランサーの背後に配置された Kube API Server との通信を直接確立します。

ROSA クラスタのすべての管理とメンテナンスは ROSA サービスアカウントで行われ、AWS インフラストラクチャへのアクセスは必要ありません。Red Hat の AWS マネージド・サポート・ポリシーは、緊急のトラブルシューティングが求められるケースにおいて、必要なレベルの AWS インフラストラクチャへのアクセスをタグに基づいて付与します。

ロードバランサーが前面に配置され、アプリケーション・ネットワーク・トラフィックが AWS アカウントから外に出ることはありません。ホスト型コントロールプレーンを備えた ROSA は、デフォルトではネットワーク・ロードバランサーが付属するアプリケーション・ルーターを前面に配置するように設定されていますが、オプションとして、古典的なロードバランサーを利用することもできます。

提供時期

ホスト型コントロールプレーンを備えた Red Hat OpenShift Service on AWS は、12 月 4 日に一般提供を開始する予定です。ホスト型コントロールプレーンを備えた ROSA は、Kubernetes を単純化し、ユーザーが最も重要なこと、つまりアプリケーションの迅速な提供と効率的な管理に集中できるようにするという、Red Hat の目標に基づいています。ホスト型コントロールプレーンを備えた ROSA に関する詳細および開始方法について、詳しくはこちらをご覧ください。