未分類

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

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

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

メッセージキューの導入判断は「非同期化すれば速くなる」という直感だけでは決められない。切り離す価値のある処理とそうでない処理の見極め、順序保証・再送・重複制御の設計判断、マネージドか自前かの選定軸を整理した実装層向け解説。

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

Kubernetes導入の失敗は「入れ方」ではなく「入れる判断の誤り」から始まる。サービス数・デプロイ頻度・チーム体制の三軸で適切な選択肢を見極め、過剰なオーケストレーションを避けるための設計判断を整理する。

キャパシティプランニングの失敗は「感覚で積む」判断プロセスに起因する。ピーク・平常・成長の三軸で需要を構造化し、ボトルネックを先行特定したうえで余裕量の境界を判断する設計思想を解説する。

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

IaCのテスト戦略は手法の組み合わせよりも「どこで自動化を止めるか」の境界設計が本質。静的解析・plan差分・ポリシー検査・結合テストの役割分担と、destroy/replaceを事前に止める設計、開発速度を保つフィードバックループ分割の考え方を整理。

クラウド・オンプレを問わず、タグと命名規約は構築直後より半年後に効いてくる設計要素。必須タグの選定基準、命名要素の取捨選択、IaCとポリシーによる強制の境界を整理し、形骸化しない規約設計の判断軸を示す。