20120303 jaws summit-meister-02_elb-as-cw

1,463 views

Published on

2012.3.3 JAWS SUMMIT 2012 
マイスターリターンズにて紹介された資料です。

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,463
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
33
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

20120303 jaws summit-meister-02_elb-as-cw

  1. 1. AWSマイスターリターンズ~ELB, AutoScaling & CloudWatch~ 2012年3月3日 松尾康博(@understeer) ソリューションアーキテクト 玉川 憲( @KenTamagawa ) 技術統括部長
  2. 2. AWSサービス一覧 お客様のアプリケーション ライブラリ & SDKs IDE プラグイン デプロイと自動化 Web インターフェース Java, PHP, .NET, Eclipse AWS Elastic Beanstalk Python, Ruby Management Console AWS CloudFormation Visual Studio ネットワーク&ルーティング 認証 & 請求 Amazon VPC AWS IAM モニタリング スケーリング Amazon Elastic LB Identity Federation Amazon CloudWatch Auto Scale Amazon Route 53 Consolidated Billing AWS Direct Connect コンテンツ配信 メッセージ通知 キューイング 分散処理 メール配信 Amazon Amazon SNS Amazon SQS Elastic MapReduce Amazon SES CloudFront ストレージ データベース コンピュータ処理 Amazon S3 Amazon RDS Amazon DynamoDB Amazon EC2 Amazon EBS Amazon SimpleDB AWS Storage Gateway Amazon Elasticache AWS のグローバルなインフラ
  3. 3. ELB、CloudWatch、Auto Scalingの密接な関係典型的使用例: 異なるアベイラビリティゾーンに存在するWebサーバー(EC2)の前にELBを利用する。CloudWatchはバックエンドのサーバーの負荷をモニタリングし、定義しておいた設定を満たすとアラームをあげ、Auto Scalingの設定(ポリシー)にそってEC2サーバーを増減させる Elastic Load ロードバランサ Balancing EC2EC2サーバを増減する モニタリングメカニズム ゾーンA ゾーンB サービス CPU利用率 Auto Scaling CloudWatch アラーム
  4. 4. マイスター的、他のサービスとの位置づけ①静的コンテンツは、S3とCloudFrontで!(楽だし簡単)②動的コンテンツで、EC2でのスケールアウト/インが必要なときはELB!! http://aws.amazon. com/architecture
  5. 5. Agenda ELBの詳細  概要説明/応用機能/利用上のTIPS/制約 AutoScalingの詳細 CloudWatchの詳細
  6. 6. ELB: Elastic Load Balancing ロードバランサーのクラウドサービス ELBの特徴  負荷分散: リクエストを複数のバックエンドのサーバーに分散  スケーラブル: ELB自体がトラフィックに応じてキャパシティを増減する  高い可用性: 異なるデータセンター(アベイラビリティゾーン)を跨って、 トラフィックを分配可能  ヘルスチェック機能: ヘルシーなEC2にのみトラフィックを分配  安価な従量課金: ロードバランサーを従量課金で利用可能(初期費用 無し) AWS Management Console、API、コマンドラインツール、SDKでELB をコントロールできる
  7. 7. ELBの概念図
  8. 8. 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レコードを 用いればサポート可能
  9. 9. ELBの基本 サポートしているプロトコル  HTTP、HTTPS、SSL、TCP  ELBのフロントエンド、ELBからバックエンドにおいて、 違うポートを用いることができる CloudWatchとの統合  リクエスト数(HTTP 2xx-5xx)  レイテンシー  ヘルシー、アンヘルシーなEC2インスタンス数 IPv4とIPv6のサポート IAMを利用してAPIへのアクセス権限設定可能 バックエンドのEC2のセキュリティグループに、 ELBからのトラフィックしか受けない設定が可能
  10. 10. ELBの基本(続き) SSLのサポート  ELBでSSL Terminationも可能 • ①ELBでSSL Terminationし、バックに復号したものを送信 • ②ELBでSSL Terminationし、バックに別途暗号化して送る • ③SSLをバイパスしてバックにTCPで送信  SSL証明書をELBで一元管理 • 証明書のアップロードはWebコンソール / IAMのAPI  受け入れるCipherの選択も可能
  11. 11. ELBの基本(続き) セッションアフィニティ(Session Stickiness)もサポート  ELB作成のcookie / application作成のcookie X-Forwardedヘッダーをサポート  X-Forwarded-Proto, X-Forwarded-Port, X-Forwarded-For, X- Forwarded-Server, X-Forwarded-Host
  12. 12. ELBの利用上のTIPS ELBのIPアドレスを直接用いない(Aレコード、ダメ!絶対!)  IPアドレスは変更しうるので、CNAMEを用いる(前述) ELBの負荷分散の性質に注意  ELB は各 AZ ごとに均等に負荷を割り振ろうとする  ELB は各インスタンスのサイズ・性能は考慮しない
  13. 13. 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
  14. 14. ELBの利用上のTIPS 非常に急激にトラフィックが急増するシステムにELBを用いる 場合は注意  ELBではキャパシティの増減には時間がかかる。  ELBのキャパシティ増減が間に合わないほどの急激なトラフィック向 上が予測される場合、ELBのキャパシティ不足が起こる可能性がある ⇒事前に 営業/プレミアムサポートにご相談ください  現時点の目安: 5分以内で2倍以上のトラフィックが予測される場合
  15. 15. ELBの利用上のTIPS DNSキャッシングに注意 TTL(60 秒)より長くキャッシュを保持するゲートウェイ、プラットフォー ムを経由した場合、間違ったDNS設定と似たような状況を引き起こす 可能性がある ELBでは最低60分間はIPアドレスの再利用はしないが、それ以上に 渡ってキャッシュされる場合、問題が起こる可能性がある → 営業/プレミアムサポートにご相談ください
  16. 16. ELBの利用上のTIPS ヘルスチェックが利用するファイルへのアクセス権に注意  バックエンドのサーバーで認証などを行っている際に、ヘルスチェック で設定したファイルが、「HTTPのステータスコードで200番を返さない と」、ヘルスチェックに失敗する • 対処例: Apache httpdのディレクティブにて: <Files health_check_file.txt> Satisfy Any Allow from all </Files>
  17. 17. ELBの利用上のTIPS SSL証明書のライセンス 技術的には1つの証明書をELBにインストールして、それをバックエン ドの複数のEC2インスタンスで用いることができます。ライセンスに関 しては、ドメイン単位/サーバー単位で発行など、ベンダーによって異 なるのでご確認ください ELBのTCPコネクションは60秒後にTerminateされます 60秒以上の待ち時間が発生する場合は、アプリケーション側で非同 期プロセスをするなど工夫が必要 ELBの負荷テストは要注意。例えば、下記を参照  http://blog.apps.chicagotribune.com/2010/07/08/bees- with-machine-guns/
  18. 18. 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
  19. 19. AutoScaingの詳細
  20. 20. Elastic Load ロードバランサ Balancing EC2EC2サーバを増減する モニタリングメカニズム ゾーンA ゾーンB サービス CPU利用率 Auto Scaling CloudWatch アラーム
  21. 21. AS: AutoScaling 定義しておいた設定にあわせて、EC2の台数を増減させることのできるメ カニズム  サーバーを不要時は落とし、必要時は増加させ、コスト効率を改善  運用を簡易化、自動化する 典型的なユースケース  ピーク対応: リクエストにあわせてキャパシティを増減させる  自動リカバリ: 不健全なサーバーを除き、キャパシティを保つ スケールさせるためのメカニズム  マニュアル – コマンドラインツール/APIで変更を指定  スケジュール – 希望時刻にあわせてスケールさせる  ポリシーベース-ポリシーを設定しておき、そのポリシーを CloudWatchのアラーム等で起動する
  22. 22. AS: AutoScaling Auto Scalingのその他特徴  ELB連携: ELB配下にてEC2インスタンスを増減させる  通知機能: SNSを利用してアクション実行時に通知送信  ヘルスチェック機能: EC2の状態をチェックする AutoScalingの設定そのもののコストはかからない 現時点で、AWS Management Consoleの設定はない ので、コマンドラインツール、もしくはAPIで設定を行う必要 がある
  23. 23. Auto Scalingが実行するタスク 下記のタスクを実行できる  Launch: インスタンスの起動を行う  Terminate: インスタンスを終了する  HealthCheck: 各インスタンスのヘルスチェックを行う  ReplaceUnhealthy: 不健全なインスタンスを入れ替える  AddToLoadBalancer: 指定したELBにインスタンスを追加する  AZRebalance: AZ間のインスタンスのバランスをとる  AlarmNotification: 起動/終了の通知を送る  ScheduledActions: スケジュールしていたアクションを実行する
  24. 24. Auto Scalingの3つの基本設定 “Launch Configuration”  起動したいインスタンスのパラメータ設定を行う  どのAMI?、セキュリティグループ? “Auto Scaling Group”  Auto Scalingさせるグループの設定  どのELBに?どのAZに? “Scaling Policy”  アラームが発令されたときのスケーリング量の指定  いくつのインスタンス数を増やす?
  25. 25. Auto Scaling利用時のTIPS インスタンスが起動しないときのチェック項目  設定が間違っている(設定したリソースがおかしい。ELB名?)  制限を超えている(インスタンス数の20の初期リミット等)  原因を確かめるために、as-describe-scaling-activities を用いよう なぜ、勝手にインスタンスが終了するの??  ヘルスチェック  リバランス  こちらも、原因を確かめるために、as-describe-scaling-activities を用いよう
  26. 26. Auto Scaling利用時のTIPS(続き) インスタンスがトラフィックを受け付けない  ELBのAZ設定が、Auto ScalingのAZ設定と異なっている →同じである必要がある Auto Scaling配下のEC2インスタンスのTerminateされる順序 は、指定できない  現時点では、Terminateの順番は指定できません。基本的には、一 番古い起動コンフィグで立ち上がった、課金タイミングの終わりに近 いものが terminate されます
  27. 27. Auto Scalingの制約 Auto Scalingのリミット  100 Launch Configurations  20 Auto Scaling Groups  125 Actions  50 Policies  20 SNS Topics → 営業問い合わせ/プレミアムサポートにご相談ください
  28. 28. CloudWatchの詳細
  29. 29. Elastic Load ロードバランサ Balancing EC2EC2サーバを増減する モニタリングメカニズム ゾーンA ゾーンB サービス CPU利用率 Auto Scaling CloudWatch アラーム
  30. 30. CloudWatch AWSクラウドのリソースをモニタリングするためのWebサービス CloudWatchの特徴  EC2インスタンス、EBSボリューム、ELB、RDSインスタンス、 SNS、SQS、ElastiCache、EMR、DynamoDB等のモニタリン グが可能(現時点)  上記以外に、カスタムメトリクスとして、ユーザーが任意のデータ を保存、可視化できる  メトリクスをベースにアラームを設定できる • アラームからAuto Scaling Policy実行、SNSで通知  メトリクスが保存される期間は2週間
  31. 31. CloudWatch GUI、コマンドラインツール、APIでコントロールできる CloudWatchの基本モニタリングは無料  EC2は有料にすると1分間隔の詳細モニタリング(無料は5分間隔)  カスタムメトリクス、アラーム、API利用は有料
  32. 32. EC2のプロパティビューのCloudWatchのグラフ
  33. 33. Graphはドリルダウン可能
  34. 34. CloudWatchのダッシュボード
  35. 35. カスタムメトリクス カスタムメトリクスを用いると、独自のメトリクスを保存し、モニタリ ング、グラフ化できる “mon-put-data”コマンドラインツール “PutMetricData”もしくは、API コール “mon-list-metrics”でデータを参照 サイズは最大8KB - HTTP GET 40KB for - HTTP POST
  36. 36. 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
  37. 37. まとめCopyright © 2012 Amazon Web Services
  38. 38. ELB、CloudWatch、Auto Scalingの密接な関係典型的使用例: 異なるアベイラビリティゾーンに存在するWebサーバー(EC2)の前にELBを利用する。CloudWatchはバックエンドのサーバーの負荷をモニタリングし、定義しておいた設定を満たすとアラームをあげ、Auto Scalingの設定(ポリシー)にそってEC2サーバーを増減させる Elastic Load ロードバランサ Balancing EC2EC2サーバを増減する モニタリングメカニズム ゾーンA ゾーンB サービス CPU利用率 Auto Scaling CloudWatch アラーム
  39. 39. ご参加ありがとう ございました Copyright © 2012 Amazon Web Services

×