Diverse developer blog

株式会社Diverse(ダイバース) 開発者ブログです。

自社システムにマッチしたツールを選び活用することが、ユーザーのサービス継続のカギになる~新ツールMackerelを導入して~

AWS移管に伴い、Diverseではサーバー監視ツールの導入が必要となりました。検討を重ね、新たに導入したのが、サーバー監視ツール「Mackerel」(マカレル)です。今回は、Mackerelを導入した経緯と導入によって生まれたメリット、さらにチームとして見えてきた今後、挑戦したいことについて、サーバサイドエンジニアの横山裕(よこやま ゆう)さんに話を聞きました!

―そもそものツール導入の経緯を教えてください。

横山:当社が提供するサービスをAWSに移管したため、既存のサーバー監視ツールは使えなくなってしまいました。そこで新たに、AWSにマッチした新ツールを導入する必要があったのです。(AWS移管については下記記事参照)

理想とする開発体制をつくるために、僕らが取り組んだこと~AWS移管を完了して~ | Diverse Dev.Blog

実は以前、別のサービスでAWSが提供しているクラウド型のサーバー監視システム「CloudWatch」を使用していたのですが、うまく扱うことが出来ませんでした。そこで以前の状況も踏まえて、まったく新しい監視ツールを使ってみようと話し合いが持たれたのです。

ツール選定の際は「操作性の良いツールであること」に主眼を置きました。チームのみんながストレスなく使えることが最重要だったからです。

その1案として、僕が個人的に無料で使っていた「Mackerel」を提案しました。はてなさんがつくった監視システムとあって、チームのエンジニアたちもその存在は知っていました。話し合いの結果、「良さそうだし、まずは使ってみようか」ということで、導入が決定。まさに弊社のValue、「Fail Fast!」という感覚でした。メリットは何と言っても、その操作性の良さ。導入作業がとにかく簡単で、mackerel-agentをインストールするだけで使い始められるという使い勝手の良さも決め手になりましたね。

24時間いつでも同じサービスを提供する。そのミッションにマッチしたツール

――Mackerelの導入で得られたメリットはどんなところにあると思いますか?

横山:どのアプリにも共通して言えることだと思いますが、僕たちが提供しているサービスは「ユーザーが安心してアプリを不具合なく、ストレスなく使えること」が前提です。その点、「サービスの品質を保つ」という意味でMackerelは、優れた機能を持っていると思いますね。

サーバー監視におけるルールをこちら側で柔軟に決められる点や、プラグインで自分たち独自の監視体制が設定できるのも大きな特長です。設定の閾値を超えるとアラートが発報されるので、それを僕たちが確認する仕様になっています。

マッチングアプリ、という特性上「検索を速くする」のはいつでも課題のひとつ。そのため、レスポンスタイムを計測するといった、データ収集も同時に行います。品質改善につなげる手がかりとしても活用しています。

他方、既存の監視ツールでは、グラフを生成するツールと、アラートを追加するツールと2つのサーバーが必要でした。しかし、Mackerel導入後は1つのツールでこれらすべてが把握可能。1つ画面を見れば全体が見通せるので、ミスの軽減にもつながったと思います。

そもそも既存の監視サーバーでは、「監視サーバーが動いているかを確認する」という作業が発生していましたが、Mackerelに関しては、「ツールが正しく動いているか」という部分ははてな側が負担してくれています。「監視サーバーの動作確認」にかかる人的コストをはてな側が担ってくれているので、こちらは「ユーザーが正しくサービスを使えているか」という確認作業に集中できるというメリットもあります。

f:id:diverse-tech:20210806110307j:plain

勉強会を開催して、チームが今、何をやっているか?を見える化

――導入にあたって、社内勉強会を実施したと聞いています。

横山:はい。すでにyoubrideでは、Mackerelを導入していたのですが、サーバサイドエンジニアから、活用事例が少なくどんなものかわかりにくい、という声が寄せられていました。

そこで、サーバサイドエンジニアに向けて監視の必要性や、活用を意識した勉強会をしようとしたところ、Mackerel側で知見共有のための勉強会企画があることを知り、CREチームの方にリクエストさせていただきました。

当日は、インフラエンジニアからサーバーサイドエンジニアまで幅広く参加。Mackerelで何ができるのか?を簡単に教えていただきました。チームを越えて横断的にみんなで知識共有をしたことで、僕たちが今何に取り組んでいるか、伝える機会にもなったと思います。

