ディストリビューション、マイクロサービス、クラスターとは何かを 3 分で理解しましょう。

1. 分散型

Xiao Ma さんは、商品管理、注文管理、ユーザー管理、支払い管理、ショッピングカートなどのモジュールを備えた TT Cat というオンライン ショッピング ウェブサイトを運営しています。各モジュールは独立したクラウド サービス ホストにデプロイされます。

現在、プログラマーの Xiao Ming は TT Cat を閲覧しており、仕事の効率を向上させるために素晴らしい Cherry メカニカル キーボードを購入したいと考えています。そこで彼は、TT Cat のホームページを開き、商品を検索し、詳細やコメントを閲覧し、ショッピングカートに追加し、注文し、支払いを行い、その他の一連の操作を実行しました。シャオミンは、多額の費用がかかったにもかかわらず、買い物をスムーズに一回で完了しました。

しかし、システムはこの一連の操作をどのように実行するのでしょうか?複雑な呼び出し関係を下の図に示します (一部の詳細は省略しています)。ユーザーは商品を見たり触ったりすることはできませんが、注文プロセス全体はインターネット上で行われます。

TT Cat はすべての機能モジュールをさまざまな場所に展開し、最終的に一連のユーザー要求を完了します。これはおそらく分散システムです。

2. マイクロサービス

ブロガーは、マイクロサービスはアーキテクチャの一種であり、分散の範囲内でもあると考えています。マイクロが複数ある場合、マイクロとは何でしょうか?分散システムでは、マイクロサービスは単一の責任、軽量通信 (HTTP)、独立性、およびプロセスの分離を重視します。まあ、これ以上言うことはありません。練習すれば完璧になります。 Spring-Cloud 関連のマイクロサービス コンポーネントについて詳しく学習することをお勧めします。

TT Cat は、女の子に人気の独身の日 (ダブル 11) などのアクティビティを毎年企画しています。深夜に大量のユーザーが集中し、特定のサービスがダウンしてしまう可能性があります。

このとき、ユーザーの注文がタイムアウトしたり、500 エラーが直接発​​生するという問題が発生します。どうすれば解決できるでしょうか?

3. 負荷分散クラスター

どうしてこんな重要なイベントでこんなことが起こるのでしょうか?実際、ジャック・マーは事前に複数のサーバーを購入しており、エンジニアは各ビジネス機能モジュールの複数のコピーをコピーして展開していました。

同じ機能を持つ各モジュールはグループを形成し、単一システムのモードで管理されます。女の子が注文すると、実際にはクラスターグループとセックスすることになりますが、システムにより、そのうちの 1 人とのみセックスすることを保証します。クラスター グループには、誰とセックスするかに関する独自のスケジュール アルゴリズムがあるため、女の子とセックスできないことを心配する必要はありません。

古代では下品ではあるがわいせつではなかったものの例を挙げてみましょう。古代に生きていたとしたら、あなたは18歳で、未婚で、背が高く、お金持ちで、ハンサムで、個人的な生理的な問題を緊急に解決する必要がありました。それで、伝説の娯楽の場所に来たわけですが、えーと、これは古代では合法だったんです。この時、マダムか大きな急須がお出迎えに来てくれます。特別なリクエストがなければ、売春婦がいる部屋に連れて行かれます...

[[209082]]

場面は突然変わり、プログラマーのチタン製の犬の目が見えなくなったようです。これを次のように理解することができます。マダムはスケジューリング アルゴリズムが組み込まれたロード バランサーであり、売春婦はグループの 1 つです。

さて、本題に戻りましょう。省略記号はあなた自身の想像のためのものです。これを見た友人は、通常の本番環境ではロードバランサーとして何を使用するのかと尋ねるかもしれません。

富裕層はハードウェアF5を使用する

DNS負荷分散は大した問題ではない

LVSは優れた技術を持つ人々によって使用されています

貧しいスタートアップはNginxしか使えない

もちろん、上記以外にもロードバランサーの種類は存在します。興味があれば、自分で Google で検索してみてください。

「知識と行動について」の章には、「事実を知り、理由を知れ」と書かれています。これらのロードバランサーがネットワーク内でどのように機能するかを簡単に説明しましょう。ネットワークを勉強したことがある友人は、おそらく 7 層のネットワーク モデルを知っているでしょう。

まず、大学の基礎科目を皆さんに復習してもらうための写真です。

授業の教科書に満足していないと感じていますか?これは別の TCP/IP 5 層モデルです。

各レイヤーでは異なるデバイスが動作します。たとえば、裕福な国有企業が使用する F5 はレイヤー 4 ～ 7 で動作し、一般的なインターネット企業が使用する LVS はトランスポート層で動作し、最も広く使用されている Nginx はアプリケーション層で動作します。

最後に、DNS 負荷分散について説明します。 DNS は最も原始的で単純な方法ですが、DNS 負荷分散の制御はドメイン ネーム サービス プロバイダーが行います。 NDS には、A レコードのマルチレベル解決とキャッシュに関する問題があり、Web サイト自体ではそれ以上の管理を行うことができません。その結果、中小企業ではほとんど使用されなくなりました。

もちろん、十分な能力がある場合は、DNS ロード バランシングも良い選択肢です。次の図は、TT Cat ドメイン名の A レコードを検出して取得した情報の一部です。あくまで参考用であり、ご自身で理解していただけます。

