サービス

ジャンル

職種：エンジニア

職種：ビジネス職

職種：デザイナー

職種：バックオフィス

職種：その他職種

技術

<h2>はじめに</h2>

<p>こんにちは！プラットフォーム事業本部ペイメントサービス部ポイントグループの大倉です。<br />
普段はDMMポイントに関するシステムの開発や保守、それと、この長い所属名を噛まずに自己紹介する方法について考えています。</p>

<div data-oembed-url="https://inside.dmm.com/entry/2020/02/17/pf-point-team">
<div>
<div style="left: 0; width: 100%; height: 140px; position: relative;"><iframe allowfullscreen="" src="//if-cdn.com/ZIkS4ZF?app=1" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" tabindex="-1"></iframe></div>
</div>
<script async="" charset="utf-8" src="//if-cdn.com/embed.js"></script></div>

<p>この記事では、ポイントグループのバッチ処理（以下、バッチ）をcronからRundeckに切り替えることで、カイゼンした運用作業について紹介します。</p>

<h2>ポイントシステムのバッチについて</h2>

<p>ポイントシステムはお金を扱うシステムのため、金額に間違いが発生しないようにするための突き合わせ処理が多いです。<br />
さらにデータも多いためリアルタイムで処理できない部分をバッチで補っています。</p>

<p>ポイントシステムは2015年に現行システムになり、稼働しています。</p>

<p>処理の多さ・稼働期間の長さから、Java製やPHP製など統一感なく多数のバッチが存在し、さらに複数のサーバに分散して実行されている状態でした。</p>

<h2>cronによるバッチと日々の運用業務について</h2>

<p>私がチームに配属された2017年9月頃の状態を説明します。<br />
日々の作業は、月毎に確認担当が二人設けられ、毎朝下記の作業を分担して実施していました。</p>

<h3>毎朝バッチの数だけメールを確認する</h3>

<p>cronサーバで実行しているバッチの結果は、各バッチ毎にメール経由で確認していました。</p>

<h3>バッチに異常があった場合、調査・修正を行う</h3>

<p>調査は、バッチの仕様を思い出すことから始まり、ログの確認・DBレコードの確認をします。<br />
修正は、DBレコードの修正・バッチの再実施が主になり、cronなので定期実行の停止・再開はサーバに入って行います。</p>

<p><img alt="" height="491" src="https://image.dmm-corp.com/xszi9pwjacihplbnib6somyj4qbk" width="681" /></p>

<h2>Rundeckによるバッチと日々の運用業務について</h2>

<p>現在のカイゼンされた状態です。<br />
日々の作業は、月毎の確認担当が一人になり、下記の作業を実施する形になりました。</p>

<h3>Slack通知が来たら確認する</h3>

<p>確認担当が自発的に確認するのではなく、通知がある場合のみ確認します。</p>

<h3>バッチに異常があった場合、調査・修正を行う</h3>

<p>調査は、Slack通知のリンクからログの確認を行い、必要に応じてDBレコードの確認をします。<br />
修正は、DBレコードの修正・バッチの再実施が主になり、定期実行の停止・再開はRundeckから行います。</p>

<p><img alt="" height="501" src="https://image.dmm-corp.com/rd36edeibut4szcp6tbhrbdad6yt" width="621" /></p>

<h2>カイゼンしていったこと</h2>

<p>ポイントグループは小さくカイゼンを繰り返し、現在の状態に至りました。<br />
ここからはどういうカイゼンを行ったのか？を説明します。</p>

<h3>１.cron &rarr; Rundeck</h3>

<p>cronだと基本的な作業が全体的に大変ですよね。</p>

<ul>
	<li>再実施するのが辛い<br />
	バッチ毎にそれぞれマニュアルがあり、それを見ながら関連サーバに接続して復旧や再実施をするのは大変です。</li>
	<li>スケジュール実行のON/OFFのためにサーバに接続してコンソールで操作するのが辛い<br />
	セキュリティエリアへの接続のための前準備や&quot;crontab -e&quot;でコメントアウトなど細かい面倒が多々あります。</li>
</ul>

<p>そこでcronで実行していたバッチをRundeckジョブからの呼び出しに変更しました。</p>

