コラム

こんにちは、株式会社ビッグツリーテクノロジー＆コンサルティングの熊谷です。
このブログは、Japan AWS Ambassadors Advent Calendar 2023の12/24分のブログになります。フェンリル柴田さんからバトンを受け継ぎました。

昨日の柴田さんの記事では、EQや心理的安全性の確保、適度なストレスがAmazonのイノベーション文化にどのように貢献したかについてのセッションが紹介されています。
「テクノロジーだけじゃないre:Invent 2023 – Amazonのイノベーション文化」

さて、育休取得中で仕事から数か月離れてしまっていますが、久しぶりにブログを書いてみようと思います。
宜しくお願いします。

産休取得前は官公庁のお客様とBTC社員合同のCoEチームに所属していました。
移行対象システムは100近くあるため、私たちが全てのシステムの移行を直接ご支援することは出来ませんが、システム担当職員や移行・運用を担当する事業者のご相談対応をしていました。
主な仕事は見積もりのレビュー、アーキテクチャレビュー、要件定義書・設計書作成支援、PoC支援等です。

ご支援する中でよくコストの見直しに関するご相談を受けますので、今回はシステムのコスト見直しに利用できるAWSサービスと、見直しをするべきタイミングについてブログを書きたいと思います。

「クラウドに移行したのにシステム運用コストが安くならない」

現在、多くの公共システムがデジタル庁の主導のもとでクラウドに移行し、運用を開始しています。
システム更改やOS・ソフトウェアのサポート切れに基づくクラウドへの移行は、時に移行すること自体が目的化され、より良いシステムを作るための適切なサービス選定や運用改善が後回しにされ、結果として運用コストが高騰することがあります。

クラウド移行後の運用コストを抑えるためには、クラウドの利便性を十分に活用できるシステム構成になっているか移行前に検討すること、そして移行後も継続的に運用の見直しを行うことが大切です。

サーバスペックの見直しとAWS Compute Optimizerの利用

「移行後のシステムの運用コストが安くならないか検討したいけど、どこから手を付けて良いかわからない」場合、システムで利用しているサーバのスペックが適切かどうかを確認してみましょう。

AWS Compute Optimizerは、直近14日間のサーバの使用状況を機械学習で分析し、適切なサーバのスペック（インスタンスタイプ）を提示してくれる無料のサービスです。
CPUやメモリを必要以上に備えたサーバを使用していないかどうか分析してくれるサービスですので、サイズダウンの検討を行いたいときに利用するのが良いでしょう。

AWS Compute Optimizerは、各サーバのスペックの分析結果を「最適化済み」、「プロビジョニング不足」、「過剰なプロビジョニング」の3つに分類します。
「過剰なプロビジョニング」に分類されたサーバは、スペックのサイズダウンが出来ることを示唆します。

AWS Compute Optimizerは、デフォルトでは、CPU・ストレージ・サーバのネットワーク帯域幅の使用率（メトリクス）に基づいて分析されます。

メモリも分析対象にする場合は、事前にAmazon CloudWatchを使ってサーバのメモリ使用率の情報をAWS上に収集する必要があるので注意しましょう。
メモリはシステムの処理速度に影響しますし、万が一メモリ使用率が100%になってしまったらシステムが停止してしまいますので、分析対象にすることを推奨します。

分析結果に関する詳細として、結果の原因が表示されます。
この項目により、CPUやメモリなど、サーバのどのリソースがオーバースペックなのかがわかるので、参考にすると良いでしょう。
※EC2 インスタンスのレコメンデーション

サーバ（EC2）を分析するためには、過去14日間のうち少なくとも累計30時間のメトリクス(※)が必要です。
※AWS Compute Optimizerは、連続しない使用率データを持つEC2インスタンスをサポートするようになりました

AWS Compute Optimizerを利用すると、適切なサイズのオプションが最大3つまで提示されます。
3つのうちどれが最適かは、ユーザが選択する必要があります。

3つも提示されるとどれを利用すれば良いか迷ってしまいますが、どれを利用するにせよ、推奨されたサイズを検証することなく、鵜呑みにして利用してはいけません。
開発・検証環境のマシンサイズをAWS Compute Optimizerで推奨されたマシンサイズに変更し、本番と同等の負荷をかけてテストし、推奨されたサイズが負荷に耐えられるか確認しましょう。

定期的にリソース使用率をチェックしよう

AWS Compute Optimizerは、14日間のサーバの稼働実績を無料で分析してくれます。
拡張インフラストラクチャメトリクスという有料機能を使うと、最大3か月のサーバの稼働実績に基づいて分析をします。

しかし、分析結果を盲信せず、推奨されたマシンサイズが適切かどうかを検討するためには、日常的に本番環境のワークロード（システムにいつどれだけ負荷がかかるか）を把握しておくことが大切です。

AWS Compute Optimizerは、スペックの見直し、つまりスケールアップ・スケールダウンを推奨するサービスですが、ワークロードによっては一時的にサーバの数を増減する方が適切な場合もあります。

例えば週末だけシステムを利用するユーザが多く、システムの負荷が高くなるというワークロードの場合、システムへの負荷が上昇したタイミングでサーバを追加し、負荷が落ち着いたらサーバを減らすAmazon EC2 Auto Scalingというサービスを利用する方が、コストを安く抑えることが出来るかもしれません。

「AWS の クラウドが選ばれる 10 の理由」から抜粋

ワークロードの把握をするためには、Amazon CloudWatchでシステムのメトリクスを収集するだけでなく、月に一度や四半期に一度、リソース使用率の最大値や平均値をシステム事業者とシステム担当職員双方で確認し、リソースをきちんと活用できているかを確認するのが良いでしょう。

コストの見直しをするために調達仕様書に記載するべきこと

公共システムにおいて、上記の作業を事業者に実施してもらう場合、その旨を「調達仕様書」にしっかり記載することが大切です。

（公共職員の方以外の読者のために、調達プロセスについて少し冗長的に説明していることをお許しください）

公共システムの場合、調達の公平性を確保するために、毎年システム事業者が変更されることが多いと考えられます。
システム担当職員は、次年度の事業者に対して希望するシステムの改修や運用について記載した調達仕様書を作成する必要があるでしょう。

調達仕様書作成のプロセスとシステム調達までの流れは、大まかに以下の通りです。
　調達仕様書作成⇒調達仕様書公開⇒入札公告期間（最大50日以上）経過⇒入札⇒開示⇒システム調達
そのため、入札公告期間によりますが、システム調達をする約2か月前には、調達仕様書のインプットとなる情報を整理すると良いでしょう。

調達仕様書には、以下の観点を記載することが望ましいと考えます。

・コスト削減の観点から運用改善に取り組むこと
・毎月、または四半期に一回システムの稼働状況を分析し、職員に報告すること
・上記の分析には、必要に応じてAWS Compute OptimizerやAmazon CloudWatch等のサービスを利用すること
・分析結果は、翌年度の事業者に引き継ぐこと

それでは次回、複数のワークロードのパターンを使用して2週間にわたり、AWS Compute Optimizerを検証してみようと思います。

Ambassador Advent Calenderのラストは「AWSコンテナ設計・構築［本格］入門」、「CloudWatch 設計・運用 虎の巻」などの著書やLTでおなじみ、ウマカツこと野村総合研究所の馬勝 淳史さんです！