[レポート] DAT315 ：NIKEにおけるAmazon Neptuneを利用したソーシャルグラフの構築 #reinvent

はじめに

サーバーレス開発部＠大阪の岩田です。 この記事はre:Invent2018のDAT315 Building a Social Graph at Nike with Amazon Neptuneのレポートになります。

概要

以下が公式の概要となります。

In this session, learn how Nike stepped up its game on Nike’s own social network. Using the Amazon Neptune graph database, Nike is unlocking the possibility of world-class athletes and millions of their followers to have unique Nike experiences. We showcase Nike's journey of migrating more than 100 million users from Cassandra to Amazon Neptune, while remaining up and available 24/7.

NIKEにおけるAmazon Neptuneの事例を紹介するセッションです。 NIKEではソーシャルアプリのバックエンドにAmazon Neptuneを活用し、何百万人ものユーザーに対して24時間365日サービスを提供しています。 このセッションではバックエンドのデータストアをCassandraからAmazon Neptuneに移行した事例について詳しく紹介して頂きました。

スピーカー

• Andi Gutmans - GM, Amazon ElastiCache and Amazon Neptune
• Aditya Soni - Principal Engineer, Nike Inc.
• Marc Wangenheim - Senior Engineering Manager, Nike

レポート(冒頭)

Andi Gutmans氏からNeptuneとグラフDBに関する概要の紹介

• グラフDBの概要とユースケース
  • レコメンデーション検索
  • ソーシャルグラフの表現
• Amazon Neptuneの特徴
  • フルマネージド
  • クエリが高速
  • 簡単に使える

レポート(前半)

ここからNIKEの事例紹介

NIKEのアプリについて

簡単な紹介と求められる業務ドメインについて

FRIENDING

• 友人同士のつながりの管理
• 友人のレコメンデーション

INTERESTS

• なんのスポーツに興味があるか？ 例えばランニング、トレーニング、バスケ、サッカー、テニス
• どこのスポーツチームが好きか？　例えばNBA、NFL、サッカーチーム
• こういったユーザーの興味に応じてフィードをパーソナライズする

LINKING

• FaceBookなどの外部プロバイダと連携したログイン

アプリにおける具体的なユースケース

• 全てのデータはサーバーサイドで用意
• 友人の一覧取得(ページネート)
• 友人の一覧取得(サーバー間)
• リクエスタとユーザー一覧の間の関係性を取得
• 友人のレコメンデーション
• 同じ領域に興味を持っているユーザー一覧の取得
• 特定のユーザーが興味を持っている領域の一覧取得

Cassandraを利用していた頃のアーキテクチャ

• EC2にCassandraを導入してオートスケールさせる構成
• この頃からマイクロサービスなアーキテクチャ

Cassandraの課題

KVSなのでグラフモデルのドメインにフィットしない

• Cassandraはパーティションキーでアクセス
  • パフォーマンスは良いが、柔軟性が無い
  • もっと色々なアクセスパターンに対応したい
  • 集約系の処理に弱い
  • 別途EMRとSparkを使っていた

スケーリング

• 双方向 <-> 単方向
• 数千件レベル <-> 数百万件レベル
• 非マネージドサービス <-> AWSのマネージドサービス

メンテナンスが難しく、セキュリティパッチの適用などの管理コストが負荷に フルマネージドに移行したい。

AWS DATA LABを活用

• AWS DATA LABを利用して1週間かけてPOC
• 多くのスペシャリストのサポートが受けれてフィードバックも早い
• 新技術を採用したプロダクトの立ち上げにオススメ

レポート(後半)

ここからスピーカーが交代し、CassandraからNeptuneへのマイグレーションについての話

Cassandraのデータモデル

• KVSなのでJOINできない
• 色々なテーブルにいくつもクエリを発行して必要なデータを取得する必要がある。

Neptuneのモデル

• 全ドメインが1つのデータモデルで表現できる
• Cassandraでは複数のクエリが必要だった処理が1つのクエリで実現できる
• Cassandraではビジネスロジックがサービスレイヤーに実装されていた
• Neptuneでは全てのビジネスロジックがクエリレイヤに

コードサンプル

gremlinクエリの例とJava GLM

Neptuneのモニタリングについて

• マネージドサービスなのでCloudWatchと統合されている
• gremlin関連のメトリクスも取得できる
• Cassandraと比べてモニタリングが簡単に

アーキテクチャ

• NLB,Kinesis,Lambdaを活用
• 読み取り用のエンドポイントはクラスタを冗長化してNLBで振り分け
• 書き込みエンドポイントはKinesis->Lambda->Neptuneという経路でアクセス
  • プライマリが落ちていた場合、書き込みに失敗するが、LambdaのDLQに貯めることができる。

分析クエリ

• CassandraはSparkを使っていた
• Neptuneはリードレプリカやスナップショットの機能を活用することで、本番環境に負荷をかけずに分析ができる
• CloudFormationを使ってスナップショット取得〜分析環境の構築までを自動化している

マイグレーション時のデータロードについて

• Load用のエンドポイントからCSVを読み込む方式
  • CPU負荷が高いという問題が
• CassandraにもNeptuneにも二重に書き込む方式
  • Cassandra側のロールバックなど書き込み失敗のハンドリング難しい
• イベント処理
  • この方式を採用
  • 書き込みリクエストを一旦キューに入れ、キューからデータレイヤーに書き込む

カットオーバー

• カナリアデプロイを採用
  • Cassandraを使うV1のAPIに95%のトラフィックを振り分け、Neptuneを使うV2のAPIに残り5%のトラフィックを振り分けてカットオーバー
• V1、V2両方のAPIにキューを用意　平行運用中はバックグラウンドでCassandra->Neptuneの書き込みとNeptune->Cassandraの書き込みを行うことでV1へのロールバックを容易に

まとめ

Neptuneを使ったシステムのアーキテクチャについて突っ込んだ話を聞くことができて、非常に面白いセッションでした。 特にマイグレーションやカットオーバー時のアーキテクチャはNeptuneやグラフDBに限らず色々と応用が効きそうなので、システムのアーキテクチャを設計する際に参考にしていきたいと思います！