Mackerel CREチームさんの記事はこちら

mackerel.io

現在リモートワーク下ではありますが、月に1回このような勉強会を開催しようという試みも始まっています。チームで開催することによって、他のチームの活動を知ったり、知ってもらったり。「今、何をしているか」の見える化を積極的にしていきたいと思っています。

ツールを正しく活用し、ユーザーのサービス継続率につなげていく

――最後に、今後挑戦していきたいこと、展望を教えてください。

横山:とにかく、僕たちの一番の目標は「ユーザーの利便性向上のため、サーバーの安定供給につとめること」です。さらに言ってしまえば、監視サーバーが使われ、アラートが出る前に、予防措置を講じられるような体制、さらにはシステムを構築していきたいと思っています。

僕たちはSREというチームなのですが、チームの目標は「サイトの信頼性を確保すること」これに尽きます。サービスのダウンが無く、質を落とさず使用できるということは、ひいてはユーザーのサービス継続率にもつながります。

楽しく、また快適にサービスを継続していただけるよう、今後もチーム一丸となってクオリティの向上を目指していきます!

――横山さん、ありがとうございました。

DiverseではMackerelや他のツールを使うことのできる「SREとして活躍できる仲間」を募集しています!

f:id:diverse-tech:20210806111140j:plain

エンジニア(インフラ/SRE)

エンジニア(サーバーサイド・youbride)

エンジニア(サーバーサイド・YYC)

Diverseが技術者コミュニティを支援する理由とは?

こんにちは!Diverse広報担当です!

突然ですが、先日DiverseのオフィスにDroidKaigi様から素敵な贈り物が届きました。ありがとうございます!!
f:id:diverse-tech:20210518155314j:plain
これをきっかけに、Diverseと技術者コミュニティの関係を探るため、エンジニア・菊池さんにインタビュー!
DroidKaigi様へ協賛を始めた背景、カンファレンス登壇、そして今後Diverseとして技術者コミュニティにどう関わっていきたいか?について教えていただきました。

  • “良いサイクル作り”に協力したい
  • エンジニアとコミュニティの心地よい関係性
  • 技術者コミュニティへの貢献と継承
続きを読む

【後編】イベント『Lookerを使ったデータドリブンなアプローチ』の資料×動画を公開します【Meetup #3】

こんにちは!Diverse広報担当です。

先日、Diverse Meetup #3となる『Lookerを使ったデータドリブンなアプローチ』を開催しました!
本ブログではイベントの様子をお伝えしております。

f:id:diverse-tech:20210707121140j:plain

connpass.com

今回は、前編に続いて「Lookerの+αの活用法」についてお届けいたします!

【前編】「Lookerの基本とデータ活用」をまだご覧になっていない方は、まずこちらをご覧ください。 developer.diverse-inc.com

▼目次

  • 当日の資料と動画を公開します
  • 続・イベントルポ大公開【後編】
    • ▼Lookerのその他の活用紹介(00:11)
    • ▼質問コーナー(01:44)
  • さいごに
    • ▼Diverseの情報発信について
続きを読む

【前編】イベント『Lookerを使ったデータドリブンなアプローチ』の資料×動画を公開します【Meetup #3】

こんにちは!Diverse広報担当です!

先日、Diverse Meetup #3となる『Lookerを使ったデータドリブンなアプローチ』を開催しました! f:id:diverse-tech:20210705102041p:plain

connpass.com

DiverseのiOSエンジニアであり、最新アプリHOPにも関わる熊埜御堂 将隆さんがご登壇!
BIツール「Looker」についての基本、Diverseで展開しているマッチングサービスでの活用法、さらにデータドリブンを実現するためのコツをお話いただきました。

今回は、当イベントの様子を前編・後編に分けてお伝えします。
まずは前編、「Lookerの基本とデータ活用」からどうぞ!


▼目次

  • 当日の資料と動画を公開中!
  • イベントルポを大公開します
    • ▼Lookerって何?(00:11)
    • ▼LookMLについて(02:15)
    • ▼Diverseの環境について(04:15)
    • ▼データドリブンなアプローチについて(05:35)
  • さいごに
    • ▼Diverseの情報発信について
続きを読む

女性も活躍できる、Diverseのカルチャーは「人」にあった

f:id:diverse-tech:20210624135249j:plain

突然ですが……。

Diverseの社員の男女比割合って どれくらいだと思いますか?

実は、

