SimpleADユーザーとGoogleアカウントを同期させる

こんにちは。YCです。

前回の記事でSimpleADにユーザーを作成できました。
今回はそのユーザーをG Suiteに連携したいと思います。
連携の為、使用するツールはGoogleの出しているAD連携ツール
「Google Cloud Directory Sync (以下GCDS)」を使用します。

GCDSの仕組み

1,LDAP サーバーまたは Active Directory のリストからデータが書き出されます。ユーザーが、リストの生成方法を指定するルールを設定します。
2.GCDS は Google ドメインに接続し、ユーザーが指定した Google ユーザー、グループ、共有の連絡先のリストを生成します。
3,GCDS はこのリストを比較し、そのデータに合わせて Google ドメインを更新します。
4,同期が完了すると、ユーザーが指定したアドレスにレポートがメールで送信されます。

Google公式ドキュメントより引用

環境準備

まずはGoogleの管理コンソールにログインし、
セキュリティ → API リファレンス →API アクセスを有効にする にチェックを付けます。
スクリーンショット 2017-09-25 17.07.41
これでとりあえずAPIが通るようになりました。

 

環境構築

Google公式の出しているGCDSのダウンロード手順書を見ながら
GCDSをダウンロードします。

ダウンロードしたら、GCDSを開き以下の手順で作業を進めます。
最初に出てくるのはGoogleとの連携です。
Primary Domain NameにGoogleのドメイン名を入力し、
Authrize Nowをクリックします。
09googledomain1
(検証後にスクリーンショットを撮ったので既にAuthrizedになってますが気にしないでください。)

そうすると、このようなポップアップが出てくるので、
Sign inをクリックし、Googleドメインにサインインしてください。
出てくるものを全て承認すると、Verification Codeが発行されるので、
Step2に貼り付けてください。
10googlesignin

次のLDAP認証が鬼門です。
実際のSimpleADへLDAPで接続します。
設定はこのように致しました。
11ldap1
注意して欲しいのが赤い下線部分です。

まず、ホスト名ですが、AWSのリソースであるSimpleADは自分の指定したドメインの前に
AWSのホスト名が付くので注意しましょう。
コマンドプロンプトから nslookup コマンドで確認して入力します。
cmd

次に、ユーザー名です。
ユーザーには事前に全てのユーザー情報の読み取り権限を委任してあげる必要があります。
鬼門なのでユーザーの権限委任から手順を載せていきます。

①グループを作成
01group

②制御の委任をクリック
02inin

③委任ウィザードの開始で次へをクリック
03ininuxiza-do

④追加をクリック
04tugie

⑤先ほど作ったグループを追加
05google

⑥権限を追加
06subeteno

⑦ユーザーを作成し、
07user

⑧先ほどのグループをユーザーに割り当てる
08groupsyozoku

これでようやくLdapが通るユーザーが作成できました。
このユーザーを使用して、「ドメイン名¥ユーザー名」で設定します。

最後にベースDNがわからない場合はLdapブラウザなどで確認してください。
基本的には上記画像のように「DC=xxxxxx,DC=xx」で良いと思います。

では、次の設定に参りましょう。
次のGeneral Settingsはとりあえず下記画像だけで問題ありません。
12general

Org Unitsはチェックをつけてください。
Googleの組織を使用するというチェックです。
13org

ユーザーアカウントの設定はこれと同じように設定するだけで構いません。
14useraccounts1
15useraccounts2

User ruleは以下のように設定しました。
16userrule
ここでのOrg Unit NameはGoogle側の組織名です。
Googleで先に組織を作っておいてください。
17googletest
今回のルールはメールアドレスの最後に.tkが入っているユーザーを見つけるというルールにしています。

次にNotificationsはこのように設定しています。
18notifications
SMTPホストはGoogleから引っ張っております。
21shosaisettei

そして、ログの吐き出し先を指定し、
22log

Syncで全項目にチェックが付いていることを確認してsimulate syncをクリックします。
23simulate

無事、シミュレーションが出来ると、
Google上のユーザ、AD上の検索で出たユーザそれぞれの数が出てきます。
24simulate1

問題がなければSync & apply changesをクリックし、
Googleにユーザーが追加された事を確認してください。
25userkakunin

これにてGoogleとADの同期は完了です。
散々詰まりましたが、こちらのサイト様のおかげで
なんとか同期の確認は取れました。

次回はGoogle Password Syncでパスワードの同期を試します。
ブログに載せられる機会があれば載せます。
以上です。では。

AWS Directory ServiceのSimpleADのユーザーをWindows7のローカルPCで管理

初めまして。YCです。

AWSのDirectory ServiceであるSimpleADの管理をする為には
SimpleADのドメインに所属するActive Directoryインスタンスを作成しなくてはなりません。
それをWindows7のローカルPCでやっちゃおうという記事です。

 

SimpleADとは

Simple AD は、AWS Directory Service が提供する Microsoft Active Directory 互換のディレクトリで、Samba 4 を搭載しています。Simple AD は、ユーザーアカウント、グループメンバーシップ、Linux および Microsoft Windows を実行するドメイン結合 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Kerberos ベースのシングルサインオン (SSO)、グループポリシーなどの一般的に使用される Active Directory 機能をサポートしています。これにより、Linux および Windows を実行する Amazon EC2 インスタンスの管理と AWS クラウドでの Windows アプリケーションのデプロイがさらに容易になります。

AWS公式ドキュメントより引用

 

構成図

構成図

ざっくりと書きましたが、今回はこんな感じで構成していきます。
VPN接続が必要となるので、VPN接続やルータの設定などを行える事が前提です。
この記事ではVPN接続やルータの設定は割愛します。

 

環境構築

  • Simple AD構築

まずはAWSコンソール上でSimple ADを構築していきます。
コンソールの“セキュリティ、 アイデンティティ、 コンプライアンス”のDirectory Serviceを押し、
ディレクトリのセットアップからSimple ADを選択します。
スクリーンショット 2017-09-14 15.14.36

各項目を入力し、次へボタンを押す
スクリーンショット 2017-09-14 15.16.53

確認画面で確認し、Simple ADの作成を押す
スクリーンショット 2017-09-14 15.17.36

Simple AD作成完了です。
スクリーンショット 2017-09-14 15.18.00

ここのDNSアドレスは後で使うので覚えておいてください。スクリーンショット 2017-09-20 11.48.23

※注意点として、SimpleADを作成すると自動でセキュリティグループが作成されます。
EC2コンソールのセキュリティグループでSimpleADのディレクトリIDを検索すると、
見慣れないセキュリティグループが作成されているのがわかります。
スクリーンショット 2017-09-14 15.57.18

