Red Hat OpenShift Service on AWS (ROSA)を活用したコンテナ実行基盤の構成例と導入検討や設計時の注意

はじめに

AWS上でコンテナオーケストレーションを実現するのに、マネージドのコンテナ実行基盤を利用する場合、次の3つのサービスが提供されています。

• Amazon Elastic Container Service (Amazon ECS)
• Amazon Elastic Kubernetes Service (Amazon EKS)
• Red Hat OpenShift Service on AWS (ROSA)

これらのうち、Amazon ECS（以下、ECS）およびAmazon EKS（以下、EKS）の事例はよく目にしますが、Red Hat OpenShift Service on AWS (ROSA)の事例は、ECSやEKSと比べると少ない印象があります。
Red Hat OpenShiftは、エンタープライズクラスのワークロードに求められる機能を標準で備えたKubernetesベースの統合プラットフォームです。コンテナベースのアプリケーションを開発、デプロイ、運用するための各種機能が標準で提供されており、さらに、Red Hat社によるユーザーサポートや各種トレーニング、導入コンサルティングも受けることができるため、これから自社のアプリケーション開発にコンテナ技術を活用しようというエンタープライズ企業にとって、有力な選択肢の1つと言えます。
AWSでのROSA（Red Hat OpenShift Service on AWS）は、2021年3月にAWS上でのサービス提供が開始されました。さらに、2023年12月には、コントロールプレーンの機能をユーザー環境から分離したホスト型コントロールプレーン（Hosted Control Plane：HCP）を採用した「ROSA with HCP」の一般提供（GA）が開始されました。それ以降も、機能追加や運用性の向上など、継続的なサービス改善が行われています。
従来のROSA (ROSA Classic)は、OpenShiftを構成する管理用のコントロールプレーンノード、ワーカーノードの一種で運用系のコンポーネントを動かすためのインフラストラクチャノードと、アプリケーションの実行を担うワーカーノードで構成されています。最小構成として、１つのクラスタに対して、最低7台のノード用のEC2インスタンスを起動する必要がありました。
一方、ROSA with HCPデプロイモデルを採用すると、コントロールプレーンはRed Hat社が保持するAWSアカウント上にてマネージドで用意されていますので、利用者はコントロールプレーン用のEC2インスタンスを管理する必要はなくなります。利用者側で起動・管理すべきEC2インスタンスの数はワーカーノード分だけでよく、最小構成で2台のEC2から利用可能となりました。これにより、ROSA with HCPの本格導入に向けた検証で利用しやすくなっています。
ROSA with HCPを活用したコンテナ実行基盤を設計・運用する場合、他のAWSサービスとの連携も考慮した、全体アーキテクチャの検討が必要となります。今回、Red Hat社からの支援のもと、ROSA with HCPを中心にアプリケーションをインターネットに公開するために必要となる、各種AWSサービスとの連携検証を実施しました。本ブログでは、ROSA with HCPの技術検証を行ったサンプル環境の概要と、AWS上でROSA with HCP環境の導入検討や設計を行う上での注意点について共有します。なお、ROSA with HCPは、2024年1月から東京リージョン(ap-northeast-1)でも一般提供が開始されています。

検証環境の構成

本来、システムのアーキテクチャは、動作させるアプリケーションの機能要件と非機能要件に加えて、ビジネス状況、組織構造、コスト等、様々な検討要素を考慮した上で決定します。今回の検証では、「ROSA with HCPと他のAWSサービスとの連携可否の確認」を主眼においているため、VPC内のPrivateサブネットにROSA with HCPのワーカーノードを配置し、AWSが提供する各種マネージドサービスと連携させ、アプリケーションをインターネットに公開するシンプルな構成としました。

本構成のうち、ネットワークに関しては、続きのブログで解説します。

データストアおよびリポジトリ構成

