0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【AWS学習】キャパシティ予約の使い所がわからなくなった人へ

0
Posted at

1.はじめに

本記事の対象者は、キャパシティ予約の勉強を始めて理解が進んできた時に必ず発生する、キャパシティ予約っていつ使うの?EC2起動しっぱなしにしておけば良くない?という疑問を持っている方向けの内容となります。

現在参画しているプロジェクトにて、キャパシティ予約を採用した際に検討した実例を元に説明していきます。

2.キャパシティ予約とは

Amazon EC2のユーザーガイドには以下記載がありました。

Amazon EC2 キャパシティ予約を使用すると、任意の期間で特定のアベイラビリティーゾーンに Amazon EC2 インスタンスのコンピューティングキャパシティを予約できます。一定レベルの長期または短期のキャパシティ保証が必要な現在または今後のビジネスクリティカルなワークロードに対し、厳格なキャパシティ要件がある場合、必要な限りにいつでも Amazon EC2 キャパシティにアクセスできるようにするため、キャパシティ予約を作成することをお勧めします。

前提として知っておかないといけないこととしては、EC2インスタンスは必ず起動できるものではない、ということです。

よくよく考えてみると当たり前ですが、EC2インスタンスも元を辿ればAWSが管理している物理的な機器が存在します。

この機器の一部をインターネット経由で利用できるのがクラウドです。AWSのEC2も同様です。

そうすると、EC2インスタンスは無限に起動できるものではなく、物理的な機器の上限が存在します。

そのため、需要が突然多くなると、EC2インスタンスも売り切れ状態になり、起動できなくなることがあるという仕組みです。

EC2 インスタンスの開始時または起動時に発生する InsufficientInstanceCapacity エラーをトラブルシューティングする方法を教えてください
https://repost.aws/ja/knowledge-center/ec2-insufficient-capacity-errors

そこで利用できるのがキャパシティ予約になります。

キャパシティ予約は、名前の通りキャパシティを予約しておくことで、EC2インスタンスを確実に起動することができる、というものになります。

よくある勘違いを1つ紹介しておきますと、EC2インスタンスを構築しておいて停止状態にしておいたとしても、新規構築時同様、必ず起動できるわけではありませんのでご注意ください。

3.キャパシティ予約の具体例

では、需要が突然多くなるのはどのような時でしょうか。

真っ先に思いつくのは、AZ障害時です。

以下のように、2つのAZに跨って2台のEC2で構成しているシステムを考えてみます。

前提として、AZ障害発生時はもう一方の生きているAZでEC2を起動し、常に2台構成が求められるものとします。

png-1.png
 ↓AZ障害発生後の構成
png-2.png

キャパシティ予約を採用しているかはともかく、AZ障害時の対応として上記のような構成を取っているシステムは多いのではないでしょうか。

こういった場合に、EC2インスタンスを起動できない可能性があるのでキャパシティ予約を採用しましょうということになります。

4.キャパシティ予約を採用する際の構成例(本題)

これにて一安心・・・とはいかないのがキャパシティ予約です。

実はキャパシティ予約は、EC2インスタンスを起動するのと同額(EBSは対象外)のお金がかかります。

つまり、以下のように初めからEC2を3台構成にしておくのと金銭面では差がないのです。
png-4.png

これが冒頭お伝えした、キャパシティ予約を使わずEC2起動しておけば良くない?という疑問に繋がるわけです。

ではどういった時にキャパシティ予約が活用できるのか?

結論、以下のような1システムで複数環境(本番・検証)を運用している場合に採用を検討することをおすすめします。
png-5.png

本番環境とは別に、本番環境でトラブルが発生した際の調査環境などを用意しておくのは良くあるかと思います。

そういったシステムの場合、キャパシティ予約を活用できる可能性があります。

以下にて、AZ障害発生時の動きを確認してみましょう。

ポイントは2つで、

  • 通常時は検証環境でキャパシティ予約を利用してEC2インスタンスを立ち上げておくこと
  • 障害時は検証環境のEC2インスタンスを停止してキャパシティ予約を解放し、本番環境でキャパシティ予約を利用すること

です。
png-3.png

こうすることで、先ほどお話をした余計にお金がかかる問題を解消することができます。

5.まとめ

キャパシティ予約は、機能自体シンプルですが、使い所がイメージしづらいかと思います。

1システムで複数環境を運用しているものがあれば、一度キャパシティ予約の採用を検討してみてください。もしかしたらEC2を削減できるかもしれません。

どなたかのコスト削減に繋がりましたら幸いです。

おまけ(複数アカウントでのキャパシティ予約利用時の注意点)

環境ごとにアカウントを分けている場合は、AWS Resource Access Managerを利用することで、キャパシティ予約を共有することができます。

この際の注意点として、アカウントごとにAZの割り当てが変わるということを覚えておく必要があります。

正確には、AZ IDが変わります。

AZの話をする際には、AZ名AZ IDを理解する必要があります。

東京リージョンを例にすると、AZ名と呼ばれているものがap-northeast-1aになります。

一方、AZ IDというのは、apne1-az1というような表記のものになります。

このAZ IDがどこのデータセンターかを示しているものになります。

そして、このAZ IDはAZ名と紐づいているのですが、この紐付き方がアカウント毎に変わるのです。

アカウントAでは、ap-northeast-1a=apne1-az1。
アカウントBでは、ap-northeast-1a=apne1-az3。

ということになる可能性があります。

そして注意しなければいけないのが、キャパシティ予約はAZ IDに紐づいているのです。

つまり、アカウントAのap-northeast-1aでキャパシティ予約を設定した場合、アカウントBのap-northeast-1aでは利用できないのです。

そのため、AWS Resource Access Managerを利用する場合には、事前に各アカウントのAZ IDがどうなっているのか確認してから利用するようにしましょう。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?