Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
エラー バジェットの使い過ぎを解消する : CRE が現場で学んだこと (後編)
2018年7月24日火曜日
前回の『
CRE が現場で学んだこと
』では、
サービスのエラー バジェット
と、サービスの信頼性目標、つまり SLO（サービス レベル目標）の遵守状況をエラー バジェットから把握することについて解説しました。
エラー バジェットを使い過ぎる理由
を把握できたら、次にやるべきことは問題を根本的に解決することです。
エラー バジェットの負債
クレジットカードを使い過ぎてしまい、その代金が毎月ごそっと口座から引き落とされた経験をお持ちではないでしょうか。うまく家計をやりくりするには、毎月の請求額を減らすよう負債をできるだけ支払っていくべきです。エラー バジェットについても同じことが言えます。
エラー バジェットの消費状況を分析し、消費率を高めている原因が特定できたら、新機能を担当している開発者の手を借りてでも、その原因に対処するための準備をしなくてはなりません。対処法としては、QA（品質保証）環境や試験セットを改善し、本番環境への移行前に多くのリリース エラーを見つけ出す方法もあれば、ロールアウトの自動化やモニタリングを改善し、不具合のあるリリースをより迅速に発見しロールバックする方法もあります。
こうしたアプローチの結果として、リリースの頻度が減ったり、リリースごとの変更点が減少してエラー バジェットへの影響が小さくなったりすることもあります。一時的にリリースのスピードを落とすのは、将来的に元のスピードで安全にリリースできるようにするためです。
下流での消費状況を把握する
もう 1 つ考慮すべきことがあります。エラー バジェットの使い過ぎの原因が開発者とは関係のないケースのときです。データセンターやクラウド プラットフォームで障害が発生した場合、開発者はなす術がありません。確かに、エンドユーザーはサービスの停止理由など気にかけないでしょうし、サービスの提供側もエンドユーザーにこれ以上迷惑はかけたくないでしょう。ただ、別の場所で発生した障害で自社の開発者を責めるのは無理があります。上述したように、エラー バジェットの消費状況を分析する際、この点は明確にしておきましょう。
次に、プラットフォームのオーナーに過去の（数値化された）信頼性状況を確認し、サービスの運用にあたって目標とする SLO とどう適合させるかを相談する必要があるかもしれません。その際、プラットフォーム側とサービス側の両方で変更が必要となることもあります。プラットフォームに特定の不具合が発生した場合に備えて、サービス側のシステムでそれを検知し、不具合に耐えられるようなシステムに変更するのです。プラットフォーム側でも検知機能を向上させれば、サービスに影響が出るような障害に迅速に対応してもらうことも可能になります。
プラットフォームが大幅に変更されるようなことは、実際はあまりありません。そのため、今後その障害にどう対応するかは決めておきましょう。障害を重大視するのであれば、影響を受けたクラウドのリージョンからサービスを自動的に他のリージョンにフェイルオーバーさせるオプションを実装（そして実行）するなど、回復力を高めるための対応が必要になります（これに関しては過去の
ブログ記事
で扱っています）。
ソフトウェアのリリースに問題があるケース
分析の結果、エラー バジェットの使い過ぎの主な原因がソフトウェアのリリースだったというケースもあります。確かに、私たち Google の経験から言えば、バイナリのロールアウトは障害の最も大きな理由の 1 つです。この場合、たとえば事後分析は次のような文章から始まるでしょう。「ソフトウェアの新リリースをロールアウトしたら、ユーザーが喜ぶであろう＜X＞となるはずだったのが、実際には＜Y＞となってしまい、ユーザーのブラウザでエラーが発生したり、猫の写真が表示できなかったり、1 分間にメールが 100 通戻ってきたりした。」
エラー バジェットをオーバーするような粗悪なリリースが連続しているときの模範的な対応は、新機能のリリースを凍結することです。これは最終手段と考えてよいでしょう。負債を減らす努力が十分な信頼性向上に結びついていないと認めることになるため、ユーザー エクスペリエンスを維持するには変更の頻度を下げることが求められるのです。リリースの凍結により、開発チームには時間や方向性が与えられ、頭を切り替えて信頼性向上に再度集中できるようになります。とはいえ、これはかなり思い切った方法です。
リリースの凍結を避けたい場合は以下のような方法もあります。
合意のもとで機能と信頼性のバランスを調整する : たとえば、いつも 2 週間分の仕事を割り振り、通常はそのうち機能面の開発に 95 %、事後分析への対応やその他の信頼性関連の仕事に 5 % 費やしているとします。SLO が遵守できていない間は、その割合を 50 % ずつにすると決めるのです。
サービスをオーバープロビジョニングする : たとえば、ほかのクラウド ゾーンやリージョンにレプリケートするための投資を増やしてみましょう。もしくは、サービスのレプリカを稼働させ、トラフィックの負荷が上昇しても対応できるようにします。ただしこれは、このアプローチがエラー バジェットの消費抑制に有効だと判断した場合のみ有効です。
リライアビリティ インシデントが発生したと申告する : 事後分析とエラー バジェットの使用状況を分析し、解決法を探る担当者を決めましょう。こうした解決法を最優先にすると事前に表明しておくことが重要です。
凍結状態の期間
実際に新機能を凍結させる必要があるとしたら、いつまで凍結を続ければよいのでしょうか。一般的には、エラー バジェットの使い過ぎが改善され、同じことが起こらないと確信が持てるまでです。エラー バジェットの計算方法は主に 2 つです。固定された期間で計算する方法と（毎月 1 日～月末）、定期的な間隔で計算する方法です（過去 N 日）。
固定期間でエラー バジェットを計算する場合、エラー バジェットの使い過ぎへの対応は、バジェットをオーバーするタイミングによって決まります。たとえば初日にオーバーすると、その月はずっとリリースを凍結することになります。ただし 28 日目にオーバーしても、実際にリリースをやめる必要はないかもしれません。次のリリースは、エラー バジェットがリセットされた翌月になる可能性があるためです。お客様が月ごとの停止状況を気にしているのなら話は別ですが、これはユーザー エクスペリエンスを最適化するにあたってあまりいい方法とは言えません。
一方、30 日間隔でエラー バジェットを測定すると、可用性 99.9 % のサービスは N-30 の間隔で使用したエラー バジェット分を埋め合わせることになるため、20 分のオーバーとなったときは、20 分の借金分がなくなるまで待たなくてはなりません。つまり、N-29 日に 15 分のバジェットを消費し、N-28 日に 5 分のバジェットを消費した場合、残高をプラスの状態にするには、ほかに障害が起こらないと仮定しても 2 日間待つ必要があります。実際には、バッファーとしてエラー バジェットの 20 % 分が貯まるまで待てば、予期せぬ小規模な障害にも対応できるようになります。
この方法に従ったうえで、月間の全エラー バジェットを 1 日で使い切るような大規模障害が発生した場合は 1 か月間の凍結を余儀なくされますが、実際にはこのようなことは受け入れられないでしょう。ただ少なくとも、リリースのスピードを大幅に緩め、根本的原因の修復に時間を割く必要はあるでしょう（前述の「エラー バジェットの負債」の項を参照してください）。ほかにもアプローチはあります。『CRE が現場で学んだこと』シリーズの過去記事でリリースの停止について解説しており、そこで
エスカレーション ポリシーの例を分析
しています。
以上のように、定期的な間隔でのエラー バジェット測定は、障害が発生した日にちに応じて対応が異なるということもありません。できる限りこの方法を採用するようお勧めしますが、現在の監視ツールでこのようなデータを収集することは難しいかもしれません。
リリースの凍結による長期的なコスト
新機能のリリース凍結にもコストはかかります。最悪のケースとしては、開発者による新機能の開発が続いているにもかかわらず、それをユーザーにリリースすることはせず、結果として変更点が積み重なり、後でリリースを再開したときに次々と不具合が見つかるということがあります。
これは実際に起こっていることです。たとえば、ブラックフライデーやニューイヤーなどのイベントでサービスの新リリースを凍結すると、その翌週はバックアップしていた変更のすべてがユーザーに届けられることになり、サービスに不具合が発生して非常に忙しくなります。こうした状況を避けるには、凍結の影響を受けるチームに対して、この凍結が機能の開発ではなく信頼性の開発に注力する余裕を持つためのものであることを、再度強調しておくことが重要です。
また、すべてのリリースを凍結することが難しい場合もあるでしょう。カンファレンスなどの大規模なイベントを予定しているときは、直近のユーザー エクスペリエンスがどうであれ、特定の新機能を本番環境にプッシュしなくてはならないこともあります。そこで、このような場合は
特効薬
を投入することも検討してみましょう。製品管理チームは、重要な機能をデプロイするために、リリースの凍結を無効にできるという（非常に制限された）権利を持っています。特効薬をうまく使う方法としては、この権利の行使には高額な費用がかかるようにし、頻度も制限することですが、特効薬の投入は障害と見なされるべきであり、事後分析を実施してなぜこうなったのか、今後の発生リスクを抑えるにはどうすればよいのかを調べる必要があります。
エラー バジェットを自社（およびユーザー）のために利用する
サービスの信頼性向上に信念を持って取り組んでいるのであれば、エラー バジェットは非常に重要な概念となります。家計の予算と同様に、エラー バジェットは（サービスの所有者が）使うためにあるもので、使い過ぎた場合にどうするかは、実際に予算オーバーとなる前にサービスの利害関係者間で合意しておくことが必要です。
エラー バジェットの使い過ぎが判明したときは、信頼性改善に向けて開発時間を優先させる機能凍結が効果的な方法となるでしょう。ただし、使い過ぎたからといって、反射的にリリースを凍結することが常に適切な対応とは限りません。エラー バジェットがどこで使われたのかを見極め、使い過ぎの発生源を縮小し、財布の紐を緩めるのが適切かどうか考えてみましょう。一番重要な原則は、データに基づいて実施することです。
SRE（サイト信頼性エンジニアリング）についてより詳しく知りたい方は、7 月に米国サンフランシスコで開催される Next '18 にぜひご参加ください。
SRE の原則をサービスのデプロイや管理に適用する方法
について紹介します。
関連コンテンツ
SLO のエスカレーション ポリシー : CRE が現場で学んだこと
可用性とどう向き合うべきか、それが問題だ : CRE が現場で学んだこと
*この投稿は米国時間 6 月 28 日、Adrian Hilton、Alec Warner、および Alex Bramley によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Adrian Hilton, Alec Warner and Alex Bramley
エラー バジェットの使い過ぎが意味するもの : CRE が現場で学んだこと
2018年7月18日水曜日
『
CRE が現場で学んだこと
』シリーズでは、これまでも Google の
CRE（顧客信頼性エンジニアリング）
チームによる SLO（サービス レベル目標）の記事を掲載してきました。SLO とは、サービスが満たすべき信頼性の目標をエンドユーザーの視点から定めたものです。
SLO では特定の期間内にどの程度サービスのダウンタイムを許容するかを指定します。たとえば 99.9 % の可用性が求められるサービスの場合、30 日間における許容ダウンタイムは 43 分です。この時間がエラー バジェットとなります。家計の予算と同様に、エラー バジェットは、予算オーバーにならない限り 30 日間に利用してもよいとされるものです。
日々の運用での積み重ねや、大規模障害によってエラー バジェットを使いきってしまった場合、サービスを使用するユーザーは困難な状況に置かれることになるため、何とか対処しなくてはなりません。
では、一体どうすればよいのでしょうか。今回の記事では、エラー バジェットを再調整する必要があるかどうかを判断するときに考慮すべき点について説明します。
何にエラー バジェットを費やしているか
SLO は、対応する SLI（サービス レベル指標）のターゲット値となります。SLI はエンドユーザー エクスペリエンスの重要な部分の測定値です。先ほど例として挙げた、99.9 % の可用性が求められるシステムの SLI は、「すべての 20x および 50x の HTTP レスポンスのうち、成功した HTTP レスポンス（200）の割合」となります。エラー バジェットの使用量は、サービスが SLO のすべてを達成できなかった測定期間の割合で計算します。これは、SLI の粒度や正確さに応じて、1 分ごとや 1 時間ごと、あるいは 1 日ごとに計算することも可能です。
日々のエラー バジェットを分析するには、測定期間中に使用したエラー バジェットについて、その主な理由がどこにあるのかを明らかにする必要があります。
ほとんどのエラーがバイナリ リリースの際に発生している場合は、リリースの頻度を控えたり、エラーを起こりにくくしたり、
エラーが発生しても影響があまり出ないようにしたり
といった対策が必要です。そうしないと、エラー バジェット内に収めることは難しいでしょう。
断続的なアプリケーション障害によってずっと同じようなエラーが発生し、それがエラー バジェットの大半を占めている場合は、アプリケーションに根本的な欠陥があるということです。ログを掘り下げて問題のクエリを探し、エンジニアと協力して根本的原因を特定したうえで、直接対処するか、もしくは次のプロジェクトの計画サイクルで修正しなくてはなりません。
“configuration pushes” や過度の負荷、“queries-of-death” が原因でサービスの大半が何分間にもわたって停止するような大規模アプリケーション障害が発生し、そこにエラー バジェットの大半が費やされている場合は、
効果的な事後分析
を実施して根本的原因を突き止め、障害を緩和させるべきでしょう。開発エンジニアの力を借りて、事後分析で優先順位トップとされた事項に対応する必要があります。したがって、機能の開発やリリースはおのずと後回しになります（これについては
別の記事
で詳しく説明します）。
クリティカルなバックエンドやコンピューティング プラットフォームのような制御対象以外との依存関係によって多くのエラー バジェットが消費されている場合は、その依存関係を見直すか、プラットフォームのオーナーと直接交渉し、SLI を示したうえで、サービスの信頼性を向上させる方法や予期される障害モードへの耐性を高める方法について話し合ってみましょう。
いずれのケースでも、問題に十分対処できたかどうかを客観的に測定することになります。以前は落ち込んでいた状況で SLI が高い状態を保つことが求められるのです。
シグナルを正しく査定しているか
ほかにも検討すべきことがあります。障害がユーザーの真の悩みを反映しているかどうかです。まとまった量のエラー バジェットを一気に使ってしまうような大規模障害が発生しても、そのことをユーザーはあまり気にしていないと確信が持てる場合は、開発業務やアーキテクチャを変更する必要はないかもしれません。とはいえ、何らかの修正は必要でしょう。新たに SLO の目標レベルを下げるか、ユーザー エクスペリエンスをより反映した別の SLI を検討するべきです。
ユーザー エクスペリエンスが低下してもユーザーは耐えられるか
99.9 % の可用性（1 か月あたり 43 分のエラー バジェット）でサービスを提供しようと努めてはいるものの、実際はその範囲内に常に収まらず、毎月 50～60 分のエラー バジェットを費やしているとします。これは実際、どの程度重要なことでしょうか。
サイト上での滞在時間や購入率、サポート チケットの発行数、さらには直接測定したユーザーの幸福度など、顧客満足度を測るビジネス インテリジェンスの手段はさまざまです。その統計を SLI と対比させて評価してみましょう。
エラー バジェットが超過した期間とユーザー満足度が下がった時期に関連性はありますか？ 関連性があるとしたら、その相関関数はどうなっていますか？ エラー バジェットが 50 % オーバーしたときの顧客収益が 1 % 減少しているのであれば、目標値達成に向けて可用性を高めようとエンジニアの労力をつぎ込むよりは、SLO を調整して可用性 99.5 % を確保するほうがよいと考えるかもしれません。
ここで重要なのは、SLO の目標値を決める際に使用するデータを入手し、文書化しておくことです。単に「ユーザーが気にしないから」という理由でエラー バジェットを 50 % 増やすような罠に陥ることがないようにしましょう。ユーザーの満足度/支出と、SLO の定義における信頼性との妥協点を明確にする必要があります。SLO の仕様は、単に数字や指標名があればよいというわけではありません。SLO のターゲットを決めるにあたっては、利用したロジックやデータが何なのかも示す必要があるのです。
ユーザー エクスペリエンスが明確でないケース
お客様が常に正しいというのは真実かもしれませんが、もしサービスのユーザーが社内にいる場合はどうでしょうか。一部のケースでは、常にエラー バジェットをオーバーしていても、ソフトウェアを構築しリリースを続けることが会社の利益のためになることもあるでしょう。エラー バジェットを使うことで従業員には迷惑をかけるかもしれませんが、ソフトウェアの新バージョンをリリースできないことのほうがユーザーに不便をかけることになり、企業にとっては大きなコスト増につながるかもしれないのです。
これは、ソフトウェアのユーザーが必要だと考えているもの（今回のサービスの例で言えば 99.9 % の可用性目標）と、ソフトウェア開発の予算を握っている幹部がユーザーに我慢を強いるべきだと考えているものとの間にギャップがある場合に起こる可能性があります。
以上で、エラー バジェットが何を伝えたいのかを理解できたのではないでしょうか。この記事の
パート 2
では、うまくバランスを保つ方法について考えます。
SRE（サイト信頼性エンジニアリング）についてより詳しく知りたい方は、7 月 に US サンフランシスコで開催される Next '18 にぜひご参加ください。
SRE の原則をサービスのデプロイや管理に適用する方法
について紹介します。
関連コンテンツ
優れた SLO を策定するには : CRE が現場で学んだこと
SLO 違反への対処 : CRE が現場で学んだこと
* この投稿は米国時間 6 月 28 日、Adrian Hilton、Alec Warner、および Alex Bramley によって投稿されたもの（投稿は
こちら
）の抄訳です。
- By Adrian Hilton, Alec Warner and Alex Bramley
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
