【レポート】Deep Dive：Amazon Neptune #reinvent #DAT318

AWS re:Invent 2017

#データベース

#アーキテクチャ

#レポート

#AWS

甲木洋介

2017.12.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

現地時間2017年11月27日(月)〜2017年12月01日(金)の計5日間に渡り行われている『AWS re:Invent 2017』。

AWS re:Invnet 2017｜AWS

当エントリでは『DAT318 - Deep dive on Amazon Neptune(Deep Dive：Amazon Neptune)』の内容をレポートします。

セッション概要

セッション登壇者と概要は以下の通りです。

スピーカー：
Bruce McGaughy - Senior Software Development Manager, Amazon
Brad Bebee - Principal PM

セッション概要：
Amazon Neptune is a fully managed graph database service which has been built ground up for handling rich highly connected data. Graph databases have diverse use cases across multiple industries; examples include recommendation engines, knowledge graphs, fraud detection, social networks, network management and life sciences. Amazon Neptune is open and flexible with support for Apache TinkerPop and RDF/SPARQL standards. Under the hood Neptune uses the same foundational building blocks as Amazon Aurora which gives it high performance, availability and durability. In this session, we will do a deep dive into capabilities, performance and key innovations in Amazon Neptune.

(訳)Amazon Neptuneは高度に接続された豊富なデータを処理するために構築された、完全に管理されたグラフデータベースサービスです。グラフデータベースには、複数の業界でさまざまなユースケースがあります。例としては、推奨エンジン、知識グラフ、詐欺検出、ソーシャルネットワーク、ネットワーク管理、ライフサイエンスなどがあります。 Amazon NeptuneはApache TinkerPopおよびRDF/SPARQL標準をサポートしています。詳しく見てみると、Neptuneは高いパフォーマンス、可用性、耐久性を提供するAmazon Auroraと同じ基本的なビルディングブロックを使用します。このセッションでは、Amazon Neptuneの機能、パフォーマンス、重要な革新について深く掘り下げて説明します。

セッションレポート

高度に接続されたデータにアプリケーションを構築する

「高度に接続されたデータ」とは
- ソーシャルネットワークにおけるユーザの関連性情報(誰と誰が何で繋がっているか)
- レストラン利用における好みの検出(ユーザが好むジャンル、店舗)
- 小売における不正利用の検出(支払いしたのは正しいユーザか)
- その他ナレッジグラフやライフサイエンス等

ナレッジグラフの例

関係に基づくレコメンデーションの仕組み

「スポーツ」をフォローしている3人の人がいる
その内2人が製品を購入したので、残りの1人も製品を購入するかも知れない

Thomson ReutersがNeptuneのプレビューに参加している

当社の顧客はますますグローバルな税制と規制の複雑なウェブをナビゲートする必要があります。 4大クライアントの洗練された企業構造をモデル化し、エンドツーエンドの税務ソリューションを提供するアプローチが必要です。私たちはプラットフォームにマイクロサービスアーキテクチャを採用し、Amazon Neptuneをグラフベースのシステムとして活用し、データ内のリンクをすばやく作成し始めています。

Thomson Reuters Tax＆Accounting CTO、Tim Vanderham

RDBを使って、高度に接続されたデータを持つアプリケーションを開発する難しさ

(SQLは)グラフデータの問合せが不自然
処理効率が悪い
- 大量のネスト結合のクエリは非常に複雑になる
- RDBとグラフデータベースは異なるI/O要件を持っている
(スキーマ定義が厳密なので)データ変更に柔軟性がない
RDBはビジネスプロセスを管理する目的に対して、高度に接続されたデータはリレーションシップの回答を得るために作る
- 誰がどのようなスキルを持っているのか？
- どの製品が誰によって作られたのか？等

「グラフデータベースは、高度に接続されたデータを簡単かつ簡潔に扱えるものである」

主要なグラフモデルとフレームワーク

プロパティグラフ
- ノードとノードのプロパティとエッジとエッジプロパティから成り立つ
- Apache TinkerPop
- Gremlinグラフ探索言語
RDF(Resource Description Framework)
- W3C標準
- SPARQL問合せ言語

現行グラフデータベースの難しさ

スケールしにくい
- データ量の増加に伴い性能が落ちる
高可用性を維持しにくい
- EC2インスタンス上に構成したクラスタでも維持は難しい
高価
- オープンソース版で始めても商用版移行時にライセンスが発生する
オープンスタンダード対応が限定的

Amazon Neptuneとは

フルマネージドのグラフデータベース
高速
- 100万のリレーションへのクエリをミリ秒のレイテンシで処理
高信頼性
- フルバックアップやリストアに3つのアベイラビリティゾーン(AZ)にまたがる6つのレプリカを使用
簡単
- GremlinやSPARQLを使用して強力なクエリを簡単に実行
オープン
- Apache TinkerPopやRDFグラフモデルをサポート

