プロジェクトチームで取り組む 実践的なクラウドコスト最適化 Sansan株式会社 ⼤澤秀⼀ July Tech Festa 2020

Data Strategy and Operation Center ⼤澤 秀⼀（@ohsawa0515） https://blog.jicoman.info/about Sansan株式会社 DSOC Cloud Cost Optimization Engineer 過去登壇歴 CloudNative Days Tokyo 2019 「 Spinnakerで実現する、クラウド開発者のためのデ プロイパターン⼊⾨」 July Tech Festa 2017 「インフラエンジニアがConsulとStretcherをつかった デプロイ改善で開発効率の向上に貢献した話」 ⾃⼰紹介

Data Strategy and Operation Center AWSコスト本の商業誌でます（多分今年中） 同⼈誌版はBOOTHで販売中 技術書典9で改訂版を頒布予定 宣伝 "84ͷྉۚମܥ΍࠷దԽϙΠϯτ͔Βɺίετ࡟ݮͷ࣮ྫ·Ͱղઆ Amazon Web Services ίε τ࠷దԽೖ໳ େᖒ लҰ ஶ

Data Strategy and Operation Center l Sansan DSOCの紹介 l 私とコスト、そして課題 l コスト最適化プロジェクトについて l （１）コストの分類・可視化 l （２）⾼コスト要因の調査 l （３）コスト最適化の実施例 l （４）評価 l コスト最適化スキルの重要性について アジェンダ

Data Strategy and Operation Center Sansan株式会社が展開する2つの事業 クラウド名刺管理サービス 名刺アプリ

Data Strategy and Operation Center 組織構成 名刺管理サービス Sansanの開発、提供 名刺アプリサービス Eightの開発、提供 研究開発部(R&D) データ分析・研究開発 （画像処理／機械学習・AI） Sansan事業部 Eight事業部 DSOC Sansan株式会社 データ統括部⾨ サービス開発部 システム開発・ データマネジメント

Data Strategy and Operation Center 名刺が⽰す情報 会社・個⼈の情報 つながり→⼈脈 強み 業種、職種、役職、地域 い つ 、 ど の 部 署 ・ 役 職 の ⼈と出会ったか 横の繋がりの豊富さから、 名刺所有者のナレッジ・経験 がある領域が⽰唆されている 役職名 ⽒名 企業名 メールアドレス/ 電話番号 / URL 1 2 3 Sansan株式会社の事業成⻑を根幹から⽀える 「出会い」のデータベースを構築

Data Strategy and Operation Center 名刺取り込み 背景分離 画像補正 1 項⽬分割 2 セキュリティー項⽬細分割、項⽬⼊⼒ 3 チェック＆補正 5 マージ 4 マイクロタスク×マルチソーシングによる独⾃の名刺データ化システム 名刺データ化システム「GEES」 セキュアな環境を構築

Data Strategy and Operation Center スマートキャプチャー 撮影されてから数秒で結果をユーザーに届けることを可能にする技術 項⽬セグメンテーション ⽂字を読み取らずに、名刺のデザインから項⽬を⾒分ける ⾔語判定 ⽂字を読み取らずに⾔語を判定 ミステイクディテクター 誤りの傾向を学習してミスの可能性を予測 独⾃に研究開発したさまざまな画像認識技術によって、名刺を⾼速かつ⾼精度でデータ化 AI・画像認識技術

私とコスト、そして課題

Data Strategy and Operation Center • 会社成⻑にともないシステム規模の拡⼤、⼈員増加 • 多岐に渡るに要望により、システム構成が複雑化 • GCPの利⽤開始、マルチクラウド化 • 機械学習などによるGPUや⼤きいインスタンスタイプの利⽤ • 計算ロジックの複雑化、業務の属⼈化 • 次第にAWSコストへの課題が顕著化 私とAWSコストとの付き合い • AWSコストに関する業務に携わったのが5年半前 • 当初はシステム規模があまり⼤きくなく構成もシンプル • 毎⽉の費⽤計算と翌⽉の簡易的な予測程度

Data Strategy and Operation Center 1. システム規模の成⻑以上のコスト増⼤ • EC2インスタンスタイプの⾒直しやRIの購⼊・⽇々のコストウォッチはしていたが、 積み重ねでコスト増 2. サービス／システム単位のコスト追跡が困難 • ⼀つのAWSアカウントに複数システムが存在しているため、コスト計測が不明確 • なぜコストが増えたのかがわかりづらい 3. コストの予測が困難 • 誰がどのぐらいのインスタンスが必要になるのか予測が困難 • リリースによって思わぬコスト増になることもある • 外部ネットワークとの通信増によるネットワーク料⾦増⼤ • メモリ使⽤量の増加によるEC2インスタンスのスケールアップ 課題

Data Strategy and Operation Center • 2019年6⽉に発⾜ • プロジェクトリーダー（私） • コスト最適化に時間を多く割けるようになる • 周囲に「コスト、コスト」と⾔い続けることによりコスト意識を植え付ける • コスト全体の把握、分類、可視化 • 施策の検討 • プロジェクトメンバー 9名 • サーバサイドエンジニア・データエンジニア・R&Dで構成されたチームから選出 • チーム内のコストを把握し責任を持ってもらう • チーム内でコスト増につながる要因をヒアリングしてもらう • 施策の実施 コスト最適化プロジェクトの発⾜