4. 高可用性クラスタ

クラスターなので、単一障害点は存在できません。クラウド サービスに注目すると、「デュアル マシン ホット スタンバイ」、「2 つの場所と 3 つのセンター」などの用語に出会うことがあります。

デュアルマシンのホットスタンバイは、高可用性を実現します。上の図に示すように、本番環境には 2 つの負荷分散ノードがあります。プライマリ ノードはアクティブ状態であり、他のノードはスタンバイ状態です。プライマリノードが予期せずダウンした場合、keepalived を使用してそれを検出し、スタンバイサービスにすばやく切り替えて、通常の業務運用を確保できます。 2 つの場所と 3 つのセンターについては、下の図を見るとよりよく理解できると思います。写真はインターネットから取ったものです。

5. エラスティッククラウド

ポニー・マーはダブルイレブンに備えて大量のサーバーを購入しましたが、イベントが終了すると、通常のユーザートラフィックがサーバーの顧客受け入れ能力に追いつかなくなり、大量のサーバーがアイドル状態になりました。

これは受け入れられません。ただ何もせずに座っているわけにはいきません。賢い Xiao Ma Ge は的を射たアイデアを思いつき、TT Cloud Team を結成しました。当社は長年の努力を通じて、従量課金制のクラウド、Elastic IP、共有帯域幅などの製品を開発し、中小企業の収益増加とコスト削減を支援してきました。

6. フェイルオーバー

[[209084]]

Xiao Ming さんはこのキーボードがよいと思い、喜んで購入ボタンをクリックしましたが、突然ログイン ページにリダイレクトされました。

なんてこった？ズボンを脱いでこれを見せたの？普通のユーザーは何も問題がないと考え、再度ログインするだけかもしれません。しかし、厳格なプログラマーであるシャオミンは、何が起こっているのかを解明したいと考えています。

データを慎重に検討し分析した結果、Xiao Ming は以下の結論に達しました。

上記の障害が発生したとき、シャオミンは自分が注文したサービスがオフラインで、別のサービスにリクエストが分散されたのだと考えましたが、なぜログインページにジャンプしたのでしょうか。プログラマーとして、Xiao Ming はサービスがステートフルとステートレスに分かれていることを明確に認識しています。通常の HTTP リクエストはステートレスですが、ユーザーのステータスを判断するために Cookie またはセッションを使用するのが一般的です。

この時点で、一体何が起こっているのか理解できるはずです。私たちがよく知っている Tomcat を例に挙げてみましょう。通常、ユーザー情報はセッションに保存され、セッションは Tomcat メモリに保存されます。ブラウザは、Cookie 内の JSESSIONID を通じてサーバーに認証します。

しかし、サーバーがクラッシュしたため、注文リクエストは別のサービスに分散されました。当然のことながら、シャオミンは自分のセッションを見つけることができませんでした。

Xiao MingさんはTT Catに問題を報告しました。これを見たシャオ・マーは、クラスターはすでに構築されているがこれが欠けていると考え、すぐにエンジニアに解決策を考えてもらうように依頼しました。

エンジニアたちは最終的に 2 つの解決策を思いつきました。

サーバー ユーザー ステータスのレプリケーション (コストが高く、ソフトウェアとハ​​ードウェアのサポートが必要で、遅延が発生し、障害のリスクがあります)

ユーザーステータスの統合保存（話さない、笑うだけ）

最終的に、エンジニアは 2 番目のソリューションを採用し、Redis を使用してユーザーのステータス データを保存しました。

知識補足

私は最近、Alibaba Cloud の負荷分散 SLB に触れて使用しており、TT Cat の負荷分散実装について大まかに理解しています。次のアーキテクチャ実装は TT Cat から派生したものです。

負荷分散では、クラスター展開を使用してセッション同期を実現し、サーバーの単一障害点を排除し、冗長性を向上させ、サービスの安定性を確保します。 Alibaba Cloud は現在、レイヤー 4 (TCP および UDP プロトコル) とレイヤー 7 (HTTP および HTTPS プロトコル) の負荷分散サービスを提供しています。

4 番目のレイヤーでは、オープン ソース ソフトウェア LVS (Linux Virtual Server) + keepalived を使用して負荷分散を実現します。

第 7 層では、Tengine を使用して負荷分散を実現します。

次の図に示すように、各リージョンの 4 層の負荷分散は、実際には複数の LVS マシンを LVS クラスターに展開することによって実行されます。クラスター展開モードは、異常な状況下でも負荷分散サービスの可用性、安定性、スケーラビリティを大幅に保証します。

LVS クラスター内の各 LVS は会話を実行し、マルチキャスト メッセージを通じてクラスター内の他の LVS マシンと同期します。これにより、LVS クラスター内のマシン間の会話の同期が実現されます。次の図に示すように、クライアントが 3 つのデータ パケットをサーバーに送信すると、LVS1 上に確立されたセッション A が他の LVS マシンとの同期を開始します。図の実線は既存の接続を表し、図の点線は、LVS1 に障害が発生したりメンテナンスが行われたりした場合に、この部分のトラフィックが正常に動作できるマシン LVS2 に送信されることを示しています。したがって、負荷分散クラスターはホット アップグレードをサポートし、マシン障害やクラスターのメンテナンス中もユーザー サービスに影響を与えることなく、ユーザーに対して可能な限り透過的になります。