text：竹田 千恵
日本アイ・ビー・エム株式会社
テクノロジー事業本部
ハイブリッドクラウド ＆ AIシステムズセンター
部長
DX時代に加速する
マイクロサービス指向とクラウド・ネイティブ化
企業が競合優位性を保ち、新しい付加価値のあるサービスを提供し続けるためには、お客様のニーズを予測し、自身が不断に変化し続けることが大事である。めまぐるしく変わる環境やビジネス要求に対して、アプリケーションを含むシステム・インフラも変化に追随して柔軟に変更（継続的改善）できる必要がある。
しかし、これまでのシステム・アーキテクチャは目的に対してモノリシック（一枚岩）にデザインされるため、部分的な変更や改変が難しい。そこで、DXによる急速なビジネス・モデルの変革に対応するために、システムの機能(サービス)を独立させるマイクロサービス指向が注目を集めている（図表1）。これは、従来型の手法とは異なり、モジュール単位でリリース可能なものを提供する方法だ。
これにより各モジュールは、API (Application Programming Interface) 経由で組み合わされることになる。互いの依存関係は少なくなり、モジュールを個別に開発したり、改変しやすくなる。2015年に設立されたCloud Native Computing Foundation (CNCF) では、マイクロサービス指向のクラウド・ネイティブ・アプリケーションや、OPEN CONTAINER INITIATIVEに基づくコンテナ実装を推進している。現在、約500の企業が参加しており、IBMとRed HatはPlatinum Membersとしてこの活動を支援している。［*1］［*2］
変化への迅速な対応へ向け
高まるコンテナの必要性
目的先行でウォーターフォール型にシステムを組み上げていく方法とは異なり、クラウド・ネイティブ・アプリケーションは目的さえも途中で新しく変わっていく。当然ながらシステムも、その都度改変が求められる。そのため、このアプリケーションを支えるインフラの要件を事前に定義することが難しい。変化した要件に応じて、その時点で使い勝手のよいものを使いたいという発想が生まれてくる。
そこで注目されるようになったのが、コンテナという考え方だ。コンテナはアプリケーションに必要なものをパッケージングする技術であり、アプリケーション部分とOS部分を切り離すことにより機能要件と非機能要件を分離する。アプリケーション開発者はアプリケーションの開発に専念できるようになる。
具体的には図表3に示すように、各々の仮想マシン（VM）が個別に所有していたOSとカーネル部分をすべて共有する。その結果、アプリケーションの作り替えが容易になり、こちらの環境からあちらの環境への移動が簡単になるのだ。可搬性が高まり、OSも共有しているため、各々のコンテナで必要なリソースも軽くなる。これにより変更しやすくなるメリットも享受できる。
コンテナが別環境に移動しても
何もしなければデータは引き継がれない
コンテナ環境を構築する場合、アプリケーション開発に注意がいきがちである。インフラの検討はもとより、データを保管するストレージの検討はさらに後回しになることがほとんどである。コンテナ環境は基本的に揮発性であるため、壊れたら別のノードで作り直すという発想が根幹にある。
この手軽さはメリットではあるものの、何もしないと実はデータは引き継がれない。コンテナが別の環境に移動したらアプリケーションで使用するデータも引き継ぎたいが、そのニーズに応えるには、図表4に示す「永続ストレージ」と呼ばれる外部ストレージへデータを保管する必要がある。
永続ストレージをコンテナ環境から使うには、CSI（Container Storage Interface）ドライバーを利用すると、動的なプロビジョニングやSnapshot、Cloning、拡張などが実施できて便利である。IBMが現在提供中のストレージはすべてCSIに対応しているので、ブロック、ファイル、オブジェクト・ストレージなど用途に合わせて選択いただくとよいだろう（図表5）。
このうち「IBM Storage Suite for IBM Cloud Packs」は、4つのIBM製品（ファイルシステムを提供する「IBM Spectrum Scale」、ブロック・ストレージを提供する「IBM Spectrum Virtualize for Public Cloud」、オブジェクト・ストレージを提供する「IBM Cloud Object Storage」、メタデータ管理を提供する「IBM Spectrum Discover」）と2つのRed Hat製品（「OpenShift Container Storage」「Ceph Storage」）が利用でき、用途に応じて自由に組み合わせ可能なソフトウェア・バンドル・パッケージである。複数製品を組み合わせて同時に使えるのに加えて、パッケージ内のストレージ製品であれば追加費用なしで変更できるので、新たなストレージ要件が出てきた場合でも柔軟に対応できて便利である。また、Red Hat製品を含めてサポート窓口はIBMで統一しているため、安心してご利用いただける。［*3］
次に、IBMストレージ製品の種別ごとの、x86 64系サーバー、IBM Power Systems、IBM Z環境におけるアクセス・モードのサポート状況を図表6にまとめた。
ブロック・ストレージは、CSI Driver経由でボリュームを単一のノードで読み取り／書き込みしてマウントできるReadWriteOnce（RWO）モードを、ファイルシステムはRWOモードに加えてボリュームを多数のノードで読み取り／書き込みしてマウントできるReadWriteMany（RWX）モードをサポートしている。オブジェクト・ストレージはREST API経由でアクセス可能だ。
このように永続ストレージと一言で言っても、ストレージの種類やアクセス・モードは多種多様であるため、アプリケーションの要件に応じて柔軟な選択肢を用意しておくことが大事だと言える。［*4］［*5］
永続ストレージを体感できる
無償プログラム
今後マイクロサービスやクラウド・ネイティブ・アプリケーションを実装する際には、コンテナ環境におけるストレージにも目を向けていただくことをお勧めする。IBMでは、図表6のソフトウェア定義型ストレージを無償で試せるプログラムもご用意している。この分野の成長はめざましく機能強化も続いているので、ぜひ一度IBMの永続ストレージをコンテナ環境で体感していただき、永続ストレージ選定のお役に立てたらうれしく思う。
◎参考リンク
［*1］CNCF Platinum Members https://www.cncf.io/about/members/
［*2］ クラウド・ネイティブ という考え方 -これからのI T基礎知識
https://www.IBM.com/blogs/think/jp-ja/cloud-native-concept-01/
［*3］意外と知られていないコンテナ環境でのストレージの役割
https://www.IBM.com/blogs/systems/jp-ja/the-importance-of-storage-solutions-in-container-environment/
［*4］ IBM block storage CSI driver – Compatibility and requirements
https://www.ibm.com/docs/en/blockstg-csi-driver/1.5.0?topic=notes-compatibility-requirements
［*5］IBM Spectrum Scale Container Storage Interface Driver
https://www.ibm.com/docs/en/spectrum-scale-csi?topic=220-planning
◎著者 竹田千恵氏が出演する「データ基盤を考えるストレージ座談会」がオンデマンドで配信中です。アクセスはこちら。
著者
竹田 千恵氏
日本アイ・ビー・エム株式会社
テクノロジー事業本部. ハイブリッドクラウド ＆ AI システムズセンター 部長
［i Magazine・IS magazine］