ユーザとはTinkerPop/GremlinもしくはRDF/SPARQLで対話
本体は高性能なグラフエンジンを搭載
S3からのバルクロードAPIを提供
ストレージは高可用性を担保する仕組みで動作

グラフの種類とクエリの方法

プロパティグラフ

プロパティグラフは、それぞれのプロパティ(キー/値のペア)を持つ頂点およびエッジのセット
- 頂点はエンティティ/ドメインを表す
- エッジは方向性関係を表す
- 各頂点とエッジには一意の識別子がある
- 頂点とエッジはプロパティを持つことができる
- プロパティは頂点とエッジに関する非リレーショナル情報を表す
プロパティグラフの操作には、Apache TinkerPopを使用する
- TinkerPopは、プロパティグラフの為のオープンソースフレームワーク
- Gremlinは、グラフ探索に使用する言語
Amazon Neptuneは、TinkerPop Gremlin 3.3.0(2017年8月リリース)に完全互換した最適な実行エンジンを提供

TinkerPopグラフ作成の例

Neptuneに接続し、Javaから操作

RDFグラフ

RDFグラフは、主語、述語、および目的語の集合(トリプル)として記述される
- 国際化リソース識別子（IRI）は、主語を一意に識別する
- 目的語は、IRIかリテラルで表現される
- RDFのリテラルはプロパティのようなもので、XML形式をサポートする
- 目的語はIRIの場合は、グラフ内にエッジが作成される

RDFグラフの例

リレーショナルモデルと比較するとシンプルに表現できる

問合せの比較

いずれも「Echoを購入した会社の名前」を求めている

SQLの例

SPARQLによる問合せ

Gremlinの場合

プロパティグラフとApache TinkerPopの「友人レコメンド」サンプル

TerryはBillと友人
SarahもBillと友人
TerryからSarahを見つける

最初にグラフの中からTerryを見つける(Terryは'user'に代入)
Terryの友人('friends')を見つけ、その友人を求める('FRIENDS')
友人('FRIENDS')達の内、Terry('user')でなく、Terryの友人('friends')でない(neq()はNot Equalを表す)人を検索する
結果として、Sarahが抽出されることになる

RDFナレッジグラフサンプル

URIをグローバルな一意識別子として使用

「NetflixはUSAの企業である」を表現
Netflixの情報は、Thomson Reutersが提供する公開IDデータセット(PermID)を使用
USAの情報は、米国の地理空間機関によって発行されている情報(geonames)を使用
いずれも、情報に対しての一意識別子(URI)として機能
リテラル(図下"Netflix Inc"や電話番号"13026587581"、ISO3166国コード"US"など)は
グラフの中に埋もれていて、外に出るエッジを持たない
RDFは文字列他XMLで使用できるデータ型(bool, integer, dates等)をサポートしている
RDFグラフにおける各エッジは主語、述語、および目的語の集合(トリプル)として表現される
URIは、エッジの両端において主語と目的語の両方に使用される

URIを使うことで、異なるデータセットを横断して接続することが可能になる
- Wikipediaと米国地理空間機関によって発行されている情報(geonames)をつなぐ、等

SPARQLによるRDFの問合せ

URI https://permid.org/1-4295902158(Netflix社のPermID) に対する企業名を問い合わせる例
求めたい値を変数(先頭が?の文字)として設定する

URI https://permid.org/1-4295902158(Netflix社のPermID) に対するプロパティとノードを問い合わせる例

Netflix IncのURIと電話番号を問い合わせる例

Amazon Neptuneのフルマネージドなエンタープライズ対応機能の背景

Amazon Neptuneが持つ利点

管理コンソールから簡単に設定できる
マルチAZの高可用性を提供する
最大15のリードレプリカをサポート
データ保管時の暗号化サポート
データ転送時の暗号化サポート(TLS)
バックアップ、リストア、ポイントインタイムリカバリが可能

NeptuneのエンドポイントはVPC内に配置する
2つの異なるAZの2つのサブネットで展開する
クラスタボリュームは常に3つのAZにまたがり、耐久性のあるストレージを提供する

"歴戦の"クラウドネイティブストレージエンジン
- データは3AZの6箇所にレプリケーション
- データはAmazon S3へバックアップ
- 修理の為のノードとディスクの常時監視
- 10GBセグメント単位で修理またはホットスポットの再調整
- 読み取り/書き込みレイテンシ耐性のための定足数システム
- クォーラムメンバーシップの変更によって書き込み速度が低下しない
- ストレージサイズは64TBまで自動拡張
その他の機能や特徴(残りの説明とQAから)
- フェイルオーバー時間は一般的に30秒以内
- バックグランドで継続的にかつパラレルにバックアップ取得
- 10GBのストレージノードに蓄積された履歴範囲で高速なオンラインポイントインタイムリカバリ
- ヘッドノードによるバッファ機能あり
- 長大な問い合わせに対する内部的なタイムアウト制御機構あり
- SPARQL Federationはプレビュー版ではセキュリティの観点から許可していない