プログラマでありたい

おっさんになっても、プログラマでありつづけたい

リザーブドインスタンスに変わる割引プランである「Savings Plans」を簡単に説明する

 こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木(@dkfj)です。
 AWSはお手軽便利で、個々のサービスの利用料はリーズナブルです。一方で、いろいろなシステムを作っていくと、気がつけば月々のコストがそれなりの金額になっている場合もあります。そういった際に検討するのが、コスト削減の施策です。一般的な利用方法だと、一番コストが高くなるのがEC2インスタンスです。EC2の利用料削減の方法として、真っ先に思い浮かぶのがリザーブドインスタンスだと思います。しかし、今ではリザーブドインスタンスをより発展させて柔軟な形で利用できるSavings Plansというものがあります。今回は、これを紹介しようと思います。

2つのタイプのSavings Plans

 Savings Plansには、2つのタイプがあります。Compute Savings PlansとEC2 Instance Savings Plansです。

f:id:dkfj:20200830024610p:plain

 EC2 Instance Savings Plansは、従来のリザーブドインスタンスと非常に近い割引プランです。リージョンやインスタンスファミリーを指定する必用がある代わりに、後述のCompute Savings Plansより高い割引率を享受できます。この割引率はリザーブドインスタンスのスタンダードRIと同等です。リザーブドインスタンスより柔軟な点としては、購入後のOS変更やテナンシーなどを変更可能です。また、インスタンス自体の価格が変動した場合、それに追随します。EC2インスタンスが値引きされたら、その値引きされた金額を基準に計算されるということです。一方で、リザーブドインスタンスとの違いとしては、キャパシティ予約などはできません。
 Compute Savings Plansは、今後のコスト削減方法の本流となるべきサービスです。基本的な考え方は、EC2 Instance Savings Plansと同じですが、全リージョンが対象となります。そして、EC2のみならずFargateやLambdaも対象となります。これは、嬉しいですね。ということで、Savings Plansがどこの部分が割引の対象で、どのように購入するのかを見てみましょう。

Savings Plansの仕組み

 リザーブドインスタンスは割引させたいインスタンスタイプを指定していましたが、Savings Plansは金額を指定します。単位時間あたりの対象サービス(EC2, Fargate, Lambda)の利用料を合計し、最低限どれくらいを使うかをコミットします。下の図でいうところの、変動の下限の部分です。その金額が単位時間あたり$10としたら、コミットメントとして割引後の金額を指定します。
※EC2 Instance Savings Plansだと、リージョンやインスタンスファミリーの指定も必用です。

f:id:dkfj:20200830024624p:plain

 文章で説明すると少し難しく感じるかもしれませんが、実際は金額を指定するだけなので簡単です。コンソールに推奨事項というのがあって、現状の利用料を元に推奨の購入額も教えてくれます。

f:id:dkfj:20200830031229p:plain

 コンソールで数字を入れてみると解るのですが、1時間あたり$1でも1ヶ月で$720、1年だと$8,760と大きな数字になってビックリするかもしれません。指定している金額と実際に払う金額の乖離が、直感とずれていることが解りにくさなのかもしれませんね。

どう使うのか

 柔軟性が高くリザーブドインスタンスより有利な条件にも関わらず、まだまだ認知度が低いように思えます。その理由の一つがインスタンスに対してではなく、利用料をコミットメントするという事にあるのかと思います。設計・構築段階では、どのインスタンスファミリーをどれくらい使うというのは、はっきりさせていると思います。一方で、それがどれくらいの料金なのかは、実際に構築している人は気にしていない事が多いのではないでしょうか?
 リザーブドインスタンスと同じなのかもしれないですが、そのAWSアカウントを管理する立場の人が定期的に利用状況をチェックし、定量的に利用している部分についてはSavings Plansを適用していくという運用が必用です。また買い方は時間あたりのコミットメントを指定するだけですが、割引率はリージョン・プラットフォーム・OSごとに異なってきます。これを厳密に計算しようとすると大変なので、EC2インスタンスなら20%引きとかざっくりと計算した方が良いです。少しづつ適用し、実際の利用額を見ながら対象を増やすといったような感じですね。

まとめ

 リザーブドインスタンスに代わる割引プランとして、Savings Plansの紹介でした。インスタンスファミリーに関わらず利用できるというのは、かなり使いやすいです。リザーブドインスタンスの課題を克服してのサービスなので、今後も拡充が期待できると思います。またリザーブドインスタンスとの併用もできるので、キャパシティ予約が必用なものはリザーブドインスタンスを利用してというような使い方もできます。これを機に、AWSの利用料を一度見直してみてはいかがでしょうか?
 なお現状はRDSは対象ではないですが、そのうち対応してくれないかと切に願っています。

AWSのインスタンスの種別を改めて整理する

インスタンスタイプの読み方

 インスタンスの種別を説明する前に、まずインスタンスタイプの表記の命名規則の説明をします。AWSを使っていると、M5.LargeとかC5.Smallとか見かけると思いますが、何となく解るようで解らないという人もいるのではないでしょうか?命名規則は、次のようにインスタンスファミリー・世代・インスタンスサイズで構成されています。

