« AWS Black Belt Online Seminar「Amazon Chime」の資料およびQA公開 | メイン | AWS Black Belt Online Seminar「AWS Code Services (CodeCommit, CodeBuild)」の資料およびQA公開 »

AWS Black Belt Online Seminar「AWS Auto Scaling」の資料およびQA公開

こんにちは、ソリューションアーキテクト 焼尾です。

2017/3/15 に開催いたしました AWS Black Belt Online Seminar「AWS Auto Scaling」の資料を公開しました。当日ご参加いただいた皆さまからのご質問の回答とあわせて紹介させて頂きます。

 

 

【Q&A】

Q1. スケーリングポリシーでリクエスト数を使用する場合、スケーリングポリシーを複数(リクエスト数の段階)に応じて設定しないといけないと思いますが、こちらベストプラクティスはありますでしょうか?

A1. サービスとアプリケーションの傾向によって適切なしきい値は異なるため、お客様のサーバ1台あたりで捌けるリクエスト数を見極めていただき、適切なリクエスト数とサーバ数をマッピングして頂く必要があります。リクエスト数以外のメトリクス(CPU使用率など)で設定するのも一般的な方法です。

Q2. インターネット経由でのアクセスを禁止し、VPN経由でのアクセスのみを認めるようなセキュリティ設定の場合でもAutoScaleとELBの設定は可能でしょうか?可能な場合、注意点などあれば教えてください。

A2. Internal ELBを利用することでVPNまたはDirectConnect経由でELBにアクセスすることが可能です。ELB配下のAutoScalingGroupについては特にアクセス元環境を意識する必要はございません。

Q3. AutoScaling配下のサーバーを手動で再起動した場合は、Terminated状態に遷移するのでしょうか?

A3. ヘルスチェックの設定に依存します。例えばELBのヘルスチェックを利用し、タイムアウト、ヘルスチェック間隔、非正常の閾値を長く取っていた場合、インスタンスが再起動されてもヘルスチェックには失敗しない場合があります。この場合、AutoScalingはアクションを実行しません。Terminatedになるのはあくまでヘルスチェックに失敗したインスタンスのみになります。

Q4. Slide27-33の例で、M台の時にCPU使用率が80%を超えた場合、全体台数の10%分増加するトリガー(計算では0.台の追加、この場合は1台とみなす?)になりますがその場合、MAX台数が優先されサーバは追されないという認識であってますでしょうか?

A4. まず、PercentChangeInCapacityで動的スケーリングする場合、小数点が出た場合以下のように動作します。
o    1 より大きい値は小数点以下が切り捨てられます。たとえば、12.7 は 12 に丸められます。
o    0 と 1 の間の値は 1 に丸められます。たとえば、.67 は 1 に丸められます。
o    0 と -1 の間の値は -1 に丸められます。たとえば、-.58 は -1 に丸められます。
o    -1 未満の値は小数点以下が切り捨てられます。たとえば、-6.67 は -6 に丸められます。
 スケーリングポリシーにより追加される台数がMAX台数を超えてしまっている場合、AutoScalingはMAX台数までのみを立ち上げます。ご認識の通りASGのMAX台数を超えることはありません。

Q5. 猶予時間が短い場合、どのような問題が生じるのでしょうか.

A5. ヘルスチェックの猶予期間はインスタンスの起動~アプリケーションデプロイ~サービス組み込み、までに要する時間よりも長くとっておく必要があります。猶予期間が短い場合、インスタンスの構成が終わっていない状態でヘルスチェックが開始してしまい、結果ヘルスチェックに失敗→Terminateという動きになってしまいます。場合によってはインスタンスが追加されないことで再度アラームが起き続け、インスタンス起動~削除の無限ループに陥ってしまう可能性もあるので注意してください。

Q6. ASGインスタンス起動時にアプリのデプロイを自動的に行いたいがどのような方法がありますか?

A6. ASGインスタンスに対するデプロイ自働化方法については大きく分けて2つのパターンがあります。1つ目はアプリケーションまですべて含めたAMIを作成してしまう方法です。このやり方ではインスタンス起動後アプリデプロイにかかる時間が短くなるというメリットがあります。一方で、アプリ更新のたびにAMIを作ることになりますので、その点まで考慮したCICDパイプラインを作っておく必要があります。
2つ目の方法は起動してきたインスタンスが自分でアプリを取得しインストールする方法です。LaunchConfigurationのuserdataで、起動時に実行されるスクリプトを指定することができます。
また、CodeDeployというサービスと連携してデプロイをおこなうことも可能です。この方法についての詳しい情報は下記のドキュメントをご覧ください。
http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/auto-scaling-integ.html

