elb & cloudwatch & autoscaling - awsマイスターシリーズ

AWSマイスターシリーズ Reloaded ～ELB, AutoScaling & CloudWatch～

2012年5月21日

玉川 憲（ @KenTamagawa ） 技術統括部長/エバンジェリスト 2012年5月21日更新 v.1.0

ELB、CloudWatch、Auto Scalingの密接な関係

典型的使用例: 異なるアベイラビリティゾーンに存在するWebサーバー（EC2)の前にELBを利用する。CloudWatchはバックエンドのサーバーの負荷をモニタリングし、定義しておいた設定を満たすとアラームをあげ、Auto Scalingの設定(ポリシー)にそってEC2サーバーを増減させる Elastic Load

Balancing

CloudWatch Auto Scaling CPU利用率

アラーム

ロードバランサ

モニタリング

サービス

EC2サーバを

増減する

メカニズム ゾーンA ゾーンB

EC2

マイスター的、他のサービスとの位置づけ ①静的コンテンツは、S3とCloudFrontで！(楽だし簡単) ②動的コンテンツで、EC2でのスケールアウト/インが必要なときはELB!!

Agenda

ELBの詳細

基本説明&デモ

応用編

利用上のTIPS/制約

AutoScalingの詳細

CloudWatchの詳細

まとめ

ELB: Elastic Load Balancing

AWSが提供するロードバランサーのクラウドサービス

ELBの特徴

管理が容易：運用、スケーリングの手間を楽に

負荷分散: 複数EC2サーバーのみならず、異なるデータセンター(AZ: アベイラビリティゾーン)を跨って、トラフィックを負荷分散

高い可用性: ELBそのものが分散システム、監視され耐障害性高い。 複数サーバ/AZに負荷分散でシステムの耐障害性を高める。

スケーラブル: ELB自体がトラフィックに応じてキャパシティを増減。 負荷にあわせてバックのサーバーを増減させる自動設定可能。

ヘルスチェック機能: ヘルシーなEC2にのみ、トラフィックを分配

安価な従量課金: 初期費用無の従量課金で利用可能

ELBの概念図

ゾーンA ゾーンB

東京リージョン

ELB

ユーザー

クライアント

Web コンソール

開発者

HTTP / HTTPS /

TCP / SSL

HTTP / HTTPS /

TCP / SSL

EC2 EC2

ELBの基本

サポートしているプロトコル

HTTP、HTTPS、SSL、TCP

ELBはトラフィックにあわせ、自動的にキャパシティを増減する →数も増減するので、IPアドレスはそれに伴い変わる

(重要) ELBを使用するときには、DNS名を用いる 例: hanako-12345678.ap-northeast-1.elb.amazonaws.com

独自ドメイン名には、名前解決にCNAMEを用いる

AWSマネージメントコンソール(Webコンソール)、API、コマンドラインツール、SDKでELBをコントロールできる

ELBのデモ

AWSマネージメントコンソールから、ELBのウィザードを使って、ELBを作成

利用するポートとプロトコルの設定

ヘルスチェックの設定

バックエンドのEC2を選択

ELB作成を実行！ →数分で作成完了

デモ: ELBの作成

デモ：ポートとプロトコルの設定

ELBからEC2へは

違うポートのアサインが可能 プロトコルの選択

(複数追加可能)

デモ：ヘルスチェックの設定

ヘルスチェックに使う、ファイルとして、この例は、index.htmlだが、

ファイル名は独自のものを使うことを推奨

デモ：バックエンドのEC2インスタンス選択

ゾーン間で均等に配分することに注意。EC2のタイプも

気にしないことにも注意。

デモ：作成確認画面

デモ：ELBが作成されました！

推奨事項: EC2側でのセキュリティグループ設定

ELBからのインバウンドしか

受け付けないように、セキュリティグループを設定できる。

“amazon-elb/amazon-elb-

sg”をそのまま用いる

Agenda

ELBの詳細

基本説明&デモ

応用編

利用上のTIPS/制約

AutoScalingの詳細

CloudWatchの詳細

ELBの応用編

ELBのSSLサポート

Zone Apexのサポート

Session Stickiness

VPCの中のELBサポート

