Docker on AWS: AWSのコンテナ関連サービスの選定例の紹介

本記事ではこれからAWS上でDockerコンテナを活用される方向けに、AWSのコンテナ関連サービスのどれを選択すると良いかの一例を紹介します。前提としては、example.com社の技術者Aさんが、自社のWebサービスをAWS上で構築するにあたって構成を決めるために、AWSのソリューションアーキテクト(SA)に相談するという流れの記事になります。AWSのどのサービスを使うかのご参考に是非ご覧ください。※こちらの選定はあくまで一例です。要件によっては選択すべきAWSのサービスが異なる点、予めご了承ください。

Dockerコンテナの基礎については以下をご覧ください。

https://thinkwithwp.com/jp/docker/

AWS Black Belt Online Seminar 2017 Docker on AWS

SA: 本日は個別相談会にお越し頂きありがとうございます。AWS上でDockerをご利用になりたいとのことですが、まずはお客様のどのようなサービスでDockerをご利用になりたいかお聞かせいただけますか？

Aさん：はい。イベント申し込み用のWebサービスを新規で構築することを検討しています。とても人気のあるイベントも取り扱いますので、申し込み開始と同時にアクセスが急増することも見込んでいます。

SA: なるほど。現時点でお考えの構成があればお聞かせください。

Aさん：はい、現時点で考えている構成が以下になります。

Aさん：上から順番に説明しますと、ユーザーはイベントに申し込むためにインターネット越しに本サイトにアクセスします。弊社のドメインであるexample.comのドメイン名の名前解決によりAmazon CloudFront（以下、CloudFront）のエンドポイントの接続先IPアドレスを取得して、CloudFrontにアクセスします。CloudFrontでは複数のオリジンを設定します。画像などの静的コンテンツはAmazon Simple Storage Service (以下、S3)に格納し、こちらを一つのオリジンとします。静的コンテンツはCloudFrontで一定期間キャッシュするようにします。動的コンテンツ配信用にもう一つのオリジンを設定しますが、ここのWebアプリケーションサーバ部分をDockerコンテナで構築したいと考えています。ここが相談したいポイントです。イベント情報やユーザー情報はAmazon DynamoDB（以下、DynamoDB）に格納します。

SA: データベースにDynamoDBをご検討されているのは良いですね。こちらは一時的な書き込み増に対応するためにDynamoDBをご検討されているのですか？

Aさん：はい、イベントへの応募が事前に決められた時刻に開始されるのですが、多くのユーザー様にイベント申し込みが同時に入ると、データベースへの書き込みが急増することが想定されます。DynamoDBであれば、書き込みキャパシティユニットの値を大きくすることで、同時に受け付けられる書き込みリクエストを増やせるので、DynamoDBが良いかと考えています。

SA: よくご検討されていますね。

Aさん：ありがとうございます。そこで今回ご相談したいWebアプリケーションサーバーレイヤーなのですが、Dockerコンテナで構築したいと考えています。理由は、Dockerコンテナであれば、開発からテスト、本番環境まで一貫して同じDockerコンテナイメージを使うことができるためです。ですが、DockerコンテナをAWS上で利用するにあたっては、どのような構成にすると良いかが知りたいです。

SA: はい、まずは基本的なところからご説明しますが、Dockerコンテナ自体はAmazon EC2の例えばAmazon LinuxベースのインスタンスにDockerをインストールして、”docker run (docker container run)”コマンドを実行すれば簡単にDockerコンテナを実行できます。勿論ご自身でこの形で構築されるのでも構いませんが、今回ご検討されているWebサービスのように高いスケーラビリティや可用性が求められたり、また管理コストも考慮すると、AWSが提供するマネージドサービスをご検討頂くことをお薦めしたいですね。

Aさん：Dockerコンテナに関連するAWSのマネージドサービスにはどのようなものがあるのでしょうか？

SA：図をご覧ください。いくつかありますが、まずはDockerコンテナの起動元イメージの置き場所となるレジストリの役割を果たすAmazon Elastic Container Registry (以下、ECR)です。アプリケーションのコードを含むコンテナイメージをレジストリにpushして、実行時にレジストリからpullして起動します。そのため、レジストリには高い可用性やスケーラビリティが求められるので、自前で構築すると管理コストがかかってきます。その点でECRはスケーラブルで高い可用性を持っているので、こちらだけをまずはご利用頂くケースもありますね。

SA：次に紹介するのが、コンテナの管理を行う役割を持つコントロールプレーンに分類されるAmazon Elastic Container Service(以下ECS)とAmazon Elastic Container Service for Kubernetes (以下EKS)です。どこでコンテナを動かすのか？コンテナの生死状態は？いつ止めるのか？デプロイ時にどうコンテナを配置するのか？を管理します。

SA: そしてもう一つ、実際にコンテナが稼働する場所(データプレーン)としてAWS Fargate（以下Fargate）とEC2があります。コントロールプレーンからの指示に従ってデータプレーン上にコンテナが起動されます。

