Mail.ru クラウド ソリューション プラットフォームでフォールト トレラント Web アーキテクチャがどのように実装されているか

こんにちは、ハブ！私はシステム管理チームの責任者、アルテム・カラミシェフです。 Mail.Ru クラウドソリューション (MCS)過去1年間、多くの新製品をリリースしてきました。APIサービスが容易に拡張可能で、フォールトトレランスを備え、ユーザー負荷の急激な増加にも対応できることを確認したいと考えました。私たちのプラットフォームはOpenStack上に実装されており、フォールトトレランスなシステムを実現するために、どのようなコンポーネントのフォールトトレランス問題を解決する必要があったかをお話ししたいと思います。これは、OpenStack上で製品を開発している方々にとって興味深い内容になると思います。

プラットフォーム全体のレジリエンスは、その構成要素のレジリエンスによって構成されます。そのため、リスクを特定し、解決したすべてのレベルを段階的に検討していきます。

このストーリーのビデオ版は、アップタイムの4日目のカンファレンスで発表されたもので、主催者は ITSumma、ぜひご覧ください アップタイムコミュニティのYouTubeチャンネル.

物理アーキテクチャのフォールトトレランス

MCSクラウドのパブリック部分は現在、200つのTier IIIデータセンターを拠点としており、その間には物理レベルで異なるルートで予約されたプライベートダークファイバーが敷設されており、スループットはXNUMXGbpsです。Tier IIIレベルは、物理インフラストラクチャに必要なレベルのフォールトトレランスを提供します。

ダークファイバーは物理レベルと論理レベルの両方で冗長化されています。チャネルの冗長化プロセスは反復的であり、問​​題が発生したため、データセンター間の接続を継続的に改善しています。

例えば、つい最近、データセンター近くの井戸で作業中に、掘削機がパイプを貫通し、メインとバックアップの光ケーブルの両方がそのパイプ内にあったことが判明しました。データセンターとのフォールトトレラント通信チャネルが、井戸のある地点で脆弱であることが判明しました。その結果、インフラの一部が利用できなくなりました。私たちは結論を導き出し、隣接する井戸から追加の光ケーブルを敷設するなど、いくつかの対策を講じました。

データセンターには通信プロバイダの拠点があり、BGP経由でプレフィックスをブロードキャストしています。ネットワークの方向ごとに最適なメトリックが選択され、さまざまなクライアントに最高の接続品質を提供します。あるプロバイダを経由した接続が切断された場合、利用可能なプロバイダを経由してルーティングを再構築します。

プロバイダーに障害が発生した場合、自動的に次のプロバイダーに切り替えます。データセンターの1つに障害が発生した場合、2つ目のデータセンターにサービスのミラーコピーが保存され、全負荷を引き受けます。

物理インフラストラクチャの回復力

アプリケーションレベルのフォールトトレランスに使用するもの

当社のサービスは、多数のオープンソース コンポーネントに基づいて構築されています。

ExaBGP — BGPベースのダイナミックルーティングプロトコルを用いて様々な機能を実装するサービスです。当社では、ユーザーがAPIにアクセスする際に使用するホワイトIPアドレスをアナウンスするために、このサービスを積極的に活用しています。

ハプロキシ OSIモデルの様々なレベルで非常に柔軟なトラフィック分散ルールを設定できる高負荷バランサーです。データベース、メッセージブローカー、APIサービス、Webサービス、社内プロジェクトなど、あらゆるサービスへの負荷分散に使用しており、すべてがHAProxyの背後にあります。

APIアプリケーション — Python で書かれた Web アプリケーション。ユーザーはこれを使用してインフラストラクチャやサービスを管理します。

労働者の応募 (以下、ワーカー) — OpenStackサービスにおいて、APIコマンドをインフラストラクチャに送信するためのインフラストラクチャデーモンです。例えば、ディスク作成はワーカーで行われ、作成要求はAPIアプリケーションで行われます。

OpenStack アプリケーション標準アーキテクチャ

