Amazon Web Services ブログ
AWS Copilot のご紹介
Amazon Elastic Container Service (Amazon ECS) をご利用中、あるいはご利用を検討されている皆さまへ
本記事でご紹介する AWS Copilot は Amazon ECS CLI の後継に当たるものです。日本はこの ECS CLI を多くのお客様にご利用いただいている地域の1つであることに加え、ECS でのコンテナ実行をもっと簡単に行えるようにしたい、シンプルなワークフローを実現したいというリクエストを多数いただいていることから、本記事を英語記事と同じタイミングで公開することにしました。
Amazon ECS でのコンテナ実行に新たな体験を提供する AWS Copilot の紹介記事です。お楽しみください！
−トリ (皆さまからの Copilot へのフィードバック、心よりお待ちしております)
本記事は Nathan Peck による “Introducing AWS Copilot” を翻訳+加筆修正したものです
Amazon ECS 向けの最初の公式コマンドラインツールは2015年に公開されました。2019年12月には、新たな体験を備えたコマンドラインツールのプレビューリリースを皆さまに紹介しました。お客様がこれまで以上に簡単にアプリケーションを Amazon ECS にデプロイできるよう、ゼロベースでデザインしたものです。そして本日、私たちはこの新たなコマンドラインツールの最新情報と、その新たな名前 – AWS Copilot – を紹介します。
AWS Copilot は、低レイヤなインフラの手動管理から脱却し、自身のアプリケーションとそのライフサイクルにフォーカスしたい ECS ユーザのためにデザインされました。Copilot は、ECS チームのエンジニアや ECS のお客様が作り上げてきたベストプラクティスに基づき、デフォルトでモダンかつプロダクションレディなインフラを構築します。
クラウド上に新しいアプリケーションを設計し始めるとき、多くの方は各 AWS サービスを示すいくつかの箱とそれらを繋ぐ線からなる構成図をホワイトボードもしくは頭の中でデザインするところから始めるでしょう。しかし実際にそのアーキテクチャを構築するタイミングになると、構成図には含めていなかった多くのクラウドコンポーネントについて考えることになります。VPC サブネットにロードバランサ、デプロイのためのパイプラインに加えて、ステートフルなアプリケーションの場合はストレージのことも考えるかもしれません。Copilot はこのようなアーキテクチャ上の細部をハンドリングします。あなたはコンテナとアプリケーションを用意し、可用性を考慮した構成やロードバランサの構築や設定などは Copilot に任せてしまえば良いのです。コードリポジトリに新しいコミットをプッシュするたびに最新バージョンのアプリケーションを自動でデプロイしたいですか？Copilot はそんなデプロイパイプラインも作ってくれます。
つまり、Copilot を使うことで、アイデアから実装までをより早く、プロダクションレディな形で構築されたインフラに自信をもってデプロイできるようになるわけです。
Copilot のインストール
GitHub から最新のリリースバイナリをダウンロードしてくることで Copilot をインストールできます。例えば macOS ユーザーの場合は次のようなコマンドでインストール可能です:
curl -Lo /usr/local/bin/copilot https://github.com/aws/copilot-cli/releases/download/v0.1.0/copilot-darwin-v0.1.0 && \
chmod +x /usr/local/bin/copilot && \
copilot --helpCopilot は AWS CLI と同じ認証情報を利用しますので、Copilot をインストールした環境ですでに AWS CLI を設定・利用したことがある場合はそのまま Copilot の利用を開始できます。
(もしまだ AWS CLI のインストールや設定を行ったことがない場合は、こちらのドキュメントを参考にしてください。AWS CLI のインストールが済んだら aws configure コマンドを実行して設定を行うことも忘れないようご注意ください。)
また、Copilot を利用する環境には Docker もインストールされている必要があります。Copilot はあなたのアプリケーションのビルドとパッケージングを行う際に Docker を利用します。
Copilot のコンセプト
まずは Copilot のハイレベルなコマンド群を見ていきましょう:
Copilot には、3つの中心となる概念が存在します:
- Application (アプリケーション) – 「アプリケーション」はシステムの構成要素をグルーピングするメカニズムです。例えばコンウェイの法則に沿って組織内に複数のチームがいる場合、あなたのシステムは複数の Copilot アプリケーションから成るでしょう。あなたの組織がまだ比較的小さく、1つの開発チームで全てを担当できている場合、1つもしくは複数のサービスから構成される単一の Copilot アプリケーションで整理できると言えます。しかし、もし複数のチームがそれぞれのシステムに責務を持ち、チームを跨いだやり取りが少ないようなケースでは、それぞれのチームが Copilot アプリケーションを1つ持つ形が望ましいでしょう。
- Environment (環境) – 「環境」は、アプリケーションのデプロイメントのステージを表現します。例えばあなたはお客様に影響を与えずにアプリケーションをテストするために「QA 環境」にアプリケーションをデプロイするでしょう。QA 環境で意図した通りに動くことが確認できたら、次にそのアプリケーションを「本番環境」にデプロイする、というイメージです。
- Service (サービス) – 「サービス」は、あるコンテナの中で実行されている常駐型のプロセスのことを指します。1つのアプリケーションは1つ以上のサービスから構成されます。もしあなたがモノリシックなアーキテクチャを選択している場合1つのアプリケーションに1つのサービス、より分散されたアーキテクチャを選択している場合は1つのアプリケーションに複数のサービスが含まれることになります。例えば、インターネットからアクセス可能なロードバランサを持つ「website」サービスと、サービスディスカバリを経由したインターナルな通信でのみ利用可能な「API」サービス、キューを利用したジョブである「background worker」サービスがあるとします。これら3つのサービスをコンポーネントとしてまとめたものが1つのアプリケーションとなります。
初めてのコンテナアプリケーションを動かしてみよう
コンテナアプリケーションの最初の1歩は Dockerfile から始まります。Dockerfile とは、コンテナの中でどのようなプログラムを動かすか、そのアプリケーションの動作に必要な依存物やファイルが何かを記述するための小さなファイルです。今回の例ではシンプルかつ静的な NGINX ウェブサーバーをデモアプリケーションとして利用することにしましょう。Dockerifle は次のような中身になります:
FROM nginx:alpine
EXPOSE 80
COPY . /usr/share/nginx/htmlこの Dockerfile は、すでにその中に NGINX を持っている既存のコンテナイメージを使い、そこにいくつかの HTML ファイルを追加して新しいコンテナイメージを作ることを Docker に指示しています。2行目には EXPOSE という命令文も含めていますが、これによって Copilot はどのポート番号をロードバランサ経由で世界に公開すれば良いかを知ることができます。
次に、copilot init コマンドをアプリケーションディレクトリで実行します:
Copilot はコマンドを実行したディレクトリに存在する Dockerfile を自動的に検出します。そして、例えばアプリケーションの名前(上記のスクリーンキャプチャでは “nyan” にしました)をどうするかなど、いくつかの質問をしてきます。それが済むと Copilot はサービスをデプロイするための環境をクラウド上に作ります。コンテナのビルドとクラウド側へのプッシュも済ませ、最終的にはアプリケーションにアクセスするための URL を表示してくれます。
それではこの URL をブラウザで開いてみましょう:
ブラウザで何度かリロードしてみたあと、次に示す Copilot のコマンドでこのアプリケーションのログを見ることができます:
copilot svc logs --follow今回のケースでは表示されたログは単なる NGINX のアクセスログですが、自身で実装したアプリケーションにおいて例えばデバッグ用に出力したいメッセージのようなものがある場合は、標準出力に送ることでここにログとして表示されます。
本番環境を構築する
はじめて Copilot でアプリケーションをデプロイするときは、1つの小さなコンテナを Fargate にデプロイする Copilot のデフォルト設定を利用するところから始めるでしょう。このデフォルト設定は料金が低くなるように最適化されており、開発目的としては理想的と言えます。しかし、これではまだ本番環境のトラフィックに対する準備はできていません。
本番環境のトラフィックを捌く準備をするために、新しい「環境」を1つセットアップします:
copilot env init
本番環境にサービスをデプロイする前に、この環境用の設定(マニフェスト)に少しだけ変更を加えます。本記事でお見せしているアプリケーションの名前は nyan にしましたので、マニフェストファイルは ./copilot/nyan/manifest.yaml です。
このファイルでは、例えばポート番号やアプリケーションが必要とする CPU/メモリの割当量、アプリケーションをいくつ複製して動かすか、といったすべてのデフォルト設定が宣言されています。本番環境ではこれらの設定を変更したいため、以下をマニフェストファイルに追記します:
environments:
production:
count: 2
cpu: 1024
memory: 2048この設定により、“production” 環境にアプリケーションをデプロイする際はアプリケーションを2つ並列で動かし、それぞれに 1 vCPU と 2GB のメモリを割り当てることを Copilot に対して伝えることができます。
次のコマンドでサービスを本番環境にデプロイできます:
copilot svc deploy --env production
これで、アプリケーションを複数のアベイラビリティゾーンに分散して、それぞれのコンテナにはより多い CPU とメモリを割り当てた形で本番環境へのデプロイができました。ApacheBench を使ってこのアプリケーションがどれくらいのドラフィックを捌くことができるか見てみます:
ab -n 5000 -c 25 http://nyan-Publi-WI97060DJP1B-2041999651.us-east-1.elb.amazonaws.comこのコマンドで ApacheBench を使って同時に25並列で合計5000のリクエストをデプロイ済みのアプリケーションに対してに送ることができます。
353 リクエスト/秒、レスポンスタイムは p99 では 165 ms、平均では 70ms/リクエストという結果になりました。悪くないですね。
これより多くのトラフィックを処理する必要があるとなった場合は、このアプリケーションのマニフェストファイルに記載した並列で走らせる数や CPU 割り当てを増やし、copilot svc deploy コマンドを実行して再度デプロイすることができます。
まとめ
ここまで見てきた通り、Copilot はプロダクションレディなサービスを少しのコマンドでデプロイできるようにデザインされています。あなたは Dockerfile を用意し、残されたビルドやプッシュ、AWS 上でのコンテナの起動は Copilot に任せることができます。
ここで紹介したものは、Copilot のパワフルな機能のほんの最初の部分だけです。Copilot を使うことで、例えば次のようなことを簡単に実現できます:
- CI/CD パイプラインを自動的に構築し、Git リポジトリへのコードのプッシュだけでデプロイできるようにする
- (Coming soon) S3 バケット、NoSQL/SQL データベースを含む、ストレージのセットアップ
将来の記事ではこれらのパワフルな機能にさらに Deep Dive していきます。Copilot へのフィードバック、機能リクエストをぜひ Copilot プロジェクトの GitHub リポジトリにお寄せください。プルリクエストも大歓迎です！