アドテクスタジオのオペレーションテクノロジー事業部（通称オペテク）の杉澤です。
前回の記事「Elastic Beanstalk の Multi-Container Docker Environment は便利①」の続きです。

概要

今回は Elastic Beanstalk のソースコードのフォルダ構成の話や、設定ファイルから構築する際の書き方などの
実際にどのように設定しているのかを、書いていきたいと思います。
また、Elastic Beanstalk によって得られるデプロイのメリットが具体的にどんなオペレーション、どんな動きで行われるのか、構築する場合に気をつけたほうが良い事などを紹介します。

本記事は要所を切り出して記事にしているため、不明な点は Elastic Beanstalk の公式ドキュメントを参考にして頂ければと思います。

Elastic Beanstalk のフォルダ構成と実際の設定内容について

Elastic Beanstalk は awsコマンドではなく、ebコマンドを使用して環境の構築やデプロイを行います。

eb コマンドは .elasticbeanstalk/config.yml の内容を読み取ってアプリケーションへの操作を行うため
webアプリケーションの操作は cd で web に移動してから、batch アプリケーションの操作は batch に移動してから行います。

※ebコマンドで環境を構築するにあたって、アクセス許可の設定などが必要になります。ドキュメントはこちらhttp://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/concepts-roles.html

私の担当するプロダクトでは以下のようなフォルダ構成となっています。

Elastic Beanstalk では eb コマンドで create や deploy を使うと git commitされた状態の
カレントディレクトリにある.ebextensions の中にある config ファイルを名前順に読み込み、適用を始めます。
そのため config ファイルのプレフィックスに数字で連番が振られています。

設定ファイルとしては、この config ファイル郡 + Dockerrun.aws.json というファイルでひとつのアプリケーションを動かす環境構築が可能です。
次に、Web のアプリケーションを例にして、それぞれのファイルの内容を実際に見ていきます。
また、以降プロダクト固有の部分については伏せてあります。ご了承ください。

00.option.config

• このファイルでは config の中で指定できる option_settings というものを設定しています。
• ドキュメントはこちら http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/command-options-general.html

01.endpoint.config

このファイルでは環境のエンドポイントに関係する以下２つを作成するように設定しています。

• AWSEBLoadBalancer : 443 to 443 のロードバランサーを作成しています。
• AssetsInternalDNSRecord: インターナルの DNS レコードを登録しています。 内容は、ドメインがeb-{環境名}.example.comでAWSEBLoadBalancerで作成したロードバランサーのエイリアスを作成しています。

AssetsInternalDNSRecord は、Elastic Beanstalk の CNAME を使いたくなかったため自前でレコードを用意しています。
理由としては、Elastic Beanstalk が提供する URL 内に Elastic Beanstalk の ID があってわかりにくく使いたくなかったのと、
提供された URL を使うと CNAME を使う事になるのですが、ルートドメインを使いたかったため、CNAME は使っていません。
（ルートドメインを使う場合、 DNS の決まり事で CNAME が使えなかったと思うので、このようにしています）

02.docker.config

社内で用意されている、JFrogArtifactory の DockerRegistry にログインしています。

03.application.config

ログをマウントするディレクトリを作成します。

04.ldap.config

内容は表示できませんが、EC2インスタンスにコマンドで hosts を追加して社内 ldap サーバーとの連携をさせる config ファイルです。

05.autoscaling.config

オートスケーリンググループに対しての設定を書いています。
今回作成する環境は夜間はアクセス頻度が落ちるため以下のようなスケジュールのスケーリングを行わせます。

• 21時 : 最低2台稼働している状態に
• 09時 : 最低4台稼働している状態に

Dockerrun.aws.json

• インスタンス内で稼働させる Docker コンテナの設定を書いています。
• ドキュメントはこちら http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create_deploy_docker_v2config.html

どうやって作成されていくのか？

infra-beanstalk/webに移動して eb create コマンドで実際に環境を作成すると、以下A〜Eのように環境が構築されます。

やり直したい場合は？

Elastic Beanstalk には、環境を消すという機能も備わっています。
この操作を行うと、 eb create コマンドで作成した時に作られたものが消えます。
（2016年8月現在、ECS の一部(task definition)で残骸が残ってしまいますが、基本的には殆どの設定が消えます）

消す命令をすると作成したものだけが消えるため、環境の作り直しが非常に簡単に行えます。

具体的にどんなデプロイができるのか

• プロダクトで採用しているデプロイ方法について書いています。
• Elastic Beanstalk がサポートしているデプロイの一覧はこちら（http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html）
• Multi-Container Docker Environment なので、デプロイの内容は Dockerrun.aws.json による各インスタンスでの新しい ECS タスクのスタートと各 config ファイルの適用を指します。

ローリングデプロイ

