データ置き場の、守り方

前回、業務アプリ量産時代のデータ戦略 ― アプリは増えても、データの置き場は増やさないを書きました。データを1か所に集めて、その上に業務アプリを載せていく、という話です。今回はその続きで、集めた置き場をどう守るかです。

自社のファイル置き場（AWSのS3）を整えたときに考えたことと、作業中に踏んだ落とし穴を書きます。構成の具体的な名前は伏せて、考え方だけ書きます。

1. フォルダは案件単位。ただし名前は案件名ではなくID

置き場のいちばん上のフォルダは、データベース名と同じにしました。案件1つにつきフォルダ1つ、データベース1つ。こうすると「このプログラムはこのフォルダにだけ書ける」という権限が1行で書けます。

そして、フォルダの名前は案件名ではなく機械的に振ったIDにします。

万一置き場を覗かれたとき、フォルダ名が案件名だと「どの取引先の何のデータか」が一目で分かる案内板になってしまいます。IDなら、それだけでは何のデータか分かりません。IDと案件の対応表は、置き場とは別の場所で管理します。

守りは壁を高くするだけではなく、壁を越えられたときに何が見えるかまで考えて初めて設計になります。

2. 権限は「分かる粒度」で切る。塞ぎ残しは拒否で潰す

権限は細かく書くほど安全に見えます。でも細かくすると「この1行は何のためか」が分からなくなり、増やすたびに事故ります。うちは案件フォルダ単位という、名前を見れば意味が分かる粒度で切りました。

ひとつ落とし穴がありました。フォルダ単位で許可を出すと、その下に置いた「もう誰も書かない過去データ」まで書けるようになります。前方一致の許可は、下の階層を全部含むからです。

ここで許可のほうを細かく割り直すと、せっかくの分かりやすさが消えます。代わりに明示的な「拒否」を1本足しました。拒否は許可より必ず強いので、フォルダ単位の許可はそのままで、守りたい場所だけ塞げます。

検証して1件塞ぎ残しが見つかったとき、テストの期待値を下げて通すのがいちばん危ない。直すのはポリシーの側です。

3. 「影響ないか」は、机上の全数と実走の両方で示す

権限を絞ったあと、「夜中の自動処理に影響ないか」を確かめる必要があります。

AWSには、実際に読み書きせずに「この操作は通るか」を判定だけ聞ける仕組み（ポリシーシミュレータ）があります。ここで大事なのは抜き取りでやらないこと。取得と取り込みの設定ファイルから、夜間に通る経路を全部機械的に組み立てて、まとめて判定にかけました。設定を足せば検査対象も自動で増えます。

ただし、机上の判定は「ポリシー上は通る」であって「プログラムが動く」ではありません。だから最後に、実際に1本走らせて書けること・読めることを確かめました。この2つが揃って、初めて「影響ない」と言えます。

4. 消す前に、戻せるようにする

作りはじめの置き場には、上書き・誤削除の戻し先がありませんでした。実はこれが一番大きな穴です。

版の保存（バージョニング）を入れると、上書きしても消しても前の状態が残ります。ただし版は放っておくと溜まり続けるので、「古い版は30日で消す」をセットで入れます。この2つは必ず対で考えます。

もうひとつ。ライフサイクル（保存期限）の設定は全ルールの置き換えです。1本足すつもりで既存のルールを消してしまう事故が起きやすいので、既存分を含めた全体を毎回出し直します。

5. 大きい削除は、削除コマンドではなく「期限」でやる

引っ越しが終わった古いフォルダを消すとき、一括削除コマンドは使いませんでした。代わりに「このフォルダは1日で期限切れ」という保存期限を設定しました。結果は同じでも、性質がまるで違います。

• 何が消える設定なのか、あとから読める
• 発動する前なら、いつでも取り消せる
• 消えたあとも、版の保存で一定期間は戻せる

急いで消す理由がないなら、消える側に時間の余裕を持たせるほうが安全です。

ここにも前方一致の罠があります。期限のルールも前方一致なので、移した先に同じ名前が含まれていると巻き込みます。「古いフォルダの残りが0件になったこと」と「移した先が無事なこと」を同時に確かめるようにしました。

6. 作業中に踏んだ、数え方の罠2つ

その1：一覧の件数が1000件で頭打ちになる。 AWSのコマンドで件数を数えたとき、どのフォルダも「1000件」と返ってきました。結果の絞り込みがページ送りの前に効いていて、1ページ分しか数えていなかったのです。数千件のフォルダを「1000件で一致」と誤判定するところでした。件数は、ページ送りを自分でやる方法で数え直します。

その2：同じ中身なのにチェックサムが合わない。 大きいファイルは分割アップロードになり、チェックサムの計算式そのものが変わります。中身が同じでも値が一致しません。サイズの一致を確かめた上で、疑わしいものは実際に読み直して別の方法（SHA256）で突き合わせました。

検証に使う数字ほど、数え方を疑う。 照合が通ったように見えて、実は数え方が壊れていた——これが移行でいちばん怖いパターンです。

7. 整理の前に「誰が書いて、誰が読んで、いつ止まったか」

置き場の整理はリスクの高い作業に見えます。でも着手前に3つを洗い出したら、見え方が変わりました。

• 誰が書いているか（取得側の設定から機械的に展開）
• 誰が読んでいるか（取り込み側の設定から同じく展開）
• 最終更新はいつか（全ファイルの更新日時を実際になめる）

結果、案件ごとに分かれていた古いフォルダはどれも誰も読んでおらず、書かれてもいない過去データでした。「動いている配管を触る危険な工事」だと思っていたものが、実際は「過去データの片づけ」だった。危険度の見積もりが1桁変わりました。

構成変更の相談を受けたら、まずこの3点を実物で出す。作業の重さはそこで決まります。

まとめ

どれも特別な道具は要りません。順番と確かめ方の問題です。

前回の記事：業務アプリ量産時代のデータ戦略 ― アプリは増えても、データの置き場は増やさない

石井 亮介（りょうさん）

データパレード 代表取締役

XContact

㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。