Bitrix24: 「すぐに上がったものは下がったとはみなされない」

現在、Bitrix24 サービスには数百ギガビットのトラフィックはなく、膨大な数のサーバーが存在するわけでもありません (もちろん、既存のサーバーはかなりの数ありますが)。 しかし、多くのクライアントにとって、これは社内で仕事をするための主要なツールであり、真のビジネスクリティカルなアプリケーションです。 したがって、落ちることはありません。 実際にクラッシュが発生したものの、サービスはすぐに「回復」したため、誰も何も気づかなかった場合はどうなるでしょうか? また、作業の品質とクライアントの数を失わずにフェイルオーバーを実装するにはどうすればよいでしょうか? Bitrix24 のクラウド サービス ディレクターである Alexander Demidov 氏が、予約システムが製品の誕生から 7 年間でどのように進化したかについてブログで語りました。

「私たちは 24 年前に Bitrix7 を SaaS として立ち上げました。 主な問題はおそらく次のような点でした。この製品は、SaaS として一般に公開される前は、単にボックス化されたソリューションの形式で存在していました。 クライアントは当社からそれを購入し、自社のサーバーでホストし、企業ポータルをセットアップしました。これは、従業員のコミュニケーション、ファイル ストレージ、タスク管理、CRM のための一般的なソリューションです。それだけです。 そして 2012 年までに、これを SaaS として立ち上げ、自社で管理し、フォールト トレランスと信頼性を確保したいと決定しました。 私たちはその過程で経験を積みました。なぜなら、それまで私たちには経験がなかったからです。私たちは単なるソフトウェア メーカーであり、サービス プロバイダーではありませんでした。

サービスを開始するとき、最も重要なことはサービスの耐障害性、信頼性、および継続的な可用性を確保することであると私たちは理解しました。なぜなら、単純で普通の Web サイトや店舗がある場合、それはあなたの手元に落ちてきて、そこにずっと座っているからです。 XNUMX時間では、あなただけが苦しみ、注文を失い、顧客を失いますが、顧客自身にとって、これはそれほど重要ではありません。 もちろん彼は動揺しましたが、別のサイトでそれを購入しました。 そして、これが社内のすべての作業、コミュニケーション、意思決定に結びつくアプリケーションである場合、最も重要なことはユーザーの信頼を獲得すること、つまりユーザーを失望させたり、失敗したりしないことです。 内部の何かが機能しない場合、すべての作業が停止する可能性があるためです。

SaaS としての Bitrix.24

私たちは、一般発売の 2011 年前の XNUMX 年に最初のプロトタイプを組み立てました。 XNUMX週間ほどで組み立てて、眺めたり回してみたりしましたが、実際に動作することもありました。 つまり、フォームに移動してポータルの名前を入力すると、新しいポータルが開き、ユーザー ベースが作成されます。 私たちはそれを見て、原則として製品を評価し、廃棄し、XNUMX 年間改良を続けました。 それは、私たちには大きなタスクがあったからです。XNUMX つの異なるコード ベースを作成したくなかったし、別個のパッケージ製品や別個のクラウド ソリューションをサポートしたくなかったので、すべてを XNUMX つのコード内で実行したかったからです。

当時の典型的な Web アプリケーションは、いくつかの PHP コードが実行され、mysql データベースが実行され、ファイルがアップロードされ、ドキュメントや写真がアップロード フォルダーに置かれる XNUMX つのサーバーでした。すべてが機能しました。 残念ながら、これを使用して非常に安定した Web サービスを起動することは不可能です。 そこでは、分散キャッシュはサポートされず、データベースのレプリケーションもサポートされません。