アプリケーションが利用するデータストア（データベースなど）や、コンテナアプリケーションの元となるコンテナイメージを保管するコンテナレジストリは、ROSA with HCP環境上で、OperatorやCustom Resource（CR）といったKubernetesの仕組みを活用することで、簡単に構築・運用できます。しかし、本構成では、データストアとしてAmazon Aurora、コンテナレジストリとしてAmazon ECRを採用しています。これは、将来的にリージョンをまたいだディザスタリカバリ（DR）構成が求められる可能性を考慮したものです。AuroraやECRといったAWSのマネージドサービスは、リージョン間でのデータレプリケーション（同期）機能を提供しており、DR対策を容易に実現できるという利点があります。

セキュリティ、ロギング関連の構成

ROSA with HCPを他のAWSリソースと連携させるためには、AWS Identity and Access Management（IAM）によるアクセス権限の設定が必要です。ROSA with HCPは、AWS Security Token Service（STS）と統合されており、一時的なセキュリティ認証情報（トークン）をSTSから取得することで、安全にAWSリソースへアクセスすることができます。この方式は、IAMロールとポリシーを利用して、きめ細かなアクセス制御を行えるのが特徴です。一方で、IAMユーザーに対してアクセスキー（アクセスキーIDとシークレットアクセスキー）を発行し、それをROSA with HCPの認証情報として使用する方法も存在しますが、この方法は長期間有効な認証情報をハードコーディングや漏洩のリスクに晒す危険性が高く、セキュリティ面で推奨されません。そのため、アクセスキー方式は、必要な権限があらかじめ最小限に制限されたハンズオン環境など、一時的かつ安全に管理された用途に限定して使用し、本番環境ではSTSを利用したIAMロールベースの認証方式を採用することが推奨されます。
ROSA with HCPおよびアプリケーションのログは、Amazon CloudWatch Logs(以下、CloudWatch Logs)に転送するように設定しました。CloudWatch Logsへのログ転送には、Red Hat OpenShift Logging Operatorのデプロイと、ロギング用のCustom Resourceの作成が必要になります。その上で、前述のSTSの仕組みを経由して一時的なセキュリティ認証情報を受け取り、ログ転送に必要なリソースを作成します。
ROSA with HCPにおけるログ（アプリケーションログ、インフラログ、監査ログなど）は、OpenShift Logging Operatorを通じて収集されます。このログ基盤では、Kubernetes上でGrafana Lokiを管理・運用するための「Loki OperatorのLokiStackカスタムリソース」でログ収集の構成を定義します。具体的には、ログ収集コンポーネントとしてログコレクターにVector、ログ保存先のストレージにLokiが利用されるケースがあります。ROSA with HCPでは、Red Hat OpenShift Logging（以前はEFKスタック）がベースですが、現在はVectorが推奨されており、LokiやCloudWatch Logsへの転送が一般的な選択肢です。Lokiを利用するには、Loki本体のデプロイに加えて、ログの収集や転送設定などの構成が別途必要です。ログストレージとしては、Loki以外にもElasticsearchなどを選択する構成もありますが、これらは別々のログ基盤として設計段階で選ぶ必要があります。なお、OpenShift環境では「ClusterLogForwarder」リソースを使って、収集したログをCloudWatch Logsなどの外部サービスへ転送することも可能です。

CloudWatch Logsへの出力は、ClusterLogForwarderで明示的にCloudWatch出力設定をする必要があります。ROSA with HCP環境では、CloudWatch Logsとの統合により、AWSネイティブな監視・アラート基盤と連携しやすくなる点もメリットです。
本検証で、ROSA with HCPがSTSの仕組みを利用することで、主要なAWSサービスと容易に連携可能なことが確認できました。その上で、ROSA with HCPの導入や設計内容を検討する上で、注意すべき点をいくつか示します。

AWSとOpenShift(ROSA with HCP)で管理する「境界線」の検討

