古のバッチサーバを葬るための技術
データ基盤ひとりAdventCalendarの19日目の記事になります。
データ基盤に関連した内容について学んだことを@takegue がまとめていきます。
内容については随時加筆/修正等を行なっていく予定です。
修正等の指摘ありましたらご連絡いただけると幸いです。
みなさんの中には「全容が誰にも把握されていない」もしくは「誰も触れない」忘れ去れしバッチジョブサーバを見たことはありませんか？
使われているのかいないのかもよくわらかない大量のプロセスが動いているサーバで行う作業はとても怖いものです。
インスタンス自体に何かのソフトウェアアップデートをかけようものなら、見たこともないジョブが突然落ちたりする経験は精神衛生上あまりよいもではありません。
放置していれば動きはし続けるのですが、こういった類は時間がたてばたつほど利用している
ソフトウェアが古くなることから移行のコストが上がります。
今回は、著者個人の経験としてデータ基盤にまつわる古のバッチサーバを葬り去ったことがあり
その経験のもと、何かしらのバッチサーバの移行をなんとかしたいと考えている方々への
tipsを残せればと思い記事を書きます。
- すべてのコードをバージョン管理にコピーしバックアップをとる
まずはじめにすべきことが、コードのバックアップです。
バッチサーバで動作するジョブに関わる全てのコードをgitリポジトリで管理できるようにしましょう。
- /etc配下の各種ミドルウェアの設定ファイル
- crontabなどの設定
- データベースの設定
- 各種ジョブの動作に利用されているコード群全て
またコード以外に次のような情報もバックアップとしてどこかに残しておけるとベストです。
- 利用されていると考えられるミドルウェアのバージョン情報
- Dockerコンテナが動作している場合にはコンテナのイメージのバックアップ
- 動き続けているコンテナの場合には docker commitを通してイメージを作成後にバックアップ
- /var/log 等にあるログ情報
- ファイルやディレクトリの配置構造
- treeコマンド等で残しておく
ここらへんの備えはあればあほど困ることはないため、思いつく限り残しておきましょう。
2. 各ジョブ動作を把握する(監視系をいれる)
基本的に何が動いているかを把握せずにエイやでやってはいけません。
古のサーバであろうとどういったジョブが動作しているかを確認する必要があります。
Datadogやmackerelなどのお手元のSaaSの監視サービスでもこの機能が用意されていると思います。
古のバッチサーバでは、cronを通して様々なジョブが動いていたのですが
プロセス監視用の監視用に僕の場合は次のようなスクリプトを書いてジョブの確認をしました。