🗿

分析基盤を構築してみた(クロスアカウントでのスナップショットエクスポート編)

柴田

2024/03/29に公開

はじめに

こんにちは。バックエンドエンジニア(?)の柴田です。
普段はNestJSとReactでBEとFE両方のアプリケーション開発やら、AWS CDKでインフラ構築やらをしています。
この度、知識もなく未経験で分析基盤の構築を担当することになったので、せっかくだし記事にしてみようと思います。
分析周りは知識が0なので、もっと良い手法があればぜひ教えてください。

構築する分析基盤の概要

今回の分析基盤ではAmazon RDSのAmazon S3へのスナップショットエクスポート機能を使用し、エクスポートしたデータをAthenaでクエリできるようにします。
また、構築はAWS CDKではなく、CDK for Terraformで行います。
CDK for Terraformの選定理由は、将来的にマルチクラウドになること(BigQueryからのデータ取得等)が予想されるので、分析基盤はTerraformで管理したい&AWS CDKしか使ったことないし、せっかくだからCDK for Terraform使ってみようといった感じです。ちなみに素のTerraformの使用経験は0です。

インフラ構成

全体の構成は以下のような感じです。
弊社ではAWSのアカウントを結構細かく分けています。
今回、分析基盤用のアカウントも別で作ったので、既に稼働しているアカウントのRDSのスナップショットを分析基盤側のS3にエクスポートしています。

この記事で説明すること

項目	説明
CDK for Terraform での環境構築方法	◯
クロスアカウントでのスナップショットエクスポート	◯
Glue Catalogの作成	別で書きます
Athenaでのクエリ実行	別で書きます

検証用のgithubリポジトリはこちら

クロスアカウントでのスナップショットエクスポートについて

弊社ではRDSのスナップショットを自動保存しているので、自動作成された最新のスナップショットを毎日S3にexportします。
スナップショットを使う関係上、全データ置き換えみたいな感じになるので、料金的にはもっと良い方法があるかもしれません。
また、今回はそこまでリアルタイム性が問われていないのでこのような構成にしていますが、どうしてもリアルタイムデータで分析したい場合は、ストリーミングで同期するかs3 event + SQSでの加速クロールなどを使うことになるかと思います。

エクスポートフローは以下の通りです。

EventBridge + AWS Step Functionsで毎日スナップショットエクスポート用のLambdaを定期実行
分析基盤側のアカウントで作成したスナップショットエクスポート用のLambda内で、RDSがある別アカウントで定義したroleにassume role
別アカウントのRDSのスナップショットを全取得
Lambda内でソートして最新のスナップショットを取得
最新のスナップショットに対し、エクスポートタスクを実行

エクスポートタスク作成用のLambda関数

ソースコードはこちら

golangで書いています。aws-sdk-go-v2を使用して、クラスタースナップショットをエクスポートする関数となっています。
指定のRDS Clusterから作成されたスナップショットを全取得し、Lambda関数内でソートして最新のものを取得している点は、そもそも最新のものだけ取るようにできないかなあと思ってます。
※ちなみに、クラスタースナップショットとインスタンススナップショット取得でメソッドやARN構成が微妙に違うので、インスタンススナップショットを用いる際は注意です。

Lambdaでassume roleするためのIAM Roleを別アカウントで作成

cd another-account-iam-role　した後に、RDSがあるアカウントで cdktf deploy dev すればOKです。(デプロイの際はassume roleするなりしてください)

CDK for Terraformでのデプロイ

実際にAWS環境にデプロイしてみたいと思います。

プロジェクトルートで分析基盤用のアカウントで cdktf deploy dev すればOKです。(デプロイの際はassume roleするなりしてください)
※初回はリモートバックエンド用のS3バケットがないので、以下のようにするとS3でterraformの状態ファイルを管理できます。

new S3Backend の処理を削除
cdktf deploy dev で状態ファイル管理用のS3バケットを作成(状態ファイルはローカル管理扱い)
手順1で削除した処理を元に戻す
cd cdktf.out/stacks/dev して terraform init -migrate-state を実行

動作確認

分析基盤用のアカウントでAWSマネジメントコンソールでStep Functionsに飛ぶと、export-another-account-rds-snapshot-to-s3-state-machine-dev のようなステートマシンが作成されているので、「実行を開始」ボタンを押す。(この際、入力はなんでも良い。)
成功したら、RDSのあるアカウントに切り替える
RDSの「Amazon S3 へエクスポート」タブに飛び、エクスポートタスクが作成されていることを確認
エクスポートタスクが完了したら、分析基盤用のアカウントに切り替える
a. データ数によっては結構時間がかかるので注意
スナップショットエクスポート用のS3バケットにオブジェクトが作成されていることを確認

まとめ

クロスアカウントでのスナップショットエクスポートが思ったより簡単にできるのは良かったです。
AWSのベストプラクティスに従っているとアカウントを細かく分けていると思うので、各アカウントにあるRDSのデータを分析用のアカウントにエクスポートして、単一のアカウントで分析できるというのは割と需要がありそうな気がします。

また、CDK for Terraformも思ったよりは楽に記述できて開発体験としては良かったです。
ただ、これはそのうち書こうと思いますが、特にcodepipelineなどのIAM周りの設定が大量に必要になるAWSリソースは、AWS CDK(というよりCDK Pipeline)が楽すぎてCDK for Terraformで書く気が起きなかったです。いちいちIAMの指定をしなければいけないのがあまりに面倒でした。
とはいえ、差分は見やすいし、CloudFormationのスタックでは管理できないところまで管理できるし、普通に他のプロジェクトで使っても良いレベルだなと思ったので、普段AWS CDK書いてる人には結構おすすめです。

最後に、今回はスナップショットエクスポートまでだったので、次回Glue Catalogの作成やAthenaでのクエリ実行まで行ってみたいと思います。
では、良いexportライフを(?)

お誘い

トリドリのプロダクト開発部では通年採用を実施しています！

ユーザの幸せについて真剣に議論したり、「やってみたい」で新しい技術に挑戦をしてみたり、気づいたら30分雑談していたり、ゆるく真面目に開発しています。もし興味を持ってもらえたら、こちらを読んでみてください！

https://toridori.notion.site/toridori-7e9c804bcfc249d6a932cdb99b83e1f6

toridori tech blogPublication

株式会社トリドリのEngineeringに関わる人が更新していくPublicationです。