Elastic Beanstalkでアプリ /インフラかんたん一括管理

2016-10-13

自己紹介

氏名 : 駒原雄祐 ( こまはらゆうすけ )

年齢 : 36歳

家族 : 妻と子供 (3ヶ月 )と犬 (2歳 )

お仕事 : 広告配信プラットフォーム A.J.A.の開発・運用エンジニア

Agenda

Elastic Beanstalkって何？

Elastic Beanstalkの基本構成

Elastic Beanstalkのイケてるポイント

Elastic Beanstalk運用上の注意点

まとめ

突然ですが

AWS使ってますか？

きょうは Elastic Beanstalkの

お話をします

Elastic Beanstalkって何？

AWS上でアプリケーションを実行、管理するのに必要な機能がパッケージングされたもの

いわば AWSフレームワークといった趣

AWSの FAQによると、下記の事項を開発者が 簡単に行えるもの https://aws.amazon.com/jp/elasticbeanstalk/faqs/

容量のプロビジョニング

負荷分散

Auto Scaling

アプリケーションの状態モニタリング

ところで

Beanstalkの読み方は？

✕ びーんず・とーく ◯びーん・すたーく

意味は？

豆の主茎

( 出典 : Weblio http://ejje.weblio.jp/ )

AWSでWeb アプリケーションを作るとき ( 1 )

NW 系の各種設定 (新規の場合 )

VPC

Subnet

Route Table

etc ...

AWSでWeb アプリケーションを作るとき ( 2 )

セキュリティ系の各種設定 (新規の場合 )

Security Group

WAF

etc ...

AWSでWeb アプリケーションを作るとき ( 3 )

アプリケーション実行環境の設定

ELB

Auto Scaling Group

EC2

RDS

etc ...

AWSでWeb アプリケーションを作るとき ( 4 )

デプロイのための仕組みの準備

アプリケーションのビルド環境の用意

Jenkinsや Circle CIなどのクラウド CIサービスなど

サーバへのデプロイ方法の用意

アプリケーションのバージョン管理

ElasticBeanstalkがカバーしているもの

NW系● VPC● Subnet● Route Table

セキュリティ系● Security Group● WAF

App実行環境● ELB● Auto Scaling Group● EC2● RDS

デプロイ●ビルド環境●デプロイ方法●アプリケーションバージョン管理

ElasticBeanstalkがカバーしているもの

NW系● VPC● Subnet● Route Table

セキュリティ系● Security Group● WAF

App実行環境● ELB● Auto Scaling Group● EC2● RDS

デプロイ●ビルド環境●デプロイ方法●アプリケーションバージョン管理

Elastic Beanstalk のアプリデプロイの流れ

アプリケーションのビルド

ビルド成果物を ZIP圧縮し、 S3にアップロード

S3にアップロードした ZIPファイルを Elastic Beanstalkにアプリケーションとして登録

登録したアプリケーションを Elastic Beanstalkの Environmentに対してデプロイ指示

こんな人に向いている

よくあるアーキテクチャ構成で、 AWSサービスを個別に設定をしていくのが面倒

アプリケーションのデプロイから起動まで、自分で仕組みを構築するのが面倒

リリース後の切り戻しなど、アプリケーションの状態管理をしたいが仕組みを構築するのが面倒

…一方で

自分で構築するといろいろ面倒な部分をまとめてお世話してくれる

その分 Elastic Beanstalkが指定する流儀に則る必要はある(ある程度はカスタマイズも可能 )

自分でなんでも細かくやりたい (やる必要がある )場合にはそもそも向かない

Elastic Beanstalkの基本構成

Elastic Beanstalk の基本構成 ( 1 )

Application (アプリケーション )

アプリケーション名

Web Application or Worker

アプリケーションのバージョン管理

1個以上の Environmentを持つ

Elastic Beanstalk の基本構成 ( 2 )

Environment (環境 )

Applicationの子要素

ドメイン

紐づく各種 AWSサービス (EC2/ELB等 )の設定

インスタンスの状態管理

Rebootや Terminateなど一部運用も可

構成例 ( 配信サーバ )

1 Application 内に 2 Environemnt 構成

Environment を作ると一緒に作られるもの

ELB (HTTP or HTTPS -> EC2 port)

Health Check

Auto Scaling Group

EC2 (指定したランタイムプリインストール )

インスタンスタイプ

Security Group

EBS

など

EC2の実行環境のカスタマイズ例

EC2のレイヤーについては 2通りのやり方

起動する EC2の AMIを指定できる

予め必要なミドルウェア等をインストールした AMIを用意しておくとよい

.ebextensionsディレクトリを配置http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/ebextensions.html

ディレクトリ内の hogehoge.config と名の付いた YAMLに実行内容を記載

Elastic Beanstalkのイケてるポイント

アプリケーションのバージョン管理

登録したアプリケーションのバージョン履歴の保持

現在デプロイされているバージョンの確認

バージョンを指定してのデプロイ

バージョンを指定してのデプロイ

アプリケーションのアップデートだけでなく、切り戻しも簡単にできる

(古いバージョンの再ビルドという形ではなく、以前動作していたものと完全に同一のモジュールをデプロイできる )

2つの Environmentでの Blue Green DeploymentEnvironmentは個別にドメインが割り当てられる

同一 Application内の Environmentは、 URL Swapでドメインを入れ替えることができる

Environmentのドメインと URL Swap

prd-glasgow-deliver-active ↑こっちにアクセスが来る

prd-glasgow-deliver-standby↑こっちはスタンバイ

URL Swap

Blue Green Deploymentの流れ

Env1Domain: active…AppVer: 001

Env2Domain: standby…AppVer: 001

Env1Domain: active…AppVer: 001

Env2Domain: standby…AppVer: 002

Env1Domain: standby…AppVer: 001

Env2Domain: active…AppVer: 002

Blue Green Deploymentの利点

本番環境を 2系統用意して片側にデプロイすることで、リリース作業を安全に行える

万一問題があった場合でも、再度 URL Swapを行うことで、容易に切り戻しが可能

Elastic Beanstalk運用上の注意点

Elastic Beanstalkレイヤーで保持する設定との齟齬

一部の設定は、対象の AWSサービス本体の設定とは別に Elastic Beanstalk上でも保持

ex) ELBのリスナーや Auto Scaling Groupのmin/maxインスタンス数など