IPv4とIPv6のサポート (東京リージョンもサポート)

ELBのDNS名に対する複数IPアドレスサポート

ELBのSSLのサポート

ELBでSSL Terminationが可能

①ELBでSSL Terminationし、バックに復号したものを送信

②ELBでSSL Terminationし、バックに別途暗号化して送る

③SSLをバイパスしてバックにTCPで送信

SSL証明書をELBで一元管理できる

証明書のアップロード/編集は、Webコンソール/IAMのAPI

受け入れるCipher(暗号化プロトコル)の選択も可能

ELBでのSSLサポート

SSLのサポート

①ELBでSSL Terminationし、バックに復号したものを送信

②ELBでSSL Terminationし、バックに別途暗号化して送る

③SSLをバイパスしてバックにTCPで送信

ELBでのSSL証明書の管理 SSLを用いる場合、ウィザードの中でSSL

の選択/インポート画面が出てくる

Cipherの選択

バックエンドのサーバーの認証

前回セミナーからの新機能！

マネージメントコンソールにて、

後からリスナーの追加が可能に！

マネージメントコンソールから、

後から、SSL証明書やCipher

の変更が可能に！

http://aws.typepad.com/aws_japan/2012/05/elastic-load-balancer-console-

updates-and-ipv6-support-for-2-additional-regions.html

Zone Apexのサポート Zone Apex(ゾーン頂点)はDNSの仕様上CNAMEでサポートできない

例) × example.com

○ www.example.com -> hanako-12345678.ap-northeast-1.elb.amazonaws.com

Route 53は独自機能でこれをサポート！-> Route 53のAliasレコード

http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/index.html?CreatingAliasRRSets.html

Session Stickiness

Session Stickiness(セッションアフィニティ)もサポート

ELB作成のcookie / application作成のcookie

(参考資料) Amazon VPCとは？

AWSクラウド上にプライベートクラウドを構築

①社内からVPN接続して閉域網でAWS利用

②仮想ネットワーキング

オンプレミスとのハイブリッドが簡単に実現

AWSが社内インフラの一部に見える

社内システム、ソフトウェアの移行がより容易に

例：業務システム、バッチ処理、ファイルサーバ

より細やかにネットワークがコントロール可能

2011年8月から全リージョンで利用可能に

26 Copyright © 2012 Amazon Web Services

お客様のインフラをAWS上に延長する

リージョン

EC2

VPC

NAT

イントラ

プライベート サブネット

パブリック サブネット

インターネット

EC2内に分離したサブネットを

自由に作成 VPN 接続

ゲートウェイ

Copyright © 2012 Amazon Web Services

VPC内のELBサポート

ELB on VPCの機能

パブリックのELB同機能

ELBのトラフィックをサブネットをまたいで分散

ELBセキュリティグループで、より細かくコントロール可能

ELB on VPCの制約

IPv6サポート現状なし

Dedicatedインスタンスはサポートせず

/25 CIDRブロック以上のIPアドレスが必要

ELB配下でのAuto Balancingは現時点で未サポート

IPv4とIPv6のサポート (東京リージョンもサポート)

各ELBで3種類のDNS名

ELBのDNS名を名前解決すると複数IPアドレス返答

DNSラウンドロビンのようにIPアドレスのリストを返信

マルチAZを用いていると、2つ以上のIPアドレスのリスト (最大8個まで)

クライアント側の再試行機能が利用できる

応用編その他

IAMを利用してAPIへのアクセス権限設定可能

X-Forwardedヘッダーをサポート

X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, X-Forwarded-Server, X-Forwarded-Host

X-Forwarded-Forに複数のクライアントIPアドレスを含むこともあり(マルチAZ時)

CloudWatchとの統合

リクエスト数(HTTP 2xx-5xx)

レイテンシー

リクエストカウント

ヘルシー、アンヘルシーなEC2インスタンス数

→CloudWatchで監視して通知を行える

Agenda

ELBの詳細

基本説明&デモ

応用編

利用上のTIPS/制約

AutoScalingの詳細

CloudWatchの詳細

ELBの利用上のTIPS

ELBのIPアドレスを直接用いない(Aレコード、ダメ！絶対！)

