プレイドが提供するCX（顧客体験）プラットフォーム「KARTE」では、リアルタイムに変化する顧客の行動などを把握・分析し、状況に合わせて最適なアクションを実現しています。この「リアルタイム性」を担っているのが「Blitz」と呼ばれるシステムです。プレイドのプロダクトの根幹を支え、価値差分につながる優位性を生むリアルタイム解析基盤であり、その開発には「高スケーラビリティ・低レイテンシー・強整合性」などの技術的な難しさと面白さが詰まっています。

Blitzの開発・運用に携わるCore Platformチームの古賀 友規と松井 大騎に、Blitzの詳細、今後のビジョン、働くなかで得られることなどを聞きました。

「基盤の仕組みを作ること」に楽しさを感じる

――まずはお二人の自己紹介をお願いします。

古賀：古賀です。プレイドには2018年4月に入社して、もう7年目になります。大手エレクトロニクスメーカーのグループ会社に新卒入社した後、制作会社に入ってiPhoneやiPad向けのアプリ開発を主に担当しました。その後転職サービスを提供する会社で働き、求人検索エンジンや求職者向けのスマホアプリの開発を担いました。

その会社の同僚が先にプレイドに入社していて、その方から誘われたのが興味を持ったきっかけです。入社前に複数の社員に話を聞いて感じたのは、とにかくプロダクトにいろいろな可能性があること。もともとプレイドではKARTEというプロダクトを提供していますが、その価値を生み出す源泉となるのがユーザーの行動データです。これを他の領域でも活用することで、さまざまなプロダクトを創出できる点に可能性を感じていました。他にも大量のトラフィックや膨大なデータを扱っていることも他にない魅力でしたね。

それから、私は前職でユーザーが使うアプリケーションを開発するのがメインの業務でしたが、プレイドならより低レイヤーの技術にも関われるだろうと考え、入社を決めました。プレイドへ入ってからは、モバイルアプリ向けのプロダクト「KARTE for App」の立ち上げやモバイルアプリ向けSDKの開発・オープンソース化、新プロダクトの開発、「KARTE Talk」の開発などに携わり、その後2022年からCore Platformチームに所属しています。

直近Core Platformチームに異動した理由は、プレイドに居るなら1度はKARTEのコアである解析基盤の開発に携わってみたいと思っていたのと、自身の性格的にも楽しく仕事ができると感じていたからです。
私はどちらかと言うと几帳面な性格で、アーキテクチャを考えたり、ソースコードをリファクタリングしたりすることに楽しさを覚えるタイプ。Core Platformチームのように、システムの基盤をしっかり考えて作っていく仕事は非常にやりがいがありますし、とても楽しいです。

松井：松井です。私はモバイルアプリ開発に特化した会社に2012年に新卒入社し、プレイドに移ったのは2015年ですね。前職ではスマホアプリの運営に携わっていたんですが、そのアプリのプッシュ通知の運用が上手くできていなくて。

本来ならば、その情報を知りたい人に最適なタイミングでプッシュ通知を送るべきですが、そのためにはユーザーのセグメンテーションやフィルタリングの開発が必要になります。開発も大変ですしコストもかかるので、「ひとまずユーザー全員に通知を送る」という運用をしていて、自分としてはあるべき姿ではないと感じていました。

そんなタイミングで、「最適な情報を、最適なタイミングで、最適な人に伝える」みたいなコンセプトでKARTEを作っているという記事を読みまして、自分が感じていた課題感と似てるなと。ここに魅力を感じて、プレイドに入りました。プレイドではインフラ関連の業務にずっと携わりました。

その後、当時シングルクラウドだった構成をマルチクラウドにしたり、Datadogなどのモニタリング体制を整備したりしていたのですが、実は一度2022年にプレイドを辞めています。アートがすごく好きなので、仕事でもアートに携わりたいと思い、アート作品を扱うスタートアップに転職しました。

そのスタートアップでは、アート作品をレンタルできるECサイトの開発に携わっていたのですが、ユーザーが直接触れる機能を作るよりも裏側のインフラ周りを触る方が好きだなと改めて思ったこと。また、インフラを触るなら大規模な分散システムを開発・運用に関わりたいという気持ちが出てきたこともあり、もう一度転職を考え始めました。