私たちは要件を策定しました。これは、異なる場所に配置でき、レプリケーションをサポートし、理想的には地理的に分散した異なるデータ センターに配置できる機能です。 製品ロジックと実際にはデータ ストレージを分離します。 負荷に応じて動的にスケーリングでき、静的な影響を完全に許容します。 実際、これらの検討から製品の要件が明らかになり、私たちはそれを XNUMX 年間かけて洗練させました。 この間、ボックス化されたソリューションや独自のサービスなど、統合されたプラットフォームで、必要なもののサポートを作成しました。 製品自体のレベルでの mysql レプリケーションのサポート。つまり、コードを作成する開発者は、リクエストがどのように分散されるかについて考えず、API を使用します。また、マスター間で書き込みおよび読み取りリクエストを正しく分散する方法を知っています。そして奴隷たち。

Google ストレージ、Amazon S3 などのさまざまなクラウド オブジェクト ストレージを製品レベルでサポートし、さらにオープン スタック Swift もサポートしています。 したがって、これはサービスとしての私たちにとっても、パッケージ化されたソリューションを扱う開発者にとっても便利でした。仕事で私たちの API を使用するだけであれば、ファイルが最終的にどこに保存されるか、ファイル システム上でローカルに保存されるか、またはファイル システム上でローカルに保存されるかについては考えません。オブジェクト ファイル ストレージにあります。

その結果、データセンター全体のレベルで予約することを即座に決定しました。 2012 年に、私たちは完全に Amazon AWS 上で立ち上げました。なぜなら、私たちはすでにこのプラットフォームの経験があり、私たち自身の Web サイトが Amazon AWS でホストされていたからです。 私たちは、Amazon が各地域に複数のアベイラビリティーゾーンを持っているという事実に惹かれました。実際、(彼らの用語では) 複数のデータセンターが多かれ少なかれ互いに独立しており、データセンター全体のレベルで予約することができます。突然障害が発生した場合は、データベースがマスター間で複製され、Web アプリケーション サーバーがバックアップされ、静的データが s3 オブジェクト ストレージに移動されます。 負荷はバランスされています - 当時は Amazon elb によって行われていましたが、少し後に、より複雑なロジックが必要になったため、独自のロードバランサーを使用するようになりました。

彼らが望んでいたものは彼らが手に入れたものです...

サーバー自体、Web アプリケーション、データベースのフォールト トレランスなど、私たちが確保したい基本的なものはすべてうまく機能しました。 最も単純なシナリオ: Web アプリケーションの XNUMX つが失敗した場合、すべては単純です。それらはバランス調整からオフになります。

バランサー (当時は Amazon の Elb でした) は、故障したマシンを異常としてマークし、それらのマシンへの負荷分散をオフにしました。 Amazon の自動スケーリングは機能しました。負荷が増大すると、新しいマシンが自動スケーリング グループに追加され、負荷が新しいマシンに分散されました。すべて問題ありませんでした。 バランサーの場合も、ロジックはほぼ同じです。アプリケーション サーバーに何かが発生した場合、アプリケーション サーバーからリクエストを削除し、これらのマシンを破棄し、新しいマシンを起動して作業を継続します。 このスキームは何年にもわたって少し変更されましたが、今も機能し続けています。シンプルで理解しやすく、難しいことはありません。

私たちは世界中で仕事をしており、顧客の負荷のピークはまったく異なります。また、友好的な方法で、顧客に気づかれることなく、いつでもシステムのコンポーネントに対して特定のサービス作業を実行できる必要があります。 したがって、データベースの運用を停止して、負荷を XNUMX 番目のデータ センターに再分散することができます。

