[レポート] Deep Dive on Amazon Neptune #reinvent #DAT403

DAT403 - Deep Dive on Amazon Neptuneに参加してきましたのでレポートをお届けします。

AWS re:Invent 2018

#イベントレポート

#Amazon Neptune

#AWS

武田隆志

2018.12.29

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

こんにちは。サービスグループの武田です。

DAT403 - Deep Dive on Amazon Neptune に参加してきましたのでレポートをお届けします。

なおセッションの動画はYouTubeからも視聴できます。

セッション概要

What can you do with Apache TinkerPop and Gremlin or RDF and SPARQL? How does Neptune provide multi-Availability Zone high availability? Learn about the features and details of Amazon's fully managed graph database service.

機械翻訳したものも掲載します。

Apache TinkerPopとGremlin、あるいはRDFとSPARQLで何ができますか？ Neptuneはマルチアベイラビリティゾーンの高可用性をどのように提供していますか？ Amazonのフルマネージドグラフデータベースサービスの機能と詳細について学びます。

アジェンダ

高密接データのアプリケーションを構築する
さまざまなタイプのグラフモデル
Amazon Neptuneの概要
高可用性とエンタープライズ機能の提供
Amazon Neptuneの始め方

高密接データのアプリケーションを構築する

グラフデータベースが必要なケース
- ノード（頂点）の関係をトラバース（走査）したい
主なアクセスパターン
- ソーシャルネットワーク
- レストランのレコメンデーション
- 小売向けの不正検出
- ナレッジグラフ
- 生活科学
- ネットワーク＆ITオペレーション

シンプルなソーシャルネットワークの例を考える
- BillはAliceとBobを知っている
- Bill、Bob、Daveはある製品を購入している
- Bob、Dave、Saraはあるスポーツに興味を持っている
このときトライアディック・クロージャー（Triadic closure）と呼ばれるテクニックを使うとSaraと製品を関連付けられる
- これがレコメンデーションアルゴリズムの基礎となる
右側も同じテクニックを使うことでAliceとBobを関連付け、レコメンデーションを作ることができる

さまざまなタイプのグラフモデル

ナレッジグラフを使用することで、ドメイン情報と異なるセットをリンクさせることができる
モナ・リザ
- レオナルド・ダ・ヴィンチが製作した
- ルーブル美術館に展示
- ワシントンのラ・ジョコンドについて
ルーブル美術館
- 美術館（博物館）
人間
- ボブはモナ・リザに興味がある
- ボブは1990年7月14日生まれ
- ボブとアリスは友人
- あとビル
パリ
- 都市
- ルーブル美術館がある
- エッフェル塔がある
エッフェル塔
- 場所
- アリスが訪れた
- ビルが訪れた
これらの基本的な情報を与えることでより洗練された質問が可能となる
- モナ・リザは誰が描いたのか？
- アリスがパリ滞在中に訪れるべき博物館は？
- ルーブル美術館にはどのような絵画があるか？

Amazon Neptuneの概要

リレーショナルデータベースを用いて高密接データのアプリケーションは作れるか
- 作ることはできるだろう。しかし欠点もある
- 不自然なグラフ問い合わせ
- 非効率なグラフ処理
- データ変更に柔軟性がないスキーマ
高密接データのアプローチの違い
- 関係モデルはビジネスプロセスを目的として構築される
- 関係に対する問い合わせへの回答を目的として構築される
グラフデータベースは効率的なストレージと高密接データのトラバースに最適化されている
主要なグラフモデルおよびフレームワーク
- Apache TinkerPop
  - PROPERTY GRAPH
  - Gremlin Traversal Language
- W3C Standard
  - RESOURCE DESCRIPTION FRAMEWORK（RDF）
  - SPARQL Query Language
- 両者の違いはエッジプロパティの構文に見られる
もっともよく知られているグラフベンチマークを例に見てみる
- Lehigh University Benchmark（LUBM）と呼ばれる
- 大学のシステムをシミュレート
- 教授と学生、受講コースなどを表す
そこで同じ大学の学士号を取得したすべての大学院生を見つける

Gremlinでクエリを書いた場合

SPARQLでクエリを書いた場合

既存のグラフデータベースの課題
- スケールの難しさ
- 高可用性を維持する難しさ
- 料金が高い
- オープンスタンダードに対する限定的なサポート
Amazon Neptuneは高スループットのフルマネージドなグラフデータベースとして設計された
- ミリ秒のレイテンシーで数十億の関係を照会する
- フルバックアップとリストアを備え、異なる3つのAZに6つのレプリカを作成する
- GremlinとSPARQLで強力なクエリを簡単に構築できる
- Apache TinkerPopとW3C RDFグラフモデルをサポート
Amazon Neptuneの高レベルアーキテクチャ
- Neptuneのコアは図の青い部分
- ハイパフォーマンスなグラフエンジンを備える
  - 耐久性と一貫性のあるACID特性を備える
- GremlinではHTTPおよびWebSocketのエンドポイントを提供する
- SPARQLではHTTPのエンドポイントを提供しバージョン1.1と互換性がある
- S3に保存したデータを高速にバルクロードできる

