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

EC2
EC2サーバを
増減するモニタリング
メカニズムゾーンA ゾーンB サービス
CPU利用率
Auto Scaling CloudWatch
アラーム

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

http://aws.amazon.
com/architecture

Agenda

ELBの詳細
 概要説明/デモ/応用機能/利用上のTIPS/制約
AutoScalingの詳細
CloudWatchの詳細

ELB: Elastic Load Balancing
ロードバランサーのクラウドサービス
ELBの特徴
 負荷分散: リクエストを複数のバックエンドのサーバーに分散
 スケーラブル: ELB自体がトラフィックに応じてキャパシティを増減する
 高い可用性: 異なるデータセンター(アベイラビリティゾーン)を跨って、
トラフィックを分配可能
 ヘルスチェック機能: ヘルシーなEC2にのみトラフィックを分配
 安価な従量課金: ロードバランサーを従量課金で利用可能
AWS Management Console、API、コマンドラインツール、SDKでELB
をコントロールできる

ELBの概念図
ユーザー
開発者
クライアント

HTTP / HTTPS /
TCP / SSL

HTTP / HTTPS /
ELB TCP / SSL Web
コンソール

ゾーンA ゾーンB

東京リージョン

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から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証明書の管理
注意：
SSLを用いる場合、
GUIでは証明書の変
ウィザードの中でSSL
更を後からできないが、
の選択/インポート画
CLIでは可能
面が出てくる

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

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/Develop
erGuide/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

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

非常に急激にトラフィックが急増するシステムにELBを用いる
場合は注意
 ELBではキャパシティの増減には時間がかかる。
 ELBのキャパシティ増減が間に合わないほどの急激なトラフィック向
上が予測される場合、ELBのキャパシティ不足が起こる可能性がある

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

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

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

Elastic Load ロードバランサ
Balancing

EC2
EC2サーバを
増減するモニタリング
メカニズムゾーンA ゾーンB サービス
CPU利用率
Auto Scaling CloudWatch
アラーム

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のコマンドラインツール
as-cmdでコマンドの一覧表示

コマンドラインツールのインストールはこちら:
http://aws.amazon.com/developertools/Amazon-EC2/2535

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インスタンスが起動

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

EC2インスタンスが起動

設定をチェック


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

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/AutoScali
ng/latest/APIReference/index.html?API_PutSc
heduledUpdateGroupAction.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
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

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

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

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

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

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

TEL可能不可不可可能可能

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

特別サポートなしなしなしあり
AWS利用総額の
AWS利用総額の
$0~$10K: 10%
AWS利用総額の 10%
料金 $49
5%
$10K~$80K: 7%
$80K~: 5%
＇最低$15K（
＇最低$400（

Q&A


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


ELB & Auto Scaling & CloudWatch 詳細 -ほぼ週刊AWSマイスターシリーズ第5回-

More Related Content

What's hot

Similar to ELB & Auto Scaling & CloudWatch 詳細 -ほぼ週刊AWSマイスターシリーズ第5回-

More from SORACOM, INC

ELB & Auto Scaling & CloudWatch 詳細 -ほぼ週刊AWSマイスターシリーズ第5回-