その際にプレイドに出戻りすることも選択肢にし、高負荷・低レイテンシーの大規模分散システムの開発や運用を行っている、Core Platformチームを選んで2023年に再度入社しています。

――大規模なインフラやトラフィックやデータを扱える会社は他にも存在していると思いますが、プレイドならではの魅力は何ですか？

松井：まず、大規模なインフラを抱えているような大手IT企業と比べると、プレイドは少人数のエンジニアで開発・運用をしているため、個々人の裁量や見られる範囲が非常に大きいです。それから、過去のイベントまで含めてユーザーの行動をリアルタイム解析し、数百ms以内に応答するということは、複雑で難易度が高く、だからこそ楽しいですよね。また、自社オンプレではなくクラウドの技術をバリバリ使い倒しているのも、個人的には面白みを感じる部分です。

古賀：ユーザーの行動データをコアに据えてさまざまなプロダクトを展開しているところが魅力の一つだと思います。そのため多様な課題に向き合うことができますし、それらの課題を解決するために技術的にも幅広くチャレンジすることができています。個人の考えやニーズを汲み取って裁量を持って働くことができるのも、プレイドの良いところだと思っています。

Blitzとは。何を担い、何を追求しているのか。

――Blitzの概要について教えてください。

古賀：シンプルに言えばユーザーの解析基盤です。Webサイトやモバイルアプリなどでのユーザーの行動をリアルタイムに解析し、それぞれのユーザーに合わせたアクションをリアルタイムに実施できるのが特徴です。過去の行動を統計値化したものと、現在の行動を掛け合わせて解析を行います。

この解析基盤の特徴として、まず非常に低いレイテンシーで処理が行えるというのがあります。ユーザーの行動を数百ms以内に解析してアクションを返すことができます。また大量のトラフィックに対しても安定して動作するのも特徴の一つです。過去には秒間で13.4万もの大量のイベントを安定して処理した実績があります。

松井：一定して大量のトラフィックがあるわけではなく、時期や時間帯によってシステムへのリクエスト量に変動があります。以前、朝晩で10倍くらいリクエストの差があった事例も見たことがあります。トラフィックが少ない時期にはインフラのコストを抑えられるように、サーバーのスケーリングをうまくやっているのも技術的な面白さですね。

少し前に、CPOの柴山が書いたBlitzのコンセプトなどを解説しているブログ記事があるので、興味がある方はぜひそちらを読んでください。

――なぜリアルタイム性を重要視しているのでしょうか？

松井：仮にユーザーがECサイトで靴を買おうか迷っているとき、その靴のクーポンが画面に表示されたとしたら「安くなるから買おう」という行動に結びつきやすいですよね。もしこれが、すでに他の商品に関心が移っているタイミングで靴のクーポンが表示されたとしたら、コンバージョン率が下がってしまうはずです。ユーザーにとっても良くない体験ですし、企業にとっても機会損失になってしまいます。

現実世界で実店舗を訪れた場合、接客している店員さんは私たちの行動を観察しながら、逐次商品をおすすめしてくれたり、情報を提示してくれますよね。その体験をオンラインでも再現するには、リアルタイム性は欠かせない要素だと考えています。

古賀：このアーキテクチャを実現するために、Google Cloudの各種サービスを適宜使っています。特にBigtableについては、日本国内でもトップクラスに使い倒していますね。他にもBigQueryやSpannerなど、複数のデータベースを適材適所に組み合わせて使っていることも、一つの特徴だと思います。

私たちの提供するプロダクトは、トラフィックが非常に多いうえに時期や時間帯によってその量が大きく増減するため、トラフィックに合わせて柔軟にスケールするデータベースが求められます。そのため、前述のデータベースのようにストレージとコンピュートが分離されていて、スケールが容易なものを使うのが基本になっています。

松井：これらのデータベースは、発行されるクエリの複雑さや求められる応答速度などによって使い分けています。たとえば、リアルタイム性が特に重要な処理の場合はレイテンシーが低いBigtableを参照し、リアルタイム性がそれほど必要ではないけれど複雑なクエリを発行する場合などはBigQueryを参照するという使い方です。