Q7. Desired Capacityを変更しても最小台数にスケールインしてしまうと思うのですが、Desired Capacityを使うユースケースはどのようなものになるでしょうか?

A7. 一時的に指定台数にしたい時、例えば今すぐに、アラームに依存せずに台数を増やしたい/減らしたいといった場合に利用します。

Q8. いつもお世話になっております、途中離席してしまい聞き逃したかもしれませんが、Load Balancersが設定できると思いますけど、EC2がELBにアタッチされるタイミングを教えてください。また、Health Check TypeにEC2を設定していた場合と、ELBを設定した場合で、アタッチされるタイミングがかわりますか?よろしくお願いいたいします.

A8.ヘルスチェック方法に関わらずEC2が起動完了した後アタッチされます。インスタンス内でアプリケーションの構成が終わっているかどうかは考慮されません。そのためヘルスチェックの猶予期間を十分にとっておくようにしてください。

Q9. インスタンスの保護を有効にすると、絶対にターミネートされることはない?

A9. あくまでスケールインイベントでのターミネートのみ回避されます。インスタンスのヘルスチェックに失敗した場合や、terminate-instances コマンドなどで明示的にインスタンスを終了した場合、インスタンス保護を有効化しているインスタンスもターミネートされます。

Q10. AZでの制限のため、目的のインスタンスタイプで起動ができなかった場合はどのような稼働になりますか?(例:t2シリーズでのリソース不足)AWS側のリソース不足の場合です)

A10. 下記のエラーメッセージとともにインスタンス起動が失敗します。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/ts-as-capacity.html
 
Q11. ログをS3などへ退避する必要があるとありましたが、アップロード処理の推奨はありますでしょうか。

A11. S3 CLI/SDKを定期的に実行して転送することもできますし、fluentdやlogstashなどで転送する方法も一般的です。また、S3ではなくCloudWatch Logsに転送するのもひとつの方法です。
http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html
 
Q12. カスタムメトリクスでスケールすることはできますか?

A12. 可能です。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/policy_creating.html

Q13. 1台をメイン機として、2台目以降をオートスケールしたいという構成はどのように構成したらよいでしょうか。

A13. 例えばASGにアタッチされたELB配下にASG外のEC2インスタンスを1台アタッチしておくことでASGとは独立したインスタンスをサービスに組み込みことが可能です。
 
Q14. Blue/Green デプロイに、ASGの再作成というお話がありました。私達は、既存のASG 2つに対して 1. 非アクティブなASGのLaunchConfigの再設定を行う2. ELBにつながるアクティブなASGを切り替えるという方法を取っています。ASGごと作り変える場合とくらべてメリット・デメリットありますか。ASGの台数設定を保てるのでこちらを選択しています。

A14. 実施いただいている方法でも問題無いかと思います。重要なのはその処理を出来る限り自働化しておくことで、そのためにセッションの中ではCloudFormationを利用したリソース再作成の方法についてご紹介しました。
 
Q15. ASGにインスタンスタイプが異なる複数のインスタンスを登録しておくことは可能ですか?

A15. ASGに登録できるLaunchConfigurationは1種類のみのため、1つのASGに複数のインスタンスタイプを登録することはできませんが、1つのサービスの中に複数のインスタンスタイプを組み込みたいということであれば、1つのELB配下に複数のASGをアタッチすることで実現可能です。

Q16. スケールアウトしたEC2も同様に監視対象に組み込むケースが多いでしょうか。

A16. ケースバイケースですが、AutoScalingに対応した監視の仕組みを導入することは一般的です。例えば下記のAWS Partnerブログでは、ZabbixのAutoScaling連携の方法が紹介されていますので参考にしてください。
http://aws.typepad.com/aws_partner_sa/2016/09/opsjaws-try-ops-with-zabbix-4.html

 

今後のAWS Black Belt Online Seminarのスケジュールは こちら です。多くの方のご参加をお待ちしております。

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2017年12 月

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31