はじめに

こんにちは、アプリケーションチームの辻です。

今回、 AWS の様々なサービス・機能を利用して、分析用データの収集基盤のプロトタイプを作ってみました。
その中で、 Amazon DynamoDB(以下、DynamoDB) の Amazon S3 へのエクスポートと Amazon S3(以下、S3) のレプリケーションという機能を使用してみたので、学んだことを備忘録として残したいと思います。

はじめに
分析用データの収集基盤 - 概要
DynamoDB の S3 へのエクスポート
S3 のレプリケーション
おわりに

分析用データの収集基盤 - 概要

分析したいデータが格納されている本番用ストレージを直接参照してデータ分析するのは、検索による負荷やオペミスによるデータ削除などが懸念されます。
そこで、負荷をかけずに本番用ストレージからデータを取得して、分析用 AWS アカウントにデータを連携するアーキテクチャを考えてみました。

詳細は後ほど説明しますが、DynamoDB の S3 へのエクスポートを利用することで、DynamoDB に負荷をかけずにデータ取得を行ってます。
また、本番用AWSアカウントへの影響を最小限にするために、S3 のレプリケーションを利用して、収集したデータを別AWSアカウントにレプリケーションしてます。
こうすることで、検索による負荷やオペミスによるデータ削除などの懸念を払拭しました。

今回は触れませんが、分析用 AWS アカウントの S3 には Athena を利用してデータ検索しようと考えてます。

それでは、早速ですが「DynamoDB の S3 へのエクスポート」と「S3 のレプリケーション」についての説明に入ります。

DynamoDB の S3 へのエクスポート

DynamoDB テーブルから S3 バケットにデータをエクスポートする機能です。

この機能の素晴らしいところは、読み込みキャパシティーユニット (RCU) を一切消費しないため、テーブルのパフォーマンスや可用性にも影響しないところです。
製品側で該当のDynamoDB テーブルを頻繁にクエリしていても、気にせずデータ取得が可能になるということで、本機能を即採用しました。

手順は公式ドキュメントにも載ってますので、ここでは注意点やナレッジをメインにお伝えします。

実行前の注意点

DynamoDB の S3 へのエクスポートはポイントインタイムリカバリ(PITR)を使用してエクスポートを行うため、該当のDynamoDB テーブルのPITRがオンになっていることを確認する必要があります。

PITRの確認画面
本機能を実行するユーザーやサービスに、S3 バケットへのエクスポートを実行するIAMポリシー権限を付与する必要があります。

Version: 2012-10-17
Statement: 
  - Effect: Allow
    Action: 
      - 'dynamodb:ExportTableToPointInTime'
    Resource:
      - 'arn:aws:dynamodb:ap-northeast-1:111122223333:table/my-table' # S3 へのエクスポート対象の DynamoDB テーブル
  - Effect: Allow
    Action: 
      - 's3:AbortMultipartUpload'
      - 's3:PutObject'
      - 's3:PutObjectAcl'
    Resource:
      - 'arn:aws:s3:::your-bucket/*' # エクスポート先の S3 バケット

エクスポート時の挙動

DynamoDB の S3 へのエクスポートを実行すると、S3 バケットにマニフェストファイルとデータがアップロードされますが、それらのオブジェクトはMultipart upload形式で出力されます。

分析用データの収集基盤では、S3 へのエクスポート完了後に Lambda を動かしたかったので、S3 イベント通知を設定してます。
当初はイベント通知のタイプをs3:ObjectCreated:Putとs3:ObjectCreated:Postにして S3 イベント通知を設定してましたが、一向にイベント通知が発火しませんでした。
そこで、s3:ObjectCreated:CompleteMultipartUploadに変更したところ、イベント通知が発火するようになりました。

DynamoDB の S3 へのエクスポートの時だけ、S3 イベント通知を発火したいという方はs3:ObjectCreated:CompleteMultipartUploadを設定するようにしましょう。
とにかく S3 にファイルができたらイベント通知を発火したいという方はs3:ObjectCreated:*という設定の仕方もありますので、状況に応じて設定してください。

まとめ

DynamoDB の S3 へのエクスポートを行う場合は、

DynamoDB テーブルの PITR をオンにしておく必要がある
dynamodb:ExportTableToPointInTime, s3:AbortMultipartUpload, s3:PutObject, s3:PutObjectAcl の権限が必要になる
s3:ObjectCreated:CompleteMultipartUploadのイベントタイプで S3 にファイルがアップロードされる

