Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
可用性とどう向き合うべきか、それが問題だ : CRE が現場で学んだこと
2017年2月14日火曜日
この『
CRE が現場で学んだこと
』シリーズでは
前回
、ロード シェディングという手法で「成功による障害」を切り抜ける方法について紹介しました。これに対して素晴らしいフィードバックをたくさんいただきましたが、その中に、いかにして数値を事業目標と結びつけるべきかという質問がいくつかありました。
そこで今回は、最初の原理に立ち戻り、そもそも成功とは何を意味するのかを追究し、実際にシステムが成功しているかどうかを把握する方法について考えてみたいと思います。
成功の前提となるのは
可用性
です。可用性のないシステムは機能を実行できませんし、最初の段階で失敗します。では、可用性とは一体何なのでしょうか。まずはこの言葉を定義しなくてはなりません。
可用性とは、システムが意図した機能をある時点で実行できるかどうかということです。可用性の測定はレポーティング ツールとして活用されるほか、過去の可用性を見ることで、今後もシステムが期待どおりに動くかどうかも把握できます。
可用性は、直接時間で計測されるだけでなく、時にはリクエスト数によって計測されることもあります。いずれにしても数式の構造は同じで、合計の単位を成功の単位で割ることになります。
たとえば、稼働時間 /（稼働時間 + 停止時間）や、成功したリクエスト数 /（成功したリクエスト数 + 失敗したリクエスト数）という数式で可用性を計測できます。どの単位を使用するかにかかわらず、計測の結果は 99.9 % や 99.999 % といった割合で示され、これをスリー ナイン、ファイブ ナインと呼ぶこともあります。
可用性を高める一番の方法は、失敗（停止時間や失敗リクエストなど）の要因に焦点を当てることです。時間ベースの可用性を例に説明しましょう。
一定の期間（たとえば 30 日、または 4 万 3,200 分）と、可用性の目標値 99.9 %（スリー ナイン）があったとします。単純計算では、このシステムには 30 日間のうち 43.2 分以上の停止時間が認められていません。43.2 分という数字は、計画時の非常に具体的な数値となっており、エラー予算と呼ばれることがあります。30 日の間に 43.2 分以上システムが停止すると、可用性の目標が達成できなかったことになるのです。
エラー予算を理解し計画するにあたって、より深い 2 つの概念が使われることがあります。
1 つは Mean Time Between Failures（
MTBF
）であり、失敗の間隔の平均時間を表します。数式は、（稼働時間の合計）/（失敗の回数）です。
もう 1 つは Mean Time to Repair（
MTTR
）で、失敗から回復するまでの平均時間です。数式は、（停止時間の合計）/（失敗の回数）です。
こうした数値は（過去 3 か月や過去 1 年など）過去にさかのぼって計算でき、（合計期間 / MTBF）× MTTR という数式で予想停止時間を計算することも可能です。先ほどの例から引き続き計算すると、過去の MTBF が 10 日間で、過去の MTTR が 20 分となり、停止時間は 60 分となることが予想されます（計算式は（30 日 / 10 日）× 20 分です）。
つまり、スリー ナインという可用性の目標値を達成するうえでのエラー予算である 44 分をオーバーしてしまいます。目標を達成するには、MTBF を（20 日ごとといったように）低減させるか、MTTR を（10 分などに）抑えるか、もしくはその両方を組み合わせるしかありません。
可用性を定義する際に、エラー予算や MTBF、MTTR などの概念を念頭に置くと、なぜ目標値がそのように設定されたのかを正当化するのに役立ちます。単に目標としていくつのナインが必要だというのではなく、その目標値を、許容された停止時間や停止頻度、回復までの時間といったユーザー エクスペリエンスと結びつけることが可能になるのです。
次に、可用性の計測時にユーザー エクスペリエンスに焦点を当てる方法について考えてみましょう。
可用性の計測
システムの可用性が担保されていることを、どのようにして把握すればよいのでしょうか。ここで、架空の「シェイクスピア」というサービスを想定してみましょう。
シェイクスピアは、シェイクスピアの小説に登場する特定の言葉やフレーズが言及されていることを探し出すサービスです。これは標準的な例であり、Google でもトレーニングの際によく使われていて、
SRE（サイト信頼性エンジニアリング）の本
でも数多く引用されています。
では、架空シェイクスピア システムの可用性を判定する科学的な手法を試してみましょう。
問題 : システムはどの程度稼働していますか？
観察 : shakespeare.com にアクセスすると、通常は “200 OK” というステータス コードと HTML blob が返ってきます。滅多にありませんが、500 Internal Server Error や接続失敗となることもあります。
仮説 : 1 日間のリクエストにおいて 200 OK となる率が可用性だとすると、システムは 99.9 % の可用性を担保しています。
測定 : シェイクスピア サービスのウェブ サーバーのレスポンス ログを追いかけ、ログ処理システムでダンプします。
分析 : 1 日の可用性を、200 OK となるレスポンス率と、リクエスト数の合計で計算します。
解明 : 7 日後、どの日も最低 99.7 % の可用性が担保されていました。
この可用性の数値を上司（Dave）に上機嫌で報告し、帰宅します。うまく仕事をこなせましたね。
翌日、Dave はサポート フォーラムに注目します。ユーザーが、shakespeare.com で検索しても何も結果が出てこないと文句を言っているのです。問題が起こっていることは明らかなのに、なぜ可用性ダッシュボードには昨日 99.7 % の可用性を担保していると示されているのか、Dave は問いただします。
ログを確認してみると、過去 24 時間にウェブ サーバーはちょうど 1,000 件のリクエストを受信し、3 件は 500 Internal Server Error となったものの、他はすべて 200 OK となっていました。1 秒あたり少なくとも 100 クエリがあったとすると、ダッシュボード上では何も問題がないのにユーザーがフォーラムで文句を言っている理由がわかります。
つまり、可用性を定義する際の測定方法がユーザーの期待値や事業目標に合っていないという典型的な間違いを起こしてしまったのです。
ブラック ボックスを監視し、ユーザー エクスペリエンスに基づいた可用性を再定義する
シェイクスピアのフロントエンド サービスがバックエンドにまで届くことを防ぐように、（設定ファイルのタイプ ミスという）致命的な問題を修正したら、今度はシステムの可用性の意味をもう一度考えてみましょう。
「shakespeare.com で 200 OK となる率」が適切な可用性の測定法でないのだとしたら、どうやって可用性を測定すればよいのでしょうか。
Dave は、ユーザーが感じる可用性を知りたいと考えています。shakespeare.com が稼働しているとユーザーが感じるのはどんな場合なのでしょうか。あれこれと活発に議論した結果、システムが稼働しているという状況は、ユーザーが shakespeare.com にやって来て、質問を入力し、5 秒以内に 100 % その結果が返される状況だということで落ち着きました。
そこで、ブラック ボックスの「探査機」を作ることにします（ブラック ボックスとしているのは、シェイクスピア サービスの実装に関しては何も想定しないためです。
SRE 本
の第 6 章を参照してください）。
この探査機を用いて、（モバイルやデスクトップなど）完全なクライアント サービスをエミュレートします。それぞれのタイプのクライアントから shakespeare.com にアクセスし、「生きるべきか死ぬべきか」というフレーズを入力し、その結果にハムレットへのリンクが含まれているかを確認します。
この探査機を 1 週間稼働させた後、1 日の最小の可用性を再計算してみます。その結果、5 秒以内にハムレットという結果を返したのは 80 % で、18 % は 5 秒以上かかり、1 % はタイムアウトに、残り 1 % はエラーとなっていました。つまり、可用性の定義上、20 % ものクエリが完全に失敗に終わっていたのです。
事業目標に即した可用性を設定する
ショックから立ち直った Dave は素朴な疑問を抱きます。「なぜ 5 秒以内に 100 % の結果を返せないのだろうか？」
最初に思いつく理由は、停電やファイバーが切れたといった、ありきたりのものばかりでした。約 1 時間後、ようやく Dave は、5 秒以内に 100 % クエリに応答することは到底無理なのだと認めるようになります。
「じゃあ、どの程度の可用性であれば提供できるのだろうか？」と Dave は考えます。
その質問に対し、Dave にさらなる質問を投げかけてみましょう。「事業目標を達成するために必要な可用性とは何なのか？」
Dave の目が輝きました。事業目標としているのは年間売上高 2,500 万ドルです。1 回のクエリにつき平均 0.01 ドルの売上げは立っています。（1 秒あたり 100 クエリ）×（年間 3,153 万 6,000 秒）×（成功率 80 %）×（1 クエリあたり 0.01 ドル）で計算すると、年間売上高は 2,523 万ドルとなります。つまり、失敗率が 20 % だとしても、売上目標は達成できるのです。
とはいえ、失敗率 20 % というのはちょっといただけません。売上目標が達成できそうだとしても、あまりいいユーザー エクスペリエンスとは言えませんし、その結果何らかの影響があるかもしれません。この状況を改善すべきでしょうか。もし改善するのであれば、可用性の目標はどうすべきでしょうか。
コストと利益の妥協点、機会費用を考える
エンジニアが 6 か月かけて問題を修復し、クエリの返答に 5 秒以上かかる率を 0.5 % まで低減できるとしましょう。この問題の修復に着手すべきかどうか、どうやって決めればよいのでしょうか。
まず、20 % の失敗率が製品のライフにおいてどの程度の売上損失につながるのか（リトライするのをやめてしまうユーザーがどの程度いるのか）、見積もってみましょう。問題の修復にかかるコストはだいたい把握できています。単純に、エラー率によって失われる売上げが問題修復にかかるコストを上回っているのであれば修復する、と決めてしまうことも可能です。
ただし、これは重要な要素を無視しています。問題修復における機会費用です。問題の修復にかかる時間を他に回せばエンジニアはどんなことができるのか、考えてみてください。
シェイクスピア サービスの検索結果の関連性を高める新しい検索アルゴリズムがあるとしましょう。そのアルゴリズムを導入すれば、可用性は変わらなくても検索トラフィックが 20 % 増加するかもしれません。こうしたトラフィックの増加で、可用性が低いことによる売上げの損失は簡単に相殺できる可能性があるのです。
SRE でよく言われていることに、「必要とされるだけ可用性が高くなるようにシステムを設計せよ。ただし、それ以上のシステムは必要ない」という言葉があります。Google ではシステム設計時に、特定の MTBF や MTTR といった数値ではなく、（99.9 % というような）可用性を目標値として定めます。この可用性が達成できれば、今度は MTBF よりも MTTR のほうに重点を置き、迅速に修復を行えるような運用の形態に最適化します。失敗は避けられないものであり、「希望は戦略ではない」ことを認めるのです。
ほとんどの場合、SRE はユーザーにとって明らかに影響のある大きな問題を数分で軽減させることができます。そのため、Google のエンジニア チームは、迅速な開発と高可用性を両立させているという評判を得ているのです。
可用性と開発速度の妥協点は、最終的には事業側で決めることです。製品に対する可用性を正確に定義することで、本質的な議論ができ、満足のいく選択が可能になるのです。
注 :
Google Cloud Next '17
開催まで 1 か月余りとなりました。Google Cloud の SVP である Diane Greene や、Google の CEO である Sundar Pichai、その他著名人らによる基調講演やコード ラボ、認証プログラム、さらには 200 以上ものテクニカル セッションにぜひ
ご登録ください
。ちなみに今回のイベントでは、Google の SRE や開発のエキスパートとイベント参加者が交流できるような専用の場を初めて設けています。
* この投稿は米国時間 1 月 26 日、Customer Reliability Engineers である AJ Ross、Matt Brown、Adrian Hilton と、Director of Customer Reliability Engineering である Dave Rensin によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By AJ Ross, Matt Brown 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
