Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
©MIXI ⻑期運⽤を⽀えるみてねの継続的な コスト最適化の取り組み 2024/10/18 - AWS 秋の Cost Optimization 祭り 2024 株式会社MIXI Vantageスタジオ みてねプロダクト開発部 プラットフォームグループ SREチーム ⽊村有希
Slide 2
Slide 2 text
2 ©MIXI ⾃⼰紹介 名前 ⽊村 有希 (@kimuson_13) 所属 株式会社MIXI Vantageスタジオ みてねプロダクト開発部 プラットフォームグループ SREチーム ⽊村 有希 (@kimuson_13) 経歴 • 2024/04に株式会社MIXIに新卒⼊社。みてねSREチームへの配属は2024/05中旬から • ⼊社前はMIXIのモンストの解析グループで内定者アルバイトをしていた • データ基盤のCD実装やデータマートのテスト実装などSREっぽいことをしていた • 他にもいろいろな企業でエンジニアとしてインターンを経験
Slide 3
Slide 3 text
©MIXI 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。
Slide 4
Slide 4 text
4 ©MIXI 2015.4 20,000,000 15,000,000 10,000,000 5,000,000 0 2016 2017 2018 2019 2020 2021 2022 国内 海外 ※ iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計 2023.11 2,000万人 突破 家族アルバム みてねの利用者数推移 2015年にリリース。7⾔語‧175の国と地域で2,000万⼈以上の⽅にご利⽤いただいています。
Slide 5
Slide 5 text
5 ©MIXI 世界中の家族のこころのインフラをつくる みてね事業部のMVV | Mission
Slide 6
Slide 6 text
6 ©MIXI 『家族アルバム みてね』(以降、みてね)はたくさんの家族に利⽤していただいている サービスのインフラにAWSを利⽤しており、シェアされた写真‧動画のデータはAmazon S3上に保存されている みてねSREチームのミッションに「事業継続性を阻害する要因を排除する」という項⽬がある これからも⻑い期間、たくさんの家族にみてねを利⽤していただくためにも継続的にコスト最適化をしていく必要がある 事業継続のため みてねにおけるコスト最適化の必要性
Slide 7
Slide 7 text
7 ©MIXI コスト削減施策 これまでやってきたこと これまでに多くのコスト削減施策を⾏い、アウトプットにもしてきた • MIXIにおけるクラウドコスト最適化術 〜 10年選⼿の現SREマネージャー 2名に訊く 〜 • 『家族アルバム みてね』に学ぶ、AWSのReserved InstancesとSavings Plansの勘所 • みてねの動画再⽣にHLSを導⼊した話 • 「無料‧容量無制限でアップロード」を ⽀える みてねのコスト削減術 • DBのコストを半額に!〜Amazon Aurora I/O-Optimizedの活⽤〜
Slide 8
Slide 8 text
8 ©MIXI コスト最適化は以下のような流れになっている 1. まずは計測 2. 最適化する対象を決めて、試算を⾏う 3. 対象の利⽤量や仕組みを最適化する 4. 結果としてコスト削減につながる 計測⾃体にも、コストの計測とリソースの利⽤量に関する計測がある ただ闇雲にコスト削減だけを⼀⽅的に⾏って、その結果ユーザー体験に悪影響がでてはいけない はじめに計測があることで、適切なリソース利⽤量にしたりインスタンスタイプを選ぶなどの具体的な施策が⾏える コスト最適化はコスト削減だけではない コスト最適化とは?
Slide 9
Slide 9 text
9 ©MIXI 毎⽇: Grafanaで各種主要サービスや、各種環境のコストを確認 → 急激に増えているものがないかにすぐに気づけるようにするため ⽉次: AWSのコストエクスプローラーのデータの実数値をスプレッドシートに展開し、コストの実績を確認 → POレビュー会でも⽉次で共有し、全体感をお互い把握するため ⽉毎に上昇トレンドになっていないかや、コスト構造に⼤きな変化がないか確認 コスト計測 みてねSREのコスト計測について
Slide 10
Slide 10 text
10 ©MIXI ある⽇、みてねのとあるAWSアカウントで唐突に料⾦が上がっていることに気づいた AWSのコストエクスプローラで詳細を確認し、対策をすることができたので翌⽉以降は適正な料⾦にすることができた これが⽉次での確認のみだった場合、対応が後⼿に遅れてしまいコストが増加していくことに。。。 急激な増加に気づけた Grafanaでのコスト計測が役⽴った事例 AWSアカウントの請求額(実際の日付ではありません) 05/01 07/01 08/01 06/01
Slide 11
Slide 11 text
11 ©MIXI リソースの利⽤量などもGrafanaで⼤きな変化がないか、サービスとして何か異常が起きていないか確認している これがRI/SPの購⼊時にも役⽴つ →特定のサービスがどれくらい使われているかを調べやすいし、共有もしやすい モニタリング リソースの利⽤量の計測について 1. RI/SPの現在の使⽤率が適切か確認 • AWSの Cost ExplorerでRI/SPの使⽤率やそれぞれのリソースの利⽤量を確認 2. 契約年数の範囲で対象のサービスの利⽤状況が変化する可能性がないか確認 • Grafanaで直近のトレンドを⾒る • 各チームにも今後の開発の⾒通しを確認 3. レビューなどを経て購⼊ RI/SPの購⼊(継続購⼊の場合)
Slide 12
Slide 12 text
12 ©MIXI いざ最適化できそうなリソースがわかっても、それがすごい⼯数がかかったがコスト削減額がイマイチだと⾟い それを防ぐ1つの⼿段として、コスト削減効果と難易度でマトリックスを作るというのがある 正確なものを計画としてだすのではなく、チーム内で認識を合わせることを意識 →先んじて試算をしておくことで、より効率的にコスト最適化を⾏うことができる 削減効果の試算 試算は⼤事
Slide 13
Slide 13 text
13 ©MIXI みてねではEKSを利⽤している。データプレーンはEC2で⼤半をSpotインスタンスを活⽤している Gravitonアーキテクチャは同等のx86ベースのプロセッサと⽐較して最⼤40%優れた料⾦パフォーマンスを誇る Spotインスタンスも安価で推移しているため利⽤したい EKSのGraviton(arm64)対応 試算を元にした最近の事例 みてねではSpotインスタンスを優先利⽤していて、枯渇した場合はOndemandにフォールバックする運⽤にしている そのため、Graviton(arm64)のSpot利⽤のみにした場合はSpotが枯渇するとサービスパフォーマンスが悪化してしまう → Graviton(arm64)とx86_64の両⽅を使えるようにして枯渇リスクを下げる 仮にx86_64とGraviton(arm64)の⽐率を6:4とした場合、約10%のインスタンスコスト削減になる! 対応のポイント
Slide 14
Slide 14 text
14 ©MIXI みてねでは、メディア処理にJob Workerを利⽤している(Rubyを使⽤しているのでSidekiq, Shoryuken) Workerを起動したPodでは以下のような⼿順でメディア処理を⾏っている 1. S3から対象のメディアをダウンロード(EBSボリューム) 2. 各種処理 3. 再度S3に加⼯後のものをアップロード instance storeの利⽤ 効果がありそうな事例
Slide 15
Slide 15 text
15 ©MIXI 各Workerを実⾏するPodは⼀時的にメディアを保存するのみで永続性は不要 → instance storeが使⽤できるのでは? instance storeの利⽤ 効果がありそうな事例 instance storeはEC2のインスタンス用のブロックレベルの一時ストレージ ホストコンピュータに物理的にアタッチされたディスク上にあるので、構造的に早い 利用料金もインスタンスの利用料金に含まれており、使用できるのはインスタンスタイプの末尾に ‘d’がつくもの(m7gd.mediumな ど) Workerの処理が早くなり、結果としてEC2インスタンスの利⽤時間が減少することが期待できる instance storeとは みてねのEKSのnode groupでは性能(vCPU, メモリ)が同じインスタンスタイプを複数同列に扱っている そのため、instance storeが利⽤できるようになるもののみになるとSpotの選択肢の幅が1/2になってしまう。。。 よって⼀旦⾒送りに。。。 導⼊するかどうか
Slide 16
Slide 16 text
16 ©MIXI 効果がありそうな事例 〜もし導⼊するなら?〜 メディアを扱うWorkerは複数ある その中でWorkerの実⾏頻度やユーザー影響などを考慮して1つ対象を選び、開発版で置き換えて何度か実⾏してみる 現状の実⾏時間もGrafana等で確認する →どの程度実⾏時間が削減されそうかを計測する まずは検証 instance storeを利⽤した場合のWorkerと現状の実⾏時間を元に同性能のEC2 instanceタイプを決めて、試算をする ボリューム料⾦もinstance storeの場合インスタンス料⾦に含まれるため、現状の⽅はEBSの料⾦も加算する 検証を元に試算 試算を元に、どの程度コスト削減が⾒込めるか?などを総合的に判断する 実装にどれくらい⼿間がかかるか、複雑になりすぎないかにも注意する 試算から判断
Slide 17
Slide 17 text
17 ©MIXI コスト最適化をする上で、計測をまず⾏うことが⼤事 • 実際どの程度コストが各種サービスでかかっているか? • サービスの利⽤量は適切になっているか? これらを踏まえた上で、試算や⼯数の⾒積もりをし優先度を決める そして、この取り組みを継続していくことが何よりも⼤事。コスト最適化に終わりはない みてねでもこれからもコスト最適化を継続し、世界中の家族のこころのインフラをつくります!! コスト最適化は計測から まとめ
Slide 18
Slide 18 text
©MIXI