DynamoDBをグローバルテーブル構成にしたうえで、DynamoDB StreamsによるLambdaトリガーを実行してみた

疑問と検証結果

疑問：グローバルテーブル構成かつ、DynamoDBトリガーを有効にした場合、更新が同期・伝搬されるリージョン側でもトリガーが作動するのか？

結果：更新が同期・伝搬されるリージョン側でもトリガーが作動した。

検証環境の構成

構成概要

• DynamoDBを更新するためにAPI Gateway + LambdaでAPIを作成
• DynamoDBはグローバルテーブル構成にして、東京リージョンとバージニア北部リージョンで同期
• それぞれのリージョンのDynamoDBの更新をトリガーに実行されるLambda関数を作成

確認観点

• 片方のリージョンからのAPI実行(データ更新)で複数のリージョンのDynamoDBトリガーが実行されるか
• 複数リージョンに作成したAPIからのデータ更新が、それぞれ双方向に同期できるか

検証環境の作成

以下のステップで進める。

1. HTTP APIによるDynamoDB操作機能の作成（東京リージョン）
2. 作成したテーブルのDynamoDBStreamsとグローバルテーブル構成の有効化（東京リージョン）
3. DynamoDBStreamsをトリガーにする関数の作成（東京リージョン）
4. DynamoDBStreamsをトリガーにする関数の作成（バージニア北部リージョン）
5. HTTP APIによるDynamoDB操作機能の作成（バージニア北部リージョン）

1. HTTP APIによるDynamoDB操作機能の作成（東京リージョン）

このセクションはAWSのチュートリアルをベースに作成します。
そのため本稿ではポイントに絞って記載します。

1-1. （DynamoDB）インプットテーブルの作成

パーティションキーが「id」のテーブル「http-crud-tutorial-items」を作成します。
デーブル名とパーティションキー以外の設定は、この時点では特に不要です。

1-2. （Lambda）インプットテーブルの更新関数の作成

Lambda関数「http-crud-tutorial-function」を作成します。
実行ロールは"AWS ポリシーテンプレートから新しいロールを作成"を選択して、マイクロサービスを選択します。

チュートリアルのページにあるNode.jsのコード(index.mjs)をコピペして、デプロイしておきます。

1-3. （API Gateway）Lambda関数のHTTP API統合

API GatewayからHTTP API「http-crud-tutorial-api」を作成します。
以下のパスについてのルートを作成して、Lambda関数と紐づけ(統合)します。

• GET /items/{id}
• GET /items
• PUT /items
• DELETE /items/{id}
  

1-4. テスト

API GatewayからAPI実行URLを確認し、HTTP APIを実行します。

• データの追加

#リクエスト
curl -X "PUT" -H "Content-Type: application/json" \
  -d "{\"id\": \"123\", \"price\": 12345, \"name\": \"myitem\"}" \
  'https://hogehoge.execute-api.ap-northeast-1.amazonaws.com/items'
#レスポンスが返ってくる
"Put item 123" 

• データの取得

#リクエスト
curl -X "GET" 'https://hogehoge.execute-api.ap-northeast-1.amazonaws.com/items'
#レスポンスが返ってくる
[{"price":12345,"id":"123","name":"myitem"}]

2. 作成したテーブルのDynamoDBStreamsとグローバルテーブル構成の有効化（東京リージョン）

作成したDynamoDBのテーブルについて、少し設定を見てみます。

DynamoDB ストリームの設定状態の確認

DynamoDBのテーブルを選択し、「http-crud-tutorial-items」の"エクスポートおよびストリーム"のタブを選択します。
"DynamoDB ストリームの詳細"を確認すると、ストリームのステータスが「オフ」になっています。

DynamoDB ストリームを有効化させる必要がありますが、グローバルテーブルを構成する操作の中で有効にできるので、グローバルテーブルの設定をしてみます。

DynamoDB グローバルテーブルの設定

DynamoDBのテーブルを選択し、「http-crud-tutorial-items」の"グローバルテーブル"のタブを選択します。

レプリケーションリージョンに"バージニア北部"を選択して、レプリカを作成します。

DynamoDB グローバルテーブルとDynamoDB ストリームの設定状態の確認

しばらくすると"グローバルテーブル"のタブのレプリカに、レプリケーションリージョンがアクティブになっていることが確認できます。
なお、レプリケーションリージョンのリンクを選択すると、バージニア北部リージョンでもテーブルが作成されたこと、同じデータが格納されていることを確認できます。

また、"エクスポートおよびストリーム"のタブの"DynamoDB ストリームの詳細"を確認すると、ストリームが有効になり、「新旧タイプ」の表示タイプで設定されていることが確認できます。

3. DynamoDBStreamsをトリガーにする関数の作成（東京リージョン）

次はDynamoDBの更新をトリガーに実行されるLambdaを作成します。

3-1. （Lambda）関数の作成

Lambda関数「DynamoDBStreams-tutorial」を作成します。

セクション1と同様に、実行ロールは"AWS ポリシーテンプレートから新しいロールを作成"を選択して、マイクロサービスを選択します。 ★ 後の手順でロールに権限を追加します。 ★

実行されたことはCloudWatchLogsから確認できるため、コードはデフォルトのままでもよいですが、参考にさせていただいた記事から以下のようなコードを設定することにしました。

Node.js

export const handler = (event, context, callback) => {

    event.Records.forEach((record) => {
        console.log('イベント種別:', record.eventName);
        console.log('DynamoDB Record: %j', record.dynamodb);
    });
};