OpenStack向けに開発されるサービスのほとんどは、単一のパラダイムに従うように設計されています。サービスは通常、APIとワーカー（バックエンド実行プログラム）の2つの部分で構成されます。APIは一般的にPythonで記述されたWSGIアプリケーションであり、独立したプロセス（デーモン）として起動されるか、NginxやApacheなどの既製のWebサーバーを介して起動されます。APIはユーザーのリクエストを処理し、実行のための追加指示をワーカーアプリケーションに渡します。転送はメッセージブローカー（通常はRabbitMQ）を介して行われますが、その他のブローカーのサポートは不十分です。メッセージがブローカーに到達すると、ワーカーによって処理され、必要に応じてレスポンスが返されます。

このパラダイムでは、RabbitMQとデータベースという共通の障害点が分離されていると考えられます。しかし、RabbitMQは単一のサービス内で分離されており、理論上はサービスごとに個別に設定できます。そのため、MCSではこれらのサービスを可能な限り分離し、プロジェクトごとに個別のデータベース、個別のRabbitMQを作成します。このアプローチは、脆弱な箇所で障害が発生した場合でも、サービス全体がダウンするのではなく、一部のみがダウンする点で優れています。

ワーカー アプリケーションの数に制限はないため、バランサーの背後で API を簡単に水平方向に拡張して、パフォーマンスとフォールト トレランスを向上させることができます。

一部のサービスでは、APIとワーカー間で複雑なシーケンシャル操作が発生する場合、サービス内での調整が必要になります。このような場合、Redis、Memcache、etcdなどのクラスターシステムといった単一の調整センターが使用されます。これにより、あるワーカーが別のワーカーに「このタスクは自分に割り当てられた（引き受けないでください）」ことを伝えることができます。私たちはetcdを使用しています。通常、ワーカーはデータベースと積極的に通信し、情報の書き込みと読み取りを行います。データベースには、マルチマスタークラスター内にあるmariadbを使用しています。

このような典型的な単一サービスは、OpenStackで一般的に受け入れられている方法で構成されます。これはクローズドシステムとみなすことができ、スケーリングとフォールトトレランスの手法は極めて明確です。例えば、APIのフォールトトレランスを実現するには、バランサーをAPIの前に置くだけで十分です。ワーカーのスケーリングは、ワーカーの数を増やすことで実現されます。

全体的なスキームにおける弱点はRabbitMQとMariaDBです。これらのアーキテクチャについては別の記事で詳しく説明する価値があります。この記事では、APIのフォールトトレランスに焦点を当てたいと思います。

Openstackアプリケーションアーキテクチャ。クラウドプラットフォームのバランスとフォールトトレランス

ExaBGP で HAProxy ロードバランサーをフォールトトレラントにする

APIをスケーラブル、高速、そしてフォールトトレラントにするために、APIの前段にバランサーを配置しました。そこでHAProxyを選択しました。私の考えでは、HAProxyは私たちのタスクに必要なすべての特性を備えています。複数のOSIレベルでのバランシング、管理インターフェース、柔軟性とスケーラビリティ、豊富なバランシング手法、セッションテーブルのサポートなどです。

最初に解決する必要があった問題は、バランサ自体のフォールトトレランスでした。バランサを単にインストールするだけでは、障害点（バランサが故障し、サービスがクラッシュする）が生じてしまいます。これを防ぐため、ExaBGPとHAProxyを併用しました。

ExaBGP では、サービスのヘルスチェックメカニズムを実装できます。このメカニズムを使用して HAProxy のヘルスチェックを行い、問題が発生した場合には BGP から HAProxy サービスを無効化しました。

ExaBGP+HAProxyスキーム

1. 必要なソフトウェアである ExaBGP と HAProxy を 3 台のサーバーにインストールします。
2. 各サーバーにループバック インターフェイスを作成します。
3. 3 台のサーバーすべてで、このインターフェースに同じホワイト IP アドレスを登録します。
4. ホワイト IP アドレスは、ExaBGP 経由でインターネットに公開されます。

