Case Study
株式会社MonotaRO

―PagerDuty Process Automation（旧Rundeck）をお使いいただいているということですが、どんなシステムで利用されているのでしょうか？

MonotaROのサイトをご覧いただいたときに皆さんがアクセスするECサイトと、基幹側の2つに分けられますが主に基幹側です。基幹側では300本ほどのバッチ（バッチ・ジョブ・プログラム）があって、そのうち80本のバッチはほかのバッチへの依存性があります。ECサイト側ではそれほど多くはありません。

もう少し詳しく言うと、PagerDuty Process Automationで管理しているのはAWS上とオンプレミス双方にある基幹系になります。PagerDuty Process Automation自体はAWS上で稼働しています。

過去にはバッチの実行を、以前はいわゆるcronでしていましたが、いくつか問題がありました。例えば順序に沿って実行すべき処理を実行させるときに、cronでは正常に終了したのか、いつ終了したのかが分からないので、時間をずらして実行させていました。だいたいこの処理ならこのくらいで終わるだろう、と見積もってスケジュールしていたのです。PagerDuty Process Automationならまず（cronに代わる）ジョブスケジューラーとして使える、つまり、依存性のあるバッチ処理のフローをスケジュールして実行させられるというので試してみました。2021年ごろでしたね。

(出典：MonotaRO Tech Blog)

―なぜEnterprise版にアップデートされたのでしょうか？

Community版では、PagerDuty Process Automationを実行させるサーバーを冗長構成にすることができません。当社としては確実にバッチ実行を管理する必要がありましたから、冗長化が可能なEnterprise版に移行するかどうかを検討しました。かなり重要度が高い処理をさせていますから、絶対に止めたくなかったのです。また、Enterpriseにはそのほかにも豊富な機能があります。例えば計画メンテンスなどに併せて、特定の日だけバッチを実行したり一時的に停止したりするような機能があります。それとは別に、ジョブのフローを複雑にした場合でも、PagerDuty Process Automationならシンプルに設計と管理ができるのではないかという意見もあり、Enterprise版を選びました。

―Enterprise版にアップデートされたのはいつでしょうか？

2022年の１月ごろです。社内にはエンジニアのグループが複数あるのですが、私のグループが概念検証（PoC）を担当しました。Enterprise版を導入してから、ほかのメンバーも触り始めています。総勢では40名になりますが、みんなが日常的に触る必要はないですし、バッチを動かす、とか、Cronにスクリプトを追加する必要がある場合に、実際に誰が作業をするかは、特に決めていません。

―PagerDuty Process Automationの効果はどう評価していますか？

まだ定量的な効果を出すのは難しいのですが、現時点でかなり楽になったと感じているポイントは、バッチサーバーをまたぐようなジョブの連携ができることです。Aというサーバーで処理が終わった後に、Bというサーバーで次の実行をする、ということができます。

これを以前はcron（コマンド）で時間を調整してやっていたのですが、難しかったところです。cronでは「たぶんこのジョブは終わっているだろう」と思って仕掛けたのに、実際には終わらないうちに、次のバッチが動くということがありました。逆にスケジュールに余裕を見すぎて無駄が発生していたりしました。設計上の問題もありますけれど、同時に動かせないバッチもあって、一種の排他制御が必要なものもあったのです。

PagerDuty Process Automationを使うと、どんなジョブを、いつ、どのサーバーで、どんな条件で動かすかを俯瞰しながら設定できます。

―インシデント対応時の手順の標準化にはお使いになっていますか？

いえ、今はまだバッチスケジューラーとしての活用にとどまっています。今後はインシデント対応などの運用用途でも使っていこうと思っています。例えば障害が起きたときに、ログの内容がこうだったらDBの値をこう変える、といった処理や操作の標準化までやれたらよいと思っています。インシデントに対するランブック（作業手順書）を拡充していきたいと思っており、インシデントの内容によっては、ランブックからPagerDuty Process Automationのジョブに誘導するようなことも考えています。

―どうもありがとうございました。