「全アクセスがmemcachedに行ったら負け」超大量リクエストをさばくフリークアウトの技術哲学

──小浜さんが新卒入社されてから、本間さんはすぐにメンターとして育成に携わったそうですね。

本間　はい。 実はフリークアウトの研究開発のチームってそれまでは中途採用しかしていなくて、小浜さんが初めての新卒採用でした。

Science div　小浜翔太郎さん

──育成は大変でしたか？

本間　小浜さんは大学時代に機械学習の研究をバリバリやっていたので、ある程度の基礎知識は身に付いていました。だから、そんなに育成に苦労した記憶はないですね。むしろ、彼の持っている強みをいかにして発揮してもらうかを、常に考えていました。

──小浜さんは、入社当時のことを覚えていますか？

小浜　覚えていますね。それに関連して、すごく印象に残っている本間さんの言葉があります。何かの案件で失敗をした後、私が慎重になりすぎてしまい業務のスピードが出なかった時期がありました。そのときに、リラックスさせるためだと思うんですけど、「失敗しても大丈夫。私たちがいますから」と本間さんが言ってくれたんです。それがすごく心強かった。

本間　小浜さんは新卒の段階ですごく優秀でした。だからこそ、失敗を恐れてもらっては困るんですよ。できる人にはどんどんチャレンジをしてもらって、経験を通じて成長してもらい、活躍の場を広げてほしい。だから、そういう言葉をかけました。

──というお話ですが、小浜さんは伸び伸びと仕事をさせてもらえた実感はありますか？

小浜　めちゃくちゃありますね。フリークアウトって、エンジニアが自発的に「このプロジェクトを担当したいです」と言って、責任を持って遂行して結果を出せば、いろいろな仕事を任せてもらえる文化があるんです。

入社してからある時期までは先輩に遠慮している部分もあったんですけど（笑）、本間さんの言葉で安心感が生まれてからは、自信を持って「やります！」と手を挙げられるようになったと思います。

障害時の対応にこそ、エンジニアの力量が表れる

Accelerator div　テックリード　本間雅洋さん

──業務の中で得た知見で、「これは重要だ」と特に思っていることはありますか？

小浜　運用の大切さですね。私は学生の頃、研究のためにプログラミングを書いてはいたんですが、それは長期運用を前提としたものではありませんでした。でも業務では、“運用に入ってから”が本番です。サービスを24時間365日、常に稼働させ続けるため、先輩エンジニアがさまざまなノウハウを活用していることに驚きました。

例えば、障害の発生を即座に検知するために監視体制を組んでおく。それから、トラブルの原因をいち早く特定するために、普段からソースコードを読んでアーキテクチャの全体像やどう動いているかを知っておく。

何か障害が起きたとき、先輩たちはすごいスピードと正確さで対応していて「自分もあんなふうになれたらいいな」と心から思いましたね。

──そんな先輩が身の回りにいたら憧れるでしょうね。フリークアウトのエンジニアは、具体的にどういった部分が秀でていると思いますか？

小浜　「障害を引き起こしている原因」を特定するのがすごく早いです。それから、原因を追究する前に、「どういった対応をすれば障害の影響を最も小さくできるか？」の判断が非常に正確だな、とも感じています。

私もそうなりたくて、障害対応が完了した後に「あれは何が起こっていたんですか？」「どう調べたらいいんですか？」と、よく先輩に教わりに行っています。

──運用のノウハウは特定のエンジニアに属人化してしまうケースも多いですが、フリークアウトではどうやってそのスキルを後輩に伝えていますか？

本間　大きく分けると2つの方法を採っていて、「（他のメンバーを）巻きこむこと」と「マニュアル化すること」です。当社では「障害当番（夜間や休日などに障害のアラートが鳴った際、対応する当番）」を決めていて、週ごとに各メンバーでその役割をローテーションしています。結局、自分でやってみなければ障害対応の手順は覚えられないですから。つまり、「巻きこむ」とは「実際に手を動かしてもらう」ということです。

