ハイブリッドクラウド環境のアプリケーション展開

記事をシェアする:

多くの企業が、一部のワークロードをクラウドに移行中もしくは、すでに移行済であることは周知の事実です。今日、企業における最も一般的なITインフラストラクチャー戦略は、オンプレミス／プライベートクラウドとパブリッククラウドの組み合わせ、あるいはハイブリッド・マルチクラウドと呼ばれる環境を目指しています。Flexera社が行なった調査では、企業の84％がマルチクラウド戦略を持っていますが、そのうちハイブリッドクラウド戦略を計画している企業の割合が58％に増加しています。

というのも、企業がアプリケーションやデータをすべてクラウドに移行することや、アプリケーションのホスト先として１つのクラウド事業者のみを選択することもまれなためです。それは何故でしょう？

クラウド事業者が提供するパブリッククラウド・サービスは、各社の注力する業界や、得意とする分野に最適化されています。また、クラウド事業者が提供しているAPIやミドルウェア、ハードウェア構成、ネットワーク特性もそれぞれ異なります。クラウドの採用が進むにつれ、企業はコンプライアンスやセキュリティー、スケーラビリティー、コストなど、特定の要求を満たせるクラウドの利用を検討し、使い分けることができるのです。

しかし、クラウド事業者の選定にあたっては、特定ベンダーのシステムにロックインされる懸念と同様に、特定クラウド事業者（のサービス）にロックインされる懸念も考慮しなくてはなりません。例えば、あるパブリッククラウド・サービス上に構築したシステムが、クラウド事業者のサービス規約の変更やビジネス・ニーズの変化によって、機能要件や非機能要件を満たさなくなり、他の環境へアプリケーションやデータを移行する必要に迫られることがあります。珍しいことではありませんが、オンプレミス／プライベートクラウド／パブリッククラウドは、その提供者や事業者によって特性が異なり、必ずしも希望通りに移行できるわけではなく、思わぬ手間やコストが発生することがあります。

容易に想像できるように、ハイブリッド・マルチクラウド環境はITインフラストラクチャーの観点でもアプリケーションの観点でも複雑になります。管理対象が増える中、アプリケーション毎に異なる機能要件／非機能要件を複雑な環境の中で最適化し、ビジネス・ニーズの変化にも柔軟かつ迅速に対応が求められます。

では、どのような点に注意して、ITインフラストラクチャー戦略の策定や、システムやクラウド・サービスを選択すればいいのでしょうか？

1つは、オープンなテクノロジーへの対応を見極めることです。コンテナや、動的オーケストレーションのためのオープンソースであるKubernetesなど、多くのクラウドがサポートしているオープンな基盤の上にシステムを構築することで、ハイブリッド・マルチクラウド環境においてもアプリケーションの可搬性を高めることができます。

もう1つは、マルチクラウド環境に適した運用管理の実現です。多くの企業は、この複雑なハイブリッド・マルチクラウド環境に向かって進んでいますが、パブリック・クラウド・サービスの採用でITインフラストラクチャー・コストが削減できても、運用コストが増大しては意味がありません。この課題の対応策としては、オープンな・テクノロジーに基づく複数のクラウド環境に対して一元的に管理・運用を可能とするマルチクラウド対応の管理ツールを採用することが考えられます。

 

絶えず変化するワークロード

アプリケーションの配置場所には多くの選択肢があるだけでなく、それらを実装する方法についても複数の選択肢が存在します。

従来、私たちは、単一のオペレーティング・システムを実行し、そのシステムが所有するすべてのハードウェア資源を利用するスタンドアロン・システムを使用し、通常、単一機能のアプリケーションを稼働させていました。ハイパーバイザーによる仮想化によって、プロセッサー、メモリー、I/Oなどのハードウェア資源を「共有」できるようになりました。つまり、単一のサーバーにさらに多くの仮想マシンを詰め込めるということです。ただし、それぞれの仮想マシンにはオペレーティング・システムとアプリケーションが稼働しています。コンテナ化は、オペレーティング・システムに仮想化のコンセプトを導入しました。これにより、コンテナはアプリケーションのランタイム・コンポーネントのみを含めればよく、「縮小化」された環境でアプリケーションのデプロイ、実行が可能となります。その結果、仮想マシンで展開・稼働するよりも必要なシステム資源は少なくなります。

