短いサイクルで変更・テスト・確認を繰り返し、ほぼ前例のない移行を実現

スタディサプリやQuipperのサービスの少なくない部分を、AWSをはじめとするクラウドサービスが支えています。ただ、クラウドは便利な基盤であるがゆえに、気が付くとどんどん拡張し、コストがかさむこともあります。小中高SREグループの田中京介さんは、データベースの基盤をGraviton プロセッサというコストパフォーマンス優れたCPUに性能を落とすことなく移行する道筋を度重なる検証を通して確認し、月1万2,000ドルに上る大幅なコスト削減を実現しました。

Q：これまでの経歴をお聞かせください。

田中：私は2021年4月に大学院を卒業し、新卒でリクルートに入社しました。最初の配属は、リクルート全体の複数のプロダクトにまたがってクラウドの利活用を推進するクラウドアーキテクトグループという部署でした。

そこで仕事をする中で、幅広い領域を見るのもいいけれど、特定のプロダクトに関心を集中させて改善していきたいという思いが強くなり、今の部署に異動を打診しました。社内でも最もクラウドの利活用が進んでいる部署の一つだったことが理由の一つです。

Q：そもそもリクルートという会社を選んだ理由は何だったのでしょう。

田中：一つは企業規模の大きさです。たいていの人が知っている認知度の高いサービスに携われる点は大きな魅力でした。新しいプロダクトを一から作るのも面白いと思いますが、大きなサービスを維持し、さらにエンハンスしていくことにも醍醐味があります。リクルートには、一つの会社の中にいろんなフェーズのいろんなプロダクトがあり、自分のように社内異動を通して携われることも魅力的だと思います。

Q：働き方についてはどうですか。

田中：実は、朝起きられないというのも入社を決めた理由の1つです（笑）。それぞれのライフステージに合わせた働き方の柔軟性もあります。現にSREグループの場合、朝5時から夕方まで働く人もいれば、僕のように午後から働き始め、夜まで勤務する人もいます。成果主義に基づく自立性がはっきりしていると思いますね。

リクルートでは「個の尊重」が一つのテーマで、リクルートが大切にする価値観の一つに「個の尊重」があり、それも体現されていると思っています。たとえば、別に「新卒の○○です」などと名乗らなくても個々人のスキルをちゃんと評価してくれますし、互いの意見を尊重する文化が根付いています。特にSREチームはその色が濃いように思います。何か問題があって変えていく必要があると感じたら、説得する必要があまりありません。「あなたが『やる』と言うのなら、それは意味のあることなんだよね」という具合に、とても信頼されていると思います。僕も逆に、他の人に対して「なんでこれをやっているのかな」と思っても、後々、それは必要なことだったんだとわかることもありました。

Q：では、SREグループのミッションについてお聞かせください。

田中：Webページ（https://brand.studysapuri.jp/career/position/sre）に書いてあるとおり、SREグループは開発者の開発生産性やサービスの信頼性にフォーカスしている組織です。「最高のプロダクトを作り続けられる開発組織の実現」というビジョンに向け、必要なことは何でも求められます。

スタディサプリ小中高と一言で言っても、BtoB、BtoCのほか、中学講座のリニューアル、あるいはコーチングなどいろいろな領域がありますが、SREでは、各チームが自分たちに必要なことを、必要な時に、自分たちでできるようにする「自己完結チーム」を実現できる環境作りに取り組んでいます。保守運用を中心とした旧来の「インフラ運用チーム」のように、何か依頼されたり、問題があったら対応するというのとは少し違いますね。インフラエンジニアとしての側面もある一方で、開発者の開発生産性を高めるところにもフォーカスでき、幅広いスキルが求められる面白いポジションだと思っています。

Q：以前からインフラ領域が好きだったのですか。

田中：もともと幅広い範囲に興味があり、大学生のときにはISUCONに参加したり、ICTトラブルシューティングコンテストの運営をやったりしていました。クラウド環境に本格的に触れたのは入社してからですが、自宅にはサーバがあってよくいじっていました。

Q：開発サイドとの関係はうまくいっていると思いますか。

