「これは本当にあるべき姿？」と疑う姿勢を持ち、ゼロベースからの施策検討でコストを最適化

何か一つだけの取り組みでコストを最適化するのは非現実的なことでしょう。小中高SREグループの田中京介さんは、試行と計測のプロセスを繰り返すミクロ的な取り組みと、「そもそもこのデータは本当に必要なものなのか」「どうあるべきか」と根本に立ち返って問い直すマクロ的な視点の両方から多数の施策を次々に実施し、コストの最適化を実現しました。

Q：昨年に続き、二年連続二回目のMVP受賞おめでとうございます。田中さんのミッションは昨年と変わらないのでしょうか。

田中：引き続きSRE(Site Reliability Engineer)としてスタディサプリ小中高と、海外事業のQuipperを見ています。昨年よりもQuipper側の比率が多少高まり、英語の比率がより高まって50%ほどになっているという点は変化かと思いますが、業務内容に大きな変化はありません。

Q：個人としてチャレンジしていることはありますか。

田中：インフラエンジニアとして入社し、SREとしておよそ3年仕事をしてきましたが、最近はもっとアプリケーション側に染み出していきたいなと考えており、部署の独自施策である社内短期留学について相談しているところです。
もともと自分はRubyが大好きです。スタディサプリ小中高の多くのアプリケーションもRuby on Railsで書かれていることもあり、読もうと思えば自分でもコードを読み書きできます。けれど社会人として開発を経験したわけではなく、本職のバックエンドエンジニアの方々に太刀打ちできるとは思っていません。そういった知識を深めることで、SREとしても能力を高め、アプリケーションエンジニアにとってより使いやすく、より早く開発ができるプラットフォームを作れるのではないかと考えています。
実は昨年、「RubyKaigi」というRuby言語に関するカンファレンスに会社から参加させてもらいました。そこで得た知見を活かして、pitchforkを導入してメモリ使用量を削減するという形でプロダクトに還元できました(https://blog.studysapuri.jp/entry/2024-pitchfork-into-the-largest-rails-application-in-studysapuri)。
そんなふうにSREならではのインフラ側の知見と、Rubyなどアプリケーションの知見、どちらも活かしたいと考えています。

Q：今回は複数の施策を実施し、多額のコストを削減したそうですが、具体的にはどんな取り組みを行ったのですか。

田中：昨年は主にデータベースのアーキテクチャを変更し、パフォーマンステストを繰り返しながらQuipperのインフラコストを削減していったことを評価していただきました。それに対し今年は、スタディサプリ小中高側での施策が対象です。
昨年Quipperなどの他事業でやったことをそのままスタディサプリに適用もしましたが、それ以外にもこれをしたらコストが最適化できるかもしれない、と思いついたことを片っ端から試してみました。結果として10件くらいは手を打っていると思います。特定の施策が大きく効いたわけではないのですが、それぞれにおいてまとまった額のインパクトがある施策をコツコツ進めていきました。

Q：大きめの課題から倒し、さらに少しずつ色々な手を打っていくという意味で、「パフォーマンスチューニングコンテスト」でチューニングを行うのと似たところを感じます。

田中：ある種、それに近からず遠からずかもしれません。「こことここには無駄がありそうだ」と目星をつけたところを具体的に掘り下げ、どのくらい削れるかを見積もって手をつけていきました。

Q：具体的にはどのような施策を行っていったのですか。

田中：大きく三つに分類できると思います。
一つ目は、前回実施したデータベースの載せ替えのように、手を動かして数字を見て、また手を動かしていく……というプロセスを繰り返していくアプローチです。これは主に、技術的難易度が比較的高いケースで採用しました。
まず、スタディサプリ小中高でもQuipperと同様にデータベースのコストが非常に大きいと言われていたので、そこに幾つかの方法でアプローチしました。スタディサプリ小中高のインフラはほぼQuipperと同じような構成になっているため、同じような手法が適用できるだろうなと考えていました。
ただ、どこを削るとどのくらい負荷が減って、どのくらいコストを減らせるのかを確かめる手法が大きく違いました。Quipperには負荷試験のための手順書が存在していたのですが、スタディサプリには、サービス全体に対する負荷試験の手法やノウハウがありません。正確に言えば、負荷が急増したコロナ禍の時期にはやっていたのですが、その後数年は行われておらず、当時使っていたツール等も使えなくなっていました。ですので、データベースに対するクエリを再現するMongoDB用のツールでずっとメンテナンスされていなかったものに手を加えて使えるようにして、その後に計測して試すアプローチをとっていきました。
もう一つ貢献できたのが学習データのデータベースの最適化です。スタディサプリでは、ユーザーの正答率や動画の視聴時間など本当にたくさんの学習データを蓄積しています。それがスタディサプリのデータの大半を占めていると言ってもいいほどです。「そのデータは本当に全て必要なんだっけ？」と考え直し、データの品質や価値を損なわないまま、データの量を削減する余地はないかと考えていました。データに責任を持つチームと共同で、三ヶ月から半年くらいかけて、使われていないデータを消したり、圧縮したり、クラスタの構成を見直すといった具合に、あれやこれやと試していきました。

Q：リクルートに限らずデータは「資産」であり、できれば取っておきたいものだと思います。そこを精査して、使わないものを削除したり、代替できる他のデータを見つけたのですか。

田中：そうですね。より小さなデータ量で同等の情報を表現できるよう保持の仕方を見直した、というのが語弊がないように思います。
例えば、「ある動画を何秒間見たか」を記録したい場合に、「0秒から30秒まで見た」という記録と「30秒から1分まで見た」という2件の記録を、「0秒から1分まで見た」という1件の記録にまとめると、その分圧縮できます。いわゆる「コンパクション」で、それをどう実現するかを、開発者チームにも話を持ちかけながら実行しました。
他にも、過剰品質を避けて不要なリソースを減らしたり、山のようにあったバックアップを消すことで、多くのコストを削減できました。

Q：バックアップは毎日取得するのが当たり前で、一度運用を始めるとあまり見直さないものですよね。

田中：そもそも必要なものとして導入していますからね。でも、スタディサプリ全体の経費の内訳をゼロベースで深掘りしてみると、実はデータベースのバックアップにかかる費用が一番大きいことが判明しました。
そこで、テクニカルな解決というよりは、法規制対応やカスタマーサポートの問い合わせ対応のために、「会社として、あるいは部署としてどのくらいの期間のバックアップデータが必要か」について話し合って合意を取り、その範囲内で合理的なコストに最適化しました。

Q：自明だと思っていたことにも、メスを入れる必要があるんですね。

田中：はい。サービスには成長の痛みがあるんじゃないかと思っています。
スタディサプリは10年かけてどんどん成長し、コロナ禍で需要が急増した際は特に、ある程度コストの増加を大目に見てでもサービスを大きくしてきた経緯があります。急成長の時期には、まず目の前の課題をどうにかしなければなりませんから、慎重に精査するのは合理的ではありません。ですが今は、そこを見直すべき時に来たのではないかと僕は思っています。どちらがいい、悪いではなく、その時々でやるべきことをしっかりやることが必要だと思います。

Q：他にはどんな手を打ちましたか。

田中：AWS(Amazon Web Services)のブログでも事例として取り上げていただいたのですが、「Amazon Aurora Serverless v2」という比較的新しいデータベースサービスを採用してみました。他にも、アクセス頻度に応じてより安価なストレージを活用する「Amazon S3 Intelligent-Tiering」なども試しています。「名前は聞いたことがあるけれど、まだ使ったことはないよね」というサービスを素直に試してみました。

Q：中には、あまり効果が出なかった案もあったのですか。

田中：もちろんありました。Amazon S3 Intelligent-Tieringはまさにそうで、多少はコストが減りましたが、全体に影響が出るほどの効果ではありませんでした。
他にも本当にいろんな案を検討し、スペシャリストの方々にも相談しました。けれど、移行にかかるコストやのリスク、技術的な難易度を踏まえて整理した結果、「今はやるべきではない」と判断し、先送りにしたものもいくつかあります。

Q：いろんな方と相談もしているんですね。

田中：そうですね。コスト削減は大事ですが、それによってユーザーに影響を与えてはいけません。そのため、変更を加える際には、どのようなリスクが、どのタイミングで生じるかなどを開発部署のマネージャーの方々に頭出しするなど、事前に周知をして、全体の計画やプロダクト品質に影響を与えないように進めました。

Q：そういう意味では、コスト削減と同時に、可用性やセキュリティといった非機能要件にも気を配っていたのでしょうか。

田中：ものによっては一から作り直しが必要になることもありました。その場合は、コスト削減と同時に改善にも手を入れたりしていました。
例えば、これまでスタディサプリの開発環境や検証環境は、すべて一つのKubernetesクラスタの上に載っていました。けれど、大きいものは何かと不安定で、問題が起きたときの影響範囲も大きくなりがちです。そこで思い切ってクラスタを検証用アプリが動いている環境とGitHub Actions self-hosted runnerの二つに分離してコストを削減するのと同時に、互いに影響を及ぼすことなく安定して動かせるようにしました。このGitHub Actions self-hosted runnerの置き場所も工夫することで、より安価に使えるようになっています。

Q：色々な施策を紹介してもらいましたが、細かく計測して確実に削減していく目線と、一歩引いて大局的な視点から「そもそもどうなんだろう」と問い直す目線、その両方が必要なんですね。

田中：僕はそう思います。インフラエンジニアとバックエンドエンジニアの両方の知見が必要だと思っている理由もそれで、視点やアプローチ、知識の数は多ければ多いほどよいと思っています。

Q：そんな引き出しを増やすコツはありますか。　いろんな場所でインプットすることでしょうか。

田中：そうですね、日頃からインプットの幅を広げるよう意識しています。
リクルートという会社は大きいので、いろんなプロダクトがあります。自分はよくSlackで、スタディサプリ以外のプロダクトの雑談チャットを覗くようにしています。「どこどこではこんな技術を試してるんだ」とか「どこどこでこういう障害があったんだ」というのを眺めて、いつかうちでも使えそうだな、この技術はこのチームが詳しそうだな、といった情報を頭の中に入れておくのは大事かもしれません。
インターネットのニュースやXでもそうですね。AWSやGCP(Google Cloud Platform)の新規プロダクトが出てきたら、「使えそうかどうか」を考えてみるようにしています。もちろん、収集しても役に立たない情報もたくさんあり、100個のうち使えるものは3個あるかないかかもしれませんが、その存在を認知しておくだけでも面白いですし、そういう飛び道具を活かしてきたケースも結構あります。

Q：RubyKaigiなど外部カンファレンスへの参加も情報収集の一つですね。

田中：そうですね。アプリケーション開発の潮流やRubyに加わる改善に関する情報が意外に役立っています。「じゃあ、ここのパラメータをいじればこういう具合に効いてくるかもしれないな」と考えながら発表を見ています。

Q：円安の影響で、クラウド費用がかさむ問題も深刻化していますが、やはり、同じようなアプローチで今後も取り組むのでしょうか。

田中：お金に限らず、今のアーキテクチャやコードもそうですが、改めて「これって本当に必要なんだっけ」「これが本当にあるべき姿なんだっけ」と疑ってみる姿勢は大切だと思っています。僕はビジョナリーというわけではありませんが、今、目の前にあるものに対して「これ、ちょっと高すぎない？」といった違和感には気づける方だと思っています。そこを元に日々深掘りしていったことで、今回も成果を出せたと思っています。

Q：今後はどんなことにチャレンジしていきたいと考えていますか。

田中：最近のホットなトピックでいうと、生成AIの活用です。スタディサプリのインフラに詳しいAIを作って、SREへの問い合わせに、人の代わりに答えてもらえるといいですよね。
個人で言うと、僕は別にインフラだけにこだわっているわけではなく、バックエンドも、フロントエンドも幅広く興味があるので、これからもエンジニアとしてのスキルを広く磨いていきたいなと思っています。
同時に、属人化するのではなく、全員の底力を上げて組織をより強くするために、ナレッジシェアも必要だと思っています。基盤はどんどん複雑になっており、使いこなすのには多くの前提知識が求められます。それをよりシンプルにしたり、学習曲線をうまく設計できないかと考えています。
僕は、SREチームが掲げる「自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る」というミッションにすごく共感しています。開発者がより強くなるために素晴らしいプラットフォームを作るのはもちろん、それを使いこなせるようなチームを作ることも必要です。どうやったらそれが実現できるのかを考えることはやりがいのある仕事ですし、これからも模索を続けていきます。

Q：スタディサプリでの働きがいはどんなところにありますか。

田中：教育という非常に重要な課題に対し、ここまで一直線なアプローチをしているプロダクトはそんなにありません。その意味で、スタディサプリはやっぱりいいプロダクトだと思いますし、意義も感じています。
リクルートという会社に関していうと、自分は「Bet on Passion」と言う価値観にとても共感しています。仕事が自動的に降ってくるのではなく、まず「こういうことがしたい」「世の中をこう変えたい」「自分はこう成長したい」といった本人の意思が最初にあって、それと会社が期待することを擦り合わせることで本人の仕事が決まっていくところが本当にいいなと思います。自分自身、社会人四年目としては信じられないくらい裁量と責任があって、その中で「今自分がやりたいこと」「やったら価値があること」を考えて積み重ねていった結果が、今につながっていると思います。

記事中で紹介した事業（名称や内容含む）や人物及び肩書については取材当時のものであり、現時点で異なる可能性がございます。