IPアドレスは変更する可能性があるのでCNAMEを用いる

高い耐障害性を求めるサイト構築の際は、複数AZを用いて 負荷分散することを推奨

ELBは、マルチAZの負荷分散に追加料金もかからない

ELBの負荷分散の性質(現時点)に注意

ELB は、各 AZ に均等に負荷を割り振る →各AZに均等、同じインスタンスタイプの利用を推奨

負荷の少ないインスタンスにリクエストを割り振る

ELBの利用上のTIPS

ヘルスチェックが利用するファイルへのアクセス権に注意

バックエンドのサーバーで認証などを行っている際に、ヘルスチェックで設定したファイルが、「HTTPのステータスコードで200番を返さないと」、ヘルスチェックに失敗する

• 対処例: Apache httpdのディレクティブにて:

<Files health_check_file.txt>

Satisfy Any

Allow from all

</Files>

ELBの利用上のTIPS

ヘルスチェックするページの指定

“軽いページ”を指定する Webサーバーが返答するかどうか？

“重いページ”を指定する Web Appサーバ、DBサーバーも含め、 すべてのパーツが動いているかチェック (参照) CDPのDeep Health Checkパターン http://aws.clouddesignpattern.org/

ELBの利用上のTIPS

非常に急激にトラフィックが急増するシステムにELBを用いる場合は注意

ELBではキャパシティの増減には時間がかかる。

ELBのキャパシティ増減が間に合わないほどの急激なトラフィック向上が予測される場合、ELBのキャパシティ不足が起こる可能性がある

⇒事前に 営業/プレミアムサポートにご相談ください

現時点の目安： 5分以内で2倍以上のトラフィックが予測される場合

ELBの利用上のTIPS

DNSキャッシングに注意

TTL(60 秒)より長くキャッシュを保持するゲートウェイ、プラットフォームを経由した場合、間違ったDNS設定と似たような状況を引き起こす可能性がある

ELBでは最低60分間はIPアドレスの再利用はしないが、それ以上に渡ってキャッシュされる場合、問題が起こる可能性がある → 営業/プレミアムサポートにご相談ください

ELBの利用上のTIPS

SSL証明書のライセンス

技術的には1つの証明書をELBにインストールして、それをバックエンドの複数のEC2インスタンスで利用可能。ライセンスに関しては、ドメイン単位/サーバー単位で発行など、ベンダーによって異なり注意要

ELBのTCPコネクションは60秒後にTerminateされる

60秒以上の待ち時間が発生する場合は、 アプリケーション側で非同期プロセスをするなど工夫が必要

ELBの負荷テストは要注意。例えば、下記を参照

Best Practices in Evaluating Elastic Load Balancing

http://aws.amazon.com/articles/1636185810492479

参考和訳: http://understeer.hatenablog.com/entry/2012/02/29/175334

ELBの利用上の制約 複数リージョンにまたがった負荷分散はできません

UDPはサポートされていません

URLレベルの負荷分散には現時点で対応しておりません

Session Affinityにおいて、cookie以外のURLリライティングやSSLセッションIDなどはサポートされていません

ELBに対してEIPを割り当てる機能は現時点でサポートしておりません

既に他のELBに追加されてるインスタンスを、別ELBにも追加するのはAPIのみで可 例) ELBを利用して1つのEC2で複数ドメインのHTTPS(SSL) - suz-lab http://blog.suz-lab.com/2011/01/elb1ec2httpsssl.html

ELBのリミット

初期設定では、最大10個までしかELBが作成できません

制限解除のフォーム http://aws.amazon.com/jp/contact-us/#request_service_limitation

Agenda

ELBの詳細

基本説明&デモ

応用編

利用上のTIPS/制約

AutoScalingの詳細

CloudWatchの詳細

Elastic Load

Balancing

CloudWatch Auto Scaling CPU利用率

アラーム

ロードバランサ

モニタリング

サービス

EC2サーバを

増減する

メカニズム ゾーンA ゾーンB

EC2

AWSクラウドデザインパターン(CDP)

Scale Outパターン http://aws.clouddesignpattern.org

AS: AutoScaling

