Zenn
Open19

AWSとDocker入門

AWS
Docker
sunasuna123gosunasuna123go

Dockerの基本用語

Dockerfile

イメージを構築するためのテキストファイル。アプリケーションに必要なライブラリとかを書く。

イメージ

コンテナを実行するために必要なビルド済みのパッケージ。

コンテナ

イメージから作成された実行主体。

sunasuna123gosunasuna123go

オーケストラとは

ビジネスの拡大に伴って複数のコンテナが連携しているとき、これらは単一のホストではなくて、複数のホストから構成された「クラスター構成」を取ることが多い。

クラスター構成は複数ホストで稼働しているため、リクエストの負荷分散やダウンタイムの最小化について考えないといけない。

オーケストラはコンテナ群を管理するためのサービスで、これらの問題を解決できる。

有名なコンテナオーケストレータにKubernetesやAmazon ECS、Amazon EKSがある。

オーケストラが解決できること

  • コンテナの配置管理
  • コンテナの負荷分散
  • コンテナの状態監視と自動復旧
  • コンテナのデプロイ

コンテナの配置管理

クラスター構成でコンテナを新規起動させるときは、ホストへの負荷が均等になるように分散配置させたい。また特定のホストがダウンしてコンテナを復旧させたいとき、どの正常稼働しているホストを代わりに起動させるかを考えないといけない。オーケストラは配置管理を自動制御できるから、これらを解決できる👍

コンテナの負荷分散

処理量に応じてリクエストを分散させることで、システムのパフォーマンスを上げることができる。オーケストラを使うと、複数ホストに分散配置されているコンテナに対して適切に処理を振り分けることができる👍

コンテナの状態監視と自動復旧

オーケストラはコンテナの状態を監視して、異常があったときも事前に設定した数のコンテナを維持させることができる👍

コンテナのデプロイ

アプリケーションをバージョンを上げる際に、オーケストラを使えば、既に起動しているコンテナを止めつつ、新しいコンテナに置き換えることかできる👍アプリケーションの稼働を正常に保ちつつ、コンテナの新旧を自動的に入れ替えることかできる。

sunasuna123gosunasuna123go

AWSが提供するコンテナを管理する機能

コントロールプレーンとも言う。以下の2つが選択肢。

  • Amazon Elastic Container Service (ECS)
  • Amazon Elastic Kubernetes Service (EKS)

意識したいのは、これらのサービスはあくまで単なるオーケストレーションサービスであって、コンテナの実行環境のサービスではないというところ。

sunasuna123gosunasuna123go

ECS用語の簡単な説明

先に結論を書くと、以下のような構成になっている。

クラスター　＞　サービス　＞　タスク(or タスク定義)　＞　コンテナ

タスク

コンテナが動作するコンポーネントのこと。タスクは1つ以上のコンテナから構成されるアプリケーションの実行単位。

タスク定義

タスクを作成する場所。JSON形式で書かれる。ここではデプロイするコンテナイメージやタスクに割り当てるリソース、CloudWatch Logsの出力先とかの色々を指定する。

サービス

指定した数だけタスクを維持するスケジューラ。『オーケストラのコア機能にあたる要素』らしい。タスク定義をベースに新しいタスクを作成して指定したタスク数を維持する。

クラスター

サービスとタスクを実行する論理グループ。

sunasuna123gosunasuna123go

AWSが提供するコンテナが実際に稼働するリソース環境

データプレーンとも言う。以下の2つが選択肢。

  • Amazon Elastic Compute Cloud (EC2)
  • AWS Fargate
sunasuna123gosunasuna123go

EC2の解説

AWSで仮想マシンを利用できるサービス。AWS内では仮想マシンのことをインスタンスと呼ぶ。設定でCPUコア数やメモリ容量、ストレージなどのスペックを変更できる。

実際に起動したいときは、AWSマネジメントコンソールからスペックを選択して数クリックするだけでサーバーが立ち上がる。

EC2はECSやEKSで動かすコンテナのデータプレーンとしても利用できる。要件に合わせて柔軟に設定を変更することができるから、EC2がデータプレーンとして使用されるケースは多い。

sunasuna123gosunasuna123go

Fargateの解説

Fargateはコンテナ向けのサーバーレスコンピューティングエンジンであり、AWSフルマネージドなデータプレーである。ECSとEKSの両方で動作する。

