通常アプリケーションを実行するためには、アプリケーション実行コードが必要です。

加えて、アプリケーションが実行するランタイムライブラリや、内部で使用する依存ライブラリ等を用意します。

そして、アプリケーションの設定ファイルも必要です。


これらのファイル群は、サーバーの数が少ない場合はあまり気にする必要はありません。

しかし、大量のサーバーを用いてアプリケーションを分散し起動したり、あるいは開発環境の様に設定を差し換えて起動したりとなると色々と問題が出てきます。

まず、環境や設定が不統一の場合はサーバーを立ち上げるのに一苦労です。


それを解消するのが、コンテナです。

アプリケーションに必要とされるアプリケーション実行コードとランタイムライブラリおよび依存ライブラリをコンテナ化し、まとめることでデプロイが簡単になります。

実行環境に合わせてコンテナの設定をカスタマイズするだけで準備が完了です。


コンテナとはアプリケーションとその実行環境を１つにまとめあげて動作させる技術のことです。

簡単にいうと、アプリケーションに必要な物をまとめた箱です。

Docker はコンテナに対するオペレーティングシステムです。

仮想マシンがサーバーハードウェアを仮想化 (直接管理する必要をなくす) ように、コンテナはサーバーのオペレーティングシステムを仮想化します。

Docker は各サーバーにインストールされ、シンプルなコマンドを使ってコンテナを構築、開始、停止できます。

近年、ここまでDockerが注目されるようになった理由は、イメージを作っておきさえすれば何度でも同じ環境を構築できる点にあります。


ソフトウェアないしサービス開発の仕事では、大体において「開発・テスト・本番・QA」の4つの環境を使いまわす必要性があります。

これらをすべて管理するのはなかなか骨が折れる作業である上、手作業が絡む場合はどうしても抜け漏れが発生しやすくなります。


作成したイメージを使い回しできるDockerなら、こういった抜け漏れを防止することができるため注目されているわけです。

Kubernetes とは、コンテナの運用管理と自動化を行うために設計されたオープンソースソフトウェアです。

読み方は「クバネティス」もしくは「クーベネティス」省略して「K8s」と表記されることもありますね、ギリシャ語で、操舵手・パイロットを意味します。


Kubernetes の操作対象は、Docker をはじめとするコンテナです。

コンテナは各種アプリケーションを実行してくれますが、それ自体を管理したり、別サーバーと連携したりはできません。

そのため、複数ホストでコンテナを運用したい場合などは、管理が煩雑になってしまいます。


Kubernetes は、このような問題を解決してくれるシステムです。

Kubernetes を使えば、複数ホストでコンテナを運用する場合に、ネットワークやストレージなどの連携管理が可能となるのです。

このような仕組みは「コンテナオーケストレーション」とも呼ばれます。


Kubernetesには、複数のコンテナを管理するKubernetes Podがあり、さらに複数のPodが「ノード」にまとめられています。

そして、「ノード」が集まったものが「クラスタ」です。

「クラスタ」とは、コンテナの配置や削除を行うときに指示を出す部分です。

「ノード」とは、「クラスタ」を構成している各サーバーを指します。


クラスタは、Kubernetes全体構造の最上位階層に位置する部分といえます。

実行される場所について言えば、Kubernetes はクラスタで実行されます。

利用目的について言うと、上述の通り、Kubernetes の利用目的は各コンテナを管理することです。

一方で、Docker の目的はアプリケーションを各コンテナに分離することです。


Kubernetes　実行場所：クラスタ　　利用目的：コンテナの管理

Docker　　　実行場所：単一ノード　利用目的：アプリケーションのコンテナ分離


まとめると、上記のように Kubernetes と Docker はそれぞれ異なります。

また、この2つは、使用目的が異なるため、どちらかのみを利用するのではなく、連携して使うことでコンテナを上手く活用できることを覚えておきましょう。


例えば、管理対象が大きくなって Docker が増えた場合などには、Kubernetes を活用することで複数の Docker ホストを管理する手間が減り、コストを削減にも繋げられます。

その他、コンテナのスケジューリングやオートスケーリング、データの管理など、Docker だけでは実現しにくいことが、Kubernetes を利用すると可能となります。

Kubernetesを導入すると、そんなコンテナ周りの一元管理、一元操作をしてもらうことができます。

Amazon Elastic Container Registry(ECR)はフルマネージドなDockerコンテナを保存しておくためのレジストリサービスです。

自身で作成したり、AWS Marketplaceで購入したDockerコンテナイメージの保存・Dockerコンテナイメージの管理・コンテナイメージをアプリケーションにデプロイが可能です。

AWS ECSとは、仮想サーバーを構築する際に使われるDockerコンテナの実行、停止、管理が簡単に出来るサービスです。