f:id:dkfj:20200829204105p:plain

 インスタンスファミリーは、後ほど詳しく説明しますが、汎用タイプ・コンピューティング最適化タイプなど幾つかのカテゴリがあり、そのカテゴリー内でも更に細分化されています。世代は、そのインスタンスファミリーの何世代目なのかです。例にあるM5だと、汎用化タイプであるMの5世代目です。A1とかだとArmベースの1世代目ということですね。基本的には、いちばん新しいのをつかっておきましょう。最後のインスタンスサイズが、性能を示します。インスタンスファミリーごとにベースとなる性能は違いますが、そのベースの性能内でsmall, medium, large, xlarge, 2xlargeとサイズが大きくなるごとにCPU・メモリーのサイズが原則的に2倍になっていきます。一部のインスタンスは等比例になっていない場合もあり、また、インスタンスファミリーによってはサイズの選択肢が少ないものもあります。

 原則としては、上記の命名規則となりますが、最近は世代のあとに小文字のアルファベットがついているケースがあります。

f:id:dkfj:20200829204121p:plain

 これは追加機能を表します。例えば、M5aだと汎用タイプの第5世代目という点は同じですが、CPUがIntelベースではなくAMDベースとなります。同様に、AWSが設計したAWS ArmベースのGraviton2プロセッサを使用するM6gなどもあります。追加機能はCPUの種類が違うだけでなく、ネットワークが強化されたM5nのようなタイプがあります。小文字を見ただけでは判断つかないケースも多いので、それぞれの説明を見てみるとよいでしょう。

aws.amazon.com

インスタンスの分類

 前説が長くなりましたが、ここからが本題です。最近のAWSの試験だと、どのインスタンスファミリーを使うのかが適切かと問われるケースがあります。画像処理をするので、高速コンピューティングであるP3インスタンスかなと導き出せる必用があります。ということで、まずインスタンスの分類をみてみましょう。現在、5種類に分類されています。

  • 汎用
  • コンピューティング最適化
  • メモリ最適化
  • 高速コンピューティング
  • ストレージ最適化

 次に、それぞれのインスタンスの特徴と具体的なインスタンスファミリーをみてみましょう。

汎用

 汎用タイプは、言葉通り一番用途の幅が広いものです。CPU・メモリのバランスが取られています。どのタイプが良いか解らない場合は、まず汎用タイプを使ってみて、CPUやメモリの利用状況を計測してみると良いでしょう。

インスタンスファミリー 概要
A1 ArmベースのAWS Graviton プロセッサを搭載
T3 バースト可能なCPU。もともとTiny(小さな)という意味でパワーとコストを抑えたファミリー
T3a AMDベースのT3ファミリー
M6g AWS Graviton2 プロセッサベース。Mシリーズの6世代目は、現在はこのM6gだけ。Intelベースは今後出てくるのか?
M5 一番オーソドックスな構成のファミリー。最初のEC2インスタンスは、M1.smallだった
M5a AMDベースのM5ファミリー
M5n ネットワークを強化したM5ファミリー

Mシリーズがベーシックで、それ以外にTシリーズのバースト特性を把握しておく事が大切です。

コンピューティング最適化

 コンピューティング最適化はメモリに比べてCPUの性能比率が高いものです。CPUを多様するアプリケーション処理で利用するとパフォーマンスが向上します。なにげにWebサーバーで利用されるケースも多いです。インスタンスファミリーとしては、事実上1系統のCしかありません。CPUが良いのはCと覚えておきましょう。

インスタンスファミリー 概要
C6g ArmベースのAWS Graviton2 プロセッサを搭載。M6gと同様、最新世代はgだけ出ている
C5 C5ファミリーのオーソドックスな構成。Intelベース
C5a AMDベースのC5ファミリー
C5n ネットワークを強化したC5ファミリー

メモリ最適化

 名前の通り、メモリが大量に載っています。実はちょっとややこしくなってくるのが、このメモリ最適化以降。汎用化やコンピューティング最適化に比べ、利用の機会が限定的なので何だっけかなとなりがちです。代表的なのはRシリーズなので、RAM(Random Access Memory)がいっぱい使いたければRと覚えておきましょう。

インスタンスファミリー 概要
R6g ArmベースのAWS Graviton2 プロセッサを搭載。M6gと同様、最新世代はgだけ出ている
R5 C5ファミリーのオーソドックスな構成。Intelベース
R5a AMDベースのC5ファミリー
R5n ネットワークを強化したC5ファミリー
X1e SAP HANAとかにも使われるエンタープライズ向けインスタンスファミリー
X1 x1.16xlargeから始まってvCPUが64個に976GBのメモリから
ハイメモリ SAP HANAとかに使われるものごっついインスタンスファミリー。u-6tb1.metalという名前から解るようにベアメタル用
z1d CPUとメモリのどちらも高性能なインスタンスファミリー

X1などは、オンデマンドで利用すると1時間で1千円くらいします。とすると、1年間で876万円。富豪的ですね。

高速コンピューティング

この辺りから理解が難しくなってきます。高速コンピューティングとあるので、コンピューティング最適化とどう違うのとまず疑問になると思います。コンピューティング最適化はCPUの性能が高く、高速コンピューティングはGPU等のCPU以外を使っての処理が得意とざっくり抑えておいてください。

