(レポート) DVO201: AWS Elastic BeanstalkによるWEBアプリケーションのスケーリング

こんにちは。オペ部の半瀬です。

はじめに

AWS re:Invent 2015 盛り上がっていますね。弊社ブログではアドバンスト以上のセッションレベルでの記事が(現時点で)多くあげられていますが、セッションレベル初級 (200) で導入編を取り扱うセッションもあります。 （コチラでレベルごとのセッション一覧をひっぱれます。）

今回は、EB導入に関するセッションを読んでみました。オペレーション対応としてもEBに関するものが増えてきています。

タイトル：目次

タイトル：(DVO201) Scaling Your Web Applications with AWS Elastic Beanstalk (弊社訳：AWS Elastic Beanstalk によるWebアプリケーションのスケーリング) 目次： ・Elastic Beanstalk (自前で用意することと比較しての利点） ・ワークフローのサンプル ・デモ（本稿では割愛します） ・ベストプラクティス ・デモ（本稿では割愛します） ・カスタマストーリー

このセッションの目標(Slide 3/38)

・ElasticBenastalkの利点を学ぶ ・EB CLIでアプリケーションをデプロイする ・環境設定の編集を学ぶ ・他のAWSリソース(RDS, SNSなど)へ拡張してみる ・数百万単位のWEBリクエストを扱うための デバッグとテスト手法 ・ゼロダウンタイムを前提としたデプロイ ・ローリングデプロイ (in-place eployments) ・Swap URL (blue/green deployments) ・alarm と notification 通知を設定する ・コストマネージメントのためのタグ付け

Elastic Beanstalk vs. DYI (Slide 4-6/38)

On-insstance configuration

Elastic Benastalk(EB)は基本的にアプリケーションのみ意識するだけでOK。アプリを動かすために必要なプラットフォームを選定し、EC2インスタンス上での環境設定はEB側で準備をしてくれます。ログインしてインストール作業を行う面倒がないものです。

Infrastructure stack

・シングルインスタンスでの起動（主に開発用途）、ロードバランシング&AutoScaling（主に本番用途）を選択しましょう ・Ec2をWEBとして使うかWorkerとして使うか選択しましょう。 ・ELB , AutoScalingGroup , SecurityGroup , RDS などのリソースは必要に合わせて EBが用意してくれます。 ・アプリアクセス用のユニークなドメインネームを発行してくれます。

ユーザー側で選択・決定すべきもの ・作成先のRegion ・コンテナタイプ java, php, node-js, docker, .net, python, ruby ... ・single構成 or ELB(AutoScaling)構成 ・RDSを使用するかしないか

ワークフローのサンプル(Slide 7-9/38)

主なデプロイ方法

・AWSマネジメントコンソールから ・AWSツールキット（for Eclipse , VisualStudio）から ・EBコマンド（EB CLI）から

EBコマンドを用いたアプリデプロイ手順のサンプル

・01. ebコマンドのインストール(pip install) ・02. アップロードしたいサンプルコードの準備（git clone :AWSサンプルコードを利用） ・03. EB初期構築（eb init) ・04. コマンドライン上で環境設定を行う ・05. EB環境作成 (eb create)

EBコマンドを用いたアプリアップデート手順のサンプル

・01. アプリ更新 ・02. デプロイ(eb deploy) ・03. 公開 (eb open)

ワークフローのデモ(Slide 10-20/38)

デモ部分は省略しますが、ポイントとしては以下のようなものです。スライド内にサンプルコードがありますので、ご参照ください。 ・Application dependency managment : verion とdependencyを明記しましょう ・.ebextensions を使用して、AWS環境設定のカスタマイズをする ・.ebextensions を使用して、他のAWSリソース(DynamoDB, SNS, SQS ... )の利用設定を付与する

ベストプラクティス(Slide 21-27/38)

テストとチューニング