今回は検証のため、全部通しましたが、必要に応じたセキュリティグループの設定が必要です。

 

  • リモートサーバー管理ツール(RSAT)インストール

Windowsサーバを使用せず、ローカルPCでAWSのDirectory Serviceを管理するためには、
ローカルPCにリモートサーバー管理ツールをインストールする必要があります。

インストール方法はこちらを参考にしてください。

      正常にインストールが完了すると、管理ツールにこのような管理項目が増えているはずです。

kanritool

 

 

 

  • Windows7での設定

最後に管理に使用するWindowsPCをドメイン参加させます。
ドメイン参加のやり方はこちらのサイトを参考に致しました。
手順通りに進めていくとドメイン参加させられるはずです。

ドメイン参加後、先ほどの管理ツールの「Active Directory ドメインと信頼関係」を開き、
「操作」→「フォレストの変更」から作成したSimpleADのドメインを入力します。
domain

そうすると、作成したSimpleADと信頼関係が結ばれるはずです。
domain2

信頼関係が結ばれた後、管理ツールから「Active Directory ユーザーとコンピューター」を開きます。
Active

これで、普通のADのようにユーザー管理が出来るようになりました!
インスタンス代金が1台分浮きました。

次回はSimpleADのユーザをGoogleAppsのユーザに同期させる記事を書きたいと思います。
以上、宜しくお願いいたします。

Auto ScalingによりローンチされたEC2インスタンスに紐づくEBSに自動でタグをつけたい

batchiです。

タイトルの通りです。
Auto Scalingグループによって自動的に増えたり減ったりするEC2インスタンス。

EC2インスタンス自体のタグに関しては、
Auto Scalingグループに付与したタグと同じものを自動的に付与させる設定があります。

でもそのEC2インスタンスにアタッチされているEBSにはタグはつかない。
つけたい。
どうしたらいいですか。

AWSサポートからの回答

「同じような要望をたくさんもらってます」
「Feature Requestとして要望中です」
「実装可否や実装時期についてはお答えできません」
「現時点で実装するなら、以下のいずれかでやってください」
・起動設定にユーザーデータ仕込む
・ライフサイクルフックを使う

というわけで、ユーザーデータを仕込むパターンを選択しました。

実装

参考にしたのはクラスメソッドさんの以下の記事。

[小ネタ] EC2インスタンスのEBSルートボリュームに自動でNameタグを付与する
http://dev.classmethod.jp/cloud/add-name-tag-to-root-volume/

カスタマイズしたのは以下のあたり。
・AWS CLIのインストールもユーザーデータで実施する
・タグを複数付与する
・ブロックデバイス名を変更
・インスタンス作成時でなくAuto Scaling起動設定に仕込む
・タグの値にインスタンス名は含めないので変数instance_nameはカット

結果、こうなりました。

#!/bin/bash
#AWS CLIのインストール
curl -O https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install awscli
#各種変数の定義
instance_id=`curl -s 169.254.169.254/latest/meta-data/instance-id`
az=`curl -s 169.254.169.254/latest/meta-data/placement/availability-zone`
region=${az%[a-z]}
volume_id=`aws ec2 describe-instances --output text --region $region --instance-ids $instance_id \
--query 'Reservations[].Instances[].BlockDeviceMappings[?DeviceName==\`/dev/sda1\`].Ebs[].VolumeId'`
#タグ付与
aws ec2 create-tags --region $region --resources $volume_id --tags Key=Name,Value=<Nameタグの値> Key=System,Value=<Systemタグの値>

AWS CLIはインストールした状態でAMIを取得してから
起動設定を作成するのが自然だろうと思いますが、
なるたけAMIおよび起動設定をいじりたくなかったのと、
インストールにかかった時間を計測したら数秒程度だったので、そのままにしました。

少しだけわからなかったところ

変数volume_idを取得している箇所で、
–query以降をなんであんな書き方するの?というのがパッとは理解できず。
(Reservationsとか何のために書いてるの?)

–outputをtable形式にするとすんなり理解できました。
(jsonに親しんでいる人はjsonのほうがいいと思います。)

>aws ec2 describe-instances --output table --instance-ids <インスタンスID>

出力結果は階層構造になっていて、
お目当ての「VolumeId」に至るまでの、
上位の階層も書いてあげないとダメというわけでした。

以下、無駄に長い出力結果です。