インスタンスファミリー 概要
P3 汎用 GPU インスタンス。画像処理となるとこのインスタンスファミリー
Inf1 機械学習推論アプリケーションに適したAWS Inferentia チップを搭載
G4 機械学習推論やグラフィックを大量に使用するワークロードに最適化
F1 FPGAが利用可能な特殊なインスタンス

 高速コンピューティングについては、概要を読んでもサッパリ解らないのではと思います。まず標準的なタイプがP3となります。NVIDIA Tesla V100 GPUを搭載し、画像処理(Picture)が得意なPシリーズとでも覚えておいてください。次にG4です。G4も機械学習推論やグラフィックとなっており、こちらも画像処理できるのかいと思うでしょう。こちらはNVIDIA T4 Tensor Core GPUsを搭載し、機械学習用途と理解しておきましょう。
 Inf1とF1は、更に特殊性が高いです。Inf1は用途的にはG4と同じで機械学習推論で利用されます。AWSが開発したAWS Inferentia チップを搭載し、コストパフォマンスが高い機械学習用途のインスタンスファミリーと理解しておきましょう。最後のF1は一番特殊です。FPGAということで、カスタムハードウェアアクセラレーションを実現できます。チップに処理を埋め込むような形で利用します。そうすることで、ハードウェアレベルで低コストでパフォーマンスの高い処理ができるとのことです。かなり特殊な用途ですね。

ストレージ最適化

 ストレージ最適化は、ストレージ処理に特化したインスタンスです。特徴としては、EBSじゃなくローカルストレージ(インスタンスストア)の性能が高く容量も大きいということです。

インスタンスファミリー 概要
I3 SSDベースで、Non-Volatile Memory Express (NVMe) SSD-backed インスタンスストレージを提供
I3en I3の拡張でネットワーク帯域が大きい
D2 HDDベースのインスタンスファミリー6〜48TBのローカルストレージ
H1 HDDベースで、CPUとメモリも大きい

 ストレージ最適化のややこしいところは、概要を読んでも違いが解りにくいところです。まずHDDベースのD2, H1とSSDベースのI3で分けましょう。HDDベースはシーケンシャルなアクセスに強く、SSDベースはランダムアクセスに強いです。HDDベースのD2とH1の違いは、CPU・メモリも高性能かという点です。が、D2は2015年、H1は2017年11月に発表されたインスタンスで、どちらもその後の後継が出ていないところをみると、性能特性としてはあまり進化していっていないです。同様にI3も2017年2月以降、後継のものは出ていません。

どのインスタンスを使うのか?

 いろいろなインスタンスファミリーを紹介して混乱したかも知れません。使い方に迷ったら、まずはMシリーズを使いましょう。そして、そのCPUやメモリの利用状況をみて、Cシリーズも検討しましょう。開発用途とかでコストを抑えたい場合は、Tシリーズになります。この3種類を使いこなせると、一般的なアプリケーション用途であれば9割ほどがカバーできます。認定試験対策としても、インスタンスファミリーの理解は必用ですので、これを機会に覚えてみてはいかがでしょうか?

Fin-JAWS 第14回で、AWS認定セキュリティ専門知識を基軸にAWSのセキュリティについて話しました

 8月13日に開催されたFin-JAWS 第14回 Fin人類育成計画で、論理登壇しました。全体のテーマは人材育成ということで、AWS認定試験の対策本の著者たちが集まってそれぞれ話しています。私は、セキュリティ専門知識の対策本を出した縁で、AWSのセキュリティの考え方を軸に話しました。

fin-jaws.connpass.com

登壇資料とTogetterまとめ

 当日の登壇資料は、これです。

speakerdeck.com

 当日のTwitterのまとめです。かなり活発に意見が飛び交いまして、最後には#finjawsのハッシュタグがトレンド入りしていました。

togetter.com

AWSのセキュリティの考え方

 資料中に書いていますが、当日話したことをダイジェストでお伝えします。

巨人の肩に乗る

 今やセキュリティ対策として検討する必用がある領域は、非常に多岐に渡っています。何の対策が必用か、自分で考えるのは現実的ではなくなっています。そこで、先人たちが考えたフレームワークに乗っかかるというのは非常に有効です。いわゆる巨人の肩に乗るということですね。

f:id:dkfj:20200820084747p:plain

 AWSのセキュリティ分野であれば、NISTのサイバーセキュリティフレームワークとAWS Well−Architectedフレームワークをまず読むことをおすすめします。

NIST サイバーセキュリティフレームワーク コア(IPA公開版)
AWS Well-Architected フレームワーク

 この2つを読み比べると解るのですが、どちらも結構似たことを言っています。それもそのはずで、AWS Well-Architectedのセキュリティの柱はNIST サイバーセキュリティフレームワークを下敷きにしている部分も多々あります。また既にWell-Architectedフレームワーク読んだよという方も、もう一度読んで見ることをお勧めします。2020年3月と7月に改訂されています。フレームワークもどんどん進化しているということですね。

 NIST サイバーセキュリティフレームワークの解説については、次の記事がお勧めです。

www.secure-sketch.com

フレームワークを当てはめる

 フレームワークでセキュリティ対策の概要を知ったら、次は実際のシステムにどのように当てはめればよいのかを考えてみましょう。その際のお勧めは、要素・構成を抽出して、同じシステムでも目的別・レイヤー別・アーキテクチャ別などいろいろな観点から構成を考えてみるのがよいです。

f:id:dkfj:20200820085748p:plain

f:id:dkfj:20200820085803p:plain

f:id:dkfj:20200820085815p:plain

 実は上記の図は全て、私が書いた技術同人誌である『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』からの引用です。当日話した内容をテキストベースで詳しく説明しているので、もし興味がありましたらBOOTHで見てください。2章までの無料版を公開しています。

