こんにちは。hacomono データ基盤部のうまちゃん ( @i9wa4_ ) です。
hacomono データ基盤におけるデータ転送の課題と今後の対応の話を通じて hacomono のデータ基盤部の業務内容の一部をお伝えできればと思います！
hacomono データ基盤のデータ転送システム構成
Embulk で hacomono 環境の Amazon RDS もしくは Amazon Aurora のデータを抽出しお客様環境の BigQuery へ転送する構成となります。
データ転送システム全体は GitHub・Terraform で管理しています。
hacomono データ基盤におけるデータ転送の課題
暫定的に構築したシステムのため、毎回全テーブルを作り直す構成になっております。
このため転送対象データが肥大化していき課題が生じています。
1. 転送処理にかかる時間が増え続けている
RDS や Aurora に蓄積するデータが増え続けていてそれを全て転送しようとしているため、転送処理にかかる時間が増え続けてしまいます。
2. 転送元 Amazon Aurora MySQL の一時テーブル領域制限に達してしまう
Aurora 側のデータ量が多く一時テーブル作成処理中にエラーが出る状況になりつつあります。
MySQL 8.0 リファレンスマニュアルに記載の下記パラメータによってデフォルトで 2GiB 分の一時テーブル領域が確保されていて、その上限に達してしまうような転送の仕方をしているものと思われます。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 5.1.8 サーバーシステム変数
- temptable_max_ram メモリ側の一時テーブル領域上限値 (デフォルト 1GiB)
- temptable_max_mmap ストレージ側の一時テーブル領域上限値 (デフォルト 1GiB)
対応方針
暫定対応 → 根本対応の順に記載しております。
1. [実施済] 転送時間短縮のために Embulk Local executor plugin のスレッド数を増やす
max_threads, min_output_tasks を用いてスレッド数を設定できます。
Embulk: Configuration
ECS の vCPU 数より多いスレッド数を強制させるために min_output_tasks の数字を大きくしてみたところ処理時間の改善が見られました。
スレッド数設定をする以前から xargs で Embulk による各テーブル転送を並列実行しておりましたが、本対応によって全体転送時間が5.5時間 → 2.5時間と半減しました。
これは最も時間のかかっていたテーブルの転送時間が4.5時間 → 2時間と変わった影響が大きかったです。
2. [未実施] Amazon Aurora MySQL の一時テーブル領域不足対策を実施する
一時テーブル領域を増やす方向性が有力です。詳細は検証を通して考えていきます。
3. [未実施] ワークフローツールを用いてテーブル抽出を並列化する
現状1テーブルに Embulk 1プロセス割り当てる形になるのでテーブルサイズが大きいとどうしても時間がかかってしまいます。
そのためテーブルを分割して取り込むようなワークフローを Digdag 等で組み、問題を回避しようとしています。
4. [未実施] そもそもデータ転送を行わない構成にする
お客様環境から View 経由でデータを参照していただく、あるいは データクリーンルームの導入などの対処になると思います。
いずれにしても基盤構成を変更するレベルの対処になっていくので腰を据えて実施していきます。
まとめ
直近の課題感を伝えることができたのではないかと思います。
データ転送のパフォーマンス改善や基盤構成の変更など課題は多いですが、面白さを感じつつ業務に取り組んでおります！
株式会社hacomonoでは一緒に働く仲間を募集しています。
採用情報や採用ウィッシュリストもぜひご覧ください！