すべてはどのように機能するのでしょうか? — トラフィックを稼働中のデータセンターに切り替えます。データセンターで事故が発生した場合、これが XNUMX つのデータベースで計画されている作業である場合は、これらのクライアントにサービスを提供するトラフィックの一部を XNUMX 番目のデータセンターに切り替え、一時停止します。それの複製です。 XNUMX 番目のデータ センターの負荷が増加したために Web アプリケーションに新しいマシンが必要になった場合、それらのマシンは自動的に起動します。 作業が完了し、レプリケーションが復元され、負荷全体が元に戻ります。 XNUMX 番目の DC で一部の作業をミラーリングする必要がある場合 (たとえば、システム アップデートをインストールしたり、XNUMX 番目のデータベースの設定を変更したりする)、通常は同じことを逆方向に繰り返します。 これが事故の場合は、すべてを簡単に実行します。監視システムのイベント ハンドラー メカニズムを使用します。 いくつかのチェックがトリガーされ、ステータスがクリティカルになった場合は、このハンドラー、つまり特定のロジックを実行できるハンドラーを実行します。 データベースごとに、どのサーバーがそのデータベースのフェイルオーバーであるか、およびデータベースが使用できない場合にトラフィックをどこで切り替える必要があるかを指定します。 歴史的に、私たちは nagios またはそのフォークの一部を何らかの形で使用しています。 原則として、同様のメカニズムがほぼすべての監視システムに存在しており、これより複雑なものはまだ使用していませんが、おそらくいつか使用するようになるでしょう。 現在、監視は利用不能になった場合にトリガーされ、何かを切り替える機能を備えています。

すべて予約しましたか？

私たちには、米国からの多くの顧客、ヨーロッパからの多くの顧客、日本、シンガポールなどの東日本に近い多くの顧客がいます。 もちろん、クライアントの大部分はロシアにあります。 つまり、仕事は 53 つの地域に集中しているわけではありません。 ユーザーは迅速な対応を求めており、さまざまな現地法を遵守する必要があります。また、各リージョン内に 53 つのデータ センターを予約しており、さらに追加のサービスもいくつかあります。これもまた、次の地域にいるクライアントのために 53 つのリージョン内に配置すると便利です。この地域は機能しています。 REST ハンドラー、認可サーバー、これらはクライアント全体の動作にとってそれほど重要ではありません。許容できるわずかな遅延でそれらを切り替えることができますが、それらを監視する方法や実行する内容について一から考え直す必要はありません。彼らと一緒に。 したがって、追加の製品で何らかの能力を開発するのではなく、既存のソリューションを最大限に活用しようとしています。 そして、どこかでDNSレベルでスイッチングを簡単に使用し、同じDNSによってサービスの活性度を判断します。 Amazon には Route XNUMX サービスがありますが、これは単なる DNS にエントリを作成して終わりというわけではなく、はるかに柔軟で便利です。 これにより、地理位置情報を使用して地理分散サービスを構築できます。これを使用してクライアントの出身地を特定し、特定の記録を提供することで、フェールオーバー アーキテクチャを構築できます。 Route XNUMX 自体でも同じヘルスチェックが設定されており、監視対象のエンドポイントを設定し、メトリクスを設定し、サービスの「稼働状態」を判断するプロトコル (tcp、http、https) を設定します。 サービスが生きているかどうかを判断するチェックの頻度を設定します。 そして、DNS 自体で、何をプライマリにするか、何をセカンダリにするか、ルート XNUMX 内でヘルスチェックがトリガーされた場合にどこに切り替えるかを指定します。これはすべて他のツールで実行できますが、なぜこれが便利なのかを設定します。一度起動したら、どのようにチェックを行うか、どのように切り替えるかについてはまったく考えません。すべてが自動的に機能します。

最初の「でも」: ルート 53 そのものを予約するにはどうすればよいですか? 彼に何かが起こったらどうなるか誰にも分かりません。 幸いなことに、私たちはこの熊手を踏むことはありませんでしたが、なぜ予約が必要だと考えたのかについては、また改めてお話しします。 ここでは事前に自分たち用のストローを敷いておきました。 53 日に数回、ルート XNUMX 内のすべてのゾーンの完全な荷降ろしを行います。 Amazon の API を使用すると、JSON で簡単に送信できます。また、いくつかのバックアップ サーバーがあり、それを変換して構成の形式でアップロードし、大まかに言ってバックアップ構成を作成します。 何かが発生した場合は、DNS 設定データを失うことなく、手動ですぐに展開できます。