booth.pm

伴走者を見つける

 これも持論ですが、この手の対策は机上でドキュメント読むだけで身につけるのは中々難しいです。実際に自分で設定して運用してみると、セキュリティーフレームワークが言わんとしていた事が理解できるようになってきます。で、実際に対策しようと、最初の取り掛かりが非常に大変です。なぜならばフレームワーク読んだとしても、実際に手を動かそうとした瞬間に何からすれば良いのか全く解らなくて途方にくれるからです。
 そんな際にお勧めは、最初は伴走者をつけることです。スタート時点で自分の少し前で走ってくれる伴走者がいると、走り出しが非常にスムーズになります。最初にすべきこと、次にすべきことといった優先順位の付け方の相談ができるだけで、心理的な負荷も小さいです。そして、気がついたら自走しているという形が理想的ですね。
 少し宣伝が入りますが、最近AWSのセキュリティ相談に関する案件が増えていることもあり、セキュリティ支援のサービスも開始しています。どういったアプローチで対策するかや、定番の対策方法についてはテンプレート化して提供もしています。も興味があれば、お気軽にお問い合わせください。

www.nri-net.com

まとめ

 ということで、AWSのセキュリティをどのような観点で考えて対策していくのかということの紹介でした。何から始めればよいか途方にくれている人の一助となれればと思っています。あと今月は、8/25にJAWS-UG朝会、8/28にSecurity-JAWS と立て続けに登壇します。朝会の方はCloudFormation StackSets × Organizations、Security-JAWSは試験対策寄りの話しをする予定です。お時間の都合が付けば、ぜひご参加ください。

jawsug-asa.connpass.com

s-jaws.doorkeeper.jp


AWSのAutoScalingの整理 猶予期間・ウォームアップ・終了ポリシー編

 基本に立ち返ろうということで、AWSのAutoScalingの仕様の確認です。前回は、スケーリングポリシーを中心に確認でした。今回は、起動や終了に関わる仕様ということで、猶予期間・ウォームアップ・クールダウン・終了ポリシーなどの解説になります。

前回
AWSのAutoScalingの整理 スケーリングポリシー編 - プログラマでありたい

ヘルスチェックと猶予期間



 まず最初にヘルスチェックと猶予期間です。ヘルスチェックは、AutoScalingの管理対象下のインスタンスの動作をチェックして、異常が認められた場合は新しいインスタンスと置き換えられます。

Auto Scaling インスタンスのヘルスステータスは、正常または異常のどちらかです。Auto Scaling グループ内のすべてのインスタンスは正常な状態で起動されます。インスタンスに異常があるという通知を Amazon EC2 Auto Scaling が受け取らない限り、インスタンスは正常であると見なされます。この通知は、Amazon EC2、Elastic Load Balancing (ELB)、カスタムヘルスチェックのうち 1 つ以上のソースから送られる可能性があります。

Amazon EC2 Auto Scaling がインスタンスを異常ありとマークすると、置き換えがスケジュールされます。インスタンスを置き換えない場合は、個々の Auto Scaling グループに対するヘルスチェックプロセスを停止できます。

Auto Scaling インスタンスのヘルスチェック - Amazon EC2 Auto Scaling (日本語)

 このヘルスチェックの挙動を理解するために重要になるのが、ヘルスチェック猶予期間です。英語では、Health Check Grace Periodです。AutoScalingが発動してインスタンスが起動されても、インスタンスの起動時間やインスタンス内のプロセスの起動時間があるために、すぐにそのインスタンスが利用可能な状態になる訳ではありません。その間にヘルスチェックでエラーが出続けると困るので、一定期間ヘルスチェックをしないという猶予期間があります。画面コンソールから作った場合の、猶予期間はデフォルトで300秒(5分)です。が、CLIやSDKから作った場合は、なんと0秒です。この辺の差異がある経緯、ちょっと気になりますね。

f:id:dkfj:20200810154503p:plain


 ヘルスチェックの猶予期間の設定画面をみると、EC2ELBの2つのヘルスチェックがあることに気が付きます。この違いは何なのか、それぞれ見てみましょう。

Amazon EC2 ステータスチェック

 まずEC2の方です。こちらは、正式名称がAmazon EC2 ステータスチェックです。その名の通り、EC2インスタンス単体としてのヘルスチェックを行います。AutoScalingのデフォルトのチェックは、こちらです。

Elastic Load Balancing (ELB) ヘルスチェック

 Elastic Load Balancing (ELB) ヘルスチェックは、ELBが提供するテストに基づいて判断されます。対象となるものは、ALBとNLBのターゲットグループならびにCLBです。ヘルスチェックの方法は、ELBの種類によって異なります。ALBの場合はアプリケーションレイヤー (HTTP および HTTPS) のヘルスチェックをサポートし、NLBとCLBの場合は、アプリケーションレイヤー (HTTP/HTTPS) とTCPの両方のヘルスチェックをサポートします。インスタンスは正常だけど、ELBから利用するプロセスが異常という場合に、素早く対処したい場合はELBヘルスチェックを利用します。
 ELBのヘルスチェックでややこしいのは、ヘルスチェック猶予期間はあくまでAuto Scalingの中だけで完結していることです。つまり、ELBからのヘルスチェックは猶予期間内であってもUnHealthyを返します。アラートがならないようにヘルスチェックをするには、この辺を考える必用があります。

 クラスメソッドさんのブログでも同じテーマで課題提起があり、ELB側ではなくAuto Scaling Group側のGroupTerminatingInstancesがお勧めとのことです。

