トイル
手作業で繰り返し行われる運用作業で、自動化によって削減すべき対象
トイルとは
トイル (Toil) は、Google の SRE (Site Reliability Engineering) が定義した概念で、手作業で繰り返し行われ、自動化可能で、サービスの成長に比例して増加する運用作業である。トイルを削減し、エンジニアリング作業 (自動化、設計改善) に時間を使うことが SRE の目標。
トイルの特徴
トイルの特徴を以下にまとめる。
| 特徴 | 説明 | 例 |
|---|---|---|
| 手作業 | 人間が手動で実行 | SSH してログを確認 |
| 繰り返し | 同じ作業を何度も行う | 毎朝のデプロイ確認 |
| 自動化可能 | スクリプトやツールで置き換え可能 | 手動のDB バックアップ |
| 戦術的 | 長期的な価値を生まない | アラートの手動対応 |
| スケールしない | サービスの成長で作業量が増加 | ユーザー追加の手動処理 |
トイルの例
手動デプロイは CI/CD パイプラインに、手動のサーバー設定は IaC (SAM, Terraform) に、手動のログ確認は CloudWatch Alarm + SNS に、手動の証明書更新は ACM (自動更新) に、手動のスケーリングは Auto Scaling に、手動のバックアップは DynamoDB PITR や RDS 自動バックアップに置き換える。
Google SRE の 50% ルール
SRE チームの作業時間の 50% 以上をトイルに費やしてはならない。50% を超えたら、自動化に投資してトイルを削減する。
理想: エンジニアリング 70% / トイル 30%
許容: エンジニアリング 50% / トイル 50%
危険: エンジニアリング 30% / トイル 70% → 自動化に投資
トイルの測定
トイルの測定を図で示す。
1. 1 週間の作業を記録
2. 各作業を「トイル」か「エンジニアリング」に分類
3. トイルの割合を計算
4. 最も時間を消費しているトイルから自動化
AWS でのトイル削減
インフラ構築は CloudFormation / SAM、デプロイは CodePipeline / GitHub Actions、モニタリングは CloudWatch + SNS、スケーリングは Auto Scaling や Lambda、バックアップは DynamoDB PITR や RDS 自動バックアップ、証明書管理は ACM (自動更新)、シークレット管理は Secrets Manager (自動ローテーション) で自動化する。
サーバーレスとトイル
Lambda + DynamoDB + API Gateway のサーバーレス構成は、サーバー管理、パッチ適用、スケーリングのトイルをゼロにする。
実務での活用方法は関連書籍にも詳しい。
この記事は役に立ちましたか?
関連用語
CI/CD
コードの変更を自動的にビルド・テスト・デプロイするパイプライン
オブザーバビリティ
システムの内部状態を外部から観測可能にし、問題の原因を迅速に特定するための仕組み
イミュータブルインフラストラクチャ
サーバーを変更せず、新しいイメージで丸ごと置き換えるインフラ運用手法
トイルバジェット
SRE が手作業の運用タスク (トイル) に費やす時間の上限を設定し、自動化を推進する管理手法
Operator パターン
Kubernetes のカスタムリソースとコントローラーで、アプリケーションの運用を自動化するパターン
ペットと家畜
サーバーを個別に管理する「ペット」から、使い捨て可能な「家畜」へ移行するインフラ運用の考え方