AWSにおけるコンテナサービス

#■コンテナって？#
![スクリーンショット 2018-11-28 18.52.05.png](https://qiita-image-store.s3.amazonaws.com/0/280929/25e7d862-54fe-7553-62ed-94d17e6f4b34.png)

**まず仮想化とは？**
ホストとなる1台のコンピュータの上に、仮想的に複数のコンピュータ（ゲストマシン）を構築する技術です。
個々のゲストマシンに独立してインストールしたOSを、ホストコンピュータのCPUでへ並行して動かすことができます。

上の図でいうと、GuestOS がプロセスを動しているということになります。

なお、ホスト型仮想化とハイパーバイザ型仮想化がある。

ホスト型仮想化は、ホストOS上で動作する仮想化ソフトウェアを利用してVMを管理する方式。
代表例：VirtualBox、VMWare
![image.png](https://qiita-image-store.s3.amazonaws.com/0/280929/28576786-97df-1116-7de8-447b2bdad7ed.png)

ハイパーバイザ型仮想化は、ハードウェア上のハイパーバイザを利用してVMを管理する方式。
代表例：KVM、Heper-V、Xen
![image.png](https://qiita-image-store.s3.amazonaws.com/0/280929/a92210e6-c8ec-77a0-40d6-0dbfa6e90c1c.png)

**一方、コンテナとは？**
ホストとなる1台のコンピュータにインストールされているOSの上に、仮想的なユーザー空間であるコンテナを構築することができる。

上の図でいうと、Docker がプロセスを動かしているイメージです。

通常、1コンテナ1プロセスで使用することとなる。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/280929/c85edeec-e35f-ae54-4ceb-89ab2898bee8.png)


なので、利用する目的としては同じです！

**仮想化の場合**
・ゲストマシンごとにOSをインストールしなければいけない。
・物理的に複数のコンピュータを動かしていることになるため、ゲストマシンの数だけリソースが要求される。
・したがって、ホストコンピュータに対して、メモリやストレージなどのハードウェア環境にそれなりのコストをかけなければいけない。
・個々のゲストマシンの起動にも時間がかかる。

**コンテナの場合**
・OSをインストールする必要がないため、メモリなど大量に消費することがない。
・OS自体を共有しているため、それぞれの環境の起動も仮想化と比べて迅速に行うことができる。
・Dockerエンジンさえあれば基本どこでも動くため、可搬性が高い。
しかし、コンテナにはデメリットもある。。。
・1台のコンピュータで異なる複数のOSを使い分けることができない。
・コンテナが攻撃を受けると、ほかのコンテナにも危険にさらされる。

参考：[Dockerのすべてが5分でわかるまとめ!(コマンド一覧付き)](https://paiza.hatenablog.com/entry/docker_intro)

<br>

#■マイクロサービス（Microservices）#
![image.png](https://qiita-image-store.s3.amazonaws.com/0/280929/68a3a57c-af8e-810f-e8e6-22dc2dbce4df.png)

**モノリス**
一枚岩のアーキテクチャでは、複数の機能を1つのアプリケーションの実行物として構築します。これまでの多くのアプリケーションはこの形で構築されています。例えば、サーバーサイドのWebアプリケーションの実装は、ビジネスロジック、UI、データベースアクセスなどが一体となった実行物としてビルド・配備されます。
これまではこのような一枚岩のアーキテクチャでも問題はなかったのですが、非常に大規模で複雑になるWebサービスを提供する上では、いくつか問題が目立つようになりました。
具体的には、
・ビジネス変化への素早い対応に向け、非常に高い変更頻度が求められる　→　ちょっとした変更でも、全体のリビルドと再配備に時間を必要とするため、変更が容易ではない。
・クライアント数の爆発などの変化に即応する高性能・高可用性が求められる　→　アプリケーションの一部の機能をスケールさせることが必要だったとしても全体を複製しなければいけないため、スケーリングに柔軟性がない。

**マイクロサービス**
マイクロサービスはこれらの問題を解決し、アプリケーションを構成する個々のサービスは独立したプロセスで実行されるように配備します。
それにより、
・きめ細かにスケールできるようになる。
・変更の影響範囲を限りなく小さくすることができる。

マイクロサービスのデメリットとして、分散化するシステム設計が複雑になる、通信オーバヘッドが大きくなる、運用管理が大変である、といったものがあります。

だから、マイクロサービスはコンテナと相性がいい！

新しい機能をどんどん追加して試していきたい。
ダメだったらすぐに切り捨てていきたい。
変化の激しいユーザのニーズに対応したい。
マイクロサービスなら、アプリケーションごとに捨てることができるので、注目されている。

<br>


#■AWSのコンテナ関連サービス#

3 つの役割に分けられる。
![スクリーンショット 2018-11-30 18.56.40.png](https://qiita-image-store.s3.amazonaws.com/0/280929/8100e529-8724-0105-2d13-623e5ef6be21.png)

|分類|説明|
|:------------------------------:|:------------------------------|
|レジストリ|各サーバが実行するコンテナイメージを一元管理する。<br>各サーバに配布するのではなく、必要な時にサーバが取りにいくことで配布する手間がなくなります。|
|コントロールプレーン|コンテナの管理する場所。<br>（どこでコンテナを動かす？デプロイ時にどう配置する？）|
|データプレーン|実際にコンテナが稼働する場所。<br>（コントロールプレーンからの指示に従って起動する。そして、コントロールプレーンへ逆にフィードバックする。|

<br>

↓イメージとしてはこんな感じ。
![スクリーンショット 2018-11-30 19.07.24.png](https://qiita-image-store.s3.amazonaws.com/0/280929/26142004-ab45-0f5f-6a70-7870ab873e11.png)

<br>

では、それぞれのサービスについて具体的に見てみましょう。

**■Amazon Elastic Container Service (ECS)**
[Amazon ECS](https://qiita.com/leomaro7/items/deb114e5ec209a044e5d) に書きました。

**■Amazon Elastic Container Service (EKS)**
[Amazon EKS](https://qiita.com/leomaro7/items/6383e4357a114c48391c) に書きました。

**■AWS Fargate**
[AWS Fargate](https://qiita.com/leomaro7/items/a3edb49d9929dd42cc0d) に書きました。


#■コンテナかサーバレスか#
![スクリーンショット 2022-03-06 15.00.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/c6debe3b-74a7-d03b-c80b-f914f5d1693f.png)