• Elastic Beanstalk のデプロイ機能としてサポートされているもので、一度に全体の何％のインスタンスにデプロイするかなど細かい設定が可能です。
• インスタンスを1台づつ ELB から切離してデプロイ、ヘルスチェックに合格したら ELB に紐付け…を繰り返して全台デプロイします。
• プロダクション（本番）環境でのみ、このデプロイ方法でデプロイしています。

option_settingsに以下を設定することで有効になる

• メリット

ダウンタイムなしデプロイを行うことが可能です。

• デメリット

デプロイに時間がかかります。
50%で実施したとして、AllAtOnce と比較してローリングデプロイは約5倍くらい時間がかかりました。
（Rolling : 約10分、 AllAtOnce : 約2分）

AllAtOnce

• Elastic Beanstalk のデプロイ機能としてサポートされているものです。
• 一度に全てのサーバーにデプロイする方式です。
• 私の担当するプロダクトでは、開発環境、確認環境（dev、stg）のデプロイで使用しています。

 

• メリット

デプロイがとにかく速いです。
Elastic Beanstalk が提供しているデプロイ方法の中では一番速いです。

• デメリット

一度に全てのインスタンスにデプロイするため、ダウンタイムが発生します。

ブルーグリーンデプロイ

• Elastic Beanstalk の「CNAMEのスワップ」とは別のものです。自分で DNS レコードの付け替えを行います。新しい Elastic Beanstalk の環境を作成して、エイリアスをその環境に向けます。
• サーバー構成に大きく変更があった場合（インスタンスタイプの調整、Docker コンテナの追加）にこのデプロイ方法を実施しています。
• 切り替わりのイメージとしては、以下のように切り替わります。

①まず eb-prd1.example.com のエイリアスとして example.com が存在するとします。

②エイリアスを eb-prd1.example.com から eb-prd2.example.com へと切り替えます。
各ユーザーの参照する DNS が更新され次第、新しいエイリアス先 （eb-prd2.example.com）へアクセスが来ます。

③２つの環境 eb-prd1.example.com と eb-prd2.example.com が同時に存在する状態となります。

④eb-prd1.example.com の環境のアクセスログに暫く書き込まれていない事を確認して、 eb-prd1.example.com の環境を削除します。

• メリット

本番に切り替える前に確認が行える事から、非常に安全にデプロイできます。
また、切替後に異常があった場合でも、切替前の環境を消さない間は切り戻しが簡単に行えます。
CNAME ではサポートされていないルートドメインも対応しています。
また、少し無理矢理ですが以下の手順で事前確認も可能です。

• デメリット

同じ環境を作成するため、環境に対して発生する料金が一時的に倍となります。
DNS を触るため、Elastic Beanstalk の通常のデプロイと比較すると大掛かりで、
レコードを誤って設定した場合などにはアプリケーションにダウンタイムが発生してしまう可能性があります。

もし構築するなら気をつけたほうが良い事

Elastic Beanstalk Multi-Container Docker Environment でプロダクトを運用し始めて約半年が経過しましたが、 注意点として以下の2点で主に気をつけたほうが良いと思ったので紹介致します。

Dockerコンテナ起動時に環境を選択する

Elastic Beanstalk Multi-Container Environment で運用していると、環境が簡単に作成できるためついつい「dev-02、dev-03、dev-04…」なんてものを作りたくなってきます。
この際にDocker コンテナ起動時に環境を選択させるようにしておくと非常に便利です。
理由は以下の２つがあります。

• 環境毎にDocker コンテナをビルドしている場合、環境が増えると環境毎にDockerビルドしなければならないため、ビルドに時間がかかる
• 開発環境で動いたコンテナを本番環境で動かす事ができる

開発環境で確認したものが本番で動かせる安心感も得られると思います。

コンテナレジストリの場所を考える

レイテンシの関係でデプロイ速度に直に影響するので、コンテナレジストリの場所をちゃんと考えたほうが良いです。
これはElastic Beanstalk に限らず、コンテナで運用する上で考えたほうが良いものだと思います。

私の担当するプロダクトでは、S3をストレージとするDocker レジストリを、公式の Docker Registry のコンテナイメージを東京リージョンで構築しています。
docker hub はこちら https://hub.docker.com/_/registry/

当初 ECR を使っており、pull する速度については問題無かったのですが、CIサーバーから docker push する際に時間が掛かっていたため、東京リージョンに変更したところ、CI を行う時間がかなり短縮されました。

まとめ

全てをコード管理し、デプロイまでも安全する Elastic Beanstalk Multi-Container Docker Environment の実際の設定内容とデプロイについての記事でした。
ある程度のアプリケーションが動く環境は Docker の中に閉じられており Dockerfile に書かれているため、Elastic Beanstalk のコード量もわりとスッキリと書くことができると思います。
Elastic Beanstalk はチーム内で使っていて割と敷居が高い以外は便利で非常に良いモノだと思うので、是非検討してみてください！