かわいそうなバッチ処理をAWS Data PipelineからLambdaに移行した

CTO室の岩本です。詳しくは別の記事に書くつもりですが、最近はEVスマート事業の譲受にともない、ドメインやメール、GitHubリポジトリなどの移管を担当しています。

大きめのタスクを進めていると、たまに息抜きしたくなることがあります。そんなときにはプレッシャーの少ない、小さめのタスクを見つくろって進めるのが慣例です。

今回の記事は、そんな息抜きで進めた、バッチ処理の移行についての話です。このバッチ処理、ちょっとかわいそうだったんですよね。

もっとシンプルにできるのに、かわいそう

このバッチがかわいそうだったのは、下記の点でした。

• データ処理ではないのにData Pipelineで実行されている
• 実行されるRubyスクリプトが読みづらい

それぞれ、簡単に説明します。

データ処理ではないのにData Pipelineで実行されている

このバッチの目的は「EC2インスタンスに付いているタグを、関連リソースにコピーすること」です。詳細は省きますが、コスト管理のために必要な処理となります。

この処理がData Pipelineで運用されているのを見て、実装の経緯を知らないぼくは不思議に思いました。EC2インスタンスを一時的に起動し、S3バケット内のRubyスクリプトを参照して実行する、必要以上に複雑な構成だったからです。

Data Pipelineの得意なデータ処理ではないので、Lambdaでシンプルに実装するのがよさそうに感じます。

実行されるRubyスクリプトが読みづらい

パイプラインで実行されているRubyスクリプトを見ると、AWS CLIコマンドをThreadで並列実行する、ぼくにとっては読みづらい内容でした。処理時間の短縮を狙ったものだとは思いますが、メンテナンスが大変な印象です。

一方で、ログを見ると、Rubyスクリプトの実行時間より、EC2インスタンスの起動や終了に要する時間のほうが、だいぶ長い状況でした。スクリプト実行に2分半、それ以外に10分といったオーダーです。

もしLambdaに移行すれば、並列実行をやめても、全体の処理時間が短くできそうです。

Lambdaに移行して、かわいそうじゃなくなった

ということで、息抜きがてら、Lambdaに移行してみました。並列実行もやめ、AWS SDKでAPIを順次実行するシンプルなロジックに変えました。

下表は、移行前後で、直近の処理時間を比較した結果です。

プラットフォーム	処理時間	うちスクリプト
Data Pipeline	12分47秒	2分30秒
Lambda	1分35秒	1分35秒

スクリプトの処理時間が短くなったのは意外でした。深くは調べていませんが、もともとあった非効率な処理が、期せずして改善されたのでしょう。

息抜きだったけれど、教訓が得られた

ちょっとした息抜きで始めたことながら、下記の点にあらためて気づけてよかったなと思いました。

• 処理に適したプラットフォームを選ぼう
• 凝ったスクリプトが効率的とは限らない

では、大きめのタスクに戻ります。