Red Hatが提供するKubernetesベースのコンテナ管理プラットフォーム「OpenShift」をAmazon Web Services（AWS）上でフルマネージドする「Red Hat OpenShift Service on AWS（ROSA）」。AWSにはコンテナ向けサービスとしてAmazon Elastic Container Service（Amazon ECS）、Amazon Elastic Kubernetes Service （Amazon EKS）、AWS Fargateなど複数のコンテナサービスの選択肢があるが、ROSAはどのような用途に向いているのだろうか。
レッドハットテクニカルセールス本部シニアソリューションアーキテクトの北山晋吾 氏と、AWS Japan Specialist Solutions Architect, Containers の林政利 氏が、各コンテナサービスとの違いやROSAの特徴・メリットについて意見を交わした。
アプリケーション特性にあったコンテナ環境を
北山：年々コンテナの需要が増えていますが、レッドハットから見ると最近はその需要にも少し変化が見られます。従来は技術者がクラウドネイティブな最新技術の1つであるからという理由でコンテナを利用しはじめましたが、この波はいったん落ち着いて、現在はビジネスオーナーの方たちがコンテナを使うことに対するビジネスメリットに注目しています。このあたりAWSの状況はいかがですか？
林：AWS側から見ても、そのような実感があります。特にアプリケーションのモダン化というキーワードで注目されていますね。AWSのイベントでも、コンテナを使ってアプリケーション開発を迅速にできるようになった事例のお話が多いです。
北山：Red HatのOpenShiftを使っていただく理由としては、開発者の方々がアプリケーション開発の時間にフォーカスできるかという点を重視しています。コンテナアプリケーションを開発したいと思っても、オープンソースのソフトウェアを組み合わせたり、コンテナの技術そのものについて学ぶ必要があったりして、実運用に持っていくのは難しいものです。そこでOpenShiftが求められる状況にあると思います。
林：AWSのコンテナサービスも、開発者の方々のアプリケーション開発のハードルをどんどん下げていこうという方針です。Amazon ECS、Amazon EKS、AWS Fargateを活用することで、コンテナをデプロイするインフラ運用を極力減らすことができます。オープンソースのKubernetesを利用して AWS 上に自分でクラスターを構築する場合、実運用に必要なソフトウェアの調達やKubernetesの更新に伴う保守作業など、アプリケーション開発やビジネスの観点で差別化にならない重労働が発生します。
北山：Kubernetesはプラットフォーム上でいろんなオープンソースを組み合わせて環境を自由にカスタマイズできますが、実際のところ多くのエンタープライズユーザーではそこまで行うのは難しいと思います。
選定の検証にも時間がかかりますし、特にエンタープライズ用途では、保守や障害時のサポートなども必要です。一方、ROSAではOpenShiftに同梱のソフトウェアのサポートだけでなくインフラ環境もクラウドサービス事業者が管理するので、利用者のサービス形態にあわせてアプリケーションを作っていけます。
また、エンタープライズの世界では、Kubernetes環境を選ぶ際に、Amazon ECS、Amazon EKS、ROSAなどを比較検証することもあります。しかし、横並びで機能比較するよりも、自分たちのアプリケーション開発や運用にどういうメリットがあるかといった点に時間を割いた方がよいと思います。
林：AWSに関しても、マネージドで提供している機能自体の検証に多くの時間を割かれているお客様がいらっしゃいます。自分たちで構築していくアプリケーション部分の検証にお時間を使ってほしいという考え方は同感です。AWSが大事にしている考え方に「責任共有モデル」があります。お互いに責任を負う部分を明確にして、一緒にサービスを作っていくという考え方です。AWS のコンテナサービスでも明確な責任共有モデルがあり、特に環境がマネージドになるにつれ、AWSの責任範囲が大きくなるようになっています。これにより、お客様が効率よくアプリケーション開発の部分に時間を使えるようになります。
北山：運用責任の共有というのは今の時代すごく大事だと思います。ROSAもお客様と我々の責任分岐点がはっきり分かれています。運用体制を外部に委託する企業では、中間層にシステムインテグレーターが置かれて責任範囲がブラックボックス化していることも少なくありませんでした。このあたりはコンテナを利用する上でも、はっきりと決まっていた方がよい点です。
林：OpenShiftの場合もはっきりしていますね。ユーザーがカスタマイズできる範囲を限定していてとにかくプラットフォーム上での開発にフォーカスしてくださいという作りになっています。
北山：責任分界点を明確化し、その制限の中で開発することが結局その開発スピードや運用の効率化につながります。アプリケーション開発体制にもよりますが、一定の責任分界点があって、そのなかでやれることを決めていくのがポイントです。
AWSにおけるコンテナ環境の選定ポイントは？
林：コンテナ活用もチームのスキルセットや資産によって、どれを選択するかが変わります。選択肢は非常にたくさんありますが、どのように選べばよいのでしょうか？
北山：Kubernetes上のコンテナ開発では、クラウド上のサービスやオープンソースで提供される監視やロギング、CI/CDのパイプライン、サーバレスを組み合わせることが前提です。ROSAではこれらがはじめからマネージドで提供され、すぐに動かせるというメリットがあります。その代わり、細かく環境をカスタマイズしたいという要求には向いていないので、そういったニーズの場合はAmazon EKSを選択していくことになると思います。
林：AWSの立場としても同感です。各サービスの図を用意しました。Amazon ECSは、AWSネイティブのコンテナサービスです。お客様はコンテナでのアプリケーション開発に注力し、それ以外の部分はAWSの機能や進化の恩恵を最大限享受できるように設計されています。
次にAmazon EKSは、OSSで開発されているアップストリームのKubernetesを、セキュアで信頼性の高い形で利用できるマネージドのKubernetes環境です。お客様の課題解決にKubernetesが必要であるというケースで採用されるサービスになります。つまり、KubernetesのAPIを使用したOSSのツールや運用手法を活用しつつ、AWSのサービスや機能と連携してコンテナ環境を構築したいケースを想定しています。Kubernetesにおける膨大なソフトウェアエコシステムを組み合わせたシステムを組む場合は、Amazon EKSの方が動かしやすいです。
ROSAの場合は、OpenShiftに統合された機能の範囲内でアプリケーションを運用できます。コンテナ化されたアプリケーションの実運用環境がすぐに整い、環境の管理やサポート、請求をシンプルにできます。Kubernetesエコシステムの選定やその検証を、自身で行うのでは無く、Red Hatにより既に検証され統合されたOpenShift環境を利用する、さらにそのOpenShift環境をマネージドで利用することでKubernetes環境の運用負荷を下げたい場合の選択肢ですね。
北山：特にOpenShiftでは、どこでも同じ運用でコンテナを管理できることが注目されています。OpenShift上で動いているソフトウェアは、AWSだけではなくて別のクラウドでも同様に稼働します。JenkinsやPrometheusなどの周辺サービスがどの環境からも使えるというのが大きなメリットです。
林：一般的に開発者はアプリケーション開発に時間を注ぎたいので、その外側は管理したくないですからね。
北山：特にROSAの場合は、OpenShiftの運用そのものをAWSやRed Hatに任せられるので、柔軟な対応ができます。これまでAWSは様々なサービスを自動化してきたと思いますが、これからはさらに上のレイヤーまでマネージドサービスを展開していく流れになります。
林：マネージドサービスの場合サポートという考え方は難しいですが、特にROSAやOpenShiftを利用する場合のメリットはありますか？
北山：開発用のベースイメージを合わせてサポートするのは大きなメリットです。通常アプリケーションの開発キット(SDK)や実行に利用するランタイムをサポートしてほしいと言われたら、サードパーティーベンダーの仕組みを利用しなければなりません。一つ一つソフトウェアベンダーと契約しなければならないのです。OpenShiftなら、Red Hatが提供しているミドルウェアや開発用のコンテナイメージが サポートされているのがポイントですね。また、サードパーティーベンダーとのパートナーシップにより、サードパーティー製アプリケーションのサポートもサードパーティーベンダーにより提供されます。
林：アプリケーションのイメージをサポートしているのが嬉しいという声は、ROSAを利用しているお客様からもよく聞きますね。
北山：Red Hatの場合は以前からRHEL（Red Hat Enterprise Linux）があり、OSのカーネルレベルでサポートしています。コンテナのポータビリティを考える場合でもカーネルのバージョンが同じということが大前提となりますので、OpenShiftはその大前提を忠実に守っています。エンタープライズの世界ではオープンソースを選ぶのはしんどいという話をよく聞きます。障害が起きた時にどのライブラリに原因があるのかといった調査や、ミドルウェアのエラーを切り分けるのは難しいです。また、保守といってもオープンソースのコミュニティへの問い合わせでは、サービスレベルアグリーメント(SLA) などで対応時間や応答時間が定義されているわけではありません。
ROSAでは我々とAWSが連携してトータルにサポートできるというのが強力なアドバンテージです。
林：Red HatまたはAWSのどちらにも問い合わせできます。エンタープライズの商用環境でも安心して使うことができますね。
マネージド対象とパートナーシップの増加でエコシステムを強化
林：OpenShiftでは、クラスタの監視もある程度セットされていて、導入時点から何を見たらよいかもほぼ決まっていますので、サービスのビジネス指標を測定することに集中できますね。
北山：今までプロセス監視みたいなことに工数を割いていたかもしれませんが、コンテナ環境ではそれがなくなり、サービスの継続性という観点を考えた監視項目を新しく定義する必要があります。これには、OpenShift標準の監視機能が役立ちます。
また、Red Hatではマネージドのポートフォリオを広げる考え方を進めていて、さらにレイヤーを上げようとしています。特に注目しているサービスが、APIやKafkaを使ったキューシステム、機械学習のマネジメント領域です。ROSA上でRed Hatのミドルウェアサービスをマネージドで提供していきます。
林：幅広いマネージドサービスを提供し、お客様はそのサービスをニーズに応じて選択し、要件を柔軟に実現することができる。AWSではこの考え方を「ビルディングブロック」と呼んでおり非常に大切にしています。ROSAにおいても、AWSのサービスのみならず、Red Hatのマネージドサービスを組み合わせて、柔軟にお客様の要件に沿ったものを選択し組み合わせることができますね。
北山：パートナーのネットワークも重要ですね。AWSのパートナーネットワークに優秀な企業様が参画されているように、OpenShiftでも同じようにISV(独立系ソフトウェアベンダ)パートナーとの関係を強化していきたいと考えています。
林：AWSも単独のコンサルティングだけでよいとは思っていません。パートナーによってお客様に対してさまざまな選択肢があることが良いことであり、多様な“パートナーネットワーク”があることがAWSの強みだと感じています。
北山：Red Hatでも、パートナービジネスをより拡充させた方が、ROSAの新たなインテグレーションも生まれてくると考えています。ぜひともパートナー企業を増やしていきたいですね。
OpenShiftでは、「Commons」というイベントでコミュニティのさまざまな情報を発信しています。
林：AWSでも「Black Belt」というオンラインセミナーシリーズをYouTubeにアップし続けていますのでぜひご覧いただきたいです。
