opswitchを利用して組織の検証環境の定時停止起動のベースラインを作成してみた
こんにちは。クラウド事業本部の木村です。
日頃組織のコスト最適化を推進しているのですが、その中で検証環境のリソース（EC2,RDS等）の夜間や休日に停止を行う際のベースラインを検討する機会がございましたのでその内容を共有したいと思います。
弊社で提供しているopswitchを利用することで、CCoEチームとアプリチーム双方の負荷が極力かからない形でコスト最適化を行うことを目指します。
はじめに
まず今回ですがCCoEチームがマルチアカウント環境で稼働している組織全体に対してベースラインを設定して、アプリチームが停止対象のリソースにタグを設定して停止させることを想定しています。
組織内には複数のアプリケーションが稼働しており、多数のアプリチームが存在しています。以下をアプリチームで自由に選択できるようにしてCCoEチームと調整なく設定することでアプリチームとCCoEチームが極力負荷が少なく進められるようにします。
- 平日夜の停止スケジュール
- 平日朝の起動スケジュール
- 休日の稼働有無
また上記のカスタマイズを可能にすることで、施策開始後にアプリチームで稼働時間の変更が必要な際にタグ値の変更のみで柔軟に停止・起動時間を変更できるようにもなります。
停止に伴う削減効果の試算
設定を開始する前に定時停止することでどの程度の削減効果を見込めるかと別の削減手段であるEC2にてSPを購入したケースを比較したいと思います。
まず定時停止を行うパターンですが以下の停止時間とした場合、オンデマンドでの起動と比較すると58.3%の費用が削減可能です。
- 平日22時~8時にて停止
- 休日は終日停止
これはリソース(EC2やRDS等)やインスタンスタイプ(t3.nanoやm7i.large等)に関係なく固定でこの削減率となります。
一方SPを購入するケースの場合はリソースやインスタンスタイプ及び購入方法条件によって変動幅が大きいです。
ですのであくまで参考程度の情報になりますが、1年のSPの割引率が20%~40%程度であるケースが大半で1年でSPを購入するパターンと比較すると定時停止を行う方が削減効果が大きくなるケースが多いです。
逆に3年のSP(主にInstance SP)を購入するケースでは、定時停止させるよりも若干割引率が高くなるケースがあります。但し3年間購入したプランで利用を継続する必要がありますので、そのリスクと割引率を天秤にかけて検討いただければと思います。
割引率の詳細については以下の料金表をご参照ください。
CCoEチームで行うopswitchのベースライン設定
ここからopswitchにて定時停止の仕組みを作成していきたいと思います。
今回は2つの検証用アカウントに対して、EC2のベースラインを設定する例で進めていきます。
opswitchの初期設定の説明はここでは割愛させていただきます。
初期設定方法やアカウント連携については以下をご参照ください。
opswitchでは今回は以下のジョブの作成を行います。
- 夜間の停止(20時~24時の1時間刻み)
- 平日早朝の起動(5時~9時の1時間刻み)
- 休日も含む毎日の早朝の起動(5時~9時の1時間刻み)
これらを組み合わせることで、以下のように柔軟性を持った設定を実現させます。
- 例
- 平日5時の起動、夜間20時の停止
- 平日9時の起動、夜間24時の停止
- 毎日8時の起動、夜間20時の起動（休日も起動させる）
タスクの作成
まずはタスクを作成していきます。
画面上部から「EC2インスタンスの起動・停止」を選択します。
続いて「作成」を選択します。
以下のように設定します。あらかじめ関連付けを行なって対象の組織アカウントを選択してください。
タグのkeyとValueで、起動停止を制御しますので他の用途で利用されているタグ値は利用しないでください。
この際タグのValueで起動の対象か判定しますので、わかりやすく起動時間と関連付けしやすい名前とするのがおすすめです。
1件作成できると、以下のように表示されます。
後の起動時間の設定は最初に作った設定をコピーして作成していきます。この際タグのValueの値も起動時間に合わせて変更してください
休日も含む毎日起動用の設定も同様にコピーして作成します。
これを繰り返して、起動用の以下タスクを作成します。
- 平日5時起動
- 平日6時起動
- 平日7時起動
- 平日8時起動
- 平日9時起動
- 毎日5時起動
- 毎日6時起動
- 毎日7時起動
- 毎日8時起動
- 毎日9時起動
同じように停止のタスクも作成していきます。起動時と同様の設定で作成していきます。
こちらもコピーを繰り返して、停止用の以下タスクを作成します。
- 毎日20時停止
- 毎日21時停止
- 毎日22時停止
- 毎日23時停止
- 毎日24時停止
ジョブの作成
続いて先ほど作成したタスクを実行するためのジョブを作成します。ジョブによって先ほど作成したタスクを決められた時間に実行させることができます。
今回の例では時間別でタスクを設定しているので、タスクとジョブが1対1で対応するように作成していきます。
まず先ほどと同様に「平日5時起動」用のジョブを作成します。
下記のようにタスクにあった実行スケジュールを設定の上、対象のタスクの関連付けを行なってください。
あとは上記と同様にタスクと合わせた事項スケジュールに合わせて作成していきます。
今回の例ではタスクを15個作っているので、ジョブも15個作成します。
（ジョブはコピー機能がないので、一つずつ作成が必要です。）
また毎日起動・停止のジョブは以下のように日時を指定してください。
以下のようにジョブの作成ができたらCCoE側で作成するベースラインの設定は完了です。
アプリチーム側で行う設定
続いてアプリチーム側で行う設定について説明していきます。
今回は先ほど例に挙げたパターンにおける設定を行なっていきたいと思います。
- 例
- 平日5時の起動、夜間20時の停止
- 平日9時の起動、夜間24時の停止
- 毎日8時の起動、夜間20時の起動（休日も起動させる）
平日5時の起動、夜間20時の停止
このパターンで行う場合には、以下のような設定を行います。
（タグの値はタスクで設定させたものと一致させてください。）
このようにアプリチーム側の対応としては、タグを2件設定いただくだけで対応が完了します。
平日9時の起動、夜間24時の停止
先ほどと違う起動停止時間の場合にはタグのValueを変更します。
上記のようにタグのValueを変更することで、起動停止時間を制御することができます。
毎日8時の起動、夜間20時の起動（休日も起動させる）
休日についても起動が必要なパターンでは先ほど設定した毎日起動が実行されるようにタグを設定します。
opswitch側でタスクを設定しておけば、休日の稼働が必要なケースについても上記のようなタグ設定で対応することが可能です。
夜間テストで一時的に稼働が必要な場合
テストなどで一時的に夜間についても稼働が必要な場合があるかと思います。
その場合については、起動が必要な期間については設定したタグを外すことで定時停止を止めることが可能です。
タグを外すだけで対応が完了するのでアプリチーム側の負荷としてはかなり小さいかと思います。
ただタグを外すのを忘れてしまうと定時停止の対象となりますので、それだけ注意してもらえればと思います。
施策当初から稼働時間の変更が必要な場合
この場合はタグを変更するだけで対応が可能です。
定時時間を20時から22時に変えたいといったパターンでは、「everydaystop」のvalueを「pm8」から「pm10」に変更するだけで対応が完了します。
まとめ
今回はopswitch利用した組織の検証環境の定時停止起動のベースラインを作成してみました。
なるべくアプリチームでの設定負荷にならないようにタグの管理だけしてもらう。CCoEチームとしてはベースラインの整備して後の対応を少なくするという形で考えてみました。
オンデマンドで24/365で動かしているような状態でしたら、今回試算したように大きな削減余地がございます。各組織に合わせて設定内容をカスタマイズして検証環境の不要なコストを削減できるように検討いただければと思います。
以上、クラウド事業本部の木村がお届けしました。