フォールトトレランスは、3台のサーバーすべてから同じIPアドレスをアナウンスすることで実現されます。ネットワークの観点から見ると、同じアドレスに3つの異なるネクストホップからアクセスできることになります。ルーターは3つの同一のルートを認識し、独自のメトリック（通常は同じオプション）に基づいて最も優先度の高いルートを選択し、トラフィックはいずれかのサーバーにのみ送信されます。

HAProxy の動作に問題が発生した場合やサーバーに障害が発生した場合、ExaBGP はルートのアドバタイズを停止し、トラフィックはスムーズに別のサーバーに切り替わります。

このようにして、バランサーのフォールト トレランスを実現しました。

HAProxy ロードバランサのフォールトトレランス

この方式は不完全であることが判明しました。HAProxyを予約する方法は学習しましたが、サービス内で負荷を分散する方法は学習しませんでした。そこで、この方式を少し拡張し、複数のホワイトIPアドレス間で負荷分散を行うように切り替えました。

DNSベースのバランシングとBGP

HAProxy の手前での負荷分散の問題は未解決のままです。しかし、私たちのケースのように、非常に簡単に解決できます。

3台のサーバーをバランスよく運用するには、XNUMXつのホワイトIPアドレスと古き良きDNSが必要です。これらのアドレスはそれぞれ、各HAProxyのループバックインターフェースで定義され、インターネットにアナウンスされます。

OpenStackでは、リソース管理にサービスカタログが使用され、特定のサービスのAPIエンドポイントが指定されます。このカタログでは、ドメイン名「public.infra.mail.ru」を指定します。このドメイン名はDNS経由で3つの異なるIPアドレスに解決されます。その結果、DNS経由で3つのアドレス間で負荷分散が実現されます。

しかし、ホワイトリストIPアドレスをアナウンスする際にはサーバー選択の優先順位を制御できないため、まだバランス調整は行われていません。通常、IPアドレスの優先順位に基づいて1台のサーバーのみが選択され、BGPではメトリックが指定されていないため、残りの2台はアイドル状態になります。

ExaBGP経由で異なるメトリックを持つルートを発行し始めました。各バランサーは3つのホワイトIPアドレスすべてを広告しますが、そのうちの1つ（このバランサーのメインIPアドレス）は最小メトリックで広告されます。そのため、3つのバランサーすべてが稼働している場合、最初のIPアドレスへのリクエストは最初のバランサーに、2番目のIPアドレスへのリクエストは2番目のバランサーに、3番目のIPアドレスへのリクエストは3番目のバランサーに送られます。

バランサーの1つに障害が発生した場合、どうなるでしょうか？いずれかのバランサーに障害が発生した場合、そのメインアドレスは他の2つのバランサーから引き続きアドバタイズされ、トラフィックはそれらの間で再分配されます。そのため、DNS経由でユーザーに複数のIPアドレスが同時に提供されます。DNSと異なるメトリックによるバランシングにより、3つのバランサーすべてに負荷が均等に分散されます。同時に、フォールトトレランスも維持されます。

DNS + BGP に基づく HAProxy 負荷分散

ExaBGPとHAProxyの相互作用

そこで、サーバー障害発生時にはルートアナウンスの終了をベースとしたフォールトトレランスを実装しました。しかし、HAProxyはサーバー障害以外の理由、例えば管理エラーやサービス内部の障害によっても切断される可能性があります。このような場合でも、故障したバランサーを負荷から切り離す必要があるため、別のメカニズムが必要です。

そこで、以前のスキームを拡張し、ExaBGPとHAProxy間のハートビートを実装しました。これは、ExaBGPがカスタムスクリプトを使用してアプリケーションのステータスを確認する際に、ExaBGPとHAProxy間のやり取りをソフトウェアで実装したものです。

これを実現するには、ExaBGPの設定ファイルでHAProxyの状態を確認できるヘルスチェッカーを設定する必要があります。今回のケースでは、HAProxyにヘルスバックエンドを設定し、ExaBGP側からシンプルなGETリクエストで状態を確認しました。アナウンスが送信されなくなった場合、HAProxyはおそらく動作していないため、アナウンスする必要はありません。

HAProxyヘルスチェック

