【自分用メモ】ECS Workshop - Cats and Dogs-をやってみた感想

今までコンテナに触れたことがなく、触りたい触りたいと思っていたのですが、なかなか手が出せていませんでした。
そんな時、jp-contents-hubの存在を知り、ECSのハンズオンも多数あることを知りました。

ハンズオンは手順書に記載されている通りにやれば出来てしまうから思考停止でやってしまうことがよくあり、「結局何も身につかないんじゃないか」と思って今まで敬遠していましたが、最近転職活動をしていた中で色々思うところがあり、下記のような結論に達しました。

最初から完璧じゃなくてええねん！！！！！

最初から「何かを身につけたい」とか「完璧に理解しよう」と思って物事を始めると億劫になって何も出来ないor続かない‥というのが私のいつものパターンでした。
なのでまずはハンズオンをやってみて、その過程で心を動かされたことをつらつらと書き留めていくことにしました。
心を動かされたことの定義は「へぇ......」と思ったことです。トリビアの泉のあのボタンが心の中にあるイメージです。
頭で理解したことは結局忘れるけど、「へぇ.....」と思ったことは結構覚えていたり引き出すことができるので、「へぇ....」を書き留めていくのです。
(なので、下記に出てくるheh1、heh2...のhehは、「へぇ」という意味です。)

heh1 DockerFile

Dockerイメージをビルドする時に必要となる設定ファイル。
ハンズオンでは下記のようなDockerFileを使っていた。

FROM句はコンテナのベースとなるイメージを指定する。下記の例ではngixと指定しているが、そうするとDockerイメージをビルドする時にngixを構築してくれるっぽい。実際、ビルドコマンド実行したらngixをインストールしたり設定していた。

FROM nginx
EXPOSE 80
RUN apt-get update -y && \
  apt-get upgrade -y && \
  apt-get install -y curl && \
  cd /tmp && \
  apt-get install awscli -y && \
  rm -rf /tmp/* && \
  rm -rf /var/lib/apt/lists/*
COPY ./default.conf /etc/nginx/conf.d/default.conf
COPY ./index.html /usr/share/nginx/html/index.html
CMD nginx -g "daemon off;"

heh2 ECSは内部的にCloudFormationを使っている。

びっくりしたよね。

heh3 ECSクラスターはコンテナ本体ではない

クラスターとは、サービスの集合体のようなイメージと理解した。
クラスターとかサービスとかタスクとかごちゃごちゃしすぎてよくわからん.....

heh4 タスク定義には複数のコンテナを含むことができる

今まで1タスクに1コンテナだと思ってた

heh5 Fargate起動モードではタスクレベルでCPUとメモリを指定する必要がある

Fargate起動モード=サーバレスを実現したい時に使用するモード....というイメージがあったため
明示的に指定する必要があるとは思っていなかった。
でもよく考えるとLambdaもメモリサイズ指定しなきゃいけなかったし似たようなものなのか？

heh6 「サービスの起動」で初めてコンテナが起動される

タスク定義を指定したり

使用するALBを指定したり

どのALBターゲットグループに追加するか選択したりした

heh7 デプロイサーキットブレーカーという機能が便利そう

サービスデプロイ時に異常発生した場合、正常に動いていたバージョンに自動ロールバックしてくれるっぽい。
最初見た時は、マイクロサービスのサーキットブレーカーパターンを自動で実装してくれるのかと思ってたけどそれとは違うっぽい。

heh8 サービス起動時、FargateはVPCやサブネットを指定する必要がある

タスク定義のネットワークモードが「awsvpc」の時は設定する必要があるらしい。
(Fargateのネットワークモードはawsvpcしか指定出来ない。)

EC2起動モードの時はVPCやサブネットを指定する必要なかったのだが、なぜ？
→タスク定義のネットワークモードがdefaultの場合、自動で設定してくれるっぽい

Classmethod様のECSでEC2インスタンスを利用する際のネットワークモードについて調べてみたが分かりやすそう。

heh9 コンテナとマイクロサービスアーキテクチャの親和性がなんとなくわかった。

今回のハンズオンで作成したアプリケーションは下記のような感じ。

トップ画面

「I love CATS」をクリックするとCATS画面に遷移する

「I love DOGS」をクリックするとDOGS画面に遷移する

トップ画面、DOGS画面、CATS画面はそれぞれ別のコンテナで動いている

つまりトップ画面、DOGS画面、CATS画面がそれぞれ独立したアプリケーションのイメージ。
→従来の3つの画面が一体化したアプリケーションと比べると、改修する場合も全体に手を加える必要はなく、個別のアプリケーションを改修しDockerイメージをビルドし、デプロイすれば良い。

heh10 Autoscalingを設定すると勝手にCloudWatchアラームも設定してくれる

Service Auto Scaleを設定した。
webへのリクエスト数が4000以上になるとスケールアウトするように設定したらCloudWatchアラームも閾値が同条件で自動生成されていた。

heh11 Apache Benchが便利

AutoScaleのテストのため、下記のコマンドを実行した。
今までJmeterしか知らなかったので、気軽にテストしたいならApache Benchで良いなと思った。

ab -c 200 -n 200 -t 30 demogo-alb-1967437663.us-east-1.elb.amazonaws.com/

Apache Bench (ab) は Apache HTTP Server に同梱されている web サーバーの性能テストツールであり、Cloud9 にはデフォルトでインストールされています。c オプションは同時に並列実行する数を指定でき、n オプションは生成するリクエスト数を表しています。また、t オプションはサーバーからのレスポンスの待ち時間を指定しています。

残った疑問点

ECSのAutoScalingタイプには2つあった。Service AutoScaleとCluster AutoScale。違いは何か？
前者はコンテナを増減させる、後者はEC2をインスタンスごと増減させる？
後者についてはDeep Dive on Amazon ECS Cluster Auto Scalingが参考になるらしい。読めたら読もう。

感想

今回のハンズオンをやったことで、特にheh9に記載したコンテナの独立性について実感できたのが良かったように思えます。CI/CDと相性が良い理由もなんとなく分かりましたが、こちらもハンズオンを実施し実感したいです。
でもApp MeshやApp RunnerやLightsailなど、聞いたことはあるが手をつけていないサービスも実践してみたいですね。