パッケージ入手経路の設計 — 外部リポジトリ直参照か社内ミラーか
パッケージ入手経路の設計判断は「外部依存をどこで断ち切るか」という位置の選択と、その断ち切り点を維持する運用コストの天秤にかかっている。直参照・キャッシュプロキシ・完全内部ミラーの三択を、可用性要件・変更管理・環境規模の軸で比較・整理する。
パッケージ入手経路の設計判断は「外部依存をどこで断ち切るか」という位置の選択と、その断ち切り点を維持する運用コストの天秤にかかっている。直参照・キャッシュプロキシ・完全内部ミラーの三択を、可用性要件・変更管理・環境規模の軸で比較・整理する。
セッション情報の配置設計は、水平スケールの可否を決める根本的な選択。ローカル保持・スティッキー割り振り・外部ストアそれぞれの特性と単一障害点リスク、アップロードファイルや一時データの逃がし先、障害時の引き継ぎ挙動まで、設計判断の境界を整理する。
スポットインスタンスの割引率は魅力的だが、中断耐性の設計なしに採用すると処理停止時の復旧コストが逆に膨らむ。何をスポットに乗せてよいか、どこをリザーブドで固めるか、判断軸と選定フローを解説する。
メンテナンス時間帯の設計では、停止可否の合意範囲・作業種別の切り分け・切り戻しタイムラインの三点を事前に文書化しておくことが判断の軸となる。計画停止・ローリング・完全無停止の選択基準と、定期枠固定の適否まで整理した設計判断ガイド。
オートスケールを「CPUが上がれば増やす」で設定したまま本番に出すと、台数の振動・ウォームアップ不足・障害時の無限増設という三つの落とし穴にはまる。閾値の決め方・クールダウン設計・上限設計の三点を軸に、固定台数・スケジュール増減・メトリクス連動の使い分けまで解説する。
アラート通知設計で最も避けるべきは「全部鳴らす」アプローチ。通知過多はアラート疲れを招き、担当者が本物の障害を見逃す原因になる。何を即時通知し、誰を深夜に起こし、何を翌朝回しにするかの判断軸を整理。閾値監視・異常検知・症状ベースの向き不向き比較と、エスカレーション設計・連鎖通知の抑制方法を解説する。
本番Linuxサーバーのディスクレイアウトは「後から直せる」という思い込みが最も危険な領域のひとつ。/varの溢れがシステム全体を停止させる構造的な理由、LVM・固定分割・単一パーティションの選び分け、XFSとext4のワークロード別使い分け、拡張を前提とした容量設計の考え方を解説する。
RHEL系・Ubuntu LTSの選び方を、サポート期限・ミドルウェアISVサポート・混在コストの三軸で解説。設計段階で突き合わせるべき判断軸と、後から行き詰まる典型的な落とし穴を整理した構築担当者向けの選定ガイド。
IaCを導入していても本番への手動変更は絶えず、気づかないまま積み重なったドリフトが再構築・複製時の障害の根本原因になる。検知設計の核心は「すべてを追う」ではなく、対象・手段・差分をどう処理するかの境界を決めることにある。
レプリケーションは「張れば安全」ではなく、同期・非同期・準同期のどれを選ぶかが可用性とデータ整合性のトレードオフを決定づける。RPOの数値合意と読み取りパターンの整理を設計の起点に据えることで、本番稼働後の不整合やフェイルオーバー時の欠損リスクを回避できる。