サーバのディスクを整理した話

あけましておめでとうございます。 本年もEatSmartシステム部ブログをよろしくお願いします。 新年最初の記事としては地味ではありますが、昨年末に行ったサーバのディスク整理について書きたいと思います。

昨年インフラをデータセンターからクラウドへ移行したことは以前書きました。当時のディスク使用量と増加分を見込んで、サーバのスペックの選定を行いました。 年明けからインフラを増強する計画があり、それに伴いディスクの使用量を確認したところ、当初の見込みより増加のペースが早いことがわかりました。 当初の見込みよりペースが早くなった要因は、主に以下の５つでした。

Dockerの不要なイメージ

クラウドへ移行してから、全てのサービスはDockerコンテナで稼働しています。 このため、以前に比べDockerイメージの数が増えたこと、テストや検証に伴いDockerイメージを作成することが増えたことで、ディスク使用量が増えていました。 不要なDockerイメージを削除するため"docker system prune"を実行しました。

docker system prune | Docker Documentation

この作業で、サーバによっては100GB弱の容量を確保することが出来ました。

Jenkinsのビルド履歴

基本的に全てのジョブで"古いビルドの破棄"を指定することにしており、不要なファイルが残らないようにしています。 同様に成果物も保存していません。これはDockerイメージとして残しているためです。 この設定がされていないものがあり、ディスク使用量が増えていました。 正しく設定することで、数GBの容量を確保することが出来ました。

ログの転送漏れ

バッチ処理等で出力されるログファイルは、全てログサーバへ転送し、一定期間が過ぎるとアーカイブされる仕組みになっています。 Dockerコンテナで稼働するバッチ処理で、ログの出力先が以前と変わったために上記の転送対象から外れてしまっていたものがありました。 この他、td-agentで集約するログの対処もされていなかったので、転送と削除を行うようにしました。 これにより、数十GBの容量を確保することが出来ました。

一時ファイルの削除忘れ

各種検証やログ解析のために一時的に作成したファイルが残っていました。 絶対的な量は少ないですが、これも削除しました。

まとめ

サービスは正常に稼働しており、またディスク使用量が閾値より少ない状態だったので、気付くのが遅れてしまいました。 以上の作業で、当初の見込みとほぼ変わらない増加ペースに戻すことが出来ました。