コンテナオーケストレーションとは？
著者
0 分で読めます
コンテナとは、アプリケーションまたはそのコンポーネントを格納した、軽量で隔離された実行可能な単位です。コンテナランタイムエンジンを備えたあらゆる環境やマシンで実行できるように、コンテナを構成できます。
コンテナを使うと、アプリケーションコードをポータブルにできます。コード、オペレーティングシステム（OS）ライブラリ、環境変数、依存関係、構成をひとつの単位にまとめられます。その後、さまざまなクラウド環境やオンプレミス環境にデプロイして、コードを実行できます。代表的なコンテナ化ツールには、Docker Engine、containerd、CRI-Oがあります。
コンテナオーケストレーションとは？
コンテナオーケストレーションとは、コンテナのデプロイ、運用、ライフサイクル管理を自動化することです。これにより、実行中のコンテナへのリソースの割り当て、デプロイ、スケーリング、監視、置き換え、ストレージ管理を自動化できます。Kubernetes、Docker Swarm、Nomad、Mesosは、広く利用されているコンテナオーケストレーターです。
コンテナ化されたアプリケーションが多数ある場合など、規模が大きくなるとコンテナの管理は困難です。独自のソリューションを使ってアプリケーションを監視、管理する方法は、時間がかかり、エラーも発生しやすくなります。十分に検証されたコンテナオーケストレーションプラットフォームを使えば、標準化と自動化によって、こうした両方の課題を解消できます。
この記事では、オーケストレーションが必要な理由を確認し、いくつかのコンテナオーケストレーターを詳しく見ていきます。また、コンテナオーケストレーションのメリットとセキュリティリスクについても解説します。
オーケストレーションの必要性
オーケストレーターが成熟する以前、コンテナ化されたアプリケーションは、多くの場合、カスタムスクリプトやデプロイツールを使ってデプロイされていました。これらのツールは通常、特定のプラットフォームやアプリケーションパッケージに特化したものでした。コンテナがもたらした標準化によって、共通のAPIとパッケージ仕様を通じてすべてのアプリケーションを扱えるようになり、汎用オーケストレーターが実現しました。
オーケストレーターが登場する前は、どのコンテナをどこで実行するかを管理するのは困難でした。特にマイクロサービスアーキテクチャへの移行では、常時数十、場合によっては数百のコンテナを稼働させ、1日に何度もアップグレードする必要があり、この課題は顕著でした。
オーケストレーターは、ホストのクラスター全体でコンテナを実行する複雑な作業を担い、スケーリング、アップグレード、ネットワークのプロビジョニングなど、さまざまな処理に標準化された仕組みを提供します。主なメリットのひとつは、開発者や運用担当者が望ましいアプリケーションの状態を指定する、宣言型のデプロイモデルを利用できることです。このモデルにより、作成者はプロセスをどのようにどこで実行するかを気にせずに済みます。クラスター内の状況に応じて、要求された状態を実現するために、オーケストレーターがコンテナやその他のエンティティを作成、削除するすべての作業を行うからです。また、デプロイしたものを継続的に監視し、アプリケーションのクラッシュやハードウェア障害などによってデプロイ状態が仕様から逸脱した場合、望ましい状態への自動復旧を試みます。
Kubernetes：主要なコンテナオーケストレーター
Googleは2015年、オープンソースのコンテナオーケストレーションプラットフォームKubernetesを発表しました。これは主に、社内で「Borg」と呼ばれていたコンテナワークロード管理システムの開発成果を基にしたものでした。2017年までにKubernetesはコミュニティから広く支持され、最も人気のある選択肢となりました。また、Kubernetes 1.0とともにCloud Native Computing Foundation（CNCF）が設立され、Googleや他の創設メンバーによってLinux Foundationに寄贈されました。CNCFは、containerd、Helm、Linkerd、Prometheus、gRPCをはじめとする、成功を収めたオープンソースプロジェクトを支援しています。
Kubernetesはプラットフォームに依存せず、互換性のあるコンテナランタイムエンジンを備えたすべてのオペレーティングシステムをサポートしています。現在は複数のクラウドプロバイダーがKubernetesをサポートしており、主要プロバイダーのAzure、AWS、Google Cloudは、Kubernetesをサービスとして提供しています。2018年、CNCFの調査では、コンテナ管理に関する調査回答者の40%がKubernetesを使用していました。2021年には、この割合は80%を超えました。
Pinterestなどの企業は、Kubernetesによって効率が高まり、プロジェクトのデプロイが速くなり、数百ものコンテナを管理することで時間とコストを節約できると述べています。CNCFによるSpotifyの事例研究では、Kubernetesの導入後、コンテナのCPU使用率が2〜3倍向上したと報告されています。
豊富な機能と活発なオープンソースコミュニティを備えるKubernetesは、非常に複雑なユースケースやアーキテクチャにも対応できます。一方、デプロイ頻度が低く、小規模でシンプルなアプリケーションをいくつか扱う場合には、機能が過剰に感じられるかもしれません。
その他のコンテナオーケストレーションプラットフォーム
Docker Swarm：Swarmは、Dockerランタイムエンジンに組み込まれたオープンソースのオーケストレーターです。他のクラスター化プラットフォームと同様に、1つ以上のマネージャーノードとワーカーノードで構成され、RAFTコンセンサスモデルを使ってノード間で状態を共有します。Kubernetesほど多機能ではありませんが、Dockerのバイナリに組み込まれているため、Swarmはセットアップやインストールが簡単です。また、Docker CLIやDocker Composeとの連携にも優れています。
Apache Mesos：Apache Mesosは、UC Berkeleyのプロジェクトです。Airbnb、Apple、Twitterをはじめとする大企業が、このコンテナオーケストレーターを利用しています。Mesosは軽量で、リソースをシームレスに割り当てられるため、スケーラビリティと柔軟性に優れています。ただし、利用には高度な技術知識が必要です。
Red Hat OpenShift：OpenShiftは、Kubernetesを基盤とするサービスとしてのプラットフォーム（PaaS）です。すべてのオペレーティングシステムで動作するわけではなく、CentOS、Fedora、またはRed Hat Enterprise Linux Atomic Host（RHELAH）が必要です。OpenShiftには、多くのKubernetesディストリビューションに欠けている認証・認可機能が組み込まれており、使いやすさも開発者にとって魅力です。
HashiCorp Nomad：Nomadは、スケジューリングと管理のプロセスに重点を置いたプラットフォームです。一方で、Kubernetesより多くのコンテナクラスターをスケールできます。
Rancher：Rancherは、Rancher Labsが提供する「Kubernetes-as-a-Service」を実現するオープンソースプラットフォームです。複数のKubernetesクラスターを管理するための、管理性、可観測性、スケーラビリティに優れたソリューションを提供します。単一のデプロイで、複数クラスターのインフラ全体に一貫性とセキュリティをもたらします。クラスターがオンプレミス、エッジ、プライベートクラウド、パブリッククラウドのいずれにあるか、またはこれらを組み合わせているかは問いません。
コンテナオーケストレーションのメリット
デプロイと管理の自動化：コンテナの数が増えるにつれて、手作業での管理はますます困難になり、エラーも起きやすくなります。オーケストレーションプラットフォームは、こうした作業を標準化して自動化します。十分に文書化されたAPIやプロセスに基づいて動作するため、運用担当者はプロセスをより簡単に監視し、トラブルシューティングできます。
状態の制御：Docker SwarmやKubernetesのようなコンテナオーケストレーターでは、コンテナの望ましい状態を事前に定義できます。オーケストレーターは、その状態で宣言されたコンポーネントを作成し、維持します。この宣言型モデルは、デプロイ用のスクリプトを記述する場合に必要となる命令型の指示よりも、開発者にとってはるかに書きやすいものです。
インストールとプロビジョニング：コンテナオーケストレーターは、トラフィックが増加した際に、新しいコンテナやアプリケーションインスタンスのセットアップを処理できます。これにより、アプリケーションの利用拡大に合わせて、新しいコンテナインスタンスを手動でインストール、プロビジョニングする必要がなくなります。多くの場合、オーケストレーションでは標準APIを使って、影響を受けるワークロードを適切にスケールできます。また、Kubernetes Horizontal Pod Autoscalerのような機能で、このプロセスを自動化することもできます。
リリースとロールバックの標準化：多くのコンテナオーケストレーション環境では、さまざまなアプリケーションバージョンのテスト、カナリアデプロイ、ブルーグリーンリリースなどを含め、リリースとロールバックのプロセスが標準化されています。
コンテナオーケストレーションのセキュリティリスク
アクセス制御と認証：ほとんどのオーケストレーションプラットフォームでは、厳格なアクセス制御や認証ポリシーが適用されません。そのため、アクセス制御が設定されていないと、デプロイされたコンテナは認証・認可に関する脅威に対して非常に脆弱です。ただし、認可や認証に関するインシデントを防ぐ対策を講じることができます。たとえば、Kubernetes APIへのアクセスを制御する方法があります。
ネットワークと通信の制御：デフォルトでは、クラスター内のすべてのコンテナが互いに通信できます。分散アプリケーションの開発を容易にする一方で、悪意のあるコンテナが他のコンテナを攻撃する可能性もあります。適切なネットワークポリシーを実装すれば、このリスクを軽減できます。
さらに、Snyk Infrastructure as Code（Snyk IaC）などのツールを使えば、開発者は構成が本番環境に到達する前にスキャンして修正できるため、インフラを安全に保ちやすくなります。
ソースコードの段階からインフラを保護
Snykはワークフロー内のIaCセキュリティとコンプライアンスを自動化し、構成ドリフトや不足しているリソースを検出します。
オーケストレーションのまとめ
コンテナオーケストレーターは、業界標準となっています。コンテナのデプロイ、インストール、プロビジョニング、管理の自動化に役立ちます。
コンテナオーケストレーションにはセキュリティリスクもありますが、適切な保護対策を講じれば、組織はコンテナ化のメリットを享受できます。一貫性を確保し、自動的にスケールしながら、時間も節約できます。
その他のリソース：
以下のリソースで、コンテナについてさらに学びましょう。