本検証では、Terraformを用いてROSA with HCPを構成するために必要なVPC、CloudFront、API Gateway、データストア、コードリポジトリ、各種AWSセキュリティサービス（例：IAM、CloudTrail、GuardDutyなど）を構築しました。また、ROSA with HCPクラスタの構築は、rosa CLI や OpenShift Cluster Manager（OCM）APIを通じて行う必要があるため、Terraform単体では対応が困難です。そのため、TerraformでネットワークやIAMなどの前提リソースを構築した後、クラスタの作成はシェルスクリプトを用いて rosa CLI を呼び出す形で実施しました。今回のインフラ構成管理においては、ROSA with HCPの手前に配置したNetwork Load Balancer（NLB）までをTerraformで管理対象とし、それ以降のKubernetesクラスタ内（OpenShift上）の構成については、別の手段で管理するという形で、インフラとアプリケーションの構成管理の境界線を明確に分けています。
Kubernetesおよびその上に構築されるプラットフォームは、大規模かつ複雑なシステム環境を効率的に管理するための仕組みを提供します。大きな特徴は、アプリケーション本体だけでなく、それを動作させるために必要なネットワーク、ストレージ、設定情報などのインフラ構成や関連リソースを、YAML形式のマニフェストファイルを使って宣言的に定義・管理できる点にあります。この「宣言的構成管理」により、クラスタ内の状態を継続的に監視・調整し、常に望ましい状態（Desired State）に保つことが可能です。その結果、手動操作による設定ミスのリスクが低減されます。また、構成ファイルは変更履歴をGitなどで管理することでイミュータブルに扱うことができ、環境の再現性や、自動化された構築・更新プロセスの実現にもつながります。このようにKubernetesは、構成の一貫性・再現性・自動化を実現することで、スケーラブルで信頼性の高いシステム運用を支えるプラットフォームとして機能します。
一方で、OpenShift Operatorそのものには、CloudFrontやWAF（Web Application Firewall）などのAWSリソースを直接構築する機能は備わっていません。ただし、TerraformやAWS Controller for Kubernetes（ACK）、Crossplaneなどのツールや専用Operatorと連携することで、これらのAWSサービスの構築や設定をKubernetes環境から自動化することが可能です。

また、OpenShiftが標準で提供する機能と、AWSのマネージドサービスの間には、機能が重複する領域も存在します。たとえば、Knativeをベースにした OpenShift Serverless と AWS Lambda は、実装方式こそ異なりますが、どちらも「イベント駆動型」で「サーバーの管理が不要」なアプリケーション実行基盤です。どちらもサーバーレスアプリケーションの実行環境を提供しており、類似した用途で利用されます。
認証に関しては、Amazon Cognito と Red Hat build of Keycloak のいずれも ID プロバイダとして機能し、ユーザーの認証および認可を提供するサービスです。このように、AWSが提供するマネージドサービスを活用するか、OpenShiftの標準機能やオープンソースソフトウェア（OSS）を組み合わせて構成するかの選定は、アーキテクチャ設計において重要かつ難易度の高い判断ポイントの一つです。

包括的なセキュリティ対策の検討

ROSA with HCPをはじめとするOpenShift製品は、開発から運用までのライフサイクルを考慮したコンテナイメージやコンテナ本体、クラスタ上のリソースを含めてセキュリティを強化するための様々な機能が標準で搭載されています。ただし、ROSA with HCPはAWSのプラットフォーム上で動作するので、ROSA with HCP外のAWS環境にも、包括的なセキュリティ対策が必要になります。
注意すべき点として、AWSが提供するCloudTrail、Config、GuardDuty、Security Hubといったセキュリティやガバナンス系のサービスをすべて有効化しても、それだけでは十分ではない場合があります。例えば、これらのサービスを有効化しても、適切な設定や監視が行われていないと、セキュリティリスクを完全に防ぐことはできません。
実際にリスク分析を行うと、「AWS単体でも、ROSA with HCP環境でも対処が難しいリスク」が必ずと言ってよいほど見つかります。これは、人的ミス、アプリケーションの脆弱性、ゼロトラスト環境の不足など、クラウド基盤のサービスだけではカバーできない領域を指しています。例えば、ROSA with HCPでワーカーノードを起動すると、OSとしてはRed Hat Enterprise Linux CoreOS（以下、RHCOS）が使用されます。RHCOSは、コンテナの実行に特化した最小限の機能を備えたイミュータブルなOSであり、ユーザーが任意のソフトウェアを自由にインストールすることはできません。そのため、一般的なウイルス対策ソフトウェアや、Amazon Inspectorと連携するためのエージェントなどをノード上に導入することが想定されていません。このように、RHCOSは搭載する機能が限定されているため、攻撃者にとっての攻撃対象領域（アタックサーフェス）が小さく、セキュリティ面で有利とされています。さらに、ROSA with HCPのワーカーノードは、一般的に外部ネットワークから直接アクセスできないプライベートサブネットに配置されることが多く、これもリスクを低減する要因になります。とはいえ、こうした設計がエンタープライズ企業の厳格なセキュリティポリシーに適合しない場合もあります。そのため、追加の対応策を講じるか、リスクを許容するかといった判断が求められることがあります。ROSA with HCP はマネージドなOpenShift環境ですが、コントロールプレーンのホスティングによって運用が簡素化される一方、責任共有モデルの見極めが必要です。

