SRE

PostgreSQL PITR復旧訓練ガイド: バックアップがあるのに戻せないを防ぐ実践手順 PostgreSQL運用で最も危険なのは「バックアップがある」という安心感です。実際の障害では、バックアップ自体より 復旧手順の不整合 で時間を失います。たとえば、WAL保管期間が足りず目標時刻に戻せない、暗号鍵が見つからず復号できない、復旧後の整合性確認が曖昧で再開判断ができない、といった問題です。 本記事では、PostgreSQLの Point-in-Time Recovery（PITR）を、机上ではなく本番レベルで回すための実装手順を解説します。pgBackRest を例にしていますが、考え方は他ツールでも共通です。 1. PITRの前提: 3つ揃わないと復旧できない PITRは次の3要素で成立します。 ベースバックアップ（フルまたは差分） WALアーカイブ（継続的） 目標時刻情報（いつまで戻すか） どれか1つでも欠けると成立しません。特に本番で多いのは「WALが途中で消えていた」ケースです。S3保存していても、ライフサイクル設定や権限変更で欠落することがあります。 2. まず決めるべきRTO/RPO 技術論の前に、業務要件を決めます。 RTO（復旧に許容される時間）: 例 60分 RPO（失ってよいデータ時間）: 例 5分 この2つで設計が変わります。 RPO 5分以内ならWALアーカイブ遅延監視が必須 RTO 60分以内なら復旧訓練を定期実施し、手順を自動化する必要あり 要件不明のまま「毎日バックアップ」だけ実施しても、障害時に役立たないことが多いです。 3. 推奨アーキテクチャ（単一リージョンの最小構成） DBサーバ: PostgreSQL 15/16 バックアップツール: pgBackRest 保存先: S3互換ストレージ（バージョニングON） 監視: Prometheus + Alertmanager 復旧先: 別ホスト（本番と同一ネットワーク） 重要なのは、本番DBと別ホストで実際に復旧できること を定期検証する点です。 4. 実装手順（pgBackRest） 4.1 PostgreSQL設定 postgresql.conf 例: wal_level = replica archive_mode = on archive_command = 'pgbackrest --stanza=main archive-push %p' max_wal_senders = 10 wal_compression = on archive_command は失敗時に非0を返す必要があります。ここが曖昧だとWAL欠落に気づけません。 ...

Kubernetes環境でDBスキーマ変更を止めずに進める：ゼロダウンタイム移行の実践戦略 「カラムを追加するだけだから大丈夫」──この油断が、本番障害の入口になります。Kubernetes のように複数バージョンの Pod が同時に存在する環境では、DB スキーマ変更はアプリ変更よりも慎重に扱う必要があります。 本記事では、Expand-Contract パターンを中心に、ゼロダウンタイムを目指すための具体手順を解説します。実際の運用では、DDLの速さより「互換性のある期間をどう作るか」が勝負です。 1. なぜKubernetesでDB移行が難しいのか Kubernetesでは、ローリングアップデート中に新旧Podが混在します。つまり次の状態が同時に発生します。 新アプリは新スキーマを期待 旧アプリは旧スキーマしか知らない DBは1つしかない このとき破綻するのが「破壊的変更を先に適用する」ケースです。たとえば旧カラムを即削除すると、旧Podがエラーを連発します。 2. 基本戦略：Expand → Migrate → Contract ゼロダウンタイム移行の原則はこの3段階です。 Expand: 互換性を壊さない変更を先に入れる（新カラム追加など） Migrate: アプリを段階的に切替え、データを移行する Contract: 旧仕様を最終削除する（十分な監視後） この順序なら、どの時点でも旧新どちらのアプリも動作可能にできます。 3. 具体例：users.full_name を first_name / last_name へ分割 3.1 Expand フェーズ まず破壊的でないDDLを適用します。 1 2 ALTER TABLE users ADD COLUMN first_name text; ALTER TABLE users ADD COLUMN last_name text; この時点で旧アプリは full_name を使い続けられます。新アプリは新カラムに対応した実装を持っていても、まだ必須にしません。 3.2 アプリを「両対応」にする 書き込み時は両方へ保存（dual write）し、読み込み時は新カラム優先 + 旧カラムフォールバックにします。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 def save_user_name(user_id: str, full_name: str): first, last = split_name(full_name) db.execute( """ UPDATE users SET full_name = %s, first_name = %s, last_name = %s WHERE id = %s """, (full_name, first, last, user_id), ) def read_user_display_name(row): if row.first_name and row.last_name: return f"{row.first_name} {row.last_name}" return row.full_name この両対応期間を作るのが、ゼロダウンタイムの本質です。 ...