定義しておいた設定にあわせて、EC2の台数を増減させるメカニズム

サーバーを不要時は落とし、必要時は増加させ、コスト効率を改善

運用を簡易化、自動化する

典型的なユースケース

ピーク対応: リクエストにあわせてキャパシティを増減させる

規模を固定して管理: 不健全なサーバーを除き、数を一定に保つ

ELBとの連携: ELBと連携し、配下のEC2インスタンスを増減させる

スケールさせるためのメカニズム

マニュアル – コマンドラインツール/APIで変更を指定

スケジュール – 希望時刻にあわせてスケールさせる

ポリシーベース-ポリシーを設定しておき、そのポリシーをCloudWatchのアラーム等で起動する

AS: AutoScaling

Auto Scalingのその他特徴

通知機能: SNSを利用してアクション実行時に通知送信

ヘルスチェック機能: EC2の状態をチェックする

AutoScalingの設定そのもののコストはかからない

現時点で、AWSマネージメントコンソールの設定はない

コマンドラインツール、もしくはAPIで設定必要 (AWS Elastic Beanstalkはコンソールで可能)

Auto Scalingが実行するタスク

下記のタスクを実行できる

Launch: インスタンスの起動を行う

Terminate: インスタンスを終了する

HealthCheck: 各インスタンスのヘルスチェックを行う

ReplaceUnhealthy: 不健全なインスタンスを入れ替える

AddToLoadBalancer: 指定したELBにインスタンスを追加する

AZRebalance: AZ間のインスタンスのバランスをとる

AlarmNotification: 起動/終了の通知を送る

ScheduledActions: スケジュールしていたアクションを実行する

Auto Scalingのコマンドラインツール

コマンドラインツールのインストールはこちら:

http://aws.amazon.com/developertools/Amazon-EC2/2535

as-cmdでコマンドの一覧表示

Auto Scalingの3つの基本設定 “Launch Configuration”

起動したいインスタンスのパラメータ設定を行う

どのAMI?、セキュリティグループ？

“Auto Scaling Group”

Auto Scalingさせるグループの設定

どのELBに？どのAZに？サーバMin/Max台数？ どのLaunch Configで？

“Scaling Policy”

アラームが発令されたときのスケーリング量の指定

いくつのインスタンス数を増やす？

Launch Configurationの作成

起動したいインスタンスのパラメータ設定を行う

設定内容: AMI、インスタンスタイプ、セキュリティグループ、キーペア, ボリューム, モニタリング設定, カーネルID, Ramdisk ID

複数のAMIの指定はできない

as-create-launch-config コマンドを用いる

Auto Scaling Groupの作成

Auto Scalingさせるグループの設定

設定内容

特定の“Launch Configuration”の指定

Minimum/Maximum/Desired(初期希望値)のインスタンス数

アベイラビリティゾーンの指定(複数可能)

(ELBを使う場合) ELBの指定 インスタンスのヘルスチェックにELBのヘルスチェックを使うかどうか

インスタンスが起動してヘルスチェックをはじめるまでの待ち時間(Grace period)

(VPCを使う場合)サブネット

as-create-auto-scaling-groupコマンドを用いる

Auto Scalingのデモ サーバー台数を常に2台に保つ設定のデモ

事前準備

ELBの作成

EC2のAMIを作成しておく (例: Apacheが自動的に起動するもの)

Auto Scaling設定

Launch Configurationを上記AMIを指定して作成

Auto Scaling Groupを、上記のリソースで作成

実験

キャパシティを変更して実験してみる

• EC2をわざと落として自動的に起動するか？

• Desired capacityを増やして、その振る舞いを観察

終了時: リソース消去の順番に注意

デモ: Auto Scalingの設定

as-create-launch-config MyLC --image-id ami-fa9a2efb -

-instance-type t1.micro --group "webapps" --key tokyo --

region ap-northeast-1

デモ: Auto Scalingの設定

as-create-auto-scaling-group MyAutoScalingGroup --launch-

configuration MyLC --availability-zones=ap-northeast-1a, ap-

northeast-1b --load-balancers MyLoadBalancer --max-size 1 --min-

size 1 --region ap-northeast-1