それから、その制度の前提としてあるのは、運用手順のマニュアル化です。ドキュメントがない状態でいきなり「調査して」と言われても、無理なので。そうやって、運用作業を“非属人化”させるというのは、意識してやっていますね。

1日のリクエスト数、120億。それを前提とした言語を選定をする

──フリークアウトでは、どんなプログラミング言語やミドルウェアを選定していますか？

小浜　私が所属しているScience divでは、基本的にPerlでバッチのスクリプトやデータの分析部分などを実装しています。

──Perlを選んでいるのはなぜ？

本間　当社の創業者がPerlエンジニアだったためシステムの基幹部分がPerlで書かれており、それをそのままメンテナンスしているからです。過去の資源をきちんと活かしたいですから。それに、Perlは他のスクリプト系言語と比べてもパフォーマンスが良いんです。

──他にはどういった技術を？

小浜　一部、アプリ内で処理スピードを速くしなければいけない箇所はCで実装する、ということもやっています。

また、バッチ処理で機械学習のデータを定期的にアプリ側に落としている箇所については、Hadoopの基盤がオンプレにあるのでHiveを活用したり。あと、最近はSparkを使うことも多いです。Scalaでデータを取ってきて、C++のコードでバッチを回してデータを落とし、それをPerlで使えるようにするという感じですね。

──C系の言語を使用しているのが非常に印象的ですが、それはフリークアウトのシステムにおいて処理速度が求められるから？

小浜　そうですね。処理対象となるデータの量が膨大すぎて、例えばPythonなどのよくあるライブラリだと処理が追い付かないんです。分散処理などを検討したこともあったのですが、システムの都合上適応が難しく、C++などを利用しています。

──さばいているリクエスト数って、1日あたりどれくらいの量なのでしょうか？

本間　システム全体で、トータルのリクエスト数は1日あたり120億ほどです。

フリークアウト社の開発チームはこのように「50ms or die.」というスローガンを掲げている。広告表示のリクエストに対して50ミリ秒以内にレスポンスしなければ、ビジネスとして成立しない、という意味だ。画像は同社の採用サイトより

──120億……！ であれば、一つひとつの言語やアーキテクチャ選定にも一切気を抜けませんね。ちょっと間違うと、すぐ障害が起きてしまう。その他に、今後実現したいことはありますか？

小浜　現在オンプレで運用しているサーバを、いつかはAWSなどのクラウド上に移行したいね、という話をエンジニア同士でしています。膨大な数のサーバをオンプレで運用していると起こる問題として「サーバのスペックを統一するのが難しい」というものがあるからです。

世代が新しいサーバマシンが登場してくると、旧サーバと新サーバの環境差異が原因で、同じアプリを動かせなくなることも多いです。そのときに、全部のサーバを刷新するのかというと、それはコスト面で難しい。だから、クラウド上で運用しておいた方がバージョンアップなどに対応しやすくなると考えています。

──常に運用方法を考えながら、技術選定を行っているんですね。

コードレビューに、ベンチマークを活用

──膨大なリクエストを処理するため、他にどういったノウハウを活用していますか？

本間　コーディングについて言及すると、なるべく「処理速度が速くなる記述方法」を用いることを徹底しています。言語によってクセが違っているので、「この言語だと、こういう書き方はスピードが出る」という情報は常にインプットしておき、実務に適用します。

小浜　それに関連して、ソースコードレビューですごく特徴的なことがあります。処理が遅くなる記述方法を指摘してもらうとき、本間さんはマイクロベンチマークを取って、実際に遅くなっていることをエビデンスとして示してくれるんです。

──そこまでしているんですか！ エビデンスを示してレビューしてくれると、納得感が全く違うでしょうね。

本間　それからコードレビュー以外にも、アーキテクチャにおいて工夫していることもあります。ネットワークアクセスを減らすことです。MySQLへのアクセスを減らすためにmemcachedを使用する、というのは多くの企業がやっていると思いますが、当社ではmemcachedへのアクセスすら極力減らすようにしています。

