クラウドへの移行: Blazegraph から Amazon Neptune への移行

グラフデータベースアプリケーションのライフスパン中、アプリケーション自体には基本的な要件、つまり、W3C 標準の SPARQL エンドポイントを機能させることのみが備わっている傾向があります。けれども、グラフデータベースが重要なビジネスアプリケーションに組み込まれるようになると、ビジネスと運用の両面からさらに多くのものが求められるようになります。重要なビジネスインフラストラクチャは、単に機能するだけでなく、可用性が高く、安全で、拡張可能で、費用対効果が優れていることが求められます。これらの要件により、オンプレミスまたはセルフホストソリューションから、Amazon Neptune などのフルマネージドグラフデータベースソリューションへの移行が求められます。

Neptune は、ビジネスクリティカルなグラフデータベースアプリケーションの構築と実行を容易にする、高速で信頼性の高い、フルマネージドグラフデータベースサービスです。Neptune は、数十億の関係を格納し、ミリ秒のレイテンシーでグラフをクエリするように最適化された専用の高性能グラフデータベースエンジンです。Neptune は、リードレプリカ、ポイントインタイムリカバリ、Amazon Simple Storage Service (Amazon S3) への継続的なバックアップ、およびアベイラビリティーゾーン間のレプリケーションにより、高可用性を実現するように設計されています。Neptune は、AWS Identity and Access Management (IAM) 認証、HTTPS 暗号化クライアント接続、および保管時の暗号化をサポートしており、安全です。Neptune は、開発とテストを対象とした低コストインスタンスを含む、さまざまなインスタンスタイプも提供しています。これにより、予測可能で低コストのマネージドインフラストラクチャがもたらされます。

現在のオンプレミスまたはセルフホストのグラフデータベースソリューションから Neptune への移行を選択する場合、この移行を実行するための最良の方法は何でしょうか?

この記事では、オープンソースの RDF トリプルストア Blazegraph から Neptune に次の手順を実行して移行する方法を説明します。

AWS インフラストラクチャをプロビジョニングします。まず、AWS CloudFormation テンプレートを使用して必要な AWS インフラストラクチャをプロビジョニングします。
Blazegraph からデータをエクスポートします。この記事では、Blazegraph からデータをエクスポートするための 2 つの主要な方法について説明します。それは、SPARQLCONSTRUCT クエリを使用するか、Blazegraph エクスポートユーティリティを使用する方法です。
Neptune にデータをインポートします。Neptune ワークベンチと Neptune バルクローダーを使用して、エクスポートしたデータファイルを Neptune にロードします。

この記事では、2 つのデータベース間を移行するときに注意する必要がある相違点についても説明します。この記事は Blazegraph からの移行を対象としていますが、このアプローチは通常、他の RDF トリプルストアデータベースからの移行にも適用できます。

アーキテクチャ

移行プロセスを説明する前に、この記事全体で使用されているアーキテクチャの基本的な組成構造を詳しく見てみましょう。このアーキテクチャは、次の 4 つの主要コンポーネントで構成されています。

Blazegraph インスタンス – インスタンスには移行するデータが含まれています。これは、セルフマネージド Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、オンプレミスサーバー、またはローカルインストールである可能性があります。
S3 バケット – データを Neptune にロードするようにバケットを設定します。
Neptune DB クラスター – Neptune DB クラスターには、少なくとも 1 つのライターインスタンスがあります (読み取りインスタンスはオプションです) 。
Neptune Workbench – ワークベンチを使用してバルクロードを実行し、結果を検証します。

次の図は、これらのリソースをまとめたもので、ソリューションのアーキテクチャを示しています。

AWS インフラストラクチャのプロビジョニング

AWS マネジメントコンソールまたは CLI を使用して必要な AWS インフラストラクチャを手動で構築することは可能ですが、この記事では CloudFormation テンプレートを使用して必要なインフラストラクチャの大部分を作成しています。

[Using an AWS CloudFormation Stack to Create a Neptune DB Cluster] ページに移動します。
目的のリージョンで [Launch Stack] を選択します。
必要なパラメータを設定します (スタック名と EC2SSHKeyPairName)。オプションのパラメータを設定して、移行プロセスを容易にすることもできます。

- [AttachBulkloadIAMRoleToNeptuneCluster] では、[true] を選択します。
  このパラメータを使用すると、適切な IAM ロールを作成してクラスターにアタッチし、データを一括で読み込むことができます。
- [NotebookInstanceType] では、使用するインスタンスタイプを選択します。
  このパラメータは、Neptune への一括ロードの実行と移行の検証に使用する Neptune ワークブックを作成します。