Data Strategy and Operation Center • AWS Well-Architected Framework「コスト最適化」のベストプラクティスでコスト最適化担当と チームを形成することの重要性が書かれている プロジェクトを発⾜する意義 COST 1 クラウド財務管理はどのように実装しますか? コスト最適化担当を設定する: 組織全体のコスト認識を確⽴し、維持する責任を持つチームを作成します。 このチームには、組織全体の財務、テクノロジー、およびビジネスの役割を持つ⼈材が必要です。 コスト最適化機能を構築するときは、メンバーを引き⼊れるとともに、CFMおよびCOのエキスパートで チームを補完することも検討してください。既存のチームメンバーは、組織が現在どのように機能してい るか、および改善を迅速に実施する⽅法を理解します。また、分析やプロジェクト管理など、補⾜的また は専⾨的なスキルセットを持つ⼈材を含めることも検討します。

コストの分類・可視化

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

Data Strategy and Operation Center • コスト配分タグで事業サイドのコスト分類はできていたが、チーム単位のコストが把握できていない 状態だった • システムによってはAWSアカウントを分けているものもあれば、⼀つのAWSアカウントに 複数システムが混在しているものもある • チームが所有しているAWSリソースにタグを付与 コストの分類 • ⾃動付与するスクリプトを定期実⾏ • AWS Lambdaで実⾏ • Nameタグ・リソース名からチーム名を推測して タグを⾃動的に付与 • 複数チームが共有して使⽤しているリソースも あるため、都度所有者を明確にする • タグ値が間違っていたら都度修正 スクリプトによって上書きしないようにする

Data Strategy and Operation Center • AWS Organizationsによりマスターアカウントの下にメンバーアカウントが存在する • Cost Explorerでメンバーアカウントをまたいだコストを⾒れるのはマスターアカウントのみ • マスターアカウントは会社全体のアカウントを統括しており、アクセスや操作に制限がかけられていて ログインできる⼈が限定されている • プロジェクトメンバーにコストを⾒てもらいため、 私たちが管理しているメンバーアカウントから コストを⾒れるようにする必要がある コストの可視化 – AWSアカウント構造 –

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

Data Strategy and Operation Center • 採⽤理由 1. ⾃分たちのロジックでクエリを組んでコストを集計できる 2. S3にアクセスできればメンバーアカウントで集計できる 3. リソースレベルのコストを追跡できる 4. BIツールとの相性がいい • CURでマスターアカウントのS3バケットにエクスポート された請求データファイル をメンバーアカウントの Amazon Athenaからクエリ実⾏ • S3にアップロードされたらメンバーアカウントへの 参照権限をファイルに付与するAWS Lambdaを実⾏ コストの可視化 – CURの採⽤ –

Data Strategy and Operation Center • RedashはオープンソースのBIツール • 採⽤理由 1. 元々利⽤していた 2. AWS、GCPのコストをまとめて可視化 3. Athenaのクエリ結果をグラフ表⽰ コストの可視化 – Redashの採⽤ –

⾼コスト要因の調査

Data Strategy and Operation Center • CURでサービス、オペレーション、使⽤タイプ、リソースID別のコストを算出 • RedashのPivot Tableでフィルタ、CSV出⼒ができるので便利 ⾼コスト要因のサービスやリソースを特定する

Data Strategy and Operation Center • AWS Compute Optimizer、AWS Trusted Advisorで最適化できる箇所を探す • ビジネスや開発上の諸事情もあるため、 100%信頼するのではなくあくまで候補と する AWSのコスト最適化サービスを活⽤

Data Strategy and Operation Center • プロジェクトメンバー（チームのコスト担当者）と何を最適化するかを決める • ⾼コストのリソースから⼿をつければいいわけでもない やむを得ずに⾼コストになっている場合もある コスト最適化⽅針 1. TCO（総保有コスト）を意識する 2. 費⽤対効果が⾼いことから着⼿する

Data Strategy and Operation Center コスト最適化⽅針 1. TCO（総保有コスト）を意識する • ある設備などの資産に関する、購⼊から廃棄までに必要な時間と⽀出の総計※のこと • 運⽤保守・メンテナンスなどにかかる⼈件費などのランニングコストも意識する • ⽬先のコストに意識が向いてしまわないようにする 例）EC2インスタンスのコストを最適化する • インスタンスタイプを下げるのがてっとり早いかもしれないが、処理性能が落ちて 実⾏時間がかかって⽣産性を落とす可能性がある • ずっと稼働するならリザーブドインスタンスやSavings Plansを購⼊する • 構成変更してスポットインスタンスで運⽤できるようにする • AWS Fargateに移⾏して運⽤コストを減らす⼿もある ※ https://ja.wikipedia.org/wiki/TCO