男女比は6:4と限りなく 同数に近づきつつあります。

マッチングアプリのサービスを展開する中で 男女どちらの視点も重要だと考えているからです。

では実際、Diverseの職場環境は女性から どのように映っているのでしょうか?

今回は、女性エンジニアとして活躍している フマファリーン・シェイクさんにインタビュー!

f:id:diverse-tech:20210624135336j:plain

2019年に南インドから来日し、Diverseに入社した彼女は、

現在活き活きと仕事をしています!

  • なぜエンジニアになったのか
  • 担当している仕事内容

を含め、Diverseの魅力をたっぷり聞きました!

起こる問題を解決していくプロセスが好きで、エンジニアの道へ

―― フマさんは、インドの大学を卒業後、日本で就職。

初めて勤務した会社がDiverseと伺っていますが、そもそもなぜエンジニアになりたいと思ったのですか?

フマ:もともと私は「問題を解決していく」そのプロセスが好きで、問題解決型の仕事に就きたいと漠然に考えていました。

そんな折、15歳の時に初めてJavaとコーディングを学び、“面白い!”と思ったんです。論理的な問題に対してコードを書くことで、解決に導くプログラミングの世界。これにすっかりハマってしまいました。 その後、大学でもプログラミングを専攻し、今に至ります。

エンジニアリングは多くの問題を解決し、人々の生活を便利にします。

以前であれば、世界中の人々をつなぐのは不可能でした。でも、技術が進歩し、世界中の人がWEBを介してつながる世界が生まれました。つまり、エンジニアリングは、“ひらめいたアイデアが現実のものになる”可能性を秘めています。私はそこに、大きな希望を感じたのです。

次第に“いつか世界を変えるようなものを作ってみたい”と思うようになり、エンジニアを志すことにしました。

―― フマさんが入社してから現在に至るまでの経緯と、現在の業務を教えてください!

フマ:2019年に入社後、OJTを経て2020年1月から2021年3月の期間、マッチングアプリ“HOP”のチームにジョイン。主にフロントエンドにはFlutterを、バックエンドにはfirebaseを使用し開発に取り組みました。

その後、2021年4月からはFlutter開発者として、婚活アプリ“youbride”のAndroid/iOSのメンテナンスと改善業務に取り組んでいます。

今後は、サーバーやバックエンドのプログラミングの知識と経験を更に増やしていきたいと思っています。

――Diverseの中で女性の人数は増えてきましたが、youbrideのエンジニアチームの男女比はどうなっていますか?

フマ:youbrideでは、私を含めて4人のエンジニアがいますが、女性は私だけです。

ちなみに以前担当していたHOPでも、女性は私1人だけでした。でも、そんなこと気にならないくらい、みんなフレンドリーなんです(笑)

f:id:diverse-tech:20210624135733j:plain

女性も男性も関係なく、「個」が大事にされているという感覚

―― 男性エンジニアと比較すると、女性エンジニアは少ない印象がありますが、正直なところ仕事がやりにくいな、と思うことはありませんか?

フマ:今回、インタビューの話をいただいてから少し考えてみたんですけど…全然無いんです。“女性だから仕事がしづらい”と感じたことは一度も無いですね。

“何故だろう?”って考えてみると、Diverseが社員ひとりひとりを大事にしているからだろうな、と感じています。例えば、業務上で困ったことがあっても、話しかけ易い雰囲気なので、相談をためらうこともありません。男女関係なく、みんな親切で話しかけやすい。

もし上手くいかないことがあっても、先輩にアドバイスをもらえたり、励まされたりするので、モチベーションもキープし易いです。

―― そういうコミュニケーションって大事ですよね。

フマ:はい!細かなコミュニケーションが行き届いているので安心して仕事に集中できるんですよね。

ほかにもDiverseの魅力はあります。女性特有のことで言えば、エール休暇(生理休暇)を月1日取得することが出来ます。女性って、体が辛い時もあるじゃないですか。なので、そういった休暇があると、“無理をしなくていいんだ”と安心感があります。

さらに、コロナ禍以前にイベントを開催したとき、私が宗教上の理由で食事の制限があった際にも配慮してもらえました。

“女性”と言うより、個人に寄り添って対応してもらえるので、“大事にされている”という実感があるんですよね。その気持ちがまた、仕事のモチベーションにつながっていると思います。

待遇面がしっかりしている、ということだけではなく、その奥には“ひとりひとりの個の違いを大切にする”、正にDiversityを社名の由来とする会社のカルチャーが表れている気がします!

