Retty インフラチームの中西です。 今回は バッチサーバのリプレースを行ったお話になります。
バッチサーバについて
Rettyのサービス黎明期から存在しているサーバでEC2インスタンスとなります。
(EC2-Classic で起動していた事から歴史を感じるサーバとなっています)
バッチとしてはそれぞれ crontab に登録をして.データの整備や集計処理を行っています。 このサーバには課題が多々含まれており、インフラ、開発からの有志としてチームを組みワーキンググループ(以下WG)として課題解決を行うことになりました。
WGの活動期間としては2021/3 -> 2022/11となります。
課題について
WGメンバ内で話し会い、改めて課題の洗い出し、掘り下げを行いました。
以下は課題の一部となります。
1. EC2-Classic からの脱却
- EC2-Classic は2022年8月15日にEOSとなったため使用することができなくなる
2. セキュリティ
3. ログ管理
- バッチ実行時のログデータがサーバ内に記録されており、サーバにsshログインしないと確認することができない
4. バッチについての管理、情報がない
- 1の対応としてバッチの移行が必要である
- 元のバッチに対してのドキュメント等が無く、移行後の動作確認の成功基準がない
- 2のセキュリティ面が問題でバッチ実行時のスクリプトがGitHub管理されていない
- 同様に crontab の内容、履歴が管理されていない
- 各バッチの登録の経緯が不明でありドキュメントがない
- メンテナンスがされていないバッチがあり、不要となっているバッチもあるかもしれない
課題に対する対応
各課題については以下の様に対応を行っていきました。
1. EC2-Classic からの脱却
EC2-Classic からAMIを取得してもVPCのEC2としては起動できないので、単純なAMIコピーは不可能でした。
その為、現行のバッチサーバの調査（ファイル構造やミドルウェア、起動プロセス等）を行い、新規のEC2を起動して手動での構築を行いました。 これでVPCで起動できる事によってAMIの取得、復旧ができるようになりました。
ログインに関してはSession Manager を通しての ssh ログインを行うように設定し、構築時の情報や構成と併せてドキュメントの作成、共有を行いました。
2. セキュリティ
センシティブな情報に関してはサーバ内に記入せず環境変数の登録時に AWS Secrets Manager から取得する処理を追加して秘匿を行いました。
具体的な対応手順としては以下となります。
(例)
SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id retty-batch-prod/secrets | jq -r '.SecretString' | jq -r .SECRET_VALUE)
これでバッチスクリプトや crontab の内容を GitHub で管理することができ、セキュリティの向上となりました。
3. ログ管理
ログ管理に関しては新しく作成したバッチサーバに CloudWatch Logs の設定を行いました
- 新バッチサーバのインスタンスロールにIAMの権限を付与
- CloudWatch Logs Agent をインストール
- CloudWatch Logs に転送したいバッチのログファイルを設定
4. バッチについての管理、情報がない
以下の流れで対応を行いました。
旧バッチサーバの crontab に登録されているバッチのリストアップを行う 以下はリストの例となります
- ヒアリングで情報が集まらないバッチに関してはソース、スクリプトの確認を開発メンバと共確認を行う
- 3でも確認が取れない場合は本番サービスに影響のないテスト環境(サーバ、DBの複製)を用意して実行後の挙動確認を行う
上記の手順で全54件の
- バッチの内容確認
- 不要と判断したバッチの停止
- テスト環境での事前実行
- 旧サーバのバッチ停止
- 新サーバへのバッチ移行
を行いました。
結果として EC2-Classic の廃止前にバッチの移行、サーバリプレースを行うことができました。
振り返りについて
WG自体は2022/11 で一旦解散としてその前に振り返りを行いました。
良かったこと
やはり技術的負債の解消ができ成果を出せた事だと思います
- EC2-Classicからの脱却
- 不要なバッチのお掃除
- 秘匿情報のSecrets Managerへの移行
- 各種スクリプトやcrontabのGitHub管理と定期反映
- ログのCloudWatch Logs移行
またWGにおける進め方や学びの面としてはとしては以下の点になります
- バッチ移行や整備タスクでメンバ各自がパフォーマンスを出せた
- 週一の定例でモブプログラミングのように移行作業ができた
- 各バッチサーバやバッチの内容が把握できた
苦労したこと
- 移行するバッチの数が多く時間がかかった
- 幸い調査の中で不要なバッチが多く、WGの活動期間の前半に1/3以上対応することができた
- 移行が完了したという基準を決めづらかった
- ある程度決め打ち(DB更新があればOK)で行わざるを得なかった
- 各メンバがWG以外のタスクを持っていることもあり特定の期間は活動できなかった
- バッチの新基盤のアーキテクチャ設計、構築の予定もあったが着手はできなかった
- 必要性が増してきたら再度WGの活動や別プロジェクトとして実施していく予定
以上となります
まとめ
今回はワーキンググループを通して、インフラメンバとして開発チームと協業をしたお話でした。
こちらに関してはサービス、システムの課題解決のほんの一例でして先述の記事の通り取り組む課題はたくさん残っています。
弊社インフラエンジニアのポジションに興味を持った方は採用ページをご覧にいただければ幸いです。 hrmos.co
