カテゴリー: 未分類

なぜ「満杯になってから」では遅いのか

ディスクの空きがなくなると、サービスは思いがけない形で壊れます。ログが書き込めずにアプリケーションが止まる、データベースが更新を受け付けなくなる、メールが届かなくなる、そもそもSSHでログインした直後にシェルの設定ファイルすら書けない、といった具合です。しかも原因が「ディスク容量」だと気づくまでに、アプリケーション側のバグを疑って時間を失うことも少なくありません。

容量不足は、突然起きるように見えて、実際にはじわじわと進行していることがほとんどです。つまり、日ごろから変化に目を向けていれば、止まる前に手を打てる種類のトラブルです。この記事では、特別なツールを入れなくても始められる「気づくための習慣」を整理します。

まずは現状を知る：2つのコマンド

最初に覚えておきたいのは、使用量を見る df と、どこが大きいかを探す du の2つです。

• df -h：ファイルシステムごとの容量、使用量、使用率を人間に読みやすい単位で表示します。
• du -sh /var/log/*：指定したディレクトリ配下の項目ごとの合計サイズを表示します。「どこが太っているか」を順にたどって絞り込めます。
• df -i：inode の使用状況を表示します。

見落としやすいのが最後の inode です。小さなファイルが大量にできると、容量には余裕があるのに新しいファイルが作れなくなることがあります。セッション情報やキャッシュ、メールキューなどを大量に生成するシステムでは、容量とあわせて確認しておくと安心です。

習慣その1：使用率ではなく「増え方」を見る

使用率70%という数字だけでは、安全かどうか判断できません。1年かけて70%になったのか、先週まで30%だったのかで、意味がまったく違うからです。そこで、使用量を定期的に記録して、増加のペースを見る習慣をつけます。

難しく考える必要はありません。cronで1日1回、日付と df の結果をファイルに追記するだけでも十分です。数週間たまると、「このペースなら何日後に埋まりそうか」がおおまかに見えてきます。グラフ化できる監視ツールがあればなお良いですが、まずは素朴なテキストの記録でも、何も見ていない状態とは大きな差があります。

習慣その2：しきい値を2段階にして通知する

通知は「警告」と「危険」の2段階に分けておくと運用しやすくなります。たとえば次のような考え方です。

• 警告：使用率が一定の水準を超えたら、翌営業日までに確認すればよい通知として届ける。
• 危険：さらに高い水準に達したら、すぐ対応が必要な通知として届ける。

具体的な数値は、ディスクの大きさや増加ペースによって適切な値が変わります。数百GBのディスクで残り10%といえば数十GBの余裕がありますが、小さなディスクでは同じ10%でも数日で消えてしまうかもしれません。使用率だけでなく、残り容量の絶対値や「あと何日もつか」で考えるのが現実的です。

また、通知が多すぎるとやがて誰も見なくなります。最初はゆるめのしきい値で始め、実際に空振りが続くようなら調整するくらいの気持ちで十分です。

習慣その3：増えやすい場所をあらかじめ知っておく

容量を食う場所は、システムによってある程度パターンが決まっています。自分の環境で次の場所を一度見ておくと、いざというときに慌てません。

• ログ：/var/log 配下。ローテーションの設定が効いているか、古いログが残り続けていないかを確認します。
• パッケージのキャッシュ：パッケージ管理ツールが保持しているダウンロード済みファイル。
• コンテナ関連：Docker を使っている場合、未使用のイメージや停止したコンテナ、ボリュームが蓄積します。
• バックアップや一時ファイル：消し忘れた古いバックアップ、/tmp に残ったままの作業ファイル。
• データベースのデータやバイナリログ：サービスの成長とともに確実に増えていきます。

とくにログは、ローテーションと保持期間を決めておくだけで、多くの問題を未然に防げます。「何日分残すか」を意識的に決めていないログは、いつか必ず大きくなります。

習慣その4：削除したのに空かない問題を知っておく

大きなファイルを消したのに、df の使用量が減らないことがあります。これは、削除したファイルをまだ動作中のプロセスが開いたままにしている場合に起こりえます。ファイル名は消えていても、プロセスが掴んでいる間は領域が解放されません。

このような状況では、lsof などで削除済みのファイルを開いているプロセスを調べられます。ログファイルを手動で消すより、ローテーションの仕組みを使ったり、内容を空にしたりするほうが安全な場合もあります。ただし、本番環境での操作は影響を確認してから行ってください。

習慣その5：消す前に、中身を見る

容量が逼迫すると、焦って大きなものから消したくなります。しかし、何のファイルか確認しないまま削除するのは危険です。データベースのファイルやアプリケーションが参照中のデータを消せば、容量の問題が別の障害に変わります。

消してよいものと、そうでないものの一覧を、平時に簡単なメモとして残しておくと役立ちます。「このディレクトリのキャッシュは消してよい」「ここは触らない」といった一言のメモが、緊急時の判断を支えてくれます。

週5分の点検ルーティンにする

ここまでの内容を、続けやすい形にまとめると次のようになります。

• 週に1回、df -h と df -i を確認する。
• 前回からの増え方を見て、気になる場合は du で原因の場所を絞る。
• ログのローテーションが動いているかを時々確認する。
• 通知のしきい値が現状に合っているかを、月に一度見直す。

この程度なら、5分もかかりません。大切なのは、完璧な監視体制を一度に作ろうとせず、小さく始めて続けることです。

まとめ

ディスクの空き不足は、前兆のある数少ない障害のひとつです。使用率だけでなく増え方を見ること、通知を段階に分けること、増えやすい場所を把握しておくこと。この3点を押さえるだけで、「気づいたときには止まっていた」という事態はぐっと減らせます。まずは今日、手元のサーバーで df -h を実行してみるところから始めてみてください。

はじめに：鍵認証は「設定する順番」が大切

SSHの鍵認証は、パスワード認証よりも安全にサーバーへ入るための基本的な仕組みです。ただ、初めて設定するときは手順を間違えて、自分自身がサーバーに入れなくなるという失敗が起こりがちです。この記事では、設定の流れそのものよりも、つまずきやすい点と事前に気をつけたいことを中心にまとめます。

大まかな流れは、手元のPCで鍵のペアを作り、公開鍵をサーバーに登録し、鍵でログインできることを確認してから、必要に応じてパスワード認証を止める、というものです。最後の「確認してから」という順番がとても重要です。

1. 秘密鍵と公開鍵の役割を取り違えない

鍵認証では、2つのファイルがペアになります。

• 秘密鍵：自分の手元だけに置く。他人に渡さない、サーバーにも置かない
• 公開鍵：サーバーに登録するもの。拡張子は一般に .pub

初心者がやりがちな間違いは、秘密鍵のほうをサーバーに登録してしまうことや、秘密鍵をチャットやメールで共有してしまうことです。共有してよいのは公開鍵だけです。秘密鍵が漏れた場合は、その鍵を使っているすべてのサーバーから公開鍵を外し、鍵を作り直す必要があります。

2. 鍵の種類はEd25519を基本に考える

鍵を作るには ssh-keygen コマンドを使います。現在は、短くて扱いやすく、広く対応されているEd25519方式が第一候補になります。例は次のとおりです。

ssh-keygen -t ed25519 -C “用途がわかるコメント”

ただし、古い機器やサービスがEd25519に対応していない場合は、RSAで十分な長さ（たとえば3072ビット以上）の鍵を選ぶことになります。接続先の対応状況は、事前に確認しておくと安心です。

3. パスフレーズは必ず設定する

鍵を作るとき、パスフレーズを聞かれます。面倒で空のままにしたくなりますが、設定しておくことをおすすめします。パスフレーズがあれば、秘密鍵のファイルが盗まれても、そのままでは使われにくくなります。

毎回の入力が負担になる場合は、ssh-agent を使うと、一度入力すればしばらく覚えていてくれます。「パスフレーズなし」と「毎回入力」の間には、ssh-agent という現実的な選択肢があります。

4. 公開鍵の登録は ssh-copy-id が楽で確実

公開鍵はサーバー側の、ログインするユーザーのホームにある .ssh/authorized_keys に1行として追記します。手作業でもできますが、改行が入ってしまう、途中で切れるといったミスが起こりがちです。

ssh-copy-id が使える環境なら、次のように実行すると、保存先の作成や権限の設定も含めて任せられます。

ssh-copy-id -i ~/.ssh/id_ed25519.pub ユーザー名@ホスト名

この時点では、まだパスワード認証でログインできる状態であることが前提です。だからこそ、パスワード認証を先に止めてはいけません。

5. パーミッション（権限）の間違いは定番の失敗原因

鍵認証がうまくいかない原因として、とても多いのが権限の問題です。SSHサーバーは、設定ファイルや鍵ファイルが他のユーザーから書き込める状態だと、安全でないと判断して鍵を無視することがあります。目安は次のとおりです。

• サーバー側の .ssh ディレクトリ：700
• サーバー側の authorized_keys：600
• 手元の秘密鍵：600

ホームディレクトリ自体が、グループや他人から書き込める設定になっている場合も、同様に拒否されることがあります。ssh-copy-id を使うと、これらが整いやすいのも利点です。

6. パスワード認証を止める前に、別の窓で確認する

鍵でログインできるようになったら、セキュリティを高めるためにサーバー側でパスワード認証を無効にするのが一般的です。設定ファイルは多くの環境で /etc/ssh/sshd_config で、PasswordAuthentication を no にします。ただし、ディストリビューションによっては設定を分割したディレクトリ側で上書きされていることがあるため、変更が効いているか確認が必要です。

ここで一番大事な注意点があります。

• 今つないでいるログイン中のセッションは、閉じずに残しておく
• 別のターミナルを新しく開き、鍵だけでログインできるか試す
• 設定を変えたら、sshd の設定内容を事前にチェックしてから再読み込みする

設定に誤りがあってもログイン済みのセッションが残っていれば、すぐに元へ戻せます。逆に、全部閉じてから失敗に気づくと、クラウドのコンソールや物理的なアクセスがなければ復旧できないことがあります。

7. 鍵は用途ごとに分け、バックアップと棚卸しもする

最初は1つの鍵をあらゆる場所で使い回しがちですが、長く運用するなら、PCごと、あるいは用途ごとに鍵を分けるほうが安全です。1つが漏れても被害を限定でき、不要になった鍵を外すのも簡単になります。コメント欄に用途や作成した年を書いておくと、あとで authorized_keys を見たときに判別できます。

また、PCが壊れて秘密鍵を失うと、鍵だけでしか入れないサーバーには入れなくなります。次のような備えを考えておくとよいでしょう。

• 別の鍵をあらかじめ登録しておく
• クラウドのコンソールなど、SSH以外の入口を確認しておく
• 退職や機器の入れ替えのときは、不要な公開鍵を削除する

つまずいたときの調べ方

ログインできないときは、手元で ssh -v ユーザー名@ホスト名 のように詳細表示を付けて実行すると、どの鍵を試し、どこで拒否されたかが分かります。サーバー側ではSSHのログを確認すると、権限の問題や設定の誤りが書かれていることが多いです。当て推量で設定をいじるより、まずログを見るのが近道です。

まとめ

SSH鍵認証の初期設定で大切なのは、次の点です。

• 共有してよいのは公開鍵だけ。秘密鍵は守る
• パスフレーズを付け、必要なら ssh-agent を使う
• 権限の設定を正しく整える
• パスワード認証を止める前に、別のセッションで鍵ログインを確認する
• 鍵は用途ごとに分け、失ったときの入口も用意しておく

仕組み自体は難しくありません。順番を守って一歩ずつ確認しながら進めれば、安全で快適なログイン環境が手に入ります。

毎朝の作業は「忘れない仕組み」に任せる

毎朝やっている作業は、一つひとつは小さくても、積み重なると意外に時間と集中力を奪います。ログの確認、バックアップの状態チェック、レポートの生成、一時ファイルの掃除などがその例です。こうした作業は、人間が覚えておくより、仕組みに任せるほうが確実です。

Linux では、その定番の道具が cron です。決まった時刻にコマンドを実行する、とても素朴な仕組みですが、素朴だからこそ設計の考え方が結果を大きく左右します。この記事では、コマンドの書き方ではなく、続けられる自動化にするための考え方を整理します。

まず「自動化してよい作業」かを見極める

何でも cron に載せればよいわけではありません。自動化に向いているのは、次のような性質を持つ作業です。

• 手順が毎回ほぼ同じで、判断を挟まない
• 失敗しても、やり直しが簡単である
• 実行したかどうかを、あとから確認できる

逆に、途中で人間の判断が必要な作業や、一度の失敗が大きな被害につながる作業は、そのまま自動化しないほうが安全です。その場合は、「準備や下ごしらえだけを自動化し、最後の確定は人が行う」という分け方が現実的です。

手で動くことを先に確認する

cron に登録する前に、同じコマンドを手で実行して、期待どおり動くことを確認します。これが最も基本で、最も効果のある習慣です。

そのうえで、作業を一本のシェルスクリプトにまとめ、cron からはそのスクリプトを呼ぶだけにします。crontab に長いコマンドを直接書くと、読みにくく、テストもしにくくなります。スクリプトに分ければ、手で試せるうえ、バージョン管理もしやすくなります。

cron の環境は対話シェルと違う

自動化でつまずく原因として、とても多いのが環境の違いです。cron が実行するときの環境変数は、普段ログインして使っているシェルより最小限です。特に PATH が短く、手では動くコマンドが cron からは見つからない、ということがよく起こります。

対策としては、次のような方法があります。

• スクリプト内で、コマンドをフルパスで書く
• スクリプトの冒頭で、必要な環境変数を明示的に設定する
• 相対パスに頼らず、作業ディレクトリを明示的に指定する

「手で動いたのに cron では動かない」ときは、まず環境の差を疑うと、原因にたどり着きやすくなります。

結果を残す：ログと通知の考え方

自動化の最大の落とし穴は、静かに失敗し続けることです。動いていないことに数週間気づかない、という事態は珍しくありません。そこで、実行結果を残す工夫を最初から入れておきます。

• 標準出力と標準エラー出力を、ログファイルにまとめて記録する
• ログには実行開始と終了の時刻を入れる
• 失敗したときだけ、メールやチャットなどで知らせる

通知は「成功のたびに届く」形にすると、すぐ読まれなくなります。失敗したときだけ目立つ形にしておくと、通知が来た時点で確実に気づけます。ただし、失敗の通知だけでは、スクリプトがそもそも起動しなかった場合には何も届きません。そのため、たまに「最近の実行記録があるか」を確認する習慣も、あわせて持っておくと安心です。

二重実行と実行時間に備える

毎朝の処理が、想定より長引くことがあります。前回の処理が終わらないうちに次の実行が始まると、同じファイルを同時に触って、データが壊れることもあります。

これを防ぐには、ロックの仕組みを使うのが定石です。たとえば flock コマンドを使えば、すでに実行中なら新しい実行を始めない、という制御を簡単に入れられます。また、処理を何度実行しても結果が同じになる「冪等」な作りにしておくと、失敗後の再実行も怖くなくなります。

時刻の決め方にも工夫がある

実行時刻は、なんとなく「朝の 9 時ちょうど」に決めがちです。しかし、自分だけでなく複数のジョブが同じ時刻に集中すると、負荷が重なります。少しずらして、切りのよくない時刻にするだけで、衝突を避けやすくなります。

また、作業の結果を使うのが何時なのかから逆算して決めることも大切です。たとえば出勤して確認するレポートなら、その少し前に終わるよう余裕をもって設定します。サーバーのタイムゾーン設定も、一度確認しておくとよいでしょう。思っていた時刻とずれていた、という失敗は意外と多いものです。

育てながら続ける

最初から完璧な仕組みを作ろうとすると、手が止まります。おすすめは、次のような順序で小さく始めることです。

• 手で毎日やっている作業を、一つだけ選ぶ
• スクリプトにして、手で動作を確認する
• cron に登録し、ログを残す
• しばらく様子を見て、失敗の通知や二重実行の対策を足す

また、何を、なぜ、いつ自動化したのかを、スクリプトの冒頭にコメントとして残しておくと、将来の自分や引き継ぐ人が助かります。cron の設定は、数か月後には存在そのものを忘れてしまいがちだからです。

まとめ

cron による自動化は、コマンドを一行書いて終わりではなく、「確実に動き、失敗に気づけ、あとから理解できる」状態までを含めた設計です。作業を見極め、スクリプトに分け、環境の違いに備え、結果を記録し、二重実行を防ぐ。この流れを押さえておけば、毎朝の作業を安心して手放せます。まずは小さな一つの作業から、試してみてください。

WordPress へようこそ。こちらは最初の投稿です。編集または削除し、コンテンツ作成を始めてください。