はじめに
こんにちは。バックエンドエンジニア(?)の柴田です。
普段は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
Discussion