【新機能】グラフデータベースの Amazon Neptune に Serverless 構成が登場！

ウィスキー、シガー、パイプをこよなく愛する大栗です。

AWS SDK for PHP のアップデート内容を見ていたら Neptune に Serverless のキャパシティを設定するための属性が追加されていたので、Neptune に Serverless の構成なんて有ったかな？と思っていたのですが、[Engine Version 1.2.0.1](Engine Version 1.2.0.1)で新機能として紹介されていたので、内容を確認してみました。

• Amazon Neptune Serverless - Amazon Neptune
• Amazon Neptune Serverless is now generally available
• Introducing Amazon Neptune Serverless – A Fully Managed Graph Database that Adjusts Capacity for Your Workloads

Amazon Neptune Serverless

Amazon Neptune Serverless はオンデマンドのオートスケーリング構成で非常に大きな処理要求の増加にも対応するために、必要に応じて DB クラスタをスケールアップしたり、スケールダウンを行うものです。ワークロードをモニタリングしてキャパシティを自動的に調整します。

Amazon Neptune Serverless は様々なワークロードをサポートしており、要求が厳しく変化の大きいワークロードに適しています。データベースの使用が短時間に集中し、その後長期間に渡って軽い動きか動きが全く無い場合に非常に役立ちます。次のユースケースなどで特に役立ちます。

• 可変ワークロード
• マルチテナント ワークロード
• 新しいアプリケーション
• キャパシティ計画
• 開発とテスト

キャパシティのスケーリング

Amazon Neptune Serverless では Neptune Capacity Units (NCU) という単位でキャパシティが定義されます。NCU は、２ GiB のメモリ （RAM） と、関連する仮想プロセッサキャパシティ (vCPU) 及びネットワークで構成されます。最小キャパシティーユニットと最大キャパシティーユニットを定義して、その範囲内で負荷に応じ自動的なスケーリングがされます。最小キャパシティーユニットと最大キャパシティーユニットは 2.5〜128 NCU の範囲で 0.5 NCU 単位で定義できます。

リーダーインスタンスはフェイルオーバー優先順位が 0 か 1 の場合にはライターインスタンスと同時にスケーリングされます。これによりフェイルオーバーした時にライターのワークロードを迅速に引き継ぐための NCU を維持できます。フェイルオーバー優先順位が 2〜15 の場合はライターインスタンスと無関係にスケーリングします。

利用可能なリージョン

2022年10月27日現在では、以下のリージョンで Amazon Neptune Serverless が利用できます。

• 米国東部 (バージニア北部) : us-east-1
• 米国東部 (オハイオ) : us-east-2
• 米国西部 (北カリフォルニア) : us-west-1
• 米国西部 (オレゴン) : us-west-2
• 欧州 (アイルランド) : eu-west-1
• 欧州 (ロンドン) : eu-west-2
• アジアパシフィック (東京) : ap-northeast-1

料金

Amazon Neptune Serverless の料金は、以下の通りです。

制限

• 以前のエンジンバージョンでは使用できません : Amazon Neptune Serverless は Engine Version 1.2.0.1 以降で使用できます。
• オートスケーリングとの互換性がありません : オートスケーリングは Amazon Neptune Serverless では機能しません。

やってみる

ここでは東京リージョンで Amazon Neptune Serverless を起動してみます。

パラメータグループの作成

Engine Version 1.2 ではパラメータグループが以前のバージョンと異なるため新たにパラメータグループを作成しておきます¹。

DB Parameter Group の作成

まずは DB Parameter Group を作成します。パラメータグループのコンソールでCreate parameter groupをクリックします。

以下の内容を設定してCreateをクリックします。

DB Cluster Parameter Group の作成

次に DB Cluster Parameter Group を作成します。パラメータグループのコンソールでCreate parameter groupをクリックします。

以下の内容を設定してCreateをクリックします。

作成したクラスタパラメータグループをクリックします。

Edit parametersをクリックします。

監査ログを有効にするためneptune_enable_audit_logを1に変更してSave changesをクリックします。

クラスタの作成

データベースのコンソールでCreate databaseをクリックします。

以下の内容を設定します。エンジンのタイプをServerlessに設定すると、バージョンは対応しているNeptune 1.2.0.1.R1だけ出てきます。

以下の内容を設定します。設定内容はデフォルトの状態です。

以下の内容を設定します。設定内容はデフォルトの状態です。

追加の接続設定（Additional connectivity configuration）をクリックして中身を開き、以下の内容を設定します。

追加設定（Additional configuration）をクリックして中身を開き、以下の内容を設定します。

CloudWatch Logs へ出力するため、ログのエクスポートでAudit logをチェックします。

Create databaseをクリックします。

Neptune が起動します。サイズがdb.serverlessとなっている事がわかります。起動が完了するまでしばらく待ちます。

Neptune の各インスタンスが Available となったことを確認してアクセスしてみます。

Gremlin Console のインストール

Neptune にアクセスできる EC2 に Gremlin Console をインストールします。ここで使用する OS は Amazon Linux 2 を前提とします。

java-openjdk11 をインストールします。

$ sudo amazon-linux-extras install -y java-openjdk11
Installing java-11-openjdk
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
・
・
・
 65  lustre                   available    [ =stable ]
 66  php8.1                   available    [ =stable ]
