Well-Architectedフレームワークに基づいた 実践的なAWSコスト最適化 Sansan株式会社 DSOC 研究開発部 大澤 秀一 JAWS Days 2021 re:Connect (2021.03.20)

Data Strategy and Operation Center 自己紹介 大澤 秀一 Sansan株式会社 DSOC 研究開発部（R&D）DevOpsエンジニア オンライン名刺 https://nextpublishing.jp/book/12273.html @ohsawa0515 @ohsawa0515 https://blog.jicoman.info/ Shuichi Ohsawa PHPer（前職） → インフラエンジニア (2015/02～) • 名刺データ化システムのインフラ運用 • デプロイ基盤の改善 • AWS/GCPコストの最適化 → R&D DevOpsエンジニア (2020/12～) • 研究員が開発したモデルをプロダクション レベルに持っていくお仕事 • R&D提供サービスの開発・運用

Data Strategy and Operation Center https://infra-eng-books.connpass.com/event/201291/

Data Strategy and Operation Center 今日のゴール Well-Architectedフレームワーク「コスト最適化」の概要について理解し、 事例を通してAWSコストの可視化・分析・最適化・評価方法を知ることで、 AWSコスト最適化をするためのきっかけを掴んでもらう

Data Strategy and Operation Center アジェンダ • Well-Architectedフレームワーク「コスト最適化」 • AWSコストについての取り組み・課題 • コスト最適化プロジェクトの発足 • コストの分類・可視化 • 高コスト要因の調査・特定 • コスト最適化の実施例の紹介 • コスト最適化の評価

Well-Architectedフレームワーク とはなにか？

Data Strategy and Operation Center Well-Architectedフレームワークとは • AWSでシステム構築する際におけるシステム設計・運用の「大局的な考え方」と ベストプラクティスが集結されたフレームワーク • AWSソリューションアーキテクトが長年にわたってさまざまなビジネス分野や ユースケースを設計してきた経験則に基づいて作られた • あくまで「設計の原則」で具体的な設計や実装について触れられていない • 定期的に更新され続けている

Data Strategy and Operation Center Well-Architectedフレームワークとは • 設計原則とベストプラクティスに沿っているかの質問と回答形式 • 質問に答えていくことでベストプラクティスと照らし合わせる • ホワイトペーパー • AWS Well-Architected Tool • 5つの柱 • 運用上の優秀性 • セキュリティ • 信頼性 • パフォーマンス効率 • コスト最適化

Data Strategy and Operation Center コスト最適化の5つの原則 • クラウド財務管理の実装 • 組織としてクラウド財務管理・コスト最適化に投資する必要がある • 消費モデルを導入 • 必要なコンピューティングリソースの費用のみを支払う • 開発環境の場合、開発する時間（8時間/日）のみ利用することでコストを削減する • 全体的な効率を測定する • ワークロードのビジネス成果とその実現にかかったコストを測定する • この測定値をもとに生産性向上やコスト削減に見合っているかを考える • 差別化につながらない高負荷の作業に費用をかけるのをやめる • マネージドサービスを利用することで、手間作業を減らしビジネス成果を出すことに集中できる • 費用を分析および属性化する • システムの使用状況とコストを正確に特定し、投資収益率（ROI）を把握する

Data Strategy and Operation Center 5つのベストプラクティスの分野 • コスト最適化に関する10の質問は5つのベストプラクティスに分類される • クラウド財務管理の実践 • 経費支出と使用量の認識 • 費用対効果の高いリソース • 需要を管理し、リソースを供給する • 経時的な最適化

Data Strategy and Operation Center クラウド財務管理の実践 - ベストプラクティス - • コスト最適化担当を設定する • 個人ではなくチームを編成し、組織全体にコスト意識を浸透させるように活動する • 担当者を中心にコストの使用状況を定期的にチェックする運用体制を築く • 継続的なコスト最適化するための運用体制を築く COST 1: クラウド財務管理はどのように実装しますか?

Data Strategy and Operation Center Cloud cost optimization is a journey. • コスト最適化は一度やれば終わりではない • コスト最適化プロセスを継続的にまわしていく必要がある 1. AWSサービスおよび料金への理解 2. 業務システムやビジネスを取り巻く環境に関する理解 • コストの知識と最適化施策をシステムに落とし込んでいく • システム特性やビジネス状況にマッチした最適化をする 3. 継続的に監視・最適化するための運用 • 意図しない料金の増加が発生していないか • リザーブドインスタンスの利用率が下がっていないか • 1～3すべて必要

