elb & auto scaling & cloudwatch 詳細 -ほぼ週刊awsマイスターシリーズ第5回-

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

2011年10月26日

玉川憲＇ @KenTamagawa （エバンジェリスト 2011年10月27日更新 v.1.1

ほぼ週刊AWSマイスターシリーズへようこそ！ ~GoToMeetingの使い方～

参加者は、自動的にミュートになっています

質問を投げることができます！

GoToMeetingの仕組みを使って、随時書き込んでください

ただし環境によっては、日本語の直接入力ができないので、

お手数ですが、テキストエディタ等に打ち込んでから、

貼り付けててください

最後のＱ＆Ａの時間で、できるだけ回答させて頂きます

書き込んだ質問は、主催者にしか見えません

Twitterのハッシュタグは#jawsugでどうぞ

Copyright © 2011 Amazon Web Services

Webセミナー

ほぼ週刊AWSマイスターシリーズ＇全10回（

10/26 第5回 ELB, AutoScaling & CloudWatch

11/1 第6回 CloudFormation

11/9 第7回 VPC

11/16 第8回 RDS

11/22 第9回 EMR

11/30 第10回 SES

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

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!!

http://aws.amazon.

com/architecture

http://aws.amazon.com/architecture



Agenda

ELBの詳細

概要説明/デモ/応用機能/利用上のTIPS/制約

AutoScalingの詳細

CloudWatchの詳細

ELB: Elastic Load Balancing

ロードバランサーのクラウドサービス

ELBの特徴

負荷分散: リクエストを複数のバックエンドのサーバーに分散

スケーラブル: ELB自体がトラフィックに応じてキャパシティを増減する

高い可用性: 異なるデータセンター(アベイラビリティゾーン)を跨って、トラフィックを分配可能

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

安価な従量課金: ロードバランサーを従量課金で利用可能

AWS Management Console、API、コマンドラインツール、SDKでELBをコントロールできる

ELBの概念図

ゾーンA ゾーンB

東京リージョン

ELB

ユーザー

クライアント

Web コンソール

開発者

HTTP / HTTPS /

TCP / SSL

HTTP / HTTPS /

TCP / SSL

ELBの基本

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

ELBを使用するときには、DNS名を用いる

ELBのDNS名を用いて使用する例: hanako-12345678.ap-northeast-1.elb.amazonaws.com

独自ドメイン名を利用する際は、名前解決にCNAMEを用いる (IPアドレスを直接使うAレコードを使わない)

CNAMEを用いる副作用として、通常のDNSではZone Apex(例: example.com)がサポートできないが、Route 53のAAレコードを用いればサポート可能

ELBの基本

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

HTTP、HTTPS、SSL、TCP

ELBのフロントエンド、ELBからバックエンドにおいて、違うポートを用いることができる

CloudWatchとの統合

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

レイテンシー

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

IPv4とIPv6のサポート (10月27日に東京リージョンもサポート)

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

バックエンドのEC2のセキュリティグループに、 ELBからのトラフィックしか受けない設定が可能

ELBの基本(続き)

SSLのサポート

ELBでSSL Terminationも可能

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

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

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

SSL証明書をELBで一元管理

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

受け入れるCipherの選択も可能

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

ELB作成のcookie / application作成のcookie

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

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

ELBの基本(続き)

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

ELB作成のcookie / application作成のcookie

X-Forwardedヘッダーをサポート X-Forwarded-Proto, X-Forwarded-Port, X-Forwarded-For, X-

Forwarded-Server, X-Forwarded-Host

(10月27日更新) ELBのDNS名が複数のIPアドレスを返すように

ELBのデモ

AWS Management Consoleから、ELBのウィザードを使って、ELBを作成

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

ヘルスチェックの設定

バックエンドのEC2を選択

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

デモ: ELBの作成

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

ELBからEC2へは

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

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

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

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

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

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

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

デモ：作成確認画面

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

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

ELBからのインバウン

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

ELBの応用編

ELBのSSLサポート

Zone Apexのサポート

Session Stickiness

ELBでのSSLサポート

SSLのサポート

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

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

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

ELBでのSSL証明書の管理注意：

GUIでは証明書の変

更を後からできないが、CLIでは可能

SSLを用いる場合、ウィザードの中でSSL

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

Cipherの選択

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

Zone Apexのサポート

Zone Apex(ゾーン頂点、)はCNAMEでサポートできないが、Route 53は独自にサポートしている

回避策

Route 53のAAレコードを用いる

http://aws.typepad.com/aws_japan/2011/05/moving-ahead-with-amazon-route-53.html

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

EIPを持ったEC2で、ルートドメインに対するトラフィックをELBにリダイレクトする

http://developer.amazonwebservices.com/connect/thread.jspa?threadID=32044

http://shlomoswidler.com/2011/01/aws-auto-scaling-and-elb-with-reliable-root-domain-handling.html














http://developer.amazonwebservices.com/connect/thread.jspa?threadID=32044




















