AWS Partner: Containers on AWS (Technical)で得た学び

seshimo.s

はじめに

10/2に行われたAPN向けのトレーニングプログラムである、AWSのコンテナサービスの入門コースを受講しました。本記事では、今回のトレーニングプログラムを通して学んだことを共有いたします。
（受講には事前にCisco Webex Meetingというアプリをインストールする必要がありますが、案内に従ってインストールすれば特に問題ないと思います。）

学習した技術の概要

  • Docker
    • アプリケーションとその依存関係を軽量なコンテナにパッケージ化するオープンソースのプラットフォームである。依存関係をパッケージ化し、どの環境でも一貫して動作させることが可能になる。
  • ECS
    • Dockerコンテナを簡単に実行・管理できるフルマネージド型のサービスである。コンテナのデプロイやスケーリングを自動化し、EC2インスタンスやFargateと呼ばれるサーバーレスコンピューティング環境で動かすことができる。
  • EKS
    • AWSが提供するマネージド型のKubernetesサービスで、ECSと同様にコンテナのオーケストレーションを目的としたサービスである。ECSと異なる点として、ECSではRUNなどの命令形コマンドが用いられるが、EKSでは宣言型のアプローチをとっている。Kubernetesは複雑なサービスであるため、本記事での紹介は簡略なものとする。

コンテナサービスを利用する背景

濱本さんが書かれた「AWS Partner: Containers on AWSを受けてきた」をご参照ください。

DockerFileのベストプラクティス

石原さんが書かれた「DockerFileのベストプラクティス」をご参照ください。

ECSについて

ECSの概略

Dockerコンテナを簡単に実行・管理できるフルマネージド型のサービスで、ECSはクラスター、サービス、タスク、コンテナで構成されている。
クラスターはアプリケーションや環境ごとの単位として用いられる。コンテナを起動する際には、タスク定義を用いてどんなコンテナを起動したいか定義する。サービスはロードバランサーを割り当てる単位みたいなもので、タスクをまとめている単位である。

ざっくり、クラスタ＞サービス＞タスク＞コンテナの順番で包含関係が成り立っている。
また、起動タイプにはそれぞれEC2インスタンスとFargateというものを指定することができる。

EC2インスタンスとFargateの違い

EC2インスタンスはいろいろなことをカスタマイズできる反面、メンテナンスの手間がかかってしまう。

Fargateを利用すると、コンテナをサーバーレス運用モデルで実行可能になる。デメリットとしては、コスト面がやや割高であることと、カスタマイズ性が損なわれてしまうことである。

どちらで構築するか検討する際は、まずFargateで構築できるかを考えるのが良い。これは、スケーリングの細かいチューニングなどが必要になるパターンが少ないためである。

Fargateの料金はタスクに割り当てたCPUとメモリ、起動時間で決定される。

タスク配置の構造

タスクの配置はスケジューリングという言葉で置き換えられる。スケジューリングという言葉に惑わされるが、時間とは関係ない。作成したタスク定義を基に、実際にコンテナをどのようにクラスター内に配置するかを決定するプロセスを指している。

  1. タスクの要件
    • 必要なCPU、メモリ、ネットワークに関する要件を評価
  2. カスタムの制約
    • AZ、インスタンスタイプ、AMIなどの細かい制約をつけられる。
  3. 配置戦略
    • スプレッド：なるべく複数のAZやインスタンスに分散して配置する。可用性が高まる。
    • ビンパック：なるべく一か所に束ねる。一つのインスタンスのメモリを使い切るように配置する。
    • ホストごとに一つのタスク：一つのインスタンス上に一つのタスク
    • ランダム：ランダム
  4. 配置対象の決定
    • 配置する最終的なコンテナインスタンスが決定される。

例１）

aws ecs run-task --cluster ecs-demo --task-definition myapp --count 5
--placement-contraints type="memberOf", expression="(attribute:ecs.instance-type
== t2.small or attribute:ecs.instance-type == t2.medium) and attribute: ecs.availability-zone
!= us-east-1d"

これはカスタム制約について記述している。5個のタスクを起動していて、インスタンスタイプはt2smallかt2mediumを指定しており、AZがus-east-1dでないものを起動している。

例２）

aws ecs run-task --cluster ecs-demo --task-definition myapp --count 9
--placement-strategy type="spread", field="attribute:ecs.availability-zone"
type="binpack", field="memory"

これは配置戦略について記述している。9つのタスクを起動し、スプレッドで配置している。基準はfieldで指定している。なお、spreadとbinbackは併用可能であり、上のコードでもspreadとbinpackが共存している。
この記述だと、各AZのインスタンスにコンテナを分散し、AZ内では一か所のインスタンスに集約されるよう配置される。

ECR

ECRは、Dockerコンテナイメージを安全に保存、管理、デプロイするためのサービスである。

ECRにローカルからアップロードする方法は、マネジメントコンソール上での”プッシュコマンドを表示”で教えてくれる。

なお、プッシュコマンドではlatestのコマンドが記載されているが、普遍性を担保するためにバージョン指定したものに変更するのが好ましい。

サービス選定について

  1. 大前提として、ジョブに適したツールを使う。
  2. 多くの場合、まずFargateを使用するのが理想的である。
  3. ECSは、コンテナ以外のワークロードがあるお客様に最適である。kuvernetesは高機能ではあるが、学習コストが高い。
  4. EKSは、すでにkuvernetesを使用しているお客様や、OSSを好むAWSのお客様に最適である。

まとめ

docker, ECS, EKSなどのコンテナ技術に関して広く学ぶことができるコースでした。特にECSに関しては使われる機会も多いと思われるため、引き続き学習を続けていきたいと思います。

Last modified: 2024-10-03

Author