夜間メンテナンスの待ち時間から始まったElasticsearchへの移行で、圧倒的な高速化を実現

学習を進める上で、自分はどのくらい頑張ったのか、目標に向けて進んでいるのかを目で見て確認することは、大きなモチベーションになります。しかし、その確認を行う管理画面が重たく、なかなか表示されないようでは、利用者や先生の意欲がそがれてしまうでしょう。そんな状況を、既存の手法にとらわれることなく新たな技術を採用し改善したのが、Englishバックエンド開発1グループの間島大智さんです。その経緯を伺いました。

Q：リクルートに入社したきっかけを教えてください。

間島：前職でもアプリケーション開発に携わっていたほか、一時期インフラ部門にもいて、多岐にわたる仕事をしていました。その前職で知り合った人たちとのつながりがあったことに加え、新規事業を興せる会社、ビジネスサイドが強い会社に行ってみたいという思いもあって転職しました。

Q：今はどんな業務を担当しているのでしょうか？

間島：主にアプリケーション開発、それも画面に見えている部分ではなく、アプリが通信する先をバックエンドチーム内で作っています。

Q：リクルートにやってきて、文化の違いなどを感じたことはありますか？

間島：営業担当が全国各地にいるのがすごく大きな強みだなと思っています。人数の多さだけでなく、それぞれが「ここ、こうしたらいいよね」「こうしたいよね」といった考えを持っていて、そこがリクルートならではだなと思います。

Q：間島さんは、スタディサプリENGLISHの学習データを格納したデータベースのレスポンスを、Elasticsearchを導入して改善したそうですね。それ以前は、そんなに管理画面が重たかったのでしょうか？

間島：そうですね。学校や団体さんが生徒の進捗状況を把握するための「学習データ」の画面描画が遅すぎる、というお声を頂戴していました。インデックスを張ったりして少しずつチューニングし、高速化を図っていたんですけれど、それでもまだまだ遅い状態が起きていたので、抜本的に見直す必要があるなと思っていたんです。

この問題がそれまで顕在化していなかったのは、データが増えてくると発生する性質の問題だからです。そんなにデータ量が多くなかった昔は問題がなかったのですが、利用者の方が増えてくるにつれてデータがどんどん蓄積され、速度が遅くなってきたところがありました。これを何とかしないといけないという思いもありましたし、この先、いろいろな形の集計をしたいとか、新たなアイデアが出てきたときに柔軟に対応できるようにしたいと考え、Elasticsearchが一番向いているんじゃないかと思って導入してみました。

Q：以前のデータベースでも何も手を打たなかったわけではなく、改善は図っていたんですよね。それでも足りなかったのでしょうか。

間島：はい、いわゆるリレーショナルデータベース（RDB）を使っていました。ただRDBの場合、単純にスペックを上げる形でしか改善できません。これに対しElasticsearchは、横に並べていくことで性能を上げ、負荷を分散しやすい作りになっているのがいいところです。

Q：ただ、実際にサービスとして提供している仕組みを、動かしながら移行するのは大変ですよね。

間島：おっしゃるとおりで、切り替えに当たってはかなり慎重を期しました。一番気にしていたのは、RDBでの出力結果とElasticsearchの出力とで齟齬が発生しないかでした。その確認のため、実際に出力結果を画面に出して比較したりしていました。

実はRDBに格納されていた値自体にも、昔のアプリケーションのロジックに起因する誤った値が入っていた場合もありました。なので、齟齬があるとしても、Elasticsearch導入によるものなのか、それとも元々のデータに何かおかしなところがあるのかは、人の目で念入りに確認しました。中には、「そもそもここにはどういう時にどんな値が入るのか」が曖昧になっているデータもあったので、その定義や不整合をきちんと整えていくところが、泥臭く、苦労しましたね。

Q：そもそも、どうしてElasticsearchを選択したのでしょうか？　他にも選択肢はありますよね。

間島：はい、確かに他にも選択肢はあったのですが、計算速度自体は早くても、その計算が走るまでの処理で待たなければいけない性質のサービスだったりして、一瞬で結果が返ってくるようなニーズを満たそうとすると難しいところがありました。そういう要件を考えてElasticsearchがよさそうだなと判断しました。僕が前職でElasticsearchに触れていて、有効性を実感していたというところもあります。

Q：これは、チーム内の他のエンジニアと意見を交換しながら決めたんですか？

