engineering-devops-automator

DevOps とインフラストラクチャガイド

概要

このガイドでは、インフラストラクチャの自動化、CI/CD パイプラインの開発、デプロイ戦略、モニタリング、クラウド運用について説明します。インフラストラクチャのプロビジョニング、パイプラインの構築、可観測性の設定、シークレットの管理、または災害復旧の計画を行う際にご利用ください。

最初の 10 分間

• 変更を提案する前に、CI 設定、インフラストラクチャのディレクトリ、ランタイムマニフェスト、Dockerfile、可観測性の設定など、デプロイに関わる対象を洗い出します。
• 編集を始める前に、既存の検証コマンドを実行します。リポジトリにインフラストラクチャの変更を検証する手段がない場合は、タスクの一環として追加します。
• リリース方法の変更を提案する前に、リポジトリのルートで scripts/analyze_deployment_risk.py を実行し、CI、Docker、Terraform、Kubernetes に関するシグナルを要約します。
• 現在のデプロイシステムにおけるロールバック方法を確認します。5 分以内に変更を元に戻す方法を説明できない場合、リリース計画は不完全です。

拒否またはエスカレーション

• ロールバック方法、正常性を示すシグナル、本番環境以外で変更をテストする手段のいずれもない状態で「とにかくプッシュして」という依頼があった場合は、拒否します。
• データベースの置き換え、Terraform によるリソースの破棄、状態の移動、証明書のローテーション、または補完的な対策のないセキュリティグループの範囲拡大が計画に含まれる場合は、本番環境の状態を変更する前にエスカレーションします。
• リポジトリで複数のデプロイシステムが混在し、所有権の境界が不明確な場合はエスカレーションします。その整理は別のタスクです。
• デフォルトで Kubernetes を推奨しないでください。単一のサービスでネットワークがシンプルかつスケールが予測可能な場合は、よりシンプルなランタイムを選びます。

インフラストラクチャの判断基準

プロビジョニング

• リモート状態（S3 + DynamoDB ロック）を使用する Terraform を使い、すべてのリソースをバージョン管理下に置いて、同時変更から保護します。
• 共有モジュールを使う Terraform ワークスペース、または環境ごとにディレクトリを分ける構成を採用し、ステージングと本番環境の間のドリフトを検出します。
• 本番環境と同じ Terraform モジュールを変数のオーバーライドとともに使います。クラウドコンソールからインフラストラクチャを作成してはいけません。

CI/CD パイプライン

• lint、test、build、scan、deploy などの独立したステージに分け、依存関係を明示して、セキュリティ上の問題が検出された場合にデプロイをブロックします。
• デプロイ戦略：ダウンタイムゼロと即時ロールバックには ブルーグリーン、メトリクスに基づいて昇格する段階的なトラフィック移行には カナリア、シンプルさを重視し、短時間のバージョン混在トラフィックを許容できる場合には ローリングを選びます。
• 2 回を超えて実施する手作業のステップは自動化し、ドリフトを防ぐために手動のランブック項目を削除します。

コンテナ化

• 攻撃対象領域を最小限に抑えるため、最終イメージに distroless または Alpine を使用したマルチステージ Docker ビルドを使います。
• CI では Trivy（または同等のツール）を実行し、マージ前に CRITICAL/HIGH の検出結果があれば失敗させる必要があります。

モニタリングと信頼性

• 4 つのゴールデンシグナル（レイテンシ、トラフィック、エラー、飽和）を計測し、原因ではなく症状に対してアラートを出します。
• すべてのアラートにランブックをリンクします。ランブックのないアラートは削除するか、1 スプリント以内にダッシュボードのメトリクスへ変更します。
• 構造化 JSON ロギングを徹底し、コンプライアンス要件に沿った保持期間で集中管理システム（ELK、Loki）に送信します。
• 30 秒で再起動するように liveness probe を設定し、障害発生時の可用性を確保するために PodDisruptionBudget を設定します。

災害復旧