[Next] を選択します。
目的のスタックオプションを設定します。
[Next] を選択します。
オプションを確認し、両方のチェックボックスを選択して AWS CloudFormation に追加機能が必要になる場合があることを確認し、次の画像に示すように [Create stack] を選択します。
スタックの作成プロセスには数分かかる場合があります。
スタックが完了したら、Amazon S3 VPC エンドポイントを作成します。
これで、エンドポイントゲートウェイができました。次の図は、その設定を示しています。
エンドポイントを設定すると、AWS インフラストラクチャのプロビジョニングが完了し、Blazegraph からデータをエクスポートする準備が整います。

ソリューションの概要

Blazegraph からデータをエクスポートするプロセスには、次の 3 つのステップが含まれます。

CONSTRUCT または Blazegraph Export ユーティリティを使用してデータをエクスポートするステップ。
データを保存する S3 バケットを作成するステップ。
エクスポートしたファイルを S3 バケットにアップロードするステップ。

データのエクスポート

最初のステップは、Blazegraph からデータを Neptune バルクローダーと互換性のある形式でエクスポートすることです。サポートされている形式の詳細については、「RDF のデータの読み込み形式」を参照してください。

Blazegraph (トリプルまたはクワッド) へのデータの格納方法と、使用されている名前付きグラフの数に応じて、Blazegraph では、エクスポートプロセスを複数回実行し、複数のデータファイルを生成する必要がある場合があります。データがトリプルとして格納されている場合、名前付きグラフごとに 1 つのエクスポートを実行する必要があります。データがクワッドとして保存されている場合、データを N-Quads 形式でエクスポートするか、名前付きの各グラフをトリプル形式でエクスポートするかを選択できます。この記事では 1 つの名前空間を N-Quads としてエクスポートしますが、他の名前空間または目的のエクスポート形式に対してプロセスを繰り返すことができます。

Blazegraph からデータをエクスポートする方法として、お勧めの方法が 2 つあります。どちらを選択するかは、移行中にアプリケーションをオンラインで使用できるようにする必要があるかどうかによって異なります。

オンラインにする必要がある場合は、SPARQL CONSTRUCT クエリを使用することをお勧めします。このオプションを使用するには、アクセス可能な SPARQL エンドポイントで Blazegraph インスタンスをインストール、設定、および実行する必要があります。

アプリケーションをオンラインにする必要がない場合は、BlazeGraph エクスポートユーティリティを使用することをお勧めします。このオプションでは、Blazegraph をダウンロードする必要があり、データファイルと設定ファイルにアクセスできるようにする必要がありますが、サーバーが稼働中である必要はありません。

SPARQL CONSTRUCT クエリ

SPARQL CONSTRUCT クエリは、指定されたクエリテンプレートに一致する RDF グラフを返す SPARQL の機能です。このユースケースでは、次のクエリを使用して、一度に 1 つの名前空間でデータをエクスポートするためにそれを使用します。

CONSTRUCT WHERE { hint:Query hint:analytic "true" . hint:Query hint:constructDistinctSPO "false" . ?s ?p ?o }

このデータをエクスポートするためのさまざまな RDF ツールが存在しますが、このクエリを実行する最も簡単な方法は、Blazegraph によって提供されるREST API エンドポイントを使用することです。次のスクリプトは、Python (3.6 以降) スクリプトを使用してデータを N-Quads としてエクスポートする方法を示しています。

import requests

# Configure the URL here: e.g. http://localhost:9999/sparql
url = "http://localhost:9999/sparql"
payload = {'query': 'CONSTRUCT WHERE { hint:Query hint:analytic "true" . hint:Query hint:constructDistinctSPO "false" . ?s ?p ?o }'}
# Set the export format to be n-quads
headers = {
'Accept': 'text/x-nquads'
}
# Run the http request
response = requests.request("POST", url, headers=headers, data = payload, files = [])
#open the file in write mode, write the results, and close the file handler
f = open("export.nq", "w") 
f.write(response.text)
f.close()

データがトリプルとして格納されている場合、「Accept」ヘッダーパラメータを変更して、GitHub リポジトリで指定された値を使用して適切な形式 (N-Triples、RDF/XML、または Turtle) でデータをエクスポートする必要があります。

REST API を使用してこのエクスポートを実行することは、データをエクスポートする 1 つの方法ですが、この追加のクエリオーバーヘッドを処理するには、稼働中のサーバーと十分なサーバーリソースが必要です。これは常に可能とは限りません。データのオフラインコピーでエクスポートを実行するにはどうすればよいでしょうか?

