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

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

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

Agenda

ELBの詳細
 基本説明&デモ
 応用編
 利用上のTIPS/制約
AutoScalingの詳細
CloudWatchの詳細
まとめ

ELB: Elastic Load Balancing
AWSが提供するロードバランサーのクラウドサービス
ELBの特徴
 管理が容易：運用、スケーリングの手間を楽に
 負荷分散: 複数EC2サーバーのみならず、異なるデータセンター(AZ:
アベイラビリティゾーン)を跨って、トラフィックを負荷分散
 高い可用性: ELBそのものが分散システム、監視され耐障害性高い。
複数サーバ/AZに負荷分散でシステムの耐障害性を高める。
 スケーラブル: ELB自体がトラフィックに応じてキャパシティを増減。
負荷にあわせてバックのサーバーを増減させる自動設定可能。
 ヘルスチェック機能: ヘルシーなEC2にのみ、トラフィックを分配
 安価な従量課金: 初期費用無の従量課金で利用可能

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

HTTP / HTTPS /
TCP / SSL

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

EC2 EC2
ゾーンA ゾーンB

東京リージョン

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から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
の選択/インポート画
面が出てくる

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

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

マネージメントコンソールにて、マネージメントコンソールから、
後からリスナーの追加が可能後から、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.c
om/Route53/latest/DeveloperGuid
e/index.html?CreatingAliasRRSets
.html

Session Stickiness
Session Stickiness(セッションアフィニティ)もサポート
 ELB作成のcookie / application作成のcookie

(参考資料) Amazon VPCとは？
AWSクラウド上にプライベートクラウドを構築
 ①社内からVPN接続して閉域網でAWS利用
 ②仮想ネットワーキング
オンプレミスとのハイブリッドが簡単に実現
 AWSが社内インフラの一部に見える
 社内システム、ソフトウェアの移行がより容易に
 例：業務システム、バッチ処理、ファイルサーバ
より細やかにネットワークがコントロール可能
2011年8月から全リージョンで利用可能に

Copyright © 2012 Amazon Web Services 26

お客様のインフラをAWS上に延長する
リージョン EC2内に分離し
VPN たサブネットを
EC2
接続自由に作成
インターネット

イントラ VPC ゲート
ウェイ
プライベートパブリック
サブネットサブネット
NAT

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で監視して通知を行える

ELBの利用上のTIPS
ELBのIPアドレスを直接用いない(Aレコード、ダメ！絶対！)
 IPアドレスは変更する可能性があるのでCNAMEを用いる
高い耐障害性を求めるサイト構築の際は、複数AZを用いて
負荷分散することを推奨
 ELBは、マルチAZの負荷分散に追加料金もかからない
ELBの負荷分散の性質(現時点)に注意
 ELB は、各 AZ に均等に負荷を割り振る
→各AZに均等、同じインスタンスタイプの利用を推奨
 負荷の少ないインスタンスにリクエストを割り振る

ヘルスチェックが利用するファイルへのアクセス権に注意
 バックエンドのサーバーで認証などを行っている際に、ヘルスチェック
で設定したファイルが、「HTTPのステータスコードで200番を返さない
と」、ヘルスチェックに失敗する
• 対処例: Apache httpdのディレクティブにて:

<Files health_check_file.txt>
Satisfy Any
Allow from all
</Files>

ヘルスチェックするページの指定
 “軽いページ”を指定する
Webサーバーが返答するかどうか？

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

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

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

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

DNSキャッシングに注意
TTL(60 秒)より長くキャッシュを保持するゲートウェイ、プラットフォー
ムを経由した場合、間違ったDNS設定と似たような状況を引き起こす
可能性がある
ELBでは最低60分間はIPアドレスの再利用はしないが、それ以上に
渡ってキャッシュされる場合、問題が起こる可能性がある

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

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

Elastic Load ロードバランサ
Balancing

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

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

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

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

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

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

EC2インスタンスが起動

設定をチェック。この後、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

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
→ 営業問い合わせ/プレミアムサポートにご相談ください

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のグラフ
アラームの作成も
各EC2インスタンス
からできるように！

1時間~2週間まで、
グラフの表示期間を変
えられる

詳細(1分間隔)の
モニタリング機能

Graphはドリルダウン可能

CloudWatchのダッシュボード

メトリクスの詳細を見る

メトリクスで見れるもの
EC2 EBS ELB RDS

SNS SQS

Dynamo、SG、EMR
ビリングアラートも！

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

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クラウドの利用料金を監視・通知できるように
SNSトピック名、メアド、サー
ビス対象(各サービス/合計)、
金額、通知名を入力すれば、
簡単にアラーム作成可能。
メールが飛んでくるので
Confirmが必要。

US EastでしかAlarmが作
れないが、全リージョンの
合計金額で監視可能


請求通知機能(ビリングアラート)
$400の利用料金を超えるとこんな通知メールがきます


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


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/

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


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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie ELB & CloudWatch & AutoScaling - AWSマイスターシリーズ

Ähnlich wie ELB & CloudWatch & AutoScaling - AWSマイスターシリーズ (20)

Mehr von Amazon Web Services Japan

Mehr von Amazon Web Services Japan (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)

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