Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
SLO、SLI、SLA について考える : CRE が現場で学んだこと
2017年2月21日火曜日
前回
の『
CRE が現場で学んだこと
』シリーズでは、システムの可用性を担保するにあたってターゲットとする正確な数値をいかにして割り出すか、ということについてお話ししました。このターゲットをシステムのサービス レベル目標（SLO）と呼びます。
今後、システムが十分な信頼性を保って稼働しているか、またシステムにどんな設計やアーキテクチャの変更が必要かについて議論する際は、システムが継続的に SLO を満たしているという枠の中で語る必要があります。
SLO の適合性は直接測定することが可能です。システムにおいて精査が成功した頻度で計るのです。これをサービス レベル指標（SLI）といいます。システムが過去 1 週間 SLO を満たしつつ稼働していたかどうかを評価する場合に、SLI からサービスの可用率を把握するのです。定められた SLO を下回っているとなれば問題があるということですから、他の場所にあるサービスの第 2 インスタンスを稼働させて負荷を分散するなど、何とか可用性を上げる必要があるかもしれません。
なぜ SLO があるのか
前回お話しした
シェイクスピア サービス
について考えてみます。正式に定義した SLO のもとで同サービスを稼働させるのは厳しすぎるという決断を下したと想定してみましょう。そこで SLO を投げ出し、サービスを「適度に可用性がある」ようにしてみます。
これで物事は簡単になりました。時々システムが 1 時間ダウンしても気にしなくていいからです。実際、新サービスのリリースや停止と再開の際にダウンタイムが発生するのは普通なのですから。
ところが、残念なことにお客様はそれを知りません。以前はちゃんと使えていたシェイクスピア検索が、突然エラーばかり起こすようになったとしか感じないのです。
サポート担当者は優先度の高いチケットを発行し、エラー率を確認して担当者にエスカレーションします。オンコール対応のエンジニアが調査し、それが既知の問題であることを確認したら、お客様に対して「これはよく起こることですので、エスカレーションの必要はありません」と返答します。
SLO がない場合、どの程度のダウンタイムであれば許されるのかを原理に基づいて語ることができないのです。発生した問題がサービスにとって重大かどうかを判断する基準さえ存在せず、「シェイクスピア検索サービスは現在 SLO に沿って運用しています」と言ってエスカレーションを終えることもできません。
Google での同僚である Perry Lorier は決まってこう言います。「SLO がなければ、君たちの仕事はとても大変だ」と。
SLO を決めるとそれがユーザーの期待値に
一般的なパターンとしては、SLO を低く設定してシステムを始動させます。低くすれば簡単に基準を満たせるためです。1 週間 7 日、1 日 24 時間のローテーションなんて組みたくないですし、初期ユーザーは数時間ダウンタイムがあってもさほど気にしません。
そこで、可用性のターゲットを最低 99 %、つまり 1 週間のダウンタイムを 1.68 時間と設定したとしましょう。しかし、実際にはシステムに結構な回復力が備わっており、6 か月間 99.99 % の可用性で稼働し、ダウンタイムは 1 か月に数分でした。
しかし、あるときシステムのどこかで障害が発生し、数時間にわたってシステムがダウンしてしまいました。地獄のような事態です。
お客様はオンコールの担当者に連絡し、何時間もシステムが 500 エラーになると苦情を伝えようとします。しかし、その連絡に気づく人はいません。というのも、オンコール担当者はページャーを机に置いたまま帰宅してしまったからです。SLO の規定によると、サポートは営業時間内のみとなっていました。
問題は、いつでもサービスが利用できる状況にお客様が慣れてしまったことです。お客様は、常にサービスが利用できるという想定のもとで、自社のビジネス システムにサービスを組み入れるようになりました。6 か月間も継続して利用できていた中で、数時間も停止してしまうと、確実に何らかの問題が起こっていることになります。これまで高可用性を保っていたために期待値もそこに合わせられ、問題となってしまったのです。
だからこそ、「SLO は上からのターゲットでもあり、下からのターゲットでもある」という言葉があるのです。もし非常に信頼性の高いシステムを作ろうとは思っていなかったり、高信頼性を約束できなかったりするのであれば、そこまでシステムの信頼性を高くしなくてよいということなのです。
Google では、可用性を過度に高めないようにするため、一部のサービスで定期的にダウンタイムを実施するようにしています。Google の Marc Alvidrez は
SRE 本
の中で、内部ロック システムの Chubby について語っています。
また、テストに利用する内部サービス用テスト フロントエンド サーバーも用意されており、外部からサービスにアクセスできるようになっています。このフロントエンド サーバーは便利ですが、決して本番サービスで使うためのものではありません。サービス レベル契約（SLA）も 1 営業日となっているため、サポート チームが修復にとりかかるまで 48 時間ダウンしていてもいいことになっています。
フロントエンドで使われていた実験サービスは、時が経つと徐々に重要なものとなっていきます。そのため、フロントエンドで数時間のダウンタイムが発生すると大騒ぎになってしまいます。
Google は現在、このフロントエンドに対して四半期ごとに計画的ダウンタイムを実施しています。担当者が警告を送信し、一部のホワイト リストを除きフロントエンドのすべてのサービスをブロックするのです。そして、この状態を数時間続けます。もしくは、ブロックによって大きな問題が発生するまで続けます。問題が発生した場合は、迅速にブロックをリバースすることが可能です。
ダウンタイムの最後に、担当者はフロントエンドを不適切に利用しているサービスのリストを受け取り、より適した場所にサービスを移動することをサービスの担当者と検討します。この計画的ダウンタイムにより、フロントエンドの可用性は適度に低く保たれ、不適切な依存関係を事前に検知して修復できます。
SLA は SLO とは違う
Google では SLA と SLO を区別しています。一般的に SLA は、サービスの利用者に対して一定期間に一定レベルの可用性を約束するもので、その規定が満たされなかった場合は何らかの罰則も存在します。罰則として、お客様がその期間に支払ったサブスクリプション料金を一部返金することになるかもしれませんし、無料でサブスクリプションの期間を追加することになるかもしれません。つまり、SLA を破るとサービス部門が打撃を受けるため、SLA を満たそうと必死になるのです。
上記のことから、また原則可用性は SLO を大きく超えるものであってはならないことから、SLA は通常、SLO より緩めの目標を定めます。目標は可用性の数値で表すこともあります。
たとえば、1 か月の可用性は SLA で 99.9 %、内部的な可用性は SLO で 99.95 %、といった具合です。もしくは、SLO を構成する基準のサブセットのみを SLA として明記することも可能です。
シェイクスピア検索サービスの場合、API として提供することに決め、課金ユーザーは 1 日 100 万回まで検索を送信可能という条件で月額 1 万ドルを支払うとしましょう。
課金することになったため、契約書にはサービスの可用性がどの程度なのか、その契約を違反した場合どうなるかも明記しなくてはなりません。最低 99 % の可用性でサービスを提供するとし、以前お話ししたように成功クエリの定義も示すといった具合です。また、サービスの可用性が 1 か月 99 % 以下になった場合は 2,000 ドルを返金し、80 % 以下になった場合は 5,000 ドルを返金するといったことも明記します。
SLO とは異なる SLA を定めている場合（ほとんどのケースはそうなのですが）、SLA にきちんと準拠しているかを監査担当者が評価することが重要となります。SLA の期間に沿ってシステムの可用性を確認できるようにしておきたいでしょうし、SLA が満たされない危機が迫っていることも簡単に見極めたいと思うはずです。
また、一般的にはログや分析などにより、契約が守られていることを正確に評価する必要もあります。（SLA という形で）課金ユーザーに対して新たな責任を背負うことになったため、課金ユーザーのクエリをその他のクエリとは別に計測する必要も出てきます（ロード シェディングが必要となったときに、無料ユーザーのクエリが落ちてもあまり気にしなくていいかもしれませんが、課金ユーザーからのクエリについては適切に処理できないと大変です）。これが SLA を設定するもう 1 つの利点で、トラフィックの優先順位を決める明確な方法なのです。
SLA を定義する際は、どのクエリを正当なものとして数えるかに細心の注意を払う必要があります。
たとえば、主要ユーザー（サービスのトラフィックの大半を占めている）3 人に対し、1 人につき 1 日 100 万クエリを割り当てたとしましょう。ユーザーの 1 人がモバイル クライアントのバグだらけのバージョンをリリースし、変更を取り消すまで 1 日 200 万クエリを 2 日間発行しました。30 日の間に、うまくレスポンスを返した回数は約 9,000 万回、エラーの回数は 200 万回でした。つまり成功率は 97.8 % です。
このことで、全ユーザーに返金するのはいやだと思ってしまいますよね。2 人のユーザーの場合は全クエリが成功に終わっているし、3,200 万クエリのうち 200 万回のクエリを拒否されたユーザーの場合は自業自得だったわけですから。つまり、SLA を計算するときは「割り当て外」のレスポンス コードをすべて除外するようにしたほうがよいでしょう。
一方、帰宅前に担当者が誤って空の割り当て仕様ファイルをサービスにプッシュしてしまったとします。全ユーザーはデフォルトで 1 日 1,000 クエリを割り当てられています。上位 3 人のユーザーは、翌朝担当者が出社して問題に気づき変更を取り消すまでの 12 時間にわたって、常に「割り当て外」エラーになってしまいました。
この時点で、月間 9,000 万クエリのうち 150 万のクエリが拒否されたことになり、成功率は 98.3 % になっています。これはすべて担当者の責任です。100 % 成功している 8,850 万クエリをカウントするのはポイントがずれていますし、SLA を測定するうえでモラル的な失敗を犯していると言えるでしょう。
まとめ
SLI、SLO、SLA というものは、単に便利な抽象的概念にとどまりません。このような指標なしにはシステムの信頼性や可用性を把握できませんし、システムが役立っているかどうもわかりません。これらの指標を明確に事業目標と結びつけなければ、選択したことが事業を促進するものか邪魔になっているかさえわからないのです。また、お客様に対して誠実な約束をすることもできません。
一からシステムを構築しているのであれば、SLI、SLO、SLA をシステム要件に入れるようにしてください。すでにシステムが稼働しているのに明確な SLI、SLO、SLA を定めていない場合は、これらを定義することが最優先です。
以上のことをまとめると次のようになります。
信頼性のあるサービスを提供したいのであれば、まず「信頼性」を定義してください。実際には、信頼性は可用性を意味することがほとんどです。
サービスの信頼性を把握したいのであれば、成功クエリと失敗クエリの率を測定する必要があります。これが SLI の基となります。
サービスの信頼性が上がれば上がるほど、運用コストも高くなります。何とかやっていける最低レベルの信頼性を定義し、それを SLO としましょう。
SLA がなければ、サービスの信頼性を高めるべきか（コストが増加し開発速度が落ちます）、信頼性をより低くするべきか（開発速度が上がります）、チームも関係者も原理的な判断ができません。
ユーザーに課金するのであれば、SLA が必要となるでしょう。SLA は、SLO より少し緩めに設定しましょう。
SRE（Site Reliability Engineering）担当者として（また DevOps 専門家として）、システムがこうした目標を達成することでどう事業に役立つかを理解し、ハイレベルな目標を脅かすリスクを可能なかぎり管理するよう、責任を持たなくてはなりません。事業目標を無視するようなシステム可用性の基準は、価値のないものよりもひどいと言えます。なぜなら、実際の可用性を曖昧にし、さまざまな危機的状況や間違ったセキュリティの感覚、そして失敗につながるからです。
前回の記事にコメントや質問を送っていただいた皆さんにとって、今回の投稿が役立つものであれば幸いです。今後もフィードバックをお待ちしています。
注 :
Google Cloud Next '17
開催まで 1 か月を切りました。Google Cloud の SVP である Diane Greene や、Google の CEO である Sundar Pichai、その他著名人らによる基調講演やコードラボ、認証プログラム、さらには 200 以上にも上るテクニカル セッションにぜひ
ご登録
ください。ちなみに今回のイベントでは、Google の SRE や開発オペレーションのエキスパートとイベント参加者が交流できるような専用の場を初めて設けています。
* この投稿は米国時間 1 月 31 日、Customer Reliability Engineers である AJ Ross と Adrian Hilton、および Director of Customer Reliability Engineering である Dave Rensin によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By AJ Ross and Adrian Hilton, Customer Reliability Engineers, and Dave Rensin, Director of Customer Reliability Engineering
12 か月間のトライアル
300 ドル相当が無料になるトライアルで、あらゆる GCP プロダクトをお試しいただけます。
Labels
.NET
.NET Core
.NET Core ランタイム
.NET Foundation
#gc_inside
#gc-inside
#GoogleCloudSummit
#GoogleNext18
#GoogleNext19
#inevitableja
Access Management
Access Transparency
Advanced Solutions Lab
AI
AI Hub
AlphaGo
Ansible
Anthos
Anvato
Apache Beam
Apache Maven
Apache Spark
API
Apigee
APIs Explore
App Engine
App Engine Flex
App Engine flexible
AppArmor
AppEngine
AppScale
AprilFool
AR
Artifactory
ASL
ASP.NET
ASP.NET Core
Attunity
AutoML Vision
AWS
Big Data
Big Data NoSQL
BigQuery
BigQuery Data Transfer Service
BigQuery GIS
Billing Alerts
Bime by Zendesk
Bitbucket
Borg
BOSH Google CPI
Bower
bq_sushi
BreezoMeter
BYOSL
Capacitor
Chromium OS
Client Libraries
Cloud API
Cloud Armor
Cloud Audit Logging
Cloud AutoML
Cloud Bigtable
Cloud Billing Catalog API
Cloud Billing reports
Cloud CDN
Cloud Client Libraries
Cloud Console
Cloud Consoleアプリ
Cloud Container Builder
Cloud Dataflow
Cloud Dataflow SDK
Cloud Datalab
Cloud Dataprep
Cloud Dataproc
Cloud Datastore
Cloud Debugger
Cloud Deployment Manager
Cloud Endpoints
Cloud Firestore
Cloud Foundry
Cloud Foundry Foundation
Cloud Functions
Cloud Healthcare API
Cloud HSM
Cloud IAM
Cloud IAP
Cloud Identity
Cloud IoT Core
Cloud Jobs API
Cloud KMS
Cloud Launcher
Cloud Load Balancing
Cloud Machine Learning
Cloud Memorystore
Cloud Memorystore for Redis
Cloud monitoring
Cloud NAT
Cloud Natural Language API
Cloud Networking
Cloud OnAir
Cloud OnBoard
cloud Pub/Sub
Cloud Resource Manager
Cloud Resource Manager API
Cloud SCC
Cloud SDK
Cloud SDK for Windows
Cloud Security Command Center
Cloud Services Platform
Cloud Source Repositories
Cloud Spanner
Cloud Speech API
Cloud Speech-to-Text
Cloud SQL
Cloud Storage
Cloud Storage FUSE
Cloud Tools for PowerShell
Cloud Tools PowerShell
Cloud TPU
Cloud Translation
Cloud Translation API
Cloud Virtual Network
Cloud Vision
Cloud VPC
CloudBerry Backup
CloudBerry Lab
CloudConnect
CloudEndure
Cloudflare
Cloudian
CloudML
Cluster Federation
Codefresh
Codelabs
Cohesity
Coldline
Colossus
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Container-Optimized OS
Container-VM Image
Couchbase
Coursera
CRE
CSEK
Customer Reliability Engineering
Data Studio
Databases
Dbvisit
DDoS
Debugger
Dedicated Interconnect
deep learning
Deployment Manager
Developer Console
Developers
DevOps
Dialogflow
Disney
DLP API
Docker
Dockerfile
Drain
Dreamel
Eclipse
Eclipse Orion
Education Grants
Elasticsearch
Elastifile
Energy Sciences Network
Error Reporting
ESNet
Evernote
FASTER
Fastly
Firebase
Firebase Analytics
Firebase Authentication
Flexible Environment
Forseti Security
G Suite
Gartner
gcloud
GCP
GCP Census
GCP 移行ガイド
GCP 認定資格チャレンジ
GCPUG
GCP導入事例
gcsfuse
GEO
GitHub
GitLab
GKE
Go
Go 言語
Google App Engine
Google Apps
Google Certified Professional - Data Engineer
Google Cloud
Google Cloud Certification Program
Google Cloud Client Libraries
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Endpoints
Google Cloud Explorer
Google Cloud Identity and Access Management
Google Cloud INSIDE
Google Cloud INSIDE Digital
Google Cloud INSIDE FinTech
Google Cloud Interconnect
Google Cloud Launcher
Google Cloud Logging
Google Cloud Next '18 in Tokyo
Google Cloud Next '19 in Tokyo
Google Cloud Platform
Google Cloud Resource Manager
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud SQL
Google Cloud Storage
Google Cloud Storage Nearline
Google Cloud Summit '18
Google Cloud Summit ’18
Google Cloud Tools for IntelliJ
Google Code
Google Compute Engine
Google Container Engine
Google Data Analytics
Google Data Studio
Google Date Studio
Google Deployment Manager
Google Drive
Google Earth Engine
Google Genomics
Google Kubernetes Engine
Google maps
google maps api
Google Maps APIs
Google Maps Platform
Google SafeSearch
Google Service Control
Google Sheets
Google Slides
Google Translate
Google Trust Services
Google VPC
Google マップ
Google 公認プロフェッショナル
GoogleNext18
GPU
Gradle
Grafeas
GroupBy
gRPC
HA / DR
Haskell
HEPCloud
HIPAA
Horizon
HTCondor
IaaS
IAM
IBM
IBM POWER9
icon
IERS
Improbable
INEVITABLE ja night
inevitableja
InShorts
Intel
IntelliJ
Internal Load Balancing
Internet2
IoT
Issue Tracker
Java
Jenkins
JFrog
JFrog Artifactory SaaS
Jupiter
Jupyter
Kaggle
Kayenta
Khan Academy
Knative
Komprise
kubefed
Kubeflow Pipelines
Kubernetes
KVM
Landsat
load shedding
Local SSD
Logging
Looker
Machine Learning
Magenta
Managed Instance Group
Managed Instance Group Updater
Maps API
Maps-sensei
Mapsコーナー
Maven
Maxon Cinema 4D
MightyTV
Mission Control
MongoDB
MQTT
Multiplay
MySQL
Nearline
Network Time Protocol
Networking
neural networks
Next
Node
NoSQL
NTP
NuGet パッケージ
OCP
OLDISM
Open Compute Project
OpenCAPI
OpenCAPI Consortium
OpenShift Dedicated
Orbitera
Organization
Orion
Osaka
Paas
Panda
Particle
Partner Interconnect
Percona
Pete's Dragon
Pivotal
Pivotal Cloud Foundry
PLCN
Podcast
Pokemon GO
Pokémon GO
Poseidon
Postgre
PowerPoint
PowerShell
Professional Cloud Network Engineer
Protocol Buffers
Puppet
Pythian
Python
Qwiklabs
Rails
Raspberry Pi
Red Hat
Redis
Regional Managed Instance Groups
Ruby
Rust
SAP
SAP Cloud Platform
SC16
ScaleArc
Secure LDAP
Security & Identity
Sentinel-2
Service Broker
Serving Websites
Shared VPC
SideFX Houdini
SIGOPS Hall of Fame Award
Sinatra
Site Reliability Engineering
Skaffold
SLA
Slack
SLI
SLO
Slurm
Snap
Spaceknow
SpatialOS
Spinnaker
Spring
SQL Server
SRE
SSL policies
Stack Overflow
Stackdriver
Stackdriver Agent
Stackdriver APM
Stackdriver Debugger
Stackdriver Diagnostics
Stackdriver Error Reporting
Stackdriver Logging
Stackdriver Monitoring
Stackdriver Trace
Stanford
Startups
StatefulSets
Storage & Databases
StorReduce
Streak
Sureline
Sysbench
Tableau
Talend
Tensor Flow
Tensor Processing Unit
TensorFlow
Terraform
The Carousel
TPU
Trace
Transfer Appliance
Transfer Service
Translate API
Uber
Velostrata
Veritas
Video Intelligence API
Vision API
Visual Studio
Visualization
Vitess
VM
VM Image
VPC Flow Logs
VR
VSS
Waze
Weave Cloud
Web Risk AP
Webyog
Wide and Deep
Windows Server
Windows ワークロード
Wix
Worlds Adrift
Xplenty
Yellowfin
YouTube
Zaius
Zaius P9 Server
Zipkin
ZYNC Render
アーキテクチャ図
イベント
エラーバジェット
エンティティ
オンライン教育
クラウド アーキテクト
クラウド移行
グローバル ネットワーク
ゲーム
コードラボ
コミュニティ
コンテスト
コンピューティング
サーバーレス
サービス アカウント
サポート
ジッター
ショート動画シリーズ
スタートガイド
ストレージ
セキュリティ
セミナー
ソリューション ガイド
ソリューション: メディア
データ エンジニア
データセンター
デベロッパー
パートナーシップ
ビッグデータ
ファジング
プリエンプティブル GPU
プリエンプティブル VM
フルマネージド
ヘルスケア
ホワイトペーパー
マイクロサービス
まっぷす先生
マルチクラウド
リージョン
ロード シェディング
運用管理
可用性
海底ケーブル
機械学習
金融
継続的デリバリ
月刊ニュース
資格、認定
新機能、アップデート
深層学習
深層強化学習
人気記事ランキング
内部負荷分散
認定試験
認定資格
料金
Archive
2019
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
6月
5月
4月
3月
2月
Feed
月刊ニュースレターに
登録
新着ポストをメールで受け取る
Follow @GoogleCloud_jp