このようなユースケースでは、Blazegraph エクスポートユーティリティを使用してデータをエクスポートできます。

Blazegraph エクスポートユーティリティ

Blazegraph には、データをエクスポートするためのユーティリティメソッド、ExportKB クラスが含まれています。このユーティリティは、Blazegraph からのデータのエクスポートを促進しますが、前の方法とは異なり、エクスポートの実行中はサーバーをオフラインにする必要があります。このため、移行中にアプリケーションをオフラインにできる場合や、データのバックアップから移行を行う場合に最適な方法です。

Blazegraph がインストールされているが実行されていないマシンから Java コマンドラインを介してユーティリティを実行します。このコマンドを実行する最も簡単な方法は、GitHub にある最新の blazegraph.jar リリースをダウンロードすることです。このコマンドを実行するには、次のパラメータが必要になります。

log4j.primary.configuration – log4j プロパティファイルの場所。
log4j.configuration – log4j プロパティファイルの場所。
output – エクスポートされたデータの出力ディレクトリ。ファイルは、ナレッジベースごとに名前が付けられたサブディレクトリに tar.gz として配置されます。
format – 必要な出力フォーマットと、RWStore.properties ファイルの場所。トリプルを使用している場合は、-format パラメータを N-Triples、Turtle、または RDF/XML に変更する必要があります。

たとえば、Blazegraph ジャーナルファイルとプロパティファイルがある場合、次のコードを使ってデータを N-Quads としてエクスポートします。

java -cp blazegraph.jar \
       com.bigdata.rdf.sail.ExportKB \
       -outdir ~/temp/ \
       -format N-Quads \
       ./RWStore.properties

正常に完了すると、次のコードのようなメッセージが表示されます。

Exporting kb as N-Quads on /home/ec2-user/temp/kb
Effective output directory: /home/ec2-user/temp/kb
Writing /home/ec2-user/temp/kb/kb.properties
Writing /home/ec2-user/temp/kb/data.nq.gz
Done

どのオプションを選択しても、Blazegraph から Neptune と互換性のある形式でデータを正常にエクスポートできます。これで、データファイルを Amazon S3 に移行して、一括ロードの準備をすることができます。

S3 バケットの作成

Blazegraph からデータをエクスポートしたら、次のステップは新しい S3 バケットを作成することです。このバケットは、Neptune バルクローダーが使用できるように Blazegraph からエクスポートされたデータファイルを保持します。Neptune バルクローダーはロード中にデータへの低レイテンシーアクセスを必要とするため、このバケットはターゲットの Neptune インスタンスと同じリージョンに配置する必要があります。S3 バケットの場所以外に、特定の追加設定は必要ありません。

バケットはさまざまな方法で作成できます。

Amazon S3 コンソールで – 手順については、「バケットの作成」を参照してください。
AWS CLI 経由 – 手順については、「AWS CLI で高レベル (s3) コマンドを使用する」を参照してください。

プログラムによる AWS SDK の使用 – 次のコードは、Python boto3 SDK を使用して S3 バケットを作成します。

import boto3

region = '<insert region name>'
bucket_name='<insert bucket name>'
s3_client = boto3.client('s3', region_name=region)
location = {'LocationConstraint': region}
s3_client.create_bucket(Bucket=bucket_name, CreateBucketConfiguration=location)

新しく作成した S3 バケットの場所を使用して、データを Neptune に一括ロードします。

Amazon S3 へのデータファイルのアップロード

次のステップは、エクスポート先の場所からこの S3 バケットにデータファイルをアップロードすることです。バケットの作成と同様に、次の方法でこれを行うことができます。

Amazon S3 コンソールで – 手順については、「バケットへのオブジェクトのアップロード」を参照してください。
AWS CLI 経由 – 手順については、「AWS CLI で高レベル (s3) コマンドを使用する」を参照してください。

プログラムで – 次のコードを参照してください。

import boto3

region = '<insert region name>'
bucket_name='<insert bucket name>'
s3 = boto3.resource('s3')
s3.meta.client.upload_file('export.nq', bucket_name, 'export.nq')

このサンプルコードは単一のファイルのみをロードしますが、複数のファイルをエクスポートした場合、各ファイルをこの S3 バケットにアップロードする必要があります。

S3 バケットにすべてのファイルをロードしたら、移行の最後のタスクであるデータを Neptune にインポートする準備が整います。

Neptune へのデータのインポート