XNUMX番目の「でも」: この写真の中でまだ予約されていないものは何ですか? バランサーそのもの！ 地域ごとのクライアントの分布は非常にシンプルになっています。 bitrix24.ru、bitrix24.com、.de のドメインがあり、現在 13 の異なるドメインがあり、さまざまなゾーンで運用されています。 各リージョンには独自のバランサーがあるということが分かりました。 これにより、ネットワーク上のピーク負荷がどこにあるかに応じて、リージョン間で分散することがより便利になります。 これが単一バランサーのレベルでの障害である場合、そのバランサーは単にサービスを停止され、DNS から削除されます。 バランサーのグループに問題がある場合、バランサーは他のサイトにバックアップされ、TTL が短いため、切り替えは最大 53、2、3 分以内に行われるため、同じルートを使用してバランサー間の切り替えが行われます5。 。

XNUMXつ目の「でも」：まだ予約されていないものは何ですか？ S3、そうです。 ユーザーのために保存するファイルを s3 に配置したとき、私たちはそれが鎧を貫通するものであり、そこに何も予約する必要はないと心から信じていました。 しかし、歴史は事態が異なることを示しています。 一般に、Amazon は S3 を基本的なサービスであると説明しています。Amazon 自体が S3 を使用してマシンイメージ、構成、AMI イメージ、スナップショットを保存しているためです... そして、この 3 年間に一度だけ発生したように、S7 がクラッシュしたとしても、これは私たちが使い続けている限りです。 bitrix24 はファンのようにフォローしています。仮想マシンを起動できない、API の障害など、さまざまな問題が発生します。

そして、S3 が落ちる可能性があります - それは一度起こりました。 したがって、私たちは次の計画にたどり着きました。数年前、ロシアには本格的な公共オブジェクト保管施設がありませんでした。そこで、私たちは独自の何かを行うという選択肢を検討しました...幸いなことに、私たちはこれを始めませんでした。私たちが持っていない専門知識を掘り下げたので、おそらく台無しになるでしょう。 現在、Mail.ru には s3 互換のストレージがあり、Yandex にもそれがあり、他の多くのプロバイダーにもそれがあります。 最終的には、第一にバックアップ、第二にローカル コピーを操作できる機能が必要であるという考えに至りました。 特にロシア地域では、s3 と互換性のある API である Mail.ru Hotbox サービスを使用します。 アプリケーション内のコードに大きな変更を加える必要はなく、次のメカニズムを作成しました。s3 にはオブジェクトの作成/削除をトリガーするトリガーがあり、Amazon には Lambda と呼ばれるサービスがあります。これはサーバーレスでコードを起動します。特定のトリガーがトリガーされたときに実行されます。

実行したのは非常に簡単です。トリガーが起動すると、オブジェクトを Mail.ru ストレージにコピーするコードを実行します。 データのローカル コピーを使用した作業を完全に開始するには、ロシア セグメントのクライアントが、より近いストレージを使用して作業できるように、逆同期も必要です。 Mail はストレージ内でトリガーを完了しようとしています。インフラストラクチャ レベルで逆同期を実行できるようになりますが、今のところ、これを独自のコード レベルで実行しています。 クライアントがファイルを投稿したことを確認した場合、コード レベルでイベントをキューに入れ、処理し、逆レプリケーションを実行します。 それがなぜ悪いのか: 製品の外部でオブジェクトに対して何らかの作業を行う場合、つまり何らかの外部手段を使用する場合、それは考慮されません。 したがって、ストレージ レベルでトリガーが表示されるまで待機し、コードをどこから実行しても、受け取ったオブジェクトが反対方向にコピーされるようにします。

コード レベルでは、クライアントごとに両方のストレージを登録します。3 つはメイン ストレージ、もう XNUMX つはバックアップ ストレージと見なされます。 すべてが順調であれば、私たちはより近いストレージを使用します。つまり、Amazon にあるクライアントは SXNUMX を使用し、ロシアにあるクライアントは Hotbox を使用します。 フラグがトリガーされた場合は、フェイルオーバーが接続される必要があり、クライアントを別のストレージに切り替えます。 このボックスは地域ごとに個別にチェックでき、前後に切り替えることができます。 これはまだ実際に使用していませんが、このメカニズムは用意されているので、いつかこのスイッチが必要になり、便利になると思います。 これはすでに一度起こっています。