PostgreSQL接続プール枯渇の実戦対処：再発防止までつなげる調査・改善プレイブック 本番障害でよくあるのが、too many clients already や remaining connection slots are reserved です。アプリ側から見ると「急にDBに繋がらない」、ユーザー側から見ると「全機能が遅い・失敗する」という最悪の体験になります。 厄介なのは、接続枯渇が「DBサーバー性能不足」だけで起こるわけではない点です。リーク、タイムアウト設定、長時間トランザクション、プールサイズ不整合など、複数要因が重なって起きます。 この記事では、接続枯渇に対して 発生時の初動 → 根本原因の特定 → 恒久対策 の順で、手順を実務レベルでまとめます。 1. まず初動：サービス継続を優先する 障害対応では、完璧な原因究明より「止血」が先です。以下を順番に実施します。 直近リリース有無を確認（機能フラグ含む） アプリの接続数・待機数・エラー率を確認 DB側で pg_stat_activity を取得 長時間実行クエリを必要に応じて停止 一時的にアプリ Pod 数を制限して雪だるま増幅を止める pg_stat_activity の基本クエリ: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 SELECT pid, usename, application_name, client_addr, state, wait_event_type, wait_event, now() - query_start AS query_duration, now() - xact_start AS xact_duration, left(query, 120) AS query_head FROM pg_stat_activity WHERE datname = current_database() ORDER BY xact_start NULLS LAST, query_start NULLS LAST; ここで見るべきは、state='idle in transaction' と異常に長い xact_duration です。これがあるとコネクションを握ったまま解放されず、枯渇の引き金になります。 ...

PostgreSQL肥大化対策の実務：VACUUM/Autovacuum/Index再編成を止めずに回す運用プレイブック PostgreSQL を長期運用すると、遅かれ早かれぶつかるのが bloat（テーブル/インデックス肥大化）です。CPU やメモリを増やしても、実体は不要領域の蓄積なので、根本原因を処理しない限り性能は戻りません。 本記事では、サービス停止なしで bloat を抑える運用を目標に、Autovacuum 設計、監視、メンテ手順を実践ベースで解説します。 1. なぜ肥大化が起きるのか PostgreSQL は MVCC を採用しているため、UPDATE/DELETE で古い行バージョンが即時削除されません。不要バージョンは VACUUM で回収されますが、追いつかないと肥大化します。 肥大化が進むと以下が起こります。 同じデータ量でも I/O が増える インデックス探索が遅くなる キャッシュ効率が落ち、p95 レイテンシが悪化 自動メンテの時間がさらに伸びる（悪循環） 重要なのは、「遅くなってから対処」だと回復コストが高いという点です。 2. 最初に見るべき指標 運用でまず可視化するのは次の4つです。 n_dead_tup（死んだタプル数） last_autovacuum（最後に vacuum が走った時刻） テーブルサイズ・インデックスサイズ推移 age(relfrozenxid)（XID 消費進行） 確認クエリ例: 1 2 3 4 5 6 7 8 9 10 SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum, last_vacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 20; XID の健全性チェック: ...

Kubernetesキャパシティ設計実践：HPA/VPA/Cluster Autoscalerを衝突させない運用術 Kubernetes は「自動でスケールするから安心」と思われがちですが、実運用では逆です。HPA、VPA、Cluster Autoscaler（CA）の設定が噛み合わないと、スケールアウトと再スケジューリングが衝突し、レイテンシ悪化やコスト増大を引き起こします。 本記事では、3つのオートスケーリング機構を同時運用する際の設計ポイントを、障害対応目線で整理します。 1. 役割分担を明確にする まず前提として、各コンポーネントの責務を固定します。 HPA: Pod 数を短期的に増減 VPA: Pod あたりの requests/limits を中長期で最適化 CA: ノード数を増減 この役割分担が曖昧だと、同じ問題を複数レイヤーで同時に解こうとして不安定化します。特に Web/API ワークロードでは、HPA を主軸、VPA は recommendation 中心で始めるのが安全です。 2. requests/limits が崩れていると全て失敗する HPA の CPU 指標は requests 基準で計算されます。requests が不正確だと、HPA の判断もズレます。最初にやるべきは次です。 過去 2 週間の実使用量を可視化 p95 使用量を requests の初期値に設定 limits は requests の 1.5〜2 倍で開始 極端に低い requests は「見かけの高負荷」を作り、不要スケールを誘発します。逆に高すぎる requests は CA の過剰増設を招きます。 3. HPA 指標選定の実践 CPU だけで運用すると、I/O 待ちや外部 API 待ちのボトルネックを見逃します。推奨は複合指標です。 CPU Utilization（基本） メモリ使用率（リーク監視） RPS あたりレイテンシ（SLO 接続） Queue 長（非同期処理） autoscaling/v2 では複数メトリクスを扱えるため、最初から設計しておくと後で楽です。 ...