--------------------------------------------------------------------------------
|                               DescribeInstances                              |
+------------------------------------------------------------------------------+
||                                Reservations                                ||
|+-------------------------------+--------------------------------------------+|
||  OwnerId                      |  13xxxxx31447                              ||
||  ReservationId                |  r-03a26xxxx77df49cc                       ||
|+-------------------------------+--------------------------------------------+|
|||                                 Instances                                |||
||+------------------------+-------------------------------------------------+||
|||  AmiLaunchIndex        |  0                                              |||
|||  Architecture          |  x86_64                                         |||
|||  ClientToken           |  alfAo1496209729199                             |||
|||  EbsOptimized          |  False                                          |||
|||  Hypervisor            |  xen                                            |||
|||  ImageId               |  ami-249fad43                                   |||
|||  InstanceId            |  i-0cd43xxxxx6953268                            |||
|||  InstanceType          |  t2.micro                                       |||
|||  KeyName               |  aws_shared_key_tokyo                           |||
|||  LaunchTime            |  2017-07-26T00:35:27.000Z                       |||
|||  Platform              |  windows                                        |||
|||  PrivateDnsName        |  ip-10-5-1-210.ap-northeast-1.compute.internal  |||
|||  PrivateIpAddress      |  10.5.1.210                                     |||
|||  PublicDnsName         |                                                 |||
|||  PublicIpAddress       |  54.xx.84.xxx                                   |||
|||  RootDeviceName        |  /dev/sda1                                      |||
|||  RootDeviceType        |  ebs                                            |||
|||  SourceDestCheck       |  True                                           |||
|||  StateTransitionReason |  User initiated (2017-07-26 15:00:06 GMT)       |||
|||  SubnetId              |  subnet-91axxxxx                                |||
|||  VirtualizationType    |  hvm                                            |||
|||  VpcId                 |  vpc-dxxxxxbc                                   |||
||+------------------------+-------------------------------------------------+||
||||                           BlockDeviceMappings                          ||||
|||+------------------------------------+-----------------------------------+|||
||||  DeviceName                        |  /dev/sda1                        ||||
|||+------------------------------------+-----------------------------------+|||
|||||                                  Ebs                                 |||||
||||+------------------------------+---------------------------------------+||||
|||||  AttachTime                  |  2017-05-31T05:48:51.000Z             |||||
|||||  DeleteOnTermination         |  True                                 |||||
|||||  Status                      |  attached                             |||||
|||||  VolumeId                    |  vol-00cxxxxxb03bfb5c8                |||||
||||+------------------------------+---------------------------------------+||||
||||                               Monitoring                               ||||
|||+------------------------------+-----------------------------------------+|||
||||  State                       |  disabled                               ||||
|||+------------------------------+-----------------------------------------+|||
||||                            NetworkInterfaces                           ||||
|||+------------------------------+-----------------------------------------+|||
||||  Description                 |  Primary network interface              ||||
||||  MacAddress                  |  06:cc:05:12:ba:2b                      ||||
||||  NetworkInterfaceId          |  eni-xxxxaabe                           ||||
||||  OwnerId                     |  1xxxxxxxx447                           ||||
||||  PrivateIpAddress            |  10.5.1.210                             ||||
||||  SourceDestCheck             |  True                                   ||||
||||  Status                      |  in-use                                 ||||
||||  SubnetId                    |  subnet-9xxxxxe6                        ||||
||||  VpcId                       |  vpc-xxxxxxbc                           ||||
|||+------------------------------+-----------------------------------------+|||
|||||                              Association                             |||||
||||+-----------------------------------+----------------------------------+||||
|||||  IpOwnerId                        |  133285731447                    |||||
|||||  PublicDnsName                    |                                  |||||
|||||  PublicIp                         |  54.xx.84.xxx                    |||||
||||+-----------------------------------+----------------------------------+||||
|||||                              Attachment                              |||||
||||+------------------------------+---------------------------------------+||||
|||||  AttachTime                  |  2017-05-31T05:48:50.000Z             |||||
|||||  AttachmentId                |  eni-attach-5450dbbc                  |||||
|||||  DeleteOnTermination         |  True                                 |||||
|||||  DeviceIndex                 |  0                                    |||||
|||||  Status                      |  attached                             |||||
||||+------------------------------+---------------------------------------+||||
|||||                                Groups                                |||||
||||+------------------------+---------------------------------------------+||||
|||||         GroupId        |                  GroupName                  |||||
||||+------------------------+---------------------------------------------+||||
|||||  sg-dcxxxxb8           |  testxxxxavpc-internal                      |||||
|||||  sg-e0xxxx84           |  testxxxxavpc-22_from                       |||||
||||+------------------------+---------------------------------------------+||||
|||||                          PrivateIpAddresses                          |||||
||||+----------------------------------------+-----------------------------+||||
|||||  Primary                               |  True                       |||||
|||||  PrivateIpAddress                      |  10.5.1.210                 |||||
||||+----------------------------------------+-----------------------------+||||
||||||                             Association                            ||||||
|||||+----------------------------------+---------------------------------+|||||
||||||  IpOwnerId                       |  13xxxxxxxcx7                   ||||||
||||||  PublicDnsName                   |                                 ||||||
||||||  PublicIp                        |  54.xx.84.xxx                   ||||||
|||||+----------------------------------+---------------------------------+|||||
||||                            NetworkInterfaces                           ||||
|||+------------------------------------+-----------------------------------+|||
||||  Description                       |                                   ||||
||||  MacAddress                        |  06:ec:04:91:0b:9d                ||||
||||  NetworkInterfaceId                |  eni-8bxxxxc5                     ||||
||||  OwnerId                           |  133285731447                     ||||
||||  PrivateIpAddress                  |  10.5.3.222                       ||||
||||  SourceDestCheck                   |  True                             ||||
||||  Status                            |  in-use                           ||||
||||  SubnetId                          |  subnet-7xxxxxx6                  ||||
||||  VpcId                             |  vpc-xxxxxxxc                     ||||
|||+------------------------------------+-----------------------------------+|||
|||||                              Attachment                              |||||
||||+------------------------------+---------------------------------------+||||
|||||  AttachTime                  |  2017-05-31T08:11:05.000Z             |||||
|||||  AttachmentId                |  eni-attach-83xxxxxb                  |||||
|||||  DeleteOnTermination         |  False                                |||||
|||||  DeviceIndex                 |  1                                    |||||
|||||  Status                      |  attached                             |||||
||||+------------------------------+---------------------------------------+||||
|||||                                Groups                                |||||
||||+------------------------+---------------------------------------------+||||
|||||         GroupId        |                  GroupName                  |||||
||||+------------------------+---------------------------------------------+||||
|||||  sg-dcdb40b8           |  testxxxxavpc-internal                      |||||
|||||  sg-e05ac084           |  testxxxxavpc-22_fromINF                    |||||
||||+------------------------+---------------------------------------------+||||
|||||                          PrivateIpAddresses                          |||||
||||+----------------------------------------+-----------------------------+||||
|||||  Primary                               |  True                       |||||
|||||  PrivateIpAddress                      |  10.5.3.222                 |||||
||||+----------------------------------------+-----------------------------+||||
||||                                Placement                               ||||
|||+------------------------------------+-----------------------------------+|||
||||  AvailabilityZone                  |  ap-northeast-1a                  ||||
||||  GroupName                         |                                   ||||
||||  Tenancy                           |  default                          ||||
|||+------------------------------------+-----------------------------------+|||
||||                             SecurityGroups                             ||||
|||+------------------------+-----------------------------------------------+|||
||||         GroupId        |                   GroupName                   ||||
|||+------------------------+-----------------------------------------------+|||
||||  sg-dcdb40b8           |  tesxxxxxavpc-internal                        ||||
||||  sg-e05ac084           |  testxxxxavpc-22_fromINF                      ||||
|||+------------------------+-----------------------------------------------+|||
||||                                  State                                 ||||
|||+-----------------------------+------------------------------------------+|||
||||  Code                       |  80                                      ||||
||||  Name                       |  stopped                                 ||||
|||+-----------------------------+------------------------------------------+|||
||||                               StateReason                              ||||
|||+----------+-------------------------------------------------------------+|||
||||  Code    |  Client.UserInitiatedShutdown                               ||||
||||  Message |  Client.UserInitiatedShutdown: User initiated shutdown      ||||
|||+----------+-------------------------------------------------------------+|||
||||                                  Tags                                  ||||
|||+--------------------+---------------------------------------------------+|||
||||  Key               |  Name                                             ||||
||||  Value             |  testxxxxa-member1                                ||||
|||+--------------------+---------------------------------------------------+|||

蛇足

以下、お遊びで以下のユーザーデータも試してみました。

#!/bin/bash
#AWS CLIのインストール
curl -O https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install awscli
#各種変数の定義
instance_id=`curl -s 169.254.169.254/latest/meta-data/instance-id`
az=`curl -s 169.254.169.254/latest/meta-data/placement/availability-zone`
region=${az%[a-z]}
volume_id=`aws ec2 describe-instances --output text --region $region --instance-ids $instance_id \
--query 'Reservations[].Instances[].BlockDeviceMappings[?DeviceName==\`/dev/sda1\`].Ebs[].VolumeId'`
date=`date`
#タグ付与
aws ec2 create-tags --region $region --resources $volume_id --tags Key=Name,Value=<Nameタグの値> Key=System,Value=<Systemタグの値> Key=Date,Value="$date"

