Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
自業自得の DDoS 攻撃から身を守るには : CRE が現場で学んだこと
2016年11月16日水曜日
編集部注
: アプリケーション ダウンタイムの最も一般的な要因は、チェックされないまま放置された低品質なソフトウェア アーキテクチャだとされています。そこで、Google
Site Reliability Engineering
では長年にわたり、本番環境の準備段階におけるレビューのときに、障害につながる可能性のあるコードを発見し、実運用に入る前に割り出すよう努力しています。
Customer Reliability Engineering
（CRE : 顧客信頼性エンジニアリング）という専門職を設けたことにより、内部システムに対して実施していたベスト プラクティスを、お客様が
Google Cloud Platform
上でアプリケーションを構築する際にも適用していただきたいと、私たち Google は考えているのです。今回の投稿は、CRE が実際の現場で直面した課題を浮き彫りにし、その問題を避けるために実施したことを紹介する最初の記事となります。
インターネット上での DDoS 攻撃は何も新しいことではありませんが、
最近目立った事件が発生し
、新たに世間を賑わせています。これを私たちは、「アプリケーションに対する最も大きな脅威は、誰か知らない第三者からのものではなく、自分のコードである」ということをもう一度思い出してもらうのによい機会だと考えました。
この投稿では、ソフトウェア アーキテクチャの設計が失敗し、自業自得の DDoS を引き起こす最も典型的な事例と、自身のアプリケーションでこのようなことを避けるために取るべき 3 つの方法を紹介します。
平等に分散されていたはずなのに……
その起源は Mark Twain 氏か、Will Rogers 氏か、あるいはその他の人とも言われていますが、有名なことわざがあります。それは、「自分が知らないことで傷つくことよりも、そんなはずじゃないとわかっていることで受ける傷のほうが大きい」というものです。
ソフトウェア開発者は、ユーザーのインタラクションについて単純な想定をしがちです。特にシステムの負荷に関しては、簡素化した想定をするのです。なかでも悪質な（そして時に致命的な）例の 1 つに、「世界中にたくさんのユーザーがいる。簡単にするため、全ユーザーの負荷が平等に分散されていると想定しよう」というものがあります。
確かに、これが現実に近くて便利だという結果になることが多いのも事実です。問題は、それが定常な状態や固定された想定である点で、時間が経ってもあまり変化は起こらないと仮定していることです。それが道を踏み外す第一歩となるのです。
よくあるパターンを考えてみましょう。バックエンドから定期的に情報を取り出すモバイル アプリを開発したと仮定します。
その情報は一刻を争うようなものではないため、同期の間隔を 15 分と設定します。もちろん、ネットワークが一時的に中断したときに次の情報まであと 15 分も待つことになるのを避けるため、エラーが発生した場合は 60 秒おきにリトライするようコードを書きます。
経験もあり注意深いソフトウェア開発者であれば、システムの稼働率も 99.9 % を保持していることでしょう。ほとんどのシステムはこのパフォーマンスで十分なのですが、その稼働率は 30 日間に最大 43.2 分のダウンタイムが発生する可能性があるということなのです。
さて、そのようなことが起こってしまった場合について考えてみましょう。もしシステムがほんの 1 分間ダウンしたとしたらどうでしょうか。
バックエンドがオンラインになった際、（a）その 1 分間で通常発生するはずのトラフィックに加え、（b）1 分間隔で発生するリトライのトラフィックも発生します。つまり、想定の 2 倍のトラフィックが発生することになります。
さらに、負荷はもう平等に分散されてはいません。というのも、15 分の 2 のユーザーがこの同期スケジュールに縛られているためです。つまりこの状況下では、特定の 15 分間において、通常の負荷が 13 分間発生しており、1 分間は何の負荷もかからず、残り 1 分間で 2 倍の負荷が発生していることになります。
もちろん、サービスの停止が通常 1 分で終わることはありません。もし 15 分間エラーが続いたとすると（それでも十分 99.9 % の稼働率を保っていることになります）、バックエンドが回復するまですべての負荷が重なり合うことになります。システムの故障を避けるには、最低でも通常の容量の 15 倍はプロビジョニングしておかなくてはならないということです。
リトライはよくロード バランサでスタックしてしまうことがありますし、負荷が増えるとバックエンドも各リクエストに対する反応が遅くなります。その結果、バックエンドが回復するまでトラフィックが通常の 20 倍（以上）となってしまうことも珍しくありません。最悪のケースだと、負荷が増大してサーバーのメモリやその他のリソースを使い尽くし、再度クラッシュしてしまうことも考えられます。
なんということでしょう。自分のアプリで DDoS 攻撃に遭ってしまうなんて。
ただ、すでに知られている問題の良いところは、だいたいその解決策もすでに存在するという点です。このような罠に引っかからないよう、やるべきことは次の 3 つです。
1. 指数バックオフを試してみる
リトライの間隔を固定してしまうと（今回の場合は 1 分）、ロード バランサにリトライのリクエストが重なり、バックエンドがオンラインになったときにオーバーロードしてしまうことは明らかです。こうした状況を回避する 1 つの案として、指数バックオフをお勧めします。
通常、指数バックオフとは、バックエンドに蓄積されている全体のリクエストの数を下げるために特定の制限時間までリトライの間隔を倍増させることです。今回の例では、最初の 1 分目のリトライが失敗すると 2 分間待たせることになります。それも失敗した場合は 4 分間待ちます。
このように、自分が妥当だと決めた上限まで間隔を倍増させていくのです（通常の同期間隔を 15 分としているのであれば、リトライのバックオフ時間の上限を 16 分としてみるのもよいでしょう）。
もちろん、リトライを遅らせると回復時の全体の負荷は軽くなりますが、クライアント側が同期のリトライをやめるわけではありません。この問題を解決するには、ジッターが必要です。
2. ジッターを追加してみる
ジッターとは、障害が長引いた際にクライアントが重なり合わないよう、次のリトライまでの時間に追加（または削減）するランダムな間隔です。通常は、たとえば 30 % など、固定された率にプラス / マイナスしたランダムな数字を選び、次のリトライの間隔に追加します。
今回の例だと、次のバックオフの間隔が 4 分となっているときは、その間隔にプラス / マイナス 30 % を追加して待ってみるのです。4 分の 30 % は 1.2 分なので、2.8 分から 5.2 分の間でランダムな数字を選ぶことになります。
ちなみに、Google のサービスの場合は、ジッターを使わないと影響があることがわかりました。Google が過去に構築したシステムの中に、当初はランダムにポーリングしていたクライアントが、その後短時間のサービス停止や運用悪化と同期するような動きを見せる傾向が強くなることがあったのです。
最終的に私たちは、ポーリングの間、負荷が大きく偏っていることを発見しました。ほとんどのクライアントがサービスのポーリングを同時に実施しており、負荷のピークが平均で 3 倍にも達していたのです。
以下は、そのシステムに障害が発生した際の事後分析グラフです。このケースでは、クライアントが 5 分間隔固定でポーリングしていたものの、何か月も経ってみると同期するようになっていました。
サーバーがオーバーロードし、緑色で示されたバックエンドのレイテンシが平均 2 倍になったときに、赤色のトラフィックが定期的に急上昇しているのが見て取れると思います。これこそジッターを採用すべき指標なのです。しかもこのグラフは、サンプルの時間間隔を示しているため、トラフィックのピークがかなり小さく表示されています。
その後、私たちはプラス / マイナス 1 分（20 %）というランダムな要素を各レイテンシのリトライに追加しました。その結果、以下のようにトラフィックはすぐに平準化され、周期性もなくなりました。
これでバックエンドがオーバーロードすることもなくなりました。もちろん、すぐにここまでたどり着いたわけではありません。しばらくこうしたオーバーロードをやり過ごすため、新しいコードを書き、クライアントが新しい動きをするよう配信しなくてはなりませんでした。 ここで言っておくべきことがあります。もしユーザーが均等に分散されていたとしても、実際には使用量が均等に分散されることなどほとんどないということです。
システムのスケールに関係なく、ほとんどすべてのシステムはユーザーの仕事や睡眠などの習慣に合わせてピークや谷間を迎えます。多くの人は、寝るときには電話やコンピュータの電源を落とします。つまり、みんなが朝起きてこれらの電源が入ると、トラフィックは山場を迎えるのです。
したがって、リトライに加え、通常の同期間隔に少しジッターを（10 % 程度）持たせるとよいでしょう。これは、アプリケーションが最初に同期を始める際には特に重要なことです。これにより、日常の周期的なトラフィックの山場を平準化させ、システムに負荷がかかりすぎないようにすることができます。
3. リトライに番号を付ける
バックエンドが大規模な場合は、すべてが同時に回復することはありません。システムが徐々に回復してオンラインになる際に、全体の処理能力も徐々に増していくのです。
待ち構えているクライアントをすべて同時に使えるようにしようとして、この回復作業を台無しにしないように注意してください。指数バックオフとジッターを両方採用したとしても、回復時にはリクエストに優先順位を付けるべきです。
簡単で効率的な方法として、クライアントがリトライするごとに番号を付加する方法があります。数値が 0 であれば、そのリクエストは通常の同期であり、1 であれば最初のリトライといった具合です。こうすることで、バックエンド側でどのリクエストを優先的に処理し、通常の状態に戻る過程でどのリクエストを無視すればよいかがわかるようになります。たとえばリトライの回数が多いときは、ユーザーは長時間同期できていなかったことになるため、そちらを優先させるようにすればよいのです。
また、リトライによる負荷の総容量を、たとえば 10 % というように固定の比率に設定し、通常の同期を優先させつつリトライは 10 % で実施するという方法もあります。
リトライをどう扱うかは、自社の事業ニーズに応じて決めてください。大切なのは、リトライに番号を付けることでサービス回復時に賢明な決断ができるということなのです。
リトライの回数を観察することで、順調に回復できているかどうかを把握することも可能です。もし 6 分間の停止状態から回復しようとしているときは、いちばん古いリトライの番号は 3 となっているはずです。回復が進むにつれ、番号 3 が急激に減り、次に 2 が減るといった状況になっていきます。
このようにならない場合は（もしくはリトライの番号が上がっていった場合は）、まだ問題が解決できていないことがわかります。単に全体のリトライの回数を見ているだけでは、こうした状況は把握できません。
最後にひと言
システムの負荷を管理し、エラーから順調に回復することはとても深いテーマです。今後も連鎖的な障害や負荷制限など、重要なトピックに関する記事を執筆する予定です。とりあえず、今回の記事にある手法を取り入れていただければ、1 分間ネットワークが遮断されたとしても DDoS のような惨事が発生することはないでしょう。
* この投稿は米国時間 11 月 9 日、Director of Customer Reliability Engineering である Dave Rensin と、Site Reliability Engineering の Software Engineer である Adrian Hilton によって投稿されたもの（投稿は
こちら
）の抄訳です。
- Posted by Dave Rensin, Director of Customer Reliability Engineering, and Adrian Hilton, Software Engineer, Site Reliability Engineering
0 件のコメント :
コメントを投稿
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
0 件のコメント :
コメントを投稿