見出し画像

ユーザー1人あたりのインフラコストを半分にするまでの道のり

こんにちは!家族1人あたりの食費は単調に増加しているあさっちです。

今回は、私が所属しているインフラ/SREグループで目標の1つとして設定している月間アクティブユーザー数(MAU)あたりのインフラコストを、2年半ほどかけて約半分に減らしてきた過程についてお話したいと思います。


Key Resultとしてのインフラコスト

弊社ライフイズテックではOKRのフレームワークで目標管理を行っています。グループで掲げているObjectに「コストの最適化を行い、事業を継続できる状態を作る」というものがあります。

そして、現在注力している中学校・高校の情報の授業向けオンライン教材、ライフイズテックレッスンでその状態を達成しているかどうかを判断するKey Resultの一つとして、

月間アクティブユーザー数(MAU)あたりのインフラコスト

を設定しています。

クラウドプラットフォームであるAWSをはじめとして、利用している各種SaaSの費用を合わせたインフラコストを、MAUで割った一人あたりの数値です。

Key Resultを達成するために、ユーザー数が増加したときにそれ以上にインフラを増やさないようにする対策はもちろんのこと、サービスが授業でどれくらい使われるか月によって差があるため、インフラの稼働も臨機応変に調整する必要があります。

MAU(赤線)とAWS費用(青線)の推移

これまで実施した4つのコスト削減策

MAUあたりのインフラコストを半分にするために、これまでに実施してきたコスト削減策には、大きく分けて以下の4つがあります。

1. Cloud9環境を動的に割り当てる

ライフイズテックレッスンでは、生徒のみなさんがプログラミング教材を学んでいただいた後に自分のオリジナルWebサイトを作る環境として、AWS Cloud9をアカウントごとに割り当てていいます。

Cloud9を通常の構成で利用すると、OSなども含まれた10GBのディスク(EBS)が常に保持されたままになります。EBSは1GBで1ヶ月あたり15円程度ですが、10GBで数十万アカウントという規模になってくると、費用が激増してしまいます。

そこで、アカウントごとに常に保持しておくのは、Webサイトのサンプルファイルが入った1GBだけのディスクにして、OSも含めたCloud9の環境は利用するときだけ動的に割り当てるようにしました。

言葉だけではイメージするのが難しいですが、詳細はJAWS-UG SRE支部の第三回でもお話させていただきましたので、よろしければご覧ください。

2. 教材ファイルストレージの移設

2018年にリリースしたテクノロジア魔法学校から、サイズが小さく数が多い教材ファイルを格納するストレージとして、EC2インスタンスにインストールしたCephを採用していました。当時はパフォーマンスが高い冗長化されたストレージの選択肢が少なかったという背景もあります。

EC2インスタンスの費用がかさむこと以外にも、2022年の2学期頃からユーザー数が増えたことによるパフォーマンスの問題が発生し、調査したところCephのディスクI/Oにボトルネックがあることが分かったものの、事例やノウハウが少なく運用が難しくなってきたという課題もありました。

AWSさんにも相談したところ、Amazon FSx for OpenZFSというソリューションを紹介していただきました。負荷試験を実施してパフォーマンスが問題ないことを確認してから移行した結果、最大レスポンスタイムが90%改善し、コストも75%低減することができました。

AWSのグローバル事例にも取り上げていただき、先進的な取り組みになったと思います。

3. 監視やログのコミット量の調整

ライフイズテックレッスンでは、サービスの監視やログの分析にDatadogを利用しています。ユーザー数が増えるにつれて、Datadogの費用も増加してきました。

DatadogはあらかじめSyntheticsやLogsなどそれぞれの機能を利用する量を確約することで、費用を削減することができます。授業で利用する中学校・高校が増えてアクセス数が上昇する時期や、夏休みのように利用が急激に減る時期もあるので、担当者の方といっしょに、確約する量を月ごとに調整しながらできるだけ費用を削減しています。

4. リザーブドインスタンスの購入

上記のDatadogの話と似ていますが、ライフイズテックレッスンはリリースされてから4年以上経過し、年間を通したアクセス数の推移と毎年のユーザー数の伸び率から、今後どの程度インフラに負荷がかかるか、どれくらいのサーバーリソースが必要になるが予測できるようになってきました。

そこで、今後1年間確実に利用するインスタンス数とインスタンスタイプを見積もって、リザーブドインスタンスを購入することも進めています。データベース(RDS)から始めて、これからEC2、ECS FargateのSavings Planにも広げていく予定です。

今後進めていくこと

最後に、今後進めていく対策についてですが、これまで様々な手を打ってきたこともあり、サービスの価値を維持したまま大幅にコストを下げられるようなものは少なくなってきました。

引き続き、上で述べたサービス利用量の臨機応変な調整やリザーブドインスタンスの購入は進めていきますが、それに加えて以下の2つを考えています。

サーバー数やSaaSコストの見積もりと調整の自動化

現在は、サーバーリソースの数やDatadogなどのSaaSの利用量を手動で見積もっています。今後はこれまでの実績から自動的に見積もり、将来的には更新するところまでシームレスに実行し運用を効率化していきたいと思っています。

サーバーを増やさないようにパフォーマンスチューニング

今後もサービスのユーザー数が増えていくことが予測されていますが、現状からなるべくサーバーリソースを増やさないように、ログや負荷試験の結果などから開発メンバーと協力してパフォーマンスチューニングも進めていきたいです。

今後も事業を継続していくために、インフラコストと格闘していくことになるはずです。その経験から得られた知見があれば共有していきたいと思います。それでは、また!


ライフイズテック サービス開発部では、気軽にご参加いただけるカジュアルなイベントを実施しています。開催予定のイベントは、 connpass のグループからご確認ください。興味のあるイベントがあったらぜひ参加登録をお願いいたします。皆さんのご参加をお待ちしています!