ユーザーデータが実行された時刻をタグとしてつけてしまおうというものです。

Auto Scalingグループのコンソール画面では、
履歴からインスタンスのローンチが行われた時刻が確認できます。

それとこのタグを比較すると…
ローンチ開始から50秒程度後にユーザーデータが実行されているようでした。

(あくまで私が試した環境において。)

なるほど。と思いました。
以上です。

[Auto Scaling]いつのまにか増えていたターゲットトラッキングポリシーを理解する

batchiです。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①

全6回の無駄に長丁場の記事を書いている最中に、
しれっと新しい動的スケーリングのポリシーが追加されていました。

– 新機能 – EC2 Auto Scalingのターゲットトラッキングポリシー –
https://aws.amazon.com/jp/blogs/news/new-target-tracking-policies-for-ec2-auto-scaling/

ひとまず前回時点では見て見ぬふりをして書き上げたので、
見て見ぬふりをしたツケをこれから払います。


ターゲットトラッキング(追跡)ポリシーとは

簡単に言えば、以下のような挙動です。

・メトリクスを指定する(平均CPU使用率、平均ネットワークI/Oなど)
・メトリクスに対するターゲット値を指定する(60%、5,000byteなど)
・ターゲット値からぶれないようにうまいこと勝手にスケーリングしてくれる

こんな感じです。動的スケーリングの設定としてはかなり簡素化されましたね。

ドキュメントとしては以下を参照しましょう。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-target-tracking.html

補足として下記のようなトピックがあります。

・指定可能なメトリクスは以下の通り
 ・事前定義されたメトリクス
  - ターゲット別のALBリクエスト数
  - CPUの平均使用率
  - 平均ネットワーク入力(バイト)
  - 平均ネットワーク出力(バイト)
 ・カスタマイズされたメトリクス
  - (どうやって設定するんだろう??)
・オプションでスケールインを無効にすることが可能
・ウォームアップの期間を指定する必要あり
・ポリシー作成時にCloud Watchアラームが自動的に作成される
・メトリクスの値を取得する間隔は1分を推奨

[改訂版]スケーリングプランごとのクールダウン/ウォームアップ

ターゲットトラッキングポリシーでは、
クールダウンの概念ではなくウォームアップの概念が適用されます。

以前私は「ウォームアップはステップスケーリングポリシーだけ」
と謳っていたのですが、修正を余儀なくされました。

というわけで以下の表の通り。

◯…適用される
×…適用されない

スケーリングプラン デフォルトのクールダウン スケーリング固有のクールダウン ウォームアップ
インスタンス数の維持 × × ×
手動スケーリング × オーバーライド可能 ×
スケジュールに基づくスケーリング × × ×
シンプルスケーリングポリシーによる動的スケーリング オーバーライド可能 ×
ステップスケーリングポリシーによる動的スケーリング × ×
ターゲットトラッキングポリシーによる動的スケーリング × ×

ウォームアップの考え方自体は、
ステップスケーリングポリシーの時と変わりありません。
(良かった。)

ターゲットの追跡スケーリングポリシーでは、新しく起動されたインスタンスのウォームアップにかかる秒数を指定できます。その指定されたウォームアップ期間が終了するまで、インスタンスは Auto Scaling グループの集合メトリクスの対象になりません。

スケールアウト時、Auto Scaling はグループの現在の容量の一部としてウォームアップ中のインスタンスは対象にしません。これにより、必要以上の数のインスタンスが追加されることがなくなります。

スケールイン時、Auto Scaling はグループの現在の容量の一部として終了中のインスタンスを対象にします。したがって、Auto Scaling グループから必要以上の数のインスタンスが削除されることがなくなります。

スケールアウトアクティビティの進行中、スケールインアクティビティを開始することはできません。

ターゲットトラッキングポリシーの実装

さわりの部分だけ紹介します。

Auto Scalingグループのコンソール画面で「ポリシーの追加」を選択すると、
ターゲットトラッキングポリシーの作成画面が開きます。

(他のポリシーを作成したい場合は画面下部から切り替える)

ターゲット追跡ポリシー

・名前(ポリシー名)
・メトリクスタイプ
・ターゲット値
・ウォームアップの長さ
・スケールインの無効化の有無の指定

上記を指定するだけで完了です。簡単。
ポリシーを作成すると、自動的にCloudwatchアラームが作成されます。

Cloudwatchアラーム

今回の例ではターゲット値として「50」を指定しましたが、
スケールアウトを担うアラームと、スケールインを担うアラームが以下の設定で作成されました。

・1分間の平均CPU使用率が50を超える期間が3回連続で検出された場合スケールアウト
・1分間の平均CPU使用率が45を下回る期間が15回連続で検出された場合スケールイン

具体的にスケールする台数は、Cloudwatchアラームからは確認できません。
よしなにやってくれるので、気にする必要がない部分ですね。

自動的に作成されたアラームは、
ユーザー側では編集も削除もできません。

削除したいときは、ポリシー削除すれば連動して削除されます。

ちなみに、ポリシー作成時に「スケールインの無効化」を有効化していると、
スケールインを担うアラームは作成されません。


というわけでターゲットトラッキングポリシーの紹介でした。

◯◯台という部分をユーザーが握れないので、
ターゲットの値を適切に設定する必要があるポリシーですね。

実際に動かしてみて、適切なターゲットの値を算出するのが良さそうです。
こちらからは以上です。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する(終)

batchiです。

まわりくどくやってきましたがようやく終わります。
自分でもあまり見返す気がしないくらい遠回りしてきました。

でもユリウスとかいう人が言っていた気がします。

『一番の近道は遠回りだった』
『遠回りこそが俺の最短の道だった』

はい。
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
同上②
同上③
同上④
同上⑤

ウォームアップとはなんぞや、という部分を書きます。


7.ウォームアップ

参照するドキュメントは以下のあたり。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-simple-step.html#as-step-scaling-warmup

そして2017年7月現在書いてあることは以下がすべてです。

ステップスケーリングポリシーでは、新しく起動されたインスタンスのウォームアップにかかる秒数を指定できます。その指定されたウォームアップ期間が終了するまで、インスタンスは Auto Scaling グループの集合メトリクスの対象になりません。

