DevOps - データサイエンス関連+αのメモ

DevOps は、開発（Development）と運用（Operations）の壁を取り除き、ソフトウェアを迅速かつ安定的に届け続けるための文化・プラクティス・ツールの総体。

従来は「開発チームが作ったものを運用チームが本番に持っていく」という分業体制だったが、このモデルではリリースが遅く、障害対応の責任が曖昧になりやすい。DevOpsはこの分断を解消することを目指す。

従来:  開発チーム ──→ (壁) ──→ 運用チーム ──→ 本番
DevOps: 開発・運用が一体となって継続的にデリバリー

DevOpsの三本の道（The Three Ways）¶

書籍 The Phoenix Project で提唱され、The DevOps Handbook で体系化された、DevOpsの根幹をなす3つの原則。

第一の道：フロー（Flow）¶

開発から本番への仕事の流れを速くする

作業の可視化（バックログ、かんばんなど）
バッチサイズを小さくする（小さな変更を頻繁にリリース）
手待ちや手戻りを減らす

第二の道：フィードバック（Feedback）¶

本番から開発へのフィードバックを速くする

障害・エラーをすぐに検知する（モニタリング・アラート）
テストで早期に問題を発見する
ユーザーの反応をすばやく把握する

第三の道：継続的学習（Continual Learning）¶

実験と学習の文化を組織に根づかせる

障害をペナルティではなく学習の機会として扱う（ポストモーテム）
改善のための時間を確保する
知識を組織全体で共有する

CI/CD¶

DevOpsの中核となる実践。

CI（継続的インテグレーション / Continuous Integration）¶

コード変更をメインブランチへ頻繁にマージし、そのたびに自動でビルド・テストを実行する。

開発者がコードをpush
      ↓
CI サーバーが自動実行:
  1. ビルド
  2. 静的解析・Lint
  3. 自動テスト
      ↓
結果を通知（Slack・PRコメントなど）

CIがない場合の問題：

長期間ブランチを切り離して開発すると、マージ時に大量のコンフリクトが発生する（“マージ地獄”）
バグの発見が遅れ、修正コストが膨らむ

CD（継続的デリバリー / Continuous Delivery）¶

CIを通過したコードを、いつでも本番にリリースできる状態に保つ。

CI 通過
  ↓
ステージング環境へ自動デプロイ
  ↓
受け入れテスト
  ↓
本番リリース（手動承認 or 自動）

継続的デリバリー と 継続的デプロイ（Continuous Deployment） の違い：

	継続的デリバリー	継続的デプロイ
本番反映	手動承認が必要	自動で本番反映
リスク	低い	より高い（自動化の信頼性が必要）
向いている場面	規制産業・慎重なリリースが必要	高速にフィードバックを得たい場合

代表的なCIツール¶

ツール	特徴
GitHub Actions	GitHubに統合されており、設定が簡単
GitLab CI/CD	GitLabに統合。セルフホストも可能
CircleCI	柔軟な設定。並列実行が得意
Jenkins	老舗のOSS。プラグインが豊富だが管理コストが高い

Infrastructure as Code（IaC）¶

インフラの構成をコードで管理する。手作業による環境構築を排除し、再現性・バージョン管理・自動化を実現する。

IaCのメリット¶

再現性 ：同じコードから何度でも同じ環境を作れる
バージョン管理 ：インフラの変更履歴をgitで管理できる
差分管理 ：現状と望ましい状態の差分を確認してから適用できる
ドリフト検出 ：手作業による設定変更を検知できる

代表的なIaCツール¶

ツール	対象	特徴
Terraform	クラウドリソース全般	宣言的。マルチクラウド対応
AWS CloudFormation	AWSリソース	AWS公式。YAMLで記述
Pulumi	クラウドリソース全般	汎用プログラミング言語で書ける
Ansible	サーバー設定	エージェント不要。YAMLで手順を記述

宣言的 vs 手続的¶

	宣言的（Declarative）	手続的（Procedural）
記述内容	「あるべき状態」を書く	「手順」を書く
例	Terraform, CloudFormation	シェルスクリプト, Ansible
冪等性	ツールが保証	自分で担保が必要

Terraformの例¶

# S3バケットを作成する例
resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"
}

resource "aws_s3_bucket_versioning" "example" {
  bucket = aws_s3_bucket.example.id
  versioning_configuration {
    status = "Enabled"
  }
}

terraform plan   # 変更差分を確認
terraform apply  # 実際に適用

モニタリングとオブザーバビリティ¶

本番環境で何が起きているかを把握し、問題を早期に検知・診断するための仕組み。

モニタリング vs オブザーバビリティ¶

	モニタリング	オブザーバビリティ
問いかけ	「今、問題が起きているか？」	「なぜ問題が起きているか？」
アプローチ	事前に決めた指標を監視	システムの内部状態を外部から推測できる
例	CPU使用率 > 80% でアラート	分散トレーシングでボトルネックを特定

テレメトリーの三本柱¶

オブザーバビリティを実現する3つのデータ種別。OpenTelemetryプロジェクトが標準化を推進している。

メトリクス（Metrics）¶

時系列の数値データ。集計・可視化・アラートに使う。

