コンテナ型仮想環境における運用管理

W 社は，オンラインゲームのアプリケーションソフトウェア（以下，ゲームアプリという）を企画，開発及び運用している。W 社の開発部は，開発環境と試験環境を利用して，ゲームアプリの開発と保守を行っている。W 社の運用部は，開発されたゲームアプリを稼働環境で運用し，W サービスとしてスマートデバイスからインターネットを経由してゲームを行う利用者に提供している。開発環境の管理は開発部が，試験環境及び稼働環境の管理は運用部が担当している。W サービスの提供時間帯は，ゲームアプリ改修に必要な計画停止時間を除いた 24 時間 365 日となっている。

ゲームアプリの競争が激しく機能追加のための改修が多いので，新たな版のゲームアプリを週 1 回の頻度で稼働環境にデプロイする必要がある。開発部と運用部では，開発に掛かる期間を短縮し，リリース頻度を高めているが，ゲームアプリの開発と運用には表 1 に示す課題がある。

開発部の Y 氏は，アプリケーションが稼働する環境を，高速かつ簡単に生成できるコンテナ技術を導入することによって，表 1 の項番 1 や項番 2 の課題を解決できないかと考えた。

コンテナ技術とは，アプリケーションプログラム（以下，AP という），ミドルウェア（以下，MW という）などを一つにまとめたもの（コンテナ）をホスト OS のコンテナ管理ソフトウェア上で仮想環境として動作させる技術のことで，次のような特徴がある。

• 開発者が自らに必要な環境を専有して開発できる。
• サーバのリソースを有効利用でき，環境の準備，起動，廃棄などを迅速に行うことができる。
• 別の環境への移行が簡単にできる。

コンテナ型仮想環境とハイパーバイザー型仮想環境の構成例を図 1 に示す。 W サービスは，運用部が運用する W システムによって実現されている。W システムの稼働環境及び試験環境は，2 台の物理サーバ，通信装置，外部記憶装置など，W 社の設備を使って構成されている。物理サーバのうち 1 台では，AP の不具合によって AP が停止した場合でも W サービスを継続できるようにハイパーバイザー型仮想環境で，二つのアプリケーションサーバ（以下，アプリサーバという）を稼働させている。他の物理サーバでも，同様に二つのデータベースサーバが稼働している。

Y 氏は，運用部の IT サービスマネージャである Z 氏にコンテナ技術の導入について意見を求めた。Z 氏は，試験項目に応じたコンテナをあらかじめ用意しておくことで，現在のコンテナの廃棄と用意されたコンテナの起動を行うことができるので，試験環境の整備を迅速かつ正確に行うことができると考えた。また，AP の不具合によって AP が停止するインシデントが発生した場合，現在の運用では，原因を調査後，原因となった問題を除去して再度 AP の起動を行っているが，その間は 2 台のアプリサーバのうち 1 台だけしか稼働していない状態となる。コンテナ技術を導入すれば，複数のコンテナを稼働させることができることに加えて，(ア) コンテナを稼働させてインシデント発生前の状態に戻すまでの時間を短縮できると考えた。

Z 氏は，ゲームアプリの開発と運用における課題に対して，コンテナ型仮想環境を活用したデプロイ方法を，ブルーグリーンデプロイメント方式にすることにした。この方式では，二つの稼働環境を用意して，利用者が使う稼働環境を切り替えられるようにする。具体的には，現状の稼働環境（ブルー）とは別に，新しい稼働環境（グリーン）を構築して最新版の AP を準備しておき，デプロイする日時に合わせて，利用者が使う稼働環境を切り替える運用方法のことである。
ブルーグリーンデプロイメント方式の例を図 2 に示す。

図 2 の例では，現状の稼働環境（ブルー）で 1.0 版のコンテナが稼働している。新しい稼働環境（グリーン）に 2.0 版のコンテナを起動させておき，コンテナ管理ソフトウェアを使って，現在の稼働環境をブルーからグリーンに変更する。(イ) 2.0 版のコンテナの動作に問題がないことを確認できた場合，1.0 版のコンテナを停止し，1.0 版のコンテナを廃棄する。

Z 氏と Y 氏は，コンテナ型仮想環境の検証を実施するための環境を新たに用意して，コンテナ型仮想環境の検証を開始した。
開発部では，AP が出力するエラーログの情報などを，稼働環境に影響を与えないようにアプリサーバに保存する設定としていた。そこで，今回の検証における AP のエラーログなどの情報も，コンテナ内に出力する設定とした。検証のために，コンテナを起動したところ，しばらく稼働していたがその後 AP が異常終了し，コンテナが廃棄される事象が発生した。運用部が原因を調査するためにエラーログ情報の内容を確認しようとしたところ，解析に必要な情報を取得できていなかったことが判明した。そこで，aする運用方法を検討することとした。
Z 氏は，コンテナオーケストレーションツールを導入し，コンテナの運用管理を自動化することにした。Z 氏が検討したコンテナオーケストレーションツールでは，起動されているコンテナの負荷状況によって，自動的にコンテナのスケーリングが行われる。スケーリングでは，CPU 使用率が一定のしきい値を上回る又は下回る場合に，コンテナ数の増減を行う。これによって CPU 能力を最適化するとともに，CPU 能力不足によってシステムがダウンする事象の発生を防ぐ。必要となるコンテナ数は，次の計算式によって求めることができる。

スケーリング後のコンテナ数 ＝ 現在のコンテナ数 × 現在の平均 CPU 使用率 ／ 期待する CPU 使用率

現在の平均 CPU 使用率は，コンテナオーケストレーションツールが定期的に自動的に測定を行う。Z 氏は，検証で最大 8 個までコンテナを稼働できる環境を用意し，現在の稼働環境の稼働状況を踏まえて，期待する CPU 使用率を 50％とした。