text=佐藤 龍一 日本アイ・ビー・エム
コンテナとストレージからDXを考える
ビジネス環境が今、急速に、かつドラスティックに変化している。企業がさらなる成長を目指すには、ITやデジタルデータを積極的に活用するDXへのチャレンジが不可欠であり、マイクロサービスによるアプリケーション開発を推進するのが有効だ。その中心技術となるのが、コンテナである。
企業の新たなる発展を目指す手段としてDXを視野に入れ、適用業務の開発を従来型からコンテナ技術へ積極的にシフトしていくべきである、と筆者は考える。
コンテナの利用環境としてはスピード、容易性、低コストなどの観点から、パブリッククラウドが第一の選択肢として検討される。しかし業務システムに求められるさまざまな要件を考慮すると、本番環境では、コンテナを運用する環境としてパブリッククラウドではなく、オンプレミスの方が適しているケースも多々ある。
コンテナのデファクト・スタンダードとして注目されるのがKubernetesであり、非常に有効なオーケストレーターである。しかしこの優れたコンテナ・プラットフォームをオンプレミスで構築する場合、運用担当者は膨大なコンポーネントの機能性を理解し、最も有効な組み合わせとなるよう取捨選択する必要があり、オープンソースゆえのサポートの困難さに直面することになる。
そこでKubernetesを中心に、ユーザーの利便性を考慮しながら各種コンポーネントをパッケージングしたのが、「Red Hat OpenShift」(以下、OpenShift)である。 OpenShiftを採用すれば、運用担当者はテスト済みの各種コンポーネントを最適に組み合わせたレベルセットを利用でき、かつRed Hat社から的確なサポートを受けられる。
ただしOpenShiftを採用するだけでは、十分ではない。特に共通の課題となり得るのがストレージ環境だ。これに応えるために製品化されたのが、「IBM Spectrum Fusion」である。
IBM Spectrum FusionはOpenShiftを基盤としながら、バックアップ機能や、高性能かつ高可用性を維持しながらサーバー内蔵ストレージを効率よく利用する機能を標準搭載し、ハイブリッドクラウド環境でのデータ共有を実現するAFM(Active File Management)機能を追加で提供するなど、コンテナ・ネイティブ時代の多彩なストレージ・ニーズに対応している。
本稿では、コンテナの実行環境としてオンプレミスの方が適しているケース、その場合の運用上の課題、OpenShiftの特徴と、それをストレージ面から強化する「IBM Spectrum Fusion」の概要を解説していこう。
コンテナの実行環境
クラウドに適さず、オンプレミスを選択すべき理由
コンテナ技術を利用したアプリケーションの実行環境としては、まずクラウドが注目される。スピード、容易性、低コストなど、パブリッククラウド上で提供されるコンテナ・マネージド・サービスの利用メリットは大きい。
業務を実行する場所は、その業務の実行にふさわしい環境であればよい。企業や組織の運営という観点から見れば、経済的かつ効率的に業務を実行できればよいわけだ。ゆえに適材適所でIT資源を利用できる点でハイブリッドクラウドが注目され、ハイブリッドクラウドを前提とする技術が発達・選択されることになる。
しかしパブリッククラウドではなく、オンプレミス(ローカル環境)にある仮想サーバーや物理(ベアメタル)サーバー上でコンテナ環境を用意することもできる。
「新しい業務システムは、必ずパブリッククラウドで実行しなければならない」とか、「本番業務システムは、オンプレミス環境で実行するのがよい」などと、画一的に考える必要はない。
初期段階ではパブリッククラウド上にコンテナ開発環境を作り、少しずつ動かし始めるなら、大きな問題は生じないだろう。コンテナによる開発のよさを実感できれば、場合によってはオンプレミスで動かしている現状の業務をコンテナで稼働させていけばよい。
あるいは、「新しい業務システムはパブリッククラウドで稼働させる」という企業方針が明確であるなら、オンプレミスの業務をパブリッククラウドへ移行していけばよい。
しかし本番稼働を想定した場合、以下のようにパブリッククラウドでの運用が適さないシステムもある。
・データの機密性やコンプライアンス、企業内の規定といった観点から、データを外部に保管できない、あるいは保管したくない
・データがオンプレミスで発生し、そのデータを即時に処理・分析する必要がある
・オンプレミスとパブリッククラウド間、あるいはパブリッククラウド同士でのデータ転送量が多く、転送時間と料金(特に下り料金)がかかる
・継続的で変動が少なく、CPUに高負荷な処理がある(高負荷状態が継続すると想定される場合は、パブリッククラウドよりオンプレミスで動かした方が経済的である)
・タスクを分割して、複数のタスクで並列処理することが困難である
・すでに大容量のデータが存在し、データ保管先に選んだパブリッククラウドから容易に離脱できなくなるリスクが将来的に懸念される
・レベルの高い高可用性構成など、利用を想定するパブリッククラウドでは現時点で希望するサービスレベルが満たせない
上記のいずれかに当てはまる場合、本番稼働ではコンテナをオンプレミス環境で用意するのが望ましい。
ただしコンテナ環境をオンプレミスで動かすための準備は、それほど楽ではない。しかもその運用は一筋縄ではいかず、乗り越えるべき種々の課題がある。
たとえば現在のデファクト・スタンダードであるKubernetesはコンテナ・オーケストレーターとして、効率的な導入や運用の仕組みを提供しており、情報の入手も容易である。オープンソースなので、すべて自社で運用すれば、利用コストが発生しない点も歓迎できる。しかし筆者の知る限り、Kubernetesはシステム運用管理者にとって高いハードルとなる懸念がある。
その原因は、利用可能なコンテナ関連のコンポーネントが非常に多く、その選択や組み合わせが多岐に渡ることにある。必要とされる技術の範囲がとても広く、コンポーネントの多くはオープンソースであるため、バージョンやリリースの変化も速い。
どれを選び、どれをアップグレードし、どれを現状のまま維持するかは、運用担当者の責任となる。数多くの斬新な技術をキャッチアップしながら、的確にコンポーネントの組み合わせを取捨選択していくのは、高度な知識と時間的余裕が必要となる。
専任・専門の担当者が求められる場合もあるだろう。市販のソフトウェアと異なり、料金が発生しない点はコスト的なメリットに見えるが、トラブル発生時にサポートを依頼するベンダーが存在せず、相談相手の確保も難しい。自力では解決手段が得られず、途方に暮れるような状況に陥り、運用管理技術者に大きな苦痛を生む。ハードであれソフトであれ、システム的な課題に直面した経験があるなら、その大変さを理解できるだろう。
それに技術者の養成も容易ではない。たとえば、Kubernetesを構成するCNCF(Container Native Computing Foundation)のプロジェクトは、2021年の報告時点で120を超えている。
◎CNCF 2021 Annual Report
◎CNCFが年次報告書「CNCF Annual Report 2021」を公開
図表1のように公開されているCNCF Landscape (Cloud Native Landscape, Serverless Landscape)を参照しても、その範囲・種類や関連団体・企業の膨大さ、その理解の大変さは容易に想像できる。
オンプレミス環境でのコンテナ運用
認識しておくべき課題とOpenShiftのメリット・デメリット
オンプレミス環境、もしくはパブリッククラウドとオンプレミスを混合して運用するハイブリッドクラウド環境でコンテナを稼働させるには、利用上の課題を認識しておく必要がある。
パブリッククラウドで稼働するコンテナ環境はマネージド・サービスで提供されるため、一般的に運用上の課題に気付きにくいが、オンプレミスでコンテナを稼働させる場合には、以下のようにインフラの提供と維持・管理が課題となる。
・障害/問題発生時の対応策
・モニタリング/パフォーマンス管理
・セキュリティ対策
・オンプレミスでのサービス・プラットフォームおよびインフラの維持・管理
・データ管理/統合
パブリッククラウドでも実は上記の課題を認識し、いろいろと対応策を考えておかねばならない。しかしマネージド・サービスとして機能をいつでも適用できる状態にあるため、実際には適用していなくても、サービスが存在するという事実に満足してしまうことがある。
典型的な例として、モニタリングの実施やパフォーマンス管理などが挙げられる。これらは当然ながらパブリッククラウドでも実施すべき項目だが、「ハードウェア・インフラは、パブリッククラウド側で提供されるので心配ない」という心理的なイメージや安心感があり、ユーザーはあまり関心を持たない傾向にある。
マネージド・サービスとして種々の機能が提供されないオンプレミス環境で、これらの課題に直接対応できる、あるいは大きな助けとなるのが、OpenShiftである。
OpenShift はエンタープライズ向けの Kubernetes プラットフォームであり、デプロイ先がどこであっても、一貫した環境を提供できる。
OpenShiftはユーザーの利便性を考慮し、Kubernetesを中心に各種コンポーネントをパッケージングしている。そのためOpenShiftを採用することで、運用担当者はテスト済みの各種コンポーネントのレベルセットを入手でき、「どのコンポーネントの、どのレベルを選択すべきか」などと悩む必要はない。またRed Hat社のサポートを得られるので、自力でトラブルに対処する苦労から解放される。
このようにOpenShiftは、コンテナ環境の構築・運用に大変便利なパッケージである。ただし残念ながら、ストレージに関する機能はまだ十分とは言えない。たとえば統合的なバックアップ機能は提供されないし、すでに社内各所に分散しているデータをコンテナ環境に取り込む手法も、従来からの方法を踏襲しているに過ぎない。
IBM Spectrum Fusion
OpenShiftをベースに多彩なストレージ・ニーズに対応
IBM Spectrum FusionはOpenShiftをベースに多彩なストレージのニーズに対応し、安心・安全な、かつ運用も容易なインフラを提供する製品である。
ストレージ・サービス自体をコンテナ内に配置して、アプリケーションなどとセットで稼働させるコンテナ・ネイティブのアプローチをコンセプトとしている。これにより、アプリケーションと整合性の取れたストレージの運用や自動化、高可用性を実現できる。
たとえばOpenShiftだけではサポートされないコンテナ環境のバックアップ機能(図表2)や、コンテナ・ネイティブのストレージ(図表3)をパッケージにして提供するため、データ管理/統合をシームレスに実行できる。これにより、OpenShiftだけでは解決できていなかった課題をカバーしている。
またIBM Spectrum Fusionでは、インフラ全体の容易な維持・管理も実現する(図表4)。
このIBM Spectrum Fusionには、「IBM Spectrum Fusion HCI」と「IBM Spectrum Fusion SDS」という2つの製品が提供されている。
IBM Spectrum Fusion HCIはコンテナ専用のインフラとして、ハードウェアを含めて丸ごと利用できるようにハイパーコンバージド・インフラストラクチャ(HCI)の形で提供されている(図表5、図表6)。
またIBM Spectrum Fusion SDSは、専用ハードウェアを必要としないSDS製品であり、2022年3月に発表された。
IBM Spectrum Fusion HCIでは、専用ハードウェアを利用したパッケージである点を活かし、オンプレミスでのAI分析をより高速に実行するGPUサーバーや、ハイブリッドクラウド環境でデータ連携を可能とする AFM (Active File Management)機能(図表7)を提供するサーバーをオプションで追加できる。
加えて、分散クラウドサービスである「IBM Cloud Satellite」と連携させることで、IBM Cloud の延長線上の存在としてIBM Spectrum Fusion HCIを利用できる(図表8)。
IBM Cloud Satelliteを使うと、ユーザーはIBM Cloud にアクセスした状態でIBM Spectrum Fusion HCI の資源を利用でき、コンテナ・アプリをIBM Spectrum Fusion HCIで稼働させたり、IBM Spectrum Fusion HCIにあるデータをIBM Cloudのコンテナ・サービスを使って処理させたりできる。
IBM Spectrum Fusionは今後、オンプレミスでのマネージド・サービスを提供するプラットフォームとして、さまざまなサービスを随時追加し、発展し続けるインフラとなっている。
専用ハードウェアとソフトウェア群を組み合わせ、利用・管理が最も容易なIBM Spectrum Fusion HCIを筆者は推奨したいが、導入済みや希望するIAサーバーを利用したい場合には、SDS版であるIBM Spectrum Fusion SDSも有効である。
IBM Spectrum Fusionは今後もさまざまな拡張を予定している。早期のDX推進に向け、ぜひ活用を検討してほしい。
参考
◎Kubernetesとは何か?
https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/
◎Kubernetes
https://www.ibm.com/jp-ja/cloud/learn/kubernetes
◎OpenShift がどのようにしてコンテナのセキュリティを可能にするか
https://www.redhat.com/ja/technologies/cloud-computing/openshift/security
◎IBM Spectrum Fusion(日本語サイト)
https://www.ibm.com/jp-ja/products/spectrum-fusion
https://mediacenter.ibm.com/media/t/1_umn36blm
著者
佐藤 龍一氏
日本アイ・ビー・エム株式会社
テクノロジー事業本部
ストレージ・テクニカル・セールス第一
ICP アドバイザリー IT アーキテクト
1990年、日本IBM入社。 メインフレーム製品テストおよび技術支援を担当した後、2000年よりストレージ製品の技術サポートを経て、2004年よりストレージ製品のプリセールスに従事。 さまざまな業種・地域のお客様を担当しているが、近年はメガバンク・グループのお客様を中心に、IBMストレージをよりよくお使いいただくべく、共創を目指して活動中。
[i Magazine・IS magazine]