$

JSON を操作する jq もインストールしておきます。

$ sudo yum install -y jq

インストールした Java 11 をデフォルトのランタイムとして設定します。

$ sudo /usr/sbin/alternatives --config java

There is 1 program that provides 'java'.

  Selection    Command
-----------------------------------------------
*+ 1           java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.16.0.8-1.amzn2.0.1.x86_64/bin/java)

Enter to keep the current selection[+], or type selection number: 1 # インストールした Java の番号である 1 を入力
$

Engine Version 1.2.0.1 がサポートしている Gremlin のバージョンである 3.5.2 をダウンロードします。

$ wget https://archive.apache.org/dist/tinkerpop/3.5.2/apache-tinkerpop-gremlin-console-3.5.2-bin.zip

ダウンロードしたファイルを解凍します。

$ unzip apache-tinkerpop-gremlin-console-3.5.2-bin.zip

ディレクトリを移動します。

$ cd apache-tinkerpop-gremlin-console-3.5.2

./conf/neptune-remote.yamlというファイルを作成して、接続情報を記述します。hostsには Neptune のエンドポイントを記述します。

$ vim ./conf/neptune-remote.yaml
$ cat ./conf/neptune-remote.yaml
hosts: [database-1-instance-1.xxxxxxxxxxxx.ap-northeast-1.neptune.amazonaws.com]
port: 8182
connectionPool: { enableSsl: true }
serializer: { className: org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1,
              config: { serializeResultToString: true }}

bin/gremlin.shを起動して接続できることを確認します。

$ bin/gremlin.sh
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/home/ec2-user/apache-tinkerpop-gremlin-console-3.5.2/lib/groovy-2.5.14-indy.jar) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Oct 27, 2022 1:39:43 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.

         \,,,/
         (o o)
-----oOOo-(3)-oOOo-----
plugin activated: tinkerpop.server
plugin activated: tinkerpop.utilities
plugin activated: tinkerpop.tinkergraph
gremlin>

負荷をかけてみる

まず Netpune Serverless の平常状態の CPU 負荷などを確認してみます。

CloudWatch で CPU 使用率のCPUUtilizationと NCU 使用率のCPUUtilizationを見てみます。NCU の下限は 2.5 ですが、 CPUUtilization は 1.95 程度になっているようです。

次にNeptune Serverless のスケーリングを確認するために、負荷をかけていきます。先程 Gremlin Console をインストールしましたが、HTTPS REST を直接叩いて負荷をかけます。

実行するクエリは最初の頂点を返します（データが入っていないため @value が空になっています）。

$ curl -X POST -s -d '{"gremlin":"g.V().limit(1)"}' https://database-1-instance-1.xxxxxxxxxxxx.ap-northeast-1.neptune.amazonaws.com:8182/gremlin | jq .
{
  "requestId": "98cec973-441e-4104-9e7e-91736ff56093",
  "status": {
    "message": "",
    "code": 200,
    "attributes": {
      "@type": "g:Map",
      "@value": []
    }
  },
  "result": {
    "data": {
      "@type": "g:List",
      "@value": []
    },
    "meta": {
      "@type": "g:Map",
      "@value": []
    }
  }
}

以下のように、先程のクエリを 5,000 回リクエストする test.sh を用意します。

test.sh

#! /bin/bash
for i in {1..5000} ; do
    curl -X POST -s -d '{"gremlin":"g.V().limit(1)"}' https://database-1-instance-1.xxxxxxxxxxxx.ap-northeast-1.neptune.amazonaws.com:8182/gremlin
done

test.sh を 10 並列で実行して Neptune に負荷をかけてみます。

$ for i in {1..10} ; do
>   (bash ./test10.sh ) &
> done

負荷をかけていた時の Neptune の CPU 使用率のCPUUtilization、NCU 使用率のCPUUtilization、Gremlin の秒間リクエスト数のGremlinRequestsPerSecを CloudWatch で見てみます。すると、秒間リクエスト数の増加に伴い CPU 使用率が増加します。CPU 負荷が NCU でキャップがかかってから 19 秒程度で NCU が 2 程度から 6 程度へ増加しています。

負荷が収まると 3 分毎に NCU が緩やかに低下しています。

Neptune ではフェイルオーバー優先順位が 0 か 1 のリーダーインスタンスはライターインスタンスと同時にスケールするので、レプリカ側の CPU 使用率と NCU 使用率を表示させてみます。ライターインスタンスの NCU が変更されてから概ね 5〜15 秒でリーダーインスタンスの NCU が追随しているのが分かります。

監査ログの確認

監査ログを CloudWatch Logs で確認してみます。

ロググループは/aws/neptune/database-1/auditです。

各 DB インスタンスごとにログストリームが作成されます。

ログの中身は、以下のようにアクセス状況等を確認できます。

さいごに

いよいよグラフデータベースにも Serverless の波が来ました。グラフデータベースのワークロードによると思いますが、長期間安定した負荷が続くことは少ないのではないかと思われるので、Neptune をご利用の方は Serverless 構成をご検討されると良いかと思います。

このまま Amazon ElastiCache や Amazon MemoryDB for Redis、Amazon DocumentDB も Serverless 化されないですかね。Amazon ElastiCache の自動スケーリングは 10 年待っているので、そろそろ対応お願いします、AWS さん！