OpenTelemetry実践導入ガイド：ログ・メトリクス・トレース統合を90日で定着させる 「監視は入れているのに障害原因の特定が遅い」。この状態は、たいていデータが足りないのではなく、データが分断されていることが原因です。メトリクスは見える、ログは別画面、トレースは導入途中、という構成だと、オンコールは毎回同じ調査を手作業で繰り返すことになります。 OpenTelemetry（OTel）はこの分断を減らすための共通規格です。ただし、導入に失敗するチームも少なくありません。理由は単純で、「計測の追加」だけやって「運用設計」を後回しにするからです。 本記事では、OpenTelemetry を 90 日で現場定着させるための、実務寄りの導入手順を紹介します。 1. まず決めるべき運用目標 OTel を入れる前に、次の問いに答えます。 どの障害をどれだけ早く見つけたいか どのサービスの MTTR をどれだけ下げたいか どのチームがトリアージ責任を持つか たとえば「API 5xx の原因調査を 60 分 → 15 分に短縮する」と明文化すると、必要な計測が決まります。逆に目標がないと、span を増やす作業が目的化して終わります。 2. 参照アーキテクチャ 本番で扱いやすい最小構成は次です。 アプリケーションに OTel SDK を導入 エージェント/サイドカー経由で OTel Collector に送信 Collector で加工・サンプリング・ルーティング Prometheus / Loki / Tempo（または商用基盤）へ出力 Collector を中継に置く理由は、アプリ側の再デプロイなしでルール変更できるからです。運用現場ではここが非常に効きます。 3. サービス命名規則を最初に固定する 命名規則を後で直すと、ダッシュボードとアラートが壊れます。以下は最低限のルール例です。 service.name: domain-service-env（例: billing-api-prod） deployment.environment: prod|stg|dev service.version: Git SHA または semver cloud.region: 実リージョン名 この 4 つが揃うと、障害時に「どの環境・どのバージョン」が悪いか一気に絞れます。 4. Pythonサービス計測の実装例 FastAPI を例に、最小導入手順を示します。 1 2 3 4 pip install opentelemetry-distro \ opentelemetry-exporter-otlp \ opentelemetry-instrumentation-fastapi \ opentelemetry-instrumentation-requests 起動時に auto-instrumentation を有効化します。 ...

Terraformドリフト検知プレイブック：本番事故を防ぐCI設計と運用手順 Terraform を導入していても、運用が進むほど「実環境がいつの間にかコードとズレる」問題にぶつかります。いわゆるドリフトです。最初は小さな差分でも、放置すると本番変更時に予期せぬ差分が混ざり、障害やリリース遅延の原因になります。 本記事では、Terraform ドリフト検知を単なる terraform plan 実行で終わらせず、継続運用できる仕組みとして実装するための具体策をまとめます。対象は AWS を例にしますが、考え方は他クラウドでも共通です。 1. ドリフト検知で最初に決めるべきこと 多くのチームが失敗するのは、実装前に運用設計を決めないことです。まず以下を決めます。 どの環境をいつ検知するか（prod は毎日、stg は平日など） 検知結果をどこに通知するか（Slack/Discord/Issue） 誰がいつまでに対応するか（当番制、SLA） 「意図した手動変更」をどう扱うか（例外ラベル、期限付き） ここを決めずに CI だけ作ると、通知がノイズ化して無視されます。ドリフト検知は技術課題より運用課題です。 2. リポジトリ構成と state 分離 最小限、次のような構成を推奨します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 infra/ modules/ vpc/ ecs/ rds/ envs/ prod/ main.tf backend.hcl variables.tf stg/ main.tf backend.hcl .github/ workflows/ terraform-drift.yml 環境ごとに backend と state を分けることが重要です。ドリフト検知ジョブが state を誤って参照すると、存在しない差分が出ます。S3 backend + DynamoDB lock を使う場合は、bucket/key/region/table の整合性を必ず固定化します。 ...