スケールアウト時、Auto Scaling はグループの現在の容量の一部としてウォームアップ中のインスタンスは対象にしません。したがって、複数のアラーム超過によってもステップ調整値の範囲は変わらず、1 つのスケーリングアクティビティという結果になります。これにより、必要以上の数のインスタンスが追加されることがなくなります。先ほどのセクションの例で、新しいインスタンスのウォームアップの最中に、メトリクスが 60 になり、さらに 62 になったとします。現在の容量がまだ 10 であるため、Auto Scaling は 1 インスタンス(10 インスタンスの 10%)を追加する必要がありますが、グループの必要な容量はすでに 11 インスタンスなので、Auto Scaling は必要な容量をさらに増やしません。ただし、新しいインスタンスのウォームアップの最中にメトリクスが 70 になった場合、Auto Scaling は 3 インスタンス(10 インスタンスの 30%)を追加する必要がありますが、グループの必要な容量はすでに 11 なので、Auto Scaling は 2 つのインスタンスのみを追加し、新しい必要な容量は 13 インスタンスになります。

スケールイン時、Auto Scaling はグループの現在の容量の一部として終了中のインスタンスを対象にします。したがって、Auto Scaling グループから必要以上の数のインスタンスが削除されることがなくなります。

スケールアウトアクティビティの進行中、スケールインアクティビティを開始することはできません。

ちょっと飲み込むのに時間がかかりそうですね。
とはいえ、上記で少し色を薄くしている部分は例が書いてあるだけです。
それを除くと、大したことは書かれていないことがわかります。

#第④回と同じく、ここでも以下の呼称を用いることにします。
・「希望する容量」「必要な容量」…『Desired Capacity』
・「現在の容量」…『Current Capacity』

スケールアウト/スケールイン共通

・ウォームアップが完了するまでAuto Scalingグループの「Current Capacity」は変動しない

スケールアウトの場合

・ウォームアップが完了するまでスケール対象のインスタンスは集合メトリクスの対象とならない
・スケールアウトアクティビティ中にスケールインアクティビティは開始されない

7.1.ウォームアップ挙動の例

ドキュメントに従い数字を用いた例を見ていきます。
以下のスケールアウトポリシーが設定されている前提で考えます。

・Current Capacityは10(台)
・Auto Scalingグループ配下のインスタンスからメトリクス値を集約する
・集約メトリクス値が以下の値をとった場合に以下アクションを行う

 (ステップ1)60以上70未満の場合、10%分の台数を増加させる
 (ステップ2)70以上の場合、30%分の台数を増加させる

このステップではスケーリング調整タイプとして
「PercentChangeInCapacity」が指定されています。

PercentChangeInCapacityで基準となる値は、
「変更前のDesired Capacity」というか、「Current Capacity」です。

そして、一区切りのウォームアップの期間内に、下記の値を順番に取った場合を考えます。

・60(ステップ1に該当)
・62(ステップ1に該当)
・70(ステップ2に該当)

値が60の時 値が62の時 値が70の時
Current Capacity 10 10※1 10※1
Desired Capacity 11
(10台の10%増加))
11
(10台の10%増加))
13
(10台の30%増加))

※1…ウォームアップ中は増加しないため10のまま

ウォームアップという概念が存在しない場合を考えます。

値が60の時 値が62の時 値が70の時
Current Capacity 10 11 12
Desired Capacity 11
(10台の10%増加))
12
(11台の10%増加※2))
15
(12台の30%増加※2))

※2…小数点切り捨て

スケールアウトにより1台増加しても、
すぐさま負荷の分散先として機能するわけではありません。

インスタンスが立ち上がって、
OS、サービスが立ち上がって、
ELB配下に組み込まれて、
負荷の分散先として機能するまでの時間。

その時間をウォームアップとして設定しておくことによって、
過剰なインスタンスのスケールを防ぐことができます。

おわりに:結局クールダウンとウォームアップの違いって?

長々とやってきましたが、結局は以下のような違いと捉えています。
例のごとくスケールアップの場合のみを例とします。
スケールインの場合は適宜読み替えてください。

クールダウンの場合

クールダウン

・手動スケーリングもしくはシンプルスケーリングポリシーに対応
・Desired Capacityの増加にあわせて待機無しでCurrent Capacityが増加
・スケールしたインスタンスは集約メトリクスの対象となる
・クールダウン中のアラート検知をトリガーとしたスケーリングは実施しない

ウォームアップの場合

ウォームアップ

・ステップスケーリングポリシーに対応
・Desired Capacityの増加後、ウォームアップ期間分待機してからCurrent Capacityが増加
・スケールしたインスタンスはウォームアップ完了まで集約メトリクスの対象とならない
・ウォームアップ中のアラート検知は変更前のCurrent Capacityを基準に判断される


というわけでクールダウンとウォームアップの違いについてでした。
書いてる最中(2017年7月)に、
動的スケーリングのポリシーの種類が増えたときはどうしようかと思いましたが、
いったん見ないことにすると決めました。

・シンプルスケーリングポリシー
・ステップスケーリングポリシー
・ターゲットトラッキングポリシー New!

追って新しいポリシーを確認します。
ひとまず以上です。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する⑤

batchiです。
まわりくどさがかなり煮詰まってきました。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
同上②
同上③
同上④

スケーリング調整タイプの説明が終わったので、
ステップ調整値とはなんぞや、というところからです。

参照するドキュメントは以下のあたり。

http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-simple-step.html#as-scaling-steps

スケーリング調整タイプは、
シンプルスケーリングポリシーでも
ステップスケーリングポリシーでもあてはまる概念でした。

ステップ調整値はステップスケーリングポリシー独自の概念です。

6.ステップ調整値

ステップ調整値とはなんぞや。
ドキュメントによれば以下の通りです。

ステップスケーリングポリシーを作成するときは、アラーム超過のサイズに基づいてスケールできるようにする 1 つ以上のステップ調整値を追加します。各ステップ調整値には、スケーリング調整タイプに基づいて、メトリクス値の下限、メトリクス値の上限、スケールする量を指定します。

ドキュメントで文字だけを追っていると読む気が失せてくるので、
実際にポリシーの設定画面で確認します。

ステップ調整値

↑この赤枠で囲ったものがステップ調整値です。
この例ではステップを2段階で設定しています。

スケーリング調整タイプ

↑ちなみに青枠で囲っているのが前回の記事で記載した「スケーリング調整タイプ」です。
この例では「5.2.1ChangeInCapacity」を指定しています。

「5.2.2.ExactCapacity」を指定したい場合は、
「追加」としているところを「設定」に変更します。

「5.2.3.PercentChangeInCapacity」を指定したい場合は、
「インスタンス」しているところを「%(グループ中)」に変更します。

6.1.ステップ調整値のルール

ステップ調整値には以下のルールがあります。

  1. ステップ調整値の範囲に重複や間隔があってはなりません。
  2. 1 つのステップ調整値のみ、下限を null (負の無限大) にすることができます。下限が負のステップ調整値がある場合は、下限が null のステップ調整値が必要です。
  3. 1 つのステップ調整値のみ、上限を null (正の無限大) にすることができます。上限が正のステップ調整値がある場合は、上限が null のステップ調整値が必要です。
  4. 同じステップ調整値で上限と下限を null にすることはできません。
  5. メトリクス値が超過しきい値を上回っている場合、下限にその値を含み、上限には含みません。メトリクス値が超過しきい値を下回っている場合、下限にその値を含まず、上限に含みます。

やっぱり文字だけだとよくわからないので、図で見ることにします。

ステップ調整値ルール

上記の例では、以下のようなポリシーになっています。

・cloudwatchアラーム「test-alarm」の値をトリガーとしてスケーリングする
・「test-alarm」はAuto Scalingグループ配下のインスタンスのCPU使用率(%)を集約した値を検出している
・「test-alarm」は300秒ごとの平均の値を評価する
・「test-alarm」により評価された値が以下の条件にあてはまった場合、ステップに応じたアクションをとる
 ・55以上で77より小さい場合、11台追加する
 ・77以上で88より小さい場合、22台追加する
 ・88以上の場合、33台追加する

それを踏まえて各ルールを見ていきます。

ルール1

1.ステップ調整値の範囲に重複や間隔があってはなりません。

以下のような設定はできません、という意味です。

(ステップ1)55以上で77より小さい場合、11台追加する
(ステップ2)74以上で88より小さい場合、22台追加する ←ステップ1と重複している
(ステップ3)90以上の場合、33台追加する ←ステップ2と間隔がある

マネジメントコンソールで設定する場合、
上限を入力すると自動的に次のステップの下限が入力されるので、
そもそもこのルールに違反する設定のしようがありません。

ルール2,3

2.1 つのステップ調整値のみ、下限を null (負の無限大) にすることができます。下限が負のステップ調整値がある場合は、下限が null のステップ調整値が必要です。
3.1 つのステップ調整値のみ、上限を null (正の無限大) にすることができます。上限が正のステップ調整値がある場合は、上限が null のステップ調整値が必要です。

先述の例で言うと、(ステップ2)の上限として正の数字である「88」を指定した時点で、
自動的に「正の無限大」を上限とするステップが追加されます。

簡単に言えば、そういうことです。

ここでいう「正負」は基準となる値に対する相対的なものだと捉えるといいでしょう。
(上の例では「55」が基準となる値)

スケールインポリシーで、絶対値としては正の数である「33」を下限に入れた場合でも、
「負の無限大」を下限とするステップが自動的に追加されます。

ステップ調整値ルール2

ルール4

4.同じステップ調整値で上限と下限を null にすることはできません。

「同じステップ調整値」というよりは
「同じスケーリングポリシー」と捉えるのが正しいと思っています。

基準となる値に対して、相対的に「正となる値」と「負となる値」を
同じポリシーに入力することはできません。

※スケールアップの場合は下限が「基準となる値」以上、
 スケールインの場合は上限が「基準となる値」以下である必要があるため。

ルール5

メトリクス値が超過しきい値を上回っている場合、下限にその値を含み、上限には含みません。メトリクス値が超過しきい値を下回っている場合、下限にその値を含まず、上限に含みます。

スケールアウトの場合:<下限>は「~以上」で<上限>は「~より小さい」で考える
スケールインの場合:<上限>は「~以下」で<下限>は「~より大きい」で考える

というだけの話です。

先程の例で言えば、

(ステップ1)55以上で77より小さい場合、11台追加する
(ステップ2)77以上で88より小さい場合、22台追加する
(ステップ3)88以上の場合、33台追加する

評価された値が「77」であった場合、
ステップ1ではなくステップ2のアクションが取られる、ということです。


だいぶまわりくどくやってきましたが、
流石にそろそろ終わります。

次にようやく「ウォームアップってどういう挙動?」というのを書きます。
以上です。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する④

batchiです。
だいぶいい感じにまわりくどくなってきました。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する②
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する③

スケーリング調整タイプとステップ調整値とはなんぞや、
というところまできました。

参照するドキュメントは以下のあたりです。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-simple-step.html#as-scaling-adjustment

5.スケーリング調整タイプ

ドキュメントの言葉を借りると以下の通り。

ステップスケーリングまたは簡易スケーリングポリシーが実行されると、ポリシーで指定したスケーリング調整値を使用して Auto Scaling グループの現在の容量が変更されます。スケーリング調整では、グループの容量が最大グループサイズより大きい容量にも、最小グループサイズよりも小さい容量にも変更されることはありません。

微妙にわかりづらいですね。

簡単に言えばスケーリング調整タイプとは、
容量の変更の仕方を指定するものです。

「◯台増やす(減らす)」か、
「◯台にする」か、
「◯%分台数増やす(減らす)」か が選べます。

ここでいう「◯」がスケーリング調整値と呼ばれるものです。

ちなみに、AutoScalingグループでは以下の容量を指定する必要があります。
グループサイズとも呼びます。

・希望
・最小
・最大

ここで指定した「最大」を超える台数に調整されることも、
「最小」を下回る台数に調整されることもない、と書かれています。

5.1.現在の容量と希望する容量

スケーリング調整タイプによってグループの「現在の容量」を変更できることはわかりました。

では具体的に「現在の容量」をどう変更するかというと、
「希望する容量」を変更することによって実現します。

「希望する容量」とは、グループサイズにおける「希望」のことです。
ドキュメントによっては「必要な容量」と訳されていたりします。

めんどくさいので「Desired Capacity」に統一することにします。
「現在の容量」は「Current Capacity」に統一します。

Current Capacityはコンソール画面で「インスタンス」と表記されている部分です。
英語だと「Instances」ですね。

autoscaling

基本的にDesired CapacityとCurrent Capacityは同一の値を取ります。
スケーリング動作が生じた時のみ以下の流れで調整が入ります。

・スケーリング調整タイプによってDesired Capacityが変更される
・Desired CapacityとCurrent Capacityの差異を埋めるべくCurrent Capacityが変更される

そしてまたDesired CapacityとCurrent Capacityが同一の値を取ることになります。

Desired Capacityは「最大」を超えないし「最小」を下回らない、
というのを改めて覚えておきましょう。

5.2.スケーリング調整タイプ詳細

スケーリング調整タイプは3種類あります。

それぞれ台数を増加させることも減少させることもあるわけですが、
表記が冗長になるので、以下では「増加させる場合」のみを例にとって書きます。
「減少させる」に読み替え可能です。

5.2.1.ChangeInCapacity

「◯台増やす」のパターンです。
スケーリング調整値として、増やしたいインスタンスの台数を指定します。
Desired Capacityがその台数分増加します。

5.2.2.ExactCapacity

「◯台にする」のパターンです。
スケーリング調整値として、稼働させたいインスタンスの台数を指定します。
Desired Capacityがその値に変更されます。

5.2.3.PercentChangeInCapacity

「◯%分台数増やす」のパターンです。
スケーリング調整値として、増やしたいインスタンスの割合(%)を指定します。
Desired Capacityが以下のように増加します。

・変更前のDesired Capacity(整数) × スケーリング調整値(%)を計算する
 ・結果が整数の場合…その値をDesired Capacityに追加
 ・結果が0と1の間の場合…1をDesired Capacityに追加
 ・結果が1以上で小数点を持つ場合…小数点を切り捨てた値をDesired Capacityに追加

オプションとして、「最低限この台数は追加したい」という値
(MinAdjustmentMagnitude)を指定可能です。

計算結果がMinAdjustmentMagnitudeより小さかった場合、
MinAdjustmentMagnitudeによって上書きされます。

*

今回もまわりくどく記したため、
ステップ調整値について書くスペースが無くなりました。

というわけで次回に持ち越しです。
以上です。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する③

batchiです。

前回までの投稿でスケーリングプランの種類と、クールダウンの種類を抑えました。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する②

やっぱりこういうのは表で一覧化しないと捉えづらいよね、ということで、
各スケーリングプランとクールダウン/ウォームアップの対応をまとめます。

3.スケーリングプランごとのクールダウン/ウォームアップ

◯…適用される
×…適用されない

スケーリングプラン デフォルトのクールダウン スケーリング固有のクールダウン ウォームアップ
インスタンス数の維持 × × ×
手動スケーリング × オーバーライド可能 ×
スケジュールに基づくスケーリング × × ×
シンプルスケーリングポリシーによる動的スケーリング オーバーライド可能 ×
ステップスケーリングポリシーによる動的スケーリング × ×

はい、こういった形となりました。
これでもう2度と迷うことがないですね。

こうなってくると、もはや気になるのは
シンプルスケーリングポリシーとステップスケーリングポリシーの違いだけですね。

4.シンプルスケーリングポリシーとステップスケーリングポリシー

どちらも動的スケーリングで用いられるポリシーです。

簡単に言えば、
シンプルスケーリングポリシーは「一回こっきり」、
ステップスケーリングポリシーは「細かく刻める」という違いがあります。

例)
シンプル:平均CPU使用率が80%以上で2台追加
ステップ:平均CPU使用率60%以上で1台、80%以上でもう1台追加

かつてはシンプルスケーリングポリシーしか存在しておらず、
ステップスケーリングポリシーは相対的に新しい概念となります。

「<メトリクス>が◯◯以上で△台追加(削除)」というくくりをステップと表現しますが、
ステップが1つの場合であってもステップスケーリングポリシーを用いることが推奨されています。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-scaling-simple-step.html

ステップ調整値が 1 つであっても、ステップスケーリングポリシーを使用することをお勧めします。このポリシーは、スケーリングアクティビティまたはヘルスチェック交換の最中でも、アラームを継続的に評価し、グループをロックしないためです。

冷やすよりは温める時代になってきたということですね。

4.1.スケーリング調整タイプとステップ調整値

シンプルスケーリングポリシーとステップスケーリングポリシーの違いは、
「一回こっきり」か「細かく刻める」かと書きました。

これをもう少し掘っていくと、
「ステップスケーリングポリシーのみステップ調整値という概念がある」
というところに行き着きます。

このステップ調整値という概念を理解するためには、
先にスケーリング調整タイプという概念の理解が必要です。

スケーリング調整タイプは、
シンプルスケーリングポリシーでも
ステップスケーリングポリシーでもあてはまる概念です。

さっそくスケーリング調整タイプについて学んでいこう、
というところで次回に持ち越しです。

やり方がまわりくどいですね。
こちらからは以上です。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する②

batchiです。