f:id:diverse-tech:20210624135710j:plain

安心できる環境だからこそ、チャレンジしようという気持ちが生まれる

―― フマさんのお話を聞いていると、Diverseって、ひとりひとりの個性を発揮しやすい環境なのかなと感じます。

フマ:間違いなくそうですね!毎日仕事をするのが楽しみです(笑)

私はDiverseでしか働いたことがないのですが、ことある毎に、“恵まれた環境だなぁ”と感じています。

特に私の場合は、日本語がまだ十分に理解出来ない点もありますが、周りのメンバーがサポートしてくれるおかげで、仕事を進められます。

これまでに2つのオープンソースを開発し、更には個人でテクニカルブログを執筆するなど情報発信にもチャレンジしました。ブログでは、良いレスポンスをいただけて嬉しかったです!

新しいチャレンジをしていく面から見ても、Diverseは女性も男性も関係なく、さまざまな機会を平等に与えてくれる会社だと思っています。

―― 多方面でさまざまなチャレンジをしているのですね!最後に、今後のフマさんの目標を教えていただけますか?

フマ:今後はバックエンドの知識をより深めていきたいと思っています。いくつかの言語をマスターして、業務の範囲をもっと広げていきたいです。

目指す姿は、“フルスタックエンジニア(設計~プログラミングなどマルチにこなせるエンジニアのこと)”ですね。

AIについても勉強しているので、開発にAIを導入するのもひとつの目標です。

その一方で、日本語の上達にも力を入れたいですね…。現在は日本語能力試験のN3レベルなので、N1レベル(最高難度、ネイティブでも難しい)を目指したいなと思っています。

スキルアップやコミュニケーション力をアップさせながら、将来的にはチームをまとめる存在になって、もっと会社に貢献したいと考えています。

とにかくやってみたいことがいっぱいで(笑)

Diverseに入社して、自分のやりたいこと、そして可能性が更に広がっていくのを実感しています。

f:id:diverse-tech:20210624135319j:plain

――フマさん、ありがとうございました!

さて、Diverseでは現在下記の職種を 積極的に採用しております!

ご興味のある方はぜひお気軽にエントリーください!

herp.careers

herp.careers

herp.careers

🔰 JanusGraphのチュートリアル「GraphOfTheGods」をローカルに構築する

これはなに

  • JanusGraphとはオープンソースのGraphDBです
  • 今回はGraphOfTheGods(神々のグラフ)を使って、GraphDBをローカルで試す方法を紹介します
  • この内容は主に https://docs.janusgraph.org/ の公式情報を日本語で簡略化したものです
  • GraphDBに興味のある方は絶賛採用中なので、こちらのブログも参照してください!

🤝 恋愛を「友だちの繋がり」で技術的に支援するサービスのバックエンド開発に力を貸してください! - Diverse developer blog

GraphOfTheGodsとは

GraphOfTheGods(神々のグラフ)はJanusGraphが公式で紹介している代表的なチュートリアルです。文章で説明するより、公式サイトの図を見る方が理解しやすいので、下記にその図を引用します。

GraphOfTheGods(神々のグラフ)の図
f:id:kurotyann:20210622142719p:plain https://docs.janusgraph.org/getting-started/basic-usage/

図によれば、hercules(ヘラクレス)の父はjupiter(ゼウス)で母はalcmene(アルクメーネー)です。そして、herculesはhydra(ヒドラ)とギリシャのサロニコス湾付近(北緯37.7 東経23.9)で戦っています。人間関係だけでなく、出来事までデータが関連しています。GraphDBの特徴を理解できる素晴らしいチュートリアルです。

セットアップ

1. Docker

まずはDocker Desktopをローカルにインストールします。https://docs.docker.com/get-docker/ から対応するプラットフォームを選んでインストールしてください。以後、ここからはMacで説明を進めます。

Docker Desktopをインストールできたら、Docker DesktopからDockerを起動してください。

2. janusgraph-docker

docker専用のJanusGraphのリポジトリをローカルにクローンします。

$ git clone git@github.com:JanusGraph/janusgraph-docker.git

3. コンテナを起動

janusgraph-dockerのmasterブランチで下記のコマンドを実行します。

$ docker run --name janusgraph-default -p 8182:8182 janusgraph/janusgraph:latest

しばらくすると、下記のコンテナとイメージが作成されます。