ELB配下でAuto Scalingを構成する場合には、ELB側のUnHealthyHostCountを利用するのではなく、Auto Scaling Groupが持っているGroupTerminatingInstancesメトリクスを利用した監視がオススメとのことです。

EC2 Auto Scaling グループの「ヘルスチェックの猶予期間」を正しく理解する | Developers.IO

スケーリングクールダウンとウォームアップ


 ヘルスチェックの猶予期間を理解したのでAutoScalingについては完璧かと思いきや、AutoScalingにはクールダウンとウォームアップという概念があります。こちらも理解しておきましょう。

クールダウン

まずはクールダウンです。正式名称は、スケーリングクールダウンというようです。これはAutoScalingが発動した直後に追加でインスタンスの増減がなされるのを防ぐための設定です。猶予期間と混同されがちですが、猶予期間はヘルスチェックの猶予であり、クールダウンはインスタンスの増減のアクションの発動に対してのパラメータとなります。

f:id:dkfj:20200810184407p:plain


 ちなみにAWSの説明では、古い設定であり現在ではデフォルトの設定のまま調整しないで済むとバッサリと切り捨てられています。

スケーリングアクティビティが完了してから別のアクティビティが開始されるまでの時間を変更します。時間の長さは、インスタンスのウォームアップ期間、またはその他のアプリケーションニーズに基づいて設定できます。これは古い設定であり、ほとんどの場合において、デフォルトの 300 秒のままとすることができます。クールダウンオプションは、ターゲット追跡スケーリングポリシー、ステップスケーリングポリシー、またはスケジュールされたスケーリングではサポートされていません。

 切り捨てられている理由としては、クールダウンは主として簡易スケーリングに対するパラメータとして動いているためです。ステップスケーリングの場合、メトリクスに対して複数の閾値が指定できます。そのためスケーリング動作中に、別の閾値に達した場合にはクールダウンと関係なく反応するようになっています。一方で50%で1台追加で60%で2台追加と設定している場合、50%に反応して1台追加中に60%に達し更に2台追加となると過剰に追加しすぎとなる場合があります。それを抑止するために、ウォームアップという概念があります。

ウォームアップ

 ウォームアップは前述のとおり、ほぼステップスケーリングで差分でインスタンスを追加するために追加された機能です。事実、ステップスケーリングの機能が追加された時に、パラメーターとして登場しています。動作のポイントは2つです。CPUの利用率が50%の時に1台追加、70%の時に2台追加というポリシーが設定された場合を例に解説します。

  • (インスタンス追加され)ウォームアップ期間中には、そのアラームでのインスタンス追加はされない
  • ウォームアップ期間中に次のアラート(70%)が発動した場合、差分の台数が追加される

f:id:dkfj:20200810231420p:plain

ウォームアップは、ステップスケーリングとターゲット追跡スケーリングポリシーに対応しています。

その他のAutoScalingのオプション


 猶予期間とクールダウン、ウォームアップを理解できれば、AutoScalingのオプションについて、ほぼ理解していると言えるのではないでしょうか。ただ、上記以外にも、まだ幾つかオプションがあります。代表的なのがライフサイクルフックと終了ポリシーです。せっかくなので、この2つについても見ていきましょう。

ライフサイクルフック

 ライフサイクルフックは、Auto Scalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行する機能です。例えば、起動時にデータを取得してきたり、削除時にログやデータの退避の処理を追加するといった用途で使えます。待機時間はデフォルトで1時間、最大で48時間まで設定できます。ただ48時間必用なケースは、どうしても思い浮かびません。

https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/lifecycle_hooks.png

終了ポリシー

 負荷に応じてインスタンスを増やすのをスケールアウトと言います。これに対して、負荷が下がってインスタンスを減らす場合はスケールインといいます。さてAutoScalingでは、スケールインの際に、どのインスタンスを削除するのでしょうか?これを決めるのが、終了ポリシーです。デフォルトの終了ポリシーでは、インスタンスがアベイラビリティーゾーンに均等に配分されるように削除します。2つのAZで2台・3台とインスタンスがある場合、3台あるAZのインスタンスを一つ削除させてAZ間で均等にさせるというような動作になります。それ以外にも、

終了ポリシー 概要
OldestInstance 最も古いインスタンスを削除
NewestInstance 最も新しいインスタンスを削除
OldestLaunchConfiguration 最も古い起動設定のインスタンスを削除
ClosestToNextInstanceHour 次の課金時間に最も近いインスタンスを削除
Default
OldestLaunchTemplate 最も古い起動テンプレートを使用するインスタンスを削除
AllocationStrategy スポットまたはオンデマンドなどのインスタンスタイプの配分戦略に沿って削除

ClosestToNextInstanceHourなんかは、出た当初は素敵と思ったのですが、今はEC2のインスタンスの課金単位時間が1時間から1秒に変わりほぼ意味がなくなっていそうです。今だと、どういった挙動になるのは、どこかで実験してみます。1時間という前提を残して動くのではと予想しています。

