【TECH連載】では当社エンジニアによるテック関連のニュースを中心に記事をお届けします！第四回は「社内の開発標準の取り組みについて #2 （AWSコスト最適化の取り組み）」について。

こんにちは、AICROSS開発チームの樋口です。

中途採用で入社して半年と少しですが、現在、社内エンジニアの開発標準の推進や技術レビューなど横断的に技術全般をみていく役割をやっています。

今回は前回につづいて開発標準の取り組みの１つ、AWSのコスト最適化のための取り組みについて紹介してきます。

AWSのコスト最適化とは？

AWSのコスト最適化とは、AWS Well-Architected フレームワークの5つの柱のうちの1つです。

AWS Well-Architected フレームワークの5つの柱
・運用上の優秀性
・セキュリティ
・信頼性
・パフォーマンス効率
・コスト最適化

ビジネスの要求を満たしていても、AWSのコストの採算が合わなければ意味が無いため、AWSのコストを最適化することはシステムを構築する上で重要な要素の1つです。

また、AWSのコスト最適化はAWSが提供するAWSコスト最適化ホワイトペーパーに記載されている5つの設計原則から成り立っています。

１．クラウド財務管理の実装
・AWSコストの最適化のための文化、チーム作り
・コスト管理、最適化のためのPDCAのプロセスづくり
２．消費モデルを導入
・使った分だけコストを払う（使用量をモニタリングする、使ってないリソースは削除する）
・クラウド利用のガバナンスを設ける（知らないリソースが増える状況を作らない）
３．全体的な効率を測定する
・費用対効果の高いアーキテクチャを採用する
・設計段階でコスト評価を行うプロセスづくり
・過剰なリソースを採用しないための試算
・最適な料金モデルの採用
４．差別化につながらない高負荷の作業に費用をかけるのをやめる
・運用の人件費を減らすため、なるべくマネージドサービスを採用する
５．費用を分析および属性化する
・ビジネスの価値に見合ったAWSコストであることを意識する
・AWSコスト削減のためのアーキテクチャ見直しの投資は費用対効果

AWSコスト最適化のための取り組み

今回は、AWSコスト最適化のうち、「クラウド財務状況管理」の範囲である、コスト最適化のための文化やチーム作り、PDCAのプロセスづくりについて、弊社の取り組みを説明していきます。

AWSのコスト最適化の考え方と組織に導入するためには、１人が理解していたとしても、その他大勢のメンバーが理解をしていないと上手くいきません。

そのため弊社では開発標準化の取り組みの１つとして、AWSのコスト最適化のチームを立ち上げて（私とインフラ技術者の２名だけですが）、以下のアプローチで進めています。

１．AWSコストのモノサシをつくる（共通のモノサシ）
２．開発メンバーがAWSのコストを意識する文化を作る。
３．AWSコストのモノサシをつくる（システム単位のモノサシと組織全体のモノサシ）
４．PDCAのライフサイクルでAWSコストを管理及び最適化していくプロセスづくり

（弊社は取り組みを始めて間もない段階のため、まだ十分に浸透しているわけではないのですが、段階的には３～４の間ぐらいの段階です。）

また弊社のアプローチはボトムアップに近いアプローチですが、統制がとれた開発組織であれば、強力なトップダウンでコスト管理の仕組みを導入していく方法もあると思います。コスト最適化の道は、組織の体制、メンバーのリテラシー、経営の理解などの条件により、それぞれ最適なアプローチはありますので、推進するメンバーが組織に合わせて試行錯誤する必要があると考えます。

AWSのコストのモノサシを作る（共通のモノサシ）

通常、AWSへのコストの理解度は、開発メンバーの中の役割や個人のスキルの違いによって、理解度がバラバラになっています。

