これはなに

LINEの友だちを活用して恋人を見つけるサービス（HOP）のバックエンド開発について紹介します。
GraphDBを利用して「友だちの友だち」や「友だちの友だちの友だち」などの人間関係を構築しています。
現在、この「友だちの繋がり」の改善に協力してくれる新たなエンジニアを探しています！！

技術から見た「友だちの繋がり」

「友だちの繋がり」をクライアント（iOS,Android）に提供するバックエンドは以下の構成になっています。HOPでは基本的にFirebaseを利用し、Firebaseで賄いきれない機能（友だちの繋がり）をAWSで補完する構成になっています。gRPCなどのコードはGoで書かれています。

HOP Backend

そして、クライアントの画面がこちらです。LINEの友だちを活用して恋人を見つけるサービスのイメージがざっくりと掴めると思います。

HOPの探すと繋がりの画面

「友だちの繋がり」を表現する技術的なおもしろさ

HOPはリリース当初から「友だちの繋がり」を表現するために技術的リソースを多く割いてきました。これは、「友だちの繋がり」がHOPが提供するサービスの重要な価値になると考えていたからです。

しかし、「友だちの繋がり」の表現は一筋縄ではいきません。主にプライバシーを守るために多くの要件を考慮に入れる必要があります。また、HOPを開発するに当たり性能劣化の問題にも直面しました。

GraphDBは2hop, 3hop, 4hopとGraphのhop数（友だち同士の距離）が増すにつれ、処理数が指数関数的に増大します。多くの課題を乗り越え、実現可能な方法を提供するところにも技術的難しさとおもしろさがあります。

どうして新メンバーが必要なのか

上記の構成を開発したメンバーが抜けたことで、AWSやGraphDBを専任するメンバー（バックエンドのエンジニア）がいないからです。

先程書いたように、HOPのバックエンドはほぼFirebaseで構成されています。一方、「友だちの繋がり」は運用コストを抑えるためマネージドなGraphDBであるNeptuneを利用しています。したがって、「友だちの繋がり」を除けばエンジニアのリソースは十分にあります。

しかし、さらにサービスを発展させ、他社のサービスとの差別化を図る上で「友だちの繋がり」は増々重要な機能になっています。ここに注力したく、新しいメンバーを探しています。

どのように改善したいのか

現在、3つの改善パターンを想定します。

① 現在の構成を維持しつつ改善する（AWSパターン）
② JanusGraphとBigTableで新たな基盤を構成する（GCPパターン）
③ 上記以外の改善策（その他）

①AWSパターンと、③その他については違和感のない改善案だと思います。では、なぜ②GCPパターンを想定するのか。それは他の技術との親和性を考慮したいからです。

HOPは良くも悪くもGoogleのサービスに強く依存しています。クライアントではFlutterを利用し、バックエンドはFirebase、各種GCPのサービスも多数利用しています。一方、AWSに強いメンバーは不足しています。

もし、「友だちの繋がり」をGCPパターンに移行できれば、既存メンバーの技術スタックを活かしつつ、ツールを集約してスピーディーな開発が可能になります。現在、この構成の技術検証を須藤(id:kurotyann, @kurotyann9696)が1人で行っています。近日、この技術検証の過程をこのTechブログに公開予定です。

GraphDBの経験は問いません。AWSやGCPなどの各種クラウドサービスの運用経験のあるバックエンドエンジニアの方、一緒に「友だちの繋がり」を開発してみませんか？

少しでも興味のある方は、弊社採用ページや私のTwitterへ連絡ストクロ (@kurotyann9696) | Twitterでも構いません。興味のある方、お待ちしています！