クラウドリソースのコスト増加は“自動化”で解消　AWSリソースへのタグの自動付与で実現した「シン棚卸システム」

自己紹介

村上颯人氏（以下、村上）：それでは、「タグ！　タグ！　タグ！　AWSリソースへのタグ自動付与による、ちりも積もれば山と“せぬ”コスト削減の術～」と題して、NTT東日本の阿部と村上が発表します。

まずは自己紹介します。最初に、本日のテーマや背景などを説明する、村上颯人と申します。そして、後に今日紹介するシステムの詳細を説明する阿部綾香。この2名で発表します。所属は2人とも設備企画部というところで、主にパブリッククラウドを使用したソリューション開発や運用業務を行っています。よろしくお願いします。

クラウドリソースの棚卸活動の悩みを解決する「棚卸の極意」

では、本日のテーマになります。クラウド運用者のみなさんであれば、このような経験をしたことはないでしょうか？　「あれ？　今月のクラウドの使用料、やたら高いな、なんでだ？」。そしてよく見ると、「あっ、なんか使ってないのに稼働し続けているリソースがある、まずい！」。そこから使用していないリソースをリストアップして、一つひとつ削除する。つまり、クラウドリソースの棚卸活動をしている運用者の方。多いんじゃないでしょうか？

しかしこの棚卸、簡単ではないと思います。各リソースを一つひとつ見にいって削除するのは大変だし、複数人で共同利用している場合、勝手に削除すると、トラブルやインシデントにつながる危険性があります。本日は、こういった悩みを解決する棚卸の極意を紹介します。

設備企画部の検証環境で起きていた問題

我々のチームは社内外問わずさまざまなDX案件に携わっていて、そのシステムの多くを「AWS」で構築しています。そのため、各メンバーのAWSの習熟だったり、システムを最初に作ってみて検証するためのAWS検証環境が存在します。

その検証環境は常時30名以上が共同利用していて、多くのプロジェクトの検証に使われているので、我々の活動の生命線と言っても過言ではありません。しかし、その最強の検証環境において、知らぬ間にコストが肥大化したり、リソース数上限が逼迫したりするといった問題に直面しています。

例えばコストの面だと、EC2インスタンスが100台以上停止済みの状態で放置されていました。停止済みだとインスタンス自体に料金は発生しませんが、それに付随するルートEBSボリュームに料金がかかっていることがわかりました。

調べてみると、この「EBS」だけで、1年あたり約20万円も多めに支払っていることが判明しました。また、リソース上限でいうと顕著なのがS3バケットで。これもいろいろなところでよく使われているサービスなので、今は上限を300とかにしているんですが、数ヶ月に1回くらい上限が来て慌てて消すということを繰り返しています。

無駄なコストを払い続けているというのもあって、このような問題が続くと、最悪の場合、検証環境がストップさせられてしまうという恐れがあり、早急な解決策が求められています。

手動で棚卸を行うも、すぐに元のコストに戻ってしまう

この問題を解決するため、まずは手動での棚卸を行いました。しかし、このアプローチには多くの課題がありました。例えば、まだ検証中のサービスがあるので、全部のリソースを簡単に一気に削除することはできないという状況があります。

また、どのリソースを誰が作ったのかが不明で、リソースの所有者を確認するために時間を費やす必要があります。予算オーバーが近づくと、ヒアリングと対象リソースの削除作業を行いますが、これに約1ヶ月もかかってしまっている状況にありました。

（スライドを示して）実際に手動の棚卸を行った結果がこちらになっています。ご覧のとおり、約1人月かけて棚卸を行って、一時的にはコスト削減ができたんですが、約9ヶ月ぐらいで元のコストに戻ってしまう状況になっていました。

なぜコストやリソース数がすぐ膨らむのか？

なぜこんなふうにコストやリソース数が膨らんでいくのでしょうか？　一番の原因は、棚卸のスパンが長いことだと考えられます。

先ほどの例では1年に1回でしたが、毎月コストは増加して9ヶ月ぐらいで元に戻ってしまうので、もっと短いスパンで棚卸をやっていかないと、すぐにクラウド上に不要なリソースが溜まってしまう状況だと言えます。ただ、先述したような手動でのやり方だと、1回にかかる負荷が重いので、短期間で繰り返すことが困難になります。

「じゃあ、いっそのこと全リソースを例えば毎日とかで一斉削除しちゃえばいいんじゃないか」と考えるかもしれません。それができればいいんですが、話はそう簡単にはいかなくて。

クラウドが提供するサービスは非常に幅が広くて、各サービスごとに開発期間や検証期間が一定ではないので、短期間のうちに定期的に全部を一斉に削除することは現実的ではないです。

タグと棚卸Webによる棚卸の自動化

こういった問題を解決して棚卸するために我々が結論付けたのが、タグと棚卸Webによる、棚卸の自動化です。まず、棚卸の頻度を上げるために、手動ではなく自動で棚卸をしようと考えました。自動化するためには、「誰がいつ作成したのか」「検証中だから削除してほしくないリソースなのか」などの情報を具体的に司る必要があったので、それらをタグで管理することにしました。

ただ、「各々で手動でタグを付けてください」となると、どうしても付け忘れが発生するので、リソースを作成した時に、自動でタグを付与するシステムを構築しました。

そして、タグを使って情報整理したリソースをWeb上で表示、管理できるようにして、「どのリソースを何月何日に棚卸するか」を、Web上で設定する。あとは自動で削除してくれるシステムを構築しました。これを「棚卸Web」と名付けています。