Aさん：コンテナの管理を行うコントロールプレーンとしてECS, EKS、そして実際にコンテナが稼働するデータプレーンとしてはFargateとEC2があるのですね。これらはどのように選ぶと良いでしょうか？

SA: 一つの考え方としてはデータプレーンを先に決めてしまう方法です。例えばDockerコンテナが稼働するデータプレーンの管理をご自身で行いたいですか？ここで言うデータプレーンの管理には次の2点が含まれます。1点目はDockerコンテナが動くEC2インスタンスは、これまで同様に脆弱性対策のためのパッチ適用やインスタンスの状態異常を検知、改善の処置を行う必要があることです。2点目は、Dockerコンテナレイヤーの管理・運用も行う必要があることです。つまり2重で管理・運用が必要になります。

Aさん：なるほど。弊社はインフラを管理するエンジニアが少ないので、できる限りデータプレーンの管理・運用負荷を軽減できると良いのですが・・・。

SA：データプレーンの管理・運用負荷を軽減したいのであれば、Fargateをお薦めします。以下の図をご覧ください。

SA：こちらはコンテナの実行基盤ですが、物理サーバ、ハイパーバイザー、ゲストOS、Docker EngineといくつものLayerの上でコンテナは動きます。データプレーンにFargateを選択した場合は物理サーバからDocker EngineまでをAWSが管理を行い、ユーザはコンテナの管理だけに集中できます。

Aさん：Fargate、いいですね。Fargateを使えば、イベント申し込みのアクセスが急増した場合でも、データプレーンのスケーリングは気にしなくても良いでしょうか？

SA: Fargateを使えばデータプレーンのスケーリングは考慮する必要はないですが、想定するピーク時のアクセス数を想定して、負荷テストを行って、求めるパフォーマンスが出るかは是非確認してみてください。場合によっては、データプレーンにEC2を選んだ方が速度が向上できることもあります。EC2を選ぶ場合はユーザー側でインスタンスタイプを選べます。選ぶインスタンスタイプによるところもあるので、EC2を使う場合でも負荷テストをすることが推奨ですね。

Aさん：わかりました。負荷テストを実施するようにします。Fargateを利用すると、コントロールプレーンはどちらを選択すればよいですか？

SA: Fargateを使うのであれば、コントロールプレーンはECSの一択です。Fargateは2019年2月現時点ではEKSには対応していません。

Aさん：ご参考までに、EKSを使うのはどのような時になるのでしょうか？

SA: EKSはマネージドのKubernetesサービスです。Kubernetes独自の機能を使いたい場合で、EKSのメリットを享受したい場合に該当します。EKSはKubernetesコントロールプレーンをインストールして操作する必要がなく、複数のAWSアベイラビリティゾーンをまたいでプロビジョン、スケールして、高可用性と耐障害性を達成します。EKSは異常なコントロールプレーンノードを自動的に検出して置き換え、コントロールプレーンへのパッチを適用します。多くのAWSサービスと統合されており、ユーザーのアプリケーションに拡張性とセキュリティを提供できます。具体的にはElastic Load Balancingによる負荷分散やAWS Identity and Access Management(IAM)による認証、Amazon Virtual Private Cloud(VPC)による分離、AWS PrivateLinkによるプライベートネットワークへのアクセス、AWS CloudTrailによるログ確認などがあります。ご注意頂きたい点は、EKSを使うにあたってKubernetes自体の知識も求められる点です。Kubernetesを理解した上でEKSの特性を理解頂く必要があります。

Aさん：わかりました。今回はFargateでまずは構築して負荷テストをしてみて、求めるパフォーマンスが出せるか判断したいと思います。もう1点質問ですが、Fargateで起動されるDockerコンテナとの通信部分である負荷分散レイヤーはどう考えれば良いでしょうか？具体的には今回の構成ですと、CloudFrontのバックエンドにFargateがあるイメージです。

SA: 今回はFargate環境がVPCのプライベートサブネットにある前提でお話します。こちらであれば、Application Load Balancer(以下ALB)をVPCのパブリックサブネットに立てます。ALBを使ってFargateで起動されるDockerコンテナへ負荷分散が可能です。

Aさん：わかりました。ALBを使用したいと思います。

SA: 最終的には以下の構成になりますね。

Aさん：わかりました。本日はご相談させて頂きありがとうございました。

SA: はい、また何かあればいつでもご相談ください。

いかがでしたでしょうか？AWSのSAは、このようなAWS上でのお客様のシステムの構成についてのご相談を承っています。こちらのページから個別相談会にお申込みいただけます。是非みなさまも構成についてご検討の上、お気軽にAWSにご相談ください。

著者について

Hara Tori はAWSコンテナスペシャリスト ソリューションアーキテクトです。お客様の AWS コンテナサービス活用支援とともに、コンテナサービス群をさらに良いものにするための業務に従事しています。ツイッターが好きです。

舟﨑 健治（Kenji Funasaki）は、AWSテクニカルソリューションアーキテクトです。AWS上でシステムを構築される多くのお客様向けに幅広く技術支援を行っています。趣味は子育てです。