コンテナストレージ 応用編２ －3つの原則と4つの使い方－

[Yoji_Inoue]

前回はコンテナを継続的に運用するには「データが消えない」、「アクセスが途絶えない」、「内容が常に一致する」ステートフルなストレージが必要であること、さらにコンテナの実運用に欠かせないオーケストレーションツールの利用方法について解説しました。今回はコンテナユーザーが気を付けるべき３原則と4つの利用シナリオについて解説します。

コンテナストレージ３原則 

海外ではよく使われるプリンシプル（Principle：原則）、日本の風習では玉虫色が良いとされることもあり、あまり意識されないことも多いようですが、ことITの世界ではこの原則を決めることは極めて重要です。これが明確でないと設計指針からサービスレベルの定義まで、常に場当たり的な対応をしてしまうことになります。

ではコンテナとデータを扱ううえでの原則は何になるのでしょうか？　ここでは私が重要と考える3つの要素を挙げてみたいと思います。

 原則１．コンテナとデータストアは分離する
　コンテナの良さは軽くて早い、アプリがすぐに起動できて移動も簡単、壊れてもまた起動すればよいところですが、一方データは重くて移動にも時間がかかります。当然壊れたら修復はできません。このような特性の違うものを1つにまとめるのはそれぞれの良いところを打ち消すだけでなく高いリスクも伴います。

原則２．コンテナの拡張に対応できるデータストアを選択する
　コンテナの特徴である、デプロイや移動、削除が簡単にできる特性を最大限生かすには、データストアにも高い拡張性、縮退性、さらにコンテナが急速に増えても継続して期待された性能（ユーザーエクスペリエンス）が提供できる柔軟性が求められます。基本アーキテクチャーとしてこのような特性を考慮した設計のストレージを利用することが重要です。

原則３．コンテナデータの回復ができる環境を整える
　コンテナ自体は簡単にデプロイしたり削除したりできますが、その簡単さゆえにオペミスで本来消してはいけない大事なコンテナまで削除するリスクもあります。同時にデータも削除されてしまうので、消えても良いデータ以外は別のデータストアに「きちんと」保存しておくことが重要です。この「きちんと」というのはデータ保護の仕組みが組み込まれていることで、スナップショット、バックアップ、さらに災害対策（DR）やサイバー攻撃に対しても考慮されている必要があります。結構ハードルが高そうですが、エンタープライズの世界ではすでにこのような機能が組み込まれたものが存在します。それらの中でコンテナ環境で使える仕組み（プラグイン）を提供してものを選択するのが一番安心でしょう。

 代表的な４つの利用方法

 コンテナのステートフルストレージの利用方法としてよく挙げられるのは以下の4つです。それぞれについて簡単に解説してみましょう。

1.　Lift & Shift（リフト＆シフト）

これは良くMTA（Modernize Traditional Applications）、いわゆるレガシーアプリ環境の刷新の話に関連して語られることが多いのですが、コンテナを使うことでレガシーアプリをクラウドプラットフォームに簡単に移行できるということです。特にコンテナ化の事例として紹介されるのが、比較的シンプルなLAMPスタックアプリ（オープンソースでよく利用されるLinux（OS）、Apache（Webサーバー）、MySQL（データベース）、Perl、PHP、Python（プログラム言語）の頭文字４文字）やERP（基幹業務システム）等です。一方アプリで利用されているデータベースがある場合、つまり「ステートフルなアプリケーションのコンテナ化」に関しては、他のアプリケーションのインスタンスとの同期、データの整合性が損なわれないよう注意が必要です。

2.　DevOps CI/CD パイプライン

DevOpsはアジャイル開発に関連して生まれた開発手法で、開発側（Development）と運用側（Operation）が連携して開発・テスト・運用を行うことで、システム開発をより柔軟に、短期間で実現する手法です。さらにDevOpsの効果を最大化するために開発・テスト・運用を継続的に行えるように自動化する手法がCI/CD（継続的インテグレーションおよび継続的デリバリー）です。このCI/CDによりデプロイの回数を劇的に増やすことができ、さらにヒューマンエラーも防ぐことができます。そしてこの開発手法と非常に相性が良いのが、動作環境（ITハードウェアやプラットフォーム等）が変わってもすぐにアプリケーションが動かせるコンテナ技術です。ただし、ここでもいくつか注意することがあります。