田中：そうですね。スタディサプリの場合はそこの「壁」が全然感じられません。こちらから「何か困っていませんか」と気軽に聞きにいくこともあるし、逆に「こういうのをやりたいと思っているんですが」と相談がくることもあります。

Q：MVPを受賞したサーバのコスト削減プロジェクトはどんな経緯で始まったのでしょうか。

田中：対象は国内向けのスタディサプリではなく、インドネシアやフィリピン向けに展開しているQuipperに関してです。スタディサプリのSREは国内で展開しているスタディサプリとグローバルのQuipperの両方を見ているのですが、そのうちQuipperのシステムでコストの大部分を占めるのがデータベースであるということは、自分がチームに入る以前から認知されてきた課題でした。

Q：では、それを見かねて手を上げたという感じだったのでしょうか。

田中：いえ、ある意味、詳しくなかったからこそ言い出せた部分があるかもしれません。私以外のSREメンバーは、新型コロナウイルスの影響でスタディサプリに対する需要が急増し、それに応えるためにギリギリのところを耐え抜きながら拡張してきた経緯を知っていました。ですので、そのスペックを下げる、しかもサービスのコアとなるデータベースの性能を下げるという、ある種リスキーなところに手を入れるとなると、どうしても疑心暗鬼になるのが自然だと思います。

もう一つ、SREではいろいろなリソースの使用率をDatadogというサービスで可視化し、グラフで見えるようにしています。自分は日頃からそれを眺めるのが趣味だったんですが、見ているうちに「このコストってここまで払わなくてもいいんじゃないか、半分くらいにはできるんじゃないか」という気がしてきました。自分なりに実現可能性を調べていく中で、いくつか必要なステップがあり、それを順番に倒していかなければならないことがわかってきました。

Q：倒さなければいけない前提条件とは、どのようなものだったのでしょう。

田中：コスト削減のコアはデータベースの性能を下げることでした。我々はMongoDBというデータベースを使っているのですが、当時リリースされた新たなバージョンではIntelのCPUに加え、ARMベースのGravitonというCPUもサポートするようになり、これを使えば更にコストを削減できるのではないかと考えました。スケールダウンとCPUの変更という大きな変更を加えてもデータベースが問題なく動き、求める性能が出るかがポイントでした。

そのためにまず「MongoDBのバージョンを上げてもちゃんと動くのか」「CPUをGravitonに変えても動作するのか」「Gravitonでも十分な性能が出るのか」という具合に、ステップを踏みながら少しずつ検証を行いました。ある程度めどが付いたので、チームを巻き込んで、本番のトラフィックにも耐えられるかどうかの負荷試験を行ったのが昨年の11月以降です。

Q：慎重にやらないといけないんですね。

田中：CPUの種類によって得意な処理が異なるため、単純に比較できないのが難しいところでした。自分である程度確信を持てる段階までいったところでマネージャーに相談し、本格的な性能試験を行いました。

Q：トントン拍子というよりも、コツコツ進めていったんですね。

田中：SREチームには、「今週はこのタスクをやらなければいけない」といった明確な割り振りはあまりありません。20％ルールのような感じでいろいろなプロジェクトに手を出すことができ、その一つとして進めていった感じです。

もちろん調査に当たっては、SREチーム、特にこれまでデータベースの面倒を見てきたシニアエンジニアの深尾さんにサポートをいただき、CI/CDのARM対応などをして頂きました。また、過去の経緯をきちんと文書として残す文化があるので、それにも助けられましたし、QAチームの皆さんにもとてもお世話になりました。

Q：検証自体はどのように行ったのでしょうか。

田中：これが計測結果の一例です。一つ一つ、いろんな設定やパラメータを試しながら「この設定ならばそれほどパフォーマンスの劣化はないな」といったことを検証していきました。

またQuipperには「定期テスト機能」という、ちょっと特徴的なワークロードがあります。ある学校から多数の生徒が一斉に同じ時間にアクセスしてくるので、普段の10倍、下手をすると100倍くらいに負荷が上昇するのですが、そこを乗り切れるかどうかがポイントでした。ここでも数値を見ながらデータベースの設定をいじりつつ試していきました。

環境が整っていたこともあり、負荷試験を行ってすぐに定量的に結果を見て、また調整して……というサイクルを短い期間で繰り返せたのはとてもよかったポイントだと思っています。

