AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

ホーム - エンジニアブログ - すべて

1 / 2212345...1020...最後 »

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

2017.09.15

こんにちは。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で管理

2017.09.01

初めまして。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に自動でタグをつけたい

2017.08.18

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]いつのまにか増えていたターゲットトラッキングポリシーを理解する

2017.08.04

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]まわりくどくクールダウンとウォームアップの違いを理解する(終)

2017.07.21

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!

追って新しいポリシーを確認します。
ひとまず以上です。
1 / 2212345...1020...最後 »