Container化の機会を特定する

既存システムをモダナイズするとき、最初からAmazon ECS、Amazon EKS、AWS Fargateのどれを利用するかを考えるとは限りません。

まず確認するのは、現在VMやホストへ直接配置しているアプリケーションや処理のうち、どの構成要素をContainer化すると、依存関係の再現性、Portability、配置単位の標準化、Orchestrationの導入といった効果を得られるかです。

Container化する価値があるかという判断と、Container化した後にどの実行基盤を利用するかという判断は分けて考えます。

1. Container化の判断は実行基盤を選ぶ前に行う

既存システムがAmazon EC2やオンプレミスのVM上で動作している場合、次のような構成を確認します。

• アプリケーション本体
• ランタイム
• ライブラリ
• 設定
• 起動方法
• ホスト固有の依存関係
• ローカルに保持している状態
• デプロイ単位
• 起動・停止・再起動などの管理方法

ここでの最初の問いは、Amazon ECSとAmazon EKSのどちらを使うか、ではありません。

先に、この構成要素をContainer化すると何が改善されるかを判断します。

既存構成
↓
Container化による利益を確認
↓
Container化する対象を決定
↓
必要であればOrchestrationを導入
↓
その後に実行基盤を選択

実行基盤の選択は、Container化の価値を確認した後の判断です。

2. 環境差異が大きい構成要素はContainer化候補になる

例えば、同じJavaアプリケーションを開発・検証・本番へそれぞれ直接デプロイしているとします。

各環境で、

JREバージョン
ライブラリバージョン
OSパッケージ
設定方法

などが異なっていると、同じアプリケーションのリリースでも動作差異が発生する可能性があります。

このような場合、

アプリケーション
+
ランタイム
+
必要なライブラリ

をコンテナイメージとしてまとめることで、実行に必要なユーザー空間の依存関係を一貫して扱いやすくなります。

Container化によって、

環境ごとに必要なものを個別導入

する構成から、

必要な依存関係を含むコンテナイメージを配置

する構成へ変更できます。

特に、環境ごとの手動構築によって依存関係の差異が生じているシステムはContainer化を検討する候補です。

3. Portabilityでは暗黙のホスト依存も確認する

Container化すると、アプリケーションと必要な依存関係をまとまった実行単位として扱いやすくなります。

ただし、コンテナイメージを作成しただけで、その構成要素が自動的にどのホストへも移動できるわけではありません。

例えばコンテナ内部の処理が、

特定ホストの固定パス
特定ホストだけに存在する設定ファイル
ローカルで動作する専用デーモン
ホストごとに手作業で作成する設定

を暗黙に前提としている場合、別の実行環境へ配置するときにも同じホスト固有構成を再現する必要があります。

Portabilityを高めるには、こうした外部要件を明示します。

例えば、

設定
→ 環境変数や明示的な設定ファイルとして渡す

外部データ
→ 明示的なストレージとして扱う

外部サービス
→ 接続先を設定として与える

特定ホストだけに存在する前提
→ 可能な範囲で削減する

という考え方です。

重要なのは、

Container化
=
ホスト依存が自動的にすべて消える

ではないことです。

暗黙のホスト依存を確認
↓
必要な外部要件を明示
↓
特定ホストへの結合を減らす
↓
互換性のある実行環境へ配置しやすくする

という観点でPortabilityを評価します。

4. Container化とマイクロサービス化は同じではない

既存のモノリシックアプリケーションをContainer化するために、必ずマイクロサービスへ分割する必要はありません。

例えば、

1つのモノリシックJavaアプリケーション
+
JRE
+
必要ライブラリ

を1つのコンテナイメージへまとめることもできます。

この場合でも、依存関係をまとめやすい、環境差異を減らしやすい、配置方法を標準化しやすい、といった効果を得られる可能性があります。

一方、どの機能を独立したサービスへ分割するかは別のModernization Decisionです。

したがって、Container化したいから必ずマイクロサービス化する、とは判断しません。

5. ホスト固有の依存関係を確認する

すべての構成要素が同じ程度にContainer化しやすいわけではありません。

Container化候補を評価するときは、特定ホストへの結合を確認します。

例えば次のような依存関係です。

カーネルモジュール
物理デバイス
固定MACアドレス
特定ホストのローカルファイル
ホスト固有ライセンス
ローカルディスク上の業務状態
ベンダーが指定する専用VM構成

こうした依存関係が強い場合、Container化に必要な変更量が増えることがあります。

逆に、外部データベースを利用、外部ストレージを利用、ホスト固有機能への依存が少ない、ランタイムとライブラリをまとめやすい、といった構成要素はContainer化候補になりやすくなります。

判断するときは、Container化できるかだけではなく、Container化によって得られる利益と必要な変更量を比較します。

6. Container化後の手動管理が残るならOrchestrationの機会になる

