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 です。これがあるとコネクションを握ったまま解放されず、枯渇の引き金になります。 ...

GitHub Actions OIDCで実現する鍵レス本番デプロイ：漏えい事故を減らす実装プレイブック CI/CD の事故は、ビルドが失敗することより「漏えいしても気づけない鍵」が残り続けることのほうが深刻です。特に AWS_ACCESS_KEY_ID のような長期シークレットを GitHub Secrets に保存し続ける運用は、便利ですがリスクが高いです。 本記事では、GitHub Actions の OIDC（OpenID Connect）連携を使って、長期鍵を使わずに AWS へデプロイする実践手順をまとめます。単なる設定紹介ではなく、最小権限・ブランチ制限・監査ログ設計まで含めて、明日から本番投入できる形で説明します。 1. まず何が危険なのか：長期シークレット運用の限界 従来構成では、次のような問題が起きます。 Secret が漏れても検知が遅い（CIログ、誤コミット、権限の広いメンバー） ローテーションが後回しになる 1つの鍵で複数環境へアクセスできてしまう 「誰のどの workflow 実行が何をしたか」が追いにくい OIDC 連携では、GitHub が発行する短命トークンを信頼し、AWS 側で一時認証情報を払い出します。つまり、保管する鍵そのものを減らすのが最大の価値です。 2. 全体アーキテクチャ 基本フローは以下です。 GitHub Actions ジョブが OIDC トークンを取得 AWS IAM の OIDC プロバイダとロール信頼ポリシーで検証 条件に一致したジョブだけ AssumeRoleWithWebIdentity 一時クレデンシャルで S3/CloudFront/ECR/ECS へデプロイ ポイントは「GitHub 側の workflow 制御」だけでなく、AWS 側で repo・branch・workflow を強制することです。 3. AWS 側の初期設定（OIDC Provider + IAM Role） 3.1 OIDC Provider を作成 CLI 例（すでに存在する場合はスキップ）: 1 2 3 4 aws iam create-open-id-connect-provider \ --url https://token.actions.githubusercontent.com \ --client-id-list sts.amazonaws.com \ --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1 3.2 信頼ポリシーを厳密化する 以下のように sub と aud を必ず絞ります。 ...

FastAPI認証・認可の本番設計：JWT運用、権限制御、監査ログまで含めた実装パターン FastAPI は実装が速い反面、認証・認可を最小構成のまま本番に出してしまい、後からセキュリティ事故に発展するケースが少なくありません。特に「JWT を入れたから安全」という誤解は危険です。 本記事では、開発速度を落とさずに本番で耐える認証基盤を作るための設計を、コード例と運用手順込みで解説します。 1. 認証と認可を分離して設計する 最初に押さえるべきは責務分離です。 認証（Authentication）: 誰かを確認する 認可（Authorization）: 何をしてよいか判定する この2つを混ぜると、実装も監査も破綻します。FastAPI では dependency を分け、get_current_user と require_permission を独立させるのが基本です。 2. JWT は「短命 + リフレッシュ + 失効管理」で使う アクセストークンを長寿命にすると、漏えい時の被害が大きくなります。実運用では以下が標準です。 Access Token: 5〜15分 Refresh Token: 7〜30日 Refresh Token は DB 保存し、ローテーション時に旧トークンを失効 sub だけでなく、jti（トークンID）や scope を持たせると管理しやすくなります。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 from datetime import datetime, timedelta, timezone import jwt ALGORITHM = "HS256" def create_access_token(user_id: str, scopes: list[str], secret: str) -> str: now = datetime.now(timezone.utc) payload = { "sub": user_id, "scope": " ".join(scopes), "iat": int(now.timestamp()), "exp": int((now + timedelta(minutes=10)).timestamp()), "jti": "generated-uuid" } return jwt.encode(payload, secret, algorithm=ALGORITHM) 3. 鍵管理とローテーション 秘密鍵を .env に固定して数年運用するのは典型的な事故パターンです。最低限、次を実施します。 ...

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 の健全性チェック: ...