Data Strategy and Operation Center コスト最適化⽅針 2. 費⽤対効果が⾼いことから着⼿する • 最適化することによってどのぐらいコストが減らせるのかを事前に⾒積もっておく • 相当の⼯数と時間がかかってようやく最適化できても削減額が少なかったら割に合わない • 最適化によってコスト削減以外のメリットがあるならそれでもアリ • 運⽤にかける時間を減らせる • セキュリティが向上する etc 例）EC2 Auto Scaling • EC2インスタンス数が少なかったりインスタンスタイプが⼩さいと効果が薄い • リザーブドインスタンス・Savings Plansを購⼊した⽅がてっとり早い

コスト最適化の実施例

Data Strategy and Operation Center • NAT Gatewayの料⾦が⾼い（=データ通過量が多い）ことに気がついた • VPCフローログからDynamoDBへの通信が多いことが判明 • DynamoDBへのVPCエンドポイントが設定されておらず、NAT Gateway経由になっていた • VPCエンドポイントを設定してNAT Gatewayのコストが削減できた （１）DynamoDB VPCエンドポイント化

Data Strategy and Operation Center • データ分析基盤でDynamoDBを利⽤ • キャパシティ確保の⾯からオンデマンド モードにしていた • Read/Writeリクエストが増えるほどコスト が増えていく • リザーブドキャパシティが使えない （２）DynamoDBキャパシティモードの変更 • プロビジョニングモードにしてもらうこと でコストが安定化 • DynamoDB AutoScaling + Kinesis Streams でキャパシティが安定化 • リザーブドキャパシティの購⼊でさらに 最適化

Data Strategy and Operation Center • Auroraはクラウド向けに構築された、MySQLおよび PostgreSQLと互換性のあるRDBサービス • データベースのデータ量が増加するとAuroraクラスタのストレージ容量が⾃動的に拡張してくれる • しかし、⼀度拡張するとデータを削除してもストレージ容量は縮⼩されない • Auroraクラスタを複数クラスタに分割した際に不要データを削除したがストレージ容量が減らないの で余分なコストがかかっていた • Auroraクラスタを移⾏するプロジェクトがあったため、新規Auroraクラスタにデータ移⾏して ストレージ容量をへらした • ダウンタイムを極⼒減らすためにバイナリログを有効化、レプリケーション （３）Amazon Auroraのストレージ容量の削減

Data Strategy and Operation Center • AWS GlueはマネージドのETLサービスで、クローラ(データ検出)と ETL(データ加⼯処理) を⾏う • Glueにかかっているコストはすごく⾼いわけではないが、減らせる余地があるため設定を⾒直してもらった • 実⾏頻度の減少（毎時→⽇次） • 不要なGlueジョブの削除、統合 • DPU（スペック）の削減 （４）AWS Glueジョブの⾒直し

コスト最適化の評価

Data Strategy and Operation Center • ワークロードが増え続け、全体的なコストが増加し続けている場合、コスト最適化の成果を どうやって測定するかが難しい • 全体費⽤額で評価すると、ワークロードの増加によって削減分が消えてしまう コスト最適化の評価 全体費⽤額ではなく、削減額で評価するようにする 1. 特定リソースのコスト追跡による削減額の算出 • 例）DynamoDBテーブル、Glueジョブ 2. 使⽤量の計測によるコスト削減額の試算 • 例） NAT Gatewayのデータ通過量と測定期間中のデータ処理量との割合から削減額を算出 • ビジネスサイドによるコスト評価する⽅法もある • 例）アクティブユーザー数やセッション数、トランザクション数に対するAWSコストの割合 • 名刺1枚をデータ化するためのコストをKPIとしている • AWSなどのコンピューティングコストに加えて⼈件費などの間接費も含まれる • 新機能をリリースすることで AWSコストが増える代わりに名刺データの⼊⼒作業が 効率化され、データ化コストが下がることもある

コスト最適化スキルの重要性

Data Strategy and Operation Center • コスト最適化するための必要なこと 1. クラウドが提供しているサービスに関する知識と運⽤についての理解 2. ⾃分たちが開発・運⽤しているシステムアーキテクチャについての理解 • これって⽴派なスキルセットですよね？ パブリッククラウドを使うならコスト最適化スキルは必須 • コスト⾒積もり・実費⽤を計測するスキルも含まれる • SRE／インフラエンジニアだけの話ではない • 使いたいサービスがあるけど、費⽤対効果が説明できない • GPUで機械学習回したいけど、どのぐらいかかるの？予算内？ • 素晴らしいサービスを開発してもお⾦が⻤かかるならサービス継続ができない • 個⼈／会社 関係ない • 個⼈開発しているサービスなら特にシビア（⾃分の懐が痛むから） • 会社なら売上に直結（⾃分のお給料に影響する）

Data Strategy and Operation Center • コスト最適化プロジェクトチームを発⾜して最適化を⾏った • やってきたこと 1. コストの分類・可視化 2. 最適化の実施⽅針 3. 実施 4. 評価 5. AWS Well-Architected Framework「コスト最適化」は⼀読を！ • コスト最適化スキルはクラウドを使うエンジニアにとって必須ではないだろうか この後、SpatialChat（トラックH-3）にいるので交流したい⼈はぜひ！ まとめ https://spatial.chat/s/JTF-Track-H-3

No content