AWSの勉強の過程でFargateに関して調べてみると、
Fargate (公式AWSより)
AWS Fargate は、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) の両方で動作する、コンテナ向けサーバーレスコンピューティングエンジンです。Fargate を使用すると、アプリケーションの構築に簡単に集中することができます。Fargate ではサーバーのプロビジョンと管理が不要となり、アプリケーションごとにリソースを指定してその分のみ料金を支払うことができ、設計段階からのアプリケーション分離によりセキュリティを強化します。
うーん、これって自分が思っていたDockerとかとどう違うの？(当方、初学者)
って疑問に思ったので、調べてみた結果、「コンテナ」、「Docker」、「コンテナオーケストレーション」、「Fargate」の4つに分けて自分なりに整理・説明してみたいと思います。
- そもそもコンテナって？
- Docker
- コンテナオーケストレーションとは
- ECSとは
- Fargateとは
- Fargateのメリット
- Fargateよりも EC2の方が良いケース
- まとめ
- Amazon公式サイトによるコンテナ移行へのステップ
まず、 Dockerとコンテナの違いから曖昧だったので、それぞれの違いから。
そもそもコンテナって？
アプリケーションの実行に必要な依存物を全てコンテナの中にパッケージングし、このパッケージをそのままデリバリーすることで、開発環境から本番環境まで同一の環境(コンテナ)でアプリケーションを動作させる事ができるようになる。
1つのアプリを違うエンジニア同士で開発・使用する際に「必要なパッケージが入ってない」、「Rubyや、railsなどのフレームワークのバージョンが違う。整合性が取れていない」といった事が起きないようにするための手段の１つ。
以上がコンテナの説明。
つまり、違うエンジニア同士でアプリケーションを実行する際などに、実行環境の違いなどでエラーなどが起きないように、開発環境から本番環境まで同一の環境にできるようパッケージングしたもの。
という解釈でいいのかな。と思います。
Docker
パッケージングされたコンテナを実行するツールとして、デファクトスタンダードとなっているのがDocker。
Docker Engineが動いている環境であればどこでも docker pull やdocker runといったコマンドでコンテナを実行する事ができる。
ちなみに、Docker Engine の管理する範囲は単一のホストマシン上でのコンテナの動作。
それ以外の例えばコンテナのオートスケーリングや複数のホストマシンにまたがるような配置、ローリングアップデートなどは別の仕組みとして実装する必要がある。
上記の説明にある通り、Dockerはあくまでもコンテナの実行ツールであり、単一のホストマシン上でしか動作しないみたい。
複数ホストマシンにまたがるような配置などは「コンテナオーケストレーション」などを利用しなければいけないらしい。
コンテナオーケストレーションとは
ECSやEKSといったAmazonサービスがそれにあたる。
複数のホストマシンにまたがるコンテナの配置やコンテナのアップデート、ロードバランサーへの紐付けなどを管理してくれる。
ユーザーはこれらのサービスのAPI経由で変更後の状態を指示し、オーケストレーションツールはその状態になるように、あるいは維持するように動作する。
これを「宣言的デプロイメント」と呼ぶ。
ECSとは
クラスターでDockerコンテナを実行・停止を可能にできるサービス。
EC２インスタンスを生成し、そこにDockerコンテナを配置した後に利用する事ができる。
コンテナが動くホストマシンではOSが動いているし、Dockerの利用にはDocker Engineが動いている必要がある。
オーケストレーションツール利用の際はECSやkubernetesなども動いている必要がある。これらへのパッチ当てやバージョンアップも以前として必要。
またコンテナをスケールさせ数を増やす際はコンテナの実行環境となるホストマシンを増やす必要がある。
それらを解決するためのものがFargate
Fargateとは
ECSでコンテナを実行する際の起動タイプのうちの1つ。
ECSで、EC2起動タイプとFargate起動タイプから選択する事ができる。
EC2で起動した場合
「どのホストマシン」で「どのコンテナ」を「いくつ起動する」かなどのハンドリングはオーケストレーションツールであるECSから行う事ができるが、各ホストマシンの管理・運用業務は依然として残る。
Fargateで起動
ホストマシンを管理・運用する必要がなく、コンテナを実行する事ができる。
Fargateのメリット
イプの選定、必要な総台数など)
シームレスなスケーリング
負荷やジョブキューの数に応じてコンテナの数をオートスケールする。
ホストマシンの管理が不要
通常であれば、OSやミドルウェアのバージョンアップやセキュリティパッチの適用などをやらないといけない。が、Fargateであればこれらは必要ない。
Fargateよりも EC2の方が良いケース
- リザーブドインスタンス/スポットインスタンスを利用する場合
- GPUを利用する場合(Fargateでは現在はCPUリソースのみ利用可能)
- EKS/Kubernetesを使いたい場合
まとめ
えーと、
アプリケーションを実行・開発する際に環境の違いなどで齟齬が起きないように、依存物をまるっとパッケージングしたものが「コンテナ」
そのコンテナを実行する代表ツールが「Docker」
ただ、Dockerは単一のホストマシンでしか動作しないので、複数のホストマシンにまたがるコンテナの配置を可能にし、コンテナのアップデートやロードバランサーへの紐付けなども管理してくれるのが「コンテナオーケストレーション」(ECSやEKS)
さらに、ホストマシンの管理まで行ってくれるのがFargate
という解釈でいいのかな、と思います。
変更・追加ある場合は順次更新していきます。
Amazon公式サイトによるコンテナ移行へのステップ
- コンテナ化するアプリケーションを選定
- コンテナでアプリケーションが動くように適した設計にする
重要なことはステートレスにアプリケーションを設計すること。具体的にはセッション情報をファイルやメモリに持たず外部のAmazon ElastiCacheに置いたり、画像ファイルをローカルのファイルシステムでなくS3に配置するなど。
- Dockerイメージをビルドする
Dockerイメージをビルドするには、どのようなイメージを作成するかという設計図が必要。
最も一般的なのがDockerfileの利用。
Dockerfileにより構成をコード化することで、docker buildコマンドでDockerイメージを安定的にビルドできるようになる。
- イメージレジストリに登録する
Docker Hubや ECRといったイメージレジストリにDockerイメージを登録する。
Dockerイメージには一意なURIが振られ、本番環境等で実行する際はこのURIを指定することになる。
- 本番環境の構成を考え、実装する(オーケストレーションツールなどの利用)
- CI/CDのパイプラインを実装する
必須ではないものの、コンテナ利用に伴い発生するDockerイメージのビルド等の手間は自動化していく事が望ましい。
参考にさせて頂いたサイト
https://business.ntt-east.co.jp/content/cloudsolution/column-171.html
https://aws.amazon.com/jp/blogs/startup/techblog-container-introduction/
