こんにちは。SREチーム インフラエンジニアの綿引です。
今までMySQLの記事ばかり書いておりましたが、
今回は運用面の話でも書かせて頂こうと思っております。
結論から申し上げると、
GitLabのバックアップが原因でサーバの容量が切迫したため
バックアップ世代数を変更して問題解決しました。という内容です。
何かの参考にして頂けたら嬉しいです。
1. 事象確認から原因特定まで
弊社では様々なツール類を使用しておりますが、
その中ではGitLabも一部使用しています。
ある時、そのGitLabを搭載しているサーバの
特定のパーティションの使用率が95%になっていることが分かりました。
「あっやべっ、、」
きっとその時にはこんな顔をしていたことでしょうが、
内心はこっちです。
いつでも使用率というのは怖いもので、
ストレージ容量や増加率にもよりますが95%という数字は少し焦ります。
判明した段階で早速原因調査に移りました。
$ du -h | grep [0-9]G [/html]
上記コマンドで判明したのは”gitlab/backups”が
多くの容量を使用しているということでした。
次にGitLabの設定を確認します。
gitlab_rails['backup_keep_time'] = 5184000
※ 5184000/24/60/60 = 60 世代保存
60世代保存らしいので、設定が効いているかを確認します。
$ ls -l gitlab/backups | wc -l
上記の結果から設定自体は効いていることが判明。良かった。。
ただ1日分のバックアップ容量が増加していたため、
当時は問題なかった全体容量も微増したよう。
そこで先輩と相談しバックアップ世代数を10世代程度に減らすことに。
2. 対応！
・30世代残す場合
gitlab_rails['backup_keep_time'] = 2592000
・10世代残す場合
gitlab_rails['backup_keep_time'] = 864000
今回は10世代残す方向で進めました。
設定ファイルを変更し、以下のコマンドを実施。
● 設定ファイル反映
$ sudo gitlab-ctl reconfigure $ sudo gitlab-ctl restart
cronの設定が以下なので、午前2時に無事容量が下がったことを確認。
0 2 * * * /gitlab/bin/gitlab-rake gitlab:backup:create > /dev/null 2>&1
これらで対応完了です。
またAWSのS3などを使用していれば、バックアップ先としてそちらも対象にできるみたい。
まとめ
今回は日常ベースの話でしたが、今度は技術検証の話も書きたいです。
ご清覧頂きありがとうございました。
Wedding Parkでは一緒に技術のウエディングパークを創っていくエンジニアを募集しています。
興味のある方はぜひ一度気軽にオフィスに遊びにいらして頂ければと思います。
