はじめに
こんにちは、インフラチームの植松です。
エムオーテックスで開発、運用しているLANSCOPE エンドポイントマネージャー クラウド版はAWS(Amazon Web Services)上で構築しているサービスです。
サービスの機能やユーザー数の拡大に伴い、AWSコストも数十万ドル単位と非常に大きくなっています。
そのようなAWSコストをモニタリングし、
・不必要なAWSコスト(コスト異常)が発生していないか？
・非効率なサービスの使い方をしていて、コストの無駄が発生していないか？
を把握し、「妥当なAWSコストの使用状況だ」という状態を維持することが重要だと考えています。
今回は、インフラチームで取り組んでいるAWSコストのモニタリングや、コスト最適化のために取り組んでいることを共有したいと思います。
コストモニタリング
コスト異常検出
AWSには、機械学習によって異常な支出を発見してくれる「コスト異常検出(Cost Anomaly Detection)」という機能があります。
何のサービスが何日から、どのくらい異常な支出をしているかが一覧でわかるようになっていて、
額が大きいもの(おおよそ$100以上が目安)については個別に原因を確認しています。
コスト異常検出の画面から、Cost Explorerのグラフを見られるので どのサービス、リソースが伸びているかや、直近にリリースあったかどうかなどを確認し、 異常な支出の原因を特定しています。
下のグラフの場合だと、一時的な利用増でS3のデータ転送が増えているから といったあたりをつけています。
一時的な利用増が異常として検出された・・・という場合が多いですが、
機能リリースのタイミングでコストがスパイクする場合もあります。
その場合は開発チームに報告して、原因を確認してもらうような運用をしています。
AWSアカウント別のモニタリング
LANSCOPE エンドポイントマネージャー クラウド版の開発、運用はマルチアカウント構成で行っています。
本番、開発、その他環境のAWSアカウントのCost Explorerのグラフを見て、 特定AWSサービスに異常な支出が無いかを週次で確認しています。
コスト異常検出で検知されている場合もありますが、そうでない場合もままあるので 実際のグラフも確認するようにしています。
以下は、とある開発環境のAWSアカウントのCost Explorerグラフです。
エムオーテックスでは土日や定時後など、開発環境を使わないときは停止して(インスタンスを落とす)
コストを削減するようにしております。
しかし5/10あたりから常時起動しているようなコストの伸びになっているので、
停止の漏れなのか、テストなどの都合による意図的なものかどうかを確認しています。
(今回の場合はテストの都合によるものだったので問題なし)
このような確認をAWSアカウント単位で行っています
AWSサービス別のモニタリング
S3、DynamoDB、Lambdaなどのコストが多くかかっているものについては、 AWSサービス別にコストをCost Explorerでチェックしています。
下のグラフは本番AWSアカウント「以外」の各開発AWSアカウントのLambdaのコストです。
5/25に不審なコスト支出(濃い赤色、オレンジ色)が見られるので、 問題ないかどうかを確認する・・・というような運用をコストが高いAWSサービスに絞って行っています。
S3 Storage Lensを眺める
Amazon S3の使用状況を可視化できるS3 Storage LensというAWSサービスがあり、 定期的にチェックしています。
ストレージ容量順、オブジェクト数順など、様々な側面から S3の使用状況を確認できます。コスト最適化の観点だと旧バージョンのバイト数や、 不完全なマルチパートアップロードのバイト数が多いバケットの絞り込みができます。
旧バージョンのバイト数やリリースの状況を照らし合わせ
コスト最適化の余地がないかを確認しています。
例えば、機能修正でバージョニングあり -> なしになったバケットは
旧バージョンを保持しておく必要はないので、ライフサイクルで旧バージョンを一掃する・・・などを行っています。
Compute Optimizerを眺める
Compute Optimizerは過剰にプロビジョニングされたリソースやプロビジョニング不足のリソースに対して
最適な値をレコメンドしてくれるAWSサービスです。
定期的にダッシュボードを開き、最適化の余地がないかを確認しています。
画像のように、実行回数が多く、メモリの割り当てが過剰なLambda関数については見直しを行っています。
コスト削減対応
リザーブドインスタンス(RI)の購入
RDS、OpenSearchは毎年特定の時期にRIを購入しています。
更新の1ヶ月前を目安に、インスタンスクラスを上げる(下げる)か、そのままで行くかを
開発チームに確認の上、購入するインスタンスの合意を取ります。
こういったRI購入までの合意形成 ~ 稟議の作業は属人化しがちですが、 現在は購入までの流れをWikiで整備しており、チームメンバー誰でもできるようになっています。
DynamoDBリザーブドキャパシティの購入
リザーブドインスタンスと同様に、DynamoDBも
使用料金を前払いすることで大幅にコスト削減を実現できるオプションがあります。
RIと同様、毎年決まった時期にどのくらい購入するかを確認の上、合意をとります。
以下のブログ記事でも紹介していますが、RI同様に確認手順を文書化しています。
Compute Savings Plans(Savings Plans)の購入
RIと同様、毎年決まった時期にSavings Plansを購入しています。
直近のSavings Plansのカバレッジを確認し、60 ~ 70%程度を維持できているかを確認します。
カバレッジが維持できていれば、基本的に前年と同じ額を購入しています。
推奨購入額がレコメンドされていれば、前年購入額に推奨購入額を上乗せするという運用をしています。
今後の展望
検討中のため本番展開はしていない取り組みですが、ご紹介したいと思います。
Cost and Usage Reportの有効化とダッシュボード
Cost and Usage Report(CUR)と呼ばれる、コストの詳細記録csvをS3に記録するAWSサービスがあります。
こちらを有効化し、Athena経由でCURをクエリした結果をダッシュボード(QuickSight)にすることを検討しています。
また、Athenaのクエリ権限をインフラチーム以外の開発メンバーにも付与する予定です。
メンバー全員がコストについて意識し、自由に確認できる基盤作成を計画しています。
コストタグの詳細化
現状、AWSリソース1つ1つに対するリソース名タグを付与しています。
リソース単位のタグは粒度が細かく、製品の機能単位、料金プラン単位での
コスト確認がしづらいという課題があったため、より高い精度でタグ付ができるよう、タグ付案を検討しています。
おわりに
いかがでしたでしょうか？
AWSコスト最適化に向けてインフラチームで取り組んでいることを、コストモニタリングを中心にご紹介しました。
コスト管理を担当されている方のお役に立てば幸いです。
ご興味あれば採用サイトのほうもぜひご確認ください
www.motex.co.jp
ここまでお読みいただきありがとうございました