Data Strategy and Operation Center 経費支出と使用量の認識 - ベストプラクティス - • AWS OrganizationsでAWSアカウントを構造的に管理する • 部署やチームなどの単位でアカウントを分けることでコストが管理しやすくなる • AWSリソースにタグ付けする • コスト配分タグやCost Categoriesによるコスト分類、グルーピングが可能になる • モニタニングツールを活用する • AWS Cost Explorer、AWS Cost and Usage Report（CUR）による可視化 • AWS Budgetsによる予算管理や予算を超えた場合の通知設定を行う • コスト配分タグによるフィルタリングが活用できる COST 2: 使用状況をどのように管理しますか? COST 3: 使用状況とコストをどのようにモニタリングしますか? COST 4: 不要なリソースをどのように削除しますか？

Data Strategy and Operation Center AWS Cost and Usage Report（CUR） • AWSのコストやリソースの使用状況の詳細をS3やRedshiftにアップロードしてくれる機能 • リソースID （EC2インスタンスIDやS3バケット名 etc）をレポートに含めることができる • Amazon AthenaでS3にあるCURに対してクエリ実行することで細かなコスト算出が可能

Data Strategy and Operation Center コスト配分タグ • AWSリソースにタグを付与して請求データを整理する機能 • EC2インスタンス、S3バケット・オブジェクト、RDS DBインスタンスなどにタグをつけると 請求データにタグ情報 （カラム）が追加される • CURのカラムに追加されるので、Athenaのクエリでフィルタやグルーピングができる

Data Strategy and Operation Center AWS Budgets • AWSの使用量や予算額を管理するサービス • APIオペレーション単位、使用タイプ単位の予算・使用量の管理、通知 • RIとSPの使用率、カバレッジのモニタニングおよび通知 • 日次レポート通知 • Slack連携（AWS Chatbotとの連携） • 複数AWSアカウントをまとめての予算管理（組織のマスターAWSアカウントのみ） • 予算を超えた際の制御アクション（AWS Budgets Actions） • EC2インスタンスの停止など