Blazegraph からデータをエクスポートし、Amazon S3 経由で利用できるようにしたので、次のステップはデータを Neptune にインポートすることです。Neptune には、SPARQL を使用してロード操作を実行するよりも速く、より少ないオーバーヘッドでデータをロードするバルクローダーがあります。バルクローダープロセスは、loader endpoint API の呼び出しによって開始され、特定した S3 バケットに格納されているデータを Neptune にロードします。この読み込みプロセスは、次の 3 つのステップで行われます。

Neptune の一括ロード
データの読み込み
データの検証

次の図は、AWS インフラストラクチャでこれらの手順を実行する方法を示しています。

Neptune の一括ロードの実行

インポートプロセスを開始するには、バルクロードを開始するよう Neptune にリクエストします。これはローダー REST エンドポイントを直接呼び出すことで可能ですが、ターゲットの Neptune インスタンスが実行されるプライベート VPC にアクセスできる必要があります。Bastion ホストをセットアップし、そのマシンに SSH で接続して cURL コマンドを実行することもできますが、Neptune Workbench を使う方が簡単です。

Neptune Workbench は、Neptune 固有のノートブックmagics がインストールされた、Amazon SageMaker ノートブックである事前設定された Jupyter ノートブックです。マジックにより、クラスターステータスのチェック、SPARQL と Gremlin トラバーサルの実行、一括ロード操作の実行など、一般的な Neptune の相互作用が簡素化されます。

バルクロードプロセスを開始するには、％load magic を使用します。これは、Neptune ローダー API を実行するためのインターフェイスを提供します。