そして、タグを自動付与して棚卸Webで削除する一連のシステムを、「シン棚卸システム」と名付けることにしました。これによって棚卸にかかる稼働が大きく削減されて、各リソースごとに棚卸日を柔軟に設定することができるようになりました。

ここから阿部にバトンタッチして、各システムの詳細について説明します。

「シン棚卸システム」の仕組み

阿部綾香氏（以下、阿部）：ここからは、私、阿部が説明します。シン棚卸システムの仕組みからお話しします。まず、マネジメントコンソールやAWS CLIでリソースを立てます。どのような方法でリソースを立てていただいても良いです。

リソースが立つとLambdaが発火し、AWSサービスのほとんどのリソースにタグが付きます。自動でタグを付ける実装は、Organizations（AWS Organizations）ではなく、フルスクラッチで実装しています。なぜフルスクラッチ、自分たちで開発したかというと、Organizationsでは「誰がリソースを作成したか」などのユーザー単位でのタグ付けができないためです。

次に、棚卸Webを操作します。棚卸Webでは、削除してほしくないリソースをリソース保護する機能。それから、逆に削除対象のリソースをリソースの作成者に通知する機能の2つがあります。

なぜ一括削除ではなくWebサイトを用意したかというと、前述したとおり、チームメンバーから削除してほしくないリソースに対して期間限定で申し入れがあるため、Webサイトでリソースを一覧化し、選択したリソースを保護できるようにしています。また、保護したリソースと作成してから20日以内のリソースは削除できないルールを敷くため、削除対象のリソースも、選択したもののみ通知してから削除しています。

次に、棚卸Webで通知した内容が「Slack」に届きます。リソースのオーナーに通知が飛ぶので、対象リソースが検証中であれば、運用者に削除しないでほしい旨を申し入れてもらいます。そして、申し入れがなかったリソースは、設定した棚卸日に自動で削除されます。

次に、棚卸Webのデモを見てください。

（デモ開始）

まず、検索窓で一覧表示するリソースを検索します。この場合はS3バケットですね。一覧が表示されました。

次に棚卸日を設定します。棚卸日は自動で削除される日付です。棚卸日が設定できました。一覧に表示されたリソースは「NotDelete」という削除不可のステータスなので、ソート、フィルターができます。

1件、リソース保護をしてみます。完了すると、完了の通知が来ます。削除の通知もしてみます。完了の通知が来ます。最後に、このサイトは運用者のみしかログインできないような仕組みになっています。

（デモ終了）

「シン棚卸システム」に実装した機能

次に、実装した機能を紹介します。3種類あります。1点目、自動タグ付け。こちらは、誰かがリソースを作成した際に自動で発火し、タグを付与するシステムです。タグの内容は、作成日、リソース、作成したオーナー、削除していいかどうかのフラグです。

2点目は棚卸Webの4つの機能です。デモでもあったように、棚卸日を設定できます。そして、サービスごとにリソースとリソースに付いているタグの一覧を取得して表示します。そして、タグの情報を基にリソースを検索、選択して、リソースを保護するための「NotDelete」タグを変更する、リソース保護の機能ですね。Slackに通知を送信する機能があります。

最後に3点目。自動削除の機能があります。指定した棚卸日に自動で発火し、削除対象のリソースを自動で削除します。

「シン棚卸システム」のアーキテクチャ

では、細かいアーキテクチャを説明します。例えばVPC（Amazon VPC）のリソースを作成したとします。左からEventBridge（Amazon EventBridge）でリソースが作成されたことを検知します。そのタイミングでLambdaが実行され、VPCにタグが付きます。リソースの作成者は、「CloudTrail」から取得してタグに付けています。

リソース保護はタグ付けと同じ要領で、「NotDelete」のタグを変更します。次に、棚卸Webで棚卸日をWebで設定すると、EventBridgeのスケジューラに登録されます。

削除通知する時はSlackに通知するのと同時に、スケジューラと同じ日付のテーブル名のDynamoDBに、削除対象のリソースのARN（Amazon Resource Name）を登録します。そして最後に、スケジューラと同じ日付のDynamoDBを照合し、棚卸日に自動で削除するLambdaを実行します。

これらの開発の内容を、次のスライドで話します。

フロントエンドは、JavaScriptとReactで1画面の構成です。CloudFront（Amazon CloudFront）とS3で静的ホスティングをしています。また、バックエンドはLambdaが6つ、DynamoDBが1種類と、棚卸日の分だけテーブルが用意されます。ポイントとしては、FaaSとNoSQLを用いたことで短納期で開発を実現したことです。

「シン棚卸システム」導入後の声

次に、導入後の声をもらっています。運用者からです。「今までリソース名だけを頼りにメンバーにヒアリングしていたが、タグ付けが自動化されてヒアリングしやすくなりました」。こちらも運用者からです。「リソースの作成日がわかるので、現在は作成が20日後を目処に棚卸の通知をしています」。最後に利用者からです。「棚卸が定期的に実行されるため、今までのクラウド環境を自由に使うことができてありがたいです」。

棚卸のサイクルの高速化はコスト削減につながる

最後にまとめです。自動でタグ付けすることで、棚卸Webから削除対象リソースを選出することができ、さらに棚卸日に選んだリソースを自動で削除することができました。

サービスごとによって異なりますが、今まで約1ヶ月程度で多くのリソースを棚卸できています。タグ付けと棚卸Webによる棚卸のサイクルの高速化は、コスト削減につながります。

ご清聴ありがとうございました。