Data Strategy and Operation Center 費用対効果の高いリソース - ベストプラクティス(1/3) - • AWSマネージドサービスを活用する • マネージドサービスによって、運用にかかる時間的・金銭的コストを削減できる • 総保有コスト（TCO）を意識する • ある設備などの資産に関する、購入から廃棄までに必要な時間と支出の総計 (by Wikipedia） • 設備の購入などの初期コストに加え、保守運用や人件費などのランニングコストも含める • AWSの利用料金を絶対視するのではなく、保守運用などにかかる人件費などの ランニングコストも意識する COST 5: サービスを選択するとき、どのようにコストを評価しますか? COST 6: コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を 選択するには、どうすればよいですか? COST 7: コストを削減するには、料金モデルをどのように使用したらよいでしょうか? COST 8: データ転送料金についてどのように計画していますか？

Data Strategy and Operation Center 費用対効果の高いリソース - ベストプラクティス(2/3) - • リージョンを選択する • 東京/大阪よりUSの方が時間あたりの単価が安いことが多い • データを国外に持ち出せない要件の場合、コンピューティングリソース（EC2など）を 国外リージョンで利用できないか検討する • 料金タイプを変える • EC2であれば、リザーブドインスタンス（RI）、Savings Plans（SP）、スポットインスタンス • SPであれば、AWS Lambda、Fargateにも適用できる • DynamoDBリザーブドキャパシティ、CloudFront Security Savings Bundleの活用 • ワークロードに応じてS3、Amazon EFSのストレージクラスを変えるとコスト削減になる • データ転送料金を最適化する • 要件とコストに応じてNAT Gateway、VPCエンドポイント、Private Link、VPC Peering、VPN、 Direct Connect、Transit Gatewayなどのネットワークサービスを選定する

Data Strategy and Operation Center 費用対効果の高いリソース - ベストプラクティス(3/3) - • メトリクスを基にリソースタイプとサイズを調整する • 監視ツール、監視SaaSを活用してメトリクスを収集し、定期的にインスタンスタイプを見直す • 最新世代のEC2インスタンスタイプを選択する • C3、C4 ⇒ C5 • 未使用・低使用率のリソースを特定する • AWS Compute OptimizerでEC2、AWS Lambdaのコスト効率を確認する • AWS Trusted Advisorで未使用・低利用のリソースがないかを確認する

Data Strategy and Operation Center 需要を管理し、リソースを供給する - ベストプラクティス - • Auto Scalingを活用する • EC2であればベースとなるインスタンスはRI、可変するインスタンスはスポットインスタンスに 使い分ける • EC2以外のAuto Scalingも活用する • DynamoDB、Amazon Aurora（レプリカ） • トラフィックの急増（スパイク）に対応する • スケジューリング機能や別の予測機能を利用した事前スケーリングを検討する COST 9: どのように需要を管理し、リソースを供給しますか?

Data Strategy and Operation Center 経時的な最適化 - ベストプラクティス - • AWSのアップデートを確認する • 新機能や新しい料金体系が頻繁に発表されるので自らのワークロードに活用できないか検討する • Savings Plansは2019年11月に登場 • AWS SAに相談する • 自力でアップデートを追い続けることはかなり大変なのでプロに聞く • 所属会社を担当しているSA、Ask an Expertなど相談できる機会は多い • 自分たちが抱えている具体的な悩みを相談できる COST 10: 新しいサービスをどのように評価していますか？

AWSコストについての取り組みと課題

Data Strategy and Operation Center AWSコストについての取り組み • AWSコストに関する業務に携わったのが5年半前 • 当初はシステム規模があまり大きくなく構成もシンプル • 毎月の費用計算と翌月の簡易的な予測程度 • 会社成長にともないシステム規模の拡大、人員増加 • 多岐に渡るに要望により、システム構成が複雑化 • AWSコストへの課題が顕著化

Data Strategy and Operation Center AWSコスト対する課題 • システム規模や人数増加にともないシステムが複雑化することによってコストが増大 • EC2インスタンスタイプの見直し、RIの購入やコストウォッチはしていたがそれだけでは不十分 • 一つのAWSアカウントに複数システムが存在し、システム単位のコスト計測ができていない • なぜコストが増えているのかわからない、どうすればコスト削減できるかわからない • コストの予測が困難 • 各月、年間の予算が決めれていて、予測から大きく外れると色々面倒 • 誰がどのぐらいのEC2インスタンスが必要になるのか予測が困難 • リリースによって思わぬコスト増になることもある • 外部ネットワークとの通信増によるネットワーク料金増大 etc

Data Strategy and Operation Center コスト最適化プロジェクトの発足 • プロジェクトリーダー（私） • コスト全体の把握、分類、可視化 • 施策の検討 • プロジェクトメンバー 9名 • 各開発チームから選出 • チーム内のコストを把握し責任を持ってもらう • チーム内でコスト増につながる要因をヒアリングしてもらう • 施策の実施 • 部署の評価対象にも含んでもらい、コスト最適化に取り組むことが評価につながった

Data Strategy and Operation Center コスト最適化プロジェクトの発足 • プロジェクトリーダー（私） • コスト全体の把握、分類、可視化 • 施策の検討 • プロジェクトメンバー 9名 • 各開発チームから選出 • チーム内のコストを把握し責任を持ってもらう • チーム内でコスト増につながる要因をヒアリングしてもらう • 施策の実施 • 部署の評価対象にも含んでもらい、コスト最適化に取り組むことが評価につながった 「クラウド財務管理の実践」のベストプラクティス • コスト最適化担当を設定する

Data Strategy and Operation Center AWSコストの可視化・分析 • AWS Cost and Usage Report（CUR）を利用 • クエリにロジックを組み込むことで細かなコスト算出が可能 • リソースレベルのコストを追跡できる • Redashとの連携が可能 • コスト配分タグによってチーム単位のコストを分類 • チームが管理している各AWSリソースに対してタグを付与 • 手動だと厳しいので自動付与するスクリプトを定期実行 • Nameタグ or リソース名からチーム名を予測してタグを自動付与 • 複数チームが共有して使用しているリソースもあるため、都度所有者を明確にする • Redash（OSSのBIツール）で可視化 • 元々部署内で利用していたので慣れている • AWS、GCPのコストをまとめて可視化

Data Strategy and Operation Center AWSコストの可視化・分析 • AWS Cost and Usage Report（CUR）を利用 • クエリにロジックを組み込むことで細かなコスト算出が可能 • リソースレベルのコストを追跡できる • Redashとの連携が可能 • コスト配分タグによってチーム単位のコストを分類 • チームが管理している各AWSリソースに対してタグを付与 • 手動だと厳しいので自動付与するスクリプトを定期実行 • Nameタグ or リソース名からチーム名を予測してタグを自動付与 • 複数チームが共有して使用しているリソースもあるため、都度所有者を明確にする • Redash（OSSのBIツール）で可視化 • 元々部署内で利用していたので慣れている • AWS、GCPのコストをまとめて可視化 「経費支出と使用量の認識 」のベストプラクティス • AWSリソースにタグ付けする • モニタニングツールを活用する

Data Strategy and Operation Center 高コスト要因のAWSサービス・リソースを特定する • CURでサービス、オペレーション、使用タイプ、リソースID別のコストを算出 • RedashのPivot Tableでフィルタしたり、CSV出力で分析

Data Strategy and Operation Center AWSコスト最適化サービスを活用する • AWS Compute Optimizer、 AWS Trusted Advisorで最適化 できる箇所を探す • ワークロードによっては最適化できない ことがあるので、あくまで候補

Data Strategy and Operation Center AWSコスト最適化サービスを活用する • AWS Compute Optimizer、 AWS Trusted Advisorで最適化 できる箇所を探す • ワークロードによっては最適化できない ことがあるので、100%信頼するのではなく あくまで候補 「費用対効果の高いリソース」のベストプラクティス • 未使用・低使用率のリソースを特定する

コスト最適化の実施例の紹介

Data Strategy and Operation Center 最適化の実施（1）- AWS NAT Gateway (データ転送料金) - • コスト分析した結果、NAT Gatewayの料金（データ通過量）が多いことに気がついた • VPCフローログからDynamoDBへの通信が多いことが判明 • DynamoDB VPCエンドポイントが設定されておらず、NAT Gateway経由で通信されていた • VPCエンドポイントを設定してNAT Gatewayのコストを削減した

Data Strategy and Operation Center 最適化の実施（1）- AWS NAT Gateway (データ転送料金) - • コスト分析した結果、NAT Gatewayの料金（データ通過量）が多いことに気がついた • VPCフローログからDynamoDBへの通信が多いことが判明 • DynamoDB VPCエンドポイントが設定されておらず、NAT Gateway経由で通信されていた • VPCエンドポイントを設定してNAT Gatewayのコストを削減した 「費用対効果の高いリソース」のベストプラクティス • データ転送料金を最適化する

Data Strategy and Operation Center 最適化の実施（2）- Amazon DynamoDB - • データ分析基盤でDynamoDBを利用 • 急激な負荷増加のためオンデマンドモード • Read/Writeリクエストに比例してコスト増 • リザーブドキャパシティが使えない • プロビジョニングモードに変更することで コスト変動が安定化 • DynamoDB Autoscaling + Kinesis Streams でキャパシティの安定化 • リザーブドキャパシティの購入でコスト最適化 • AWS SAに相談して、実際の利用量を基に購入キャパシティ数を決定

Data Strategy and Operation Center 最適化の実施（2）- Amazon DynamoDB - • データ分析基盤でDynamoDBを利用 • 急激な負荷増加のためオンデマンドモード • Read/Writeリクエストに比例してコスト増 • リザーブドキャパシティが使えない • プロビジョニングモードに変更することで コスト変動が安定化 • DynamoDB Autoscaling + Kinesis Streams でキャパシティの安定化 • リザーブドキャパシティの購入でコスト最適化 • AWS SAに相談して、実際の利用量を基に購入キャパシティ数を決定 「費用対効果の高いリソース」のベストプラクティス • 料金タイプを変える 「需要を管理し、リソースを供給する」 • Auto Scalingを活用する 「経時的な最適化」 • AWS SAに相談する

Data Strategy and Operation Center 最適化の実施（3）- AWS Glue - • AWS GlueはマネージドのETLサービス • クローラ(データ検出)と ETL(データ加工処理) を行う • Glueのコストがすごく高いわけではないが、減らせる余地があり設定を見直してもらった • 実行頻度の減少（毎時→日次） • 不要なGlueジョブの削除、統合 • DPU（スペック）の削減

Data Strategy and Operation Center 最適化の実施（3）- AWS Glue - • AWS GlueはマネージドのETLサービス • クローラ(データ検出)と ETL(データ加工処理) を行う • Glueのコストがすごく高いわけではないが、減らせる余地があり設定を見直してもらった • 実行頻度の減少（毎時→日次） • 不要なGlueジョブの削除、統合 • DPU（スペック）の削減 「費用対効果の高いリソース」のベストプラクティス • メトリクスを基にリソースタイプとサイズを調整する

コスト最適化の評価

Data Strategy and Operation Center 技術サイドによるコスト評価 • 事業が成長し、全体的なコストが増加している場合、コスト最適化の成果を 測定するのが難しい • 全体費用額で評価すると、ワークロードの増加によって削減分が消えてしまう • 全体費用額ではなく、削減額で評価するようにする • 特定リソースのコスト追跡による削減額の算出 • 例）Amazon DynamoDB、AWS Glue • 使用量の計測によるコスト削減額の試算 • 例）AWS NAT Gatewayのデータ通過量

Data Strategy and Operation Center ビジネスサイドによるコスト評価 • 例）アクティブユーザー数やセッション数、トランザクション数に対する AWSコストの割合 • 1ユーザあたりのAWSコストを指標とする • 名刺1枚をデータ化するためのコストをKPIとしている • AWSなどのコンピューティングコストに加えて人件費などの間接費も含まれる • 新機能をリリースすることでAWSコストが増えるが入力作業が効率化されて 全体のコストが下がる

Data Strategy and Operation Center まとめ • Well-Architectedフレームワークと柱の一つである「コスト最適化」における ベストプラクティスを紹介 • これまで取り組んできた事例とベストプラクティスを照らし合わせて紹介

No content