――ちなみに、高速性の実現の裏に、複雑性があるからこそ難しいのだと思いますが、どのような要素や処理があるのでしょうか？

松井：ユーザーの過去の行動を全部踏まえた上でアクションを返しているからこそでしょうか。その人が過去に何万円購入したとか、何回このサイトを訪問したかとか、直近のセッションで購入しているかどうかとか、長いタイムスパンの統計情報をもとにアクションを出すこともできます。そしてもちろん、その瞬間の結構短いタイムスパンで解析・アクションを実行することもできる。ここをかなり柔軟にやっていることが複雑な処理につながっていると僕は思っていますね。

システム基盤の信頼性・可用性をさらに向上させる

――今後、改善していきたい点はありますか？

古賀：システム基盤としての安定性を高めることは、直近1年ほどで特に重要なテーマになっています。実は昨年にBlitzで障害が発生しクライアント企業やそのユーザーの方々にご迷惑をおかけしてしまったことがありました。Blitzは我々が提供するプロダクトたちの根幹を支える基盤であるため、もしシステムが停止してしまうとかなりの範囲に影響が及びます。可能な限り障害をなくし、障害が起こったとしても被害を最小限に抑えられる仕組みを作っていく必要があります。

この障害をきっかけに、この1年はシステムの信頼性を高めていく活動に特に注力してきました。具体的にはサーバーをマルチリージョン構成にしたり、特定のデータベースが動作しなくてもユーザーに致命的な影響がでないように複数のデータベースを組み合わせるアーキテクチャに変えるなど、可用性を高める取り組みを行ってきました。

また、大手企業を中心に求められる要素として、監査ログ取得やセキュリティ強化、データの保管場所を固定化できるオプションを用意するなどの対応にも取り組んでいますね。

今後の取り組みとしては、エンタープライズレベルの信頼性を獲得するために、障害発生から解消までのオペレーションを可能な限り自動化して障害解消までの短縮することや、システムの異常をより素早く把握するためにオブザーバビリティの強化に取り組んでいきたいと思っています。

松井：プロダクトに求められる当たり前のレベルが上がってきていることは感じています。エンタープライズ企業の根幹かつ広範で導入される事例も増えてきていますし、そのための基盤や機能への要求は高まり続けていると思います。

サービスレベル目標（SLO）を定義して遵守する活動もしています。従来は、ざっくりとしたSLOは決めたもののきちんと運用できていない状態だったので、それを改善するためにエラーバジェットポリシーを策定して、定期的に振り返る機会を持ったり体制上の運用を定めたりする取り組みを始めています。

技術的に広く・深く扱えるチーム

――Core PlatformチームやBlitzに携わる面白さや難しさはどのような点にありますか？

古賀：扱う技術的な領域が非常に幅広く、かつ深いという点は、面白さであり難しさでもあります。Blitzにおいてはサーバーサイドのアプリケーションの設計・実装やインフラの構築以外にもやることがあって、たとえばWebサイトに埋め込むためのJavaScriptやアプリに組み込むSDKの設計・実装なども私たちが担当しています。

データを扱う部分に目を向けると、収集したユーザーの行動データを価値あるものにし、さらに分析しやすいものにするためにはどう扱えば良いか考えることも求められます。データの利活用を促進するためには、高速にデータの分析が行えることが求められますが、それを実現する手段として独自のデータベースエンジンを作ることにも挑戦しています。

これだけ求められる技術の幅が広いとキャッチアップも大変ですし、日々学ぶことも多いです。逆に言えば飽きることもないですし、日々の仕事に楽しく取り組めるのは、このチームの特徴です。

あとは、非常に規模の大きな基盤を運用しているからこそ、インパクトの大きい施策がやりやすい環境ではあると思うんですよね。たとえば、自分の担当した開発によってシステムの安定性が上がりサービスの価値が向上したとか、大幅なコストダウンになるようなことも、よく実現・実感できるので、そうした点もやりがいにつながります。

松井：「仕事が与えられるインパクトの大きさ」については私も同意見ですね。たとえば特定機能のパフォーマンスを改善することによって、サーバーの台数を減らし、大きなコスト削減を実現できるようなことがあるんですよ。それから、大規模なインフラを運用していなければまず遭遇しないような珍しい問題とも出会えるので、その解決策を考えるのも楽しいです。