Docker Desktopで見えるコンテナとイメージ
f:id:kurotyann:20210622143919p:plain

4. Gremlin Consoleに接続

ターミナルで操作している場合、もう一つ別のタブを開いてjanusgraph-dockerのmasterブランチで下記のコマンドを実行します。

$ docker run --rm --link janusgraph-default:janusgraph -e GREMLIN_REMOTE_HOSTS=janusgraph --name gremlin-console -it janusgraph/janusgraph:latest ./bin/gremlin.sh

実行すると、Gremlin Consoleが起動するので、ターミナルからGraphDBにクエリを実行することが可能になります。

$ docker run --rm --link janusgraph-default:janusgraph -e GREMLIN_REMOTE_HOSTS=janusgraph -it janusgraph/janusgraph:latest ./bin/gremlin.sh
Jun 22, 2021 3:42:27 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.

         \,,,/
         (o o)
-----oOOo-(3)-oOOo-----
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/opt/janusgraph/lib/slf4j-log4j12-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/opt/janusgraph/lib/logback-classic-1.1.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
plugin activated: tinkerpop.server
plugin activated: tinkerpop.tinkergraph
03:42:32 WARN  org.apache.hadoop.util.NativeCodeLoader  - Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
plugin activated: tinkerpop.hadoop
plugin activated: tinkerpop.spark
plugin activated: tinkerpop.utilities
plugin activated: janusgraph.imports
gremlin>

ここでGremlinという聞き慣れない名前が出ました。Gremlinとはグラフデータベース操作言語です。RMDBのSQLと似たようなものです。詳細な説明はこちらのサイトを参照してください。

5. GraphOfTheGodsをロードする

起動したGremlin Consoleに下記のコマンドを実行して、GraphOfTheGodsのデータをロードします。今回はGremlinをすぐに実行してデータ構造を理解するために、インデックス無しでデータをロードします。

gremlin> graph = JanusGraphFactory.open('conf/janusgraph-inmemory.properties')
==>standardjanusgraph[inmemory:[127.0.0.1]]
gremlin> GraphOfTheGodsFactory.loadWithoutMixedIndex(graph, true)
==>null
gremlin> g = graph.traversal()
==>graphtraversalsource[standardjanusgraph[inmemory:[127.0.0.1]], standard]
gremlin>

これでGraphOfTheGodsのデータがローカルで確認できるようになりました。

クエリを実行してみる

1. 簡単なクエリ

まずはGraphOfTheGodsのデータが正しくロードされたのか確認します。

gremlin> g.V().count()
04:19:21 WARN  org.janusgraph.graphdb.transaction.StandardJanusGraphTx  - Query requires iterating over all vertices [()]. For better performance, use indexes
==>12
gremlin>

g.V().count() とは、頂点(vertex)の数です。最初の図で言うと、赤丸の数と同じです。RMDBだと行みたいなものです。さらにデータを見てみましょう。

gremlin> g.V().values('name')
04:26:52 WARN  org.janusgraph.graphdb.transaction.StandardJanusGraphTx  - Query requires iterating over all vertices [()]. For better performance, use indexes
==>sky
==>hydra
==>cerberus
==>neptune
==>alcmene
==>jupiter
==>pluto
==>sea
==>saturn
==>hercules
==>nemean
==>tartarus
gremlin>

それぞれの頂点から name プロパティを取得しました。神やモンスターや場所の名前が一覧で出てきましたね。 より詳細に確認するならスキーマを見ると良いでしょう。

