大規模なサーバー障害にも対応可能な、レジリエントなインフラを構築するには
生活に必要な多くのツールが電力に頼っていますよね。ひとたび停電になれば全てが止まり、途方に暮れてしまいます。
全く同じことが、クラウドプロバイダーとクラウドを利用するオンラインサービス、ウェブサイト、モバイルアプリ、ゲームなどにも言えます。2012 年 12 月には、停電が原因でアマゾン・ウェブ・サービス（AWS）のサーバーが全地域でダウンする事故が発生し、その影響は衝撃をもたらしました。
しかし、Wix もある程度 Amazon のサービスを利用しているにも関わらず、Wix のユーザーや Wix で作られたウェブサイトの訪問者はこの世界的事件にほとんど気づくことはありませんでした。
この記事では、私たちがどのようにレジリアンスと柔軟性を核としたシステムを構築し、数千キロも離れたサーバー間でリソースとデータを移動させることができるのか、その手法を具体的に説明します。
地理的な分布
Wix はユーザーファーストを徹底しています。私たちプロダクション・エンジニアは「問題は起こるもの」というスタンスを大前提とし、できる限り事前に問題を防ぐことに心血を注いでいます。
私たちのユーザーが構築しているサイトが常に正常に機能し、「ユーザーのユーザーが安心して利用できる」ように、念には念を入れて仕事をしています。すなわち、もしインフラパートナーに障害が発生し、地理的にオフラインになったとしたら、私たちも問題が解決するまで対応するという事です。
したがって、万が一 Wix のサービスを動かしているインフラに問題が発生したときにも、ユーザーに影響が及ばないように適切な緩和策を講じるように構築しています。私たちのアプローチで特にユニークな点は、既存の枠組みにとらわれずに、クラウドプロバイダーが提供するハイ・アベラビリティ(HA)*を利用している事です、あまり普通のことではありません。私たちは、同じ区域のハイ・アベラビリティゾーンに集中するのではなく、複数の地理的拠点を通してハイ・アベラビリティを実現しています。
*ハイ・アベラビリティ(HA)とは高可用性のこと。システムが利用可能である状態を指し、システムの障害の発生しにくさや、障害発生から復旧までの時間などによって計測されます
ハイ・アベラビリティゾーンで提供されているすべてのサービスを活用することをはじめとし、それ以上の対策をおこなっています。共有インフラにはゾーン全体をダウンさせる可能性があるため、完全には頼れないのです。そこで、サーバーを地理的に分散しつつ、ハイ・アベラビリティを実現するために、何千キロも離れたさまざまな場所（アメリカ東海岸、ヨーロッパ、アジア）にあるすべてのハイ・アベラビリティゾーンを利用し、全体で15カ所、そのすべてを常に活用しています。
すべての拠点で、受信するトラフィックの量に応じて規模を調整し、サービスを提供しています。つまり、1つの非常に大きな拠点から全体にサービスを提供するのではなく、15の「小さな」拠点に分散させているわけです。平均をとると、元のサイズのおよそ6.6％になります。
そして何らかの理由で1つの拠点が潰れたとしても、残りの14拠点がその負荷をすべて引き受けることができるのです。通常は最も近い2-3拠点に分散させます。このように分散させる一方で、経済的に効率よく処理するために、私たちはいくつかのアルゴリズムを構築し、適切に機能するように常にモニタリングしています。
費用対効果の面でも、平常時はすべての拠点が常にトラフィックにサービスを提供しており、待機しているわけではないので、無駄はありません。
危機回避の手法
すべての根底にあるのは「モニタリング」です。私たちは、ユーザーのユーザーが安心して利用できるように、すべての拠点を積極的に監視し、稼働ししている最後のサービスに至るまで、すべて監視しています。このように広い視野を持つことにより、各拠点の状態を深く理解することができます。そのため、もし必要とあればいつでも、どの拠点が、どの時点で、トラフィックを提供するのに十分なパフォーマンスを提供しているかすぐに調べることができます。障害が拠点全体を襲うのを待つのではなく、障害の兆候を確認したらすぐに、実際に先手を打つことを徹底しているのです。
ここで、先ほどの Amazon の障害についてお話します。私たちは障害の少し前に、DynamoDB に関連する小規模なサービスにおいて、いくつかの問題が発生し始めたことを確認しました。簡単に言うと、複数のサービスが「調子が悪い」とシステムに伝達し、状況が「不安定」になったということです。当時、Amazon 側では誰も問題を認識できておらず、何も報告していませんでした。それでも私たちは、その拠点から「引っ越す」判断に十分な情報を得たので、US-EAST へのユーザートラフィックを停止させました。その後、プロバイダに障害が発生したのですが、Wix ユーザーは影響を受けることなく、何事もなかったかのようでした。
システムの舞台裏
リソースを別の拠点に移し、ユーザーを危険にさらすことなく、冷静に状況を調査できるシステムを、どのように構築しているのでしょうか。簡単に説明すると以下の通りです。
スタック全体を常に監視し、技術スタック全体の中からどこに問題があるかを把握。
異なる拠点からのトラフィックに対応可能。（DNS プロバイダーを使って、さまざまなデータセンター間でトラフィックを移動させることが可能）
需要の急激な変化に対応するため、リソースを自動的かつ迅速に拡張できるよう構築。
ある区域で受けとったリクエストが、別の区域で受け取ったリクエストの続きであることを理解できるデータレイヤーを所有していること。
上記に加えて、我々のインフラ全体が地理的に分散しているので、リクエストが何であるか、どのように入ってくるか、そして異なる区域を移動するときにどのように処理する必要があるかを常に意識しています。
つまり、あるユーザーのウェブサイトでチェックアウトの取引が発生したとき、その取引の背後には、ある拠点にある一連のサーバーで取引が始まり、別の拠点で継続するときに、シームレスかつ継続的に点をつなぐことができる耐障害性インフラが必要なのです。もちろん、物理的に何千キロも離れた拠点に分散させるという話です。
瞬時に「移動」できるようにするためには、私たちのシステム全体が、その変化に対応しながら、どのように拡大させるのか知っている必要があります。そのため、サーバーの自動最適化(オートスケール)で運用しているのです。さらに、季節的なスパイク変動があるときに切替が行われても大丈夫なように、常にリソースのバッファを確保しています。
この設計により、私たちは以下のことを実現しています。
地理的に単一の地域に留まらない
すべての拠点間のリクエストをシームレスに追跡する
各拠点が必要な時に必要なだけオートスケールすることを可能にしている
システム全体を移行するのではなく、小さな部分ごとに移動する
以上のことから、どのような事象に対しても非常に迅速に対応することができ、信頼できるシステムを提供できるようになりました。この自信こそが、私たちが「リアクティブ・プロダクション」と呼ぶシステムのバックボーンになったのです。
前にも述べたように、「問題は起こるもの」です。「リアクティブ・プロダクション」システムは、重大な問題が顕在化する前に、必要な時に必要なものを移動することができます。要するに、クラウド事業者のインフラの潜在的な問題をキャッチし、リアクティブ・プロダクションシステムが人間よりも速く行動し、任意の瞬間、瞬時にトラフィックを自動的に再分配するため、安心して利用できるのです。
私たちはこの 2 年半、万全を期すためにこのシステムのテストを続けてきました。そして、2021 年の AWS 障害の際には、Amazon 側が障害の詳細に気づく前に、素早く、自動的に機能したのです。
サマリー
プロダクション・エンジニアでは「問題は起こるもの」を大前提として、できる限り事前に障害を防ぐように努力しなければなりません。
これは、すべての Wix サービスを動かしているインフラを、レジリエンスと柔軟性を考慮して構築することを意味します。つまり、私たちは、同じ区域のハイ・アベラビリティゾーンに集中するのではなく、複数の地理的拠点を通してハイ・アベラビリティを実現することが重要なのです。
私たちのアプローチが有効であることは、Amazon がホストするサーバーの East-1 地域全体が停止したときに、私たち、そして、すべてのクライアントがオンラインを維持したことで証明されたと言えるでしょう 。
ライター： Wix Team
