コンテナは型にはめられることにうんざりしている

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

感謝祭といえば……七面鳥。クリスマスといえば……ツリー。コンテナといえば……マイクロサービス。

それぞれについて最初に思い浮かべた言葉が私の予想どおりだったなら、今日のテクノロジー市場に見られる過度な関連付けに陥っていることになります。コンテナとマイクロサービスは、どちらか一方をテーマにした議論でも、すぐにセットで語られがちです。その理由の1つは、アプリケーションを目的の明確なアジャイルなサービスへと分割するアーキテクチャアプローチであるマイクロサービスが、コンテナベースのデプロイモデルのアジャイルな性質と相性がよいことです。しかし、コンテナ自体が独立したテクノロジーであることを忘れてはなりません。コンテナは、マイクロサービスというアーキテクチャの構想が生まれるはるか以前から存在しており、そのメリットはマイクロサービスベースのアプリケーションのデプロイだけに限られるものではありません。

次の興味深いデータをご覧ください。これは、Enterprise Development Trends 2016という2,100人のJVM開発者を対象とした調査から得られたものです。この調査を基に、Lightbend（自らを世界有数のReactiveアプリケーション開発プラットフォームを提供する誇り高き企業と称しています）は、クラウド、コンテナ、マイクロサービスに関するさまざまな知見を導き出しました。興味深いことに、過半数（59%）が新規アプリケーションのコンテナ化を検討している一方で、41%は「既存のアプリケーション」をコンテナ化の対象としています。

これは決して異例ではありません。2016年8月の調査（MesosphereがMesosユーザー500人を対象に実施）によると、51%がMesos上でモノリシックアプリケーションやレガシーアプリケーションを実行しています。また、予想どおりとも言えますが、85%がマイクロサービスアーキテクチャを実行しています。

コンテナが新しいアプリケーションだけのものではないことは明らかです。レガシーアプリケーションやモノリシックアプリケーションでも、可搬性、迅速なスケーリング、DevOps主導の運用との高い親和性といったコンテナの多くのメリットを得られる手段として活用されています。結局のところ、摩擦のない可搬性が約束されていたにもかかわらず、実際には各パブリッククラウドプロバイダーが異なるイメージ形式を標準として採用したため、再イメージ化に長い時間がかかることになりました。複数のゴールドイメージ（環境ごと、マイナーブランチごと、メジャーブランチごと……もうお分かりでしょう）を維持することは、運用上の悪夢となりました。しかし、コンテナはラーテルのように、そんなことは気にしません。OSからOSへ、仮想マシンから仮想マシンへ、クラウドからクラウドへと自在に移動できます。コストに基づいて、瞬く間に（計測している方のために言えば約400 msで）シームレスにクラウドを移行するという理想郷を実現する手段として、これまでに提案された中でも特に優れた方法の1つです。

とはいえ、コンテナを「クラウド」技術と決めつけるべきではありません。コンテナは、以前から期待されながら実現することがほとんどなかったクラウドプロバイダー間のポータビリティを大きく向上させますが、その用途はクラウドやクラウドに似た環境に限定されません。実際にコンテナが「クラウド」で使用されていることは、Sumo Logicの最新レポートでも示されています。同レポートでは、調査対象のアプリの15%でDockerが本番環境に使用されていることが明らかになりました。しかし、これはオンプレミスなど、ほかの環境でコンテナが使用されていないという意味ではありません。実際、前述のMesosphereのレポートによると、ユーザーの半数近く（45%）が「オンプレミスのみ」で利用しており、残りの大半は「ハイブリッド」と「クラウドのみ」に分かれています。また興味深いことに、「大企業（従業員数500人以上）ほどオンプレミスで運用する傾向が強い」ことも明らかになりました。

コンテナは興味深いデプロイ手段です。Docker、Docker swarm、MesosとMarathon、Kubernetesなどのコンテナオーケストレーションソリューションと組み合わせることで、アプリケーションをデプロイし、必要に応じて自動的にスケールアップ／ダウンできる、非常に俊敏な環境を実現します。これはマイクロクラウド、少なくともクラウドに似た環境であり、パブリッククラウドやプライベートクラウドだけでなく、「クラウド」を一切使用しない環境にもデプロイできます。コンテナは、モノリシックアプリ、モダンアプリ、マイクロサービスベースのアプリ、APIのデプロイとスケーリングに利用できます。オペレーティングシステム層を標準化し、アプリが環境に密結合しないようにすることを重視しているため、柔軟性に優れています。

端的に言えば、コンテナは抽象化レイヤーです。これにより、アプリケーションはラーテルのように、下位レイヤーの細かな違いを「気にせず」に動作できます。コンテナオーケストレーションソリューションで監視・管理することで、この抽象化を通じてスケールアップ／ダウンやスケールイン／アウトを自動化し、アプリケーションインフラストラクチャ全体のリソース効率を高めることができます。

コンテナ、マイクロサービス、クラウドは大の仲良しかもしれませんが、それぞれが独立して十分に成り立つ存在です。それぞれのメリットは互いに補完し合い、ときには、あえて言うなら相乗効果も生み出します。しかし、コンテナを「マイクロサービス専用」「クラウド専用」という非常に狭い枠にはめるべきではありません。

コンテナは、決まりきった役割に当てはめられることにうんざりしています。アーキテクチャ内でさまざまな役割を担わせてみれば、どの役割でも主役を務めるだけの十分な能力があると気づくかもしれません。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事