gremlin> mgmt = graph.openManagement()
==>org.janusgraph.graphdb.database.management.ManagementSystem@62b09715
gremlin> mgmt.printSchema()
==>------------------------------------------------------------------------------------------------
Vertex Label Name              | Partitioned | Static                                             |
---------------------------------------------------------------------------------------------------
titan                          | false       | false                                              |
location                       | false       | false                                              |
god                            | false       | false                                              |
demigod                        | false       | false                                              |
human                          | false       | false                                              |
monster                        | false       | false                                              |
---------------------------------------------------------------------------------------------------
Edge Label Name                | Directed    | Unidirected | Multiplicity                         |
---------------------------------------------------------------------------------------------------
father                         | true        | false       | MANY2ONE                             |
mother                         | true        | false       | MANY2ONE                             |
battled                        | true        | false       | MULTI                                |
lives                          | true        | false       | MULTI                                |
pet                            | true        | false       | MULTI                                |
brother                        | true        | false       | MULTI                                |
---------------------------------------------------------------------------------------------------
Property Key Name              | Cardinality | Data Type                                          |
---------------------------------------------------------------------------------------------------
name                           | SINGLE      | class java.lang.String                             |
age                            | SINGLE      | class java.lang.Integer                            |
time                           | SINGLE      | class java.lang.Integer                            |
reason                         | SINGLE      | class java.lang.String                             |
place                          | SINGLE      | class org.janusgraph.core.attribute.Geoshape       |
---------------------------------------------------------------------------------------------------
Vertex Index Name              | Type        | Unique    | Backing        | Key:           Status |
---------------------------------------------------------------------------------------------------
name                           | Composite   | true      | internalindex  | name:         ENABLED |
---------------------------------------------------------------------------------------------------
Edge Index (VCI) Name          | Type        | Unique    | Backing        | Key:           Status |
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
Relation Index                 | Type        | Direction | Sort Key       | Order    |     Status |
---------------------------------------------------------------------------------------------------
battlesByTime                  | battled     | BOTH      | time           | desc     |    ENABLED |
---------------------------------------------------------------------------------------------------

gremlin>

なんとなくデータの構造が見えてきますね。 いくつかの簡単なクエリで、データがロードされてることが確認できました。

2. 任意のデータ(vertex)だけ取り出す

もう少しクエリを実行してみます。

gremlin> g.V().has('name', 'jupiter').values('age')
==>5000
gremlin>

jupiter(ゼウス)の年齢を取得しました。5000歳です。今度はjupiterの頂点(vertex)そのものを取得してみます。

gremlin> jupiterV = g.V().has('name', 'jupiter').next()
==>v[4208]
gremlin> g.V(jupiterV).valueMap()
==>[name:[jupiter],age:[5000]]
gremlin>

少し複雑になってきました。 g.V().has('name', 'jupiter') はjupiterを指定して .next()jupiterV に入れました。このように変数へ代入するような書き方が、グラフDBでは一般的な書き方のようです。公式では、これを「エントリーポイントを指定する」と表現しています。

The typical pattern for accessing data in a graph database is to first locate the entry point into the graph using a graph index. That entry point is an element (or set of elements) — i.e. a vertex or edge. https://docs.janusgraph.org/getting-started/basic-usage/#global-graph-indices

3. 関係(edge)をたどる

グラフDBの強みであるデータ同士の関係をたどってみます。

gremlin> g.V(jupiterV).out('father').values('name')
==>saturn
gremlin> g.V(jupiterV).in('father').values('name')
==>hercules
gremlin> 

jupiter(ゼウス)を起点に考えます。jupiterの父はsaturn(サートゥルヌス)です。さらに、hercules(ヘラクレス)の父はjupiterです。上記の図で言うと、outin がjupiterに関係する矢印の向き(関係= edge)と対応しています。そして、saturnはherculesの祖父であり、herculesはsaturnの孫とも言えます。この関係をクエリで書くと以下のようになります。

gremlin> saturn = g.V().has('name', 'saturn').next()
==>v[4336]
gremlin> hercules = g.V(saturn).repeat(__.in('father')).times(2).next()
==>v[8432]
gremlin> g.V(hercules).valueMap()
==>[name:[hercules],age:[30]]
gremlin>

saturnを起点にして、孫のherculesのプロパティを取得して表示しました。

終わりに

チュートリアルをなぞっただけですが、これで自分のPCにGraphDBのデータベースを構築できました。興味のある方はローマ神話とGraphDBを学べるお得なチュートリアルなので是非トライしてみてください。最後に、Gremlin Consoleを閉じておきましょう。

gremlin> :exit

しかし、実際にサービスで利用するには、チュートリアルだけでは終われません。任意の初期データの投入や、各種クラウドサービスとの連携などが必要です。

次回はGraphOfTheGodsではなく、任意の初期データの投入してGremlin Consoleを起動して接続する方法を紹介します。

もし、このようなGraphDBに興味のある方は絶賛採用中なので、下記のブログも合わせて読んで応募してください!

developer.diverse-inc.com

🤝 恋愛を「友だちの繋がり」で技術的に支援するサービスのバックエンド開発に力を貸してください!

これはなに

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

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

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

HOP Backend
f:id:kurotyann:20210603115041p:plain

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

HOPの探すと繋がりの画面
f:id:kurotyann:20210603115848p:plain

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

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でも構いません。興味のある方、お待ちしています!