アプリ技術者
アプリ開発が作業の中心であるため、AWSのインフラ構成はある程度は理解しているが、詳細なAWSコストの構成や最適化の方法について理解が少ないもしくは気にしていない。
インフラ技術者
インフラの構成およびコストの構成について十分理解をしているが、Lambdaアプリケーションの性能向上やメモリ抑制など、アプリケーションで実現するコストの最適化方法についての理解が少ない。
リーダー／マネージャー
各サービスごとのAWSの全体コストについて理解をしているが、詳細な内訳やコストの構成について理解していることが少ない。

そのため、それぞれのAWSのコストに対するモノサシを統一するため、まず各チーム全体で共通となるAWSコストのモノサシ（各リソースのごとのコスト感）を共有していく必要があります。

共有するモノサシは単純な方が良い

AWSのコストの理解度を統一するためのモノサシは、なるべく単純である方が良いです。
AWSのコスト試算については、AWSが提供する料金計算ツールにより試算が可能です。
ただし、だいたいの場合においては、AWSのコスト試算は厳密である必要はなく、おおよその概算で十分なケースがほとんどです。
そのため、AWSのコスト最適化のチームではAWSのコスト試算のための単純なモノサシを用意して、まずは勉強会という形で各チームメンバーに周知していきます。
例えばEC2の場合はこんな感じです。

ざっくりの試算の単位としてはこの３つです。
💡ほぼ使わない
💡そこそこ使う（ギガ使う）
💡いっぱい使う（テラ使う）
ちゃんとインフラのコスト試算をされている方からは怒られそうなぐらいの超ざっくり試算ですが、なるべく単純にすることによって、AWSのコスト試算は難しいというイメージをアプリ開発者や管理者から払拭していきます。
また、このモノサシはAWSのコストの構造と節約方法も勉強会の中で周知していきます。
以下は弊社のAWSコスト勉強会の中で展開している節約例です。

EC2の節約
・インスタンス費用＝稼働時間、利用しない時間帯は停止したほうがコスト削減になる。
・EBSのボリュームはデタッチしても料金は発生する。使わないものはスナップショットをとって消したほうがいい
・稼働時間が減らせないものはSavings Planもしくはリザーブドインスタンスで予約することによってコスト削減。
・格安のスポットインスタンスの利用

Lambdaの節約
・Savings Plansを使うと少し安くなる。最大15％OFF
・起動時間確保のためのプロビジョニング設定は1lambda“ざっくり“500円／月
・Lambdaの費用＝利用メモリ量ｘ実行時間、実行時間を短縮することにより料金を削減
　実行時間が半分＝料金が半分
　＜実行時間短縮のために＞
　・不要なライブライをロードさせない（共通レイヤーは必要最低限）
　・ロジックの改善
　・適切なメモリ量の指定

ELB(ALB)の節約
ELBは費用＝台数で決まる
集約して1台のELBで複数のFQDNを受け付けると経費削減に
（ALB/NLBではFQDNによるターゲットグループの振分けが可能）

DynamoDBの節約
・保存するデータ量が少なければ、RDSよりもほとんどの場合で安くなるので積極的に使っていく。
・バックアップはストレージ料金が約2倍になる。
・書き込み、読み込み回数が予測可能であれば、プロビジョニングでかなりお安くなる。

ElastiCacheの節約
・ElastiCacheは停止できない。つまりインスタンス費用＝稼働台数
   1.検証環境など台数を減らせるものは極力減らす工夫をする。
   2.リザーブドインスタンスは積極的に使う。
・バックアップは別料金が発生するが、そもそも利用目的がキャッシュのためバックアップ不要な設計が望ましい。

AWSのコストを意識する文化を作るために

この共通のモノサシが各チーム間で共有できている状態になったら、普段の会話の中で少しずつコストを意識した会話になるように変化をつけていきます。
最初は、コスト最適化のチームが各チームのインフラの構成変更の打ち合わせに割り込んでいって、インフラ構成変更に対して、コストがどれくらいかかるのかを会話の中で示していきます。

＜before＞
アプリ開発者
「検証のためmediumのEC2インスタンスを1台立てます。」
（コストがいくらかわからないけど、それほど高額にはならないだろう）
管理者「わかった」
（コストがいくらかわからないけど、それほど高額にはならないだろう）

