20年間誰もファイルを削除しなかった本番サーバーを整理した話
はじめに
私は、とあるウェブサービス運営会社の開発部でアプリケーションエンジニアとして働いている。
これは、私が仕事で経験した「20年間誰もファイルを削除しなかった本番サーバーを整理した」ときの話である。
経緯
大量の使途不明なディレクトリ
私が現在担当しているウェブサービス（以降「サービスA」と呼ぶことにする）のドメインは、社内では古いドメインで、昔から様々な用途に使われてきた歴史がある。しかし、そのほとんどは長年の間に規模が大きくなって別のサブドメインに分離していったり、逆にサービス終了したりして、現在の用途はサービスAのみに限定されている。
しかし、私はサービスAの担当になった当初から、このドメインのドキュメントルート（一番親のディレクトリ）の直下にやたらとディレクトリが多いことが気になっていた。どれもサービスAとは関係なさそうな名前のディレクトリばかりで、しばらく業務を続けてもそれらのディレクトリが必要とされる場面は全く無かった。
あるとき、サーバー上で1つのディレクトリの中を試しに覗いてみたところ、なんと空だった。別のディレクトリの中を覗いてみたところ、最終更新日が15年以上前のファイルが入っていた。さらに別のディレクトリの中には、「test」や「backup」といった名前を含む、本番環境に置いておくべきとは到底思えないファイルが大量に入っていた。
実は、このドキュメントルートに残された大量のディレクトリは、ほとんどが過去にこのドメインを使用した別サービスたちの残骸だったのだ。一番古いもので20年以上前のファイルが残っており、その頃からずっと誰も「使用を終えたファイルの削除」をしてこなかったのだ。
長年の見て見ぬふりの代償
なぜ誰も削除をしてこなかったのかは、様々な要因が重なってのことだとは思うが、社歴の長い人の話から私が想像する限りではおそらく以下のような理由だと思う。
サービス開始当初の黎明期に誤削除によるトラブルが発生し、ファイルの削除が禁忌となった。
社内のサービスが増えたためサービス間の依存関係が複雑になり、削除しても問題無いかの判断が難しくなった。
成長期には、全社的に「次にどんな新しいことをするか」「いかに会社の売上に貢献するか」が優先され、「終わったものの後始末」は価値の無い仕事と見なされた。
放置が長年くり返された結果、担当者も中身も分からなくなり、誰も手を付けられなくなった。
私も過去の人と同じように、見て見ぬふりをすることはできた。しかし、実はドキュメントルートには現在も運用中のディレクトリもいくつか混ざっているのである。つまり、「ほとんどはゴミだが、たぶんいくつかは必要」「でもどれが必要なのか把握してる人は誰もいない」というひどい状況だったのだ。
さらにもっと会社の信頼に関わる致命的な問題もある。ドキュメントルートにあるということは、つまりURLさえ分かれば世界中の誰でもアクセスできてしまうということなのだ。テスト用のファイルや、今では無効となった古い情報などが、一般のユーザーに見られてしまったり、Googleの検索結果に出てしまったりする可能性があるのだ。URLが知られることはないから大丈夫、とは言い切れない。ユーザーのタイプミスで「運用中のディレクトリと1文字違いのゴミディレクトリ」にアクセスされる可能性もある。（後述するが、この懸念は現実となってしまう。）
このあまりにひどい状況を、上長やサーバーを保守するインフラ関係者とともに目の当たりにし、ついにこのゴミだらけのドキュメントルートを整理するというプロジェクトが始まったのだった。
設定した最終目標
プロジェクト開始時点で、ドキュメントルートの直下には489個のファイルとディレクトリがあった。lsコマンドを叩くと画面が埋まる量である。最終的に目指す目標として、この489個の全てを、「削除する」か「担当部署を確定させる」かのいずれかに必ず持っていくこととした。
当初から空ディレクトリがやたらと多いことは分かっていた。静的なファイルを返すウェブサーバー上で、空ディレクトリというのは全く無意味な存在である。一方で、古いファイルばかりで不要そうだけど、一部が更新されていたりしてもしかしたら誰かが使ってるかもしれない…というよく分からないディレクトリも多かった。
そこで、「明らかに不要なディレクトリ」を対象とする【第1フェーズ】と、「必要か不要かよく分からないディレクトリ」を対象とする【第2フェーズ】の2つの期間に区切ってプロジェクトを進めていくこととなった。
第1フェーズ
明らかに不要なディレクトリの削除
まず最初は、100%不要であると断言できる空ディレクトリを削除した。なんとこれだけで142個もあった。
次いで、サーバーのアクセスログを1ヶ月間調査し、「アクセスが全く無いディレクトリ」と「アクセスがほとんど無いディレクトリ」を抽出した。これもかなりの数が見つかり、空ディレクトリとは別にさらに214個が該当することとなった。
こちらは念のため中身を一つずつ確認したが、どれも10～15年以上前のファイルだったり、明らかにバックアップ用やテスト用のファイルだったり、記載内容が古いままで現在では間違っていて公開してはいけない内容だったりするものばかりだった。これらも削除は問題無しと判断された。
削除にあたっては、万が一を考え、今回のプロジェクト専用の「ゴミ箱ディレクトリ」を作ってそこに移動する、という形をとった。また、古いディレクトリはファイルシステム上の権限の問題で変更不可なものが多かったため、root権限を持つインフラチームに毎回作業を依頼することとなった。インフラチームには依頼が重なり申し訳ない気持ちになったが、サーバー上を整理することに対しては、インフラ環境の負荷やリスクの軽減につながるため、インフラチームは大いに賛成してくれて心強い味方となった。
ここまでで、489－142－214＝133個となり、一気に3分の1以下にまで減らすことができた。
懸念された問題が現実に…
幸先の良いスタートを切ったかに思われたが、タイムリーなタイミングでついに起きてはいけないトラブルが起きてしまった。古いコンテンツがGoogleの検索結果へ露出し、SNSで炎上してしまったのである。
その当時、とあるスポーツであるチームの優勝に期待がかけられていたため、多くの人が「チーム名 優勝」などのキーワードで検索していた。その中にヒットしたのが、我が社のサイトのページだったのだが、なんとそのチームの今回の優勝ではなく、前回10年以上前に優勝したときに行なったキャンペーンのページだったのである。SNSでは「まだ優勝してないのにもうキャンペーン始まってると思ったら10年前のだった」とのコメントとともに拡散されてしまい、緊急で削除を行なう事態となってしまった。
この一件以降、不要なファイルを本番環境に放置することのリスクが社内で少しずつ認識され、今回の削除プロジェクトに対しても少しずつ周囲から理解が得られるようになっていった。
第2フェーズ
やってることは考古学
先のトラブルで2個のディレクトリが追加で削除されたため、第1フェーズを終えた段階で残りは133－2＝131個となった。ここから先は「必要か不要かよく分からないディレクトリ」との戦いという、本プロジェクトで最も難しいフェーズに入る。
さて、ここで一体どんな不要ファイルがあったのか、一部を紹介しておこう。
数年前に終了し、今では部署も解散となったサービスのコンテンツ（なんで解散前に責任を持って削除しなかったのか…）
誰が設置したか全く分からないGoogle Search ConsoleなどのSEO系のファイル（「ドキュメントルートへの設置」を強要してくるタイプのファイルは他にも多数）
20年以上前のCGIプログラム（しかも、バイナリなので何の機能なのか全く読み取れず、当然元のソースコードは行方不明）
20年前の日付と今の会社の偉い人の名前が入ったソースコード（つまり、その人がまだ若くて平社員で現場にいたときに書いたもの）
「最新のセキュリティ対策をしています」との文言とともに今では時代遅れとなった10年前の手法が解説されたページ（ユーザーに見られてしまったら大問題である）
何らかの実験的なバッチの自動生成によって1000万個以上のファイルで埋め尽くされたディレクトリ
今では存在しないNASやサーバーを指しているリンク切れのシンボリックリンク
プログラムの仕様書やトラブルの記録書（社外秘のものがなんで公開領域に置いてあるのか…）
「README」（しかもパーミッションが000で開けない）
「Makefile」（公開領域でビルドするな…）
「index.html.20000710」（もはや博物館に寄贈すべき）
…とまぁ面白いものを挙げればキリがない。我が社のサービス黎明期のファイルも多数残されていたため、社内で博物館を作った方がいいのでは…？と一時真剣に考えたりもした。
なぜこんなファイル名なのか？
なぜここにこんなものを設置したのか？
なぜこんな状態で放置されてしまったのか？
…とにかく容赦なく「一体なぜ…？」の疑問の気持ちを湧き起こさせるものばかりであった。過去の開発環境や経緯を推理する、まさに私がやってることは考古学であった。
担当者探しと削除の裏取り
「必要か不要かよく分からない」ディレクトリの要否を決定するため、担当者を探し回る日々が始まった。
まず最初は、社内の広範囲にメールを送信し、手がかりを募った。特に長年関係の深かった部署には全てのディレクトリを一通り確認してもらった。
担当者が見つかっていくつか驚きの事実も判明した。それは「ここがユーザーから直接アクセスされるドキュメントルートだと知らずに使っていた」部署があったことだった。こっちにしてみれば「何勝手に使ってんだ」という感じであるが、彼らにしてみれば「そんなの聞いてないです」という感じなのだろう。まぁこんなにゴミだらけの場所なら「私たちも勝手に使って大丈夫だろう」と思われても仕方なかったと思う。別の場所へ移行できる場合は移行してもらい、不可能な場合は一般ユーザーがアクセスできないようにした上で担当者を把握しておく、という方針を取ることにした。
次第に担当者が判明していき、担当者の確認の結果、削除OKの判断が下されたディレクトリも増えていったが、やはりゴミ漁りが好きな人はあまりいないようで、担当者を見つけてもはぐらかされてしまったり後回しにされてしまったりすることが多かった。どの部署もやはり「削除」という作業になぜか大きな抵抗感がある（一体みんなどんなトラウマを抱えているのか…）ようだったので、私はアクセスログなどできる限りの情報提供をし、削除する代わりにリダイレクトを残すなどの選択肢も増やし、また万が一の場合のロールバックも可能である点を強調するなどして、削除に対する抵抗感を払拭するよう努力した。
それでもなかなか返事がもらえない場合は、メール→チャット→会議→デスクへ直談判…とアプローチの方法を強めていった。こんなに多くの他部署の人（しかも大半は自分よりも格上の人）と一人でコミュニケーションを取る経験は当時の自分にはほとんど無かったため、なんとしてでも返事をもらおうと私は必死であった。
時にはひどい対応をされたこともあった。そもそも「不要ファイルの削除」自体に賛成できないという人も多く、真摯にお願いを続けていたつもりだったが「もういいよ、勝手に削除しろ」みたいな捨て台詞を吐かれてしまったこともあった。担当部署のトップの口から削除しろという言葉が出たんだからこれで責任取ってもらうか…とも考えたが、なんとか別の担当者をつかまえて改めて入念に確認してもらったところ、実は使用中の重要なファイルが含まれるディレクトリだった、なんてこともあった。
こうして、いろいろと苦労はあったが、半年間に及ぶ確認作業の結果、第2フェーズでは83個のディレクトリが不要と認められて、無事に削除することができた。これで当初489個あったディレクトリが、131－83＝48個まで減った。見えているディレクトリの9割がゴミだったのである。もちろん残った48個も担当者や用途が無事に判明し、ドキュメントにまとめて管理していくことになった。
最終成果
合計2.4TBが不要だった
第1フェーズ・第2フェーズと1年近くに及んだ不要ファイル削除プロジェクトの最終成果は以下の通りである。合計約3780万個、2.4TBものファイルが「不要」であるにもかかわらず長年放置されていたのだった。
削除したドキュメントルート直下のファイル＆ディレクトリ：
441個（489個 → 48個）削除したファイル数の合計（サブディレクトリ以下も含む）：
約3780万個削除したファイルサイズの合計（サブディレクトリ以下も含む）：
約2.4TB削除によってアクセスできなくしたURL：
少なくとも2,000個以上
なんだかもう桁数がおかしくて実感がわかない（これ以降、私のファイル数やファイルサイズに対する数の感覚は狂ってしまった）。
将来再び同じことが起きないために
削除の結果大きなトラブルが起きることもなく、プロジェクトは無事に一区切りした。最後に、将来再び同じ状況に陥らないために、ドキュメントルート直下には監視システムを入れた。監視の内容は以下の3つである。
ドキュメントルート直下に勝手にディレクトリやファイルが作成されていないか。
今後はもう使用しないと決めた（リダイレクト等を設定した）ディレクトリが再び使用されてしまっている兆候がないか。
ドキュメントルートと知らずに利用していた他サービスのディレクトリが継続して使用されている形跡があるか（使用の形跡が無くなった場合は放置されたと判断し削除する）。
1.はホワイトリストを作り、それ以外のファイル・ディレクトリが存在するかどうかで判定、2.はディレクトリ内のファイル数が増えていないかで判定、3.はディレクトリ内のファイルが定期的に更新されているかどうかで判定している。
さらに、サーバーのroot権限を持つインフラチームと、社内のファイル配信ツールを管理する部署には、今後「このドキュメントルートの場所を使いたい」という要望を受けたときには、無断でアクセス権限を与えるのではなく、必ず全て断るよう、念押ししておいた（逆に、なぜ今まで無断でアクセス権限がホイホイと付与されていたのか不可解である…）。
振り返って
最初の方で述べたが、このような大量の不要ファイルが放置されることになった原因の一つに、
「次にどんな新しいことをするか」「いかに会社の売上に貢献するか」が優先され、「終わったものの後始末」は価値の無い仕事と見なされた。
という価値観があったのではないかと思う。実際、多くの部署の担当者に問い合わせる中で、「整理して下さりありがとうございます」「放置したままで申し訳ありません」という声はほとんど無く、「なんで今それやる必要あるんですか？」という反応ばかりであった。
システム管理者の間では、溜まったシステムのログを定期的・自動的に削除するログローテーションというしくみが昔から常識となっていると思うが、コンテンツ製作者にはそのようにコンテンツのライフサイクルを考慮して古くなったものを削除していく思想はあまり無いのかもしれない。システムログに比べると生成スピードが遅くライフサイクルが長いからかもしれないが、大規模なサービスを運営していると、製作されるファイルの数も馬鹿にならない量になるのだ。
それを放置していれば当然、本来不要なコストの発生やディスクフルなどによるシステム障害、あるいは先に紹介したように古くなって内容の誤ったコンテンツが露出してしまう事故などが発生する。それは機会損失や会社の信用喪失につながるだろう。
「公開場所」と「保管場所」を混同している人も多いようだ。私が問題にしているのは「公開場所」を「保管場所」として使っているケースだ。要するに、「子供の頃の思い出の靴を、物置にしまうのではなく玄関に置きっぱなしにして、今使ってる新しい靴とごちゃごちゃになってしまった状態」と言える。記録や再利用のために残しておく必要性がある場合は、公開場所とは別に保管のための場所（例えば、クラウドストレージやバージョン管理ツールなど）を作ってそちらを利用するべきだろう。
このプロジェクトで多くの部署に声をかけたことや、プロジェクトの最中に実際に古いファイルが原因のトラブルが発生したことで、問題に対する社内の意識は多少は高まったと思う。しかし、中には必要性を理解してもらえなかった部署があったように、まだ全然足りないと思っている。そのため、私はこれ以降、社内でコンテンツのライフサイクル管理に不備があるシステムを探しては、問題提起と関係者への啓蒙を心がけるようになった。
現在は別のサービスで、同様に過去のファイルを削除するしくみが無く全て残されてしまっている問題の解消を手掛けている。そのサービスでは、アクセスログなどから使用形跡があると思われるファイルが約30万個であるのに対し、ファイルシステム上に存在するファイルはなんと約700万個もあるのだ。約95%が不要なファイルと推定されている状況である。これに対し、確実に不要と判断できる条件をコンテンツ製作者たちと協議しながら設定し、それに基づいて自動的に削除するシステムを製作しているところである。
さらに、これよりもっと闇の深い無法地帯な場所があることも知っている。そちらは直接の担当ではないため、まだ何も手をつけられていないが、今後何らかの形で問題解決に貢献できればと思っている。社内を見渡せばこんなのがまだたくさんあるのだ。
昨今では、優秀なAIの登場が話題で、エンジニアは職を奪われるとまで言われているが、私がやっているこのような泥臭い仕事はぜひ奪ってもらいたい。願わくは、近い将来に「社内のシステムと歴史を全て学習した社内事情に超詳しいAI」ができて、無法地帯の担当者と過去の経緯が一瞬で分かるようになっていてほしいものである。
（長文をお読みいただき、ありがとうございました。）
この記事が気に入ったらサポートをしてみませんか？