1. はじめに

現在、データベースの機能と処理性能に深く依存していたELTシステムを、アプリケーション側で処理を行うETLシステムへと刷新するプロジェクトを進めています。
本番リリースがいよいよ目前に迫ってきました。そこで本記事では、このアーキテクチャ刷新を振り返り、移行によって得られた成果や直面した課題について紹介します。

2. 刷新前後のシステム構成イメージ

■before

■after

尚、刷新のプロジェクトではオンプレミスのシステム基盤をクラウド(AWS)へ移行しています。
プロジェクトの主目的はクラウド(AWS)への移行ですが、ここではETLへの刷新を主題に話します。

3. 現行システムで抱えている課題と解決状況

課題の概要	課題の詳細(Before)	解決状況(After)
RDB依存(ELT)	・実行計画への依存と不安定さ・統計情報のズレやプランの急変による性能劣化に悩まされる。・統計情報のメンテナンスに工数を割きたくない。・マネージドサービス(DWH)側のサイレント修正による性能劣化リスクがある。・ACID特性(分離レベル)に伴うロック競合が障壁となり、並列化が困難。・結果として直列のバッチ処理にならざるを得ない。・データ調査時にSQLでサクッと検索したい。	✅処理性能の安定化 (Immutable)pandasによる手続き型処理へ移行し、実行計画に左右されない安定した性能を実現。クラウド側の変更による劣化リスクも解消。 ⚠️オーバーヘッドの質の変化統計情報の更新は不要になったが、代わりにコンテナ起動(コールドスタート)のオーバーヘッドが発生。 ✅クラウドネイティブな並列処理DBのロック機構から解放されたため、Step FunctionsのMapステートとECSタスクを用いた大規模な並列処理が可能に。 ⚠️SQLインターフェースの維持Athena(Partition Projection)でSQL実行環境は確保。ただしデータ実体がS3ファイルのため、RDBと同等のレスポンスや使い勝手ではない。 ⚠️スキーマ変更への弱さデータの実体がオブジェクトストレージ上のファイルであるため、カラム追加・削除や型変更などのスキーマ変更(Evolution)への追従がRDBより難しい。
ベンダーロックイン	・長年、特定ベンダー製品の仕様やコストに苦しめられている。・大規模移行のサイクル(5年ごと)のEOL対応(DBバージョンアップや製品移行)が重い。・製品特有の方言や、バージョンごとのバグ・挙動差異への対応コストが高い。	✅特定ベンダー製品から卒業し、ライセンスコストやベンダー都合の制約から解放された。 ✅EOLに伴う強制的なDB移行プロジェクトが不要になった。 ⚠️DB製品(5年周期)に比べ、Pythonやライブラリのエコシステムはライフサイクルが早い。依存関係の解消やアップデートを、より高頻度に行う必要がある点に運用上の不安が残る。

4. ELTからETLに切り替わってどうだったか

■データ加工ロジックの基盤刷新(SQL -> pandas)

当初は複雑怪奇に絡み合ったSQLによる業務ロジックを、pandasで正しく再現できるか不安がありました。
結果としては完全に再現できただけでなく、以前は困難だったCI(継続的インテグレーション)の構築という大きな副産物を得ることができました。

良かった点・工夫した点

DBとの密結合からの脱却とテストコード化
- SQLからアプリケーションコード(Python)へ移行したことで、DBの状態に依存せずに重要な業務ロジックの単体テストが可能になりました。
巨大なクエリの関数化・モジュール化
- 以前はパフォーマンス(セットベース処理の高速性)を優先するためにあえて複雑なままにしていたSQLを、可読性の高い小さな関数へと分割・整理できました。
アーキテクチャによるパフォーマンス向上
- 単一処理の実行速度はRDBMSのエンジンに劣りますが、設計と実装の工夫により、トータルの処理時間は短縮されました。
  - 並列処理化: RDBのACID特性(ロック待ち等)を気にする必要がなくなったため、マルチプロセスでの並列処理を前提とした設計に変更しました。
  - メモリ管理: pandasの課題であるOutOfMemory(OOM)を回避するため、データを適切にチャンク分割(Partitioning)して並列化効率を高めました。
エコシステムの活用
- pandasに関する知見はWeb上に豊富にあり、トラブルシューティングや実装がスムーズでした。

■データ保存先の刷新(RDB -> S3)

データ加工ロジックと同様に、データの永続化先をRDBからファイルストレージ(S3)へ移すことにも不安がありました。
特に「障害調査や運用保守の際に、即座にSQLでデータを叩いて確認できない」という点は依然として課題感が残っています。

しかし、この課題に対しては、S3バケット内のデータ構造をHive形式(パーティション構成)で設計することで対策しています。これにより、Athena、Glue、Redshift Spectrum等のマネージドサービスを経由してSQLライクにデータへアクセスできる経路を確保しました。この構成により、本番運用にも耐えうると判断しています。

コストとリソースのトレードオフ

最大のメリットはランニングコストでした。ELT構成(常時起動のRDSやRedshift)と比較して、インフラコストを約50%削減できました。
一方で、基盤刷新に伴う実装難易度の上昇により、開発時の人的コスト(初期開発工数)は増加しました。
これは長期的な運用コスト削減と保守性向上のための投資と捉えています。

5. おわりに

ELTからETLへ切り替える際の参考になれば幸いです。
技術選定の話を書くか迷いましたが、業務要件は千差万別な事と生成AIの台頭により控えました。
生成AIの活用について話を聞く度、時代に取り残された気になり、気持ちはおじいちゃんです。ﾜｼｶﾞﾜｶｲﾄｷﾊﾉｩ
拙筆ながら本記事をご覧いただきありがとうございました。

明日3日目は、宮田さんによる「LaravelのUIフレームワーク、Livewireを触った話」です。

JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です！
フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。
詳細は下記の募集一覧からご確認ください。 hrmos.co

まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。
hrmos.co

★最新記事のお知らせはぜひ X（Twitter）、またはBlueskyをご覧ください！
Tweets by jmdc_tech twitter.com bsky.app