NTT東日本が明かす、未経験者も使うクラウド技術者育成用AWSハンズオン環境のコスト管理ポイント：特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理（3）

社内でのクラウド活用が加速する他、DX案件の中でクラウドサービスを利用するケースが増えるNTT東日本。クラウド技術者の育成が急務となり、育成の場として選ばれたのはAWS上に構築されたハンズオン環境だった。しかし、従量課金モデルの場合、管理を少しでも怠れば、高額な料金が請求されるリスクがある――運用管理者に光を当てるオンラインイベント「Cloud Operator Days Tokyo 2021」の同社による講演では、AWS活用におけるコスト管理のポイントが明かされた。

[谷崎朋子，＠IT]

クラウド技術者育成向けハンズオン環境の課題はコスト管理

東日本電信電話 Associateの田口裕真氏

　Amazon Web Services（AWS）をはじめとするクラウドの活用において重要なのは、「いかに技術の進化スピードに合わせて継続的に学習できるか」だ。

　東日本電信電話（以下、NTT東日本）では、クラウドの活用がますます加速している。2016年にクラウド技術のノウハウを集約する先端組織を設置。外部に委託していたAWSの運用を内製化して知見の集積を図った。また、社内のデジタルトランスフォーメーション（DX）活動支援組織、いわゆる「Cloud Center of Excellence（CCOE）」も設置。2020年には社内のDX活用相談件数が前年比6倍になり、その大半のシステムやツールでクラウドが活用されている。

　そうした中で課題となったのは、クラウドの開発者や運用者の育成だ。特にAWSに絞った場合、技術者のスキルアップ方法は大きく3つ挙げられる。

　1つ目は、AWS認定トレーニングやウェビナーなどを活用する方法。2つ目は、AWS主催イベント「AWS Summit」「AWS re:Invent」「AWS Innovate」などに参加し、最新のリリースや機能の情報を取集した上で、社内の勉強会やイベントなどでアウトプットして知識を定着させる方法。3つ目は、手を動かして確認する方法だ。

　特に一番効果的なのは、3つ目のハンズオン学習方法だ。新しくリリースされたサービスをいち早く扱い、「どのようなメッセージが表示されるのか」「画面がどのように変わったのか」といったところを含めて検証し、自らの経験値に変えることができる。

　もっとも、検証環境を準備するにも、当然コストがかかる。

　「Cloud Operator Days Tokyo 2021」の講演「不要リソース削減漏れ通知システムによるコスト削減」で、NTT東日本 Associateの田口裕真氏は管理者がクラウド関連で抱える悩みの“あるある”を3つ挙げた。

• 年間の予算枠にコストが収まるのかどうか
• 突然の高額な請求が発生しないかどうか
• 不要なコストが発生していないかどうか

クラウド関連の予算管理者のよくある悩み（田口氏の講演資料から引用）

　まず不安要素の一つとして、「検証環境という性質上、従量課金での利用となり、かつ検証目的で利用状況が変動することから、コストの予測がしづらい」という課題がある。

　「うっかり無料の利用枠を超えて利用してしまった」「不正アクセスやプログラムで想定外のリクエストが集中して請求額が予期せず加算されてしまった」といった理由から、非常に高額な請求が発生する可能性もあるだろう。

　「土日夜間などに不要なリソースが稼働しっぱなしだった」「削除漏れのリソースがあった」などが原因で、いらぬコストを支払ってしまうリスクも懸念される。

　最初の2つの不安要素については、AWSが用意している「My請求ダッシュボード」内の「AWS Budgets」機能とコスト異常検出機能で、「ある程度は管理できる」と田口氏。予算の範囲に応じて請求アラートを設定すれば、いちいち見にいかずともアラート通知で即時対応できる。また、コスト変動の幅を閾（しきい）値として設定し、超えた場合は通知するなども可能だ。つまり、管理者で対策ができる。

　問題は、3つ目だ。この対策には、利用者の協力が必要だ。

　そこで同社は、不要なコストを発生させない仕組みやユーザー向けルールを開発することにした。

強制的に取り締まらず、利便性を損なわず、無駄遣いをさせない仕組みやルール

　ルールや仕組み作りにおいて、田口氏たちは「利用者自身がルールを守って自主的に棚卸しする方法」を選択した。

　「『AWS Identity and Access Management』（IAM）の権限を制御する」「サービスコントロールポリシーでサービスを使えなくする」など、権限に基づき強制的に機能をオフにする方法もあった。確かに強制的に取り締まる方が、確実な効果が期待できるが、利便性は損なわれるだろう。また、今回の管理対象は検証環境であり、機能面などで制限をかけると検証作業自体に影響が出かねない。

　検討の末、田口氏たちは3つの対策を講じた。

• AWSの検証アカウント利用ルールを策定する
• 不要リソース削除漏れ通知システムで管理する
• リソースの棚卸しに有用なサービスを利用する

AWSアカウント利用のガイドラインで自主的な対策を促す

　AWSの検証アカウント利用ルールについては、運用負担を軽減するために予算管理者とアカウント管理者で役割を分担。リソース管理は、作成者自身が不要となったリソースを停止、削除することを大前提に規定した。また、検証で常時稼働が必要なリソースについては、あらかじめ定義するよう指定した。利用リージョンについても、リソースの棚卸しの調査範囲を限定する目的で、基本は「東京」リージョンを利用するように規定。「東京」で使えないものに関しては、「バージニア」リージョンを利用するものとした。

