バッチ処理の運用について経験したことから書いてみます
こんにちは！！
Uniposアドベントカレンダー202220日目です！
僕は現在UniposでSREチームでSREエンジニアとして働いています。
この記事は Google Cloud Workflowsを用いたバッチ処理の構成の続きなので、ぜひまずはそちらを読んだあとにこの記事を読んでみてください。
この記事について
この記事では、バッチ処理に関して組織で運用することを考えてどういう設計にすべきか、また作ったあとにどうすれば組織に運用が浸透するのか、を僕の経験に基づいて書こうと思います。
現在バッチ処理をどう設計すればいいかなどに迷っている人の参考になればと思います。
また、前の記事で説明しているGoogle Cloud Workflowsの利用を前提としているので、ワークフローという言葉はGoogle Cloud Workflowsのワークフローを指しています。
バッチ処理の運用
主な運用は以下の２つがあると思います。
- 処理の追加や修正
- エラーが起きたときに、実行されなかった処理やデータのリカバリ
この記事ではこの２つに焦点を当てて話していきます。
前提の話
この話を書く前提で、僕が思っているバッチ処理の特徴を説明します。
特にマイクロサービスを採用している場合、それぞれのバッチ処理は各マイクロサービスに属すると思います。
それらの実行順序を制御する必要がある場合、マイクロサービスをまたいで処理フローを制御するワークフローが必要になります。この、マイクロサービスや責務をまたいで何か処理する必要があることが運用する上で鍵になってくると思っています。
（マイクロサービスの切り方が悪いのでは？という意見もあると思いますが、ここではいったんそこは考えずに進みます。可能ならマイクロサービスの切り方を直して解決できる場合そうするほうが懸命だと思いますが、必ずしも選択できる選択肢では無いと思うので。）
処理の追加や修正
上記の特徴を踏まえた上で、UniposではマイクロサービスをまたぐワークフローのオーナーはSREチームとしました。
この時「各マイクロサービスのオーナーが新しいバッチ処理を追加したい場合、SRE管轄のワークフローへの修正」がネックになり、開発チームの改善活動が行いづらくなってしまう問題が起こりました。
この問題への解決策として、「SREチーム管轄のワークフローのPRは超簡単になる」ようにした上で、「マイクロサービスのオーナーが自分で必要な実装をし、PRをSREチームへ出す」形にしています。
この、「SREチーム管轄のPRは超簡単になる」がすごく大事で、ここが難しいとみんな手が出せずに、バッチ処理の改善や、修正があまり行いづらくなります。
具体的には、Uniposでは配列にワークフロー名を追加するだけで既存の処理の流れに組み込める、としたことで開発者も1行のPRで済むので修正や改善の変更の負担が少ない。SREも1行のPRを見ればいいだけなので楽。という形にしています。
こうすることで、マイクロサービスをまたぐ処理部分の修正がネックで開発チームの改善活動が妨げられることを避けられました。
バッチの復旧
どこかの処理がコケてしまうと、そのデータを前提にする処理は当然コケます。これがサービスを跨いでいた場合、
- コケた処理がどれで、なぜ失敗したかを調べる
- どのサービスオーナーへ復旧の連絡をすべきかを判断する
- 復旧のために処理の順序などを気にする必要があるかを考える
など、復旧にあたり複数考えないといけないことが出てきます。
改善初期は、失敗した箇所から復旧するという方針で、復旧の手順自体は復旧時間をパラメータとしてボタンを押すだけと言うもので、手順自体は簡単なものにしていました。しかし、思ったよりも復旧の方法が浸透せず、発見した人が僕を呼んで僕が復旧するという形になってしまいました。
その時、どこから復旧すればいいかをlogから追って判断するということがネックになっていることに気づきました。
それらを加味して、Uniposでは一連のすべてのバッチ処理に冪等性をもたせ、どんな失敗でも処理の最初から再実行すれば復旧できるという形を採用しました。
こうすることで、誰でも全く同じ手順で簡単に安心して復旧できるので、エンジニアは失敗を見つけても焦ることなく安心して手順に従って復旧することができるようになります。
この復旧が複雑になってしまうと、いくら復旧のドキュメントや仕組みを用意しても、分かる人に頼らないと安心して復旧できない。という事態を招いてしまいます。
これは、自サービスや自分の責務以外のことも知らないと安心して復旧できないという状況になっていることがおかしいと思っています。皆安心して復旧出来なくて当たり前なのですが、そのことに気づけていませんでした。
まとめ
ここまで書いたことは当たり前は当たり前なのですが、バッチ処理では必ずしも問題があった場所に詳しいエンジニアが対応するとは限らないことがあると思います。（早朝のバッチの失敗で気づく人が限られているとか）
だからこそ、バッチ処理の変更や復旧のオペレーションは誰でも簡単に安心して作業を行える状態を目指すのが重要と思います。
書きながら、組織の大きさやシステムのフェーズも関係するだろうから一概には言えないだろうなと思いましたが、もしバッチ処理の設計で迷ったときに役立てば幸いです。
Discussion