Neptuneのフルマネージドサービスについて
- コンソールから簡単に設定可能
- Multi-AZおよび高可用性
- 15リードレプリカのサポート
- RESTによる暗号化のサポート
- TLSによる通信時の暗号化のサポート
- バックアップとリストア、およびポイントインタイムリカバリ
セキュリティ
- VPCによる独立したネットワーク
  - セキュリティグループを使用したインバウンドの制御
- TLS 1.2を使用したHTTPS接続
- KMSを使用したRESTの暗号化
- IAMポリシーによるNeptuneリソース作成の保護
- IAMベース認証のアクセスコントロール
  - 各リクエストはAWS署名バージョン4で署名される
  - GremlinおよびSPARQLのライブラリ提供
Neptuneは、さまざまなプロダクトで使用されている

高可用性とエンタープライズ機能の提供

Neptuneの分散ストレージアーキテクチャ
- パフォーマンス、可用性、耐久性
- スケールアウトするレプリカアーキテクチャ
  - プライマリノードは通常書き込み専用
- 数百ノードにわたってストライピングされた10GB分割の共有ストレージ
- データは3AZにわたって6つにレプリケーションされる
- ホットスポットのリバランス、迅速なデータベースのリカバリ
- ストレージレイヤーに組み込まれたログアプリケーター
  - ログのみ送信
  - エンジンの作業量低下
  - ネットワークトラフィックの最小化

AZ+1 ^*1の障害を耐えるために行う6-wayレプリケーション
- 3つのAZにまたがる6つのコピー
- 6つ中4つの書き込みクォーラム、6つ中3つの読み込みクォーラム
- ディスク、ノード、ネットワーク、電源など多くの障害が発生する可能性
- 継続的な障害の監視
- P2Pゴシッピングおよびレプリケーションによる自動的な修復

なぜ6つのコピーが必要なのか
- AZの障害を許容するためには3つのAZにまたがったレプリケーションが必要
- 1つのAZに1つのコピーではいけないのか
  - AZ+1のノードに障害が起きた場合、クォーラムが機能しなくなる
- パフォーマンスにとっても重要
  - （クォーラムによって）最長のネットワーク遅延を隠せる
  - 読み取りは3/6のACKのみ
  - 書き込みは4/6のACKのみ

継続的なバックアップ
- 定期的に各セグメントのスナップショットを並行して取得する
  - REDOログを継続的にAmazon S3にストリーミングする
- パフォーマンスや可用性に影響を与えることなくバックアップを継続的に取得する
- リストア時に、適切なセグメントスナップショットとログストリームをストレージノードへ復旧する
- セグメントスナップショットへのログストリームの適用は並列かつ非同期で行われる

インスタントクラッシュリカバリ
- 伝統的なデータベース
  - 最後のチェックポイント以降のログを再実行する必要がある
  - 通常チェックポイントは5分ごと
  - しばしばシングルスレッドである
- Amazon Neptune
  - 通常の読み取りでストレージレイヤーのログも再実行される
  - 並列で、分散で、非同期である
  - 起動時に再実行しない

データベースバックトラック
- バックトラックにより、バックアップからリストアすることなくデータベースを特定時点に戻すことができる
  - 意図していない挿入や削除
  - 非破壊的であるため、正しい地点を見つけるまで複数回の巻き戻しが可能

簡素化されたストレージ管理
- ストレージはパフォーマンスに影響することなく、自動的に最大64TBまで拡張される（10GBずつ追加される）
- パフォーマンスに影響することなく、ユーザースナップショットを即座に作成

リードレプリカ
- パフォーマンス
  - アプリケーションは最大15個のリードレプリカにまたがって読み取りトラフィックをスケールアウトできる
- 低遅延のレプリケーション
  - 通常10ms未満
  - マスターがREDOログをレプリカに送信
  - キャッシュページにREDOを適用
  - 未キャッシュページは共有ストレージから取得
- 可用性
  - 障害が発生したデータベースノードは自動的に検出されて置き換えられる
  - プライマリに障害が発生した場合、レプリカに置き換えられる（通常60秒未満）
  - 強制フェイルオーバーによるプライマリのアップグレード

モニタリング
- AWS CloudTrail
  - すべてのNeptune API呼び出しログはS3バケットに保存される
- イベント通知
  - AWS CLIまたはAWS SDKによってSNSサブスクリプションが作成できる
- Amazon CloudWatch
  - さまざまなメトリクス

Amazon Neptuneの始め方

まとめ

前半はグラフデータベースをどのような領域に適用できるのか、後半はAmazon Neptuneがどのようなアーキテクチャによって高可用性などを確保しているのかといった内容でした。なんとなくレコメンデーションなどに使われているらしい程度の知識しかなかったのですが、不正検出などさまざまな用途に利用されていることも分かりました。レプリケーションについてはAmazon Auroraを知っていると理解も早いのでしょうか。この辺も合わせて理解できるとよさそうです。Neptuneはまだ勉強し始めたばかりですので、実際に触ってみながらいろいろと試していきたいです。