HAProxyピア: セッション同期

次に必要なのはセッションの同期です。分散バランサーを使用する場合、クライアントセッションに関する情報のストレージを整理するのは困難です。しかし、HAProxyは、ピア機能（異なるHAProxyプロセス間でセッションテーブルを転送する機能）を備えているため、これを実現できる数少ないバランサーの1つです。

バランスをとる方法はいくつかある。例えば、 ラウンドロビン、そしてクライアントのセッションが記憶され、毎回同じサーバーにアクセスするたびに、拡張されたオプションが実行されます。私たちは後者のオプションを実装したいと考えていました。

HAProxyは、このメカニズムのクライアントセッションを保存するためにスティックテーブルを使用します。スティックテーブルには、クライアントの送信元IPアドレス、選択されたターゲットアドレス（バックエンド）、および一部のサービス情報が保存されます。スティックテーブルは通常、送信元IPアドレスと宛先IPアドレスのペアを保存するために使用され、ラウンドロビンバランシングモードなど、別のバランサーに切り替える際にユーザーセッションコンテキストを転送できないアプリケーションで特に役立ちます。

スティックテーブルを異なるHAProxyプロセス間（バランシングが行われるプロセス間）で移動するように設定すれば、バランサーは1つのスティックテーブルプールで動作できるようになります。これにより、バランサーの1つに障害が発生してもクライアントネットワークをシームレスに切り替えることができ、クライアントセッションの動作は以前に選択された同じバックエンドで継続されます。

適切に動作させるには、セッションを確立するバランサの送信元IPアドレスの問題を解決する必要があります。この場合、これはループバックインターフェース上の動的アドレスです。

ピアは特定の条件下でのみ正常に動作します。つまり、TCPセッションが中断される時間がないほど、TCPタイムアウトが十分に大きいか、スイッチングが十分に高速である必要があります。ただし、これによりシームレスなスイッチングが可能になります。

同じ技術をベースにしたIaaSサービスも提供しています。これは OpenStack 向けロードバランササービスOctaviaと呼ばれるものです。2つのHAProxyプロセスをベースにしており、最初からピアサポートが組み込まれています。彼らはこのサービスにおいて優れた実績を誇っています。

この図は、3 つの HAProxy インスタンス間のピア テーブルの移動を概略的に示しており、これをどのように設定するかについての構成が提供されています。

HAProxyピア（セッション同期）

同じスキームを実装する場合は、慎重にテストする必要があります。100%のケースで同じ形式で動作するとは限りません。しかし、少なくともクライアントの送信元IPを記憶しておく必要がある場合でも、スティックテーブルが失われることはありません。

同じクライアントからの同時リクエスト数を制限する

APIを含む、公開されているサービスは、リクエストの集中攻撃を受ける可能性があります。その原因は、ユーザーエラーから標的型攻撃まで、実に様々です。IPアドレスによるDDoS攻撃も定期的に発生しています。また、クライアントのスクリプトにミスがあり、小規模なDDoS攻撃が発生することも少なくありません。

いずれにせよ、追加の保護対策を講じる必要があります。明白な解決策は、APIへのリクエスト数を制限し、悪意のあるリクエストの処理にプロセッサ時間を浪費しないようにすることです。

このような制限を実装するために、HAProxyをベースに構築されたレート制限を使用しています。レート制限は、同じスティックテーブルを使用しています。この制限は非常に簡単に設定でき、APIへのリクエスト数によってユーザーを制限できます。アルゴリズムはリクエストの送信元IPを記憶し、10人のユーザーからの同時リクエスト数を制限します。もちろん、各サービスのAPIの平均負荷プロファイルを計算し、その値の約XNUMX倍の制限を設定しています。私たちは状況を常に注意深く監視し、常に最新の情報を把握しています。

実際、これはどのように見えるでしょうか？当社のAPIを自動スケーリングに常時使用しているお客様もいらっしゃいます。そのようなお客様は、朝方に1000～XNUMX台の仮想マシンを作成し、夕方に削除しています。OpenStackの場合、特にPaaSサービスでは、仮想マシンの作成に少なくともXNUMX件のAPIリクエストが発生します。これは、サービス間のやり取りもAPIを介して行われるためです。

