1．コンテナの利用状況と課題
近年のシステム開発においては、ビジネス変化の速さに対応できることが重要視されており、アジリティ向上の手段として、コンテナ技術が活用されるケースが増えています。IPAが公開しているDX白書2021（※）によると、海外では多くの企業がコンテナ技術を利用しています。しかし、日本国内ではコンテナ利用割合は低く、コンテナ技術は普及段階にあります。
そのため、コンテナを初めて利用する方が多く、コンテナを用いたアプリケーション設計方法が分からないという声が挙がっています。以下に具体例を紹介します。
- コンテナが停止するとコンテナ内のログファイルが消えてしまい、ログを永続化する方法がわからない
- コンテナのメモリ上でセッションを保持していたが、オートスケールでコンテナが停止した際、セッション情報も消えてしまった
- コンテナが停止するたびに環境依存値が消えてしまい、何度も書き直すことが面倒である
上記の事例は、コンテナの特徴を考慮した設計がされていない場合に発生します。コンテナの特徴を考慮した良い設計ができていれば、コンテナの様々なメリットを享受できますが、考慮した設計がされていなければ、多くの問題が発生する恐れがあります。このように、コンテナ上で動作するアプリケーションの設計においては、コンテナの特性を十分に理解することが重要です。
2．アプリケーションの設計ポイント
コンテナ上で動作するアプリケーションが考慮すべき設計ポイントについて、ファイル永続化、ロギング、環境依存値管理、セッション管理の4つを紹介します。
2.1 ファイル永続化
コンテナを起動すると、コンテナ上にファイルシステムが割り当てられます。コンテナ上に割り当てられたファイルシステムは揮発性であり、ファイルシステムに格納されたデータはコンテナ停止時に削除されてしまいます。そのため、データの永続化を行いたい場合は、別途ストレージを用意する必要があります。
ファイルの永続化を行う方式は、利用するストレージの種類によって、以下のように大きく二つに分類できます。
・NFSサーバ
図1で示すように、データの永続化を行うNFSサーバを別途構築し、複数のコンテナのボリュームとしてマウントする方式です。この方式では、アプリケーションがファイルシステムに入出力する従来通りの方法で、ファイルが永続化されるといったメリットがあります。しかし、コンテナとシステム基盤が密結合であるため、NFSサーバの障害時にコンテナを起動することができないといったデメリットもあります。
図1：NFSサーバを利用する方式
・オブジェクトストレージ
図2で示すように、オブジェクトストレージを別途構築し、複数のコンテナからオブジェクトストレージにAPI経由でアクセスする方式です。コンテナ内でのファイル出力後にPUTを行い、API経由でファイルを外部のオブジェクトストレージに格納することで、ファイルの永続化を実現します。この方式では、コンテナとオブジェクトストレージを疎結合に保つことができるため、オブジェクトストレージの障害時においても、コンテナを起動できるといったメリットがあります。しかし、APIを呼び出す処理をアプリケーション側で実装しなければならないといったデメリットもあります。
図2：オブジェクトストレージを利用する方式
2.2 ロギング
従来のアプリケーションでは、ログファイルを動作サーバのローカルディスクに出力する方式が一般的です。しかし、コンテナ上で動作するアプリケーションの場合、コンテナ内のローカルディスク領域が揮発性であるため、従来の方式ではログファイルを永続化できません。よって、コンテナでは、ログの永続化を考慮した設計が必要となります。
ログの永続化については、ログ収集基盤で管理する方式が一般的です。ログ収集基盤とは、ログの収集・保管・可視化の一連の処理を行う仕組みを指します。図3で示すように、コンテナ上のアプリケーションがログを標準出力に出力し、別途構築したログ収集基盤で収集・保管・可視化を行うことで、ログを永続化することが可能です。
図3：ログ収集基盤を用いたログ永続化
2.3 環境依存値管理
コンテナのメリットとして、一度ビルドしたコンテナイメージはコンテナエンジンさえあれば、どの環境でも同じように動作するという可搬性が挙げられます。コンテナが持つ高い可搬性により、開発環境で試験済のコンテナイメージをそのまま商用環境で動作させることで、環境差異に起因するシステム障害の発生リスクや、リリースなどの運用コストを低減できます。
しかし、コンテナイメージ内に環境依存値を含むアプリケーション資材がパッケージングされている場合、コンテナ実行環境が異なると、コンテナイメージをそのまま利用することができません。仮想マシン等のコンテナ上で動作しないアプリケーションでは、環境依存値は設定ファイルで外部管理し、動作環境に応じて設定ファイルを差し替えることで環境差異を吸収する方式を取ることがあります。この方式をコンテナ上で動作するアプリケーションで採用すると、環境ごとにイメージビルドが発生し、可搬性が低下します。
この問題の回避するためには、図4で示すように、コンテナオーケストレーションツールを利用し、環境変数経由で環境依存値を注入する必要があります。コンテナオーケストレーションツールはコンテナの起動時に環境変数を設定できるため、環境変数を予めコンテナオーケストレーションツールに設定しておくことで、コンテナイメージから環境依存値を排除することが可能となります。
図4：コンテナオーケストレーションツールを用いた環境依存値管理
2.4 セッション管理
コンテナオーケストレーションツールの特徴の一つにオートスケール機能があります。リソース高騰時には自動で追加のコンテナを起動し（スケールアウト）、リソース使用量が通常に戻ると、自動でコンテナを停止します（スケールイン）。スケールインを行う場合、コンテナのメモリ上で保持している情報は削除されてしまいます。
一般的なWebアプリケーションでは、複数のリクエストに跨る一連の処理について、処理の状態をセッションとして管理し、Webアプリケーションのメモリ上に保持する方式が一般的です。前述の通り、スケールインを行う場合、コンテナはオーケストレーションツールによって自動的に停止します。コンテナが停止すると、図5で示すように、メモリ上のセッションが同時に削除されてしまい、エンドユーザの一連の処理が中断される問題が発生します。
この問題を回避するため、コンテナ上で動作するアプリケーションでは、図5で示すように、セッションをKVS（Key Value Store）のような軽量なデータストアを用いて外部管理することが望ましいです。
図5：コンテナ上で動作するアプリケーションのセッション管理
3．まとめ
日本国内でのコンテナ利用割合はまだまだ低く、今後普及するためには、多くのエンジニアが開発の基本知識としてコンテナに関するノウハウを身につけておく必要があります。そこで本記事では、コンテナ技術の普及を目的として、コンテナを利用する際に考慮すべき4つのポイントを紹介しました。本記事を参考にコンテナを積極的に活用し、ビジネス変化の速さに対応していきましょう。