具体的には、一度取得したデータをファイル化して、それぞれのサーバのローカルに配置しているんです。システムがさばいているリクエスト量が膨大すぎるので、“全アクセスがmemcachedに行ったら負け”なんですよ。

──まさに、広告配信システムのために最適化されたアーキテクチャなんですね。

本間　そうですね。そういう意味では、フリークアウトはあまり新しすぎるツールやミドルウェアを好まなくて、どちらかというと枯れていて安全に運用できるものを選びます。セオリーに忠実な構成にするというか。これは、徹底した安定稼働が求められる当社“らしい”技術選定の特徴かもしれないですね。

一方で、学習意欲の高い小浜さんは会社であまり使わないような最新技術のインプットも積極的に行っているという。例えば、オンライン学習サービス「UDACITY」で、Deep Learning Nanodegreeという講座を半年間受講し、Deep Learningの知見を深めたそうだ。「Deep Learningを俯瞰したいという自分の動機にとてもマッチしていて効率的に学べた」と、小浜さんは同サービスを高く評価する。

良い引継ぎの秘訣は可読性の高いソースコード

──過去にさまざまなプロジェクトを経験してきたかと思いますが、お2人で一緒に取りくんだ仕事の中で印象に残っているものはありますか？

小浜　機械学習のA/Bテストツールのやつですかね。

本間　そうですね。A/Bテストかな。

──具体的には、どのようなテストだったのですか？

本間　機械学習の実装方法を変えた場合、その変更後のロジックが変更前のロジックよりも良くなっていることを何かの方法でA/Bテストする必要があるんです。そのベースとなるようなツールを私が開発しました。

しかし、そのシステムには弱点があって、複数の人が同時にテストできない作りになっていたんです。だから、使いたい人が増えると順番待ちになってしまい、あまりスケールしない仕組みになっていました。それが同時並列でできるように、改善を小浜さんにお願いしたんです。

彼はそのツール改善をすごく上手くやってくれました。結果的に、複数のテストを同時並列でできるようになり、最近はレスポンス速度改善の検証などにもA/Bテストツールの基盤を活用できるようになりました。任せて本当によかったなと思っています。

──ツール開発の引継ぎがスムーズにいった要因はなんだとお考えですか？

本間　既存の設計が、拡張することを意識した作りになっていた、というのは大きいと思います。作ったのは私なので手前味噌なんですけど（笑）。それもあって、安心して引き継げたというのはありますね。

小浜　それから、ソースコードにコメントで説明がちゃんと書かれていたのも、引継ぎやすい要因のひとつでした。拡張しやすい設計や可読性の高いコードってすごく重要だと、改めて感じましたね。

アドテクは、テクノロジーが直接的にビジネス価値となる領域

──最後に聞きたいのですが、エンジニアが広告配信の領域に携わるやりがいや面白さってどういう部分にあると思いますか？

本間　エンジニアの作ったシステムで直接的にお金が生まれる、という点でしょうか。そういう意味では、FinTechに近い部分もあるかもしれません。機械学習のロジックをちょっと改善しただけで売上が大きく上がる、ということが起きる業界なので、「自分のエンジニアリングがビジネスにダイレクトに反映されている」という実感が持てると思います。

小浜　それから、広告配信系のシステムが持つ“技術導入のスピード感”も大きな魅力だと思っています。例えば保険系や金融系などのシステムでは、どうしても「堅牢であること」が最優先なので、アーキテクチャを変更するのに数多くの承認が必要になってしまうケースも多いと思います。

でも広告配信系のシステムでは、堅牢さが求められつつも「より良いシステムにし続けること」も求められるので、新しいものをどんどん検討していける楽しさがあります。エンジニアとして、すごくチャレンジしがいのある領域なんですよ。広告配信って。

──モチベーションの高いエンジニアにとって、非常にエキサイティングな領域なのですね。お2人のノウハウ、とても参考になりました。今回はありがとうございました！

連載バックナンバー

employment.en-japan.com

取材：中薗昴（サムライト）