【備忘録】データ基盤 on AWS への移行を考える
オンプレミスで稼働しているデータ基盤 の AWS への移行を検討した際に、調査した内容を備忘録としてまとめました🐱
前提
- オンプレミスの データ基盤 へは、HULFT を利用して各システムからのデータを集信している。
- データ基盤では、1日に2回各システムのデータを 順次処理 で加工後に Oracle DB へ格納するジョブを実行している。
- ジョブの開発体制は少数メンバーで遂行。
- 格納データのファイル要件
- ファイル数：50ファイル以上。今後増加する予定。
- １ファイルのサイズ：0.5MB~2.2GB
構成図
使用する主なサービス
| 機能 | AWS サービス名 |
|---|---|
| データレイク | Amazon S3 |
| DB | RDS for Oracle , DynamoDB |
| データ加工 | AWS Glue |
| イベント管理 | EventBridge, Step Functions |
| イベントログ | CloudWatch |
| 専用線接続 | Direct Connect |
コメント
- AWS で HULFT からのデータを集信する先は S3 を利用する。
参考：HULFTのS3アップロード機能を試してみた (実践編)
検討事項
1. DB 移行の方法
DB 移行の際、ダウンタイムを許容する（リアルタイムのデータ移行を考慮しない）場合には下記手順を選択します。
- Oracle Data Pump を使用してデータをダンプファイルにエクスポート
- データベースに必要な移行時間に応じて、Direct Connect (データサイズが 10 GB から 5 TB の場合) または AWS Snowball (データサイズが 5 TB を超える場合) を使用して、オンプレミスから S3 バケットにデータダンプファイルをコピー
- Amazon RDS for Oracle DB インスタンスの DATA_PUMP_DIR ディレクトリにダウンロードし、そのデータを DB インスタンスにインポートする
参考： AWS 規範ガイダンス - Oracle データベースの AWS クラウドへの移行
ダウンタイムを許容しない 場合には、Oracle Data Pump と AWS Database Migration Service (AWS DMS) を利用して移行を行います。
引用／参考：AWS DMS を使用してほぼゼロのダウンタイムで Oracle データベースを移行する
2. データを DB に取り込む方法
各システムのデータファイルを格納した S3 から DB にデータを取り込む方法として、AWSでは下記のサービスがあります。
今回は、①データの加工 × ②順次処理 の観点で、 ①AWS Glue × ②Step Functions を選択しました。
引用：AWS Black Belt - AWS ETL サービス適材適所選択のコツ
①データの加工：AWS Glue
AWS Glue とは、データの抽出、変換、ロード（ETL）を自動化するためのフルマネージドサービスです。
引用：AWS Black Belt - AWS Glue
AWS Glue を利用する際の注意点
- ファイルサイズ
Glue のほとんどのワークロードでは、5～10 DPUクラスターに 100 MB～1 GB のファイルサイズを推奨（最大は数ペタバイトまで対応）。サイズの小さいファイルが多数あると、データ処理が遅くなる可能性があり、最適化のためのチューニングを推奨。
参考：入力ファイルサイズのETL取り込みを最適化する - ジョブ数
AWS Glueのジョブ同時実行数制限は、「（ジョブ関係なく）アカウント内のジョブの最大同時実行数は50」かつ「1つのジョブの最大同時実行数は1000」
参考：AWS Glueのジョブ同時実行数制限には気をつけた方がいいという話 - ワークフロー
AWS Glue に備わっている Workflow機能 では、Jobの失敗時のデバッグや再実行が困難。
参考：AWS GlueのworkflowsからAWS Step Functionsに乗り換えた話
②順次処理：Step Functions
AWS Step Functionsとは、複数のAWSサービスを連携させてワークフローを構築するためのフルマネージドサービスです。
引用：AWS Black Belt - AWS Step Functions
AWS Glue の処理で汎用化できる処理などがあれば、Step Functions のフローの中に Lambda を入れてパラメータを渡して呼び出すことなどもできます。
参考：LambdaからGlueJobにパラメーターを渡してみた
Step Functions を利用する際の注意点
- Step Functionsがバッチのワークフローに特化したサービスではない為、失敗したジョブから再実行が出来ない。
対応：失敗後に再開すると、新規に最初から実行されるため、途中から実行したい場合は別途 DynamoDB などに各ステップの Status を記録し、それを参照するようにする必要がある。
参考：AWS Step Functionsでバッチジョブワークフローの実行基盤を構築する - 親ジョブから子バッチの呼び出しなど、フロー図を複雑化させないように意識する。
- 適切なStep Functions ワークフローでのエラーの処理を定義する。
その他代替サービス について
要件や、開発コストなどの観点で選定しなかったサービスの概要について、大変参考にさせて頂きました🙇♀️
- 全体：AWS Black Belt - AWS ETL サービス適材適所選択のコツ
- バッチ基盤：AWSでバッチ処理を実装する際の選択肢とサービス比較
- 順次処理：スタートアップでもバッチワークフローの使い分けはあり Amazon MWAAからの一元管理で安心感のある運用を
さいごに
AWSで ETL・バッチ処理 を設計・実装するパターンが複数あること、また「順次実行」というポイントでサービス選定に時間がかかりました。
もし誤りやアドバイス等ございましたら、コメント頂けますと幸いです🙇♀️
以上、えみり〜でした|ωΦ)ฅ
参考
-
RDS or Aurora
-
Step Functions
-
AWS Glue
Discussion