コンテナ化プロジェクトの準備を行うための4つのステップ：Gartner Insights Pickup（83）

ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。

　新しいアプリケーションを開発したり、既存アプリケーションのリファクタリングを行ったりして、パイプラインの進行が遅いことやパイプラインでエラーが起こりやすいことに気付いたら、インフラのアジリティを高めるためにコンテナの導入を始めるべきかどうか悩むかもしれない。

　的確な判断ができるように、「コンテナとは何か」「コンテナは、『アプリケーションライフサイクルのシンプル化』という課題をどのように解決できるのか」をまず見ておこう。

　コンテナでは、ソフトウェアをあるコンピューティング環境から別の環境に移しても確実に実行できる。「コンテナは、アプリケーションをパッケージ化し、全ての依存関係（ライブラリ、構成ファイル）とバンドルして、1つのポータブルなイメージにしたものだ」と、Gartnerの主席リサーチアナリストを務めるアナ・ベラク氏は説明する。

　「コンテナ化は、アプリケーションとその依存関係をインフラから分離する。その結果、OSディストリビューションやコアインフラの違いに起因する問題が解消される」（ベラク氏）

　コンテナは、幾つかの現実におけるユースケースに適している。例えば、コンテナを使うと、オンプレミスインフラからクラウドへ、あるいは2つのクラウド事業者間で、ワークロードを比較的簡単に移行できる。こうした移行は、クラウド戦略の一環として行われる永続的なものと、クラウドバースティングなどの場合に行われる一時的なものがある。

　コンテナはOSを共有しながらワークロードを分離するので、管理者は同一サーバ上で単一アプリケーションの幾つかのバージョンを干渉なしで実行できる。コンテナ化のこうした特徴は、サーバ集約の観点からも利用できる。

　さらに、コンテナは軽量で、起動と停止を高速に行えるので、迅速なソフトウェア開発／リリースのための、自動化された継続的インテグレーション（CI）や自動化されたテスト環境で円滑に使用できる。

　Gartnerは、技術担当者がコンテナ化の取り組みを成功させるには、プロジェクトを開始する前に、以下の4つのステップを完了すべきだと認識している。

コンテナ化の準備を行うためのGartnerフレームワーク（出典：Gartner）

ステップ1：文化的調整の準備を行い、スキルギャップを埋める

　ベラク氏はこう説明する。「企業におけるコンテナの導入は、単独のチームで責任を持って管理するには手に余る。コンテナ化プロジェクトは時間がかかる上、コストが高くつくこともある。そのため、成功を収めるには、例えばセキュリティやITインフラ＆オペレーション（I＆O）、ネットワーキング、アプリケーション開発といった、関連する全てのチームから支持を得なければならない」

　また、新しい技術の実装では多くの作業が必要になるため、技術担当者がプロジェクトに関わるチーム間、とりわけアプリケーション開発チームや、I＆Oチームの間での活発な協力を促進することが重要だ。

　「われわれは、DevOpsの考え方を持っている組織の方がコンテナ化に伴う課題に対処する態勢が整っていると認識している。コンテナが提供する技術フレームワークは、DevOpsの方法論に合致しているからだ」（ベラク氏）

　コンテナを本番環境にデプロイするのに必要なソリューションの多くが、商用サポートを含むオープンソースベースのエンタープライズライセンス付き製品として提供されている。組織がオープンソースコンポーネントを採用するか、商用製品のみを採用するかにかかわらず、チームはコンテナを的確に管理するのに新しい運用モデルを導入する必要がある。

　技術担当者は、こうした新しい複雑なソリューションの管理が迅速に軌道に乗り、長期にわたって一貫して行われるように、スタッフに適切なトレーニングを提供しなければならない。

ステップ2：インフラの自動化ノウハウを磨く

　コンテナのデプロイでは、コマンドラインインタフェース（CLI）やAPIによる自動化と管理が必要になる。コンテナは、高度なライフサイクル処理、高速な起動、シャットダウンが行われることから、手動で大規模に管理するのは難しすぎるからだ。コンテナ管理ソリューションはデプロイ状況を可視化するダッシュボードを提供するが、ほとんどの運用タスクはCLIかAPIで実行しなければならない。

　「技術担当者が、ダッシュボードで可視性を提供するコンテナ管理ツールを選択することは重要だ。だが、同時に、デプロイ操作はGUIではなく、CUIかAPIで行うしかないことを念頭に置く必要がある」とベラク氏は説明する。

ステップ3：明確な第1および第2目標を立てる

　技術の1つであるコンテナからビジネス価値を引き出すには、組織は現実的な目標を設定する必要がある。第1目標と第2目標を立ててプロジェクトを推進し、影響が小さい事項にこだわらないようにする。

　「第1目標は、コンテナ化の取り組みの直接的な結果として達成できれば理想的な目標だ」とベラク氏は語る。これらの目標は影響が大きく、以下に当てはまる。

• 既存の大きな問題点に対処する
• 定量化可能なコスト削減の機会を創出する
• チームが社内外の顧客への商品やサービスの提供を明らかに改善することを可能にする

　第2目標は、影響が中程度の目標だ。この目標は、第1目標が失敗しても達成できる。つまり、これは第1目標に関連する目標であり、第1目標に取り組んだ結果として、自動的にあるいは最小限の労力を加えることで達成することが可能だ。

　よく言及されるものの、影響が小さい目標としてライセンス料の節約や、“仮想化税”の支払いの回避といったものがある。コンテナ化に取り組むことでこうした結果が得られる場合もあるが、これらは投資するに値しない。

　だが、アジリティや運用効率、顧客満足を高めるアプリケーションのリファクタリングは、投資に値するだろう。インフラコストの低減のなどのプラス効果ももたらす可能性がある。

ステップ4：アプリケーション候補を選択する

　この最終ステップでは、リファクタリングプロセスの対象候補として、どのアプリケーションが適切かを慎重に選択するか、あるいは全く新しいアプリケーションをコンテナでデプロイすべきかを判断する。

　方針を決定したら、チームとしてシンプルなコンテナ化プロジェクトを行うスキルセットを育成する。チームに新しい知識とツールを提供し、開発者や運用担当者が将来のプロジェクトの潜在的な落とし穴を予測したり、以降の取り組みのために、適切なアプリケーション候補を自信を持って選択したりできるようにする。

出典：Prepare for Your Containerization Project（Smarter with Gartner）