Container化しても、複数ホストへの配置や障害時の再起動などをすべて手動で管理している場合があります。

例えば、

コンテナをどのホストへ配置するか
停止したコンテナをどう再起動するか
必要な実行数をどう維持するか

を独自スクリプトや手作業で管理している状態です。

このような場合は、Container化だけでなくOrchestrationを導入する機会があります。

Orchestrationでは、必要な実行数、配置、再起動、継続的な実行状態などを宣言的に管理しやすくなります。

AWSではAmazon ECSやAmazon EKSなどを利用できます。

ここで判断するのは、Amazon ECSとAmazon EKSのどちらが優れているか、ではなく、手動でContainerのライフサイクルを管理しているためOrchestrationを導入する価値があるかです。

7. Amazon ECS / Amazon EKSの選択条件は再判断しない

Amazon ECSとAmazon EKSは、Container化されたワークロードをOrchestrationするための選択肢です。

ただし、Container化するべきかと、Amazon ECSとAmazon EKSのどちらを使うかは異なる判断です。

ここでは、既存アプリケーションにContainer化の機会があるかを先に評価します。

既存アプリケーション
↓
Container化の価値を評価
↓
Container化
↓
Orchestrationが必要か評価
↓
必要に応じてAmazon ECS / Amazon EKSなどを選択

という順序で考えます。

8. AWS Fargateの適否とContainer化の価値を分離する

AWS Fargateを利用できない要件があっても、Container化自体に価値がないとは限りません。

例えば、あるアプリケーションが特殊なホスト機能、特別なホスト構成を必要としていて、AWS Fargateの実行条件に適さないとします。

この場合でも、

依存関係をコンテナイメージへまとめる
配置単位を標準化する
環境差異を減らす

といったContainer化の効果を得られる可能性があります。

したがって、

AWS Fargateを使えない
↓
Container化する意味がない

とは判断しません。

Container化の価値と、どのContainerコンピューティングを利用するかは分離して評価します。

9. Container化によって配置単位を標準化する

従来のVM中心の構成では、1台のサーバーに複数のアプリケーションや処理をまとめて配置していることがあります。

例えば、

1台のAmazon EC2
├─ ウェブアプリケーション
└─ バッチ処理

という構成です。

この状態ではウェブアプリケーションだけを更新した場合でも、サーバー全体への影響を確認する必要が生じることがあります。

Container化によって、

ウェブ
→ Container A

バッチ
→ Container B

のように配置単位を分けると、バージョン、配置、実行数、更新を構成要素ごとに管理しやすくなります。

これは、サーバーを主な配置単位とする構成から、Containerを配置単位とする構成への変更です。

ただし、別々のContainerへ分けただけでアプリケーション同士が自動的に疎結合になるわけではありません。

10. Container化による利益と変更量を比較する

Container化は目的ではなく、モダナイズのための手段です。

そのため、Container化できる、だけで採用を決めません。

例えば次の利益を確認します。

依存関係の再現性向上
Portability向上
配置単位の標準化
Orchestration導入
デプロイ方法の一貫性向上

同時に、必要となる変更も確認します。

ホスト固有依存の除去
設定方法の変更
永続データの扱い変更
運用方法の変更
監視方法の変更

そして、得られるビジネス価値が必要な変更量と運用負荷を上回る構成要素を優先してContainer化します。

11. 一部だけContainer化してもよい

既存システム全体を一度にContainer化する必要はありません。

例えば、

ウェブAPI
バッチワーカー
ベンダー製品

の3つから構成されているシステムを考えます。

ウェブAPIとバッチワーカーは、

ホスト固有依存が少ない
外部データベースを利用する
ランタイムとライブラリをまとめやすい

一方、ベンダー製品は、

専用VMがサポート条件
カーネルモジュールが必要
物理デバイスとの連携が必要

という場合があります。

この場合、

ウェブAPI
バッチワーカー
↓
Container化候補

ベンダー製品
↓
既存VMを維持

という段階的なModernization Decisionが可能です。

12. Container化の機会の判断表

13. 判断フロー

Container化の機会は次の順序で整理できます。

既存アプリケーション / 処理を確認
        ↓
依存関係や環境差異が大きいか
        ↓
ホスト固有の依存関係は何か
        ↓
外部要件を明示して
特定ホストへの結合を減らせるか
        ↓
Container化すると
Portability・再現性・配置単位を改善できるか
        ↓
変更量に対して十分なビジネス価値があるか
        ↓
Container化対象を決定
        ↓
手動の配置・再起動・実行数管理が残るか
        ↓
必要ならOrchestrationを導入
        ↓
実行基盤を選択

重要なのは、

Amazon ECS / Amazon EKS / AWS Fargateを使いたい
↓
Container化する

ではありません。

現在の依存関係
ホストへの結合
配置単位
運用方法
を確認
↓
Container化で改善できる部分を特定
↓
Modernization Decision

という順序で判断します。