正式名称をElastic Container Serviceといい、非常に高速で、仕事や利用者の増加に対応出来る能力に長けていることに高い評価を受けています。

Dockerコンテナへと対応しているため、Amazon EC2インスタンスのマネージドクラスターで、簡単にアプリケーションを実行することが可能です。

このコンテナを管理するサービスのことを、オーケストレーターといいます。

ちなみにオーケストレーターでコンテナ管理すること、そのものはオーケストレーションといいます。


注意点としては、ECSはコンテナを動かす実行環境ではないという点です。

あくまでもコンテナの管理に使用し、実際にコンテナを実行する環境には、Amazon EC2やFargateといった別のサービスを使用します。

コンテナオーケストレーターを使う目的は、複数ホストで起動するコンテナを一元管理するためです。

コンテナオーケストレーターであるECSの導入により、ECSが複数のDockerホストそしてコンテナを管理してくれます。

よって、管理者はECSだけを確認すればよくなります。


また万一、コンテナが停止した場合もあらかじめ定義した設定に従ってコンテナを再起動し、サービス提供可能な状態にしてくれます。

Amazon Elastic Kubernetes Service (Amazon EKS) は、 独自の Kubernetes コントロールプレーンまたはノードをインストール、操作、および維持することなく、 AWS で Kubernetes を実行するために使用できるマネージドサービスです。

Kubernetes Master(コントロール プレーン)に当たる部分を、マネージドで運用してくれます。

EKSを利用することで、Kubernetesをクラウド上で実行できるようになります。


マネージドサービスなので、以下のことは勝手にやってくれます。

Kubernetes Masterの更新・パッチの適用

死んでしまったKubernetes Masterの検出、置き換え

複数AZへのKubernetes Masterの配置・構成


また、 AWSの提供する他サービスとの連携も、できるようになっています。

例えば、ロードバランサや、ストレージなどをKubernetesが作成する場合、AWSマネージドのサービスを選択できます。

そのため、それらの運用の一部をAWSに任せることができます。

一方で、Kubernetes Node(データプレーン)として、運用するマシンは自分で管理・運用する必要があります。


ECSとの違いとしては、オーケストレーションツールが異なります。

ECSはAWS独自のオーケストレーションツールを利用しておりAWS上でのみ利用できますが、 EKSはKubernetesを利用しているため、オンプレミスでKubernetesを利用している方はクラウド上で同一のものを使える利点があります。

また、ECSにはない高度な機能として、コンテナのスケーリングや障害時の自己修復機能などが利用できます。

Amazon ECSとAmazon EKSで動作する、ホストマシンを意識せずにコンテナを実行できる環境です。

AWS Fargateを利用すれば、コンテナとコンテナの実行環境の2重管理が不要になります。

いわゆる、コンテナ向けのサーバーレスコンピューティングです。


Fargateを一言で表すと「AWS上でコンテナをサーバーレスで実行することができる機能」です。

サーバーレスとは、サーバーの構築や保守などを意識することなく、サーバー上でプログラムを実行できる仕組みであり、アプリケーション開発に集中できるというメリットがあります


Fargateはこの機能をAWS上で提供するのですが、他にも以下のような特徴があります。

・データプレーンとしてECSやEKSと組み合わせて利用

・AWSマネージドで、EC2インスタンスのプロビジョニング、スケール、管理が不要

・仮想マシンを意識しないシームレスなスケーリングができる

・コンテナの起動時間、使用リソースに応じた従量課金

・他のAWSサービス（VPCネットワーキング、ELB、IAM、Cloud Watchなど）と連携可能


Fargateを理解する際のポイントとして「データプレーン」という言葉がありますので、こちらについても解説していきます。

「データプレーン」と「コントロールプレーン」という言葉はいろんな場面で見かけますが、AWSでは「コンテナを管理するサービス」を語るときに出てきます。


AWS上でのそれぞれの役割は以下です。

データプレーン：コンテナの実行環境。FargateとEC2がこの機能に該当する。

コントロールプレーン：コンテナをコントロールする機能。ECSとEKSがこの機能に該当する。


上述したFargateの特長に「ECSやEKSと組み合わせて...」と記載いたしましたが、以下のようにデータプレーンとコントロールプレーンを組み合わせることができます。

①Fargate+ECS②Fargate+EKS③EC2+ECS④EC2+EKS


データプレーンでEC2を選ぶ場合との違いは？

データプレーンはFargateかEC2どちらか選べますが、両者の違いを端的にお伝えすると「Fargateでは細かい設定や管理が不要。

EC2では細かい設定や管理が必要。」というものになります。


知識を身に付けたり詳しい人を雇わず「まずはコンテナ環境で開発を始めてみよう」という方法をとれるのが、Fargateの大きなメリットになります。