はじめに
こんにちは！プラットフォーム事業本部ペイメントサービス部ポイントグループの大倉です。
普段はDMMポイントに関するシステムの開発や保守、それと、この長い所属名を噛まずに自己紹介する方法について考えています。
この記事では、ポイントグループのバッチ処理（以下、バッチ）をcronからRundeckに切り替えることで、カイゼンした運用作業について紹介します。
ポイントシステムのバッチについて
ポイントシステムはお金を扱うシステムのため、金額に間違いが発生しないようにするための突き合わせ処理が多いです。
さらにデータも多いためリアルタイムで処理できない部分をバッチで補っています。
ポイントシステムは2015年に現行システムになり、稼働しています。
処理の多さ・稼働期間の長さから、Java製やPHP製など統一感なく多数のバッチが存在し、さらに複数のサーバに分散して実行されている状態でした。
cronによるバッチと日々の運用業務について
私がチームに配属された2017年9月頃の状態を説明します。
日々の作業は、月毎に確認担当が二人設けられ、毎朝下記の作業を分担して実施していました。
毎朝バッチの数だけメールを確認する
cronサーバで実行しているバッチの結果は、各バッチ毎にメール経由で確認していました。
バッチに異常があった場合、調査・修正を行う
調査は、バッチの仕様を思い出すことから始まり、ログの確認・DBレコードの確認をします。
修正は、DBレコードの修正・バッチの再実施が主になり、cronなので定期実行の停止・再開はサーバに入って行います。
Rundeckによるバッチと日々の運用業務について
現在のカイゼンされた状態です。
日々の作業は、月毎の確認担当が一人になり、下記の作業を実施する形になりました。
Slack通知が来たら確認する
確認担当が自発的に確認するのではなく、通知がある場合のみ確認します。
バッチに異常があった場合、調査・修正を行う
調査は、Slack通知のリンクからログの確認を行い、必要に応じてDBレコードの確認をします。
修正は、DBレコードの修正・バッチの再実施が主になり、定期実行の停止・再開はRundeckから行います。
カイゼンしていったこと
ポイントグループは小さくカイゼンを繰り返し、現在の状態に至りました。
ここからはどういうカイゼンを行ったのか？を説明します。
１.cron → Rundeck
cronだと基本的な作業が全体的に大変ですよね。
- 再実施するのが辛い
バッチ毎にそれぞれマニュアルがあり、それを見ながら関連サーバに接続して復旧や再実施をするのは大変です。 - スケジュール実行のON/OFFのためにサーバに接続してコンソールで操作するのが辛い
セキュリティエリアへの接続のための前準備や"crontab -e"でコメントアウトなど細かい面倒が多々あります。
そこでcronで実行していたバッチをRundeckジョブからの呼び出しに変更しました。
（※）Rundeckについて
RundeckとはOSSのジョブスケジューラとなり、Webコンソール・コマンドラインツールおよびWebAPIを備えています。
参考：https://www.rundeck.com/open-source
これにより下記のようにカイゼンされました。
- バッチのスケジュール実行の再開・停止・再実施がWebブラウザで可能になった！
- バッチのスケジュール実行の再開・停止・再実施が一箇所にまとまった！！
スケジュール実行の巻き戻し忘れでサーバを行ったり来たりしたのはもう過去の記憶です。 - バッチのパラメータが分かりやすくなった！！！
再実施するたびにcronに書かれた実行コマンドを見たり、資料確認をしなくても分かる安心設計になりました。
２.メールチェックをスクリプト化し、必要な情報のみSlackで通知
システムのログを毎朝大量に見させられると機械になった気持ちになりますよね。
- 大量のバッチの結果をメールで確認するのが辛い
１バッチ１メールなので単純に全部開封するだけでも結構なクリック数になります。 - システムのログを目で見て確認するのが辛い
メール本文のシステムのログから入力値や処理したレコード数などを確認をしていました。
バッチによって確認箇所が違うため、バッチのマニュアルを見ながら実施する手間が非常に多くかかっていました。
メール内容は基本的にフォーマットが決まっていたため、チェックをスクリプト化し、社内の連絡ツールであるSlackに通知しました。
Slackへの通知は下記のような形にしました。
これにより下記のようにカイゼンされました。
- バッチの確認結果がまとめて通知されるようになった！
- バッチの成功・失敗がアイコンになって一目で分かるようになった！！
３.バッチの成否をRundeckで判別して通知
毎日「成功しました！」という通知を見続けると「見なくていいのでは？」と思いませんか？
- 何もしなくていい通知を確認するのが辛い
バッチが失敗したらSlack通知するようにしました。
これにより下記のようにカイゼンされました。
- 問題がない時は、何もしなくて良くなった！
- 問題が発生した時だけ確認作業が発生するため、異常の調査への着手が早くなった！！
４.バッチの実行をワークフロー化
cron運用時の問題がそのまま残っていました。
バッチの前後関係を把握するのが辛い
バッチは実行時間から推測したタイムスケジュールで管理していたため、問題の発生したバッチに異常がない場合、直前のバッチに問題が見られることがあります。
異常時の対応が遅れると雪だるま式にエラーが増えて確認するのが辛い
タイムスケジュールによる管理のため、直前のバッチの結果はお構いなしで実行されます。ひどい日はエラーまみれです。
タイムスケジュールで管理していた前後関係のあるバッチをRundeckのJob Workflowsでまとめました。
これにより、下記のようにカイゼンされました。
- バッチが失敗したら後続は停止！
問題のあったエラーだけが通知され、異常時の調査が行いやすくなりました。 - 次のバッチの待ち時間が減少！！
全体の実行時間が短縮されました。 - バッチの前後関係が分かりやすい！！！
タイムスケジュールを覚えていなくても実行すべきバッチが把握できるため、復旧対応を行いやすくなりました。
さいごに
運用業務をカイゼンすることができましたが、やれることはまだまだあります。
最終的には人が監視しなくても全自動で復旧したいです。
ポイントグループは、小さいカイゼンを繰り返して最終的に良いものを作っていくことが多いです。
１つ１つは小さいため、不慣れな作業でも誰でも作業に入りやすく、分からない時はペアプロなどで一緒に考えてくれます。
それにより最終的にチームメンバー全員がなんでもできるようになってきていると感じます。
私の所属するポイントグループでは一緒に働いてくれる仲間を募集しています。
ご興味のある方はぜひ下記募集ページをご確認ください。
dmm-corp.com