エンタープライズでのコンテナ活用はストレージがポイント

ビジネス環境が急速に移り変わる昨今、アプリケーションのリリースを加速する「コンテナ技術」への注目度が高まっています。The Orange Ring – Tech セミナー第 10 回『Pure Service Orchestrator のご紹介』の内容を抜粋してご紹介します。

溝口修

4月 20, 2020

34分

Pure Service Orchestrator The Orange Ring

はじめに

ピュア・ストレージ・ジャパンは、お客様のデジタル変革を支援する取り組みの一環として、技術セミナー「The Orange Ring – Tech」を開催しています。

急速にビジネス環境が移り変わる昨今では、アプリケーションのリリースを加速する「コンテナ技術」への注目度が高まっています。2019 年 11 月 15 日開催の The Orange Ring – Tech セミナー第 10 回では、『Pure Service Orchestrator のご紹介』と題し、わたくし溝口がコンテナ活用におけるストレージの重要性やピュア・ストレージのソリューションについて解説しました。本稿では、その内容を抜粋してご紹介します。

エンタープライズでも選ばれるコンテナ技術

コンテナは、現在最も注目されている開発技術の 1 つです。2013 年に Docker、2014 年に Kubernetes の最初のバージョンが登場し、多くのデベロッパーに支持されてきました。現在では、7 割を超える企業がコンテナを利用・評価していたり、Kubernetes エンジニアへの投資欲が高まっていたりと、さまざまな調査からコンテナの利用が広まっていることがわかります。すでに数多くのアプリケーションやサービスで Kubernetes が利用されており、その関連製品としてエンジン、実行環境、オーケストレーターが登場しています。Google、Microsoft Azure、Amazon Web Services（AWS）といったパブリック・クラウド・サービスでも、Kubernetes 向けのコンテナ・マネージド・サービスを展開しています。

人気のある各種サービスは、極めて迅速かつ頻繁にソフトウェアを展開し、ビジネス優位性を確保しようと試みています。少し古い記事（2015 年 9 月 25 日付け）ですが、こちらをもとにいくつかの例をあげてみましょう。

Amazon は、11. 7 秒ごとにコードをデプロイしている
Facebook は、隔週での製品リリースを目標に設定している
Netflix は、1 日に複数回のコード・リリースに変更した
参照：10 companies killing it at DevOps – TechBeacon

このような近年の厳しい競争下では、迅速なリリース・サイクルが必要とされています。旧来の方式では、要件定義の際に決めたシステムが、提供時には時代遅れになりかねません。効率よく小さな単位の機能をすばやくリリースして、フィードバックを得ながら改善していくことが重要となります。そこで、短期間のリリース・サイクルで個別の機能を開発し、それらをつなぎあわせて 1 つのサービスとして提供する「マイクロ・サービス」の概念が必要となります。

マイクロ・サービス

コンテナは、OS 上で隔離された実行環境として稼働します。サーバー仮想化とは異なり、OS の起動・停止プロセスが必要ないため、軽快に動作します。OS が含まれないためリソース効率がよく、1 つのホストで多くのコンテナを稼働させることが可能です。クラウドでもオンプレミスでも実行環境に依存しません。

コンテナとサーバー仮想化の違い

コンテナをエンタープライズ環境で活用する際には、いくつかの課題を解決しなければなりません。

仮想マシンのように、コンテナに障害が発生したときには復旧してほしい
アクセス集中の際にはオートスケールしてほしい
最適なホストにコンテナをデプロイしてほしい
複数のホストにコンテナをデプロイしたい
負荷分散の機能がほしい

こうした課題を解決する技術が、コンテナ・オーケストレーターです。代表格である Kubernetes は、コンテナ化されたアプリケーションのデプロイやスケーリング、管理を自動化する機能などを実装したオープンソース・システムです。

コンテナの可用性を高める機能や負荷分散機能を持ち、ネットワークとストレージの機能も提供します。1 つないしは複数のコンテナをポッドという単位で管理するのが特徴です。エンタープライズ環境でも活用できるように、Kubernetes が Docker 等のエンジンに足りない部分を補足しているのです。

コンテナの永続性をサポートする Pure Service Orchestrator

コンテナ化されたワークロードは一般的に短命なものと捉えられてきましたが、昨今では永続性が重視されるアプリケーションも増えています。そこでポイントとなるのが、ストレージです。実際、Kubernetes でも永続ストレージをサポートし、長命なアプリケーションでもコンテナを活用できるようになっています。

しかし数年前までは、コンテナからローカル・ストレージへの保存しか行うことができませんでした。つまり、コンテナ・インスタンスを削除すると保存されているデータも削除されたり、コンテナを別のサーバーにデプロイするとデータが見えなくなったりしてしまうのです。

一方、Docker では 2016 年ごろから外部ストレージにデータを保持するために、Docker Volume Plugin などの仕組みを提供しており、永続化／永続ストレージの検討が重視されるようになりました。Docker で最も多く利用されているコンテナ・アプリトップ 10 のうち、7 つが永続ストレージを使用しているという調査結果もあります。

Kubernetes 1.9では、Kubernetes からコンテナ用ストレージを制御するための API「Container Storage Interface」（以下、CSI）がアルファ版として実装されました。

