オンプレミスでのコンテナの課題と解決策は　クラウドスタッフをオンプレミスでもスムーズに活用　見えてきたマルチクラウド戦略の最適解

オンプレミスにもクラウドネイティブな環境を

デル・テクノロジーズ株式会社
Customer Centric Cloud and Containers
アジア・パシフィック＆ジャパン
アドバイザリーシステムエンジニア
平原一雄氏

将来を予測するのが困難な時代の中、急速に変化し続ける市場や顧客に対応するため、ビジネスに求められるやり方も大きく変化している。従来は、既に決められた業務プロセスを確実に回すことが重視されていたため、経験則や熟練者の勘でも十分に対応できた。しかし現在では、様々なところからデータを集め、そこから市場ニーズの変化などをとらえた上で、客観的なデータドリブン型の意思決定を行うことが必須となりつつある。

もちろんデータを有効に活用し続けるには、データソースを広げながら、そこから収集したデータをビジネスプロセスに取り込むアプリケーションを作成しなければならない。また新たなアプリケーションによって、収集されるデータの種類がさらに増えていくことも考えられる。このようなサイクルを確実かつ迅速に回し続けることが、DXを成功させる大きな要因の1つだといえるだろう。

「アプリケーションを素早くビジネスに投入し続けるには、その開発スピードの高速化が必要です。こうしたニーズへの親和性が高いことから、コンテナ技術が注目されています。コンテナ技術を活用すれば、アプリケーションを構成する各種機能部品（マイクロサービス）同士の疎結合が可能になり、新たなアプリケーションを開発する際に機能ごとに柔軟にスケールしたり、再利用したりすることが容易になります。また、既存アプリケーションの継続的な改善や機能強化を、アジャイルに進めることも可能になります」と指摘するのはデル・テクノロジーズの平原一雄氏だ。

このような特性が評価され、パブリッククラウドにコンテナ環境を構築し、「クラウドネイティブなアプリケーション」を開発する企業も増えている。もちろん開発環境だけではなく、最近はコンテナベースのアプリケーションの流通により、実行環境としてもコンテナ環境の採用が広がっている。

さらにこのような流れの中で、パブリッククラウド側で実現された「クラウドネイティブな環境」をオンプレミス側でも実現したい、というニーズが高まっている。アプリケーションやデータの中には、その機密性の高さやガバナンス確保のために、パブリッククラウドには載せにくいものもあるからだ。また定常的に負荷の高いアプリケーションをパブリッククラウドで動かすとコストが高くなるため、パブリッククラウドで開発したアプリケーションをオンプレミスで動かす、といったことも増えているという。

「つまり、オンプレミスとパブリッククラウドの間で、アプリケーションやデータをシームレスに移動できるマルチクラウド環境へのニーズが、急速に高まっているのです」（平原氏）

クラウドネイティブ環境をオンプレミスで実現する方法は

コンテナ環境（クラウドネイティブ環境）をオンプレミスでも実現するには、パブリッククラウド側で利用している「クラウドスタック」を、オンプレミス側にも実装する必要がある。同じクラウドスタックがオンプレミスとパブリッククラウドの両方にあれば、その間でのアプリケーションやデータの移動も容易になるだろう。

しかし、オンプレミスでのコンテナ環境の構築は、複数のオープンソースソフトウエア（OSS）を組み合わせて実装する必要があり、かなりの手間と時間がかかってしまう。またエンタープライズ向けのコンテナ基盤として高いシェアを持つRed Hat OpenShiftなどでも、3カ月程度のサイクルでバージョンアップを行う必要があり、インフラを含む導入後のライフサイクル管理の負担は小さくない。「導入とライフサイクル管理をどう簡素化するのか。これがオンプレミスでクラウドスタックを動かす際の、最大の課題だといえます」と平原氏は語る。

この課題を根本から解決するために、デル・テクノロジーズが提供を開始したのが「Dell APEX Cloud Platform」だ。

同社は「双方向マルチクラウド戦略」に基づき、「クラウド・トゥ・グラウンド（クラウドの体験をオンプレミスにもたらすこと）」と「グラウンド・トゥ・クラウド（オンプレミスで培われた最先端技術をクラウドでも利用可能にすること）」という、大きく2つの取り組みを進めてきた。Dell APEX Cloud Platformは「クラウド・トゥ・グラウンド」のアプローチの1つとなる。

その全体像を示したのが図1だ。大きく3つの要素で構成されていることが分かる。

クラウドスタックを動かす「コンピュートノード」、高性能SDSである「ストレージノード」、一元化された運用管理を実現した「M&O（運用管理ツール）」で構成されている

1つ目の構成要素は、中央に置かれている「コンピュートノード」。これはクラウドスタックを実際に動かすためのもの。各種クラウドスタックを最適な条件で動かせるように、BIOSやファームウエアなどの互換性が事前にコントロールされている。

2つ目は、右側に配置されている「ストレージノード」だ。これは、ノードの追加によって性能をリニアにスケールさせることができる、エンタープライズクラスのSDS（Software-Defined Storage）」。既に全世界で提供されている「Dell APEX Block Storage」と互換性があるという。