まとめ



 前後2回に渡って整理してきたEc2 AutoScalingの仕様の確認はいかがでしたでしょうか?普段使わない設定も多く、知らない事も多かったのではないでしょうか?AWSの認定試験は、ケースごとにどのような設定をすれば良いのかということを問われます。そのためには、網羅的に仕様を把握しておく必用があり、AutoScalingは特に重要なポイントです。ELBとAutoScalingは一緒に設定することが多く、どれがどちらの仕様か混同して覚えてしまうことが多いです。一度、AutoScalingとELBを別々に学ぶというのは有効だと思います。
 次回は、ELBを整理してみようと思います。

AWSのAutoScalingの整理 スケーリングポリシー編

 AWS認定試験の対策本を書いていることもあって、試験についての相談を受けることがよくあります。その中で、AutoScaling関係の問題が難しいという相談が多い。話しを聞いていると、ELBの機能かAutoScalingの機能か切り分けて理解していないケースが多いようです。実務的には、ELBとAutoScalingは一体で使うことが多く、無理もないかなぁと思います。
 私も曖昧な理解している所が多かったので、改めてAutoScalingの機能について整理してみました。そうすると思っていた以上に多くの機能がアップデートされていて、定期的に知識のアップデートすることが必用だなと痛感させられます。ということで、今日はAWSのAutoScalingについて整理してみます。

EC2 AutoScaling


 EC2 AutoScalingは、EC2インスタンスの利用状況に応じて動的に増減させるサービスです。クラウドの特徴を活かした機能で、必用な時に必用なリソースを用意するというクラウドの象徴的な機能の一つではないでしょうか?私も初めてこの機能を使った時の感激はひとしおでした。さて、このEC2 AutoScalingには複数のスケーリング方法があり、次の3つの分類できます。

  • 動的なスケーリング
  • 予測スケーリング
  • スケジュールスケーリング

一番代表的なのが、1つ目の動的なスケーリングです。動的なスケーリングには、更に3種類のスケーリングの設定方法があります。

  • 簡易スケーリング
  • ステップスケーリング
  • ターゲット追跡スケーリング
簡易スケーリング

 1つ目の簡易スケーリングはCPU使用率が70%を超えたらといったように、1つのメトリクスに対して1つの閾値を設定します。簡易スケーリングという名前に変えられてしまいましたが、これが最初期のスケーリング方法です。古参のAWSユーザーには馴染みが深いのでは思います。で、実はこれは今は非推奨になっていて、簡易スケーリングを使いたい場合は、それよりも次で紹介するステップスケーリングを使うべきとなっています。

ステップスケーリング

 では、そのステップスケーリングです。ステップスケーリングは、1つのメトリクスに対して複数の閾値を設定します。例えば、CPU使用率が50%を超えた場合、60%を超えた場合と段階(ステップ)ごとの設定ができます。また、複数の閾値を設定できるものの1つの閾値のみを設定することもできます。つまり、簡易スケーリングの上位互換ということです。そのため、AWSとしては簡易スケーリングよりステップスケーリングを推奨しています。

AutoScalingグループの初期設定画面で、簡易スケーリングとステップスケーリングが選択できない

 と、ここまで来てAutoScalingグループの初期設定画面をみてみましょう。いつからかこうなっているのか解らないのですが、今では初期設定段階では簡易スケーリングもステップスケーリングも選択できなくなっています。これから紹介するターゲット追跡スケーリングか、スケーリングポリシー無しのどちらかです。AutoScalingグループなのにスケーリングなしって何だよと突っ込みたくなるかもしれませんが、例えば初期に設定した2台をずっと維持したい場合や、途中でインスタンスの障害が発生しても新たに立ち上げて2台を維持したいという場合、スケジュールスケーリングで時間に従ってインスタンスの増減させたい場合に効力を発揮します。
f:id:dkfj:20200808105951p:plain

 では、簡易スケーリングとステップスケーリングは設定できないのかというとそうではなく、AutoScaling グループ作成後に設定変更で選択できるようにはなっています。またCLIでは、パラメータを指定すれば初期設定時点から指定ができます。AWSとしては、この2つではなくターゲット追跡スケーリングを使ってねという強い意志を感じますね。

f:id:dkfj:20200808110009p:plain

ターゲット追跡スケーリング

 最後にターゲット追跡スケーリングです。1つのメトリクスに対して、目標値を設定します。例えばCPUの利用率を50%という目標値を設定すると、AutoScalingグループ全体でCPU利用率が50%を維持できるように自動的に調整されます。ステップスケーリングのように、細かく刻んで設定しなくてもAWS側があんじょうやってくれます。これは楽でいいですよね。従来ですとメトリクスに対してどのようにスケーリングさせるのかは、ある意味ノウハウでした。この辺りがお任せできます。

f:id:dkfj:20200808113306p:plain

 ということで、EC2ダッシュボードの新UIで、AutoScalingの設定の動画です。ELBと連携させず、また起動テンプレートを設定済みという状況での作成の流れです。


EC2ダッシュボードの新UIでAutoScaling設定

起動設定と起動テンプレート


 ここまで読んで起動テンプレートってなんぞやと思った人もいるかと思います。起動設定じゃないのと。従来、AutoScalingグループは、起動設定を利用していました。今は、起動設定と起動テンプレートのどちらの指定も可能となっています。そして、新UIでは、起動テンプレートがデフォルトとなっています。つまり、起動テンプレートが推奨なのですね。
 起動テンプレートは、よく使うEC2の起動設定をテンプレート化して再利用しやすくするものです。一度、テンプレート化しておけば、二度目以降は台数指定するだけで同じ設定のものを起動できるようになります。この起動テンプレートは、別にAutoScalingグループのためだけにあるのではなく、通常のEC2の起動にも使えます。また設定内容も起動設定よりも細かく指定できるので、上位互換ですね。こちらもデフォルトになっていって、起動設定は恐らく緩やかにフェードアウトしていくのでしょう。

