ヘルスチェックの設計 — livenessとreadinessをどう判定するか

ヘルスチェックの設計 — livenessとreadinessをどう判定するか

liveness(生存確認)とreadiness(受付可否確認)を区別せず設計すると、プロセスが稼働していてもトラフィックが途絶える、あるいは再起動ループで本番を落とす障害につながる。健全の定義の言語化から、依存先障害の伝播境界、カスケード障害リスクの計算まで、ヘルスチェック設計の判断軸を整理した実装層向けの解説。

IaCのリポジトリ構成の設計 — モノレポとマルチレポの分け方

IaCのリポジトリ構成の設計 — モノレポとマルチレポの分け方

IaCのリポジトリ構成は、チームが増え環境が拡張するほど後から変えにくい決定になる。モノレポとマルチレポの選択は「変更の単位・レビューの単位・権限の境界」を先に整理し、その結果として構成を決める順序が重要。本記事では境界の引き方と判断基準を整理する。

アーティファクト・イメージ保管の設計 — 何を成果物として残しどうバージョンするか

アーティファクト・イメージ保管の設計 — 何を成果物として残しどうバージョンするか

ビルドパイプラインが整った後も、アーティファクト保管の設計が場当たり的なままでは「再現できない・どれが本番かわからない」状態が半年以内に訪れる。何を保管し何を捨てるか、イミュータブルなバージョン付けをどう設計するか、保持世代とクリーンアップの線引きをどこに置くかを整理する。

リバースプロキシ/APIゲートウェイの配置設計 — どこで終端しどこに置くか

リバースプロキシ/APIゲートウェイの配置設計 — どこで終端しどこに置くか

リバースプロキシとAPIゲートウェイを「どこに置くか」は、TLS終端・認証・ルーティングの責任境界を決める設計の核心。エッジ集約・サービス前段・両段構成の向き不向き、単一障害点の排除、前段肥大化の防止まで、配置の設計判断を体系的に整理する。

内部認証局を持つかの判断 — 自前CA・マネージド・公開CAの選定

内部認証局を持つかの判断 — 自前CA・マネージド・公開CAの選定

証明書管理の方針を設計段階で決めなければ、数年後には発行済み証明書の台帳もなく失効手続きも誰も把握できない状態に陥る。自前CA・マネージドPKI・公開CAの三者を発行対象・運用負荷・監査要件の軸で比較し、発行・更新・失効・信頼チェーン配布の設計判断を整理する。

HAトポロジの選定 — Active-ActiveとActive-Standbyの線引き

HAトポロジの選定 — Active-ActiveとActive-Standbyの線引き

HAトポロジの選定は「Active-ActiveかActive-Standbyか」という二択ではなく、許容ダウンタイム・書き込み整合性・状態共有の設計を起点にした判断。目的を定義せずに構成を決めると、フェイルオーバーが本番で動かない設計が出来上がる。

メトリクス収集の設計 — Push型とPull型をどこで選ぶか

メトリクス収集の設計 — Push型とPull型をどこで選ぶか

Push型かPull型かを後回しにすると、短命コンテナやオートスケール環境で計測が欠落し、障害後のポストモーテムで「その時間帯のデータがない」状態に陥る。収集方式は環境の特性・ネットワーク境界・カーディナリティの三軸で判断する。