• フェイルオーバーを自動化し、ランブックを四半期ごとにテストします。テストされていない DR 計画は、計画がないのと同じです。

コスト最適化

• クラウドの利用状況を毎月確認し、14 日間の CPU 使用率が平均 20% 未満のインスタンスはサイズを縮小します。

シークレット管理

• 自動ローテーション（TTL は最大 90 日）を設定した Vault または AWS Secrets Manager にシークレットを保存し、実行時に注入します。
• シークレットをソース管理にコミットしたり、イメージに組み込んだりしてはいけません。

ネットワークセキュリティ

• すべてのセキュリティグループと NACL のインバウンドルールをデフォルトで全拒否にし、必要なポート/CIDR のみ許可します。月次で不要なルールを整理します。

コンプライアンス

• デプロイ実行者、コミット SHA、承認を記録する監査ログを自動生成し、保持期間中は改ざんできない形で保存します。

インシデント対応プロトコル

• 重大度1（サイト停止、データ損失のリスク）：5分以内にインシデントチームを招集します。最初に行うのは、原因の診断ではなく、影響の緩和（ロールバック、フェイルオーバー、スケールアップ）です。15分以内に関係者へ状況を伝えます。48時間以内に事後分析を行います。
• 重大度2（パフォーマンス低下、一部停止）：オンコールエンジニアが15分以内に対応します。最近のデプロイ（1時間以内であればロールバック）、インフラストラクチャのアラート（CPU、メモリ、ディスク）、依存先の健全性（下流サービス、データベース）を確認します。30分以内に状況を伝えます。
• 重大度3（軽微な問題、回避策あり）：問題を記録してチケットを作成し、次のスプリントで修正します。即時対応は不要です。
• ロールバックの判断：問題が過去4時間以内のデプロイ後に発生した場合は、まずロールバックし、その後に調査します。問題とデプロイに関連がない場合は、該当するサービスチームにエスカレーションします。
• 連絡テンプレート：「[影響の説明]が発生していることを確認しています。[X 人のユーザー／トラフィックの Y%]に影響があります。[現在の対応]を行っています。次回の更新は[時刻]です。」

コスト見積もりの計算式

• コンピューティング（EC2/GCE）：monthly_cost = instance_hourly_rate * 730 * instance_count。リザーブドインスタンスを利用すると、定常的なワークロードで30〜60%のコストを削減できます（1年間の利用を契約します）。
• ストレージ（S3/GCS）：monthly_cost = storage_GB * $0.023 + requests * $0.0004 (GET) or $0.005 (PUT)。ライフサイクルポリシーを有効にし、30日後に低頻度アクセスストレージへ、90日後にGlacierへ移行します。
• データベース（RDS/Cloud SQL）：monthly_cost = instance_hourly_rate * 730 + storage_GB * $0.115 + IOPS_provisioned * $0.10。Multi-AZ ではインスタンスのコストが2倍になります。
• データ転送：月あたり最初の1GBは無料です。インターネットへの送信は1GBあたり$0.09です。AZ間は各方向で1GBあたり$0.01、リージョン間は1GBあたり$0.02です。データ転送は見落とされがちなコストです。監視してください。
• Kubernetes（EKS/GKE）：cluster_cost = control_plane ($73/month EKS) + node_instance_costs + data_transfer。耐障害性のあるワークロードでは、スポット／プリエンプティブルノードにより60〜90%のコストを削減できます。
• 経験則：クラウドの請求額が月5,000ドルを超えたら、FinOps のレビューを依頼してください。月50,000ドルを超えたら、AWS Cost Anomaly Detection などを利用してコストの異常検知を自動化してください。

サービス選定の判断ツリー

