re:Invent 2023: AWSとRed Hatが語るROSA最新機能とIBMアプリ実行例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Running OpenShift on AWS using Red Hat OpenShift Service on AWS (ROSA) (CON207)
この動画では、AWSのシニアプロダクトマネージャーEric ChapmanとシニアコンテナスペシャリストTrey Hoehneが、Red Hat OpenShift Service on AWS (ROSA)について詳しく解説します。ROSAの最新アーキテクチャや、コスト削減につながるホステッド制御プレーン(HCP)の導入、Terraformを使ったデプロイメント自動化など、クラウド移行を加速させる具体的な方法を学べます。さらに、IBMのビジネスソフトウェアをROSA上で実行する新しいユースケースも紹介されており、エンタープライズアプリケーションの近代化に興味のあるエンジニアにとって見逃せない内容となっています。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
re:Invent 2023セッション：ROSAの概要と本日のアジェンダ
re:Invent 2023へようこそ。re:Inventの旅の最初の一歩としてこのセッションを選んでいただき、嬉しく思います。このセッションは「AWSでRed Hat OpenShift Serviceを使用してOpenShiftを実行する」、略してROSAについてのものです。私はEric Chapmanと申します。AWSのシニアプロダクトマネージャーで、2年以上にわたってRed Hatの仲間たちと密接に協力してROSAサービスの提供に携わってきました。本日はTreyと一緒にプレゼンテーションを行います。Trey、自己紹介をして始めてください。
みなさん、こんにちは。私はTrey Hoehneと申します。AWSのシニアコンテナスペシャリストです。つまり、毎日コンテナについてお客様とお話しする仕事をしています。AWSのコンテナポートフォリオ全般を扱いますが、特にRed Hat OpenShift Service on AWS、略してROSAについて多く話します。始める前に、朝早いセッションですので、少し会場の皆さんと対話してみましょう。まず、現在OpenShiftを使用している方はいらっしゃいますか？手を挙げてください。はい、何人かいらっしゃいますね。かなりの数です。ROSAについてはどうでしょうか？はい。Kubernetesはどうですか？Kubernetesを始めたけれど、難しくて諦めた人はいますか？1人だけですね。プラットフォームチームや中央ITの方はいらっしゃいますか？はい。ビジネスチームや開発者チームの方は？つまり、OpenShiftを使用している人、ROSAを使用している人、Kubernetesを使用している人など、様々な背景の方々がいらっしゃるということですね。素晴らしいです。
アジェンダを簡単に説明させていただきます。まず、お客様からよく聞かれる一般的な要件について触れます。次に、コンテナでアプリケーションを実行することが、アプリケーションチームのイノベーションをどのように加速できるか、そしてそれによって生じる課題についても議論します。その後、ROSAに深く踏み込み、ROSAがコンテナパラダイムによって生じる多くの課題をどのように解決できるかを説明します。もちろん、AWSでROSAクラスターをデプロイする方法にはいくつかのオプションがありますので、それぞれのアプローチについても説明します。最後に、最近のローンチや今後のロードマップ上の機能について議論し、Q&Aで締めくくります。
クラウド移行の課題とコンテナ化のメリット
ここでシナリオを説明しましょう。皆さんの中にも経験がある方がいるかもしれません。あなたの会社がクラウドへの移行を望んでおり、会社のすべてのアプリケーションが展開される環境のための共有サービスプラットフォームの開発を任されたとします。現在、会社のアプリケーションの大部分はオンプレミスで動作しています。VMで動作するモノリスがあり、直接ベアメタルで動作しているアプリケーションもあるかもしれません。コンテナを試している顧客も少しいるかもしれませんし、市販のソフトウェア（COTSアプリケーション）も使用しているかもしれません。そして、もちろんあなたの目標は可能な限り早くクラウドに移行することです。
会社内には様々なスキルレベルの差があることもわかっています。移行の準備ができているアプリケーションもあれば、そうでないものもありますが、繰り返しになりますが、目標は迅速に移行することです。何百ものアプリケーションを管理するのは大変な作業です。そこで、管理のオーバーヘッドを引き受けてくれるソリューションが欲しいと考えています。これにより、チームは運用上の差別化されていない重労働を管理するのではなく、ビジネス価値の提供に集中できます。選択肢を評価する際には、考慮すべき点が多くあります。今日は、いくつかの選択肢について話し合い、Red Hat OpenShift Service on AWSがどのように役立つかを議論します。
クラウド移行への道筋を評価する際に考慮すべき要件について、もう少し詳しく見ていきましょう。クラウドで運用する上で、今日の顧客が持つ一般的な要件のいくつかに触れていきます。
シニアコンテナスペシャリストとして、私は多くの顧客と話をしますが、彼らはこれらの共通の質問やテーマをほぼ毎日のように私たちに伝えてきます。顧客は、顧客に価値を提供するために迅速にイノベーションを起こす必要があると言います。開発チームには、インフラの設定や異なる環境間の一貫性の管理といった運用タスクを心配することなく、可能な限り迅速にアプリケーションを提供することに集中してほしいと考えています。
彼らは、インフラが信頼性が高く、可用性が高いものを望んでいますが、同時にセキュアでコスト効率が良く、ある程度ニーズに合わせてカスタマイズできるものも求めています。必要なサイズに拡張できる実績があり、かつ迅速にスケールアップやスケールダウンができるプラットフォームやベンダーを求めています。セキュリティと分離、そしてアクセスと権限の制御を望んでおり、もちろん人為的ミスを減らすための自動化の方法も求めています。AWSには250以上のサービスがあり、これらのニーズを満たすための多くの選択肢がありますが、これらの質問や要件についてもう少し詳しく見ていきましょう。
マネージドサービスとROSAの利点
顧客として、もちろんニーズに合わせて環境を設定やカスタマイズできる必要がありますが、本当にプラットフォームの基盤となるインフラを管理したいでしょうか？ほとんどの企業にとって、クラウドインフラの管理は差別化されない重労働であり、マネージドサービスを選択することで、はるかに低い運用コストで要件を満たすことができます。マネージドサービスでは、AWSと、この場合Red Hatが、お客様に代わってAWSインフラを管理する運用の負担を引き受けるので、お客様はアプリケーションの開発と価値の提供に集中できます。覚えておいてください。私たちの目標は、クラウド移行のための環境を確立することです。大規模なチームを雇用したり拡大したりすることが目標ではありません。
マネージドサービスを活用することで、この差別化されない管理層を他社にアウトソースすることができます。クラウドインフラを構築・管理するための大規模なチームを雇用したり拡大したり、専門知識を開発したりする必要はありません。
クラウドへの移行戦略を立てるプラットフォームチームの視点から見ると、どこで実行しても一貫した運用体験が欲しいものです。移行の旅を始めると、AWSとオンプレミス環境にまたがるワークロード、ワークフロー、アプリケーションが出てきます。アプリケーションの数が増え、環境が拡大するにつれて、 ワークロード、事業部門、インフラ全体にわたるアクセス制御などの運用の一貫性が必要になってきます。これらの環境ごとに特別なプロセスを開発する心配をしたくはありません。
複数の環境にわたって管理、プロビジョニング、運用の一貫性を保つことは、移行や運用の目標を達成する上で最も重要です。この時点で、要件に加えて、いくつかの疑問が浮かんでくるかもしれません。これらのワークロードをクラウドにどのように移行できるでしょうか？アプリケーションをどのようにモダナイズできるでしょうか？開発者に自己サービスのプラットフォームをどのように提供できるでしょうか？開発者が要求するたびにチケットを提出させて環境を作成するのは避けたいものです。これらすべてにわたって、一貫したツールとガバナンスをどのように実現できるでしょうか？ここでも、各環境に特化したプロセスを構築したくありません。そして、急速に変化する世界に対応するために、どのように迅速にスケールアップとダウンを行えるでしょうか？
コンテナ化とKubernetesの課題
多くのお客様にとって、アプリケーションのコンテナ化は、これらの疑問に答え、先ほど議論した要件を満たすための一つの方法です。コンテナがこれらの課題の多くを解決することは周知の事実ですが、同時に新たな課題も多く生み出します。少し話を戻して、なぜお客様がコンテナを採用するのか考えてみましょう。この10年以上、お客様はコンテナでアプリケーションを実行することで、アプリケーションのモダナイズを選択してきました。
標準化された船舶コンテナのサイズが、世界中で貨物を移動させる標準的な方法を提供し、海運業界に革命をもたらしたように、コンテナはアプリケーションに対して同じことを行います。コンテナを使用すると、ソフトウェアを標準化されたユニットにパッケージ化して、デプロイメントと配布を行うことができます。このコードの標準化されたユニットにより、ローカルデスクトップからクラウドまで、さまざまな環境でアプリケーションが一貫して動作することを確信できます。
コンテナは、仮想マシンと比較して運用効率も高くなります。これにより、インフラストラクチャ全体でワークロード密度を高め、コストを削減できます。つまり、使用状況に合わせて環境を適切なサイズに調整できるのです。コンテナ化されたアプリケーションのインスタンスを迅速に起動できるため、アプリケーションの迅速なテストとアジャイルな反復が容易になります。より制御された再現可能な環境に移行し、自動化を採用することで、製品の提供とベロシティが劇的に向上すると同時に、品質、安定性、セキュリティも向上します。
これらはすべて素晴らしく聞こえます。コンテナは確かに有効な方法ですが、考慮すべき点もあります。お客様がコンテナを採用する際には、確かに学習曲線があります。すべてが簡単というわけではありません。コンテナベースの共有サービスプラットフォームを構築するには、あなたやチームがまだ馴染みのないツールを組み合わせる必要があります。Infrastructure as Codeを使用した自動化もベストプラクティスですが、どこから始めればよいでしょうか？また、コンテナについて話す際、可観測性やセキュリティはどうなるのでしょうか？さらに、FinOpsを考慮する場合、これらすべてをコストの観点からどのように捉えればよいでしょうか？
コンテナオーケストレーションプラットフォームは、これらの多くの問題に対する解決策を提供してくれます。そして、多くの顧客が標準化しているオーケストレーションプラットフォームの1つがKubernetesです。ご存知ない方のために説明すると、KubernetesまたはK8sは、コンテナ化されたアプリケーションの自動化、デプロイ、スケーリングのためのオープンソースシステムです。しかし、Kubernetesが提供するコンテナ管理レイヤーがあっても、総合的な環境を構築するためには、統合するコンポーネントを選択する必要があります。
これはCNCFのすべてのサービスを示した図です。CNCFとは、Cloud Native Computing Foundationの略で、Kubernetesを所有し、その方向性を定める統括団体です。もしあなたのチームがコンテナやKubernetesを一から始めるのであれば、この図は少し圧倒的に感じるかもしれません。 K8sのエコシステムには素晴らしいツールが数多くありますが、それらをどのように組み合わせるかのガイドはありません。
ROSAの特徴とAWS上での実装
コンテナの運用上のメリットは欲しいものの、あなたの任務は迅速な移行を推進することです。チームには、アプリケーションプラットフォームを自前で構築する時間も、必ずしも専門知識もありません。そこで、コンテナが私たちのニーズを満たすという結論に至りました。 コンテナは、クラウドへの迅速な移行を可能にし、Kubernetesがコンテナを実行するためのオーケストレーションレイヤーとなります。では、AWSでKubernetesを実際に実行する方法と、ROSAがどのように適合するかについて話しましょう。
Kubernetesでコンテナをビルドするには、いくつかのオプションと方法があります。 まず、DIY（Do It Yourself）の方法があります。EC2インフラストラクチャに直接デプロイし、Kubernetesディストリビューションを入手し、何らかのツールを使用して環境に直接Kubernetesをデプロイします。このオプションは完全な制御を可能にしますが、運用コストが非常に高くなります。私たちは運用の複雑さを減らし、迅速に移行することを目指しているため、環境に複雑さを加えるDIY Kubernetesは、この状況には適していないかもしれません。
マネージドサービスの領域に近づくもう一つのオプションは、Amazon EKS（Elastic Kubernetes Service）です。Amazon EKSは、コントロールプレーンを代わりに管理することで支援し、Kubernetes APIとetcdをAWS管理VPCに移動します。EKSは多くのことを簡素化してくれます。観測性のためにCloudWatchを、コンテナレジストリにECRを利用でき、さまざまなワーカーノード用にAWS最適化マシンイメージを使用できます。しかし、ライフサイクルの更新管理やデータプレーンのアップグレードなど、まだ運用作業が必要です。コントロールプレーンはAWSによって管理されますが、データプレーンは私たちの責任のままです。EKSのデータプレーンを構成するサービスやワーカーノードのアップグレード、さらにネットワーキングやイングレスを提供するクラスターサービスのインストールと管理は、私たちの役割となります。
ここで、ROSA（Red Hat OpenShift on AWS）の出番です。OpenShiftについてご存じない方のために説明しますと、これはRed Hatが開発・サポートするコンテナ化アプリケーションプラットフォームです。Red Hat Enterprise LinuxとKubernetesをベースに構築されており、大きな利点はターンキーであることです。ROSAには、コンテナ化アプリケーションを実行するために必要なものがすべて揃っています。これには、アプリケーションからインフラストラクチャまでを監視できる可観測性など、組み込みのサービスや、OperatorHubを通じてOperatorとして利用可能な多くのサービスが含まれます。
ROSAはまた、開発者にとってコンテナ体験をより簡単にする機能も提供しています。Kubernetesの運用面を簡素化するコンソールや、CLIツール、コードエディタやIDE向けのツールなどがあります。重要なのは、Red Hat SREによる企業レベルの技術サポートを含む、スタック全体にわたるサポートが受けられることです。これは、AWSでROSAを実行するお客様にとって、スタック全体のサポートを受けられる大きな利点となります。
私たちはよく、ROSAは「バッテリー付きだが交換可能」と言っています。サードパーティの可観測性プラットフォームなど、お好みのツールがある場合は、デフォルトのツールチェーンを組織の運用要件に合わせて交換できます。OpenShiftには、すでにサービスメッシュ用のIstio、CI/CD用のTekton、GitOps用のArgoCDなど、人気のオープンソースプロジェクトをベースにしたデフォルトのプラットフォーム統合が組み込まれています。プラットフォームでの作業経験を積み、Kubernetesエコシステムに慣れてくれば、Kubernetesのモジュール性を活かして、ニーズにより適した異なるコンポーネントに常に交換できます。
では、サポートの側面と責任分担について話しましょう。先ほど見たように、ROSAのサポートバーはスタック全体にわたっています。ROSAに近づくにつれて、Red HatとAWSが完全なスタックを管理してくれます。オンプレミスや、EC2ノードやクラウドインフラの上で自己管理方式でOpenShiftを実行できますが、ROSAを使えば、その責任をAWSとRed Hatに移すことができます。Red Hat SRE（Site Reliability Engineer）を活用して、OpenShiftプラットフォームと基盤となるAWSインフラストラクチャを代わりに管理してもらうことができます。
ROSAの利点を簡単におさらいしましょう。Kubernetesを簡単にすることで、クラウドファーストの戦略に沿っています。Kubernetesの運用と管理を簡素化し、Day 2オペレーションが組み込まれたターンキーソリューションを提供します。ROSAは、単なる管理されたコントロールプレーンではなく、管理されたクラスターを提供し、専門家のSREによる24時間365日のプロアクティブなサポートを提供します。これにより、お客様は運用ではなく、ビジネス価値の創出に集中できます。
ROSAは、Kubernetesの上に構築された豊富な開発者体験を提供するアプリケーションプラットフォームを提供することでこれを実現しています。ROSAクラスターを立ち上げると、すぐにコンテナ化されたアプリケーションのホスティングを開始できます。マネージドクラスターには、コントロールプレーンからワーカーノードまで、すべてをサポートしており、Kubernetesの運用負担をさらに軽減します。事後対応ではなく事前対応型のサポートは、Red Hat SREによって24時間365日、フォローザサン方式で提供されます。これらの機能により、ユーザーは運用ではなくビジネス価値の創出に集中できます。
ROSAのアーキテクチャと構成要素
ROSAが、クラウド上で自分で管理する必要のない包括的なアプリケーションプラットフォームを提供するという点で私たちのニーズを満たしていることがわかりましたが、AWSインフラストラクチャにデプロイされたときのアーキテクチャや全体像について気になっているでしょう。Eric、その点について説明してもらえますか？
はい、ありがとうございます、Trey。Treyが最初に紹介したシナリオに戻りますが、あなたは運用担当者で、ROSAの仕組みについてもっと詳しく知りたいと思っています。この時点で、「ROSAは自分の環境でどのように動作するのか？」「どのようなAWSリソースをプロビジョニングするのか？」「ROSAやROSA上で動作するワークロードは他のAWSサービスとどのように連携するのか？」「ROSAクラスターを作成する一貫したパターンをどのように自動化できるのか？」「ROSAはオンプレミスのワークロードをクラウドに移行し、クラウドとオンプレミス環境にまたがって実行するのにどのように役立つのか？」といった質問をしているでしょう。
次のスライドでは、ROSAが環境でどのように動作するかについて詳しく説明し、その後、2023年に提供した機能と2023年末から2024年にかけて計画している機能について説明します。ROSAクラスターを作成する際には、ユースケースに合わせてクラスターを作成できるよう、多くのアーキテクチャの選択肢を提供しています。ここでは、ROSAクラスターを作成する際に行う3つの主要なアーキテクチャの決定について説明します。
まず、クラスターをパブリックインターネットに公開するかどうかを決定します。現在、本番環境で運用しているお客様の大多数は、パブリックサブネットやインターネットゲートウェイのないプライベートVPCでROSAを実行することを選択しています。次に、ROSAを単一のアベイラビリティーゾーンで実行するか、複数のアベイラビリティーゾーンにまたがって実行するかを選択します。この決定は、ワークロードの可用性の要件によって異なります。単一のアベイラビリティーゾーンのアーキテクチャは、可用性よりもインフラストラクチャの効率性が優先される開発やテストのワークロードに適している場合がありますが、本番環境で運用しているお客様の大多数は、複数のアベイラビリティーゾーンにまたがって実行することを選択しています。
最後に、従来のROSAデプロイメントモデルであるROSA classicを実行するか、新しいホステッド制御プレーン（HCP）を備えたROSAデプロイメントモデルを実行するかを選択します。ROSA classicでは、EC2インスタンスやROSA制御プレーン、インフラストラクチャサービス、ワーカーノードを実行するすべてのAWSリソースがお客様のAWS環境内に存在します。一方、HCP付きのROSAは、過去数ヶ月間パブリックテクニカルプレビューで提供されており、12月にGA（一般提供）になる予定の新しいデプロイメントモデルです。お客様はHCP付きROSAに非常に期待しており、私たちも同様です。HCP付きROSAのアーキテクチャの詳細については後ほど説明しますが、簡単に言えば、制御プレーンコンポーネントと一部のインフラストラクチャコンポーネントをお客様のAWS環境から中央のROSAサービスアカウントに移動させ、AWSインフラストラクチャのコストを削減します。
ROSA with HCPの利点と実装
では、ROSAクラスターを構成するAWSリソースとは何でしょうか？ユースケースを考慮し、ニーズを満たすアーキテクチャを図示してみましょう。シナリオに戻ると、ROSAを使用してクラウドに移行する予定の最初のアプリケーションは、銀行プラットフォームだとしましょう。トランザクション処理、データ管理、カスタマーサービスなどのアプリケーションコンポーネントがあります。プラットフォームには高可用性が必要で、Webコンソール、モバイルアプリケーション、カスタマーサービスチャットボットなど、フロントエンドコンポーネントのみをパブリックインターネットに公開したいとします。
このような要件を持つお客様が本番環境でROSAを実行する場合、現在最も多く選択されているのはこのスライドに示されているROSA classic マルチAZ PrivateLinkアーキテクチャですが、HCP付きROSAデプロイメントモデルがGAになれば、より多くのお客様がそちらを選択するようになると予想しています。では、アプリケーションをホストするROSAクラスターの基盤となるAWSサービスを見ていきましょう。まずはこのスライドに示されているROSA classic マルチAZ PrivateLinkアーキテクチャを構築し、その後、HCP付きROSAがROSA classicとどのように異なるかの詳細を説明します。まず、3つのプライベートサブネットを持つAmazon VPCを作成します。パブリックサブネットやインターネットゲートウェイは不要です。
ROSA classicとHCP付きROSAの両方で、これはPrivateLinkクラスターなので、AWSサービスのクォータ制限内に収まり、影響範囲を制限するために、実行する各ROSAクラスターに対して1つのVPCを作成することをお勧めします。ROSA classicでは、ワーカーノード、制御プレーン、インフラストラクチャサービスをホストするEC2インスタンスはすべてお客様のAWS環境内に存在します。
ワーカーノードから始めましょう。これらはワークロードをホストします。Treyが説明したように、主にコンテナ化されたアプリケーションとOpenShift Operatorです。OpenShift virtualizationの導入により、単一のROSAクラスター内でコンテナと仮想マシンを並行して実行することもできます。ROSAはワーカーノードのvCPU時間ごとにオンデマンドサービス料金を請求します。銀行プラットフォームのコンポーネント（トランザクション処理アプリケーション、データ管理アプリケーション、カスタマーサービスアプリケーションなど）は、コンピューティングとメモリの最適化に関する要件が異なり、スケーリング動作も異なります。
ROSAやOpenShiftでは一般的に、OpenShiftマシンプールを作成します。これにより、各アプリケーションコンポーネントに適したサイズのコンピューティング環境を作成し、個々のマシンプールにスケーリング動作を設定して、ニーズに対応することができます。ROSA classicでは、ワーカーノードに加えて、最低3つのROSAインフラストラクチャノードと3つのROSAコントロールプレーンノードがアカウント内で実行されます。インフラストラクチャノードは、OpenShiftのルーティング層、組み込みのコンテナレジストリ、およびPrometheusモニタリングスタックをホストします。
OpenShiftバージョン4.14以降では、クラスターへの顧客リクエストのイングレスはAmazon Network Load Balancerを通じて行われます。これにより、OpenShiftの以前のバージョンで使用されていたクラシックロードバランサーの実装と比較して、スケーラビリティの向上、レイテンシーの低減、全体的なパフォーマンスの向上が実現します。コントロールプレーンは、Kubernetes APIサーバー、Kubernetesコントローラー、およびクラスターの状態を追跡するetcdキーバリューストアをホストします。クラスター管理者は、コントロールプレーン上で実行されているOpenShift APIに対してアクションを取り、新しいマシンプールやOpenShiftプロジェクトの作成などを行うことができます。
これはマルチAZアーキテクチャであるため、コントロールプレーン、インフラストラクチャノード、およびワーカーノードを実行するEC2インスタンスは3つのAWS Availability Zoneにまたがって実行されます。これにより、障害耐性が提供されます。AZがダウンしたり停止したりしても、アプリケーションは引き続き実行され、クラスターは利用可能な状態を維持します。完全に管理されたOpenShift体験を提供するために、ROSA SREはクラスターの健全性を継続的に監視し、必要に応じてワーカーノードのライフサイクル管理やコントロールプレーンのスケールアウトなどの積極的な是正措置を講じます。これらのタスクを実行するために、ROSA SREはAWS Security Token Serviceから短期的な認証情報を取得し、AWS PrivateLink接続を介してAWSアカウントに対して限定的なアクションを実行することができます。
さて、移行中の銀行プラットフォームの一部であるトランザクション処理アプリケーションについて考えてみましょう。このアプリケーションは、企業のデータセンターからデータを取り込み、そのデータに対して処理を行い、結果をパブリックインターネット経由で提供する必要があります。まず、企業のデータセンターにAWS Direct Connect接続を作成し、AWS Transit Gateway経由でVPCへのセキュアなデータ送信を可能にします。データがVPCに入り、ワーカーノード上で実行されると、トランザクション処理アプリケーションがトランザクション処理を行い、結果をパブリックウェブ経由で提供したいと考えます。これはPrivateLinkクラスターであるため、VPC内にインターネットゲートウェイは実行されていません。お客様が一般的に取るアプローチは、トラフィックのイグレスとパブリックインターネット経由でのデータ提供を専門に扱う2つ目のAmazon VPCを設定し、このイグレスVPCを別のAWS Transit Gatewayを使用してROSA VPCに接続することです。
ROSAクラスターの基盤となるAWSリソースについて説明しましたが、トランザクション処理アプリケーションはデータベースやメッセージキューなどの他のAWSサービスと統合する必要があります。ROSAで実行されているアプリケーションを他のAWSサービスと統合するには、VPCゲートウェイエンドポイントを使用して、特にAmazon S3とAmazon DynamoDBに対するトランザクションを行うことができます。
別の方法として、インターネットゲートウェイやNATデバイスを必要とせずに、AWS PrivateLinkを使用することもできます。さらに、AWS PrivateLink接続を使用して、ROSAクラスター内で実行されているアプリケーションをAmazon SageMakerなどの他のAWSマネージドサービスに接続することも可能です。このアプローチを取る場合、ROSA SREが使用するPrivateLink接続を再利用したり転用したりするのではなく、ROSA VPC上に2つ目のPrivateLink接続を作成することをお勧めします。
クラウド移行とハイブリッド環境におけるROSAの活用
次に、AWS Transit Gatewayを使用して、ROSA VPCを共有サービスVPCに接続できます。共有サービスVPCもプライベートにすることができ、Amazon RDSなどのAmazonサービスを実行することができます。共有サービスVPCとROSA VPCの両方がプライベートである場合、必要に応じてパブリックインターネット経由でデータを提供したい場合は、インターネットゲートウェイとパブリックサブネットを持つ出口VPCに両方のVPCを接続できます。
ROSA classicのマルチAZ PrivateLinkアーキテクチャは、運用上のニーズとチームのニーズを満たしますが、インフラストラクチャのコストが積み重なり、AWS環境内でマネージド型のコントロールプレーンコンポーネントやインフラストラクチャサービスを実行したくないと考えるかもしれません。お客様から、ROSAをより効率的に実行する方法について定期的に質問を受けており、それがROSAのホステッドコントロールプレーン（HCP）の主要な利点の1つとなっています。
ROSA with HCPでは、コントロールプレーンノードとインフラストラクチャノードが提供するほとんどのサービスが、お客様のAWSアカウントから中央で管理されるROSAサービスアカウントに移動し、ROSAクラスターの実行にかかるインフラストラクチャコストが大幅に削減されます。中央で管理されるROSA VPCは、PrivateLinkエンドポイントを介してお客様のAWSアカウントで実行されているVPCに接続します。ROSA with HCPクラスターには、先ほど説明したワーカーノードのvCPU時間あたりの料金に加えて、クラスター時間あたりの料金が発生しますが、インフラストラクチャ支出の削減により、ROSAの実行にかかる総所有コストが大幅に削減されると予想しています。
ROSA with HCPは、2021年3月のローンチ以来、ROSAサービスの最も重要なアップデートです。12月には、ROSA with HCPを6つのリージョン（Virginia、Ohio、Oregon、Dublin、Frankfurt、Jakarta）でGA（一般提供）としてロールアウトする予定です。2024年1月から、さらに多くの商用AWSリージョンへのロールアウトを2024年前半にかけて進めていきます。ROSA with HCPのインフラストラクチャ効率の向上に加えて、ROSA with HCPクラスターは現在のROSA classicクラスターの約4分の1の時間で起動し、より迅速に本番環境に移行できるようになります。
また、ROSA with HCPのためのAWSマネージドポリシーのシリーズも導入しました。これにより、クラスターのアップグレードプロセスが効率化され、ROSAロールで使用されるAWSポリシー、IAMポリシーの更新責任をAWSが担うことになります。2024年前半には、ROSAマシンプール（デフォルトのマシンプールを含む）をゼロノードまで縮小する機能を導入する予定です。これにより、使用していないワークロード（例えば、週末のテストクラスター上のワークロード）をスピンダウンする際に、さらなるコスト削減が可能になります。
バンキングアプリケーションとホステッド制御プレーン付きROSAから話を移すと、オンプレミスや他の環境でOpenShiftやコンテナ上で実行されている多くのアプリケーションがあることはご存知でしょう。これらのアプリケーションの一部はクラウドに移行し、他はオンプレミスに残ることになります。Red Hat Hybrid Cloud Consoleを使用すると、OpenShiftクラスターがどこで実行されていても、観察や操作が可能です。AWS上に作成されたROSAクラスターは、自動的にRed Hat Hybrid Cloud Consoleと統合され、誰がどこでOpenShiftを実行しているかの全体的な概要を提供します。
コンテナ化されていて、クラウドへの移行準備ができている、つまりROSAへの移行準備ができているアプリケーションについては、Red HatがMigration Toolkit for Containers（MTCオペレーター）を導入しました。これをROSAクラスターと対象クラスターにOpenShift OperatorHubからデプロイします。このオペレーターは、移行の計画と実行のためのコンソールインターフェースを実装します。まだコンテナ化されていないが、迅速に移行したいアプリケーションについては、ROSAはsource-to-imageなどのツールを提供しています。これにより、ソースコードを実行可能なコンテナイメージに注入して、迅速にクラウドに移行できます。
しかし、一部のアプリケーションはVMで実行されており、まだコンテナ化の準備ができていません。コンテナ化されたワークロードと仮想化されたワークロードの一貫した管理体験を提供するために、 最近、OpenShift virtualizationのサポートを導入しました。KubeVirtプロジェクトをベースとするOpenShift virtualizationを使用すると、単一のOpenShift ROSAプラットフォーム上でLinuxとWindows VMをコンテナと並行して実行でき、管理が簡素化されます。
OpenShift virtualizationを使用すると、アプリケーションをコンテナ化する前に再ホスティングすることで、より迅速にクラウドに移行できます。同時に、仮想化されたワークロードに対して、パイプライン、GitOps、サービスメッシュなどのOpenShiftの構成要素を活用できます。オンプレミスとクラウド環境の両方に対応し、コンテナ化されたアプリケーションとVMで実行されているアプリケーションの両方に対応する、クラウドへの迅速な移行を可能にする戦略を開発しました。では、実際にROSAクラスターを一貫して作成するにはどうすればよいでしょうか？
TerraformによるROSAクラスターの自動化
クラウドインフラを一貫性のある再現可能な方法で作成することは難しい場合があります。ミッションクリティカルなインフラの更新を手動で行うとリスクが生じ、カスタムビルドされたスクリプトの管理は運用の負担を増やします。これまでは、ROSA CLIツールを使用するか（場合によってはそれに自動化を加えて）、あるいはRed Hat Hybrid Cloud Consoleを使用してROSAクラスターをプロビジョニングすることしかできませんでした。最近、私たちはROSA classicのTerraformサポートを導入しました。HashiCorp Terraformは、クラウドリソースのプロビジョニングのための人間が読める設定ファイルを作成でき、バージョン管理、再利用、共有が可能なインフラストラクチャ・アズ・コードツールです。
ROSA classicのTerraformサポートは、Red Hat Cloud Services TerraformプロバイダーとROSAクラスターモジュールによって実現されています。ROSAモジュールを使用すると、ROSAクラスター、マシンプール、AWSのアイデンティティプロバイダーを定義できます。さらに、ROSAクラスター上で実行されるアプリケーションが使用する他のAWSサービスも定義できます。ホストされたコントロールプレーンを持つROSAのTerraformサポートは、2024年前半に予定されています。Terraformを使用することで、顧客は今やROSAクラスターと、そのアプリケーションを実行するために計画している他のAWSサービスを、統一されたシステム内でプロビジョニングできるようになりました。
ROSAの最新アップデートと2024年の展望
ROSAが目標と要件に最も適していると確信しています。セキュアで効率的、そして高可用性のある方法でアプリをホストするために、プライベートなマルチAZのROSAとホストされたコントロールプレーンクラスターを利用します。ROSAが提供する移行ツールを活用してクラウドへの移行を迅速に行い、Terraformを使用してROSAクラスターのデプロイメントを自動化します。今、プルーフオブコンセプトを開始することに興味がありますが、その前に、サービスの最近の改良点と、今年の残りの期間および2024年に向けて計画していることについてもっと知りたいと思っています。
ここで、前のスライドで触れていないサービスの改良点と、今後予定されているROSAの改良点について簡単に説明します。ここで言及する時期はあくまで計画であり、コミットメントではありません。計画は変更される可能性があるためです。では、2023年にROSAをどのように更新したでしょうか？AIに焦点を当てる業界全体のシフトに伴い、加速されたコンピューティングの需要が高まっています。2023年には、P3、P4、G4、G5インスタンスファミリーのNVIDIAベースのGPUインスタンス、およびHabana LabsのDL1インスタンスタイプに対するROSAサポートを導入しました。年末までにNVIDIA P5ベースのインスタンスのサポートを導入する予定です。
お客様は、ROSA上に独自のAIOpsツールチェーンを構築することも、Red Hat OpenShift AIを活用することもできます。Red Hat OpenShift AIは、ROSAにAI/MLフレームワーク、ノートブック、その他のツールを追加し、モデルのトレーニングから微調整、サービング、モニタリングまでを最初から提供します。デプロイメントオプションに移ると、AWSリージョンは広大な地理的エリアをカバーしていますが、オンラインゲームや金融サービスなどの一部のユースケースでは、一桁ミリ秒の低レイテンシーやデータレジデンシー要件を満たすためのローカルデータ処理が必要です。AWS Local Zonesはこれらのニーズに対応しており、2023年には、ROSAのデプロイメントをAWS Local Zonesにも拡大しました。
また、クラスターのプロビジョニング時にカスタムAWSリソースタグを実装する機能もお客様に提供しました。お客様はリソースタグを使用して、クラスターやビジネスユニット全体の支出を追跡します。この機能のローンチにより、お客様は自動化されたクラスタープロビジョニングワークフローの一部としてAWSリソースタグ付けを含めることができるようになり、ROSAによってリソースが作成されるとすぐに効果的にコストを追跡できるようになりました。
ネットワーキングの観点から、一部のお客様はVPCやRoute 53ホストゾーンなどのネットワーキングコンポーネントの管理を一元化することを選択しています。このパターンを可能にするために、共有VPCサポートを導入しました。これにより、お客様は1つのアカウントでネットワーキングコンポーネントを作成し、VPCの特定のサブネットへのアクセスを、リソースを管理する他のAWSアカウントと共有することができます。
また、AWS Load Balancer Controllerのサポートも導入し、ROSAのイングレスコントローラーとしてNetwork Load BalancerとApplication Load Balancerを作成できるようになりました。最後に、ROSAの利用可能性をさらに多くのAWSリージョンに拡大しました。具体的には、UAE、スペイン、メルボルン、ハイデラバード、チューリッヒです。
2024年を見据えると、ホストされたコントロールプレーンを備えたROSAは、12月に6つのリージョンでGAとしてロールアウトされる予定です。2024年の上半期を通じて、現在ROSAクラシックが稼働しているすべてのリージョンで、ホストされたコントロールプレーンを備えたROSAをGAとしてロールアウトしていきます。また、テルアビブリージョンや2024年中にGAとなる他のリージョンにもROSAを拡大していく予定です。
コンプライアンス認証について話しましょう。多くの米国公共部門のお客様は、AWS GovCloudリージョンでFedRAMP Highレベルで運用することが求められています。ROSA classicはFedRAMP Highレベルでのagency authority to operateを取得し、2024年初頭のJABレビューに向けて優先されています。Red Hatの担当者と直接やり取りすることで、GovCloudでFedRAMP HighレベルのROSA classicにアクセスできます。年末までに、ROSAのGovCloudオンボーディングを開始するためのセルフサービスプロセスを導入する予定です。FedRAMP HighレベルでのROSA with HCP実装とGovCloudでの実装は現在計画段階にあり、今後数四半期にわたってROSA classicがROSA GovCloud展開の継続的なユースケースになると予想しています。
非GovCloudのAWS商用リージョンでFedRAMP Mediumレベルで運用する必要があるお客様向けに、2024年後半にROSA with HCP展開モデル専用のFedRAMP Medium認証を取得する予定です。ROSA with HCPは新しいため、ROSA classicが持つSOC 2、SOC 3、ISO、PCIDSS、IRAPなどの地域認証をまだ取得していません。2024年前半を通じて、FedRAMP High以外の認証についてROSA classicとROSA with HCPの間で認証の同等性を達成するよう取り組みます。FedRAMP HighについてはROSA with HCPでは後日対応する予定です。
展開オプションについて、特に通信業界で事業を展開しているAWSのお客様の中には、ROSAのコンピューティングとストレージを5Gネットワークに統合する必要がある場合があります。AWS Wavelengthはこのニーズに対応しており、2024年にはROSAのサポートをAWS Wavelengthに導入する予定です。 最後に、ROSAでサポートする新しいインスタンスファミリーを導入します。先ほど言及したNVIDIAベースのP5インスタンスに加えて、上半期にはROSA with HCPのマシンプールにARMベースのGravitonサポートを導入する予定です。お客様はGravitonインスタンスのコストパフォーマンスの高さを評価しており、ROSAでもご利用いただけることを楽しみにしています。また、新世代のインスタンスファミリーや新しいインスタンスタイプが一般提供されるにつれて、それらのサポートも追加していきます。
ROSAの活用事例とre:Inventでの学習機会
締めくくる前に、特に注目しているユースケースの1つを紹介したいと思います。それは、ROSAでIBMのビジネスソフトウェアを実行することです。IBMは、Maximo Application Suiteなど、次世代のビジネスソフトウェア製品をROSA上で動作するように再設計しました。これらの製品はAWS Marketplaceを通じてマネージドSaaSとして調達できます。その場合、そのソフトウェアをホストするROSAクラスターはお客様のAWS環境では実行されません。ただし、高度なセキュリティ設定や統合のニーズがあるお客様にとっては、マネージドSaaSオプションが適さない場合があります。そのような場合は、お客様のAWSアカウントでホストされるROSAクラスター上でIBMソフトウェアを実行することができます。ROSAを使用すれば、基盤となるプラットフォームの管理を心配することなくこれを実現できます。IBMソフトウェアの実行環境を検討する際には、ROSAを最優先に考えていただきたいと思います。
ROSAの使用を開始したり、詳細を知りたい方には、いくつかのオプションがあります。まず、QRコードからリンクされているRed Hat ROSAの製品ページからアクセスできる新しいROSA Hands-on Experienceがあります。この新しいHands-on Experienceでは、最大8時間まで無料でフル機能のROSA with HCPクラスターを利用できます。このクラスターを使用して、ROSAを使用したアプリケーションの構築、デプロイ、スケーリングの練習ができます。次に、ROSAワークショップに参加することができます。これらは大規模な仮想イベントとして提供されますが、お客様のチームと協力して、ユースケースやシナリオに合わせたカスタムワークショップを構成することもできます。最後に、準備ができたら、無料でROSAの概念実証を開始できます。AWSとRed Hatの専門家が、お客様の環境で実行されているROSAクラスターにアプリケーションを移行するお手伝いをします。カスタムROSAワークショップや概念実証にご興味がある場合は、TreyまたはPrivateにお問い合わせください。
re:Inventでは、ROSAについてさらに多くの学習機会があります。Red Hathのブース（ブース364）に立ち寄るか、AWSビレッジのKubernetesスタンドで私たちと話すことができます。また、ROSAを特集する他のre:Inventセッションにも参加できます。明日、Red HatとAir Canadaが、Air CanadaのROSAを使った取り組みについてセッションを行います。水曜日には、Red HatとAWSがRed Hathブースでセッションを行い、ROSAを使用してアプリケーションワークロードを最新化する方法について、IBM、SAS、MuleSoft、その他のCOTSアプリケーションに焦点を当て、それらをROSAでクラウドに移行する方法を紹介します。最後に、私のRed HatのPMの同僚であるAaronが、Red HathブースでいくつかのROSA with HCPの詳細セッションを行います。
re:Inventの旅の最初の立ち寄り先として、ここに来ていただき、誠にありがとうございます。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion