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

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

以上です。

ALBでパスベースのルーティングができると何が嬉しいのか~後追い編~

batchiです。
過去2回ほどこのテーマで書いていました。

前置き編
中継ぎ編

気づいたらパスベースだけでなくホストベースでもルーティングできるようになっていた。

びっくりですね。早いですね。AWSのアップデートがね。
こちとらパスベース前提の記事も書き終わっていないというのにね。

でも、この新機能を記事に盛り込める、とプラスに考えます。
新機能についての詳細は2017/4/5発表の以下記事をどうぞ。

(新規 – AWS Application Load Balancer に対するホストベースのルーティングのサポート)
https://aws.amazon.com/jp/blogs/news/new-host-based-routing-support-for-aws-application-load-balancers/

CLBとALBのコンポーネントの違い

なぜALBではパスベース(そしてホストベース!)でのルーティングが可能で、
CLBではできないのか、その答えはコンポーネントの違いだと私は捉えています。

簡単に言えば、「ターゲットグループ」というコンポーネントの有無に尽きるかと思います。

CLBのコンポーネント

ALBとの対比にちょうどいいコンポーネント図が無かったので、
勝手に作りました。正確性は保障しておりません。

CLBコンポーネント図

簡単に言えば、ロードバランサーがあって、リスナーがあって、配下にインスタンスがあります。
ロードバランサーが配下のインスタンスに対してヘルスチェックを実施します。
どのような内容でヘルスチェックを行うかは配下のインスタンスすべてに対して共通です。

ロードバランサーには1つ以上のリスナーが必要です。
1つのリスナーにつき以下2つを定義します。

  • クライアントとロードバランサー間の接続プロトコル・ポート…①
  • ロードバランサーとバックエンドインスタンス間の接続プロトコル・ポート…②

CLBのリスナーでサポートされているプロトコルは以下の通りです。

  • HTTP(レイヤ7)
  • HTTPS(レイヤ7)
  • TCP(レイヤ4)
  • SSL(レイヤ4)

1つのリスナーにおいて、①と②で異なるレイヤのプロトコルを設定することはできません。
また、①に設定するポート番号は複数のリスナーで重複することはできません。

どのようなリスナーを経由しても、ルーティング先の候補は配下のインスタンス全台になります。
条件を指定してルーティング先を限定する、ということはできません。

ALBのコンポーネント

こちらは以下ドキュメントから拝借してきました。
(http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/introduction.html#application-load-balancer-components)

component_architecture

CLBと比べてコンポーネントが増えています。
リスナーの中にルールというコンポーネントがあったり、
インスタンスがターゲットというコンポーネントになっていたり、
(つまりEC2インスタンス以外のリソースを宛先にできる。らしい)
ターゲットの集まりであるターゲットグループというコンポーネントがあったりします。

どのような内容でヘルスチェックを行うかはターゲットグループ単位で設定できるようになっています。

少し注釈をつけます。

ALBコンポーネント図

CLBにおいては「①で受け取ったら問答無用で②にルーティングする」、というイメージですが、
ALBにおいては、「リスナーで受けとったらルールに応じてターゲットグループにルーティングする」というイメージです。

ターゲットグループごとにプロトコルとポート番号の組み合わせを定義します。
ターゲットグループに対してターゲット(主にインスタンス)を関連付けていきます。
(CLBではロードバランサーにインスタンスを関連付ける)

リスナーとターゲットグループで使用できるプロトコルは以下の通りです。

  • HTTP(レイヤ7)
  • HTTPS(レイヤ7)

CLBと違いレイヤ4のプロトコルは指定できません。

ちなみに、CLBの①と同様、複数のリスナーで同一のポート番号を指定することはできません。

複数のターゲットグループにインスタンスを関連付けることで、
同一インスタンスの異なるポートにルーティングを行う、ということも可能になります。

ヘルスチェックは実行対象の単位が変わっただけでなく、
どのようなHTTPステータスコードが返ってくれば正常とみなすかを設定可能です。
(CLBでは200固定)

おわりに

ALBは、ターゲットグループ(と、ルール)というコンポーネントが追加されたことで、
CLBに比べ柔軟なルーティングが可能になっていることがわかります。

ホストベースとかパスベースをひっくるめて
コンテントベースのルーティングと言うらしいです。

CLBとALBそれぞれできることが違いますので、用途によって使い分けましょう。

以上です。

Multi-AZ配置とSingle-AZ配置とは?

こんにちは。SKMです。

今回はAWSをやっていてよく耳にするけど詳しく分からなかった、

Multi-AZ配置とSingle-AZ配置について説明してみます。

そもそもどのタイミングで活用されるのか?

RDS(Relational Database Service)で、DBインスタンスの高可用性とフェイルオーバーを実現するために使われます。

マスター(M)が存在するアベイラビリティゾーンとは異なるアベイラビリティゾーンに同期スタンバイのスレーブ(S)を配置します。 →高可用性

異常や障害が発生したとき、冗長な待機系コンピュータサーバ/システム/ネットワークに切り替える機能。 →フェイルオーバー

どのタイミングでフェイルオーバーするのか?

下記の状態が発生した場合、プライマリBDインスタンスがスタンバイレプリカに自動的に切り替えられる。(フェイルオーバーする)

・アベイラビリティゾーンの機能停止

・プライマリDBインスタンスのエラー

・DBインスタンスのサーバータイプ変更

・DBインスタンスのオペレーティングシステムでソフトウェアのパッチ適用中

・DBインスタンスの手動フェイルオーバーが [Reboot with failover] を使用して開始された

 

 

Multi-AZとSingle-AZの違い

Multi-AZ配置

複数のアベイラビリティゾーンに配置される、自動でフェイルオーバーが行われる。AZ

 

Single-AZ配置

1つのアベイラビリティゾーンに配置される、手動で復元する必要がある。

singleAZ

 

1つのリージョンに複数のAZがあり、その中にマスターやスレーブがある。

マスターは管理・制御する元のデータであり、

それに対してスレーブがマスターを複製したものになる。

スレーブはマスターに問題が生じたときに、常に最新の状態に更新されているため、マスターに昇格する。しかし、マスターが動いている間は読み書きしないため、マスターの負荷を減らすことはない。

それと合わせて、Multi-AZ配置する際に覚えておきたいのが、リードレプリカです。

データの読み書きはマスターのみ可能で、スレーブは読み取りも出来ない完全なスタンバイになるので、データベースの読み取り性能を上げたい場合はリードレプリカを作成するかElastiCacheを配置します。リードレプリカは読み込みが可能なため、マスターの読み取り負荷を軽減させることが出来ます。

先程スレーブは自動的に同期されると記載しましたが、リードレプリカは非同期です。

 

Multi-AZとSingle-AZに関する説明は以上になります。

今までマスターとスレーブの存在をそもそも知らなかったため、なぜデータベースで可用性を高めるのがMulti-AZ配置なのか分かりませんでした。

マスターとスレーブの役割を知ったのでMulti-AZ配置について理解出来ました。

以上になります。