コンテナ移行を阻む課題と解決のヒント：失敗しないコンテナ化戦略【前編】

レガシーアプリケーションのコンテナ化にはどのような課題が発生するのか。それを最小限のコストで解決するためのヒントを紹介する。

[Adrian Bridgwater、Cliff Saran，Computer Weekly]

　パブリッククラウドにモノリシックアプリケーションをそのままデプロイするという、何もかもが力ずくの動きは依然存在する。

　アプリケーションは、機能ブロックに分解して各ブロックをコンテナで実行する方が効率が高い。Computer Weeklyは、企業がコンテナに移行する際に直面する最新の動向、力学、課題を専門家に聞いた。

関連記事

• 企業が絶対知っておくべきコンテナセキュリティの弱点
• 実はリスクが多いコンテナのセキュリティを確保する方法
• 「コンテナ」の“誇大広告”にだまされないために確認すべきチェックポイント
• 後悔しないKubernetesプラットフォームの選び方
• 小さくて速くてセキュアなユニカーネルの簡単作成ツール

　仮想マシン（VM）とは異なり、コンテナはOS（カーネル）を共有する。そのため1つのOSで複数のコンテナをサポートできる。簡単に言えば、コンテナはOSレベルではなくプロセス（アプリケーション）レベルの仮想化と見なすことができる。

　コンテナに移行すれば、よりモジュール性の高い構成が可能になる。だがリソースの相互接続が複雑になり、管理、メンテナンス、オーケストレーションが必要になるというトレードオフを伴う。「Kubernetes」のエコシステムが広がりを見せてはいるが、デプロイされている全てのコンテナの健全性、機能、広範な状態を同時に把握するのは簡単なことではない。

コンテナへの移行

　Alibabaのレイ・チャン氏（技術リード兼エンジニアリングマネジャー）は次のように話す。「アプリケーションをVMからコンテナに移行するベストな方法についてよく尋ねられる。Kubernetesの構築を試みる顧客は全て、それを複雑だと感じているようだ」

　VMのコンテナ化を検討している企業が最初にすべきことは、明確な移行計画を作成することだとチャン氏は言う。そのためには、移行を複数のステップに分ける必要がある。最も安定しているアプリケーション（例えばWebサイト）から始め、複雑なアプリケーションはコンテナスタックが成熟してから移行する。

　Appviaのルイス・マーシャル氏（技術エバンジェリスト）は、リスクを軽減するだけでも大きなメリットがあり、レガシーシステムをコンテナ化するという決定が容易になると語る。「レガシーシステムは適宜アップグレードしなければならないため、イミュータブル（訳注）ではない。イミュータブルなコンテナを利用することは、レガシーシステムに存在する不適切な習慣、プロセス、運用プラクティスを取り除く機会になる」と同氏は話す。

訳注：immutable（不変）。この場合は、本番環境にパッチ適用などの変更は行わず煩雑な更新作業から解放されること。

　手作業の処理が多く、あらゆる種類のアップデート作業に驚くほど手間が掛かり、リスクを伴うレガシーシステムもある。マーシャル氏の経験では、コンテナには運用コストとメンテナンスコストを下げながらセキュリティを向上させる能力があるという。

　レガシーシステムの運用コストがゼロに向かって下がるように努めることをマーシャル氏は推奨する。「コストが高く、提供するビジネス価値が限られているシステムがあるのなら、それをアップデートまたはアップグレードすることを優先する必要がある。システムが『稼働し続ける』ために数人の担当者が定期的に多くの残業を強いられているのなら、それは重大な危険信号だ」

　「システムが古くなると、通常はメンテナンスコストが上がり、セキュリティのリスクが高くなり、安定性が低下することを忘れてはいけない」（マーシャル氏）

コンテナ化の課題

　コンテナベースのサービスは、新たなアップデートが利用可能になったらサービスを削除してデプロイし直すことができる。だがCCS Insightのボラ・ロティビ氏（リサーチ部門ディレクター）は、適切な制御を施して常にアクセス可能にしておかなければならない重要なデータも存在すると指摘する。

　「開発者は、コンテナを含むストレージ資産のプロビジョニングに関与する必要がある。データ駆動型の企業は、最新データストレージと物理ストレージ層に精通することが不可欠になる」（ロティビ氏）

　Hammerspaceのダグラス・フォールズトロム氏（製品および運用部門バイスプレジデント）は、アプリケーションはインフラとデータの場所を認識する必要があると指摘する。これによりコンテナ化の全体的な複雑さが増し、何かが変わったらアプリケーションを再構築する必要性が生じると同氏は警告する。

　「オーケストレーションをシンプルにするために、コンピューティングはサーバレスになった。同様に、アプリケーションがインフラについて何も知らなくてもデータにアクセスできるように、データもストレージレスにする必要がある。ストレージレスデータが実際に意味するのは、どのサイトでもどのクラウドでもデータ管理がセルフサービスで行われ、自動化によってデータのサービス提供や保護がIT部門に負担を掛けることなく最適化される必要があるということだ」（フォールズトロム氏）

　データ管理の点で言えば、データベースは一般的にはクラウドネイティブアーキテクチャで運用するようには構築されていない。Cockroach Labsのジム・ウォーカー氏（製品マーケティング部門バイスプレジデント）は、Kubernetesなどのインフラでレガシーデータベースを管理するのは非常に難しいと言う。Kubernetesが提供するスケールアウト環境と並行してデータベースを運用している企業が多いと同氏は語る。

　「これによって、多くの場合はアプリケーションのボトルネックが発生し、さらに悪いことに単一障害点ができる。KubernetesでNoSQLデータベースを運用するのが適切だが、それでもトランザクションの一貫性の問題が発生する」（ウォーカー氏）

　データベースのこの問題に対処せずにクラウドネイティブアプリケーションを構築しているソフトウェア開発者は、コンテナとオーケストレーションの価値のほんの一部しか得られないと同氏は考えている。「Kubernetesは本来ステートレスなワークロード向けだ。結果として導入が抑えられている。導入が実際に進むのは、データを集中的に扱うワークロードをKubernetesで構築するときだろう」と同氏は語る。

後編では、コンテナ化したアプリケーションの運用時に発生する可能性のある問題と、迅速なコンテナ化を成功させる3つのステップを紹介する。