ポケモンGOのローンチリマインダー「スケールに合わせて構築」が「失敗に合わせて構築」と同じくらい重要な理由

過去何年にもわたる DevOps とクラウドのキャッチフレーズの 1 つは、「失敗するために構築する」でした。 その前提は、容量関連のパフォーマンスの問題により、コストのかかるダウンタイムや収益（および生産性）の損失を経験する企業が多すぎるため、そのような恐ろしい出来事が再びあなたを悩ませないように、アプリとインフラストラクチャを「失敗することを前提に」構築する必要があるということです。 へっ。 私が何をしたのか分かりますか？ はい、私はオフィスで一人でリモートワークをしています。 時々、自分を楽しませる必要がある。

悪い駄洒落はさておき、ポケモンGOの最近の驚異的な成功（聞いたことありますよね？）は、多くの人にとって驚異的にイライラする経験ももたらしました。 特に、今すぐ行きたくてたまらなかったが、アカウント作成が一時的に停止され、需要が殺到したために厳しく制限されたために行けなかった、興奮した子供を持つ親たち。

さて、アマゾンのCTOであるヴェルナー・フォーゲルス氏が、同社の容量問題への対処を支援すると申し出たことは、そもそも「クラウド化」していなかったこと、それが根本的な問題だったことを示唆していると指摘する人もいるかもしれないが、それは実際にクラウド化していなかったと仮定した場合の話であり、現時点では私にはよく分からない。 実際、拡張現実開発者に関するウィキペディアの最新情報によると、この開発者は「人々が物理世界で現実および仮想のオブジェクトと対話する中で、1日あたり2億回以上のゲームアクション」を処理しているそうです。 これについては、彼らに少しの猶予を与えることができると思います。少なくとも、システムの相互作用とパケットのプッシュに関してそれが何を意味するかを理解している私たちはそうすることができます。 アップデートでは「サーバーの問題」が指摘されていますが、「サーバー」が「アプリとネットワーク インフラストラクチャ全体に広がる 15 種類のコンポーネント」を表す技術コードであることは誰もが知っています。

いずれにせよ、ここでの根本的な教訓は、クラウドが必ずしも予期せぬ成功に対処するのに優れているということではありません。 確かにそうかもしれませんが、それはクラウドだからではありません。 それは、クラウドが障害に備えて構築されているだけでなく、拡張できるようにも構築されているからです。

Niantic Labs が需要に応えられなかった理由を私が判断できる立場にはありません。 おそらく容量不足だったのでしょう。その場合、クラウドは良い選択でしょう。また、アプリやインフラストラクチャが拡張できるように構築されていなかったのかもしれません。その場合、クラウドはまったく役に立たなかったかもしれません。 肝心なのは、彼らが何をしたか、何をしなかったかについて、彼らを突っつく（笑）ことではありません。 重要なのは、アプリケーションの世界では、組織は成功のための構築と同様に失敗のための構築にも配慮する必要があるという現実を、これらは完璧な例であるということです。 そして、徐々に成功するだけではなく、ポケモンGOのように瞬時に、一夜にして成功するのです。

なぜなら、もしそのようなことが起こった場合、その成功の失敗がインターネット中に広まるのは望ましくないからです。

スケーラビリティの問題の一般的な原因はデータ ソースにあります。 ベテランの Twitter ユーザーなら、ソーシャル メディアの初期の頃はデータベースのスケーラビリティの課題に悩まされていたことを覚えているでしょう。 PayPal は、膨大なユーザー数という課題に対処するためのスケーリング戦略としてシャーディングを最も早くから積極的に推進した企業の 1 つであり、この手法は、データベース、パフォーマンス サービス、アプリケーションなどに適用できる一般的な手法として採用されています。 NoSQL データ ソースの台頭により、従来のリレーショナル データベースよりも優れたスケーラビリティが利点の 1 つとして挙げられます。

スケーラビリティの問題のもう一つの原因は、インフラストラクチャにのみあります。 クラウドでの自動スケーリングは、コンピューティングを自動的に追加するだけでなく、「アプリ エンドポイント」の容量を増やす機能に依存します。 規模に依存して容量の増加を実現するアーキテクチャでは、何らかの負荷分散サービスが必要になります。 コンピューティングを増加した場合は、負荷分散サービスに登録する必要があります。 これは、API とスクリプト、自動化、オーケストレーションの使用を意味します。 これらのコンポーネントは、必要になる前に設置しておく必要があります。そうしないと、需要によって容量の増加が必要になった場合に遅延が発生します。

あらゆるアプリ アーキテクチャに負荷分散サービスを組み込むことが必須となります。 負荷分散サービスは、2 つのアプリケーション インスタンス間のフェイルオーバーを本質的にサポートしているため、「失敗を前提とした構築」のニーズに対応するだけでなく、成功に必要な「拡張を前提とした構築」のニーズもサポートします。 しかし、これは単にアプリ (またはマイクロサービス) の前に負荷分散サービスを配置するだけと考えないでください。 運用担当者は、需要が発生したときに自動スケーリングが対応できるように、自動化 (スクリプト) とオーケストレーション (プロセス) を導入することが重要です。 今日のスケーリングはアルゴリズムではなくアーキテクチャに関するものであり、アーキテクチャ上の負債によって制限が厳しくなり、現状のままでは行き詰まってしまう前に、事前にアーキテクチャを考慮することが重要です。

正直に言うと、Niantic Labs は失敗を想定して良い仕事をしました。 容量障害が発生した場合、よく表示されるデフォルトの HTTP ステータス コード ページではなく、わかりやすいメッセージが表示されました。 ユーモアがあって、子供でも読みやすく、理解しやすい本でした（私の8歳の子供が20分ごとに読んでくれたので、その通りです）。  彼らが予想していなかったのは、彼らが遭遇したおそらく予想外の成功だった。 これは、スケールさせるために構築することは、失敗するために構築することと同じくらい重要であるということを、すべての人にとって思い出させる良いことです。   

そうしないとロケット団が勝ってしまうからです。