ああ、アマゾンは逃げた…

今年の XNUMX 月は、ロシアでテレグラムのブロッキングが始まった記念日にあたります。 これに該当する最も大きな影響を受けたプロバイダーは Amazon です。 そして残念なことに、全世界のために働いていたロシア企業はさらに苦しんだ。

企業がグローバルであり、ロシアがその企業にとって 3 ～ 5% という非常に小さなセグメントである場合、いずれにせよ、彼らを犠牲にすることができます。

これが純粋なロシアの会社であれば、地元にある必要があると確信していますが、それはユーザー自身にとって単に便利で快適であり、リスクも少ないでしょう。

これが世界的に事業を展開し、ロシアと世界各地にほぼ同数の顧客を抱えている会社だったらどうなるでしょうか? セグメントの接続性は重要であり、何らかの形で相互に連携する必要があります。

2018 年 3 月末、Roskomnadzor は最大手事業者に書簡を送り、Zello メッセンジャーをブロックするために数百万の Amazon IP をブロックする計画であると述べました。 これらの同じプロバイダーのおかげで、彼らは手紙を全員に漏らすことに成功し、Amazon との関係が崩壊する可能性があるという理解がありました。 その日は金曜日で、私たちは慌ててservers.ruの同僚に向かってこう言いました。「皆さん、ロシアでもアマゾンでもなく、たとえばアムステルダムのどこかに設置するサーバーがいくつか必要です」同じ sXNUMX のエンドポイントなど、まったく影響を及ぼせない一部のエンドポイントに対して、少なくとも何らかの方法で独自の VPN とプロキシをインストールできるようにするため、新しいサービスを立ち上げて別の IP を取得することはできません。私たちはまだそこに到達する必要があります。 わずか数日で、これらのサーバーをセットアップし、稼働させ、一般的にはブロッキングが始まる瞬間に備えることができました。 不思議なのは、この大騒ぎとパニックを見てRKNが「いいえ、今は何もブロックしません」と言ったのです。 (ただし、これはまさに、Telegram がブロックされ始めた瞬間までの話です。) バイパス機能を設定し、ブロックが導入されていないことに気づいたにもかかわらず、問題全体を解決し始めたわけではありません。 はい、念のため。

そして2019年の現在も、私たちは依然として遮断された状況にあります。 昨夜調べてみると、約 20 万の IP が引き続きブロックされています。 確かに、Amazon はほぼ完全にブロックされておらず、ピーク時には 2 万アドレスに達していました。一般に、現実には一貫性や良好な一貫性は存在しない可能性があります。 突然。 火災や掘削機などの技術的な理由で存在しない可能性があります。 あるいは、これまで見てきたように、完全に技術的なものではありません。 したがって、独自の AS を持つ大規模な企業は、おそらく別の方法でこれを管理できるでしょう。直接接続などはすでに L3 レベルにあります。 しかし、私たちのような単純なバージョン、またはそれよりも小さいバージョンでは、万が一に備えて、別の場所にあるサーバーのレベルで冗長性を確保し、事前に vpn やプロキシを構成し、それらのセグメントでそれらの構成にすばやく切り替えることができます。接続にとって重要なものです。 これは、Amazon のブロックが始まったときに何度も役に立ちました。最悪の場合、SXNUMX トラフィックの通過のみを許可しましたが、徐々にすべてが解決されました。

プロバイダー全体を予約するにはどうすればよいですか?

現時点では、アマゾン全体がダウンした場合のシナリオはありません。 ロシアについても同様のシナリオがあります。 ロシアでは、XNUMX つのプロバイダーによってホストされ、そのプロバイダーから複数のサイトを選択しました。 そして XNUMX 年前、私たちは問題に直面しました。これらは XNUMX つのデータセンターであるにもかかわらず、プロバイダーのネットワーク構成レベルですでに問題が発生しており、引き続き両方のデータセンターに影響を与える可能性があります。 そして、両方のサイトで利用できなくなる可能性があります。 もちろん、それが起こったのです。 私たちは最終的に内部のアーキテクチャを再検討することになりました。 あまり変わっていませんが、ロシアの場合は XNUMX つのサイトがあり、それらは同じプロバイダーからのものではなく、XNUMX つの異なるプロバイダーからのものです。 どちらかが失敗した場合は、もう一方に切り替えることができます。