＜after＞
アプリ開発者
「検証のためmediumのEC2インスタンスを1台立てます。」
コスト最適化チーム
「EC2はmediumだとインスタンス費用5000円です、検証のためそこそこギガぐらい使うなら+1万円の月1.5万ぐらいです。ただし業務時間後に落として稼働利が半分ぐらいにするなら、金額も半分ぐらいですね」
管理者「わかった、業務時間外はインスタンス落としておいてね」

理想形では、アプリ開発者と管理者の間でコストを意識した会話が自然に成り立つことが、AWSのコストを意識する文化ができあがるゴールです。

＜after（理想形）＞
アプリ開発者
「検証のためmediumのEC2インスタンスを1台立てます、ストレージは500Gbyteぐらいなので、だいたい月1.5万ぐらいかかりそうです」
管理者「わかった、業務時間外はインスタンス落としておいてね」
（インスタンスを落とせば半分ぐらいの月7500円にはなるから予算の範囲内だな）

組織の文化は長年の積み重ねのため一朝一夕で変わるものではありません。（弊社もまだまだ道半ばです）
時間と労力がかかるのは避けられないのですが、組織にとって必要で正しいと思ったことは、周りの理解や協力を得ながら、理念をもってブレずに時間をかけて進めていく事が大切になります。

システムのモノサシ作りとPDCAのライフサイクル

各チームがAWSのコストを意識する文化がある程度できてくれば、今度はシステムのモノサシ作りです。
AWSコスト管理のPDCAを回していくときに必要なのは

何の判断基準をもってそのシステムのAWSのコストが最適であると判断するのか？
の判断基準（モノサシ）を設けることです。
（これが２つめのモノサシであるシステムのモノサシです）

このモノサシがない状態で、コスト管理のPDCAを回したとしても
１．高コストだがサービスの性能や可用性の確保ために必要なリソース
２．低コストだが不要なリソース
があったときに、１を削減できないか検討して、２は低コストだから放置する。といった誤ったアプローチが発生してしまい、無駄な努力になってしまいます。
このモノサシを基準に以下のAWSのコスト最適化のためのライフサイクルをまわしていくプロセスを作っていきます。

１．モノサシづくり - 各システムのインフラ構成図から、AWSコストの見積りをつくる）
・この見積りがシステムのモノサシになります。
・モノサシの精度はPDCAの中で上げていくので、多少間違っていても良いのでまずは最初のモノサシを作ることがスタート地点です。
・AWSのコスト見積りにはインフラの構成管理ができていることが前提です。（大切）
・システムのAWSコストのモノサシの集合が組織全体のAWSコストのモノサシになります。

２．計画（予測）と実行 - インフラ構成の見直しの際には、AWSコスト見積りの更新をおこない、変更後のコスト予測を立てる
・インフラの変更にかかるコストがビジネスの利益と比較して適正かを判断するプロセスを作ります。
・インフラ変更にかかるコストを最小化のための議論を、実際の変更前にチーム内でおこなうための基準となります。（機能や性能の他に、コストを意識したアプリ・インフラ設計をすること）

３．改善と評価 - AWSコストの見直しは定期的に見直しをおこない、評価と改善を繰り返していく
・評価のために常に正しいモノサシは維持する
・モノサシとConst Exploerとの差分を定期的にチェックする（アクセスの増加にともなう増加など外部要因の変化もモノサシに取り込む）
・AWS Trusted Advisorでの指摘事項から、適正コストとの差分を確認して分析をおこなう。（貴重なアドバイスは素直に聞く）
・定期的に開発メンバーがモノサシを基準に構成見直しによるコスト削減が可能かの議論ができる土壌を作る。（モノサシを持たない空中戦は良くない）

最後に

以上が弊社のAWSコスト最適化チームが推進しているコスト最適化のためのアプローチになります。
まだまだ取り組み段階でこれからという面もありますが、今後また発展があればそのうち紹介していきたいと思っていますのでよろしくお願いします。