LaKeel DXを活用した並列分散バッチ
はじめに
こんにちは。
株式会社ラキールで LaKeel DX コンサル3 Groupに所属する内田です。
普段の業務は、LaKeel DX上で動作するシステムの設計・開発・保守を行っております。
今回紹介させていただくのはLaKeel DXを活用した並列分散処理になります。
私が担当しているプロジェクトで大量データを短時間で処理しなければならないという課題がありました。この課題解決にあたり並列分散バッチが考案され、採用されました。これまでのLaKeel DXではサポートした事のない処理であったため、新しい魅力としてお伝えできたらと思います。
並列分散バッチとは
並列分散バッチはラキール内の造語であり、端的に述べると並列分散処理をバッチに置き換えたものになります。
並列分散バッチは以下の３つのAPIから構成されており、
API内から別APIを連結して呼び出す仕組みとなっています。
バッチ全体の動作の制御を担う「ディスパッチAPI」
処理対象のデータを保持し、ワーカーDBへの格納処理を担う「ワーカー処理API」
ワーカーDBのデータを参照・加工し、トランザクションDBへデータ反映を担う「ワーカー完了API」
ワーカー処理API、ワーカー完了APIの並列数を増減させることで負荷分散の程度をコントロール可能とします。
ディスパッチAPI
並列分散バッチが起動する際に呼ばれる。
入力データを受け取り、分割したデータをワーカー処理APIに渡して処理を分散させる。
ワーカー処理API完了を検知して、ワーカー完了APIを呼び出し、トランザクションDBへ更新コミットを行う。
ワーカー処理API
ディスパッチAPIから、分割したデータを受け取り、ワーカーDBに格納する。
分割したデータがそれでもまだ大きい場合は、処理の負荷が小さくなるように、更に小さなサイズに切り分け、繰り返し処理を行う。
ワーカー完了API
ワーカーDBを参照して、データ加工を行い、トランザクションDBへの更新コミットを行う。
並列分散バッチによって解決された課題
大量データのインサート
1億件のデータインサートが1時間ほどで完了できた。
並列分散しない場合、20時間かかると見込まれていた。複雑な処理でも短時間で完了
データベースのテーブルに対して、複雑なSQLの発行を必要とするとき、 並列数を増やすことで一度に操作するデータ件数を減らし、テーブルのロック時間をより短くした。リソースの調整が可能
ワーカー処理を行う並列数を変更することでリソースのコントロールが可能なため、負荷が高い日だけ並列数を増やすなどインフラコストのコントロールも可能になった。
並列分散バッチを採用する上での今後の課題点
トランザクションDBの負荷上昇
並列分散する都合上、1つのデータベースに対して複数のAPIが接続するためデータベース負荷が上昇した。開発コストの高さ
各APIのDBへのアクセスが別セッションになるため、トランザクションの範囲に制限が生まれ、ロールバックを行いたい処理は別で用意する必要があった。レコードの処理順について
並列に多数のレコードを処理しているため、レコードに処理の順番がある場合は適用が困難だった。
並列に動く処理が干渉しないことで同じAPIが並列に動作することを可能としているため、レコードで処理の順番が決まっているものに関しては分散することに工夫がいる。
(レコードを分散させる際に依存関係をあるレコードグループをまとめて、ワーカー処理APIに処理させるなど)
並列分散バッチを運用するにあたって
並列数の定義について
今回紹介させていただいている並列分散バッチは、システム要件上、日付ごとに大量データの処理日が決まっているため、日付ごとに使用するワーカー数を定義しています。並列数の最適値の算出について
並列数の最大値については、並列数の増加によるトランザクションDBへのアクセス負荷が高まるため、トランザクションDBのCPU、メモリ割り当ての使用率の上限によって決まります。
並列数が増加することで速度が向上していくため、システム要件上で処理速度を優先する必要がある場合、トランザクションDBのリソースの上限まで並列数を増やし、処理時間に目安が決まっているのであれば、並列数を徐々に減らしていくことで最適な並列数を導出することが可能になります。採用するにあたっての留意点
・各レコードの処理順番に依存関係がある場合。
・エラー時のロールバック処理は別の処理として作成する必要がある。
・データベースの負荷と並列数の兼ね合いを計測する必要がある。
おわりに
本記事はLaKeel DXを活用した並列分散バッチについて紹介しました。
並列分散バッチの魅力は処理効率を抜群に高く出来ることと、
並列数を増減させることにより適切なリソースコントロールが可能であることにあります。
難点としてはトランザクションDBへの負荷上昇が高く、初めてのアーキテクチャだったこともあり開発コストが当初計画より増えた点になります。
開発コストに関しては、開発フローの見直しや開発時使用するツールを研究することで今後改善できると見込んでいます。
また、私ごとの所感になりますが並列分散バッチはAPIで非同期の処理を実装しているため、全体像が複雑になりやすかったです。
その結果、実装およびテストのトライ&エラーに費やす時間は想定より必要になりました。
ラキールではプロジェクトの成功のため、探求心、想像力をもってお客様の課題解決に努めております。
本記事では、LaKeel DXの魅力について、まだまだお伝えきれていない部分が多々ありますが、この機会に、興味をもって頂けたら幸いです。
最後まで読んでくださり、ありがとうございました。