スケジュールスケーリング


 スケジュールスケーリングは、Auto Scalingの設定後にオプションで設定します。詳細画面の自動スケーリングタブの予定されたアクションから設定できます。

f:id:dkfj:20200809094808p:plain

 指定の仕方は、Cron式や、5分毎・30分毎・1時間毎・毎日・毎週・一度の指定ができます。注意点としては、時間の指定はUTCであることと、一時的に増やした場合は対となる減らす設定も必用ということです。

f:id:dkfj:20200809100845p:plain

AWS Auto ScalingとAmazon EC2 Auto Scaling


 ここまでがEC2のAuto Scalingグループのスケーリングポリシーの説明でした。最初に3つのスケーリングポリシーがあると言っていたものの、予測スケーリングがまだ出てきていません。実はややこしいことに、今現在のAWSのAuto Scalingは、AWS Auto ScalingとAmazon EC2 Auto Scaling、そしてApplication Auto Scalingの3種類があります。このうち、Application Auto Scalingは、ECSやEMRのクラスターやDynamoDBなどのアプリケーションのAuto Scalingを担当します。AWS Auto Scalingは独立したサービスのカテゴリーとして存在し、予測スケーリングはAWS Auto Scalingから設定することになります。AWS Auto Scalingは、管理カテゴリーに属するサービスとなります。

f:id:dkfj:20200808221245p:plain

 EC2のAuto Scalingで予測スケーリングを利用する場合は、設定済みのAuto Scalingグループを指定します。その際は、スケーリングポリシーはなしにしておきましょう。

f:id:dkfj:20200809101725p:plain

 そして、どういった方針に従ってスケーリングさせるかのスケーリング戦略を指定します。カスタムで細かく指定することも出来ますが、可用性最適化・コスト最適化などのデフォルトの戦略があるので、それを使うのも良いと思います。

f:id:dkfj:20200809101744p:plain

 こういった感じで、AWS Auto Scalingを利用した予測スケーリングも簡単に指定できます。ただし、EC2の管理画面から離れているということもあり、初見では解りづらいというのもあるかと思います。そのうち、EC2のダッシュボードからも指定できるようになるのではという気がします。

まとめ


 かなり長くなってきたので、今回はここまでとします。AutoScalingは、実はAWS AutoScalingとApplication AutoScaling、Amazon EC2 AutoScalingの3つがあります。一般的にAutoScalingと言われているものは、Amazon EC2 AutoScalingだと思いますが、今後はカテゴリーとして独立しているAWS AutoScalingの機能拡張がされていきそうです。Amazon EC2 AutoScalingのスケーリングポリシーには、簡易スケーリング・ステップスケーリング・ターゲット追跡スケーリングの3つがありますが、AWSとしてはターゲット追跡スケーリングを推しているようです。実際、細かいことを考えずに充分使えるのでお勧めです。

 もともと猶予期間やウォームアップ・終了ポリシーなどの解説をしようとしたのですが、Auto Scalingのアップデートを追っているうちに長くなってしまいました。次回、Auto Scalingの細かい話を解説します。AutoScalingは、AWSを使いこなす上でも、AWSの認定試験の対策でも重要なテーマとなります。どういった設定ができるのか、またどういった時に使わけるのか、しっかりと理解しておきましょう。

AWSのAutoScalingの整理 猶予期間・ウォームアップ・終了ポリシー編 - プログラマでありたい


AWS認定 セキュリティ専門知識の対策本の書名・目次と書影

 今月7月29日発売のAWS認定 セキュリティ専門知識の対策本の書名や目次と書影がFIXしましたので紹介です。

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

書籍の内容について

共著者の上野さんと、私の方からそれぞれ書籍紹介のエントリーをあげています。書籍の内容については、こちらを参照ください。

fu3ak1.hatenablog.com


blog.takuros.net

表紙について

 表紙については、オレンジと黒を基調としたデザインです。帯の文言に『この1冊で身に付く!』とありますが、この本1冊読んだだけで合格するほどスペシャリティの試験は甘くありません。この本をガイドブックに、いろいろな資料・ドキュメントを読み、その上で実際に手を動かし経験を積むことによって合格レベルまでたどり着けます。という意味で、ちょっと不適切な文言なので、今後は直してもらうように調整しています。見落としており、初版は間に合わないのでご容赦ください。

f:id:dkfj:20200719003858j:plain

目次

 最後に目次です。おおよそ試験範囲のところを網羅していると思います。マルチアカウントまでは出ないかなぁと思いつつ、セキュリティ上重要なのでカバーしております。

第1章 AWS試験概要と学習方法
 1-1 AWS認定試験の概要
 1-2 学習教材
 1-3 学習の進め方
 1-4 何に重きをおいて学習すべきか
第2章 IDおよびアクセス管理
 2-1 IAM
 2-2 AWS Directory Service
 2-3 AWS Organization
 2-4 Amazon Cognito
 2-5 AWS Organizations
 2-6 IDおよびアクセス管理に関するアーキテクチャ、実例
 2-7 IDおよびアクセス管理 まとめ