一般的なマルチティアアプリケーションではデータの質が重要になります。例えばCI/CDプロセスの中で運用側のデータをテスト側にコピーする場合ですが、運用側の性能低下を招く危険性や、逆にテスト環境の性能が十分に出ないということもあり得ます。ではテスト環境のデータを実データではなくテスト用に作成したものを使えばよいかというとそれにも課題があります。テストデータの量や質が実データとかけ離れていると、実際の運用時に発覚する問題点が洗い出せないことがあり得るからです。 実運用で問題を起こさないためにもテストにはより実運用に近いデータを使用する必要があるのです。また近年のCI/CDシステムでは一日に数サイクルのテストとデプロイを繰り返すことも珍しくありません。つまりCI/CDサイクルをさらに高速に行う必要があります。すでに解説していますように、コンテナ内にデータを置く場合はコンテナの移動、削除によりデータも消失します。といってその都度データをコンテナにコピーしていてはせっかくのコンテナによるCI/CDパイプライン迅速化のメリットが損なわれかねません。そのため実運用やテストデータでさえも外部のステートフルストレージ（永続ストレージ）に保存する必要があります。そうすることで開発・テスト・運用プロセス間でコンテナの継続的移動を繰り返しても、一貫して同じデータを使うことができ、ソフトウェアの品質を向上し、開発・変更プロセスの短縮化も実現できます。

3.　IT オペレーション

通常のITオペレーションでもコンテナが使われることも増えてきています。有名なのは、ELK スタック（Elasticserch, Logstash, Kibanaで構成されるログ抽出・分析・可視化ツールのセット）や前述した LAMPスタックアプリ、WordPress、MongoDB、Node.jsなどです。 また最近ではLinuxだけでなくWindowsやMAC OSのサポートが始まったり、パブリッククラウドでもサポートされるようになったりと、一般企業のIT環境でも十分使える時代になってきました。一方、大量のデータを処理したり複数のコンテナ化されたアプリからアクセスする場合は注意が必要です。例えばELK スタックのようなログ分析ツールなどはデータ処理の性能が求められるため、それなりのストレージ性能と拡張性が求められます。またSMACK（Spark, Mesos, Akka, Cassandra, Kafka）スタックのようなビッグデータ分析基盤には大容量、高拡張性、高性能なだけでなく、ビッグデータを保持するためのステートフルなストレージが必要になります。

4.　Container-as-a-Service (CaaS)

IaaSとPaaSの間に位置するCaaSは開発用セルフサービスとして使われることが多いです。例えばHPEのソフトウェア開発基盤はこのコンテナセルフサービスでできています。このプラットフォームを利用することで、エンタープライズクラスの信頼性・セキュリティ・性能を備えつつ、開発者が自ら開発に必要な機能をカラログから選択し、自分自身の開発環境を構築することができます。一方IT管理者は個々のリクエストに対応することなく、テンプレートの作成や全体の監視だけをすればよいのです。以下の図でそのプロセスを簡単に説明してみましょう。 

 1. 管理者はベースとなるコンテナイメージを作成し、共通のリポジトリ（DTR：Docker Trusted Repositry）に保存
2. 開発者は必要なコンテナイメージをDTRから読み出して開発環境を自ら構築
3. CI/CDツールで開発を繰り返す
4. テストができるところまで完成したらそのコンテナをTest/QAフェーズに移行
5. テストプロセスでバグが見つかったらそのコードを開発者に返す
6. テストが完了したコンテナはProduction（本番環境）に移行
7. 新しい機能の開発は開発者によって継続的に行われる

このように早くて軽くて移動が簡単なコンテナとソフトウェア開発のセルフサービス化は非常に相性が良く、開発スピードが飛躍的に上がるだけでなく、効率化と同時にヒューマンエラーの低減が実現できるため、企業の競争力も増していくのです。

関連記事

コンテナストレージ　応用編（１）