を考慮するようにしましょう。

S3 のレプリケーション

S3 バケット間でオブジェクトを自動で非同期的にコピーする機能です。

この機能の素晴らしいところは、始めに設定さえしておけば、以降は自動でオブジェクトのコピーを行ってくれるところです。
そのため、わざわざ各 S3 バケットに同じオブジェクトをアップロードする必要がなくなります。
また、レプリケーション先の S3 バケットは、異なるアカウントの S3 バケットにすることも可能です。
本番用 AWS アカウントへの影響も最小限にできるので、分析用データの収集基盤では、異なるアカウントの S3 バケットへのレプリケーション、すなわちクロスアカウントレプリケーションを採用しました。

ここでは、レプリケーションするために必要なことや注意点をメインにお話していきます。

レプリケーションするために必要なこと

レプリケーション元・先バケット両方とも、バージョニングを有効にする必要があります。
レプリケーション元バケットのレプリケーション設定にIAMロールを付与する必要があります。
- レプリケーション設定に付与するIAMポリシーは以下の通りです。

Version: 2012-10-17
Statement:
  - Effect: Allow
    Action:
      - 's3:GetReplicationConfiguration'
      - 's3:ListBucket'
    Resource:
      - 'arn:aws:s3:::replicaton-source-backet' # レプリケーション元の S3 バケット
  - Effect: Allow
    Action:
      - 's3:GetObjectVersionForReplication'
      - 's3:GetObjectVersionAcl'
      - 's3:GetObjectVersionTagging'
    Resource:
      - 'arn:aws:s3:::replicaton-source-backet/*' # レプリケーション元の S3 バケット
  - Effect: Allow
    Action:
      - 's3:ReplicateObject'
      - 's3:ReplicateDelete'
      - 's3:ReplicateTags'
    Resource:
      - 'arn:aws:s3:::replicaton-dest-backet/*' # レプリケーション先の S3 バケット

レプリケーション先バケットにレプリケーション受信用のバケットポリシーを付与する必要があります。

Version: 2012-10-17
Statement:
  - Effect: Allow
    Principal:
      AWS:
        - arn:aws:iam::111122223333:role/replication-source-role # レプリケーション元のレプリケーション設定に付与したIAMロール
    Action:
      - 's3:ReplicateObject'
      - 's3:ReplicateDelete'
    Resource:
      - 'arn:aws:s3:::replicaton-dest-backet/*' # レプリケーション先の S3 バケット
  - Sid: 'Permissions on bucket'
    Effect: Allow
    Principal:
      AWS:
        - arn:aws:iam::111122223333:role/replication-source-role # レプリケーション元のレプリケーション設定に付与したIAMロール
    Action:
      - 's3:List*'
      - 's3:GetBucketVersioning'
      - 's3:PutBucketVersioning'
    Resource:
      - 'arn:aws:s3:::replicaton-dest-backet' # レプリケーション先の S3 バケット

注意点

S3 のレプリケーションには幾つか注意点がありますので、設計時に考慮いただければと思います。

すでに S3 バケットにオブジェクトがある状態でレプリケーションを設定しても、レプリケーション設定前のオブジェクトはレプリケーションされません。
ライフサイクルルールによって実行されたアクションはレプリケーションされません。
- そのため、レプリケーション元・先の S3 バケットそれぞれでライフサイクルルールを設定する必要があります。
デフォルトでは削除マーカーのレプリケーションはされません。

その他

S3 レプリケーションには、Replication Time Control (S3 RTC) という設定があります。
こちらを設定すると、オブジェクトの99.999%を15分以内にレプリケートできます。

また、レプリケーションのメトリクスを有効にすることで、保留中のバイト数、保留中のオペレーション、レプリケーションに失敗したオペレーション、レプリケーションのレイテンシーなども確認できるようになります。
メトリクスを有効にすると、レプリケーションに関する S3 イベント通知も使用できるようになります。

おわりに

分析用データの収集基盤で利用した「DynamoDB の S3 へのエクスポート」と「S3 のレプリケーション」についてお伝えしました。
これらの機能はDR（ディザスタリカバリ）の目的で使われることが多いかと思いますが、今回のような使い方もできることが分かり、更に視野が広がりました。
これからも、AWS の様々なサービス・機能を使っていきたいと思います。

ここまでお読みいただき、誠にありがとうございます。
本内容がお役に立てれば幸いです。