<blockquote>
<p><em>（※）Rundeckについて<br />
RundeckとはOSSのジョブスケジューラとなり、Webコンソール・コマンドラインツールおよびWebAPIを備えています。<br />
参考： <a href="https://www.rundeck.com/open-source">https://www.rundeck.com/open-source</a></em></p>
</blockquote>

<p><img alt="" height="501" src="https://image.dmm-corp.com/rrslmri8o7mzybkpxmeqkagwjh4h" width="551" /></p>

<p>これにより下記のようにカイゼンされました。</p>

<ul>
	<li>バッチのスケジュール実行の再開・停止・再実施がWebブラウザで可能になった！</li>
	<li>バッチのスケジュール実行の再開・停止・再実施が一箇所にまとまった！！<br />
	スケジュール実行の巻き戻し忘れでサーバを行ったり来たりしたのはもう過去の記憶です。</li>
	<li>バッチのパラメータが分かりやすくなった！！！<br />
	再実施するたびにcronに書かれた実行コマンドを見たり、資料確認をしなくても分かる安心設計になりました。</li>
</ul>

<p><img alt="" height="451" src="https://image.dmm-corp.com/4dwisybjoo7wmgpg3i9lu6672amr" width="800" /></p>

<h3>２.メールチェックをスクリプト化し、必要な情報のみSlackで通知</h3>

<p>システムのログを毎朝大量に見させられると機械になった気持ちになりますよね。</p>

<ul>
	<li>大量のバッチの結果をメールで確認するのが辛い<br />
	１バッチ１メールなので単純に全部開封するだけでも結構なクリック数になります。</li>
	<li>システムのログを目で見て確認するのが辛い<br />
	メール本文のシステムのログから入力値や処理したレコード数などを確認をしていました。<br />
	バッチによって確認箇所が違うため、バッチのマニュアルを見ながら実施する手間が非常に多くかかっていました。</li>
</ul>

<p><img alt="" height="278" src="https://image.dmm-corp.com/94345v6o1h9zunwjscc3qonfps8l" width="800" /></p>

<p>メール内容は基本的にフォーマットが決まっていたため、チェックをスクリプト化し、社内の連絡ツールであるSlackに通知しました。</p>

<p><img alt="" height="481" src="https://image.dmm-corp.com/lp0gkgvq6i5dtocnzrtkd4eur04w" width="592" /></p>

<p>Slackへの通知は下記のような形にしました。</p>

<p><img alt="" height="380" src="https://image.dmm-corp.com/y37oho6ju6tlpg5d0jty9vhg9by4" width="597" /></p>

<p>これにより下記のようにカイゼンされました。</p>

<ul>
	<li>バッチの確認結果がまとめて通知されるようになった！</li>
	<li>バッチの成功・失敗がアイコンになって一目で分かるようになった！！</li>
</ul>

<h3>３.バッチの成否をRundeckで判別して通知</h3>

<p>毎日「成功しました！」という通知を見続けると「見なくていいのでは？」と思いませんか？</p>

<ul>
	<li>何もしなくていい通知を確認するのが辛い</li>
</ul>

<p>バッチが失敗したらSlack通知するようにしました。</p>

<p><img alt="" height="481" src="https://image.dmm-corp.com/080prrq76rqk3cwip1tvfsm3amo9" width="592" /></p>

<p>これにより下記のようにカイゼンされました。</p>

<ul>
	<li>問題がない時は、何もしなくて良くなった！</li>
	<li>問題が発生した時だけ確認作業が発生するため、異常の調査への着手が早くなった！！</li>
</ul>

<h3>４.バッチの実行をワークフロー化</h3>

<p>cron運用時の問題がそのまま残っていました。</p>

<ul>
	<li>バッチの前後関係を把握するのが辛い<br />
	バッチは実行時間から推測したタイムスケジュールで管理していたため、問題の発生したバッチに異常がない場合、直前のバッチに問題が見られることがあります。</li>
</ul>

<p><img alt="" height="181" src="https://image.dmm-corp.com/nfr3ws4jrmkssi93kzmlzn04lzrj" width="800" /></p>

<ul>
	<li>異常時の対応が遅れると雪だるま式にエラーが増えて確認するのが辛い<br />
	タイムスケジュールによる管理のため、直前のバッチの結果はお構いなしで実行されます。ひどい日はエラーまみれです。</li>