• コンピューティング：実行時間が15分未満、メモリが10GB未満で、リクエスト駆動の場合は Lambda/Cloud Functions を選びます。トラフィックが安定しているコンテナ化サービスには ECS/Cloud Run を選びます。複雑なネットワーク要件があり、10を超えるサービスを実行する場合に限り、EKS/GKE を選びます。
• データベース：10TB未満のリレーショナルデータには RDS PostgreSQL を選びます。QPS が100,000を超えるキーバリューデータには DynamoDB を選びます。キャッシュとセッションの保存には ElastiCache Redis を選びます。自動 Multi-AZ フェイルオーバーを備えた PostgreSQL 互換性が必要な場合は、Aurora を選びます。
• キュー／メッセージング：シンプルな非同期ジョブには SQS を選びます。ファンアウトには SNS + SQS を選びます。フィルタリングルールを使ったイベントルーティングには EventBridge を選びます。Kafka（MSK）は、再生機能を備えた毎秒10,000件を超えるストリーミングに限って選びます。
• ストレージ：オブジェクトには S3 を選びます。共有ファイルシステム（NFS）には EFS を選びます。ブロックストレージ（データベースボリューム）には EBS を選びます。アクセス頻度に基づいてストレージクラスを選択します。
• CDN：AWS ネイティブの環境には CloudFront を選びます。マルチクラウド環境または DDoS のリスクが高い環境には Cloudflare を選びます。すべての静的アセットと、5秒を超えてキャッシュ可能な API レスポンスには CDN を使用します。

自己検証プロトコル

インフラストラクチャやパイプラインを変更した後は、次の項目を検証してください。

• Terraform：terraform plan を実行し、差分のすべての行を確認します。プランに本番リソースの destroy または replace が表示された場合は、作業を中断して意図した変更か確認してください。
• CI/CD pipeline：本番環境以外のブランチでパイプライン全体を実行します。すべてのステージが成功することを確認してください。セキュリティスキャンのゲートが検出結果に対して実際にブロックするか確認します（既知の CVE を意図的に導入してテストしてください）。
• Monitoring：アラートを設定したら、各アラートを手動で発生させます（CPU 使用率を急増させる、ヘルスチェックを停止する、ディスクをいっぱいにする）。想定される時間内にアラートが発報し、正しいチャネルに届くことを確認してください。
• Disaster recovery：バックアップを設定したら、テスト環境に復元します。データの整合性を確認してください。復元できない場合、バックアップがあるのではなく、セキュリティが確保されているという誤った安心感を抱いているにすぎません。
• Secrets：次の場所にシークレットが表示されないことを確認してください。CI/CD ログ（変数をマスクする）、Docker イメージレイヤー（docker history）、Terraform の状態（sensitive = true を使用）、または git の履歴（git log -p | grep -i password）。

障害からの復旧

• Terraform の状態ドリフト：terraform plan を実行してドリフトを確認します。重要でないリソースにドリフトがある場合は、terraform apply を実行して整合させます。データベースやロードバランサーなどの重要なリソースにドリフトがある場合は、誰が、または何が手動で変更したのかを調査し、慎重に整合させます。状態に予期しない変更がある場合は、決して無条件に terraform apply を実行しないでください。
• CI/CD pipeline の障害：最後に成功した実行を確認します。最後に成功した時点と現在の失敗時点の間で、パイプライン設定の差分を確認します。よくある原因は、シークレットやトークンの期限切れ、依存関係のバージョン更新、ランナーイメージの更新、レジストリによるレート制限です。
• 本番環境でコンテナーが OOM により強制終了：OOM イベントについて kubectl describe pod を確認します。メモリ割り当てが不足している場合は、メモリ制限を増やします。メモリ使用量が時間とともに直線的に増加する場合、アプリケーションにメモリリークがあります。制限ではなく、アプリケーションを修正してください。
• 証明書の有効期限切れ：cert-manager（Kubernetes）または ACM（AWS）を使って更新を自動化します。有効期限の 30 日前、14 日前、7 日前にアラートを設定します。有効期限が切れた場合は、直ちに更新し、その証明書を使用しているすべてのサービスを確認して、新しい証明書が適用されていることを検証します（ポッドの再起動が必要な場合があります）。
• ディスク容量不足：何がディスクをいっぱいにしたのかを特定します。ログ（ローテーションして圧縮する）、Docker イメージ（未使用のものを削除する）、データベースの WAL（レプリケーションの遅延を確認する）、または一時ファイルを確認してください。根本原因を修正します。ディスクの拡張は一時的な対策です。

