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

現地時間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)』の内容をレポートします。

セッション概要

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

セッションレポート

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

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

ナレッジグラフの例

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

• 「スポーツ」をフォローしている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はプレビュー版ではセキュリティの観点から許可していない

感想

Amazon Neptuneの概要から具体的な使い方のイメージ、そして裏側のアーキテクチャに至るまで、発表されたたばかりとは思えない充実の内容でした。また、後半のストレージ周りの説明を聴いていてまさか…とは思ったのですが、Auroraのストレージの仕組みを上手く流用していることにも関心しました。

Auroraのストレージエンジンに関する詳細は下記セッションレポートを参照下さい。

【レポート】DAT301: Deep-dive to Amazon Aurora #reinvent #dat301

早速プレビューを申し込んでいるので、触るのが楽しみです。