第3章 インフラストラクチャのセキュリティ
 3-1 AWS WAF
 3-2 AWS Shield
 3-3 AWS Firewall Manager
 3-4 Amazon Route 53
 3-5 Amazon CloudFront
 3-6 Elastic Load Balancing
 3-7 AWS Auto Scaling
 3-8 Amazon API Gateway
 3-9 Amazon Virtual Private Cloud
 3-10 Security Group
 3-11 AWS Artifact
 3-12 セキュリティに関するインフラストラクチャのアーキテクチャ、実例
 3-13 インフラストラクチャのセキュリティ まとめ
第4章 データ保護
 4-1 AWS Key Management Service (KMS)
 4-2 AWS CloudHSM
 4-3 Amazon Elastic Block Store (Amazon EBS)
 4-4 Amazon RDS
 4-5 Amazon DynamoDB
 4-6 Amazon S3
 4-7 Amazon Secrets Manager
 4-8 データ保護に関するアーキテクチャ、実例
 4-9 データ保護 まとめ
第5章 ログと監視
 5-1 Amazon CloudWatch
 5-2 AWS Config
 5-3 AWS CloudTrail
 5-4 AWS X-Ray
 5-5 Amazon Inspector
 5-6 S3に保存されるAWSサービスのログ
 5-7 Amazon Athena
 5-8 VPC Flow Logs(フローログ)
 5-9 Amazon QuickSight
 5-10 Amazon Kinesis
 5-11 Amazon Elasticsearch Service
 5-12 ログと監視に関するアーキテクチャ、実例
 5-13 ログと監視 まとめ
第6章 インシデント対応
 6-1 AWS Config
 6-2 AWS Systems Manager
 6-3 Amazon CloudWatch
 6-4 AWS Trusted Advisor
 6-5 AWS CloudTrail
 6-6 AWS CloudFormation
 6-7 Amazon Macie
 6-8 Amazon Guard​Duty
 6-9 AWS Security Hub
 6-10 Amazon Detective
 6-11 インシデント対応に関するアーキテクチャ、実例
 6-12 インシデント対応 まとめ
第7章 AWS Well-Architected
 7-1 AWS Well-Architected
 7-2 AWS Well-Architected まとめ
第8章 練習問題
 8-1 問題の解き方
 8-2 問題・解答

感想

 ちょうど今月、AWSソリューションアーキテクトのプロフェッショナルの対策本がでました。そして、今回セキュリティ専門知識の対策本を出すことが出来ました。日本語でも高度レベルの試験対策本が商業誌として出せるようになったのは喜ばしいです。AWSの利用者が増え、かつ高度レベルの受験者が増加しているという証左だからです。市場が育ってきたということに素直に喜びを感じます。
 一方でそもそも実務で鍛えた知識や経験を問うものだから、、こういったベンダー試験に試験対策本がそもそも必用なのかという議論はあるかもしれないのです。しかし、試験対策本があることにより受験への敷居を下げる効果があるのではと考えています。また、体系的・網羅的にまとまった本があることにより、短期間で効率的に勉強できるようになると思います。効率的な勉強方法がある事が、結果的にAWSのより良い利用方法を習得している人が増えることに寄与すると信じています。
 ちょっと他の宿題を片付けたら、他のスペシャリティやプロフェッショナルの対策本についても検討してみようかなと思います。

IAMに有効期限を設定する条件式

 IAMの条件式に設定できるものを眺めていた時に、発見した小ネタです。
IAMではCondition要素で、そのポリシーが適用される条件が設定できます。
その中の1つに、有効期限を設定できる条件式があります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "DateGreaterThan": {"aws:CurrentTime": "2020-04-01T00:00:00Z"},
                "DateLessThan": {"aws:CurrentTime": "2020-06-30T23:59:59Z"}
            }
        }
    ]
}

DateGreaterThanで有効なる開始日時、DateLessThanで終了日時を指定します。日時の指定は、UTCです。

docs.aws.amazon.com

ユースケース

 一時的に許可を与える場合や、定期的にユーザー・ロールの棚卸しが必要な場合に良さそうですね。上の例では、有効期限で区切って許可ステートメントを与えていますが、○○日以降は全て許否(Deny)というポリシーを作って、グループやロールに追加するのが良いのではと思います。そうすることで、権限を制御するポリシーと有効期限を制御するポリシーを分離でき、権限ポリシーのパーツ化が図れます。図にすると、こんな感じですかね。

f:id:dkfj:20200707123355p:plain

 このような形が良いと思うのは、IAMポリシーはできるだけパーツ化したいので、個人に紐付く有効期限等を権限管理と一緒にするのは避けたいからです。そして分離する場合は、許可じゃなくて許否にします。というのは、AWSのIAMのポリシーの評価論理としては、明示的許否 > 明示的許可 > 暗黙的拒否(デフォルト拒否)となっているからです。

f:id:dkfj:20200707123546p:plain

 まぁこんな感じで使えるかなぁと思ったネタです。不要なIAMユーザーやIAMロールの定期的な削除は必要です。人間系の運用も必用となる部分なので、抜け漏れのヒューマンエラーを防ぐためにこういった手立てもよいのではないでしょうか?
 もう一歩組織としての管理が進むと、IAMユーザーは無くしてADによる認証とフェデレーションによるIAMロールの利用という形になるかと思います。全ての組織がそう出来るわけではないので、もし適合できるシチュエーションがあればご検討ください