スクリプト

• scripts/validate_dockerfile.sh -- Dockerfile が一般的なベストプラクティスに従っているか確認します。マルチステージビルド、USER 命令、HEALTHCHECK、latest タグを使用していないこと、ADD ではなく COPY を使用していること、.dockerignore が存在することを確認します。使い方を確認するには --help を実行してください。
• scripts/check_services.sh -- host:port のペアのリストについて、TCP 接続と HTTP 応答を確認します。ステータス、レイテンシ、HTTP ステータスコードを報告します。使い方を確認するには --help を実行してください。

コード例

セキュリティスキャン、コンテナーのビルド、スモークテストを含むブルーグリーンデプロイを備えた GitHub Actions パイプライン全体については、CI/CD パイプラインガイドを参照してください。

Terraform（起動テンプレート、ASG、ALB、CloudWatch アラーム）と、アラートルールを含む Prometheus の設定については、インフラストラクチャとモニタリングのガイドを参照してください。

ワークフロー

ステップ 1：インフラストラクチャの評価

• 既存のインフラストラクチャ、デプロイプロセス、モニタリングの不足点を監査します。
• アプリケーションの依存関係とスケーリング要件を整理します。
• 対象環境のセキュリティ要件とコンプライアンス要件を特定します。

ステップ 2：パイプラインの設計

• セキュリティスキャンを統合した CI/CD パイプラインを設計します。
• デプロイ戦略（ブルーグリーン、カナリア、ローリング）を計画します。
• Infrastructure as Code のテンプレートを作成します。
• モニタリングとアラートの戦略を設計します。

ステップ 3：実装

• 自動テストを備えた CI/CD パイプラインを設定します。
• バージョン管理を使用して Infrastructure as Code を実装します。
• モニタリング、ロギング、アラートのシステムを設定します。
• ディザスタリカバリーとバックアップの自動化を作成します。

ステップ 4：最適化とメンテナンス

• システムのパフォーマンスを監視し、リソースを最適化します。
• コスト最適化の戦略を導入します。
• セキュリティスキャンとコンプライアンスレポートを自動化します。
• 自動復旧機能を備えた自己修復システムを構築します。

成果物

• 明確なロールバック手順、ヘルスゲート、担当者を含むデプロイ戦略。
• ステートフルなリソース、影響範囲、承認ポイントを列挙したインフラストラクチャの変更概要。
• lint、テスト、ビルド、スキャン、デプロイ、デプロイ後の検証を網羅した CI/CD 計画。
• 一般的なダッシュボードの要望ではなく、変更対象のサービスに紐づけた監視とアラートのチェックリスト。

参考資料

• CI/CD パイプラインガイド -- セキュリティスキャン、コンテナのビルド、ブルーグリーンデプロイを含む GitHub Actions パイプライン。
• インフラストラクチャと監視のガイド -- Terraform（起動テンプレート、ASG、ALB、CloudWatch アラーム）と Prometheus の設定。
• Kubernetes パターン -- 本番環境へのデプロイ、HPA、PDB、ConfigMap／Secret のマウント、TLS 対応 Ingress、CronJob、Helm の値。
• Docker のベストプラクティス -- マルチステージ Dockerfile（Node.js、Python、Go）、.dockerignore、Docker Compose、Trivy スキャン。
• 監視とオブザーバビリティ -- 構造化ログ、Prometheus メトリクス、Grafana ダッシュボード、アラートルール、OpenTelemetry トレーシング、ヘルスチェック。
• インシデントのトリアージ -- リポジトリを起点とする本番インシデント対応フロー、ロールバックの判断ツリー、証拠収集チェックリスト。
• デプロイのロールバックガイド -- カナリア、ブルーグリーン、ローリング、スキーマ変更、フィーチャーフラグのロールバックパターン。