</ul>

<p>タイムスケジュールで管理していた前後関係のあるバッチをRundeckのJob Workflowsでまとめました。</p>

<p><img alt="" height="397" src="https://image.dmm-corp.com/59uon4sgwbbnmq3d1cgg664tylsy" width="800" /></p>

<p>これにより、下記のようにカイゼンされました。</p>

<ul>
	<li>バッチが失敗したら後続は停止！<br />
	問題のあったエラーだけが通知され、異常時の調査が行いやすくなりました。</li>
	<li>次のバッチの待ち時間が減少！！<br />
	全体の実行時間が短縮されました。</li>
	<li>バッチの前後関係が分かりやすい！！！<br />
	タイムスケジュールを覚えていなくても実行すべきバッチが把握できるため、復旧対応を行いやすくなりました。</li>
</ul>

<h2>さいごに</h2>

<p>運用業務をカイゼンすることができましたが、やれることはまだまだあります。<br />
最終的には人が監視しなくても全自動で復旧したいです。</p>

<p>ポイントグループは、小さいカイゼンを繰り返して最終的に良いものを作っていくことが多いです。<br />
１つ１つは小さいため、不慣れな作業でも誰でも作業に入りやすく、分からない時はペアプロなどで一緒に考えてくれます。<br />
それにより最終的にチームメンバー全員がなんでもできるようになってきていると感じます。</p>

<p>私の所属するポイントグループでは一緒に働いてくれる仲間を募集しています。<br />
ご興味のある方はぜひ下記募集ページをご確認ください。</p>

<div data-oembed-url="https://dmm-corp.com/recruit/">
<div>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 52.5%; padding-top: 120px;"><iframe allowfullscreen="" src="//if-cdn.com/lYoH0j6?app=1" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" tabindex="-1"></iframe></div>
</div>
<script async="" charset="utf-8" src="//if-cdn.com/embed.js"></script></div>

<p>&nbsp;</p>


レガシーとの向き合い方　〜cron から Rundeck へ〜

facebook

twitter

DMM TV

DMMブックス

DMM pictures

DMM GAMES

DMMオンクレ

DMMスクラッチ

DMMくじ

DMM Factory

ぷらさぷ ～＋SURPRISE～

DMMオンラインサロン

DMMいろいろレンタル

DMM DVD／CDレンタル

DMM通販

DMMオンラインクリニック

デジタルコミック事業

DMMチャットブースト

DMM英会話

DMM FX

DMMかりゆし水族館

ベルリング

ハッシャダイソーシャル

ヤンキーインターン

シント=トロイデンVV

DMM 地方創生

DMM.make 3Dプリント

DMM.make PRODUCTS

Seamoon Protcol by DMM Crypto

DMMバヌーシー

DMM EV ON

DMM WEBCAMP

DMMぱちタウン

DMM競輪

Waitinglist

Algoage

DMMポイントクラブ

社会課題

エンターテインメント

動画

電子書籍

アニメ

ゲーム

アプリゲーム

コミュニティ

オンラインサロン

PCゲーム

通販

レンタル

オンラインイベント

ビジネスソリューション

教育

英会話

水族館

ハードウェア・プロダクト

救急車両

消防車両

モノづくり施設

サッカー

スポーツ

地方創生

VR体験

Web3

生成AI

研究開発

アプリ

ブロックチェーン

プラットフォーム

横断開発

社会インフラ

アミューズメント

ダイバーシティ

同人

Webエンジニア

フロントエンドエンジニア

バックエンドエンジニア

サーバーサイドエンジニア

モバイルエンジニア

SRE・インフラエンジニア

情報システム

データ・AI・機械学習エンジニア

エンジニアリングマネージャー

テックリード

プロジェクトマネージャー・ディレクター

プロダクトマネージャー

事業開発・経営企画

営業

マーケティング・プロモーション

企画・プロデュース

ゲーム企画・プロデュース

コンテンツ制作・編集

カスタマーサポート・運営

データ分析・ストラテジー

UI・UXデザイナー

Webデザイナー

2Dデザイナー・イラストレーター

デザインマネージャー

デザインリード

レガシーとの向き合い方 〜cron から Rundeck へ〜

シェア

レガシーとの向き合い方　〜cron から Rundeck へ〜