(事前に、ロードバランサーをゾーン1a,1bで動作させておくことに注意)

デモ: Auto Scalingの設定

as-describe-auto-scaling-groups MyAutoScalingGroup --headers --region

ap-northeast-1

EC2インスタンスが起動

デモ: Auto Scalingの設定

EC2インスタンスが起動

手動で、min-sizeを切り替えてみる

設定をチェック。この後、EC2インスタンスを手で落としても自動的に立ちあがる！

デモ: Auto Scalingの設定

順番に、消去していくことに注意。

as-update-auto-scaling-group

MyAutoScalingGroup --min-size 0 --region ap-

northeast-1

as-delete-auto-scaling-group

MyAutoScalingGroup --region ap-northeast-1

as-delete-launch-config MyLC --region ap-

northeast-1

Auto Scaling Policyの作成

CloudWatchのアラームが発令されたときのスケーリング量の指定

設定内容:

増減するインスタンスを数で指定 / 現在のキャパの％指定 / 特定の数への指定

as-put-scaling-policyコマンドを用いる

デモ: Auto Scalingの設定

as-put-scaling-policy MyScaleUpPolicy --auto-scaling-

group MyAutoScalingGroup --adjustment=1 --type

ChangeInCapacity --cooldown 300 --region ap-

northeast-1

Auto Scalingのスケジューリング

PutScheduledUpdateGroupActionを用いる

AutoScalingGroupName、StartTime、DesiredCapacity、MaxSize、MinSizeを指定できる

http://docs.amazonwebservices.com/AutoScaling/latest/APIReference/index.html?API_PutScheduledUpdateGroupAction.html

CDP

Scheduled Auto Scaling パターン

Scheduled Scale Outパターン

Auto Scaling利用時のTIPS

インスタンスが起動しないときのチェック項目

設定が間違っている(設定したリソースがおかしい。ELB名？)

制限を超えている(インスタンス数の20の初期リミット等)

原因を確かめるために、as-describe-scaling-activities を用いよう

なぜ、勝手にインスタンスが終了するの？？

ヘルスチェック

リバランス

こちらも、原因を確かめるために、as-describe-scaling-activitiesを用いよう

Auto Scaling利用時のTIPS(続き)

インスタンスがトラフィックを受け付けない

ELBのAZ設定が、Auto ScalingのAZ設定と異なっている →同じである必要がある

Auto Scaling配下のEC2インスタンスのTerminateされる順序は、指定できない

現時点では、Terminateの順番は指定できません。基本的には、一番古い起動コンフィグで立ち上がった、課金タイミングの終わりに近いものが terminate されます

Auto Scalingの制約

Auto Scalingのリミット

100 Launch Configurations

20 Auto Scaling Groups

125 Actions

50 Policies

20 SNS Topics

→ 営業問い合わせ/プレミアムサポートにご相談ください

Agenda

ELBの詳細

基本説明&デモ

応用編

利用上のTIPS/制約

AutoScalingの詳細

CloudWatchの詳細

Elastic Load

Balancing

CloudWatch Auto Scaling CPU利用率

アラーム

ロードバランサ

モニタリング

サービス

EC2サーバを

増減する

メカニズム ゾーンA ゾーンB

EC2

CloudWatch

AWSクラウドのリソースをモニタリングするためのWebサービス

CloudWatchの特徴

EC2、EBS、利用料金、 ELB、RDS、SNS、SQS、EMR、ElastiCache、DynamoDB、StorageGateway のモニタリング

上記以外に、カスタムメトリクスとして、ユーザーが任意のデータを保存、可視化できる

メトリクスが保存される期間は2週間

メトリクスをベースにアラームを設定できる

• アラームからAuto Scaling Policy実行、SNSで通知

CloudWatch

GUI、コマンドラインツール、APIでコントロールできる

CloudWatchの基本モニタリングは無料

ELB、RDSは1分間隔が無料

EC2は5分間隔のモニタリングが無料 (有料で1分間隔の詳細モニタリング可能)

カスタムメトリクス、アラーム、API利用は有料

カスタムメトリクスは無料使用枠で10メトリクスまで無料

料金詳細は、こちら http://aws.amazon.com/jp/cloudwatch/

