監査ログ保持の設計 — 誰が何をしたかを、どこまで残すか

監査ログ保持の設計 — 誰が何をしたかを、どこまで残すか

監査ログは「取るだけ」では証跡として機能しない。追跡できる設計にするには、保存先の選定・保持期間の3層構造・改ざん防止・アクセス制御という判断を設計段階で組み込む必要がある。「取っているが追えない」ログが生まれる構造と、それを防ぐ設計の判断軸を整理。

リソース制限の設計 — 1プロセスの暴走で全体を巻き込まないために

リソース制限の設計 — 1プロセスの暴走で全体を巻き込まないために

リソース制限なしで複数サービスを同居させると、1プロセスの暴走が全体を道連れにする。制限の有無ではなく、どの単位で・どこまで絞るか・超過時の挙動をどう設計するかの三軸を整理することが判断の本質。cgroup・ulimit・ディスククォータの守備範囲比較とチェックリストで設計の抜け漏れを点検する。

パッチ適用戦略の設計 — 更新を止めずに回す仕組みの決め方

パッチ適用戦略の設計 — 更新を止めずに回す仕組みの決め方

パッチ適用が後回しになる構造的な原因と、それを設計で断ち切る方法を解説する。定期適用と緊急適用のフロー分離、検証環境から本番への適用順序の設計、自動化の境界線の引き方を中心に、手動・自動・イメージ差し替えの選択軸と、再起動を伴う更新の運用組み込みまでを具体的に示す。

キャッシュ層を入れるかの判断 — どこに何を挟むと効くか

キャッシュ層を入れるかの判断 — どこに何を挟むと効くか

キャッシュは性能改善の定石手段だが、「とりあえず挟む」判断が整合性事故と運用崩壊を招く。CDN・リバースプロキシ・アプリ・DB各層への選定基準、キャッシュすべきデータとしてはいけないデータの線引き、expire/purge設計の考え方、境界の壊れやすさを構築担当者向けに整理。

無停止DBマイグレーションの設計 — スキーマ変更で止めないために

無停止DBマイグレーションの設計 — スキーマ変更で止めないために

本番DBのスキーマ変更を無停止で行うには、後方互換を保つ段階的な設計と、アプリ・DBの切り替え順序の制御が必要。Expand-Contractパターン・オンライン変更ツール・デュアルライトの向き不向きと、ロールバック判断・大規模テーブルの境界見極めを解説する。