ここ何年もの間、DevOpsとクラウドの決まり文句の1つに「障害を前提に構築する」があります。その背景には、あまりにも多くの企業が、キャパシティに起因するパフォーマンス上の問題によって、多額の損失を伴うダウンタイムや収益（そして生産性）の低下を経験しているという現実があります。そこで、こうした恐ろしい事態に再び悩まされないよう、アプリケーションとインフラストラクチャを「障害を前提に」構築すべきだ、というわけです。ふふ、今の言葉遊びにお気づきですか？そう、私はオフィスで1人、リモートワークをしています。たまには自分で自分を楽しませないといけません。
下手な駄洒落はさておき、最近のPokémon Goの驚異的な成功（もちろんご存じですよね？）は、多くの人にとって、とてつもなく苛立たしい体験ももたらしました。特に、今すぐ出かけたいと大興奮する子どもを抱えた親にとっては、なおさらです。需要が殺到したため、アカウント作成が一時停止され、その後も厳しく制限されて、出かけることができなかったのです。
さて、これについては、AmazonのCTOであるWerner Vogels氏による支援の申し出が、同社のキャパシティの問題への対応を支援するものだったことから、そもそも同社は「クラウド化」しておらず、それが根本的な問題だったのではないかと指摘する向きもあるでしょう。しかし、それは同社がクラウド化していなかったという前提に立った見方であり、現時点ではその点は明確ではありません。実際、拡張現実の開発元に関するWikipediaの更新情報によると、「現実世界で人々が現実の物体や仮想オブジェクトとやり取りする中で、1日あたり2億件を超えるゲーム内アクションを処理している」とのことです。今回については、少し大目に見てもよいのではないでしょうか。少なくとも、それがシステム間のやり取りやパケット転送の観点で何を意味するかを理解している人なら、そう思えるはずです。更新情報では「サーバーの問題」とされていましたが、言うまでもなく、「サーバー」とは「アプリケーションとネットワークインフラストラクチャ全体に分散する15の異なるコンポーネント」を指す技術者の隠語です。
いずれにせよ、ここから得られる本質的な教訓は、予想外の成功への対応において、クラウドが必ずしも優れているということではありません。実際に優れている可能性は十分にありますが、それはクラウドだからではありません。クラウドは、障害の発生を前提に構築されているだけでなく、スケールできるようにも構築されているからです。
Niantic Labsが需要に対応できなかった理由について、私には判断できません。キャパシティ不足が原因だった可能性もあり、その場合はクラウドが適切な選択肢だったでしょう。一方、アプリやインフラストラクチャがスケールできるように構築されていなかった可能性もあり、その場合はクラウドがまったく役に立たなかったかもしれません。ここで言いたいのは、同社が何をしたか、あるいはしなかったかを突く（poke）ことではありません。同社の事例は、アプリケーションの世界では、組織が成功に備えて構築するのと同じくらい、障害に備えて構築する必要があるという現実を如実に示しています。しかも、徐々に訪れる成功だけでなく、Pokémon Goのように一夜にして訪れる爆発的な成功にも備える必要があります。
なぜなら、実際にそうなったとき、「成功ゆえの失敗」がインターネット中に知れ渡る事態は避けたいからです。
スケーラビリティの問題は、データソースに起因することがよくあります。Twitterを長年利用している方なら、サービス初期にデータベースのスケーラビリティに関する課題が相次いだことをご存じでしょう。PayPalは、膨大なユーザー規模に伴う課題に対処するスケーリング戦略として、いち早くシャーディングを強く提唱した企業の1つです。この手法は一般的なものとして広まり、データベースだけでなく、パフォーマンスサービスやアプリケーションにも適用されています。NoSQLデータソースの台頭に伴い、従来のリレーショナルデータベースよりも高いスケーラビリティが、そのメリットの1つとして挙げられています。
スケーラビリティの問題を引き起こすもう1つの要因は、インフラストラクチャにあります。クラウドの自動スケーリングでは、コンピューティングリソースを自動的に追加するだけでなく、「アプリのエンドポイント」のキャパシティを拡張できることが前提となります。スケーリングによってキャパシティを拡張するアーキテクチャでは、何らかの負荷分散サービスが必要です。コンピューティングリソースを追加した場合は、負荷分散サービスに登録する必要があります。そのためには、APIやスクリプト、自動化、オーケストレーションを使用します。これらのコンポーネントは、必要になる前に用意しておく必要があります。そうしなければ、需要の増加に応じてキャパシティを拡張する際に遅延が生じます。
あらゆるアプリケーションアーキテクチャに、ロードバランシングサービスを組み込むことを必須とすべきです。ロードバランシングサービスは、2つのアプリケーションインスタンス間のフェイルオーバーを本質的にサポートしているため、「障害を前提とした設計」の要件を満たすだけでなく、成功に欠かせない「スケールを前提とした設計」の要件にも対応します。ただし、アプリケーション（必要に応じてマイクロサービス）の前段にロードバランシングサービスを配置するだけでよいわけではありません。需要が発生した際に、オートスケーリングによって対応できるよう、運用担当者が自動化（スクリプト）とオーケストレーション（プロセス）を整備しておくことが重要です。現在のスケーリングで重要なのは、アルゴリズムではなくアーキテクチャです。アーキテクチャ上の負債による制約が大きくなり、既存の構成から抜け出せなくなる前に、アーキテクチャをあらかじめ検討しておくことが重要です。
率直に言って、Niantic Labsは障害を前提とした設計をうまく行っていました。処理能力を超えた際には、よく目にするデフォルトのHTTPステータスコードページではなく、親しみやすいメッセージが表示されました。ユーモアがあり、子どもにも読みやすく理解しやすい内容でした（8歳の子どもが20分おきに私たちに読み上げてくれたので、よく分かります）。一方で、おそらく予想外だった成功への備えは十分ではありませんでした。これは、障害を前提とした設計と同じくらい、スケールを前提とした設計も重要だということを、改めて思い起こさせてくれます。
そうしなければ、ロケット団の勝利です。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。