「クラウドスタックは将来のキャパシティが読みにくく、求められるI/O性能の予測も困難です。そこでコンピュートだけではなくストレージも、ノードの追加で性能を高められるようにしています。性能値はノード数とリニアに比例するため、サイジングや増強計画の立案も容易です。また99.9999％の可用性を実現しているため、大規模なミッションクリティカルシステムにも問題なく対応可能です。これと同じストレージノードを各種ハイパースケーラ上で稼働させれば、オンプレミスとパブリッククラウドとの間でのデータ移動やレプリケーションも、シンプルな形で実現できます」（平原氏）

そして最後の3つ目の構成要素が、左側に配置された「自動化されたM＆O（運用管理）」だ。

「Dell APEX Cloud Platform ではサーバーハードウエア上で直接クラウドスタックを動かしますが、ハードウエアからクラウドスタックまで一元管理できるようにしているのがこのM＆Oツールであり、Dell APEX Cloud Platformの心臓部ともいえます。既にデル・テクノロジーズは、VxRailで当社ハードウエアレイヤとVMware社のハイパーバイザレイヤの一元管理を実現しており、Dell APEX Cloud Platformでもそのノウハウを活用しています」と平原氏は話す。

導入時間とアップデートの時間を10分の1以下に

このDell APEX Cloud Platformで動かせるクラウドスタックは、現時点ではMicrosoft Azureのクラウドスタックと、Red Hat OpenShiftの2種類。近い将来にもう1つVMwareが追加される予定だ（図2）。

現在既に、Microsoft AzureとRed Hat OpenShiftに対応しており、近い将来にはVMwareに対応したものも提供される

それではDell APEX Cloud Platformによって、冒頭で指摘した課題はどう解決できるのか。

「例えば、Dell APEX Cloud Platform for Red Hat OpenShiftを例に挙げてみます。まずRed Hat OpenShiftをサーバーハードウエアに直接導入する場合、手作業では80時間程度かかります。これに対してDell APEX Cloud Platformでは、ウィザード型の導入ツールを使うことで6時間程度にまで短縮可能です。またウィザード型なので決められたパラメータに基づく実行で試行錯誤を排除でき、確実な導入を可能にします」と平原氏は説明する。

「短時間で確実に導入できること」は、オンプレミスとパブリッククラウドの「適材適所」での活用を実現する上で、大きな意味を持つことになる。ここで時間がかかりすぎてしまうと、迅速なサービス投入を期待する事業部門の意向が、パブリッククラウドに流れやすくなる傾向があるからだ。

導入後は、自動化されたM＆Oによる一元管理が可能になる上、Red Hat OpenShiftの管理画面で、ハードウエア管理まで実施できる。さらに注目したいのが、Red Hat OpenShiftのアップデートも大幅に効率化できる点だ。Dell APEX Cloud Platformには自動化されたライフサイクルマネジメント機能が装備されているからだ。

「クラウドネイティブ環境は短いサイクルでアップデートされており、そのメリットを享受したいなら、迅速にアップデートを適用しなければなりません。従来のオンプレミスシステムのような『塩漬け』という選択肢は、もはや考えるべきではありません。Dell APEX Cloud PlatformはVxRailと同じ考え方に基づき、デル・テクノロジーズがハードウエアとの整合性をきちんと確認した上で、最新アップデートを提供します。これを自動化されたライフサイクルマネジメントで適用することで、事前チェックなどスタック更新にかかる時間も約90％削減でき、ハードウエアとの不整合で発生する問題も回避できるのです」（平原氏）

さらに長期的なビジョンとして、単一の共通ストレージレイヤの上で、異なるクラウドスタックを載せた複数のコンピュートノードを動かすことも計画されているという。これが可能になれば、コンテナ化されたアプリケーションの移動を、異なるクラウドスタック間で行うことも容易になる。共通ストレージレイヤにある永続ボリュームを、移動したコンテナにひも付けるだけで再利用できるからだ（図3）。

共通ストレージレイヤ上で複数のクラウドスタックを動かし、これらを統合管理できるようにすることが計画されている

またパブリッククラウドにも同じ共通ストレージレイヤを実装しておけば、マルチクラウドでの相互運用がより円滑になることも期待できる。例えば、Microsoft Azure上のコンテナと永続ボリュームをオンプレミスのDell APEX Cloud Platform上で動くAzureスタックへと移し、その次にDell APEX Cloud Platform上で動くRed Hat OpenShift環境へと移動、さらに別のパブリッククラウド上にあるRed Hat OpenShift環境に持っていく、といったことが可能になるわけだ。

「マルチクラウドスタックで構成された環境も、単一の運用管理ツールで統合管理できるようにする予定です。これによってDell APEX Cloud Platformは、マルチクラウドで動くクラウドネイティブ環境の『ハブ』として、重要な役割を担うようになるはずです」（平原氏）

このようなクラウドネイティブ環境の実現は、ITインフラ全体を管理・運用するIT部門にとって、最適解の1つだといえるだろう。