CSI は、Kubernetes、Mesos、Docker、Clound Foundry が、特定のコンテナ・オーケストレーションに依存することなく、コンテナで外部ストレージを利用できるように策定した仕様です。業界標準の “CSI” への対応により、ストレージ・ベンダーがプラグインを開発すれば、さまざまなコンテナ・オーケストレーション・システムで利用できることが実現可能になります。

ピュア・ストレージの Pure Service Orchestrator（PSO）は、FlashArray と FlashBlade のストレージ群を統合し、CSI（v1.2 準拠 – 2020 年 4 月現在）を通じて永続ストレージを提供するソフトウェアであり、上記のような課題を解決する機能を提供します。

Pure Service Orchestrator

PSO の 3 つの特長として、スマート・プロビジョニング、柔軟なスケーリング、自動修復をご紹介します。

1. スマート・プロビジョニング

スマート・プロビジョニングは、コンテナからブロック・ストレージ、あるいはファイル・ストレージを選択してボリューム・サイズを指定するだけで、複数のアレイの負荷状況を考慮して、最適なストレージを割り当てる機能です。

スマート・プロビジョニング

2. 柔軟なスケーリング

ストレージを容易にスケーリングする機能も提供しています。PSO がない場合、コンテナごとにストレージを割り当てる必要があります。PSO があれば、Kubernetes の設定ファイルにアレイの情報を追加するだけで、コンテナを起動するときに自動的にストレージが割り当てられ、複数のアレイにまたがって自動的にスケールできるようになります。新しいアレイを簡単に追加して容量などの増強ができるため、スモール・スタートが容易になるという利点もあります。

ストレージを容易にスケーリング

3. 自動修復

自動修復機能は、Kubernetes のポッドがなんらかの理由でノードを移動したときに、自動的に当該のノード側にボリュームを割り当て直してデータ・アクセスの整合性を保つものです。エンタープライズ・レベルの信頼性を確保できる重要な機能の 1 つです。

自動修復

ピュア・ストレージはコンテナ／クラウド活用を支援

ピュア・ストレージは、コンテナ環境に向けた機能の強化を図ります。

その 1 つが、FlashArray の技術をパブリック・クラウドで利用できる Cloud Block Store とのレプリケーション機能です。オンプレミス・クラウドのハイブリッドな Dev/Ops 環境を実現し、管理ツール Pure1 から統合的に管理できるようになります。

Cloud Block Store for AWS

セミナー当日のデモンストレーションでは、オンプレミスのコンテナ化されたデータベースを、たった 4 つのコマンドを実行するだけで AWS へ展開・実行する様子をご紹介しました。数百メガのボリューム（Thick Provisioning）を 5 つもコピー（レプリケーション）したにも関わらず、重複排除・圧縮技術が十分に働き、クラウド側の実容量は 9 MB 弱で済みました。コンテナ環境においても、ピュア・ストレージの技術が効果を発揮し、ストレージ・コストを抑えます。

ピュア・ストレージでは、今後もクラウドへの対応を強化し、AWS や Microsoft Azure、国内ホスティング・サービスなどをサポートして迅速に同期し、クラウドでもオンプレミスでもシームレスにデータを活用できるポータブル・アーキテクチャに注力していきます。

Pure Service Orchestrator の最新情報

ピュア・ストレージは、本セミナーが行われた 2019 年 11 月以降も Google Anthos Support といったコンテナ環境においても、積極的な取り組みを行っています。

また、4 月 30 日には、「Pure Service Orchestrator v5.2.0」がリリースされました。「v5.1.0」とあわせて、このリリースには、以下の 5 つの重要な新機能が含まれています。

FlashArray の Raw ブロックに対して、accessModes: Read-Write-Many（RWX）のサポート
ブロック・ストレージの RWX モードは、クラウド・ネイティブ・アプリケーションでの用途は限定的かもしれませんが、これによりホストをまたがるポッドから同じボリュームをマウント可能になります。ただし、ブロック・ストレージですので、複数のポッドから書き込みを行う場合はデータの整合性を保つため、ポッド内でクラスタ化されたアクセスが必要になります（例：Oracle ASM）。
Storage Topology のサポート
Storage Topology は、複数アレイがある中でアプリケーションの永続ストレージが作成されるアレイを制御する機能を提供します。これにより、クラウド・ネイティブ・アプリケーションが、アプリケーションに地理的に近いアレイを指定したり、開発・本番向けのアレイといった指定が可能になります。Storage Topology は、以前の Flex Driver で存在していた「label」機能の CSI 版に相当し、ストレージ・プール内のアレイをより細かくグルーピングすることが可能になります。
Soft Import 機能の追加
Soft Import 機能により、Kubernetes の制御下で、既存の FlashArray ボリューム、または、FlashBlade の共有をアタッチすることができるようになります。アタッチするにあたり、ボリュームまたは共有の名前を変更する必要はありません。
ボリューム拡張（Volume Expansion）
Volume Expansion では、FlashArray のボリューム、および FlashBlade 共有をオンラインでサイズ変更（増加のみ）が可能となります。ただし、FlashArray のボリューム・サイズ拡張は、ボリュームをマウントするポッドを再起動する必要があります（CSI 標準要件）。

詳細につきましては、下記のドキュメントをご参照ください。