これは課題でもありますが、大規模なシステムだからこそ、アーキテクチャ改善による工夫の余地が大きいです。多種多様なクラウドプロバイダーやそのサービスを組み合わせて使うことで、パフォーマンスやコストを最適化させていく面白さがあります。

基盤の開発をイメージすると、「あまり顧客の役に立っている実感を得られないのでは」と思われるかもしれませんが、全くそんなことはありません。リアルタイムの解析機能を高速化したり、より利便性を高めたりすると、それがプロダクトの新たな機能の種になります。システムの裏側を触って基盤の改善をすることでプロダクトそのものに貢献でき、顧客に直接的にインパクトを与えられる面白さがあると感じますね。

また、今後の目標としてシステムの安定性を高めるため、モニタリングに加えてオブザーバビリティにも取り組みたいです。発生した問題に対する検知の仕組みはかなり推進できているものの、問題発生時の情報収集や今後起こり得る問題への対処の仕組みなどはまだ不足しているので、より良くしていけたらと考えています。

いまのシステム基盤に満足せず、さらなる改善を

――チームには、どのようなタイプの人が多いのでしょうか？

松井：各々のスキルは異なっていますが、共通してみんな粘り強いイメージがありますね。私たちの扱っているシステムは大規模かつ複雑だからこそ、何かのバグや障害が発生した場合に原因の特定が非常に難しいです。そうした場合でも一つひとつのログを丁寧に見て、仮説を立てつつ検証できる人が揃っているチームだと思います。

古賀：何かの事象が起こっている原因や理由をきちんと解き明かす。なぜそれが起こっているのかを突き詰めて見ていく人が多いですよね。

松井：あと、技術の根本の部分まで深掘りして理解しようとする特性がある人たちの集まりだと思います。仮にオープンソースソフトウェアで問題が発生した場合などには、該当箇所のソースコードを読むなどして、小手先の対応ではなく本質を理解したうえでの対応をする人が多いです。

過去の事例を挙げると、Google CloudのBigtableで特定のノードの負荷が高くなりパフォーマンスが悪くなったことがありました。その際にGoogle Cloudのサポートに連絡をするだけではなく、Bigtableの構造について書かれた論文を読んで内部構造を把握しトラブルシュートしたメンバーがいました。

古賀：Javaの標準ライブラリにHTTPのリクエストを扱うメソッドがあるんですが、その処理のパフォーマンスがなぜか劣化したときがありました。その際に、きちんとスタックトレースを1行ずつ追って、具体的にどの箇所のコードが悪影響を与えているのかを見つけたメンバーもいます。他にも、Node.jsのバージョンアップをした際にパフォーマンスが劣化して、その原因を解明する際にCPUのフレームグラフを取得して、処理が重たくなっているメソッドを見つけて原因特定をした事例もありましたね。

他のメンバーがインタビューを受けた記事もあるので、よければこちらもご覧ください。 

――最後に、Blitzの開発・運用における今後の目標を教えてください。

古賀：今のシステム基盤でも十分に素晴らしい強い基盤なのですが、それに満足せずより価値のあるシステムへと改善したいです。直近では基盤の信頼性・可用性を磨き込むのはもちろんですが、それ以外にもデータの価値を高めるための取り組みも進めながら、それが最終的に顧客のビジネスの改善につながれば私は嬉しいです。

松井：個人的に直近で挑戦したいのは、システム基盤の状態をよりわかりやすくすることです。先ほど話したオブザーバビリティにも通じますが、いろいろなクラウドサービスを使っているからこそ、システムが複雑で見えにくい部分も多々あります。各種のシステムのステータスがどのような状態になっているのかがクリアにわかるような仕組みを作っていくと、今後の開発や運用もしやすいでしょうし、新しくチームに参画した人も情報をキャッチアップしやすくなると思います。

これからも、各種プラットフォームで新しいサービスが登場したり、既存のサービスがより便利になったりといったことがあるはずです。そうした新技術を積極的に取り入れ、パフォーマンスが良くてコストも低く、スケールもしやすい、信頼性も可用性も高いBlitzへとさらに進化させ続けていきたいです。

■ 関連の採用情報