AWSサービス本体側の設定を直接変更した場合、 Elastic Beanstalk側の設定と差異が生じ、不具合につながる場合がある

Elastic Beanstalk側に設定がある項目はそちらから設定変更するのが無難

Blue Green Deployment 実施時の注意 ( 1 )

Auto Scalingによるスケールアウト /スケールインをしている場合 (高トラフィックなアプリケーションなど )

URL Swapによってスケールアウトしていない状態の環境が突然高負荷にさらされることになる

URL Swapの前に、インスタンス数を増やしておくなどの準備が必要

Blue Green Deployment 実施時の注意 ( 2 )

高トラフィックなアプリケーションなどで、 ELBを利用している場合、 URL Swapによって、 ELB自体がスケールダウンしている状態で突然高負荷にさらされることになる

事前にダミートラフィックを流しておくなどして ELBの性能を引き上げておく

両環境の ELBのプレウォーム申請をしておくことで性能を確保しておく(A.J.A.ではこちらを採用 )

URL Swap方式であることによる注意点

URLが入れ替わるだけのため、待機系環境もNW的に接続できなくなるわけではない

DNSキャッシュなどの要因で、少量ながら待機系にもアクセスは残る

待機系へのアクセスが許容できない場

URL Swap後に同一バージョンのアプリケーションを待機系にもデプロイ

ELBの Security Groupでアクセスを遮断

などの対策が必要

まとめ

まとめ

Elastic Beanstalkは、形式に則って実装することで、インフラ面をほぼまるっとおまかせできる AWSフレームワーク

立ち上げ期で時間がない人や面倒くさがりな人におすすめ

いくつかの罠は存在するが、バージョン管理やBlue Green Deploymentなど、うまく使えば運用が便利になる機能が盛り込まれている

ご清聴ありがとうございました