・最適化のための指標とするために、パフォーマンス要件を整理しましょう 1. レイテンシ 2. 同時接続ユーザー数 3. 特定の期間での総リクエスト数　　など ・ロードテストをしましょう 1. アプリが過負荷状態でどの程度アクセス品質を落とすかを知るために、１インスタンス（AutoScalingの最大最小を１とする）下でのテストをしましょう 2. 現行環境での有効値（パフォーマンス期待値）がどの程度パフォーマンス要件に一致するか確認しましょう。 ・パフォーマンス要件に合わせて最適化しましょう 1. １度にスケールアウトする台数を決める 2. [Breach Duration]を決める ※ [Breach duration] は、トリガーが発せられるまでに、指定した限度（[Upper threshold] と [Lower threshold] の値）を超えることが許可される時間 3. トリガーのための具体的なメトリクス指標を決める ・バックエンド（DynamoDB, RDS）のパフォーマンスチューニング: フロントエンドのスケールアウトで事足るように余裕を持たせると良いでしょう。

デプロイ方法：ローリングデプロイ

よい点 ・デプロイがはやい（20-60 sec.) よくない点 ・ロールバックに時間がかかる：前バージョンを再デプロイする必要がある ・(?:直訳)環境を長時間実行する上での、変更の蓄積（の可能性がある。)

デプロイ方法：blue/green

よい点 ・ロールバックがはやい：前バージョンは変更されないため ・変更の蓄積がない よくない点 ・ローリングデプロイと比較してデプロイに時間がかかる(2-5 min.)：新規で環境設定を作成するため。 ・モバイルデバイス側（クライアント全般）でのDNSキャッシュに依存する問題が出る

ログ、メトリクス、アラームの準備

・ログをS3に自動転送しましょう ・EB環境設定で利用可能なメトリクスについて理解しましょう ・メトリクスが通常運用の想定範囲を超えた値を検知いた場合に、アラート通知するように設定しましょう ・Route53 ヘルスチェックを設定しておきましょう

タグの準備

・作成したEB環境と関連するリソースを一目でわかるようにタグ付けが必要です。 ・それによりEB環境でかかったコストの管理もしやすくなります。 ・EBは以下の要素で自動的にタグ付けを行います： ・環境名 ・環境ID

カスタマストーリー:Royal Caribbean Cruises Ltd.(Slide 28-37/38)

Royal Caribbean Cruises Ltd.について

・43隻の客船を運営（※一部訳不明） ・７大陸、490の都市で運航 ・Royal Caribbeanサイト単独で 9000のHTMLページ ・2015年3月に EBを導入 ・ピーク月：月間総計1億ページビュー ・ピーク月：月間600万ユニークユーザー ・ピーク月間では、ピーク外の平均総ページビューに比べ、4000万ページビュー多い

The case for Elastic Benastalk（EBを選んだ理由）

・continuous deliveryとしてのEB ・増大していくユーザーへの価値提供を実現するにあたっての費用、時間、リスクを低減する ・より低いITの重圧 ・開発、テスト、本番環境をほぼすべて自前で準備できる ・供給/スケール/復旧の自動化 ・ELB, EC2, AutoScaling, Cloudwatch を一枚ガラスで扱うことができる ・非常に安定した動作環境 ・ゼロダウンタイムのデプロイ：速さと信頼性 ・技術的な実施可能要件がもたらすもの ・総じてマーケティングチームに実践的な活力を与えられる ・ヘルスチェック、パフォーマンス、KPIの可視化を提供することができる ・複数のプロジェクトに、それぞれの環境を簡単に作成し提供することができる

Environment on demand（環境要件）

・個別あるいは同じ環境スタックを簡単に用意できる必要がある。テストサイクル、平行リリース、あるいはその他のプロジェクト段階に応じて。 ・様々なプロジェクトごとの環境要件がありつつも、共通のパラダイムをフォローする必要がある

Application architecture / Automation (環境の実現と自動化）

・CloudFormationテンプレートを使用 ・共有設定と固有設定をネストする ・環境作成とアップデートを AWS APIで記述する ・EBへの調整と開発にjenkinsを使用する ・EBテンプレートをGit管理する ・EBコンソールはモニタリングとトラブルシュートに使用する ・再現性を保つために、信頼性を確保するために、報告可能なように、すべてを自動化する ・構成の標準化 ・ヒューマンエラーが入る余地を無くす ・巻き戻しと監査(?) ・Quick and Easy

Continous Delivery

Results (実現できたこと）

・ゼロダウンタイムのデプロイ ・３時間のデプロイタイムを３０分に ・高負荷時においても安定した稼働 ・すべてのEB環境にパートタイムでリソース共有

さいごに

EBの導入部分のセッションをご紹介しました。何を目的に、なぜEBを導入するのか、を事例を見て学ぶ良い機会となりました。

それではー。