3-2. （IAM）Streamを受け取るためのロール設定

今回は
作成したLambda関数の"設定"タブからアクセス権限を選択して、先ほど作成した実行ロールのリンクを選択します。

遷移したIAMロールのページから「AWSLambdaMicroserviceExecutionRole」で始まる許可ポリシーを選択し、「編集」を選択します。
ポリシーエディタから以下のアクションを許可するように設定を修正します。

• "dynamodb:GetShardIterator"
• "dynamodb:GetRecords"
• "dynamodb:ListStreams"
• "dynamodb:DescribeStream"

3-3. （Lambda）DynamoDBをトリガーに設定

ページ上部の関数の概要に表示されている「トリガーの追加」を選択します。

トリガーにDynamoDBを選択し、セクション1で作成したテーブル「http-crud-tutorial-items」を選択してトリガーを設定します。

3-4. テスト

ここまでのトリガーの設定がうまくいっているか、一度テストしてみます。
セクション1で実施したデータの追加APIを実行します。
※IDはパーティションキーのため重複しない値を設定してください。

#リクエスト
curl -X "PUT" -H "Content-Type: application/json" \
  -d "{\"id\": \"456\", \"price\": 12345, \"name\": \"myitem\"}" \
  'https://hogehoge.execute-api.ap-northeast-1.amazonaws.com/items'
#レスポンスが返ってくる
"Put item 456" 

次に、DynamoDBトリガーで実行されるLambdaのログを確認するために、CloudWatchLogsに移動します。
セクション3で作成したLambda関数「DynamoDBStreams-tutorial」の"モニタリング"タブから、「CloudWatch ログを表示」を選択します。

ログストリームを選択してログを確認してみると、以下のようにAPIで追加した情報がログに記録されています。

4. DynamoDBStreamsをトリガーにする関数の作成（バージニア北部リージョン）

続いてバージニア北部リージョンでセクション3で作成した関数を作成してみます。

マネジメントコンソール右上からリージョンを変更して、同じ作業を実施します。

4-1. （Lambda）関数の作成

セクション3-1と同様です。
なお、セクション3と同じ実行ロールを転用すると、リージョンが違うためResource部分の修正が必要になります。

4-2. （IAM）Streamを受け取るためのロール設定

セクション3-1と同様です。

4-3. （Lambda）DynamoDBをトリガーに設定

セクション3-1と同様です。

4-4. テスト

セクション3-4と同様にAPIを実行し、DynamoDBを更新してみます。(nameの値を変えてます)

#リクエスト
curl -X "PUT" -H "Content-Type: application/json" \
  -d "{\"id\": \"789\", \"price\": 12345, \"name\": \"replitem\"}" \
  'https://hogehoge.execute-api.ap-northeast-1.amazonaws.com/items'
#レスポンスが返ってくる
"Put item 789"

同様にCloudWatchLogsを確認してみます。
まずはDynamoDBが直接更新された 東京リージョン側 を見てみると、セクション3と同様にLambdaが実行されたことが確認できました。

続いてDynamoDBの更新が伝搬された バージニア北部リージョン側 を見てみると、こちらもセクション3と同様にLambdaが実行されたことが確認できました。

5. HTTP APIによるDynamoDB操作機能の作成（バージニア北部リージョン）

最後に、データ更新をバージニア北部リージョン側で実施するためのAPIを作成します。
手順はセクション1と同様です。

5-1. （DynamoDB）インプットテーブルの作成

セクション2のグローバルテーブルの設定で作成されているので、追加で作成不要です。

5-2. （Lambda）インプットテーブルの更新関数の作成

セクション1-2と同様です。

5-3. （API Gateway）Lambda関数のHTTP API統合

セクション1-3と同様です。

5-4. テスト

バージニア北部リージョンのAPI GatewayからAPI実行URLを確認し、HTTP APIを実行します。

• データの取得

#リクエスト
curl -X "GET" 'https://hogehoge.execute-api.us-east-1.amazonaws.com/items'
#レスポンスが返ってくる。
# バージニア北部リージョンで取得(Lambda)を実行しても、
# 更新が同期されているため、これまでのテストで東京リージョンに追加したデータが表示される
[{"price":12345,"id":"456","name":"myitem"},{"price":12345,"id":"123","name":"myitem"},{"price":12345,"id":"789","name":"replitem"}]

• データの追加

#リクエスト
curl -X "PUT" -H "Content-Type: application/json" \
  -d "{\"id\": \"000\", \"price\": 12345, \"name\": \"secondlyitem\"}" \
  'https://hogehoge.execute-api.us-east-1.amazonaws.com/items'
#レスポンスが返ってくる
"Put item 000" 

合わせてDynamoDBトリガーのLambdaが実行されたか、CloudWatchLogsを確認してみます。
まずはDynamoDBが直接更新された バージニア北部リージョン側 、これまでと同様にLambdaが実行されたことが確認できました。

続いて今度はDynamoDBの更新が伝搬された 東京リージョン側 を見てみると、こちらも同様にLambdaが実行されたことが確認できました。

まとめ

• グローバルテーブル構成の場合、直接更新されたか・他リージョンの更新が反映されたかは問わずにDynamoDBトリガーが動くようでした。
• グローバルテーブルはグローバルなデータアクセスやリージョン障害対策に有効ですが、トリガーも設定する場合はイベントフィルターをかけるか、ロックなどの排他制御が必要になりそうですね。

参考