Neptune コンソールで、[Notebooks] を選択します。
[aws-neptune-blazegraph-to-neptune] を選択します。
[Open notebook] を選択します。
次の画像に示すように、開いた後、Jupyter ノートブックの実行中のインスタンスにリダイレクトされます。
ここから、既存のノートブックを選択するか、Python 3 カーネルを使用して新しいノートブックを作成できます。
開いているノートブックでセルを開き、「％load」と入力して、セルを実行します。
次に、バルクローダーのパラメータを設定する必要があります。
[Source] には、ソースファイルの場所を入力します (s3:// {bucket_name}/{file_name}) 。
[Format] では、適切なフォーマットを選択します。この例では、[nquads] です。
[Load ARN] には、IAMBulkLoad の ARN を入力します (この情報は IAM コンソールの [ロール] にあります) 。
[Submit] を選択します。

結果には、リクエストのステータスが含まれます。一括ロードは長時間実行されるプロセスです。この応答は、ロードが完了したことを意味するのではなく、ロードを開始したことを意味します。このステータスは定期的に更新され、ジョブが完了するまで最新の読み込みジョブのステータスが示されます。ロードが完了すると、ジョブステータスの通知が届きます。

ロードジョブが正常に完了すると、データが Neptune にロードされ、インポートプロセスの最後のステップであるデータ移行の検証に進む準備が整います。

データの読み込みの検証

他のデータ移行と同様に、データが正しく移行されたことを検証する方法はいくつかあります。これらの方法は、移行するデータ、移行に必要な信頼レベル、特定のドメインで最も重要なものによる傾向があります。ほとんどの場合、検証作業には、移行前と移行後のデータ値を比較するクエリを実行する作業が含まれます。

これを簡単にするために、Neptune Workbench ノートブックには、Neptune クラスターに対する SPARQL クエリの実行を簡素化するマジック (%% sparql) があります。次のコードを参照してください。

%%sparql

SELECT * WHERE {
	?s ?p ?o
} LIMIT 10

この Neptune 固有のマジックは、関連する Neptune インスタンスに対して SPARQL クエリを実行し、結果を表形式で返します。

Blazegraph から Neptune への互換性

調査する必要がある最後の事柄は、Blazegraph と Neptune の違いにより、アプリケーションを変更する必要があるかという点です。幸い、Blazegraph と Neptune はどちらも SPARQL 1.1 と互換性があります。つまり、アプリケーション設定を変更して新しい Neptune SPARQL エンドポイントを指すようにすれば、すべてが機能するはずです。

ただし、他のデータベース移行と同様に、Blazegraph と Neptune の実装にはいくつかの違いがあり、移行する能力に影響を与える可能性があります。以下の大きな違いにより、移行プロセスの一部として、クエリかアプリケーションアーキテクチャへの変更、またはその両方の変更が必要になります。

全文検索 – Blazegraph では、Apache Solr との統合により、内部全文検索または外部全文検索機能を使用できます。これらの機能のいずれかを使用する場合は、Neptune がサポートする全文検索機能の最新の更新情報を入手してください。詳細については、「Amazon Elasticsearch Service を使用した Amazon Neptune 全文検索」を参照してください。
クエリヒント – Blazegraph と Neptune はどちらも、クエリヒントの概念を使用して SPARQL を拡張します。移行中に、使用するクエリヒントを移行する必要があります。Neptune がサポートする最新のクエリヒントの詳細については、「SPARQL クエリヒント」を参照してください。
推論 – Blazegraph は設定可能なオプションとしてトリプルモード推論をサポートしていますが、クワッドモードでは推論はサポートされていません。ユースケースに推論が必要な場合は、フォワードチェーンオプションが最適かもしれません。AWS は、推論のユースケースに関する情報を収集しています。情報をお寄せいただける場合は、コメントを残すか、Amazon Neptune ディスカッションフォーラムから Neptune チームにご連絡ください。
地理空間検索 – Blazegraph は、地理空間サポートを可能にする名前空間の設定をサポートしています。Blazegraph でこの機能を使用する場合は、Neptune 内の代替手段を検討する必要があります。Amazon Neptune ディスカッションフォーラムで Neptune チームにご連絡ください。
マルチテナンシー – Blazegraph は、1 つのデータベース内でマルチテナンシーをサポートしています。Neptune では、名前付きグラフにデータを格納し、SPARQL クエリに USING NAMED 句を使用するか、テナントごとに個別のデータベースクラスターを作成することにより、マルチテナンシーがサポートされます。
フェデレーション – Neptune は現在、プライベート VPC 内、VPC 全体、外部インターネットエンドポイントなど、Neptune インスタンスにアクセスできる場所への SPARQL 1.1 フェデレーションをサポートしています。特定のセットアップと必要なフェデレーションエンドポイントによっては、追加のネットワーク設定が必要になる場合があります。
Blazegraph 標準拡張 – Blazegraph には、SPARQL および REST API 標準の両方に対する複数の拡張が含まれていました。Neptune は標準仕様とのみ互換性があるため、拡張機能の使用を移行する必要があります。

ただし、Neptune には、次のように、Blazegraph にはない追加機能がいくつかあります。

高可用性とスケーラビリティ – Neptune はすべてのデータを複数のアベイラビリティーゾーンに保存して、データ損失を防ぎます。Neptune はまた、データベーストラフィックを処理するために、15 個のリードレプリカまで簡単にスケールアップおよびスケールダウンします。
自動バックアップと復元 – Neptune では、バックアップ保持期間が定義された自動バックアップが行えるように設定されています。
モニタリング – Neptune は、さまざまな運用およびパフォーマンスメトリクスを Amazon Cloudwatch に公開しています。詳細については、「Amazon CloudWatch を使用した Neptune のモニタリング」を参照してください。
安全性 – Neptune は、転送時と保存時の両方でデータを暗号化するように設定されています。Neptune はまた、AWS Key Management Service (AWS KMS) と統合して暗号化キーのアクセス制御を行い、IAM と統合して、リクエストの Signature Version 4 署名によるユーザー認証と承認を行っています。
コスト管理 – 固定費用がかかるセルフマネージドインスタンスや EC2 インスタンスとは異なり、Neptune は、開発とテストのワークロード用の小規模な低コストオプションを含むさまざまなインスタンスサイズを提供することで、コスト管理を可能にしています。さらに、最大 7 日間、Neptune インスタンスを停止できます。その間、データベースインスタンスの時間は課金されません。
ストリーム – Neptune Streams は、ダウンストリームシステムによる消費のため、グラフに対して行われた変更の重複排除ストリームをキャプチャすることで、他のシステムの統合を簡素化します。

まとめ

この記事では、オンプレミスまたは自己ホスト型の Blazegraph インスタンスからフルマネージドの Neptune データベースに移行するプロセスを詳しく見ました。Neptune への移行は、開発の観点から多くのアプリケーションの要件を満たすだけでなく、ビジネスに不可欠なアプリケーションの運用ビジネス要件も満たします。さらに、この移行により、コストの最適化、ネイティブクラウドツールとの統合の改善、運用上の負担の軽減など、多くの利点がもたらされます。

この記事を読んで、自信をもって移行を開始できるようになればと願っています。ご質問、コメント、その他のフィードバックがある場合は、Amazon アカウントマネージャーに、または Amazon Neptune ディスカッションフォーラムからいつでもお問い合わせいただけます。

著者について

Dave Bechberger は Amazon Neptune チームのシニアグラフアーキテクトです。彼は、長年お客様に協力してきた経験を活かして、グラフデータベースで支えられたアプリケーションを構築し、インスピレーションを受けて Manning の「Graph Databases in Action」を共同執筆しました。

Amazon Web Services ブログ