図1：仮想マシンとコンテナーの比較

 

企業にとっての意義

企業は、従来のアプリケーションの一部をクラウドネイティブ・アプリケーションに変換する方法を模索していますが、同時に、特定のワークロードは非機能要件を満たすために仮想マシン上で稼働させなければならない必要性を認識しています。このことは、コンテナ化されたワークロードと仮想マシンのワークロードの両方を、最も適したハイブリッド・マルチクラウド環境に展開／管理する必要性があるということです。

さらに、コンテナをデプロイ後に管理することを想像してみてください。コンテナは正しく起動したか？期待どおりに機能しているか？アプリケーションへのアクセス管理は？アプリケーションのアップグレードをどう進めるか？これを、数百または数千の個別のコンテナを実行している環境で1つ1つ行うのは気の遠くなる作業で、どれほど複雑で困難な作業であることがお分かりいただけると思います。

こうしたコンテナ管理にまつわる課題を解決するテクノロジーとして、今、最も注目を集めているのがRed Hat OpenShiftです。

 

Red Hat OpenShiftがどのように役立つか

Red Hat OpenShift Container Platformは、Kubernetes上に構築されたエンタープライズ対応のサービス・プラットフォームです。その主な目的は、ハイブリッド・クラウド上でコンテナ化されたマイクロサービス・アプリケーションを構築し、スケール可能なプラットフォームをユーザに提供することです。 OpenShiftで利用可能な機能は多岐にわたり、数多くのブログ記事を書くことができるほどです。それらの機能は、オンプレミス、パブリッククラウド、またはマネージド・サービスを通じて提供することができます。

OpenShift Container Platformアーキテクチャーは、マスター・ホストとワーカー・ノードで構成されます。マスター・ホストには、APIサーバー、クラスターストア (etcd) 、コントローラー・マネージャー、HAProxyなどのコントロール・プレーン・コンポーネントが含まれており、単一点障害を回避するために高可用性構成で展開する必要があります。OpenShift Container Platform v 3.11では、マスターホストはIBM Power Systemsで稼働するRHEL環境、またはx 86上で動作するRHEL/Atomic環境です。

ワーカー・ノードは、マスター・ホストによって管理され、アプリケーション・コンテナの実行を担当します。これらのアプリケーション・ワーカー・ノードは、マスター・ホストによってワーカー・ノードにスケジュールされます。OCP v3.11では、ワーカーノードは、IBM Power SystemsやIBM Z、IBM LinuxONEで稼働するRHEL、またはx86で稼働するRHEL / Atomic / Linux環境です。なお、現在、同じOCPクラスター内でノード・アーキテクチャーを混在させることはできません。

 

OpenShift Container Platformで実現できること

OpenShiftは、DeploymentConfig、StatefulSets、DaemonSetsなどの多数のデプロイメント・メソッドを提供しています。これらにより、ポッドの数、レプリケーションの数、それらのポッドに使用するイメージ、スケーリング・オプション、アップグレード・オプション、ヘルスチェック、モニタリング、サービスIP、ルーティング情報、リッスンするポートなどの主要な機能を含む、コンテナ化されたアプリケーションのデプロイ方法を定義できます。次に、そのアプリケーション・テンプレートをカタログに追加し、セルフサービス・ポータルのユーザーが自分のプロジェクト・スペース内にアプリケーションを展開できるようにします。