Q：まさに「早いサイクルで変更していく」というSREの仕事そのものですね。他に、うまくいった理由はどこにあると思いますか。

田中：今回のようにいろんな要素がからんでくる場合には、必要な条件や関連する事柄をうまく洗い出すことが重要になります。難易度の高い作業ですが、達成したいゴールに向け、そこをきちんと分解しながら進められた点がよかったなと思っています。

もう少し具体的に言うと、何を評価すればOKなのかを見極めるのが難しかったりします。たとえば「こういう負荷をかけたときにどのグラフを見て、どのパラメータがどの範囲にあればOKなのか」を自分で見極め、ロジックを組み立て、定量的に示していく必要があります。1つのデータベースから何十種類ものグラフが出てくる中から、「どれが性能に影響するのか」をきちんと見定めて進めることができた点はとてもよかったと思いますし、一朝一夕に身に付くものではないと思います。

Q：クラウドは社会人になってから触れ始めたそうですが、違和感はなかったのですか。

田中：クラウドといっても、実はオンプレミスで求められるものとあまり変わらない部分も結構あると思っています。ファイルシステムはどのように動作し、ディスクにはそれぞれどんな特性があって……といった事柄を理解していたからこそ、「では、この数値を見れば、その性能に影響しているかどうかがわかる」ときちんと確認して進められたと思います。

Q：コンピュータサイエンスの基礎ですね。

田中：そうですね。そういう意味ではISUCONや社内で開催されたR-ISUCONに参加して経験した、ボトルネックを見極め、一つ一つ原因を倒していくプロセスを、現実世界でも実践できたと思っています。

Q：昔は、「動いているシステムには手を付けない」のが鉄則と言われたものですが……。

田中：データベースもまさに、スタディサプリ小中高というプロダクトの中では手を付けにくいものの一つではありました。けれど、今回のように事前の検証をしっかりやれば、自信を持ってそこにトライできることが示せたと思います。

Q：移行によるコスト削減に関して、何かフィードバックはありましたか？

田中：我々の給与にダイレクトに反映されるわけではないんですが（苦笑）……でも、エンジニアもある程度コスト感覚を持つことも大事だなと思っています。

クラウドはスケールアウトさせやすい半面、うまく使わなければ、なんやかんやでお金を使いすぎてしまう側面があると思います。たとえば利益率5％のプロダクトでクラウドのコストを1万円削減できれば、売り上げ20万円分の寄与になると考えると、意外と馬鹿にできません。数字とも向き合いつつうまく使いこなすことが大事だと思います。

SREチームのビジョンである「自己完結」という言葉には、自分たちのサービスのコストにも意識を払っていくという要素も含まれると私は考えています。自分たちのサービスが生み出す売り上げや利益に対し、どのくらいのコストを払っているかにも意識を向けながら進めていくのがいいと思っています。

Q：では、SREの心得とは何でしょう？

田中：壊れないものは試せばいいと思っています。チームのバリューにも「Fail Smart」という言葉があります。大事なのは失敗しないことではなく、同じ失敗を二度と繰り返さないことです。同じ失敗を繰り返さなければ、より強いシステムになり、サービスはどんどん前に進んでいけますし、今のシステムもそうやって成り立っています。リスクを検討したうえで、いかに賢く失敗し、早く学びを得られるかが大事だと思っています。

Q：今後チャレンジしたいと考えていることがあればお聞かせください。

田中：引き続き、デベロッパーが開発しやすく、開発生産性が最高な環境を作ることが使命だと思っており、その垣根をもっと低くしたいと思っています。

また個人的には、社会人になってからアプリケーションエンジニアとしての経験がそんなにないので、その経験を得るため、他チームへの留学もちょっと考えています。スタディサプリでは社内留学的な制度が実態としてかなり活用されていて、開発者からSREへ、SREから開発へ、という具合に毎期誰かが留学しています。こうした経験を通して、お互いがどういう仕事をしていて、どういうところにフォーカスしているのかを知ったり、そこから得られた知見をシェアしたりするといった活動がポジティブに捉えられており、自分もチャレンジしてみたいなと考えています。

取材時期：2023年4月

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