AWS Black Belt Techシリーズ Amazon CloudWatch & Auto Scaling
•
51 likes•25,708 views
AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ) Amazon CloudWatch & Auto Scaling
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to AWS Black Belt Techシリーズ Amazon CloudWatch & Auto Scaling
Similar to AWS Black Belt Techシリーズ Amazon CloudWatch & Auto Scaling (20)
More from Amazon Web Services Japan
More from Amazon Web Services Japan (20)
Recently uploaded
Recently uploaded (10)
AWS Black Belt Techシリーズ Amazon CloudWatch & Auto Scaling
- 1. Amazon CloudWatch & Auto Scaling AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ) アマゾンデータサービスジャパン株式会社 ⼭山本教仁
- 2. 2 Agenda • Amazon CloudWatch • Auto Scaling
- 4. 4 Amazon CloudWatchとは？ AWSの各種リソースをモニタリングするためのWebサービス 状況を レポート CloudWatch
- 5. 5 CloudWatchができること • 各AWSサービスのメトリックス監視 – メトリックス = 監視項⽬目（例例：CPU使⽤用率率率） – メトリックスはあらかじめ定義され、構成済み • サービス開始時から監視開始 • EC2ではハイパーバイザーから監視できる項⽬目 – メトリックスを追加定義も可能 • カスタムメトリックス – メトリックス値を時系列列にグラフ表⽰示 • 各メトリックスに対してアラームを作成可能 – しきい値を設定（例例：CPU使⽤用率率率60%以上） – メトリックス値がしきい値を越えたら起こすアクションを定義（例例：メールで通知） • EC2上のログ監視 ・・・Amazon CloudWatch Logs – メトリックスとアラームも作成可能 – 詳細は近⽇日BlackBeltでご紹介
- 6. 6 CloudWatchができること：メトリックス監視 • CloudWatch監視対象サービス – EC2 – EBS – ELB – Auto Scaling – RDS – DynamoDB – ElastiCache – EMR – OpsWorks – Redshift – Route 53 – CloudFront – SNS – SQS – SWF – Storage Gateway – Billing • メトリックス例例 EC2のメトリックスELBのメトリックス CPUCreditBalance CPUCreditUsage CPUUtilization DiskReadBytes DiskReadOps DiskWriteBytes DiskWriteOps NetworkOut NetworkIn StatusCheckFailed_̲Instance StatusCheckFailed StatusCheckFailed_̲System VolumeIdleTime VolumeQueueLength VolumeReadOps VolumeReadBytes VolumeTotalReadTime VolumeWriteBytes VolumeWriteOps VolumeTotalWriteTime Latency BackendConnectionErrors HealthyHostCount UnHealthyHostCount RequestCount HTTPCode_̲ELB_̲5XX HTTPCode_̲Backend_̲4XX CPUUtilization FreeableMemory SwapUsage FreeStorageSpace DiskQueueDepth ReadIOPS ReadThroughput ReadLatency NetworkReceiveThroughput NetworkTransmitThroughput WriteIOPS WriteThroughput WriteLatency DatabaseConnections BinLogDiskUsage EBSのメトリックス RDSのメトリックス
- 7. 7 CloudWatch利利⽤用イメージ：メトリックス監視 i-‐‑‒xxxxxxxx i-‐‑‒xxxxxxxx 対象インスタンス を検索索 メトリックスを 選択 グラフ表⽰示期間 の指定 アラーム状態 の表⽰示
- 8. 8 CloudFront対応・・・New! US East (N. Virginia) で閲覧可能
- 9. 9 CloudWatchができること：アラーム • アラーム設定 – メトリックス（e.g. CPU使⽤用率率率）としきい値（e.g. 60%以上）で構成 – 3つのアラーム状態を管理理 • OK– メトリックスの値が、定義されたしきい値を下回っている • ALARM – メトリックスの値が、定義されたしきい値を上回っている • INSUFFICIENT_̲DATA – アラームが開始直後であるか、メトリックスが利利⽤用できないか、データが不不⾜足していていア ラームの状態を判定できない – 各アラーム状態に対してアクションを定義可能 • 通知（Notification） – Amazon Simple Notification Service（SNS）を使って通知 – メール送信やHTTP(S)送信、Amazon Simple Queue Service（SQS）への送信が可能 • Auto Scalingアクション – Auto Scaling GroupのScaling Policyを指定し、インスタンスのスケールアウト／インが可能 • EC2アクション – EC2インスタンスの停⽌止およびTerminateが可能
- 10. 10 CloudWatch利利⽤用イメージ：アラーム設定 しきい値として、 CPU使⽤用率率率70%以上が 3期間（ここでは1期間＝5分）以上 アクション定義 AutoScalingGroup アラーム設定
- 11. 11 CloudWatch利利⽤用イメージ：Billingアラーム設定 US East (N. Virginia) で全リージョンの合計⾦金金額を提供 何ドルを越えたら どこにメールするかを設定
- 12. 12 カスタムメトリックス • 独⾃自のメトリックスを保存し、モニタリング、グラフ化できる – AWS CLIの”put-‐‑‒metric-‐‑‒data”、API Toolsの”mon-‐‑‒put-‐‑‒data”、もしくは”PutMetricData” APIでデータを登録 – “list-‐‑‒metrics”でメトリックス定義を参照 – “get-‐‑‒metric-‐‑‒statistics”でデータを参照 – サイズ制限として、HTTP GETは8KB、HTTP POSTは40KB、1つのPutMetricDataリクエ ストに20データまで $ aws cloudwatch put-‐‑‒metric-‐‑‒data –metric-‐‑‒name RequestLatency -‐‑‒-‐‑‒namespace GetStarted“ -‐‑‒-‐‑‒timestamp 2014-‐‑‒10-‐‑‒28T12:30:00Z -‐‑‒-‐‑‒value 87 -‐‑‒-‐‑‒unit Milliseconds $ aws cloudwatch put-‐‑‒metric-‐‑‒data -‐‑‒-‐‑‒metric-‐‑‒name RequestLatency¥ -‐‑‒-‐‑‒namespace GetStarted“¥ -‐‑‒-‐‑‒timestamp 2014-‐‑‒10-‐‑‒28T12:30:00Z -‐‑‒-‐‑‒statistic-‐‑‒value Sum=60,Minimum=15,Maximum=105,SampleCount=5 GetStartedという 架空のアプリケーションの 指定した時刻のRequest Latencyを登録する例例 単⼀一値の登録と 統計セットの登録例例
- 13. 13 カスタムメトリックス • データの参照 – “get-‐‑‒metric-‐‑‒statistics”でデータを参照 $ aws cloudwatch get-‐‑‒metric-‐‑‒statistics -‐‑‒-‐‑‒metric-‐‑‒name RequestLatency”¥ -‐‑‒-‐‑‒namespace GetStarted”¥ -‐‑‒-‐‑‒statistics Average”¥ -‐‑‒-‐‑‒start-‐‑‒time 2014-‐‑‒10-‐‑‒28T12:30:00Z¥ -‐‑‒-‐‑‒end-‐‑‒time 2014-‐‑‒10-‐‑‒28T12:30:00Z -‐‑‒-‐‑‒period 300 – マネージメントコンソール
- 14. 14 サンプルスクリプトの提供 • OSでしか取れない情報をカスタムメトリックスとしてCloudWatch に登録するサンプルスクリプトを提供 – メモリ利利⽤用率率率、ディスク利利⽤用率率率、など – Cronなどで実⾏行行可 – 5分おきにメモリ利利⽤用率率率とディスク利利⽤用率率率を登録するcronの設定例例 */5 * * * * ~∼/aws-‐‑‒scripts-‐‑‒mon/mon-‐‑‒put-‐‑‒instance-‐‑‒data.pl -‐‑‒-‐‑‒mem-‐‑‒util -‐‑‒-‐‑‒disk-‐‑‒space-‐‑‒util -‐‑‒-‐‑‒disk-‐‑‒path=/ -‐‑‒-‐‑‒from-‐‑‒cron • LinuxとWindows向けに提供 – Linux • http://aws.amazon.com/code/8720044071969977 – Windows • http://aws.amazon.com/code/7932034889155460
- 15. 15 サンプルスクリプト設定例例 • サンプルスクリプトをEC2のUserDataに定義 – CloudWatchのput権限を与えたIAM Roleを付与 – User Dataに下のように定義 – EC2起動時から⾃自動的にメモリとディスク利利⽤用率率率をCloudWatchで監視 #!/bin/sh cd /home/ec2-‐‑‒user wget http://ec2-‐‑‒downloads.s3.amazonaws.com/cloudwatch-‐‑‒samples/CloudWatchMonitoringScripts-‐‑‒v1.1.0.zip unzip CloudWatchMonitoringScripts-‐‑‒v1.1.0.zip rm CloudWatchMonitoringScripts-‐‑‒v1.1.0.zip chown ec2-‐‑‒user:ec2-‐‑‒user aws-‐‑‒scripts-‐‑‒mon echo */5 * * * * ec2-‐‑‒user /home/ec2-‐‑‒user/aws-‐‑‒scripts-‐‑‒mon/mon-‐‑‒put-‐‑‒instance-‐‑‒data.pl -‐‑‒-‐‑‒mem-‐‑‒util -‐‑‒-‐‑‒disk-‐‑‒space-‐‑‒util -‐‑‒-‐‑‒disk-‐‑‒path=/ -‐‑‒-‐‑‒from-‐‑‒cron /etc/crontab
- 16. 16 CloudWatchの特徴と注意点 • 標準監視は設定不不要で無料料 • 監視項⽬目の追加も可能 – 標準メトリックスで取得できない監視項⽬目は追加が必要 • アラーム設定により通知可能 • メトリックスデータの保管は2週間まで – 2週間以上保存する場合は、get-‐‑‒metric-‐‑‒statisticsでデータを取得し別の場所に保管し ておく – CloudWatch Logsのログの保管は無期限含めた⻑⾧長期保管可能 • データ保管粒粒度度は最短で1分間隔 – 1分間でのAverage、Maximum、Minimum、サンプル数が記録されていく • APIコールにスロットリングあり – カスタムメトリックスの頻繁な登録や頻度度の⾼高いデータ取得には注意
- 17. 17 監視システムでのCloudWatch活⽤用例例 • 既存の監視システムを使いたい場合、CloudWatchとの連携が必要 • CloudWatchだけでは監視要求が満たされないと判断される場合も、 カスタムメトリックス、CloudWatch Logs、もしくはサードパーティツール と組み合わせての監視が必要 組み合わせ例例 監視要求項⽬目 本番環境検証環境 EC2RDSEC2RDS ホスト（Ping）サードパーティツールCloudWatch※CloudWatch※CloudWatch※ CPUサードパーティツールCloudWatchCloudWatchCloudWatch メモリサードパーティツールCloudWatchCloudWatchCloudWatch ディスクI/OサードパーティツールCloudWatchCloudWatchCloudWatch ディスク使⽤用量量サードパーティツールCloudWatchCloudWatchCloudWatch ネットワークサードパーティツールCloudWatchCloudWatchCloudWatch プロセスサードパーティツールCloudWatchなしCloudWatch ポート／サービスCloudWatch ELBCloudWatchなしCloudWatch ログサードパーティツールスクリプトなしなし ※アラーム状態情報（OKかINSUFFICIENTか）で代替
- 18. 18 監視システムでのCloudWatch活⽤用例例 監視システムでのCloudWatch活⽤用イメージ 統合監視 専⽤用線 接続 AgentAgent Cloud Watch サードパーティ監視ツール の確認ポイント • AWSに対応しているか • CloudWatchとの連携機能が あるか • CloudWatchカスタム メトリックスに対応しているか • Auto Scalingに対応しているか • EC2インスタンス⾃自動検出／ ⾃自動削除に対応しているか
- 19. 19 CloudWatchの料料⾦金金 • 初期費⽤用無しの従量量課⾦金金 • 標準の監視は無料料 – EC2インスタンスの標準監視（5分間隔） – EBS、ELB、RDSは1分間隔が無料料 • アラームやカスタムメトリックスは⼀一定数まで無料料 – 10メトリックス、10 アラーム、および100万APIリクエスト – 1 か⽉月あたり5GBのデータの取り込みおよび5GBのアーカイブされたストレー ジ • 課⾦金金対象及び料料⾦金金（2014年年10⽉月現在 Tokyoリージョン） – EC2詳細モニタリング1インスタンスにつき$3.50/⽉月 – カスタムメトリックス1つにつき$0.50/⽉月 – アラーム1つにつき$0.10/⽉月 – APIリクエスト1000回につき$0.01（Get, List, Putごとに） 最新の料料⾦金金情報は、http://aws.amazon.com/jp/cloudwatch/pricing/
- 20. Auto Scaling
- 21. 21 Auto Scalingとは • トリガーを受けてEC2インスタンス数を⾃自動的に増減させる仕組み – パフォーマンス維持やキャパシティ増強、コスト削減のために利利⽤用可能 CloudWatchAuto scaling Group Alarm Auto Scaling Elastic Load Balancing ①リソース監視 ②しきい値を越えたら アラーム ④結果として新規にサーバが デプロイされる ③アラームのアクションに 登録されたASアクションが起動
- 22. 22 Auto Scalingの典型的な利利⽤用ケース • 負荷分散ELB配下のWebサーバ • SQSからジョブを取ってバッチ実⾏行行するワーカ Elastic Load BalancingSimple Queue Service WebサーバのAuto Scaling Group CPU使⽤用率率率やELBのRequest数などを トリガーにする ワーカ（バッチ）のAuto Scaling Group SQSのキューに溜溜まっているメッセージ数などを トリガーにする
- 23. 23 Netflixでの活⽤用例例 リクエスト数の増減に応じた インスタンス数の増減 リクエスト数の推移 インスタンス数の推移 CPU利利⽤用率率率 Netflix techblogより： http://techblog.netflix.com/2012/01/ auto-‐‑‒scaling-‐‑‒in-‐‑‒amazon-‐‑‒cloud.html
- 24. 24 Auto Scalingの基本的な動き Auto Scaling Groupの中で最低台数（Min値）維持 CloudWatchのアラームをトリガーとして受ける Auto Scaling Policyに応じて、 対象のEC2インスタンス群に対し何台増やすか決める 指定されたAMIからEC2インスタンスを起動する
- 25. 25 Auto Scalingの基本的な動き Auto Scaling Groupの中で最低台数（Min値）維持 CloudWatch への設定 CloudWatchのアラームをトリガーとして受ける AutoScaling AutoScaling Policyの設定 Groupの設定 Auto Scaling Policyに応じて、 対象のEC2インスタンス群に対し何台増やすか決める 指定されたAMIからEC2インスタンスを起動する Launch Configuration の設定 AutoScaling Groupの設定
- 26. 26 Auto Scaling Group • 設定項⽬目 – Auto Scaling Group名 – Launch Configuration – Maximum（インスタンス最⼤大数） – Minimum（インスタンス最⼩小数） – Desired Capacity – VPC – Availability Zones – Health Check Type – Health Check Grace Period – Load Balancer – Termination Policy – Tag Auto scaling Group Add! Desired capacity Auto Scaling 起動している インスタンスグループの設定 min max
- 27. Auto Scaling Groupの設定 EC2管理理コンソールから設定 27 Launch Configuration の指定 その後、Policyや 通知⽅方法、タグの指定 所属するVPCやSubnet、ELBを指定
- 28. 28 Launch Configuration • 設定項⽬目 – Launch Configuration名 – AMI – インスタンスタイプ – kernel id – RAMDISK ID – Block Device Mappings – Security group(s) – Keypair名 – IAM Profile – Spot Price – user-‐‑‒data – ebs-‐‑‒optimized – Detailed Monitoring Auto scaling Group Add! Auto Scaling どのAMIからどんな設定で 起動するかを決める
- 29. Launch Configurationの設定 EC2管理理コンソールから設定 29 その後、ストレージや セキュリティグループ、 公開鍵の指定 Launch Configuration名の指定や Roleの定義 AMIの指定インスタンスタイプ の選択
- 30. 30 Auto Scaling Policy • 設定項⽬目 – Auto Scaling Group名 – Policy名 – Scaling adjustment（増減させる台 数） • スケールイン時はマイナス記号をつ ける – Adjustment type • ChangeInCapacity: X台増減 • ExactCapacity: X台に指定 • PercentChangeInCapacity: 現キャ パシティに対してX%増減 – Cooldown period（Auto Scaling Policyを実⾏行行する間隔） Auto scaling Group Add! Auto Scaling インスタンス追加/削除 時の挙動の設定
- 31. Auto Scaling Policyの設定 Auto Scaling Group定義の中のScaling Policiesで設定 31
- 32. 32 CloudWatchアラーム • CloudWatchのアラーム設定で、Auto Scaling Actionを定義し、トリガーを送るAuto Scaling GroupとAuto Scaling Policyを選択 • もしくは、Auto Scaling GroupのScaling Policy設定画⾯面からトリガーとしてのアラーム を設定
- 33. 33 その他の使い⽅方 • Auto Healingとして利利⽤用 – Min N, Max Nとして設定すれ ばN台のHealthyなインスタン スをキープ • Auto Scaling Groupをま とめて監視 • スケジュールベースでイ ンスタンス増減
- 34. 34 スケジュールベースの設定イメージ • 時刻を指定してのスケジューリング $ aws autoscaling put-scheduled-update-group-action --scheduled-action-name ScaleUp --auto-scaling-group AUTO_SCALING_GROUP --start-time 2014-10-29T10:00:00Z --desired-capacity 3 • cronのように繰り返しのスケジューリング $ aws autoscaling put-scheduled-update-group-action --auto-scaling-group AUTO_SCALING_GROUP --recurrence “30 0 1 1,6,12 0” --desired-capacity 3 • 複数のスケジュールを設定可能
- 35. 35 Auto Scalingによるインスタンス増減のタイミング • Auto Scaling GroupのHealthyインスタンス数検知 – StatusがHealthyなインスタンス数がMin値以下になるとインスタンス追加起動 • CloudWatchアラームのAuto Scaling Actionトリガー – AutoScaling Policyにしたがってインスタンス数を増減 • Auto Scaling Groupのスケジュール – スケジュールにしたがってインスタンス数を増減 • ⼿手動コマンド – コマンドでMax/Min/Desired Capacity値修正しインスタンス増減 – コマンドでAuto Scaling Policy実⾏行行 – コマンドでインスタンスの追加（Attach）／削除（Detach） – コマンドでAutoScaling Groupに所属するインスタンスのStatusをUnhealthyに変更更しイ ンスタンス増減
- 36. 36 ライフサイクル・アクションフック • ライフサイクル・フック ・・・New! – EC2インスタンスが起動後Auto Scaling Groupに追加されるまで、StatusがPendingとなる – EC2インスタンスがAuto Scaling Groupから除外されTerminateされるまで、Statusが TerminatingとなりTerminate処理理が⼀一時停⽌止する – ライフサイクル・フックを設定しておくと、PendingまたはTerminatingの状態になったときに、 通知対象にメッセージを送り、標準で60分間待機に⼊入る – 待機時間は最⼤大48時間 – 通知対象としては、SNSトピックもしくはSQSキュー • ライフサイクル・アクション – ライフサイクル・フックを拾拾って各種インスタンス初期化処理理が可能 • ソフトウェアのインストールや設定、EBSボリュームの作成／初期化／アタッチ、メッセージキューイン グへの接続、等 • 最後にスナップショットの取得、ログの退避、問題判別作業、等 – 処理理が終了了したらAuto Scalingライフサイクルへ完了了を通知する – 処理理が60分以内に終わらない場合は、Heartbeatを送って時間延⻑⾧長可能
- 37. 37 インスタンス増のときの注意点 • インスタンス起動時にアプリケーションが⾃自動的に動作 するよう設計する – アプリケーションをインストール済みで⾃自動起動設定をしたAMIを作成 – アプリケーション構成スクリプト等をLaunch Configurationのuser data に記載してインスタンス起動時に⾃自動実⾏行行＆構成 – Auto Scaling Lifecycle Hookを使って外からEC2構成 起動時 すべてインストールHook:Pending ＆構成済みのAMI ⾃自動スクリプト実⾏行行 Hookを拾拾って スクリプト実⾏行行 構成ファイル 取得構成ファイル 取得
- 38. 38 インスタンス減のときの注意点 • インスタンスがTerminateされた場合を考慮した設計にする – Auto Scaling配下のインスタンスは、随時Terminateされる可能性がある – Termination Policyのカスタマイズは可能だが、障害等も鑑み、いつ落落ちてTerminateされ てもよいような設計とする • ステートレスなアーキテクチャー – スティッキーセッションは使わない、セッション情報は外側の永続的ストレージに保管 （Dynamo DBやElastiCache等） – ログは定期的にS3に送る（サーバ終了了時に残りのログをS3にバックアップ） Hook:Terminating Terminate時に残りのログ等を 外部ストレージに対⽐比させる セッション情報含めたデータは外 部DB/ストレージに保管してある ためTerminateされても問題なし Hookを拾拾って スクリプト実⾏行行
- 39. 39 EC2インスタンスのライフサイクルを理理解する • Auto ScalingはEC2インスタンスをLaunchし、Terminateする （Start/Stopではない） • 既存インスタンスのAuto Scaling GroupへのAttach、およびAuto Scaling Group内インスタンスのDetachが可能 – 利利⽤用例例） • 既存インスタンスや⼿手動で構成したインスタンスをAuto Scaling Groupに追加可能 • あらかじめ起動構成済みのインスタンスをすぐにAuto Scalingへ追加可能（Launchを待つ必 要がない） • Auto Scaling Group内インスタンスをDetachして別⽬目的で流流⽤用可能 • Auto Scaling Group内EC2インスタンスをStandbyにして⼀一時的 にGroupから外すことが可能 – 利利⽤用例例） • インスタンスの問題判別、メンテナンス • ライフサイクル・フック機能で、LaunchしてAuto Scaling Group に参加する前およびTerminate前にユーザ処理理を⼊入れることが可能
- 40. 40 Auto Scalingのライフサイクル（⾃自動） Auto Scalingを設定したときの動き DesiredCapacity数 でインスタンス起動 トリガーと Auto Scaling Policy でインスタンス増 トリガーと Auto Scaling Policy でインスタンス減 Hook:LaunchingHook:Terminating SNSSQSSNSSQS スケジュールで インスタンス起動停⽌止
- 41. 41 Auto Scalingのライフサイクル（⼿手動） Attachで 既存インスタンスを Auto Scaling Group に追加 Standbyで インスタンスを⼀一時的に Auto Scaling Group 適⽤用外に Detachで Group内インスタンスを Auto Scaling Group から外す Terminate Instanceで Auto Scaling Group 内インスタンスを Terminate Hook:Terminating Set Healthで インスタンス ステータスを ⼿手動でセット StandbyUnhealthy SNSSQS Auto Scaling Groupに対する⼿手動での操作例例
- 42. 42 Termination Policy Auto Scaling Group内インスタンスをどの順番でTerminateするかのポリシー があり、カスタマイズも可能です。 • 標準では以下の⼿手順 – （Terminationを⾏行行うAZの中で）最 も古いLaunch Configurationを使う インスタンスを選択 – 同条件のインスタンスが複数いたら 次の課⾦金金が始まるタイミングが最も 近いインスタンスを選択 – さらに同条件のインスタンスが複数 いたらランダムに選択して Terminate • カスタムポリシー – 下記のポリシーを1つまたは複数指定可 • OldestInstance / NewestInstance – インスタンスの起動時刻を参照して、最 も古い / 新しいインスタンスを優先的 にTerminate • OldestLaunchConfiguration – 最も古いLaunch Configurationを使う インスタンスを優先的にTerminate • ClosestToNextInstanceHour – 次の課⾦金金が始まる時刻が最も近いインス タンスを優先的にTerminate • Default – 標準動作 – 複数指定した場合は指定順で適⽤用 – 全ポリシーを適⽤用しても複数インスタ ンスが候補になったらランダムに選択
- 43. 43 Auto Scaling Policyの使い⽅方 • Policyのトリガーが重要 – 何をトリガーにインスタンス数を増減させるか – EC2のCPU使⽤用率率率か、ELBのLatencyやRequest数か、HTTP接続数か等 • スケールアウト時に増やすインスタンス数 – Policyは、default cooldownで指定された秒数（デフォルトでは300秒）待ってから次のPolicyが実⾏行行されるため、 インスタンス数を増やすのに時間がかかる – Policyで何インスタンスずつ増やすかの指定が重要 – ⼿手動コマンドでPolicy実⾏行行する場合は、-‐‑‒-‐‑‒no-‐‑‒honor-‐‑‒cooldownオプションでこの待ち時間を無視できる • スケールインのタイミング – スケールインでインスタンスをTerminateする際、ステートフルなアプリケーションの場合はセッションが切切れる可 能性がある – スケールインはゆっくり⾏行行うか、アクセスの少ない時間帯に⼿手動もしくはスケジュールで実⾏行行 • 予測できる負荷はスケジュールベースで対応 – バッチ処理理 – アクセス傾向から⾒見見た定時アクセス負荷増 – たとえば、保険として、予測できない負荷への対応のために負荷ベースのスケーリングをしかける • Policyの整合性を確認する – スケジュールベースと負荷ベースでインスタンス台数の整合性は取れるようにしておく（Auto Scalingはトリガーを 元に順番に実⾏行行していくだけ） – 負荷がかかってインスタンス数が増えた状態で、スケジュールベースが実⾏行行されるといったんインスタンス数が減り、 負荷に応じて再度度増やす、というような想定しないインスタンス数の増減が起こる可能性がある
- 44. 44 急激な負荷増のときへの対応 • Auto Scalingは時間がかかる – CloudWatchでアラームとなるのに数分 – EC2起動⾃自体に数分 – アプリケーションやコンテンツのデプロイに数分以上 – Cooldown時間アクションを待ちながら、指定されたインスタンス数ずつのEC2増減をイテレーション で実⾏行行していくため、⼤大量量インスタンス起動時はさらに時間がかかる • キャンペーン時など、急激な負荷増加が⾒見見込まれる場合、事前にAuto Scaling 配下のインスタンスを増やしておく – Auto Scaling API/CLI（execute-‐‑‒policy、attach-‐‑‒instances、set-‐‑‒desired-‐‑‒capacity）等であらかじめ 台数を増やしておく – ELBのPre-‐‑‒Warming（暖機運転）もあらかじめ申請しておく • AutoScalingですぐに台数を増やしたいとき – set-‐‑‒desired-‐‑‒capacityやexecute-‐‑‒policyを-‐‑‒-‐‑‒no-‐‑‒honor-‐‑‒cooldownオプションで実⾏行行 – ⼀一度度に複数台の増減をすることも可
- 45. 45 Auto Scaling運⽤用上の注意点まとめ • Auto Scalingをうまく使えば、可⽤用性があがり、コスト最適化され、運⽤用 負荷が軽減する • 対象アプリケーションをステートレスに設計する – Auto Scaling Group内のインスタンスは、つねにTerminateされうることを想定する – ステートレスにできない場合は、ライフサイクル・フック機能等をうまく使う • Auto Scalingのライフサイクルを理理解する • Auto Scaling Policyのトリガーを何にするかがポイント – アプリケーションとしてどのメトリックスを⾒見見ればスケールアウトによって解決できる負荷増なの かを理理解する – トリガーとする各メトリックス性質を理理解する • 例例：t2インスタンスはCPUがバーストするのでCPU使⽤用率率率で負荷増を捉えにくい • スケールアウト時、Pre-‐‑‒Warming（暖機運転）含めどう対応するか、何台 ずつ何秒間隔で増やすか検討する • スケールインのタイミングと実施⽅方法を検討する • 事前の負荷テストによる動作確認、⼩小規模システムからの適⽤用等、Auto Scalingの性質を理理解しながら適⽤用する • Auto Scalingをうまく使ってクラウド最適なシステムを実現
- 46. 46 参考資料料 • Amazon CloudWatch Developer Guide – http://docs.aws.amazon.com/ja_̲jp/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html • Amazon CloudWatch FAQ – https://aws.amazon.com/jp/ec2/faqs/#amazon-‐‑‒cloudwatch • Amazon CloudWatch価格 – http://aws.amazon.com/jp/cloudwatch/pricing/ • Auto Scaling⼊入⾨門ガイド – http://docs.aws.amazon.com/ja_̲jp/AutoScaling/latest/GettingStartedGuide/Welcome.html • Auto Scaling Developer Guide – http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/WhatIsAutoScaling.html • Auto Scaling FAQ – https://aws.amazon.com/jp/ec2/faqs/#auto-‐‑‒scaling • Auto Scaling価格 – http://aws.amazon.com/jp/autoscaling/pricing/
- 47. 47 QA
- 48. 48 Webinar資料料の配置場所 • AWS クラウドサービス活⽤用資料料集 – http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/