仮に、Amazon については、別のプロバイダーのレベルでの予約の可能性を検討しています。 もしかしたらGoogleかもしれないし、他の誰かかもしれない... しかし、これまで実際に観察してきたところによると、AmazonではXNUMXつのアベイラビリティーゾーンのレベルで事故が発生しているものの、地域全体のレベルでの事故は非常にまれです。 したがって、理論的には「Amazon は Amazon ではない」予約を行う可能性があるという考えがありますが、実際にはまだそうなっていません。

自動化について一言

自動化は常に必要ですか? ここでダニング・クルーガー効果を思い出すのが適切です。 「x」軸は私たちが得た知識と経験を表し、「y」軸は私たちの行動に対する自信を表します。 最初は何も知らず、まったく自信がありません。 その後、私たちは少しだけ知識を得て、非常に自信を持つようになります。これはいわゆる「愚かさの頂点」であり、「認知症と勇気」という絵がよく示しています。 それから私たちは少し学んで、戦いに行く準備が整いました。 そして、私たちはいくつかの重大な間違いを犯し、何かを知っているように見えて、実際には多くを知っていないとき、絶望の谷にいることに気づきます。 そして、経験を積むにつれて自信がついていきます。

特定の事故へのさまざまな自動切り替えに関する私たちのロジックは、このグラフで非常によく説明されています。 私たちは何もする方法を知らず、ほとんどすべての作業を手作業で行いました。 その後、あらゆるものに自動化を適用すれば、安らかに眠ることができることに気づきました。 そして突然、私たちは大きな熊手を踏んでしまいます。誤検知が引き起こされ、良い意味でこれを行うべきではなかったときにトラフィックを前後に切り替えます。 その結果、レプリケーションが失敗するなど、まさに絶望の谷です。 そして、何事にも賢く取り組まなければならないという理解に至ります。 つまり、誤警報の可能性に備えて自動化に頼ることは理にかなっています。 しかし！ 結果が壊滅的なものになる可能性がある場合は、当直勤務のエンジニアに任せたほうがよいでしょう。エンジニアは実際に事故が発生したことを確認して監視し、必要な措置を手動で実行します...

まとめ

7 年間かけて、私たちは、何かが落ちるとパニックが起こるという事実から、問題は存在せず、課題があるだけで、それらは解決しなければならず、解決できるという理解まで進みました。 サービスを構築するときは、サービスを上から見て、発生する可能性のあるすべてのリスクを評価します。 それらがすぐに見つかった場合は、事前に冗長性を確保し、フォールト トレラントなインフラストラクチャを構築できるようにしてください。障害が発生してサービスの動作不能につながる可能性があるポイントは必ずそうなるからです。 また、s3 など、一部のインフラストラクチャ要素は絶対に失敗しないと思われる場合でも、失敗する可能性があることを念頭に置いてください。 そして、少なくとも理論上は、何かが起こった場合に彼らに何をするかを考えておいてください。 リスク管理計画を立ててください。 すべてを自動または手動で行うことを検討している場合は、リスクを評価してください。自動化によってすべてが切り替わり始めたら何が起こるでしょうか。これは、事故と比較してさらに悪い状況につながるのではありませんか? おそらくどこかで、自動化の使用と、実際の状況を評価して何かをその場で切り替える必要があるか、「はい、しかし今は必要ではない」かを理解する勤務中のエンジニアの反応との間で合理的な妥協点を設ける必要があるでしょう。

完璧主義と、最終的に得られる計画に費やせる実際の努力、時間、お金との間の合理的な妥協点。

このテキストは、会議でのアレクサンダー・デミドフ氏の報告書の更新および拡張版です。 稼働時間 4 日目.

出所： habr.com