このようなタスク転送は非常に大きな負荷を引き起こします。この負荷を評価し、日々のピーク値を収集し、それを10倍に増やして、これがレート制限となりました。私たちは常に状況を把握しています。ボットや、起動可能なCGAスクリプトがあるかどうかを確認しようとするスキャナーが頻繁に出現するため、積極的にそれらをカットしています。

ユーザーに気づかれずにコードベースを更新する方法

コード展開プロセスレベルでもフォールトトレランスを実装しています。ロールアウト中に障害が発生することもありますが、サービスの可用性への影響は最小限に抑えられます。

私たちはサービスを継続的にアップデートしており、ユーザーに影響を与えることなくコードベースを更新する必要があります。私たちは、HAProxyの管理機能を活用し、サービスにGraceful Shutdownを実装することでこれを実現しました。

この問題を解決するには、バランサー管理とサービスの「正しい」シャットダウンを確実に行う必要がありました。

• HAProxyの場合、制御は統計ファイルを介して行われます。統計ファイルは基本的にソケットであり、HAProxy設定ファイルで定義されています。stdio経由でコマンドを渡すことができます。しかし、私たちの主な設定管理ツールはAnsibleなので、HAProxyを管理するための組み込みモジュールが搭載されています。私たちはこれを積極的に活用しています。
• APIとエンジンサービスのほとんどは、正常なシャットダウン技術をサポートしています。シャットダウン時には、HTTPリクエストやサービスタスクなど、現在のタスクが完了するまで待機します。ワーカーでも同様です。ワーカーは実行するすべてのタスクを把握しており、すべてが正常に完了すると終了します。

これら 2 つの点により、安全なデプロイメント アルゴリズムは次のようになります。

1. 開発者は新しいコード パッケージ (この場合は RPM) をビルドし、開発環境でテストし、ステージでテストして、ステージ リポジトリに残します。
2. 開発者は、新しいパッケージのバージョン、新しい機能の説明、および必要に応じてデプロイメントに関するその他の詳細など、「成果物」の最も詳細な説明を使用して、デプロイメントのタスクを設定します。
3. システム管理者がアップデートを開始します。Ansibleプレイブックを実行すると、以下の処理が実行されます。
   • ステージ リポジトリからパッケージを取得し、それに基づいて製品リポジトリ内のパッケージ バージョンを更新します。
   • 更新されるサービスのバックエンドのリストをコンパイルします。
   • HAProxy で更新する最初のサービスをシャットダウンし、そのプロセスが完了するまで待機します。正常なシャットダウンにより、現在のすべてのクライアント要求が正常に完了することが保証されます。
   • API、ワーカーが完全に停止し、HAProxy がシャットダウンされた後、コードが更新されます。
   • Ansible はサービスを開始します。
   • 各サービスごとに、事前に定義されたいくつかのキーテストに対するユニットテストを実行する特定の「ハンドル」がプルされます。新しいコードの基本的なチェックが行われます。
   • 前の手順でエラーが見つからなかった場合、バックエンドはアクティブ化されます。
   • 次のバックエンドに進みましょう。
4. すべてのバックエンドが更新された後、機能テストが実行されます。テストが不足している場合、開発者は追加された新しい機能を確認します。

これでデプロイは完了です。

サービス更新サイクル

この仕組みは、一つのルールがなければ機能しません。私たちは、戦闘において新旧のバージョンを同時にサポートします。ソフトウェア開発段階で事前に、サービスデータベースに変更があっても以前のコードに影響が及ばないように規定しています。その結果、コードベースは段階的に更新されます。

まとめ

フォールト トレラントな WEB アーキテクチャに関する私自身の考えを共有し、その重要なポイントをもう一度強調したいと思います。

• 物理的なフォールトトレランス。
• ネットワークフォールトトレランス（バランサ、BGP）
• 使用および開発されるソフトウェアのフォールト トレランス。

皆様、安定した稼働をお祈りします！

出所： habr.com