前回はスケーリングプランの種類についておさえました。
[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①

それぞれのスケーリングポリシーに関わるクールダウン/ウォームアップを整理する前に、
クールダウンの中にも種類があるよ、というところから始まります。

2.クールダウンの種類

参照するのはこのあたりです。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/Cooldown.html

クールダウンとは、簡単に言えば、
過剰にスケールさせないために設ける待機時間です。

例えば、「負荷が高まってきたので1台追加した」となっても、
その1台がすぐに負荷の分散先として機能してくれるわけではありません。

インスタンスが作成されて、そのOS上でサービスが起動して…
となるまでは、負荷は高いままとなります。

そこの時間を踏まえないと、1台追加して「まだ負荷高い!もう1台追加しなくては!」となり、
さらなる1台もすぐには準備が整わないので「さらにもう1台!」となり、
すべての追加分のインスタンスが準備万端となったころには
過剰な台数が稼働している…となりかねません。

それを避けるためにクールダウンがあります。

クールダウンには、以下の2種類があります。

・デフォルトのクールダウン
・スケーリング固有のクールダウン

2.1.デフォルトのクールダウン

AutoScalingグループ作成時に設定する項目です。
ここをブランクにすることはできません。

よって、すべてのAutoScalingグループは、
1つの「デフォルトのクールダウン」の値を持ちます。

「デフォルトのクールダウン」のデフォルト値は300秒です。ややこしいですね。

「デフォルトの」っていうことはデフォルトでないクールダウンもあるわけでして、
それが次に説明する「スケーリング固有のクールダウン」です。

2.2.スケーリング固有のクールダウン

特定のスケーリングプランを取る時に、
デフォルトのクールダウンの値を上書き(オーバーライド)することができます。

デフォルトのクールダウンはAutoScalingグループに対して設定していましたが、
スケーリング固有のクールダウンはスケーリングプランごとに設定します。
(具体的には、シンプルスケーリングポリシーか、手動スケーリングアクション)

スケーリング固有のクールダウンは、
オプション的な位置づけで、指定は必須ではありません。

指定しなかった場合はデフォルトのクールダウンの値が採用されることになるんですね、
と理解したくなりますが、少しだけ違います。
スケーリングプランによります。

はじめに「特定のスケーリングプラン」と書きましたが、
スケーリング固有のクールダウンが関わるのは、
「手動スケーリング」か「シンプルスケーリングポリシーによる動的スケーリング」のどちらかです。

2.2.1.手動スケーリングの場合

ここでスケーリング固有のクールダウンを指定しないと、
クールダウンそのものが無視されます。

デフォルトのクールダウンは手動スケーリングにサポートされていないためです。

スケーリング固有のクールダウンを指定した時のみ、
クールダウン期間分の待機が実施されます。

#この場合も「オーバーライド」というのが正しいのか不明です。
#CLIによる手動スケーリングの時だけしかスケーリング固有のクールダウンを指定出来ない気がします。

2.2.2.シンプルスケーリングポリシーによる動的スケーリング

ここでは、スケーリング固有のクールダウンを指定しない場合、
デフォルトのクールダウンの値が採用されます。
これは分かりやすいですね。

スケーリング固有のクールダウンを指定すればそちらが採用される、
すなわちオーバーライド、というのも分かりやすいです。

* * * *

クールダウンの種類が判明しましたので、
次回はそれを踏まえてスケーリングプランごとの
「デフォルトのクールダウン/スケーリング固有のクールダウン/ウォームアップ」の関連を整理したいと思います。

進み方がまわりくどいですね。
こちらからは以上です。

[Auto Scaling]まわりくどくクールダウンとウォームアップの違いを理解する①

2017年7月に新たなポリシーが追加されたので、若干事情が変わりました。
[Auto Scaling]いつのまにか増えていたターゲットトラッキングポリシーを理解する


batchiです。

Auto Scalingをいじっていると、クールダウンという言葉をよく目にします。
それとは別に、ウォームアップという言葉もあります。

え?何が違うの?
冷やしたらいいのか温めたらいいのかどちらですか?

…と、なった時に一度調べたのですが、
久しぶりに思い出そうとしたらまったく思い出せなかったので、
改めて調べて記します。

結論のようなもの

・冷やすのと温めるのは同時にはできません
・冷やすか温めるかはスケーリングプランないしポリシーによって決定されます
・温める機会があるのはステップスケーリングポリシーを選択したときだけです
・デフォルトのクールダウンって何、と思ったらメインルートテーブルを思い出そう
・温める動作の意味が分からなかったらdesired capacityとcurrent capacityを意識しよう

この結論に至るまで、まわりくどく寄り道をして記していきます。

1.スケーリングプラン

「Auto Scalingによってインスタンスが増えます減ります」という動作を、
どのように実現しましょうか、という方法(プラン)は、いくつか種類があります。

参考にするドキュメントは以下のあたりです。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/scaling_plan.html#scaling_typesof

1.1.インスタンス数の維持

指定したインスタンス数を維持しようとするスケーリング動作です。
この「インスタンス数」にカウントされるのは、正常なインスタンスだけです。

なので、インスタンスに異常が検知された場合には、
そのインスタンスを削除し、
新たな正常なインスタンスを起動することでインスタンス数を維持します。

何をもって異常とするかは、ヘルスチェックの設定によります。
デフォルトでは、EC2インスタンスのステータスのみを評価します。
 
******長い脱線開始*****

EC2インスタンスのステータスってどこのこと指してます?
ドキュメントを見ましょう。

インスタンスステータスが running 以外の状態の場合、またはシステムステータスが impaired である場合は、Auto Scaling はインスタンスを異常ありと見なし、代わりのインスタンスを起動します。
http://docs.aws.amazon.com/ja_jp/autoscaling/latest/userguide/as-maintain-instance-levels.html#determine-instance-health

こういったドキュメントとかコンソール画面の日本語は、
ひっかかりやすいのでうっかりすると間違いそうですね。

まず「インスタンスステータス」とは、
マネジメントコンソールで「インスタンスの状態」と表示されている部分のことです。

‘running’と記載があるのでイメージはしやすいですね。

running以外は異常ありとみなすので、
うっかり「停止」を押して「stopping」状態になると、瞬く間に削除されます。

次に「システムステータス」とは何を表しているか。

「2/2のチェックに合格しました」でおなじみのステータスチェック。
内訳を見ると以下の2つがある。

①システムステータスのチェック
②インスタンスステータスのチェック

※②で「インスタンスステータス」という言葉が出てくるのが紛らわしいですが、
‘running’とか表示される「インスタンスの状態」とは別物です。

「システムステータス」って要は①のことでしょ、と思っていたら、違いました。
①②の結果によって「システムステータス」が決定される、でした。

ステータスチェックは 1 分ごとに実行され、それぞれ成功または失敗のステータスを返します。すべてのチェックが成功すると、インスタンス全体のステータスが OK になります。1つ以上のチェックが失敗すると、全体のステータスが impaired になります。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html?icmpid=docs_ec2_console

①②両方とも成功するとシステムステータスは「OK」になる。
①②いずれかが失敗するとシステムステータスは「impaired」になる。

そういうことでした。

同じことを言っててもドキュメントやコンソール画面で言い回しが違ったりするので、
惑わされず「ここでいうこれは何を指してるんだろう」というのを正確に読み取るのは大事ですね。

******長い脱線終了*****
 
ここまで述べたEC2のステータスに加えて、
ELBによるヘルスチェックの結果もAuto Scalingグループによる評価対象に加えることができます。
(Inservice/OutOfserviceと表示されるアレです)

このスケーリングプランを利用して、
障害が発生しても自動回復させよう、という試みを俗にAuto healingと言いますね。

1.2.手動スケーリング

手動で稼働させる台数を指定し、スケールアウトないしスケールインを実施します。
Auto Scalingなのに手動で操作するんですか?という質問はやめましょう。
自動車の自動運転だってまだ実現してないじゃないですか。

1.3.スケジュールに基づくスケーリング

スケジュールとインスタンス数を設定しておけば、
自分の代わりに小人が手動スケーリングを行ってくれるイメージです。

スケジュール指定で自動でやるか人力でやるかの違いだけです。
一度きりでも繰り返しでも設定もできます。

1.4.動的なスケーリング

どの「きっかけ」に基いて、
「どのような内容で」スケーリングを実施するかを予め設定しておくことで、
負荷状況に合わせたスケーリングが実現できます。

「きっかけ」になりうるのは以下の2つ。
・メトリクス(Cloudwatchアラームによる監視)
・Amazon SQS

「どのような内容で」というのは「スケーリングポリシー」によって定義します。
スケーリングポリシーは以下の2種類があります。

・シンプルスケーリングポリシー
・ステップスケーリングポリシー

冒頭で述べましたが、ウォームアップが関わってくるのは、
後者のステップスケーリングポリシーだけです。

1.スケーリングプランで様々なスケーリング方法が出てきましたが、
一番最後の「動的なスケーリングでステップスケーリングポリシーを使う」場合のみ、
ウォームアップが関わってきます。

じゃあそれ以外はクールダウンが関わってくるんですね、
というとそういうわけではなく、
クールダウンすら関わってこない場合と、
クールダウンの中でも種類があってこのクールダウンだけ…というのもあるので、
それは次回まわりくどく説明します。

以上です。