Kubernetes障害対応ランブック実践編：15分で切り分け、60分で復旧するための現場手順 Kubernetes で障害が起きたとき、技術力より先に問われるのは「順序」です。順序が崩れると、正しいコマンドを打っていても復旧が遅れます。逆に、判断フレームが決まっていれば、難しい障害でも被害を最小化できます。 本記事では、実運用で使える障害対応ランブックを、初動 15 分・復旧 60 分を目安に具体化します。対象は EKS/GKE/AKS を含む一般的な Kubernetes 本番環境です。 1. 最初の5分：人と情報の交通整理 まずやるべきは技術調査ではなく、交通整理です。 インシデントの指揮者（IC）を1人決める ログ担当、メトリクス担当、アプリ担当を分ける Slack/Discord の専用チャンネルを作る 5分ごとの時系列ログ（タイムライン）を残す この段階で「誰が何を見ているか」が曖昧だと、同じ調査を3人で繰り返し、誰も復旧判断をしない状態になります。ICは手を動かさず、意思決定に集中するのが基本です。 2. 5〜15分：影響範囲の特定 次に「どのユーザーに、どの機能で、何%の影響があるか」を確定します。 2-1. まず全体の健康状態 1 2 3 kubectl get nodes kubectl get pods -A --field-selector=status.phase!=Running kubectl get events -A --sort-by=.lastTimestamp | tail -n 50 見るポイント: Node が NotReady になっていないか 特定 namespace だけで CrashLoopBackOff が増えていないか 直近イベントに FailedScheduling や Back-off restarting failed container がないか 2-2. SLO/SLIから影響を数値化 「遅い気がする」ではなく、以下を数値で押さえます。 ...

FastAPI本番運用ハードニング完全ガイド：セキュリティ・性能・障害対応を実装で固める FastAPI は開発速度が高く、PoC から本番まで一気に進めやすいフレームワークです。しかし、早く作れることと安全に運用できることは別問題です。実際の障害は、コードの正しさよりも運用の隙から発生します。 本記事では、FastAPI を本番で安心して運用するためのハードニング手順を、実装可能な形でまとめます。対象は「すでにAPIが動いているが、運用強度を上げたい」チームです。 1. 入口防御：TLS、ヘッダ、レート制限 TLS終端とForwardedヘッダ ロードバランサ配下で動かす場合、X-Forwarded-For と X-Forwarded-Proto の扱いを明確にします。誤るとクライアントIPが取れず、監査も制限も機能しません。 1 2 3 4 5 from fastapi import FastAPI from starlette.middleware.trustedhost import TrustedHostMiddleware app = FastAPI() app.add_middleware(TrustedHostMiddleware, allowed_hosts=["api.example.com", "*.example.com"]) allowed_hosts をワイルドにしすぎると Host Header Injection の温床になります。 セキュリティヘッダ 最低限次を返します。 Strict-Transport-Security X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy APIでも無関係ではありません。管理画面やドキュメントUIを守る意味があります。 レート制限 ブルートフォースと突発負荷に備え、IPまたはAPIキー単位でレート制限を設定します。 認証系: 5 req/min 通常API: 60 req/min 高負荷検索: 20 req/min Redis バックエンド方式にして、アプリ再起動でカウンタが失われないようにします。 ...

Kubernetesコスト最適化の実務：FinOps視点で無駄を可視化し、性能を落とさず削減する方法 Kubernetes を導入した直後は「自動で効率化される」と期待されがちですが、実際には逆です。適切な運用ルールがないと、クラウド請求は静かに膨らみ続けます。 典型例は次の通りです。 リクエスト/リミットが過大でノードが常時スカスカ 夜間トラフィック減少時も同じ台数を維持 開発環境が週末ずっと起動 HPA が CPU しか見ておらず、キュー滞留を無視 過剰なストレージクラス（IOPS課金）を全環境で使用 本記事では、FinOps の考え方を用いて、Kubernetesコストを「見える化→改善→定着」の順に進める方法を解説します。 コスト削減の前に定義すべき指標 削減施策が失敗する理由は、目標が「安くする」しかないからです。最低でも次の 4 指標を定義します。 Unit Cost: 1リクエストあたりコスト / 1ジョブあたりコスト Utilization: CPU・Memoryの実効使用率 Reliability: SLO 達成率（削減で品質を落とさない） Waste Ratio: 予約/実使用の差分率 この4つを同時に追うと、単なるコストカットでなく「健全な最適化」になります。 ステップ1：可視化基盤を整える 1-1. Kubecost または OpenCost の導入 EKS/GKE/AKS いずれでも、namespace / deployment / label 単位で費用を把握できる状態にします。重要なのは team, service, env ラベルを強制することです。 推奨ラベル: cost-center owner environment（prod/stg/dev） criticality ラベルがないと請求分析ができず、改善責任が曖昧になります。 1-2. 観測ダッシュボード 最初のダッシュボードは次を必須にします。 Namespace別コスト（当日/前日比） Pod別 request/usage ギャップ ノード空き率（CPU、Memory） 時間帯別トラフィックとレプリカ数 ここまでで「どこが高いか」は見えます。次は「なぜ高いか」を潰します。 ステップ2：最も効果が高い改善施策 2-1. Right Sizing（最優先） 多くの環境で最大効果が出るのは request/limit の見直しです。VPA recommendation を参考に、まずは read-only で 2 週間観測します。 ...