こんにちは。リサーチ・アンド・イノベーションの塚田です。サーバーサイドエンジニアとして弊社サービス CODEの開発やインフラ・データ基盤の整備を担当しています。

その中で今回はデータ基盤のリプレースに関した取り組みをご紹介したいと思います。

リプレースに至った背景

弊社のデータ基盤はAWS上に構築しており以下の理由からリプレースを進めることにしました。

処理時間の長期化

一番の理由はデータ量増大に伴う処理時間の増加で以下のような問題がありました。

DBに保存されているデータ量の増加に伴い集計処理時間も増加傾向にある
- データ基盤利用者が業務でデータを利用する午前10時までに処理が完了するようにしていたが、ギリギリになってきてしまっている
リトライ機構を入れているが、リトライすると想定以上の時間がかかってしまう
データ基盤構築当時のデータ増加量を元に余裕を持ったリソースを用意していたが、枯渇するようになってきた
処理の長時間化に比例してAWSリソースのコストも上がっている

データ基盤構築時には使うことができなかった以下の機能がリリースされたため組み合わせて使用することによって処理時間の高速化が期待できると考えました。

RDSスナップショットのS3エクスポート
- リリース記事
Athenaエンジンバージョン2
- リリース記事
- 2022年12月現在エンジンバージョン3がリリースされていますが、リプレース当時はなかった機能なので、こちらは使用せずに進めます
- エンジンバージョン2で使用するPrestoのバージョンが上がったことにより、使用可能なTimestampの精度が上がりリプレースが可能になりました

リプレースの方針を記載する前にリプレース前の大まかな処理の流れを記載します。

データエクスポート処理
1. AWS Batchを利用し以下の処理をテーブルごとに並列実行
  1. AuroraからCSVエクスポート実行
  2. Athenaで利用可能なようにCSVファイルのフォーマット処理を実行
  3. 2で作成したCSVをS3に配置しGlueのテーブル情報を更新
1次集計
- データエクスポート処理で作成したファイルを利用してベースとなる各種データをAthenaで生成
2次集計
- 1次集計のデータをもとにデータ基盤利用者がよく利用する情報をAthenaで生成

ここで問題になっているのはデータエクスポート処理になるので、 1次・2次集計は手をつけずデータエクスポート処理のみを変更する方針としました。

リプレース後の処理は以下のようになりました。

データエクスポート処理
1. AuroraのDBスナップショットを生成
2. DBスナップショットからS3エクスポートを実行
3. Lambdaを利用しAthenaで利用可能なS3パスへPaquetファイルをコピー
4. 3で作成したPerquetファイルをもとにGlueのテーブル情報を更新
1次集計(変更なし)
2次集計(変更なし)

実際には各処理の実行ステータスのチェックやエラーハンドリングをStep Functionsを利用して実施しています。

S3間のオブジェクトコピーのLambda以外はStep FunctionsのAWS SDK統合を積極的に利用し処理全体の見通しが良くなるように配慮しています。

実際にStep Functionsで実行しているデータエクスポート処理のフローが以下になります。

一番の問題点であった処理時間についてはリプレース前10時間程度かかっていたものが 2時間以内に処理が完了するようになり、リプレース効果は非常に高いものになりました。また、リプレースしてから半年以上経過しその間にもデータ量は増大していますが、処理時間はほとんど変化がなく安定的に利用ができています。

AWSの利用料の観点ではBatchがスナップショットエクスポートにおきかわったので、劇的な変化はありませんでしたが、コストダウンも併せて達成できました。

構成変更により、スナップショットからのエクスポート処理の実行になったためAuroraの状況に影響せず独立した処理になり可用性も上がりました。

課題・問題点に対してAWSの新しい機能を組み合わせることで改善した事例をご紹介しました。

実際にはリプレース前後の2環境を運用し利用者からのフィードバックをもらうようにしていましたが、集計処理は変更していないため利用者側への大きな問題は発生せず運用スタートができました。

AWSは日々新しいサービス・機能を出していますので、改善につながるものは積極的に導入していきたいと考えています。

リサーチ・アンド・イノベーションではエンジニアを募集中です。

興味を持っていただけた方はお気軽にご連絡ください！