実験データの登録から変換までを自動化したい
最近、あるシステムでデータをS3にアップロードすると、そこからデータを登録し、さらにセンサー情報を解析したうえでデータ変換を行う仕組みを作る必要がありました。この一連の流れをAWSのサービスを活用して自動化しようというのが今回の目的です。
具体的には、
-
データ登録処理: S3にアップロードされた
sample.jsonを読み込み、データをデータベースに登録する。 - センサー解析処理: 登録されたデータをもとにセンサー情報を解析し、ネットワーク名を推定してデータベースに保存する。
- データ変換処理: 上記の結果を用いて、最終的にデータ変換するステートマシンを起動する。
この流れをStep Functionsで構築することで、処理の順序を管理しつつ、問題が発生した際にもわかりやすく追跡できる設計を目指しました。
前提として、データ登録処理とセンサー解析処理それぞれ独立したLambda関数として実装されている状態です。
見えてきた課題
この計画を進める中で、いくつかの課題が明らかになりました。
1. 必要なデータが分散している
- データ登録処理とセンサー解析処理がそれぞれ独立したLambda関数として実装されており、必要な情報が片方でしか手に入らない状況でした。
- 例えば、
sample.jsonの情報はデータ登録処理で取得される一方で、センサーのネットワーク名はセンサー解析処理でしか取得できません。この2つを統合しないと、次のデータ変換処理に必要なパラメータを生成できません。
2. トランザクションの一貫性がない
- 1つ目のLambda関数が成功し、データベースに登録が完了しても、2つ目のLambda関数で失敗すると、中途半端な状態がデータベースに残ってしまいます。
- これでは後続の処理が正しく動作しない可能性があります。
3. 実行時間の制限
- Lambda関数の最大実行時間は15分。1つのLambdaにすべての処理を詰め込むと、この制限を超える可能性がありました。
解決策の検討
課題を解決するために、いくつかのアプローチが考えられました。
案1: Lambda関数を統合する
- データ登録とセンサー解析を1つのLambda関数で処理する。
- 必要な情報が1つの関数内で揃うため、後続のデータ変換処理に必要なパラメータを容易に生成できる。
-
メリット:
- トランザクション制御が容易になり、一貫性を保てる。
- Step Functionsの設計がシンプルになる。
-
デメリット:
- 処理が複雑になり、実行時間が長くなるリスクがある。
案2: JSONデータを拡張する
- データ登録処理からセンサー解析処理に渡されるJSONデータに、
sample.jsonの情報をすべて含める。 - センサー解析処理で
sample.jsonの情報とセンサー情報を組み合わせてデータ変換処理のパラメータを生成する。 -
メリット:
- 現在の分散処理の構造を維持できる。
-
デメリット:
- JSONデータが巨大化し、処理負荷が増加する可能性がある。
案3: 専用のLambda関数を作成する
- データ登録処理とセンサー解析処理をそのままにして、両方の処理が完了した後でデータ変換処理を起動する専用のLambda関数を作成する。
- この専用関数がデータベースから必要な情報を取得し、パラメータを組み立ててデータ変換処理を起動する。
-
メリット:
- 現在の構造を大きく変更せずに対応可能。
- 各処理が分離されているため、保守性が高い。
-
デメリット:
- Step Functionsの設計が複雑化し、管理が難しくなる。
実際に採用した解決策
最終的には、案1: Lambda関数を統合する を採用しました。
理由は以下の通りです:
- トランザクションの一貫性が確保できるため、処理の信頼性が向上する。
- Step Functionsの設計をシンプルに保てる。
- 実行時間が15分を超えないように設計可能と判断した。
実装のポイント
1. データ登録とセンサー解析の統合
-
データ登録処理:
-
sample.jsonをS3から取得し、データをデータベースに登録。
-
-
センサー解析処理:
- メッセージリストを用いてネットワーク名を推定し、データベースに登録。
- 両方の処理を1つのLambda関数にまとめることで、必要な情報を1つの関数内で揃えられるようにしました。
2. トランザクション制御
- Lambda関数内でトランザクションを利用し、すべての処理が成功した場合のみコミットする仕組みを採用。
- 途中でエラーが発生した場合は、すべての変更をロールバックするようにしました。
3. データ変換処理の起動
- データ登録とセンサー解析が完了した後、Step Functionsの次のタスクとしてデータ変換処理を起動。
結果と振り返り
この統合により、以下の課題が解消されました:
- 必要な情報が1つのLambda関数内で揃うようになり、パラメータ生成が容易になった。
- トランザクション制御が可能になり、中途半端な状態がデータベースに残らなくなった。
ただし、Lambdaの実行時間が長くなるリスクには引き続き注意が必要になります。そのため、処理が重くなりそうな場合は、Step Functionsやバッチ処理をさらに活用する方法も検討しています。