バージョンアップ戦略の検討

ROSA with HCPを含むOpenShiftは、Kubernetesをベースに構築されていてサポートされるバージョン範囲が限られているため、定期的なバージョンアップ（アップグレード）が必要になります。EKSやROSA with HCPでは、コントロールプレーンおよびワーカーノードのいずれも、Kubernetesのバージョンを元に戻す（デグレード）操作は非推奨でありサポートされていません。そのため、バージョンアップ後にOpenShift上のリソースやアプリケーションで問題が発生し、それが解消困難な場合、クラスタ全体を新規に再作成し、リソースを移行する必要が生じる可能性があります。このようなリスクを避けるために、事前にステージング環境での検証を行うなど、慎重な運用計画が重要です。
クラスタのバージョンアップ方式には、主に2つのパターンがあります。1つは、既存のクラスタをそのままアップグレードするインプレースアップグレード（In-Place Upgrade）です。Kubernetes系（OpenShiftやEKSなど）では、クラスタを停止せずに順次コンポーネントをアップグレードしていく方式であり、一般的なアップグレード方法です。もう1つは、旧バージョンのクラスタとは別に新しいバージョンのクラスタを用意し、新環境での動作確認が完了した段階で、本番トラフィックを新クラスタに切り替えるBlue/Green方式のアップグレードです。この方法により、アップグレード時のサービス中断を最小限に抑えつつ、安全に移行することが可能です。Blue/Green方式のアップグレードは、大規模システムやミッションクリティカルな運用で使われます。どちらの方式を採用するかは、コスト、プラットフォームのバージョンアップの頻度や、アップグレード時に許容できるダウンタイムの有無・長さなどを踏まえて検討します。
本検証では、あらかじめ最新バージョンのROSA with HCPのクラスタを新規作成し、クラスタとアプリケーションの動作検証を実施、検証結果に問題なければ、CloudFrontの連携先を新規作成したクラスタに切り替えるBlue/Green方式の手順を採用しました。あらかじめOpenShiftリソースの作成はマニフェストとシェルスクリプトで構築自動化していたことで、新規クラスタの作成も容易に実現できました。

まとめ

今回のような小規模なアプリケーションを実行するだけであれば、ROSA with HCPやKubernetesベースのコンテナプラットフォームは、機能・運用コストの面でオーバースペックとなる可能性があります。軽量なアプリケーションをコンテナで動かすだけであれば、AWS Fargateを利用したECSやLambdaといった、よりシンプルで管理の少ない選択肢でも十分対応できます。OpenShiftは、オンプレミスのプライベートクラウドとパブリッククラウドを連携させたハイブリッドクラウド構成や、数百から数千ノード規模のクラスタを運用するような、大規模かつ複雑な要件を持つエンタープライズ企業向けのプラットフォームです。オンプレミス環境と比較して、パブリッククラウドではインフラの構築や検証を短時間で行えるため、まずはROSA with HCP上でPoC（技術検証）を実施し、実際の機能や操作性を確認してみることをおすすめします。