コンテナ向けだからFargate単体では利用できなくて、ECSやEKSと一緒に使う。

「フルマネージド」の簡単な説明

「めちゃ面倒見てくれる」って感じ。
「マネージドサービス」の時点でサーバーの管理を代行してくれてたのに、更にそれに「フル」が付いてセキュリティ監視や障害対応とかもしてくれるようになった。

sunasuna123gosunasuna123go

Fargateがもたらした変化

Fargateがフルマネージドなサービスであるから、今までサーバーのスケーリングやパッチ処理などホスト管理にまつわる手間を省くことができるようになった。これのお陰で、OSインフラの管理負荷が減ってアプリケーションの開発に注力できるようになり、延いてはビジネス競争力を上げることができるようになった。

その代わりにEC2を使うよりも価格が高く（少しずつ改善されてはいる）、またフルマネージドであるが故に当然ながらAWS使用者はOSに直接介入することができない。

sunasuna123gosunasuna123go

AWS上でコンテナイメージを格納するリポジトリサービス

コンテナのイメージを格納するサービスがAWSにはあって、それがAmazon Elastic Container Registry (ECR)である。これを使ってコンテナイメージを簡単に保存・管理できるようになる。

ECRはECSと容易に連携ができるから、新しいコンテナをECSで立ち上げるときにコンテナイメージをECRから取得することができる。

sunasuna123gosunasuna123go

その他のコンテナレジストリ

王道のコンテナレジストリとしてDocker Hubがある。昔はECRがプライベートリポジトリしか対応してなかったからDocker Hubを使う人が多かったけど、2022年12月にECRでパブリックリポジトリが一般提供されて、Docker Hub等を介さずにAWSだけで処理を完了することができるようになった。

sunasuna123gosunasuna123go

アーキテクチャを構成する

上記でコントロールプレーンとデータプレーンについて長々と説明したのには理由があって、これらは用途によって組み合わせを選ぶことができるからだ。具体的には以下の4通りの組み合わせができる。

ECS EKS
EC2 ECS on EC2 EKS on EC2
Fargate ECS on Fargate EKS on Fargate
sunasuna123gosunasuna123go

各アーキテクチャのPros & Cons

それぞれのアーキテクチャのメリット&デメリットを以下の4つの観点で比較する。

  • 使用料や運用、学習などあらゆる面でのコスト
  • デプロイの速さや水平&垂直スケーリングの面での拡張性
  • 意図したとおりにはワークロードが動くかや復旧計画の面での信頼性
  • エンジニアの人材確保の面でのエンジニアリング観点

結論：ECS on Fargate

  • 今は勉強コストを減らして、なる早でアプリをリリースしたい
    • コントロールプレーンについて、Kubernetesを勉強しないといけないので消去法でECS
    • データプレーンについて、AWSがフルマネージしてくれるのでFargate

上記の理由から、比較するまでもなく自動的にECS on Fargateを採用することにします。

ただ、この組み合わせにもたくさんのデメリットがあるから、ゆくゆくはECSやKubernetesも勉強したいとは思う。

sunasuna123gosunasuna123go

挙げられているデメリット

  • 使用量が割高
  • 複数の理由でデプロイが遅め
  • ひと昔前までは障害時の調査が困難だった（最近はAmazon ECS Execなるものでコンテナに対してシェルが打てるようになったから、ある程度は改善された）
sunasuna123gosunasuna123go

AWSでするCI/CD

  • 同じ手順になりがちなビルドやテスト、デプロイ作業の自動化は開発サイクル高速化の手段
  • CI/CDを用いることで、変更を自動でリリースできるようになり、今までビルドやデプロイに費やしていた時間をアプリケーション開発にら集中させることができる
  • 一般的にコンテナはCI/CDとの相性がよい
sunasuna123gosunasuna123go

環境を分ける

  • プロダクション環境とは別にステージング環境を設けて品質担保したい
  • ステージング環境とは別に開発環境を設けて開発速度を上げたい
  • プロダクション環境のCI/CDパイプラインを他の環境から分離してガバナンス強化したい
  • ステージング環境でビルド&テスト済みのコンテナイメージのちをプロダクション環境にデプロイして動作品質を維持したい