間島：実は、通常業務の一環で夜中に2〜3時間くらいの停止メンテナンスを行っていた際、実行が終わるまでの空き時間で、前から課題に感じていたRDBをElasticsearchにすることを試してみたんです。それが発端だったのですが、入れてみたら意外と動くのではないかと思い、あらためてプロトタイプを作るための時間をもらってテストしてみました。それで動きそうなことがわかったので、本格的にプロジェクトを動かすことになりました。

Q：この先を見据えた柔軟性は実現できましたか？

間島：RDBの時は、高速化のためにデータをある程度集約して保存していました。「トレーニング」単位ではなく、それをいくつかまとめた「レッスン」単位で学習時間を保存していたのです。Elasticsearchでは、トレーニングという最小単位で学習時間を保存できるようになったので、「どんなトレーニングが苦手か」とか「正解率はどのくらいか」といったことを確認できる基盤が整いました。例えるなら、都道府県単位ではなく、市町村単位でデータを見られるようになったという感じですね。近々学校向けの学習データの画面でトレーニングの種類ごとの正解率を出す予定ですが、これはElasticsearchがなければできなかったと思っています。

Q：プロジェクトを進めるにあたって、苦労したことはありましたか？

間島：実はこれは年度計画にはなかった話で、予算もありませんでした。多くの事業管理やビジネスの方々に調整していただいて予算を確保できたおかげで、段取りよくできたと思っています。

Q：予算獲得のための説得やプレゼンテーションはどのように行ったのでしょうか？

間島：プロトタイプを作り、その結果実際にどのくらい高速化したかという数字をきちんとまとめて効果を示しながら合意を得ていきました。プロトタイプがあったので、予算面はもちろん、技術面でもブラッシュアップでき、良いステップを踏んで進められたと思います。

Q：既にRDBからの移行は一通り完了したのでしょうか。

間島：おかげさまで3種類あるデータのうち1つは移行が完了しており、残る2つの移行を、順次、他の方に進めてもらっています。僕は、ハンズオンなどを通じてElasticsearchの使い方を部署内に啓蒙しているところです。

Q：それは、Elasticsearchに関する知識を属人化させないためですか？

間島：そうです。そこはかなり大事だと思います。正直に言うと個人的には新しいものを取り入れるのは反対な方です。「それ誰が保守するんだっけ」というのもあって、相当な理由がない限り新しいものは入れたくない、という思いが強いのですよね。その延長で、何か新しいものを導入しても、属人化してしまうとその人が全部見ないといけなくなるし、その人がいなくなれば困ってしまいます。なので、なるべくいろんな人が触れるようにしていきたいなと思っています。

逆に、明確な利点があるなら新たな技術を入れるべきだと思います。実際、RDBだとやりにくいことが、Elasticsearchだとすごくやりやすいんです。SQLだったらたくさん条件文を付けなければいけないクエリを、Elasticsearchでは柔軟に書けますし、高速開発もできるので、「ここにも応用できるね」「こんな使い方ができるね」といった発想ができる人を増やしていくのが大事かなと思っています。

Q：数年後、Elasticsearchのデータベースが再び技術的負債にならないようにするのも大切ですね。

間島：どんな技術でも、2〜3年後に見てみると、別の技術の方がいいんじゃないかと判断される可能性はあります。Elasticsearchも例外ではありません。そういう意味では、データベースに格納されている根本のデータがおかしくてはいけないので、それを整理しつつ、「このデータはどういう意味か」を定義し、ドキュメントを整理しています。

Q：この先、一人のエンジニアとしてはどんなことに挑戦していきたいですか？

間島：「作りたいものを何でも作れる人」になりたいなと思っています。僕は今、フロントエンドの開発は全然できないのですが、それも含めてサービスを作れるような、本当の意味でのフルスタックエンジニアになりたいです。

Q：リクルートという環境では、それを目指していく上でいろいろと刺激が得られそうですね。

間島：各部門に本当に優秀な方々がたくさんいて、どの話を聞いても面白いですし、いろんなことをやらせてくれる環境なのがいいなと思います。また、内製していることもあって、案件への関わり方が深いですね。受注開発だと「この仕様で作ってください」と言われたとおりに作るだけですが、「ここはこういう風にした方がいいんじゃないですか」「こんな出し方もできますよ」と追加の提案ができるのがこの会社の魅力かなと思います。内部をシンプルにしつつ、お客様にもわかりやすいものを提供する、そんな提案ができるのっていいことですよね。

取材時期：2022年4月

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

スタディサプリの開発主体であったQuipper Japanは組織再編のため、2021年10月に株式会社リクルートに事業譲渡しています。