次に、アプリケーションをどのように監視できるのかをご説明します。OpenShiftはコンテナを監視して、定義された状態と一致していることを確認します。定義された状態から逸脱している場合、OpenShiftは問題を解決するためのアクションを実行します。

例えば、アプリケーションが構成テンプレートで2つのポッドが必要だと定義されていて、何らかの理由で2つのポッドの1つが終了した例を考えてみましょう。OpenShiftマスターは、次の図に示すように、この逸脱を認識してアクション（この場合は新しいポッドを作成）を実行します。

図2：終了したポッドの代わりに、新たにポッドを作成している画面

 

IBM Cloud Pak for Data

Red Hat OpenShift Container Platform上に構築され、企業がデータを収集、編成、分析し、組織全体にAIを組み込む方法をモダナイズする ”データとAIのための統合プラットフォーム” がIBM Cloud Pak for Dataです。IBMやサード・パーティーの数多くのマイクロサービスで簡単に拡張可能なIBM Cloud Pak for Dataは、あらゆるハイブリッド・マルチクラウド環境で稼働し、企業がより簡単に分析とアプリケーションを統合して、イノベーションを加速できるようにします。

2020年6月に発表された最新版V3.0では、Red Hat OpenShift v.4.3の採用により非機能要件（バックアップやロギングなど）の強化に加え、より可用性に優れた基盤や高い処理能力が必要な場合に向けてIBM Power Systemsにも対応しています。Power Systemsが搭載するPOWER9は、x86と比較して同時処理可能なスレッドがコアあたり2倍または4倍となっており、コンテナを活用したクラウドネイティブなアプリケーションを少ない資源でも高速に処理することができます。

ブログ：Red Hat OpenShift 4.3がPower Systemsに対応

 

IBM Cloud Pak for Multicloud ManagementおよびCloud Automation Manager

Red Hat OpenShiftはコンテナ化されたアプリケーションを提供するだけでなく、マルチクラスター環境を管理し、オンプレミスやパブリッククラウドにまたがって仮想マシンなど従来のIT環境を管理することができます。

Red Hat OpenShift Container Platformで稼働するIBM Cloud Pak for Multicloud Managementは、アプリケーションがオンプレミス、クラウド、エッジのいずれか、あるいはこれらの間のどこにあろうと、一貫性のある可視化、ガバナンス、オートメーションが提供されます。企業は、複数のKubernetesクラスターの管理、イベント管理、アプリケーション管理、ITインフラストラクチャー管理ができます。また、IBM Cloud Pak for Multicloud Management は、予測された「ゴールデン・シグナル」に基づく高度なデータ分析により、柔軟性向上とコスト削減をご支援します。

 

図3：IBM Cloud Pak for Multicloud Managementの概要

IBM Cloud Pak for Multicloud Managementから、OpenShiftクラスター内にIBM Cloud Automation Manager（CAM）をデプロイできます。Cloud Automation Managerを使用すると、オンプレミスのIBM PowerVC（OpenStackに基づく）やVMware vSphere環境に、IBM Cloud、Amazon EC2、Microsoft Azure、Google Cloudなどのクラウド事業者を登録でき、複数のハイブリッド・クラウド環境に仮想マシンのアプリケーションをプロビジョニングできます。

クラウド事業者を追加したら、次に、ターゲット環境内での仮想マシンの外観を定義するTerraformベースのテンプレートを構成し、次の図に示すように、このテンプレートをOCPカタログに表示されるサービスとして公開できます。

図4：仮想マシン・オプションを含むOpenShiftカタログ

Red Hat OpenShift、IBM Cloud Automation Manager、IBM PowerVCを組み合わせることで、図4に示すようなアプリケーションのセルフサービス・カタログを提供することが可能になり、ハイブリッド・マルチクラウド環境にまたがる複数のアプリケーションをリクエストできるようになります。

 

---

＊本記事は、How Red Hat OpenShift can support your hybrid multicloud environmentを抄訳し、一部編集したものです。