EC2のプロパティビューのCloudWatchのグラフ

1時間~2週間まで、

グラフの表示期間を変えられる

詳細(1分間隔)の

モニタリング機能

アラームの作成も

各EC2インスタンス

からできるように！

Graphはドリルダウン可能

CloudWatchのダッシュボード

メトリクスの詳細を見る

メトリクスで見れるもの

EC2 EBS ELB RDS

SNS SQS

Dynamo、SG、EMR

ビリングアラートも！

Using CloudWatch API Tools

CloudWatchのデモ

事前準備

Auto Scalingのポリシーの設定まで済んでいる (Auto Scalingのデモ時)

CloudWatchのAlarm作成

SNSで通知の設定

Alarm起動時に、Auto Scalingのポリシーを起動する設定

CloudWatchデモ: Alarmの作成

CloudWatchデモ: Alarmの作成

CloudWatchデモ: Alarmの作成

CloudWatchデモ: Alarmの作成

Alarmから、Auto Scalingのポリシーを指定

CloudWatchデモ: Alarmの作成

Alarmから、SNSの通知を指定

カスタムメトリクス

カスタムメトリクスを用いると、独自のメトリクスを保存し、モニタリング、グラフ化できる

“mon-put-data”コマンドラインツール “PutMetricData”もしくは、API コール

“mon-list-metrics”でデータを参照

サイズは最大8KB - HTTP GET 40KB for - HTTP POST

Agenda

ELBの詳細

基本説明&デモ

応用編

利用上のTIPS/制約

AutoScalingの詳細

CloudWatchの詳細

まとめ

AWSクラウドデザインパターン(CDP)

Scale Outパターン http://aws.clouddesignpattern.org

ELB使用料金の見積もり例

構成例

ELB1台 + バックエンドにEC2 10インスタンス、1TB転送料

見積もり例

Elastic Load Balancing

• 30日間のELB利用料金 = $18

• 1000GBのELBデータ転送 = $8.00 ($0.008/GB)

(オプション)CloudWatchの詳細監視

10インスタンス x 30日間 = $36.75

見積もりツール http://calculator.s3.amazonaws.com/calc5.html?lng=ja_JP

©2011 Amazon Web Services May not be reused or redistributed without permission

請求通知機能(ビリングアラート)

AWSクラウドの利用料金を監視・通知できるように

©2011 Amazon Web Services May not be reused or redistributed without permission

US EastでしかAlarmが作

れないが、全リージョンの合計金額で監視可能

SNSトピック名、メアド、サービス対象(各サービス/合計)、金額、通知名を入力すれば、

簡単にアラーム作成可能。

メールが飛んでくるのでConfirmが必要。

請求通知機能(ビリングアラート)

$400の利用料金を超えるとこんな通知メールがきます

©2011 Amazon Web Services May not be reused or redistributed without permission

AWSプレミアムサポート アーキテクチャ設計に関するガイダンス、ベストプラクティスも日本語でご案内できます aws.amazon.com/jp/premiumsupport/

Copyright © 2011 Amazon Web Services

ブロンズ シルバー ゴールド プラチナ

初回応答時間 １２時間 ４時間 １時間 １５分

サポート連絡先 １人 ２人 ３人 無制限

24/365対応 なし なし あり あり

TEL可能 不可 不可 可能 可能

専任スタッフ なし なし なし あり

特別サポート なし なし なし あり

料金 $49 AWS利用総額の

5%

AWS利用総額の

$0~$10K: 10%

$10K~$80K: 7%

$80K~: 5%

（最低$400）

AWS利用総額の

10%

（最低$15K）

Q & A

Copyright © 2011 Amazon Web Services

Webセミナー ほぼ週刊AWSマイスターシリーズ Reloaded!

ほぼ週刊AWSマイスターシリーズ

5/21 ELB & CloudWatch & Auto Scaling

5/28 AWS SDK for Java/ AWS Toolkit for Eclipse

さらに続々と！

http://aws.amazon.com/jp/event_schedule/ 申し込みサイト

昨年の資料集 http://aws.amazon.com/jp/aws-meister/

ご参加ありがとう ございました

Copyright © 2011 Amazon Web Services