GitHub Actions高速化実践：Matrix戦略・依存キャッシュ・失敗切り分けの設計ガイド GitHub Actions は便利ですが、プロジェクトが成長すると「遅い」「不安定」「原因が分かりにくい」という三重苦になりがちです。特に monorepo や複数ランタイム対応（Node/Python/Go など）では、ワークフローの設計次第で CI 時間が 2〜3 倍変わります。 本記事では、実行時間を短くしながら失敗時の調査コストも下げるために、matrix 設計・キャッシュ設計・障害時の確認順序を具体的に整理します。 1. まず「何を並列化するか」を決める Actions の高速化は、いきなりキャッシュ最適化から入るより、先にジョブ分解を決める方が効きます。原則は次の通りです。 並列化すべき: 独立テスト（OS/バージョン別、サービス別） 直列にすべき: デプロイ、DB マイグレーション、本番反映 依存を分ける: lint/typecheck/test/build を一つに詰め込まない 悪い例は、1ジョブに全部詰め込み、失敗時に最初から再実行するパターンです。良い設計では「lint は通るが test だけ失敗」のように切り分けできます。 2. matrix を作るときの実践ルール matrix は便利ですが、組み合わせ爆発で逆に遅くなることがあります。例えば os x runtime x db をすべて直積にすると、不要なジョブが大量発生します。そこで include/exclude を活用します。 1 2 3 4 5 6 7 8 9 10 11 12 strategy: fail-fast: false matrix: os: [ubuntu-latest, macos-latest] node: [20, 22] include: - os: ubuntu-latest node: 22 coverage: true exclude: - os: macos-latest node: 20 ポイントは次です。 ...

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 の整合性を必ず固定化します。 ...

Redisキャッシュスタンピード対策ガイド：高負荷時にDBを守る設計と実装 Redis を使っていても、ピークトラフィック時に DB が突然落ちることがあります。原因の多くはキャッシュスタンピードです。人気キーの TTL が同時に切れると、大量リクエストが一斉に DB へ流れ、接続プールが飽和します。 「Redis を入れたのに遅い」「ピーク時だけ 500 が増える」という現象は、このパターンで説明できることが非常に多いです。 本記事では、キャッシュスタンピードを実運用で防ぐために、設計原則・実装パターン・監視方法を順に解説します。 1. キャッシュスタンピードとは何か 典型シナリオ: 商品ランキング API が ranking:daily を Redis に 300 秒で保存 300 秒後、人気時間帯にキー期限切れ 同時に 1000 リクエストが miss 1000 回 DB 集計が走ってレイテンシ急増 このとき Redis 自体は正常でも、背後の DB が壊れます。つまり、問題はキャッシュ障害ではなく「再生成の同時実行制御」です。 2. 防御の基本は三層構え スタンピード対策は単一施策では不十分です。次の三層を組み合わせると安定します。 同時再生成の抑制（singleflight / 分散ロック） 期限切れの分散（TTL ジッター） 期限切れ後の挙動制御（stale-while-revalidate） 3. パターン1: singleflight で同時再生成を止める 同一キーの miss が同時発生しても、1 リクエストだけ再生成し、他は待つ設計です。 TypeScript 例: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 const inflight = new Map<string, Promise<string>>(); async function getOrCompute(key: string, ttlSec: number, compute: () => Promise<string>) { const cached = await redis.get(key); if (cached) return cached; if (!inflight.has(key)) { const p = (async () => { try { const value = await compute(); await redis.set(key, value, { EX: ttlSec }); return value; } finally { inflight.delete(key); } })(); inflight.set(key, p); } return await inflight.get(key)!; } 単一プロセスではこれで十分ですが、複数インスタンス構成では分散ロックも必要です。 ...

PostgreSQLデッドロック調査プレイブック：再現・可視化・恒久対策までの実践手順 本番運用で厄介なのは、エラーが「たまに」しか出ない障害です。PostgreSQL のデッドロックはその代表で、発生頻度は低くてもビジネス影響が大きいことが多いです。決済や在庫更新で発生すると、リトライが雪だるま式に増え、アプリ全体の遅延を引き起こします。 本記事では、デッドロック発生時に現場でそのまま使える手順を、初動対応・再現・恒久対策の順で整理します。 1. まず理解すべき前提 デッドロックは「どちらかが悪い」ではなく、ロック順序が循環したときに必ず起きる現象です。PostgreSQL は循環を検出すると、どちらか一方のトランザクションを強制中断します。 典型的な症状: ERROR: deadlock detected API の一部がランダムに 500 を返す リトライ実装により DB 負荷が上振れ ここで重要なのは、単純なタイムアウトと混同しないことです。タイムアウトは待ち時間超過、デッドロックは循環待ちです。対策が違います。 2. 初動でやること（5〜15分） 2-1. エラーログの採取 まず、DB 側ログに詳細を出す設定があるか確認します。 1 2 3 SHOW log_lock_waits; SHOW deadlock_timeout; SHOW log_min_error_statement; 推奨設定（本番）: log_lock_waits = on deadlock_timeout = '1s' log_min_error_statement = error deadlock_timeout を短めにすることで、待ちが長引いたケースの追跡がしやすくなります。 2-2. 現在のロック状況を確認 1 2 3 4 5 6 7 8 9 10 11 12 13 14 SELECT a.pid, a.usename, a.application_name, a.state, a.query, l.locktype, l.mode, l.granted, a.query_start FROM pg_stat_activity a JOIN pg_locks l ON a.pid = l.pid WHERE a.datname = current_database() ORDER BY a.query_start; 見るべき点は「長く生きているトランザクション」と「granted = false が連鎖している箇所」です。 ...