今更ながらEC2やRDSの停止忘れを防止するSaaSをリリース
この記事は、EC2などのクラウドリソースの停止忘れを防止するSaaS、「kantok」の紹介記事です。
アルファ版を無料公開していますので、「開発用に用いているEC2やRDSインスタンスが、夜間や休日の誰も利用していない時に課金されるのを防ぎたい」という方は、ぜひ「kantok」を使っていただき機能の要望や感想を聞かせていただきたいです。
**現時点で対応しているクラウドはAWS、対応サービスはEC2とRDSです。
開発の背景
株式会社tc-iのsuwaです。弊社では深層学習モデルを学習させるために、GPUを搭載したEC2インスタンスを使うのですが、学習が完了しているにも関わらず停止することを忘れ、無駄な利用料が発生することが月に3、4回あります。
比較的安いp2.xlargeでも東京リージョンでは $1.54/hour なので、一晩で2,000円ほどの費用が発生することになります。
対策について調査したところ、「クラウドコスト管理系のツール」や「Cloudwatchアラート」を使うといった記事は見つかりましたが、「停止忘れを防止したいだけなのに値段が高い」「機能がたくさんありすぎて学習コストが高い」「気軽に使い始められない」「アラートを柔軟に設定できない」「アラートや通知を出すための仕組みを構築して運用しなければならない」といった、絶妙に痒いところに手が届かないものが多い印象でした。
また、かねてから開発に用いているEC2インスタンスの運用に関しては以下のようなトレードオフを感じておりました。
- EC2の起動停止を開発者自身に任せるためにエンジニア全員のAWSアカウントを作るのは、クラウド管理上リスクになるので、なるべくアカウント数は増やしたくない。
- かといって開発者のAWSアカウントを作らない場合、クラウド管理者に起動停止の依頼をSlackや口頭ですることになる。クラウド管理者が出勤していなかったりメッセージを見落としたりすると、停止忘れにつながるので、なるべくインスタンスを起動停止できる人は多い方が良い。
以上のような理由から、「EC2を利用しているエンジニア自身がコスト意識と責任を持って、安全にインスタンスの起動停止ができる」ようなSaaSとしてkantokを開発しました。
現状の分析: 既存のツールや運用で解決できないのか?
AWSが提供する機能を使い、以下のような仕組みを作って起動停止アラートを出したりEC2利用者自身に起動停止をやってもらうようにすることは可能ですが、プロジェクトが増えてくるとアラートの仕組みを管理すること自体が一つの仕事となってしまいそうというのが感想です。
1. Cloudwatch や Event bridgeを使って、アラートや自動停止をさせる
「EC2 停止忘れ」などで検索すると、以下の記事のようにcloudwatchやEvent bridgeを用いてアラートや自動停止を実現する記事があります。
弊社でも最初はこの方法を検討していたのですが、継続的な運用に関して以下のような難しさがありました。
- アラートの設定変更や無効化・再有効化など、クラウド管理者に依頼することになる。
- プロジェクトごとにAWSアカウントを分けているので、CloudwatchやEvent bridgeの設定を変更する場合はいちいちAWSアカウントを変更しないといけない。
- プロジェクトが増えると、どのプロジェクトで何のアラートが有効・無効になっているのかなどの管理が非常に面倒。Terraformで定義したとしても面倒。
- Cloudwatch単体では定期アラートが設定できない。この記事のようにLambdaなどを組み合わせると実現は可能だが、今度はアラートシステムの運用が発生する。メール通知を送りたい場合、AWS SESなどの設定も必要になってくる。
2. AWS CLIを使って開発者自身に起動停止してもらう
開発者がSSM(Services Systems Manager)などでEC2に接続するような構成を仮定すると、開発者のIAMポリシーにStopInstances
やStartInstances
のアクションを追加すれば、自分で起動停止してもらえる環境を作ることができます。
しかし停止忘れを防止する効果は無いので、1のようなアラートの仕組みは別途必要になります。
また、SSHで経由でアクセスをしている場合は起動停止をクラウド管理者に依頼することになります。
その他. リザーブドインスタンスを使う
ツールではありませんが、そもそもリザーブドインスタンスを使えば停止忘れの概念は無くなります。しかし、リザーブドインスタンスは一年以上の契約かつ割引率が最大でも30%オフほどなので、短期(3ヶ月ほど)の開発プロジェクトでは少し勿体無いと感じます。
例えばEC2を業務時間内でしか使わない場合は、オンデマンドの方が安くなります。
時間あたりコスト | 1ヶ月(720時間)使用時 | 1人月(160時間)使用時 | |
---|---|---|---|
オンデマンド | $1.542 | $1110.24 | $246.72 |
リザーブド(1年) | $1.080 | $777.6 | $777.6 |
リザーブド(3年) | $0.8220 | $591.84 | $591.84 |
**東京リージョン、p2.xlargeで計算
フリーランスエンジニアやインターン生に対して、EC2を開発用環境として提供するようなケースでは、停止忘れさえなければ、オンデマンドインスタンスの方が安くなることが多いと思います。
また、リザーブドインスタンスを一年分契約すると数十万 ~ 数百万円の請求が発生するので、そうとう確度が高い利用計画がないと購入に至るのは難しいと思います。
kantokでできること
1. クラウド管理者が利用者にインスタンスを割り当て、利用者がインスタンスを管理できる
kantok上には「オーナー」「管理者」「一般」の三種類の権限が存在します。
管理者以上の権限ではAWSアクセスキーの登録やユーザ管理、一般ユーザに対するインスタンスの割り当てなどのクラウド管理者としての操作が可能です。
一般ユーザはEC2を実際に利用するユーザ権限で、自分に割り当てられたリソースについてアラート設定や起動停止、CPU利用率のモニタリングが可能となっています。
2. 損失コストの分析
kantokアルファ版では、夜間(19:00 ~ 翌9:00)と週末(土曜、日曜)にリソースが起動しているにも関わらず、使われなかった時間(CPU使用率が10%以下だった時間)をアイドル時間として損失コストを見えるようにしています。
kantokアカウントを作成し、AWSのアクセスキーをセットアップすれば、直近二ヶ月の損失コストを確認することができます。
夜間や週末の損失コストが、それぞれ月当たり$100を超えているようであれば、無駄に稼働しているリソースがあるかもしれません。
3. AWSとの連携
kantok アルファ版は以下のポリシーを必要とします。EC2とRDSについて起動・停止・モニタリングが可能となっています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "kantok",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:SimulatePrincipalPolicy",
"sts:GetCallerIdentity",
"cloudtrail:LookupEvents",
"cloudwatch:GetMetricData",
"ec2:DescribeInstances",
"ec2:StopInstances",
"ec2:StartInstances",
"rds:DescribeDBInstances",
"rds:DescribeDBClusters",
"rds:StopDBInstance",
"rds:StartDBInstance",
"rds:StopDBCluster",
"rds:StartDBCluster"
],
"Resource": "*"
}
]
}
以下のような管理画面からアクセスキーとシークレットを登録してもらい、連携が完了します。
登録したアクセスキーから、さらにAssume Roleを実行して他のAWSアカウントと連携することも可能です。
4. (リリース予定)リソースをまとめて起動・停止
複数のEC2インスタンスやRDSを開発に用いている場合、それら全てを起動・停止したいといったユースケースがあると思います。kantokでは複数のインスタンスをまとめたリソースセットを定義することができ、それらをボタンひとつで起動・停止することができます。
5. (リリース予定)Slack、Teams連携
現状ではEメールでのアラート通知のみとなっておりますが、SlackやTeamsへの通知も順次リリースする予定です。
アルファ版を無料公開しました
今回EC2やRDSの停止忘れを防ぐため、ミニマムな機能を搭載したkantokアルファ版をリリースしました。
弊社と同じような課題を抱えている方は、ぜひ一度使ってみていただき、感想やご要望を教えていただけると大変嬉しいです!
Discussion