モバイルやデスクトップ画面で作り出したのかがわかります。これらをはじめ、さまざまな興味深い疑問の答えが見つかります。クラウドに移行しました。最新動向を伝えるこのブログをお読みいただき、感謝いたします。年もさらなる活動を展開していきます。お試しになっていない方は、ぜひ無料試用をお申し込みください。よって投稿されたもの(投稿はこちら)の抄訳です。現場で学んだこと2016年12月27日火曜日この程度なら起こってもかまわないと思えるような問題だからといって、それが問題でないというわけではありません。サイト信頼性エンジニアリング)チームが優雅に(トラフィックを)処理する手法を学びます。Platform(GCP)に適用した例について紹介します。攻撃を回避する方法について説明しました。今回は、ある意味誰もが望むような問題、つまり成功によって失敗が引き起こされたときにどう対処するべきかをお話ししましょう。ソフトウェアの失敗で一番厄介なのは「成功による障害」です。持続的に処理できる以上のトラフィックが、思いがけずアプリケーションに対して常に発生している状態がそうです。これを見たユーザーは、こんなシステムを使う価値はないと考え始め、最終的に別のシステムに移行するかもしれません。これが最悪な失敗かというと、それが起こるとは誰も考えていないからです。これは完全に回避できる問題です。シェディング(負荷制限)を採用していれば、こんな嫌な思いをすることはないのです。シェディングとは、可用性を担保するため、どれだけトラフィックがシステムに送られていたとしても、システムはあくまで公称の処理能力を提供するという手法です。シェディングを適用するにあたっては、一部のリクエストを無視し、クライアントにリトライさせる必要があります。シェディングギリシャ神話で、ポセイドンの息子プロクルステスが、捕らえた旅人の身長を寝台のサイズに無理やり合わせようとした話をご存じでしょうか。シェディングもそのようなものです。キューの長さといった簡単に取得できる数値を測定し、負荷テストで立証された負荷の数値が事前に決めた「安全」レベルを超えると、一部トラフィックの流入を制限し、負荷を安全レベルに戻すのです。始まるリクエストをシステムがはじくといった具合です。それでもシステムの負荷が高いままであれば排除するリクエスト数を増やし、負荷が安全レベルに戻ると排除するリクエスト数を減らします。1このシステムにさまざまな負荷を与えると、以下のような動きをします。ここで示したシステムは、一定の時間が経過するとリクエストが無効となり、さまざまなコストが発生します。リクエスト)の場合、システムは制限内で順調に稼働します。シェディングが始まります。リミット内に収まります。一般に、拒否されるリクエストのほうが、無効となるリクエストよりも多くなります。リソースを消費するため、そのほうが私たちにとっても都合がよいのです。通常レベルに戻ると、それ以上リクエストが拒否されたり無効になったりすることはありません。シェディングが再稼働しますが、その頻度は低いでしょう。それは、すべてのリクエストやクライアントを平等に扱うという点です。これまでの経験上、すべてのリクエストやクライアントが平等であることなどめったにありません。実際に購入している人からのものだとすると、後者のリクエストを優先したいですよね。シェディングを実施しても、後者のリクエストを優先できないのです。幸いにも別の方法があります。重要度とコストでリクエストをランク付けする(リクエストをはじいたり接続を拒否したりするような)あまり重要でない作業に時間を費やす前に、まずは各リクエストの重要度を相対的にランク付けする必要があります。リクエストのコストを把握するのです。つのコストが存在します。よって決まります(たまにネットワークのリソースが少ないこともありますが、ほとんどが特殊なケースです)。機会に対するコストは少し計算が難しくなります。何かをしないことのコストをどうやって計算すればよいのでしょうか。金額で示そうとするのは単純すぎます。売上と利益は同じではないからです。自社のビジネスにとって、どちらか一方が極めて重要である可能性が高いのです。つのルールについてお話しします。少ないリソースをベースにコストを数値化しましょう。ベースにすべてのコストを示すのです。少ないリソースが売上や利益だとすれば、その数値を使いましょう。開発時間をベースにコストを算出することがあります。お金よりも開発時間のほうが足りないと感じているためです。リクエストの種類をランク付けする前に、どの単位を基準にしてランク付けを行うのか、メンバー全員の意見を一致させておきましょう。社内の部門が異なれば、トラフィックを制限するコストへの視点も異なります。広告部門はコンテンツが表示されないことで失う売上金額を重視するでしょうし、マーケティング部門はアプリケーションに同時アクセスできる総ユーザー数を重視しているかもしれません。反応が遅いとユーザーがイライラすることから、レイテンシが最も重要だと考えているかもしれないのです。した見解の違いは、最初にランク付けの単位を決めることで解決します。削減する作業コストの試算方法が決まれば、どのリクエストをはじくのかをランク付けしていきます。重要度を決めるということです。重要なトラフィックは、あまり重要でないトラフィックよりも優先順位が高くなります。それでも微妙な差異は出てきます。システムは、機会に対するコストの総計を最小限に抑えようとしますし、他のシステムは機会に対するコストと直接的なコストを関係づけようとします(これは、重み付けされたコスト、または見積もりコストとも言われます)。ランタイムの特定クエリに対する直接的なコストや機会に対するコストを把握することは、ほぼ不可能だと言ってよいでしょう。把握できたとしても、各リクエストに対してインラインで計算する際にかかるコンピュータのオーバーヘッドにより、サービス容量が大幅に低下するおそれがあります。そんなことをするよりも、把握できているリクエストの種類に応じて、重要度別にバケットやクラスを設定してみましょう。これにより、各リクエストをより簡単にバケットへと分類し、優先順位のランク付けができるようになります(ネットワークに詳しい人は、これがサービス品質(QoS)システムの重要な要素であることに気づくでしょう)。シェディングを最大限に活用するには、設定した基準をベースにシステムがリクエストの重要度をできるだけ早く、そしてできるだけ安価に決定しなくてはなりません。重要度を決める一般的な方法をいくつか挙げてみます。使って優先順位の低いトラフィックをブラックホール化し、犠牲となるサーバーへと向かわせることができます。驚かれるかもしれませんが、こうすることで、過負荷状態のサービスにリクエストが到達できなくなるため、命拾いにもなるのです。サービス側で多少余分な処理が必要となります。下)か、といった具合です。これにより、最も正確なバケット化が可能ですが、リクエストごとに確認することになり、多くのコストがかかります。(たとえばバックグラウンドで写真をアップロードするなどの)バッチ処理を「重要度が低くリトライ可能」と分類することがよくあります。時間遅れたりしたとしてもユーザーは気にしないと判断しているからです。このような場合、システムはリクエストを簡単にはじき、クライアントに対して後ほどアップロードを再試行するよう指示することもできます。再試行の間隔が長ければ、再試行による総ボリュームも低く抑えられ、システムへの負荷が回避されしだい、クライアントはアップロードを再開できます。これまで、ある不良クライアントが他の優良クライアントと同じホストネームを使っていることが原因で、何度も苦い経験をしてきました。優良クライアントに影響を与えることなく不良クライアントをブロックできなかったのです。サービスが、種類の異なるさまざまなクライアントに対してサービスを提供している状況にあり、全タイプのクライアントが独自のホストネームでサービスにアクセスしています。そのため、私たちは素行の悪いクライアントのトラフィックを隔離し、空き容量のある遠方のサーバーへと転送できるようになりました。タイプへの影響はなくなります。他にも、不良クライアントのトラフィックが過負荷の傾向にあることを見越して、こうしたトラフィックをできる限り処理するようサーバーのサブセットを指定し、他のクライアントからのトラフィックをこのホストに近づけないようにする方法もあります。最終手段として、不良トラフィックを単純にブラックホールに入れてしまうこともあります。重要度は時とともに変化する機会に対するコストは決まった道を進むことがほとんどなく、いま重要なことが今後も重要であるとは限りません。時間の経過とともに、重要度に応じて決められたバケット間をリクエストが移動することもあります。ページの読み込みを例に考えてみましょう。ページを読み込むというリクエストは非常に重要です。秒以上を要したりすると、ユーザーは遅いページに見切りをつけ、どこか別のページに行ってしまうからです。ページを読み込むリクエストが最重要バケットに入ることになります。秒に達すると、最も重要度の低いバケットに入れるほうがよいかもしれません(もしくは、リクエストをすべてキャンセルするという選択肢もあります)。いうのも、ユーザーはどこか別のページに行ってしまい、すでに存在しない可能性があるためです。データやデザインによって決まるレスポンスの期限をオーバーしたリクエストなのです。この期限をうまく調整すればするほど、安価な運用が可能となります。万だと想定してみましょう。この上限をクォータ(割当量)と呼びます。万以下だった場合は、当然のことながら余剰能力が発生するという問題が生じます。マシンの助けでもない限り)決して取り戻せないため、何としてもこうした事態は避けなければなりません。社内では重要な原則に従い、作業の節約を行っています。システムの処理能力に空きがある場合、クォータを超えたクライアントを抑制してはならないことになっているのです。クォータと位置づけています。システムが余分な負荷に対応できる場合、クォータによって制限する必要はないためです。クォータは、どんな状況でも制限を決して超えてはならないというものです。クォータは限りあるリソースを「公平に」管理するためのものです。その公平さはビジネスの内容によって定義づけられるべきです。重要なことを考えなくてはなりません。システムが処理能力を使い果たしたときは、最もクォータをオーバーしているクライアントが最初に調整対象となります。抑制するのはフェアではありません。楽観的な抑制と悲観的な抑制どのトラフィックを抑制するかが決まったら、どのように抑制するかも決めなくてはなりません。ここでは基本的に楽観的な抑制と悲観的な抑制のどちらかを選ぶことになります。楽観的な抑制とは、グローバルに処理能力が上限に達するまでトラフィックを制限しない方法です。シェディングがリクエストに対して稼働し始めます。重要度の最も低いリクエストがまず対象となり、問題なく稼働するようになるまで作業を控えて貯めておきます。この方法の良いところは、簡単に実行できることと、グローバルでの上限に近づくまで何もしないため、比較的安価なことです。このような楽観的な抑制には欠点があります。シェディングを開始する際にグローバルでの上限を超えてしまうことです。ほとんどのユーザーはこの瞬間的な過負荷状態によって若干レイテンシが高くなったように感じるだけなので、この方法は多くのシステムでお勧めできます。楽観的な抑制を実施するときは、ロジックを完璧にテストしておくことが非常に重要です。シェディングが中断してしまう危険性があるためです。シェディングが稼働し、サーバーがセグメンテーション違反を起こすまでそのことに数週間気づかないこともあります(私たちがそんな目に遭ってしまったわけではないのですが)。悲観的な抑制では、どんな状況下でも一瞬たりともグローバルの上限を超えないと想定します。これは、コンピューティングの視点から見れば、よりコストのかかる方法です。負荷管理システムが継続的にクォータやさまざまな制限値を計測(および再計測)し、システム内の至るところに送信する必要があるからです。この手法では、グローバルの処理能力に達することはほぼありません。万が一達したとしても、超えた分の計算負荷は他で使われているはずの能力を使用することになります。したことから、悲観的な抑制を実施し維持するのは、より困難でコストもかさみます。抑制の分析システムがトラフィックの一部を抑制し始めたとすると、それは何を意味すると思いますか?単純に考えると、修復が必要な何らかの問題があり、それを解決する最も簡単な方法はシステムに処理能力を追加することです。サーバーを増設したり、すでにあるサーバーにリソースを追加したりすることです。多く消費したとしても、追加分の能力を日々のピーク時に数分だけ利用するのであれば、リソースを有効活用しているとは言えません。売上といった観点から抑制の効果を考えてみてください。実際のユーザーは、抑制によるエラーやサービス低下を感じているでしょうか。ユーザーのうち、どれだけの人がその影響を受けているのでしょうか。そこで抑制されたことによるコストと、リクエストに応じるためにコンピュータのリソースを追加した場合のコストを比較してみましたか?インタラクティブでないリトライ可能なリクエストのみをシステムが抑制しているのであれば、そのシステムは目的どおり稼働していると考えてよいでしょう。レベル目標値内に完了しているのであれば、より迅速なサービスを目指して追加投資するといった必要はありません。時間も抑制されているようなサービスの場合は、処理能力について検討する時期が来ているのかもしれません。リクエストはバケットに分類されるため、抑制による影響を分析することは比較的簡単です。ツールがあれば、各バケットのリクエストにおいてどの部分が抑制されているかまで把握できるようになります。クライアントに対するサービスを提供したことがあります。デバイスにキャッシュするというものでした。か所同時に利用できなくなることも想定した作りになっていました。大量のインタラクティブな(ユーザーと直接やり取りする)トラフィックも処理していました。シェディングの対象候補とみなし、「リクエスト優先順位」というフィールドに従って、「重要なユーザーとのやり取り」から「重要でないバックグラウンド処理」(バックグラウンドでのアップロード)に至るまでリクエストをマーク付けして稼働させました。事前に決められた能力の上限に達すると、リクエストが自動的に優先順位の低いものから順番に抑制されるように設定したのです。日後に問題が発生しました。新たなアプリがリリースされ、それがクライアントにプッシュ配信されたことが不幸な影響をもたらし、どのデータがアップロード済みなのかという記録がリセットされてしまったのです。このバグにより、すべてのクライアントが全データを再アップロードしようとサービスに同時接続しました。以下のグラフは、アップロードが失敗した率を示しています。担当者がこんなグラフを見せられたら、さぞかしぞっとすることでしょう。システムはトラフィックを正常に処理し続けました。リクエストが約半分に削減された一方で、残りのクライアントも辛抱強く待機して後ほどリトライしたため、システムが過負荷状態に陥らずに済んだのです。示す青い線が一瞬跳ね上がっているのは、新たなリソースを設置した際に抑制処理を停止したことによるものです)。シェディングにより、取り消すことのできないコードのバグに対する多重防御が実現したのです。最後に誰だって、野心的な夢さえも上回るような人気の高いシステムを手がけてみたいと考えるものです。実際には「(人気が高いことに起因する)問題を一度は抱えてみたいものだ」と言って、自分の考えを打ち消すことがよくあります。私たちの経験から言えることは、抱えてみたい問題というのは、実際抱えてみると抱えたいものではないということです。それは、単なる問題に過ぎません。非常に痛みを伴う問題なのです。重要な要件は信頼性です。自分が手がけたアプリケーションがとてつもない人気者になることを喜ばない人はいないでしょう。シェディングは、その成功を念頭に置いて設計する安価な方法です。シェディングを構築すれば、こうだったかもしれないのにと考えて苦しむこともなくなります。関連の投稿はこれが最後になります。シーズンをお過ごしください。多くのコメントや意見をいただき、ありがとうございました。来年またお会いしましょう。それまでクエリが順調に流れ、ページャで呼び出されることがありませんように......。よって投稿されたもの(投稿はこちら)の抄訳です。この程度なら起こってもかまわないと思えるような問題だからといって、それが問題でないというわけではありません。サイト信頼性エンジニアリング)チームが優雅に(トラフィックを)処理する手法を学びます。Platform(GCP)に適用した例について紹介します。攻撃を回避する方法について説明しました。今回は、ある意味誰もが望むような問題、つまり成功によって失敗が引き起こされたときにどう対処するべきかをお話ししましょう。ソフトウェアの失敗で一番厄介なのは「成功による障害」です。持続的に処理できる以上のトラフィックが、思いがけずアプリケーションに対して常に発生している状態がそうです。これを見たユーザーは、こんなシステムを使う価値はないと考え始め、最終的に別のシステムに移行するかもしれません。これが最悪な失敗かというと、それが起こるとは誰も考えていないからです。これは完全に回避できる問題です。シェディング(負荷制限)を採用していれば、こんな嫌な思いをすることはないのです。シェディングとは、可用性を担保するため、どれだけトラフィックがシステムに送られていたとしても、システムはあくまで公称の処理能力を提供するという手法です。シェディングを適用するにあたっては、一部のリクエストを無視し、クライアントにリトライさせる必要があります。シェディングギリシャ神話で、ポセイドンの息子プロクルステスが、捕らえた旅人の身長を寝台のサイズに無理やり合わせようとした話をご存じでしょうか。シェディングもそのようなものです。キューの長さといった簡単に取得できる数値を測定し、負荷テストで立証された負荷の数値が事前に決めた「安全」レベルを超えると、一部トラフィックの流入を制限し、負荷を安全レベルに戻すのです。始まるリクエストをシステムがはじくといった具合です。それでもシステムの負荷が高いままであれば排除するリクエスト数を増やし、負荷が安全レベルに戻ると排除するリクエスト数を減らします。1このシステムにさまざまな負荷を与えると、以下のような動きをします。ここで示したシステムは、一定の時間が経過するとリクエストが無効となり、さまざまなコストが発生します。リクエスト)の場合、システムは制限内で順調に稼働します。シェディングが始まります。リミット内に収まります。一般に、拒否されるリクエストのほうが、無効となるリクエストよりも多くなります。リソースを消費するため、そのほうが私たちにとっても都合がよいのです。通常レベルに戻ると、それ以上リクエストが拒否されたり無効になったりすることはありません。シェディングが再稼働しますが、その頻度は低いでしょう。それは、すべてのリクエストやクライアントを平等に扱うという点です。これまでの経験上、すべてのリクエストやクライアントが平等であることなどめったにありません。実際に購入している人からのものだとすると、後者のリクエストを優先したいですよね。シェディングを実施しても、後者のリクエストを優先できないのです。幸いにも別の方法があります。重要度とコストでリクエストをランク付けする(リクエストをはじいたり接続を拒否したりするような)あまり重要でない作業に時間を費やす前に、まずは各リクエストの重要度を相対的にランク付けする必要があります。リクエストのコストを把握するのです。つのコストが存在します。よって決まります(たまにネットワークのリソースが少ないこともありますが、ほとんどが特殊なケースです)。機会に対するコストは少し計算が難しくなります。何かをしないことのコストをどうやって計算すればよいのでしょうか。金額で示そうとするのは単純すぎます。売上と利益は同じではないからです。自社のビジネスにとって、どちらか一方が極めて重要である可能性が高いのです。つのルールについてお話しします。少ないリソースをベースにコストを数値化しましょう。ベースにすべてのコストを示すのです。少ないリソースが売上や利益だとすれば、その数値を使いましょう。開発時間をベースにコストを算出することがあります。お金よりも開発時間のほうが足りないと感じているためです。リクエストの種類をランク付けする前に、どの単位を基準にしてランク付けを行うのか、メンバー全員の意見を一致させておきましょう。社内の部門が異なれば、トラフィックを制限するコストへの視点も異なります。広告部門はコンテンツが表示されないことで失う売上金額を重視するでしょうし、マーケティング部門はアプリケーションに同時アクセスできる総ユーザー数を重視しているかもしれません。反応が遅いとユーザーがイライラすることから、レイテンシが最も重要だと考えているかもしれないのです。した見解の違いは、最初にランク付けの単位を決めることで解決します。削減する作業コストの試算方法が決まれば、どのリクエストをはじくのかをランク付けしていきます。重要度を決めるということです。重要なトラフィックは、あまり重要でないトラフィックよりも優先順位が高くなります。それでも微妙な差異は出てきます。システムは、機会に対するコストの総計を最小限に抑えようとしますし、他のシステムは機会に対するコストと直接的なコストを関係づけようとします(これは、重み付けされたコスト、または見積もりコストとも言われます)。ランタイムの特定クエリに対する直接的なコストや機会に対するコストを把握することは、ほぼ不可能だと言ってよいでしょう。把握できたとしても、各リクエストに対してインラインで計算する際にかかるコンピュータのオーバーヘッドにより、サービス容量が大幅に低下するおそれがあります。そんなことをするよりも、把握できているリクエストの種類に応じて、重要度別にバケットやクラスを設定してみましょう。これにより、各リクエストをより簡単にバケットへと分類し、優先順位のランク付けができるようになります(ネットワークに詳しい人は、これがサービス品質(QoS)システムの重要な要素であることに気づくでしょう)。シェディングを最大限に活用するには、設定した基準をベースにシステムがリクエストの重要度をできるだけ早く、そしてできるだけ安価に決定しなくてはなりません。重要度を決める一般的な方法をいくつか挙げてみます。使って優先順位の低いトラフィックをブラックホール化し、犠牲となるサーバーへと向かわせることができます。驚かれるかもしれませんが、こうすることで、過負荷状態のサービスにリクエストが到達できなくなるため、命拾いにもなるのです。サービス側で多少余分な処理が必要となります。下)か、といった具合です。これにより、最も正確なバケット化が可能ですが、リクエストごとに確認することになり、多くのコストがかかります。(たとえばバックグラウンドで写真をアップロードするなどの)バッチ処理を「重要度が低くリトライ可能」と分類することがよくあります。時間遅れたりしたとしてもユーザーは気にしないと判断しているからです。このような場合、システムはリクエストを簡単にはじき、クライアントに対して後ほどアップロードを再試行するよう指示することもできます。再試行の間隔が長ければ、再試行による総ボリュームも低く抑えられ、システムへの負荷が回避されしだい、クライアントはアップロードを再開できます。これまで、ある不良クライアントが他の優良クライアントと同じホストネームを使っていることが原因で、何度も苦い経験をしてきました。優良クライアントに影響を与えることなく不良クライアントをブロックできなかったのです。サービスが、種類の異なるさまざまなクライアントに対してサービスを提供している状況にあり、全タイプのクライアントが独自のホストネームでサービスにアクセスしています。そのため、私たちは素行の悪いクライアントのトラフィックを隔離し、空き容量のある遠方のサーバーへと転送できるようになりました。タイプへの影響はなくなります。他にも、不良クライアントのトラフィックが過負荷の傾向にあることを見越して、こうしたトラフィックをできる限り処理するようサーバーのサブセットを指定し、他のクライアントからのトラフィックをこのホストに近づけないようにする方法もあります。最終手段として、不良トラフィックを単純にブラックホールに入れてしまうこともあります。重要度は時とともに変化する機会に対するコストは決まった道を進むことがほとんどなく、いま重要なことが今後も重要であるとは限りません。時間の経過とともに、重要度に応じて決められたバケット間をリクエストが移動することもあります。ページの読み込みを例に考えてみましょう。ページを読み込むというリクエストは非常に重要です。秒以上を要したりすると、ユーザーは遅いページに見切りをつけ、どこか別のページに行ってしまうからです。ページを読み込むリクエストが最重要バケットに入ることになります。秒に達すると、最も重要度の低いバケットに入れるほうがよいかもしれません(もしくは、リクエストをすべてキャンセルするという選択肢もあります)。いうのも、ユーザーはどこか別のページに行ってしまい、すでに存在しない可能性があるためです。データやデザインによって決まるレスポンスの期限をオーバーしたリクエストなのです。この期限をうまく調整すればするほど、安価な運用が可能となります。万だと想定してみましょう。この上限をクォータ(割当量)と呼びます。万以下だった場合は、当然のことながら余剰能力が発生するという問題が生じます。マシンの助けでもない限り)決して取り戻せないため、何としてもこうした事態は避けなければなりません。社内では重要な原則に従い、作業の節約を行っています。システムの処理能力に空きがある場合、クォータを超えたクライアントを抑制してはならないことになっているのです。クォータと位置づけています。システムが余分な負荷に対応できる場合、クォータによって制限する必要はないためです。クォータは、どんな状況でも制限を決して超えてはならないというものです。クォータは限りあるリソースを「公平に」管理するためのものです。その公平さはビジネスの内容によって定義づけられるべきです。重要なことを考えなくてはなりません。システムが処理能力を使い果たしたときは、最もクォータをオーバーしているクライアントが最初に調整対象となります。抑制するのはフェアではありません。楽観的な抑制と悲観的な抑制どのトラフィックを抑制するかが決まったら、どのように抑制するかも決めなくてはなりません。ここでは基本的に楽観的な抑制と悲観的な抑制のどちらかを選ぶことになります。楽観的な抑制とは、グローバルに処理能力が上限に達するまでトラフィックを制限しない方法です。シェディングがリクエストに対して稼働し始めます。重要度の最も低いリクエストがまず対象となり、問題なく稼働するようになるまで作業を控えて貯めておきます。この方法の良いところは、簡単に実行できることと、グローバルでの上限に近づくまで何もしないため、比較的安価なことです。このような楽観的な抑制には欠点があります。シェディングを開始する際にグローバルでの上限を超えてしまうことです。ほとんどのユーザーはこの瞬間的な過負荷状態によって若干レイテンシが高くなったように感じるだけなので、この方法は多くのシステムでお勧めできます。楽観的な抑制を実施するときは、ロジックを完璧にテストしておくことが非常に重要です。シェディングが中断してしまう危険性があるためです。シェディングが稼働し、サーバーがセグメンテーション違反を起こすまでそのことに数週間気づかないこともあります(私たちがそんな目に遭ってしまったわけではないのですが)。悲観的な抑制では、どんな状況下でも一瞬たりともグローバルの上限を超えないと想定します。これは、コンピューティングの視点から見れば、よりコストのかかる方法です。負荷管理システムが継続的にクォータやさまざまな制限値を計測(および再計測)し、システム内の至るところに送信する必要があるからです。この手法では、グローバルの処理能力に達することはほぼありません。万が一達したとしても、超えた分の計算負荷は他で使われているはずの能力を使用することになります。したことから、悲観的な抑制を実施し維持するのは、より困難でコストもかさみます。抑制の分析システムがトラフィックの一部を抑制し始めたとすると、それは何を意味すると思いますか?単純に考えると、修復が必要な何らかの問題があり、それを解決する最も簡単な方法はシステムに処理能力を追加することです。サーバーを増設したり、すでにあるサーバーにリソースを追加したりすることです。多く消費したとしても、追加分の能力を日々のピーク時に数分だけ利用するのであれば、リソースを有効活用しているとは言えません。売上といった観点から抑制の効果を考えてみてください。実際のユーザーは、抑制によるエラーやサービス低下を感じているでしょうか。ユーザーのうち、どれだけの人がその影響を受けているのでしょうか。そこで抑制されたことによるコストと、リクエストに応じるためにコンピュータのリソースを追加した場合のコストを比較してみましたか?インタラクティブでないリトライ可能なリクエストのみをシステムが抑制しているのであれば、そのシステムは目的どおり稼働していると考えてよいでしょう。レベル目標値内に完了しているのであれば、より迅速なサービスを目指して追加投資するといった必要はありません。時間も抑制されているようなサービスの場合は、処理能力について検討する時期が来ているのかもしれません。リクエストはバケットに分類されるため、抑制による影響を分析することは比較的簡単です。ツールがあれば、各バケットのリクエストにおいてどの部分が抑制されているかまで把握できるようになります。クライアントに対するサービスを提供したことがあります。デバイスにキャッシュするというものでした。か所同時に利用できなくなることも想定した作りになっていました。大量のインタラクティブな(ユーザーと直接やり取りする)トラフィックも処理していました。シェディングの対象候補とみなし、「リクエスト優先順位」というフィールドに従って、「重要なユーザーとのやり取り」から「重要でないバックグラウンド処理」(バックグラウンドでのアップロード)に至るまでリクエストをマーク付けして稼働させました。事前に決められた能力の上限に達すると、リクエストが自動的に優先順位の低いものから順番に抑制されるように設定したのです。日後に問題が発生しました。新たなアプリがリリースされ、それがクライアントにプッシュ配信されたことが不幸な影響をもたらし、どのデータがアップロード済みなのかという記録がリセットされてしまったのです。このバグにより、すべてのクライアントが全データを再アップロードしようとサービスに同時接続しました。以下のグラフは、アップロードが失敗した率を示しています。担当者がこんなグラフを見せられたら、さぞかしぞっとすることでしょう。システムはトラフィックを正常に処理し続けました。リクエストが約半分に削減された一方で、残りのクライアントも辛抱強く待機して後ほどリトライしたため、システムが過負荷状態に陥らずに済んだのです。示す青い線が一瞬跳ね上がっているのは、新たなリソースを設置した際に抑制処理を停止したことによるものです)。シェディングにより、取り消すことのできないコードのバグに対する多重防御が実現したのです。最後に誰だって、野心的な夢さえも上回るような人気の高いシステムを手がけてみたいと考えるものです。実際には「(人気が高いことに起因する)問題を一度は抱えてみたいものだ」と言って、自分の考えを打ち消すことがよくあります。私たちの経験から言えることは、抱えてみたい問題というのは、実際抱えてみると抱えたいものではないということです。それは、単なる問題に過ぎません。非常に痛みを伴う問題なのです。重要な要件は信頼性です。自分が手がけたアプリケーションがとてつもない人気者になることを喜ばない人はいないでしょう。シェディングは、その成功を念頭に置いて設計する安価な方法です。シェディングを構築すれば、こうだったかもしれないのにと考えて苦しむこともなくなります。関連の投稿はこれが最後になります。シーズンをお過ごしください。多くのコメントや意見をいただき、ありがとうございました。来年またお会いしましょう。それまでクエリが順調に流れ、ページャで呼び出されることがありませんように......。よって投稿されたもの(投稿はこちら)の抄訳です。アイコンとアーキテクチャ図サンプルを公開2016年12月27日火曜日(GCP)のアイコンとアーキテクチャ図サンプルをダウンロードできるようにしました。ペーパーやデータシート、プレゼンテーション、その他の技術コンテンツにおいて、複雑なクラウド設計を表現できます。クラウドやマルチクラウドの構成についても正確に表現できます。プロダクト、図の要素、サービスなどを表します。Iconsこれらのファイルは新しいプロダクトのリリースに合わせて更新されますので、後ほどチェックしてみてください。以上のサンプル図のごく一部を以下に紹介します。個々の図を一から作成する必要はもうありません。よって投稿されたもの(投稿はこちら)の抄訳です。Platform技術は図解することで理解が深まります。Platform(GCP)のアイコンとアーキテクチャ図サンプルをダウンロードできるようにしました。ペーパーやデータシート、プレゼンテーション、その他の技術コンテンツにおいて、複雑なクラウド設計を表現できます。クラウドやマルチクラウドの構成についても正確に表現できます。プロダクト、図の要素、サービスなどを表します。Iconsこれらのファイルは新しいプロダクトのリリースに合わせて更新されますので、後ほどチェックしてみてください。以上のサンプル図のごく一部を以下に紹介します。個々の図を一から作成する必要はもうありません。よって投稿されたもの(投稿はこちら)の抄訳です。エクスペリエンスを簡素化します。最新リリースにおけるハイライトは以下のとおりです。プロジェクトの中でも最速のペースで進んでおり、コミュニティの活動に関しても最も活発な部類に入ります。加速度的な利用にも表れています。サービスを利用することで、インフラストラクチャを維持することよりも、顧客に価値を提供することに力を注げます。以下では、お客様の最新事例を紹介します。使用して、新しい電子商取引アプリケーション機能の顧客への継続的デリバリをサポートしています。いった小売企業が含まれています。コンテナの管理やオーケストレーションを行ううえで必要としているオープン性、安定性、スケーラビリティを提供してくれます。フライデー(米国における感謝祭翌日の金曜日。マンデー(感謝祭翌週の月曜日。ショッピングが盛況)の間にサービスの停止やダウンタイム、中断はまったく発生しませんでした。コストを削減しました。管理せずに済むようになりました。コミュニティにご参加ください。試してみることはとても簡単です。クラスタをワンクリックで作成できるのです。こちらから無料試用をお申し込みください。よって投稿されたもの(投稿はこちら)の抄訳です。エクスペリエンスを簡素化します。最新リリースにおけるハイライトは以下のとおりです。プロジェクトの中でも最速のペースで進んでおり、コミュニティの活動に関しても最も活発な部類に入ります。加速度的な利用にも表れています。サービスを利用することで、インフラストラクチャを維持することよりも、顧客に価値を提供することに力を注げます。以下では、お客様の最新事例を紹介します。使用して、新しい電子商取引アプリケーション機能の顧客への継続的デリバリをサポートしています。いった小売企業が含まれています。コンテナの管理やオーケストレーションを行ううえで必要としているオープン性、安定性、スケーラビリティを提供してくれます。フライデー(米国における感謝祭翌日の金曜日。マンデー(感謝祭翌週の月曜日。ショッピングが盛況)の間にサービスの停止やダウンタイム、中断はまったく発生しませんでした。コストを削減しました。管理せずに済むようになりました。コミュニティにご参加ください。試してみることはとても簡単です。クラスタをワンクリックで作成できるのです。こちらから無料試用をお申し込みください。よって投稿されたもの(投稿はこちら)の抄訳です。サービスの構築2016年12月22日木曜日もっとも、アプリケーション自体も進化しており、高度な分散と複数の層で構成されます。その多くはマイクロサービスとして提供されています。バランサに関するこうした状況が背景にあります。インスタンスのためのスケーラブルで可用性の高い内部サービスの構築を可能にします。カンファレンスの場で詳しく説明してきました。HTTP(S)負荷分散を使用しています。サービスが必要とする拡張性、パフォーマンス、可用性を提供しています。バランサはどこ?」という質問をよく受けます。秒間にサポートできる接続数は?」と聞かれます。ベースのソリューションでもありません。バランサは仮想ネットワーク上で必要な場所であればどこにでも存在しますが、ネットワークを停滞させるポイントとなることは決してありません。したアーキテクチャのおかげで、内部負荷分散ではサービスが必要とする接続数を最大限までサポートできるのです。秒間に多くの接続数をサポートできます。トラフィックを分散できます。インスタンス(10.240.0.2)に負荷分散されます。内部負荷分散により、次のことが可能になります。地域内の複数のゾーンにあるインスタンスにまたがる形で負荷分散できます。アフィニティを設定できます。チェックを設定できます。インスタンスを瞬時にスケーリングできます。フルマネージド負荷分散サービスの利点をすべて享受できます。バランサがサービス停止の原因となることを心配する必要はありません。設定の詳細はこちらをクリックしてください。負荷分散を実現します。ここでは、同サービスの興味深い事例を紹介します。アーキテクチャの場合、デプロイした複数のインスタンスにまたがる形でトラフィックを分散させることで、各サービスに可用性と拡張性を提供します。内部負荷分散を使えばこれが実現できるほか、インスタンスを自動スケーリングしてサービスへのトラフィック増加にも対応できます。内部負荷分散は多層アプリケーションを構築するうえで重要なコンポーネントとなります。HTTP(S)負荷分散をデプロイすることが可能です。バランサの背後にデプロイし、そこにウェブ層のインスタンスからリクエストを送ることができます。ビート通信を行い、ステート情報をやり取りすることによって実現していました。ベースの仮想アプライアンスでは機能しません。いうのも、物理ハードウェアにアクセスできないからです。ベースの高可用性を享受することはできません。アプリケーションが堅牢性などを高めるために共有状態をアプリケーションの外部に保管することです。そのため、従来のセッション同期状態を取り除くことができます。インスタンスを導入することです。チェックを実行したうえで、正常なインスタンス間でトラフィックを分散し、トラフィックに基づいてインスタンスの数を増減します。近いうちに、いくつかの機能が内部負荷分散に追加される予定です。グループのサポートなどです。内部負荷分散を試してみてください。上でデプロイするのです。皆さんからのフィードバックをお待ちしています。よって投稿されたもの(投稿はこちら)の抄訳です。バランサは、復元性と弾力性の高いサービスを構築するうえで重要な要素です。バランサにより、インフラストラクチャについてさほど考慮せずに、アプリケーションにもっと集中できるようになります。アプリケーション自体も進化しており、高度な分散と複数の層で構成されます。その多くはマイクロサービスとして提供されています。バランサに関するこうした状況が背景にあります。インスタンスのためのスケーラブルで可用性の高い内部サービスの構築を可能にします。カンファレンスの場で詳しく説明してきました。HTTP(S)負荷分散を使用しています。サービスが必要とする拡張性、パフォーマンス、可用性を提供しています。バランサはどこ?」という質問をよく受けます。秒間にサポートできる接続数は?」と聞かれます。ベースのソリューションでもありません。バランサは仮想ネットワーク上で必要な場所であればどこにでも存在しますが、ネットワークを停滞させるポイントとなることは決してありません。したアーキテクチャのおかげで、内部負荷分散ではサービスが必要とする接続数を最大限までサポートできるのです。秒間に多くの接続数をサポートできます。トラフィックを分散できます。インスタンス(10.240.0.2)に負荷分散されます。内部負荷分散により、次のことが可能になります。地域内の複数のゾーンにあるインスタンスにまたがる形で負荷分散できます。アフィニティを設定できます。チェックを設定できます。インスタンスを瞬時にスケーリングできます。フルマネージド負荷分散サービスの利点をすべて享受できます。バランサがサービス停止の原因となることを心配する必要はありません。設定の詳細はこちらをクリックしてください。負荷分散を実現します。ここでは、同サービスの興味深い事例を紹介します。アーキテクチャの場合、デプロイした複数のインスタンスにまたがる形でトラフィックを分散させることで、各サービスに可用性と拡張性を提供します。内部負荷分散を使えばこれが実現できるほか、インスタンスを自動スケーリングしてサービスへのトラフィック増加にも対応できます。内部負荷分散は多層アプリケーションを構築するうえで重要なコンポーネントとなります。HTTP(S)負荷分散をデプロイすることが可能です。バランサの背後にデプロイし、そこにウェブ層のインスタンスからリクエストを送ることができます。ビート通信を行い、ステート情報をやり取りすることによって実現していました。ベースの仮想アプライアンスでは機能しません。いうのも、物理ハードウェアにアクセスできないからです。ベースの高可用性を享受することはできません。アプリケーションが堅牢性などを高めるために共有状態をアプリケーションの外部に保管することです。そのため、従来のセッション同期状態を取り除くことができます。インスタンスを導入することです。チェックを実行したうえで、正常なインスタンス間でトラフィックを分散し、トラフィックに基づいてインスタンスの数を増減します。近いうちに、いくつかの機能が内部負荷分散に追加される予定です。グループのサポートなどです。内部負荷分散を試してみてください。上でデプロイするのです。皆さんからのフィードバックをお待ちしています。よって投稿されたもの(投稿はこちら)の抄訳です。メンバーとして加盟2016年12月20日火曜日(GCP)の目標は、開発者にとっても企業にとっても最もオープンなクラウドを構築し、素晴らしいソフトウェアを簡単に開発、運用できるようにすることです。コミュニティの活発なメンバーとなり、勤務先が新興企業か大企業かを問わず、さまざまな分野の開発者と直接協力することです。メンバーとして加盟しました。コミュニティとの協力を通じて多くの成果を達成しました。した取り組みはツールの開発や統合にもつながっています。ブローカが挙げられます。API私たちは以前から、こうしたプロジェクトにお客様やパートナーと協力して取り組んできました。加わることはシンプルな決断でした。その活気あふれるコミュニティは多くの企業に広がっており、さまざまなチーム間で行われている技術的なコラボレーションは見事なものです。エコシステム全体とのつながりや協力を一層深めることができます。Foundation、そして両者のコミュニティの間で、さらなる統合やイノベーションが進むことを楽しみにしています。よって投稿されたもの(投稿はこちら)の抄訳です。Platform(GCP)の目標は、開発者にとっても企業にとっても最もオープンなクラウドを構築し、素晴らしいソフトウェアを簡単に開発、運用できるようにすることです。コミュニティの活発なメンバーとなり、勤務先が新興企業か大企業かを問わず、さまざまな分野の開発者と直接協力することです。メンバーとして加盟しました。コミュニティとの協力を通じて多くの成果を達成しました。した取り組みはツールの開発や統合にもつながっています。ブローカが挙げられます。API私たちは以前から、こうしたプロジェクトにお客様やパートナーと協力して取り組んできました。加わることはシンプルな決断でした。その活気あふれるコミュニティは多くの企業に広がっており、さまざまなチーム間で行われている技術的なコラボレーションは見事なものです。エコシステム全体とのつながりや協力を一層深めることができます。Foundation、そして両者のコミュニティの間で、さらなる統合やイノベーションが進むことを楽しみにしています。よって投稿されたもの(投稿はこちら)の抄訳です。