編集部注 : アプリケーション ダウンタイムの最も一般的な要因は、チェックされないまま放置された低品質なソフトウェア アーキテクチャだとされています。そこで、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