Session Stickinessの利用

ELBの利用上のTIPS

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

IPアドレスは変更しうるので、CNAMEを用いる(前述)

ELBの負荷分散の性質に注意

ELB は各 AZ ごとに均等に負荷を割り振ろうとする

ELB は各インスタンスのサイズは考慮しない


Management Consoleでサポートしていないが、コマンドラインツール/APIにおいては、サポートしている設定変更あり

ポート追加、証明書変更/削除

既に他のELBに追加されてるインスタンスを、別ELBにも追加

• 利用例: 1つのEC2インスタンスで、複数のバーチャルホストを立てて、異なるポートを利用する ELBを利用して1つのEC2で複数ドメインのHTTPS(SSL) - suz-lab http://blog.suz-lab.com/2011/01/elb1ec2httpsssl.html

http://blog.suz-lab.com/2011/01/elb1ec2httpsssl.html




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

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

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

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

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

http://aws.amazon.com/jp/contact-us/aws-sales/

http://aws.amazon.com/jp/premiumsupport/


DNSキャッシングに注意

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

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




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

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

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

<Files health_check_file.txt>

Satisfy Any

Allow from all

</Files>


SSL証明書のライセンス

技術的には1つの証明書をELBにインストールして、それをバックエンドの複数のEC2インスタンスで用いることができます。ライセンスに関しては、ドメイン単位/サーバー単位で発行など、ベンダーによって異なるのでご確認ください

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

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

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

http://blog.apps.chicagotribune.com/2010/07/08/bees-with-machine-guns/








ELBの利用上の制約

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

ELB そのものに対するアクセス制限はできない

バックエンドのEC2側に関しては、ELBからのトラフィックしか受けないように調整できる(前述)

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

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

ELBに対してEIPを割り当てる機能は現時点でサポートしておりません (沢山のお客様からご要望頂いております！！)

ELBのリミット

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

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

http://aws.amazon.com/jp/contact-us/



AutoScaingの詳細

Elastic Load

Balancing


アラーム


モニタリング

サービス

EC2サーバを

増減する


EC2

AS: AutoScaling

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

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

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

典型的なユースケース

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

自動リカバリ: 不健全なサーバーを除き、キャパシティを保つ

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

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

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

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

AS: AutoScaling

Auto Scalingのその他特徴

ELB連携: ELB配下にてEC2インスタンスを増減させる

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

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

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

現時点で、AWS Management Consoleの設定はないので、コマンドラインツール、もしくはAPIで設定を行う必要がある

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に？

“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のデモ

事前準備

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


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で動作させておくことに注意)


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

ap-northeast-1

EC2インスタンスが起動


EC2インスタンスが起動

手動で、desired capacityを切り替えてみる

設定をチェック


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

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コマンドを用いる


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




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

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



CloudWatchの詳細

Elastic Load

Balancing


アラーム


モニタリング

サービス

EC2サーバを

増減する


EC2

CloudWatch

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

CloudWatchの特徴

EC2インスタンス、EBSボリューム、ELB、RDSインスタンス、SNS、SQS、ElastiCacheのモニタリングが可能(現時点)

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

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

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

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

CloudWatch

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

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

EC2は有料にすると1分間隔の詳細モニタリング(無料は5分間隔)

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

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

Graphはドリルダウン可能

CloudWatchのダッシュボード

メトリクスの詳細を見る

メトリクスで見れるもの

EC2 EBS ELB RDS

SNS SQS

Using CloudWatch API Tools

CloudWatchのデモ

事前準備

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

CloudWatchのAlarm作成

SNSで通知の設定

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

CloudWatchデモ: Alarmの作成


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


Alarmから、SNSの通知を指定

カスタムメトリクス

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

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

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

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

料金の見積もり例

構成例

ELB1台 + バックエンドにEC2 10インスタンス

CloudWatch の詳細モニタリングでAuto Scaling

見積もり例

Elastic Load Balancing

• 30日間 = $18

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

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

• 10インスタンス x 30日間 = $108

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

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

http://calculator.s3.amazonaws.com/calc5.html?lng=ja_JP

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

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

Balancing


アラーム


モニタリング

サービス

EC2サーバを

増減する


EC2

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


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

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

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

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

TEL可能不可不可可能可能

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

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

料金 $49 AWS利用総額の

5%

AWS利用総額の

$0~$10K: 10%

$10K~$80K: 7%

$80K~: 5%

＇最低$400（

AWS利用総額の

10%

＇最低$15K（

Q & A


Webセミナー

ほぼ週刊AWSマイスターシリーズ＇全10回（ 10/26 第5回 ELB, AutoScaling & CloudWatch

11/1 第6回 CloudFormation

11/9 第7回 VPC

11/16 第8回 RDS

11/22 第9回 EMR

11/30 第10回 SES

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

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


elb & auto scaling & cloudwatch 詳細 -ほぼ週刊awsマイスターシリーズ第5回-

Technology