AWS検証アカウント利用ルール：全体およびリソース（田口氏の講演資料から引用）

　ルールの中には、タグの活用が含まれる。棚卸し時に役立つ情報をタグとして設定しており、作成者を識別する「owner」タグ、土日夜間の稼働対象を識別する「always」タグ、目的案件の書類を識別する「service」タグなどと分類した。なお田口氏によると、検証環境なので、ネームの細かい命名規則は定義しない方向にしたという。

　特定のサービスの利用については、事前に管理者に相談する方針にした。「IAMユーザーを利用したい場合、適正な利用者が使うのか」「部外者が利用者に指定されているかどうか」などをチェック。マーケットプレースの場合、新規ドメインでは申し込みの時点で料金がかかってキャンセルできないので、利用目的を確認し、妥当性や必要性を確認している。「特に、利用途中で停止しても料金が発生するようなものは、事前に連絡してほしいと促している」（田口氏）

AWS検証アカウント利用ルール：タグおよびサービス（田口氏の講演資料から引用）

EventBridge＋LambdaでEC2停止忘れ通知システムを構築

　こうしたルールを設けても、人的ミスは起こる。「AWS学習用の検証環境ということは、利用者はAWS初心者の可能性が高い。ルールを読んでも十分に理解できないこともあるだろう。他にも、大量のリソースを作って見落としてしまったり、常に立ち上がっているリソースと勘違いして停止し忘れたり、オートスケーリングが有効になっていたため停止したつもりでも新しいリソースが立ち上がってしまったりといったケースもある」（田口氏）

　停止忘れ防止対策でよくあるのは、対象の「Amazon EC2」インスタンスに対して「AWS Lambda」でタグを付与し、使用しない時間は自動的に停止、使用する時間では起動させる仕組みだ。

　問題は、この仕組みは日中だけ稼働させるシステムには向いているが、リソースの作成、破棄が頻繁に発生する検証環境にはあまり向いていない点だ。また、タグを付与し忘れると、自動停止が機能しないという問題点もある。「意図せず強制停止されたり、タグの付け替えや設定変更などのチューニングが手間だったりする点も悩みどころでした」と田口氏は指摘する。

　そこで田口氏たちは、「タグがないEC2の停止忘れにも気付けること」「強制停止ではなくアラート通知にとどめること」「検証中で常時起動しておくべきものは通知対象から除外できること」を要件とした上で、通知システムの構築を進めた。

　システムの概要は、下図の通り。「Amazon EventBridge」で定期的にLambdaを起動し、インスタンスIDとタグをチェック。通知対象を「Slack」に送る。「今回はインスタンスIDのみとしたが、ネームタグも一緒に付与できれば、利便性はさらに上がる」（田口氏）

EC2停止忘れ通知システムの概要（田口氏の講演資料から引用）

Trusted Advisor、Compute Optimizerでリソースの棚卸し

　最後に、リソースの棚卸しで有用なサービスとして、田口氏は「AWS Trusted Advisor」「AWS Compute Optimizer」を取り上げた。

　Trusted Advisorは、十分活用されていないリソースを洗い出すサービスだ。アイドル状態のDBインスタンス、関連付けがない「AWS Elastic Load Balancing」（ELB）、使用率の低いEC2インスタンス、古いスナップショットなど、マネジメントコンソールで調べるには手間のかかるものが一覧表示される。「コストだけでなくセキュリティに関してもアドバイスしてくれるのでお勧め」と田口氏は言う。

　Compute Optimizerは、EC2のインスタンスやLambdaのインスタンスサイズが適正かどうかを確認し、推奨インスタンスサイズを提案してくれる無料サービスだ。「スペックが高過ぎても低過ぎても無駄なコストは発生する。推奨インスタンスサイズを参考に、適切なサイズに変更できるのがメリット。ダッシュボードで一覧できるのも分かりやすくてよい」（田口氏）

未経験者が利用することを想定したルールや仕組み作りを

　最後に田口氏は次のようにまとめ、講演を締めくくった。「検証環境は未経験者が利用することを想定して、可能な限り利用者の自主性に任せながら利便性を保てるルールや仕組み作りが大切だ。今回の講演が少しでもAWS環境のコスト最適化に役立てば幸いだ」

特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理

ITがビジネスを加速させる昨今、多くの新規サービスが開発、リリースされ、運用管理者には安定したサービスの供給や、利用動向のログの解析などが求められている。だが、これに伴い解析すべきログや拾うべきアラートも増す一方となり、多大な負担が運用管理者の身に振り掛かっている。また、新規サービス開発でのクラウド活用、基幹システムのクラウド移行が進み、可用性や柔軟性といったクラウドならではの特性を生かす、いわゆるクラウドネイティブなアプリケーションの運用が増え、コンテナやマイクロサービスといった複雑な運用管理も求められている。しかも、オンプレミスに残さざるを得ないサーバとのハイブリッドな運用も並行しなければならない。このような中、従来の手法や技術では、とうてい運用管理業務が回らず、ビジネスに貢献することができないのが実情だ。現状を打破するためには、従来の慣習を疑い、新しい技術や自動化、AI（人工知能）などを取り入れ、現状に合った新たな運用管理の手法を実践することが大前提となる――本特集では、運用管理の最新技術や使いこなし方を徹底的に深掘りする。

特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理