Upload
amazon-web-services-japan
View
1.224
Download
2
Tags:
Embed Size (px)
DESCRIPTION
2012.3.3 JAWS SUMMIT 2012 マイスターリターンズにて紹介された資料です。
Citation preview
AWSマイスターリターンズ ~ELB, AutoScaling & CloudWatch~
2012年3月3日
松尾康博(@understeer)
ソリューションアーキテクト
玉川 憲( @KenTamagawa ) 技術統括部長
AWSサービス一覧
お客様のアプリケーション
ライブラリ & SDKs Java, PHP, .NET,
Python, Ruby
Web インターフェース
Management Console
IDE プラグイン
Eclipse
Visual Studio
デプロイと自動化 AWS Elastic Beanstalk AWS CloudFormation
認証 & 請求 AWS IAM
Identity Federation Consolidated Billing
モニタリング Amazon CloudWatch
スケーリング Auto Scale
ネットワーク&ルーティング Amazon VPC
Amazon Elastic LB Amazon Route 53
AWS Direct Connect
コンテンツ配信Amazon
CloudFront
メッセージ通知Amazon SNS
分散処理 Elastic MapReduce
メール配信 Amazon SES
コンピュータ処理 Amazon EC2
ストレージ
Amazon S3
Amazon EBS AWS Storage Gateway
データベース Amazon RDS
Amazon DynamoDB Amazon SimpleDB
Amazon Elasticache
AWS のグローバルなインフラ
キューイングAmazon SQS
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
Agenda
ELBの詳細
概要説明/応用機能/利用上のTIPS/制約
AutoScalingの詳細
CloudWatchの詳細
ELB: Elastic Load Balancing
ロードバランサーのクラウドサービス
ELBの特徴
負荷分散: リクエストを複数のバックエンドのサーバーに分散
スケーラブル: ELB自体がトラフィックに応じてキャパシティを増減する
高い可用性: 異なるデータセンター(アベイラビリティゾーン)を跨って、トラフィックを分配可能
ヘルスチェック機能: ヘルシーなEC2にのみトラフィックを分配
安価な従量課金: ロードバランサーを従量課金で利用可能(初期費用無し)
AWS Management Console、API、コマンドラインツール、SDKでELBをコントロールできる
ELBの概念図
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のサポート
IAMを利用してAPIへのアクセス権限設定可能
バックエンドのEC2のセキュリティグループに、 ELBからのトラフィックしか受けない設定が可能
ELBの基本(続き)
SSLのサポート
ELBでSSL Terminationも可能
• ①ELBでSSL Terminationし、バックに復号したものを送信
• ②ELBでSSL Terminationし、バックに別途暗号化して送る
• ③SSLをバイパスしてバックにTCPで送信
SSL証明書をELBで一元管理
• 証明書のアップロードはWebコンソール / IAMのAPI
受け入れるCipherの選択も可能
ELBの基本(続き)
セッションアフィニティ(Session Stickiness)もサポート
ELB作成のcookie / application作成のcookie
X-Forwardedヘッダーをサポート X-Forwarded-Proto, X-Forwarded-Port, X-Forwarded-For, X-
Forwarded-Server, X-Forwarded-Host
ELBの利用上のTIPS
ELBのIPアドレスを直接用いない(Aレコード、ダメ!絶対!)
IPアドレスは変更しうるので、CNAMEを用いる(前述)
ELBの負荷分散の性質に注意
ELB は各 AZ ごとに均等に負荷を割り振ろうとする
ELB は各インスタンスのサイズ・性能は考慮しない
ELBの利用上のTIPS
Management Consoleでサポートしていないが、コマンドラインツール/APIにおいては、サポートしている設定変更あり
ポート追加、証明書変更/削除
既に他のELBに追加されてるインスタンスを、別ELBにも追加
• 利用例: 1つのEC2インスタンスで、複数のバーチャルホストを立てて、異なるポートを利用する ELBを利用して1つのEC2で複数ドメインのHTTPS(SSL) - suz-lab http://blog.suz-lab.com/2011/01/elb1ec2httpsssl.html
ELBの利用上のTIPS
非常に急激にトラフィックが急増するシステムにELBを用いる場合は注意
ELBではキャパシティの増減には時間がかかる。
ELBのキャパシティ増減が間に合わないほどの急激なトラフィック向上が予測される場合、ELBのキャパシティ不足が起こる可能性がある
⇒事前に 営業/プレミアムサポートにご相談ください
現時点の目安: 5分以内で2倍以上のトラフィックが予測される場合
ELBの利用上のTIPS
DNSキャッシングに注意
TTL(60 秒)より長くキャッシュを保持するゲートウェイ、プラットフォームを経由した場合、間違ったDNS設定と似たような状況を引き起こす可能性がある
ELBでは最低60分間はIPアドレスの再利用はしないが、それ以上に渡ってキャッシュされる場合、問題が起こる可能性がある → 営業/プレミアムサポートにご相談ください
ELBの利用上のTIPS
ヘルスチェックが利用するファイルへのアクセス権に注意
バックエンドのサーバーで認証などを行っている際に、ヘルスチェックで設定したファイルが、「HTTPのステータスコードで200番を返さないと」、ヘルスチェックに失敗する
• 対処例: Apache httpdのディレクティブにて:
<Files health_check_file.txt>
Satisfy Any
Allow from all
</Files>
ELBの利用上のTIPS
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
AutoScaingの詳細
Elastic Load
Balancing
CloudWatch Auto Scaling CPU利用率
アラーム
ロードバランサ
モニタリング
サービス
EC2サーバを
増減する
メカニズム ゾーンA ゾーンB
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の3つの基本設定 “Launch Configuration”
起動したいインスタンスのパラメータ設定を行う
どのAMI?、セキュリティグループ?
“Auto Scaling Group”
Auto Scalingさせるグループの設定
どのELBに?どのAZに?
“Scaling Policy”
アラームが発令されたときのスケーリング量の指定
いくつのインスタンス数を増やす?
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
CloudWatch Auto Scaling CPU利用率
アラーム
ロードバランサ
モニタリング
サービス
EC2サーバを
増減する
メカニズム ゾーンA ゾーンB
EC2
CloudWatch
AWSクラウドのリソースをモニタリングするためのWebサービス
CloudWatchの特徴
EC2インスタンス、EBSボリューム、ELB、RDSインスタンス、SNS、SQS、ElastiCache、EMR、DynamoDB等のモニタリングが可能(現時点)
上記以外に、カスタムメトリクスとして、ユーザーが任意のデータを保存、可視化できる
メトリクスをベースにアラームを設定できる
• アラームからAuto Scaling Policy実行、SNSで通知
メトリクスが保存される期間は2週間
CloudWatch
GUI、コマンドラインツール、APIでコントロールできる
CloudWatchの基本モニタリングは無料
EC2は有料にすると1分間隔の詳細モニタリング(無料は5分間隔)
カスタムメトリクス、アラーム、API利用は有料
EC2のプロパティビューのCloudWatchのグラフ
Graphはドリルダウン可能
CloudWatchのダッシュボード
カスタムメトリクス
カスタムメトリクスを用いると、独自のメトリクスを保存し、モニタリング、グラフ化できる
“mon-put-data”コマンドラインツール “PutMetricData”もしくは、API コール
“mon-list-metrics”でデータを参照
サイズは最大8KB - HTTP GET 40KB for - HTTP POST
CloudWatch 料金の見積もり例
構成例
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
©2012 Amazon Web Services May not be reused or redistributed without permission
まとめ
Copyright © 2012 Amazon Web Services
ELB、CloudWatch、Auto Scalingの密接な関係
典型的使用例: 異なるアベイラビリティゾーンに存在するWebサーバー(EC2)の前にELBを利用する。CloudWatchはバックエンドのサーバーの負荷をモニタリングし、定義しておいた設定を満たすとアラームをあげ、Auto Scalingの設定(ポリシー)にそってEC2サーバーを増減させる Elastic Load
Balancing
CloudWatch Auto Scaling CPU利用率
アラーム
ロードバランサ
モニタリング
サービス
EC2サーバを
増減する
メカニズム ゾーンA ゾーンB
EC2
ご参加ありがとう ございました
Copyright © 2012 Amazon Web Services