エンタープライズ IT でコンテナが支持を得ている理由とは

2020-04-16 (Thu)  •  By 伊藤  •  活用のヒント  •  クラウド

今回の記事は、ゴーツーグループ ブログ英語版「Why are Containers Gaining Ground in Enterprise IT? 」の弊社翻訳版です。原文と差異がある場合は、原文の内容が優先されます。

ここ数年、企業が顧客の要求に応えるべく IT 戦略を順応および転換させていくに伴い、コンテナの採用は勢いを増しています。基本的に、コンテナとは IT 作業負荷ホスティング オプションであり、大規模な実稼働環境への展開に使用されるケースが増えています。コンテナ技術の採用は急速に進んでおり、調査企業であるガートナー社は 2022 年までにグローバル企業の 75% 以上がコンテナ化アプリケーションを実稼働環境で実行していると予測しています。この記事では、コンテナが何故重要なのか、組織でコンテナを利用し始める際に理解および調査すべき点について解説します。

アプリケーションの移植性の高さ

コンテナは、コンピューティング環境を別の場所に移動したときにいかにソフトウェアを効率良く実行させるかという問題の解決策になります。たとえば、開発者のノート パソコンからテスト環境へ、ステージング環境から実稼働環境へ、または自社運用のデータ センターからクラウドへの移動などです。コンテナはすべての関連する構成ファイル、ライブラリ、依存ファイルと共にアプリケーション コードをパッケージ化するため、「一度ビルドすればどこでも実行できる」という手法が可能になり、多様なプラットフォーム間でのアプリケーションの移植が非常に容易になります。開発者は新しいクラウド プラットフォームが使用されるたびにコードを書き直す必要がなくなるため、コンテナの移植性という利点は今日のマルチクラウド環境では意義のあるものとなります。

コンテナは CI/CD および DevOps を促進するツールとしても有効です。DevOps の成功基準の鍵の 1 つは、開発者の運用への関わりおよび実稼働環境でコードがどのように実行されるかへの関わりを高めることです。これはまさにコンテナが対処しうる問題です。コンテナでは、開発者は各コンテナ イメージ内のものを掌握し、緻密に制御された環境をセットアップしてビルド/テスト/展開パイプラインを作成できます。コンテナにはベース オペレーティング システムから 1 つのイメージにバンドルされたアプリケーション コードに至るまで、すべてが含まれています。そのため、コンテナ内でアプリケーションが作成、テスト、および展開された場合、ソフトウェア デリバリ チェインのあらゆる部分において一貫して同じ環境が保たれます。つまり、コンテナが開発環境で実行される場合と QA や実稼働環境で実行される場合では、まったく同じ状態になります。

システム リソースの利用効率の高さ

OS カーネルをシステム上の複数のコンテナ間で共有できるため、システム リソースという面でもコンテナは旧来の仮想マシン環境よりも利用効率がずっと高いです。このアプローチでは OS のインスタンス 1 つだけで多数の孤立したコンテナを実行できるため、仮想マシンで生じがちな CPU、メモリ、およびディスクのオーバーヘッドを減らすことができます (仮想マシンでは個々の OS インスタンスが必要)。こうしたことはすべて IT 面でのコスト削減につながります。コンテナ化されたアプリはホスト ハードウェア上でより密にパッケージ化できるため、同じ作業負荷を実行するのに必要なオペレーティング システムのインスタンス数を削減し、ソフトウェア ライセンスに掛かる費用を減らすことができます。

高モジュール性

コンテナの別の利点として、高いモジュール性が挙げられます。単一のコンテナ内に複雑なアプリケーション全体を実行する代わりに、アプリケーションを複数のモジュールやマイクロサービスに分解できます。各モジュールが比較的シンプルであり、アプリケーションの他の部分を中断せずに個々のモジュールを更新できるため、この方法で作成されたアプリケーションは管理が容易です。コンテナは軽量であるため、これらの個々のモジュールまたはマイクロサービスは「ジャスト イン タイム」方式で必要なときに必要なだけ、ほぼ瞬時に起動できます。

強力な災害復旧およびセキュリティ機能

コンテナは分離されているため、互いに干渉しあうことはありません。1 つのサーバー上で複数のコンテナが実行されており、そのうちの 1 つがクラッシュした場合、残りのコンテナは中断なしで実行し続けることができます。同様に、1 つのコンテナでハッキングまたはセキュリティ侵犯が発生した場合、影響はそのコンテナだけに留まります。コンテナは軽量であるため、シャットダウンして瞬時に再起動できます。

しかし、マイナス面もある

もちろんコンテナにもマイナス点はあります。コンテナでのアプリケーションの展開は比較的新しい取り組みです。新しい技術すべてに言えることですが、開発者はそのメリットをどのように活かすかをまだ学習している段階です。業界標準およびさまざまな領域での成功事例を十分に注視する必要があります。特に、学習段階において組織はデータ セキュリティ、システムの整合性、および通常のサービス レベルが低下しないように常に留意する必要があります。

コンテナ オーケストレーション (ユーザーが定義したパラメーターに基づいたコンテナの作業負荷のスケジューリングと管理) も考慮すべき点です。コンテナ オーケストレーション ツールとして最も広く使われているのは Kubernetes です。コンテナ オーケストレーション プラットフォームに期待する主な機能として、コンテナの準備と展開、作業負荷に応じたコンテナの規模増減、障害時でのアプリケーションの高可用性の確保、セキュリティ上の欠陥の検出、コンテナの正常性の監視などが挙げられます。

考慮すべき別の要素として、コンテナが長期にわたって無秩序に広がってしまう可能性があることです。コンテナは「1 つのコンテナに 1 つのアプリケーション」というインフラを基にしているため、管理および監視すべき個々の単位が大量に発生することになります。コンテナの数が増えるほど、環境の複雑さは増します。これは雪だるま式に技術的負債につながっていき、適切な監視と管理を確立しなければ予測のつかない複雑な状況に陥る可能性があります。

組織でコンテナ構想を開始するにあたって

アプリケーション展開にコンテナを活用するにあたって、当然のことながら考慮すべき点が数多くあります。導入を開始する前に、組織の現在の IT の状態を分析する必要があります。アプリケーションを一から構築するのか、古いワークロードをリファクタリングするのかを決める必要があります。マイクロサービスのパターンおよび変更の発生しない設計インフラという観点で特定の要件を考慮した後で、Docker テンプレートを使用して必要なコンテナ イメージを作成するのは比較的簡単であるため、通常、コンテナ化は新しいプロジェクトでの使用がより適切です。リファクタリングを行う場合、コンテナ化に最適なアプリケーションが個々のコンポーネントに分解されます。重要なことは、大幅な書き換えにつながる混乱を起こすことなく、コンポーネントがコンテナ内で分割および分離可能であるという点です。

考慮すべき別の重要な点として、チームが現在使用しているスキルを再形成して高める必要があるということです。コンテナ化は非常に速いスピードで進められていますが、それでもまだ初期段階であり、成熟度の問題や産みの苦しみを抱えています。実戦経験を持つ人材とスキルが不足しています。シンプルなコンテナ化プロジェクトでチームのスキル セットを高めることから始めるのが理にかなっています。また、開発者と IT 運用スタッフが最新技術を把握できるように、Cloud Native Computing Foundation (CNCF) や Kubernetes をサポートする他の組織への参加をチームに促すこともできます。さらに、組織の多くが将来のプロジェクトにおける潜在的な落とし穴を予測し、今後のコンテナ化構想で候補となるアプリケーションを選定するにあたってコンサルタント会社やサードパーティ ベンダーに協力を仰いでいます。

  Previous Next  

関連記事