レスポンスタイム（P50, P95, P99）
エラーレート
スループット（req/s）
CPU・メモリ使用率

ログ（Logs）¶

イベントの記録。何が起きたかを詳細に把握する。

import logging

logger = logging.getLogger(__name__)

logger.info("order_created", extra={"order_id": "123", "user_id": "456"})
logger.error("payment_failed", extra={"order_id": "123", "reason": "card_declined"})

構造化ログ（JSON形式など）にすると、ログ収集基盤での検索・集計がしやすくなる。

トレース（Traces）¶

リクエストが複数のサービスをまたいで処理される流れを追跡する。マイクロサービス環境での問題特定に有効。

ユーザーリクエスト
  └─ APIゲートウェイ (10ms)
       └─ 注文サービス (50ms)
            ├─ 在庫サービス (20ms)
            └─ 決済サービス (200ms)  ← ここがボトルネック

SLI / SLO / SLA¶

用語	正式名称	内容
SLI	Service Level Indicator	計測する指標（例：可用性、レイテンシ）
SLO	Service Level Objective	SLIの目標値（例：可用性 99.9% 以上）
SLA	Service Level Agreement	ユーザーとの合意・契約（SLOを下回ると補償など）

エラーバジェット：SLOで許容している障害の余裕のこと。

SLO = 99.9% の場合、1ヶ月のエラーバジェット ≈ 43分
バジェットが残っているうちは新機能のリリースを積極的に進める
バジェットを使い切ったら安定性改善に集中する

代表的なツール¶

カテゴリ	ツール
メトリクス	Prometheus, Datadog, CloudWatch
ログ	Elasticsearch + Kibana, Loki, Datadog
トレース	Jaeger, Zipkin, AWS X-Ray
オールインワン	Datadog, New Relic, Grafana Stack

デプロイ戦略¶

本番環境への変更をどのように展開するかの戦略。リスクを最小化しながらリリースするための手法。

ブルーグリーンデプロイ¶

本番（Blue）と新バージョン（Green）の環境を並行して用意し、ロードバランサーで切り替える。

          ロードバランサー
               │
       ┌───────┴───────┐
    Blue環境         Green環境
   （現行ver）       （新ver）
       │                │
   本番トラフィック →  切り替え後にすべて流れる

メリット ：切り替えが一瞬。問題があればBlueに即切り戻し
デメリット ：インフラコストが2倍になる

カナリアリリース¶

新バージョンを一部のユーザーだけに段階的に展開する。

全ユーザー ──→ 旧バージョン（95%）
           └─→ 新バージョン（5%） ← まず少数に流す
                      ↓
              問題なければ段階的に拡大（20% → 50% → 100%）

メリット ：影響範囲を限定しながら検証できる
デメリット ：管理が複雑。複数バージョンが並行するDBスキーマ変更に注意

ローリングアップデート¶

複数のサーバーを順番に更新していく。

Server1: 旧 → 新  ✓
Server2: 旧 → 新  ✓
Server3: 旧 → 新  ✓
（Kubernetesのデフォルト動作）

メリット ：追加インフラ不要
デメリット ：更新中は新旧バージョンが混在する

フィーチャーフラグ（Feature Flags）¶

コードのデプロイとフィーチャーのリリースを分離する。フラグをオン/オフすることで特定ユーザーだけに機能を見せる。

def show_new_dashboard(user):
    if feature_flag.is_enabled("new_dashboard", user):
        return render_new_dashboard()
    return render_old_dashboard()

メリット ：デプロイを怖がらずに進められる。A/Bテストにも使える
デメリット ：フラグが増えるとコードが複雑になる（定期的に削除が必要）

インシデント管理¶

本番障害が発生したときの対応と再発防止の仕組み。

インシデント対応のフロー¶

検知（アラート・ユーザー報告）
      ↓
トリアージ（重大度の判定）
      ↓
対応チームのアサイン（インシデントコマンダー）
      ↓
原因調査・暫定対応（サービス復旧を最優先）
      ↓
根本原因の特定・恒久対応
      ↓
ポストモーテム（振り返り）

重大度の定義例（Severity Level）¶

レベル	内容	例
Sev1	サービス全停止。全ユーザーに影響	本番DBが落ちた
Sev2	主要機能が使えない	決済が通らない
Sev3	一部機能が劣化	検索が遅い
Sev4	軽微な問題	画面のレイアウトが崩れている

ポストモーテム（Post-mortem）¶

障害後に行う振り返りのこと。ブレームレス（blameless） で行うことが重要。人を責めず、システムや仕組みの問題として捉える。

ポストモーテムに書く内容：

インシデントの概要 ：何が起き、どのくらい影響したか
タイムライン ：検知から復旧までの経緯
根本原因 ：なぜ障害が発生したか（5 Whysなど）
対応策 ：再発防止のためのアクションアイテム

SRE（Site Reliability Engineering）¶

Googleが提唱した、信頼性を工学的アプローチで担保する職種・考え方。

開発エンジニアがオンコール（障害対応当番）を担う
トイル（toil：手作業の繰り返し作業）を自動化で減らす
エラーバジェットで新機能開発と安定性のバランスを取る