NDCロンドンカンファレンス。 マイクロサービス災害の防止。 パート1

モノリスをマイクロサービスに再設計するのに何か月も費やし、ついに全員が団結してスイッチを入れることができました。最初の Web ページにアクセスすると、何も起こりません。それをリロードしますが、やはり良い結果は得られません。サイトは非常に遅く、数分間応答しません。どうしたの？

ジミー ボガード氏は講演の中で、実際のマイクロサービス障害に関する「事後分析」を実施します。彼は、彼が発見したモデリング、開発、および生産上の問題と、彼のチームがどのようにして新しい分散モノリスをゆっくりと最終的な正常な状態に変換したかを示します。設計エラーを完全に防ぐことは不可能ですが、少なくとも設計プロセスの早い段階で問題を特定して、最終製品が信頼性の高い分散システムになることを保証することはできます。

みなさん、こんにちは。私はジミーです。今日は、マイクロサービスを構築するときに大規模災害を回避する方法を聞きます。これは、船が氷山に衝突するのを防ぐために私が約 90 年半働いた会社の話です。この話を適切に伝えるには、過去に戻って、この会社がどこで始まったのか、そしてその IT インフラストラクチャが時間の経過とともにどのように成長してきたのかについて話す必要があります。この災害で無実の人々の名前を守るために、私はこの会社の名前をベルコンピュータに変更しました。次のスライドは、XNUMX 年代半ばのこうした企業の IT インフラストラクチャがどのようなものであったかを示しています。これは、コンピュータ ハードウェア ストアを運営するための大規模なユニバーサル フォールト トレラント HP Tandem メインフレーム サーバーの典型的なアーキテクチャです。

すべての注文、販売、返品、製品カタログ、顧客ベースを管理するシステムを構築する必要があったため、当時最も一般的なメインフレーム ソリューションを選択しました。この巨大なシステムには会社に関するあらゆる情報が含まれており、あらゆるトランザクションがこのメインフレームを通じて実行されました。彼らはすべての卵を 1 つのカゴに入れており、それが正常だと考えていました。ここに含まれないのはカタログ通販と電話注文だけです。

時間が経つにつれて、システムはますます大きくなり、膨大な量のゴミが蓄積されました。また、COBOL は世界で最も表現力豊かな言語ではないため、システムは巨大なモノリシックのジャンクになってしまいました。 2000 年までに、多くの企業が Web サイトを使用してすべての業務を遂行していることに気づき、最初の商用ドットコム Web サイトを構築することにしました。

初期のデザインは非常に見栄えがよく、トップレベルのサイト bell.com と、個々のアプリケーション用の多数のサブドメイン (catalog.bell.com、accounts.bell.com、orders.bell.com、product search search.bell) で構成されていました。コム。各サブドメインは ASP.Net 1.0 フレームワークと独自のデータベースを使用し、それらはすべてシステム バックエンドと通信しました。ただし、すべての注文は引き続き単一の巨大なメイン​​フレーム内で処理および実行され、その中にはすべてのゴミが残りますが、フロントエンドは個別のアプリケーションと個別のデータベースを備えた個別の Web サイトでした。

したがって、システムの設計は秩序正しく論理的に見えましたが、実際のシステムは次のスライドに示すとおりでした。

すべての要素は、相互の呼び出し、アクセスされた API、組み込みのサードパーティ DLL などに対応していました。バージョン管理システムが他人のコードを取得してプロジェクト内に押し込み、その後すべてが壊れるということがよくありました。 MS SQL Server 2005 ではリンク サーバーの概念が使用されており、スライドには矢印を示していませんが、複数のデータベースから取得したデータに基づいてテーブルを構築することに問題がないため、各データベースも相互に通信します。

システムの異なる論理領域間である程度の分離が行われたため、これが分散された汚れの塊となり、最大のゴミが依然としてメインフレームのバックエンドに残っています。

面白いのは、このメインフレームはベル コンピュータの競合他社によって構築され、依然としてその技術コンサルタントによって保守されていたということです。アプリケーションのパフォーマンスが不十分であることを確信した同社は、それらを削除してシステムを再設計することにしました。

既存のアプリケーションは 15 年間運用されており、これは ASP.Net ベースのアプリケーションの記録です。このサービスは世界中から注文を受け付け、この XNUMX つのアプリケーションからの年間収益は XNUMX 億ドルに達しました。利益の大部分は、bell.com Web サイトによってもたらされました。ブラック フライデーには、このサイトを通じて行われた注文の数が数百万件に達しました。ただし、システム要素の厳密な相互接続によりサービスに変更を加えることが事実上不可能だったため、既存のアーキテクチャでは開発ができませんでした。

最も深刻な問題は、このような取引スキームがグローバル企業では非常に一般的であるにもかかわらず、ある国で注文し、別の国で支払い、第三国に送ることができないことでした。既存のウェブサイトではこのようなことはできなかったため、電話で注文を受け付けて発注する必要がありました。これにより、同社はアーキテクチャの変更、特にマイクロサービスへの切り替えについてますます検討するようになりました。

彼らは、他の企業を調べて同様の問題をどのように解決したかを確認するという賢明な行動をとりました。これらのソリューションの 1 つは、API と外部データベースを介して接続されたマイクロサービスで構成される Netflix サービス アーキテクチャでした。

Bell Computers の経営陣は、特定の基本原則を遵守して、まさにそのようなアーキテクチャを構築することを決定しました。まず、共有データベースのアプローチを使用してデータの重複を排除しました。データは送信されず、それどころか、データを必要とする人は全員、集中管理されたソースにアクセスする必要がありました。その後、分離と自律性が続き、各サービスは他のサービスから独立しました。彼らは、あらゆることに Web API を使用することを決定しました。データを取得したり、別のシステムに変更を加えたい場合は、すべて Web API を通じて行われました。最後の目玉は、競合他社のハードウェアをベースにした「Bell」メインフレームとは対照的に、「Bell on Bell」と呼ばれる新しいメインフレームでした。

そこで、18 か月かけて、これらの基本原則に基づいてシステムを構築し、プリプロダクションに持ち込みました。週末が終わり仕事に戻った開発者たちは集まって、新しいシステムが接続されているすべてのサーバーの電源を入れました。 18 か月の作業、何百人もの開発者、最新の Bell ハードウェアを使用しましたが、良い結果は得られませんでした。このシステムをラップトップで何度も実行し、すべて問題がなかったので、多くの人がこれに失望しました。

彼らはこの問題の解決にすべてのお金を投じたのは賢明でした。彼らは、スイッチ付きの最新のサーバー ラックを設置し、ギガビット光ファイバー、非常識な量の RAM を備えた最も強力なサーバー ハードウェアを使用し、すべてを接続し、設定しましたが、やはり何もしませんでした。その後、原因はタイムアウトではないかと疑い始めたので、すべての Web 設定とすべての API 設定を調べて、タイムアウト設定全体を最大値に更新しました。そのため、彼らにできることは座って何かが起こるのを待つことだけでした。サイトへ。彼らは待って待って、ウェブサイトが最終的に読み込まれるまで 9 分半待ちました。

その後、彼らは現状を徹底的に分析する必要があることに気づき、私たちを招待してくれました。私たちが最初にわかったことは、18 か月にわたる開発期間中、本物の「マイクロ」は XNUMX つも作成されておらず、すべてが大きくなるばかりだったということでした。この後、私たちは災害の原因を理解するために、「回想」または「悲しい回顧」としても知られる事後調査（「ブレイム ストーム」とも呼ばれる、「ブレインストーム」とも呼ばれる、「ブレイム ストーム」）を書き始めました。

いくつかの手がかりがあり、そのうちの 2 つは API 呼び出し時のトラフィックが完全に飽和していたことでした。モノリシック サービス アーキテクチャを使用すると、障害の原因となった可能性のあるすべてを報告する単一のスタック トレースがあるため、何が問題になったのかをすぐに理解できます。多数のサービスが同じ API に同時にアクセスする場合、WireShark などの追加のネットワーク監視ツールを使用する以外にトレースを追跡する方法はありません。これを使用すると、単一のリクエストを調べて、その実装中に何が起こったのかを知ることができます。そこで私たちは XNUMX つの Web ページを取り上げ、ほぼ XNUMX 週間かけてパズルのピースを組み立て、さまざまな呼び出しを行って、それぞれが何をもたらしたのかを分析しました。
この画像見て。これは、1 つの外部リクエストによりサービスが多数の内部呼び出しを実行し、それが返されることを示しています。必要な情報を取得するために他のどこにもアクセスできないため、このリクエストを独立して処理できるようにするために、各内部呼び出しが追加のホップを行うことがわかります。この図は、外部リクエストが追加サービスを呼び出し、そのサービスがさらに別の追加サービスを呼び出すというような、無意味な呼び出しのカスケードのように見えます。

この図の緑色は、サービス A がサービス B を呼び出し、サービス B がサービス C を呼び出し、サービス A が再度サービス A を呼び出すという、サービスが互いに呼び出し合う半円を示しています。その結果、「分散デッドロック」が発生します。 1 つのリクエストで 1,000 のネットワーク API 呼び出しが作成され、システムにはフォールト トレランスとループ保護が組み込まれていなかったため、これらの API 呼び出しの 1 つでも失敗するとリクエストは失敗します。

計算してみました。各 API 呼び出しの SLA は 150 ミリ秒以下で、稼働時間は 99,9% でした。 200 つのリクエストで 200 回の異なる呼び出しが発生し、最良の場合、ページは 150 x 30 ミリ秒 = 99,9 秒で表示されます。当然、これではダメでした。 200% の稼働時間を 0 で乗算すると、可用性は XNUMX% になります。このアーキテクチャは最初から失敗する運命にあったことが判明しました。

私たちは開発者に、18 か月の作業にもかかわらず、どのようにしてこの問題を認識できなかったのかを尋ねました。実行したコードの SLA のみをカウントしていましたが、サービスが別のサービスを呼び出した場合、その時間は SLA にカウントされていなかったことが判明しました。 150 つのプロセス内で起動されるものはすべて XNUMX ミリ秒の値に準拠していましたが、他のサービス プロセスへのアクセスにより合計遅延が何倍にも増加しました。最初に学んだ教訓は、「SLA を管理しているのはあなたですか、それとも SLA があなたを管理していますか?」ということでした。私たちの場合は後者でした。

次に私たちが発見したのは、彼らはピーター・ダイッチとジェームス・ゴズリングによって定式化された分散コンピューティングの誤解の概念については知っていたが、その最初の部分を無視していたということでした。 「ネットワークは信頼できる」、「遅延ゼロ」、「スループットは無限」という記述は誤解であると述べています。その他の誤解としては、「ネットワークは安全である」、「トポロジは決して変更されない」、「管理者は常に 1 人だけである」、「データ転送のコストはゼロである」、「ネットワークは同種である」などがあります。
彼らはローカル マシンでサービスをテストし、外部サービスに接続しなかったため、間違いを犯しました。ローカルで開発し、ローカル キャッシュを使用する場合、ネットワーク ホップに遭遇することはありませんでした。 18 か月にわたる開発期間中、外部サービスが影響を受けた場合に何が起こるか考えたことは一度もありませんでした。

前の図のサービス境界を見ると、それらがすべて間違っていることがわかります。サービス境界の定義方法についてアドバイスする情報源はたくさんありますが、次のスライドの Microsoft のように、そのほとんどが間違っています。

この写真は、「マイクロサービスの構築方法」というテーマに関する MS ブログからのものです。これは、単純な Web アプリケーション、ビジネス ロジックのブロック、およびデータベースを示しています。リクエストは直接送信されます。おそらく、Web 用に 1 台のサーバー、ビジネス用に 1 台、データベース用に 1 台のサーバーが存在します。トラフィックが増加すると、状況は少し変わります。

ここでは、2000 つの Web サーバー間でトラフィックを分散するロード バランサー、Web サービスとビジネス ロジックの間に配置されるキャッシュ、およびビジネス ロジックとデータベースの間に配置されるもう XNUMX つのキャッシュが登場します。これはまさに、XNUMX 年代半ばに Bell が負荷分散および Blue/Green デプロイメント アプリケーションに使用したアーキテクチャです。このスキームはモノリシック構造を目的としていたため、しばらくの間はすべてがうまく機能しました。

次の図は、MS がモノリスからマイクロサービスへの移行を推奨する方法を示しています。これは、各主要サービスを個別のマイクロサービスに分割するだけです。ベルが間違いを犯したのは、この計画の実行中にでした。

彼らはすべてのサービスをさまざまな層に分割し、各層は多くの個別のサービスで構成されていました。たとえば、Web サービスにはコンテンツのレンダリングと認証のためのマイクロサービスが含まれ、ビジネス ロジック サービスは注文とアカウント情報を処理するためのマイクロサービスで構成され、データベースは特殊なデータを含む一連のマイクロサービスに分割されました。 Web、ビジネス ロジック、データベースはどちらもステートレス サービスでした。

ただし、この図は完全に間違っていました。会社の IT クラスターの外部にあるビジネス ユニットがマッピングされていなかったからです。このスキームは外部世界とのつながりをまったく考慮していないため、たとえばサードパーティのビジネス分析をどのように取得するかは明確ではありませんでした。彼らは、より多くのお金を得るためにできるだけ多くの人々を管理しようとする個々の従業員のキャリアを開発するためだけに発明されたいくつかのサービスもありました。

彼らは、マイクロサービスへの移行は、内部の N 層物理層インフラストラクチャを取り出して、そこに Docker を貼り付けるのと同じくらい簡単だと信じていました。従来の N 層アーキテクチャがどのようなものかを見てみましょう。

UI ユーザー インターフェイス レベル、ビジネス ロジック レベル、データ アクセス レベル、データベースの 4 つのレベルで構成されます。より進歩的なのは DDD (ドメイン駆動設計)、つまりソフトウェア指向アーキテクチャで、XNUMX つの中間レベルがドメイン オブジェクトとリポジトリです。

私は、このアーキテクチャにおけるさまざまな変化領域、さまざまな責任領域に目を向けようとしました。典型的な N 層アプリケーションでは、構造の上から下まで垂直に浸透するさまざまな変更領域が分類されます。これらはカタログ、個々のコンピューターで実行される構成設定、チェックアウト チェックであり、私のチームが処理しました。

このスキームの特徴は、これらの変更領域の境界がビジネス ロジック レベルに影響を与えるだけでなく、データベースにまで及ぶことです。

サービスとは何を意味するのか見てみましょう。サービス定義には 6 つの特徴的なプロパティがあります。サービス定義は次のようなソフトウェアです。

• 特定の組織によって作成および使用されます。
• システム内の特定の種類の情報のコンテンツ、処理、および/または提供に対して責任を負います。
• 特定の運用ニーズを満たすために独立して構築、展開、実行できます。
• 消費者およびその他のサービスと通信し、合意または契約上の保証に基づいて情報を提供します。
• 不正アクセスから自身を保護し、情報の損失を防ぎます。
• 情報の損傷につながらないように障害を処理します。

これらの性質はすべて「自律性」という一言で表現できます。サービスは互いに独立して動作し、特定の制限を満たし、人々が必要な情報を受け取るための契約に基づいて定義されます。特定のテクノロジーについては言及しませんでしたが、その使用は自明のことです。

次に、マイクロサービスの定義を見てみましょう。

• マイクロサービスはサイズが小さく、1 つの特定の問題を解決するように設計されています。
• マイクロサービスは自律的です。
• マイクロサービス アーキテクチャを作成するときは、都市計画のメタファーが使用されます。これは、Sam Newman の著書『Building Microservices』の定義です。

境界コンテキストの定義は、Eric Evans の著書 Domain-Driven Design から引用されています。これは、ボリューム建築モデルを操作してモデルを異なる境界コンテキストに分割し、それらの間の相互作用を明示的に定義する建築設計センターである DDD の中核となるパターンです。

簡単に言えば、境界コンテキストは、特定のモジュールが使用できる範囲を示します。このコンテキスト内には、たとえばビジネス ドメインで見ることができる論理的に統合されたモデルがあります。受注関係者に「顧客とは誰ですか」と聞けば1つの定義が得られ、営業関係者に聞けば別の定義が得られ、出演者が3つ目の定義を与える。

したがって、Bounded Context は、サービスの消費者が何であるかについて明確な定義を与えることができない場合は、この用語の意味について話すことができる境界を定義し、その後、これらの異なる定義の間の移行点を定義しましょう、と言っています。つまり、クライアントのことを発注の観点から言えばこれはこれを意味し、営業の観点から言えばこれはこれを意味します。

マイクロサービスの次の定義は、あらゆる種類の内部操作をカプセル化し、作業プロセスのコンポーネントが環境に「漏洩」することを防ぐことです。次に、SLA から返される契約の概念に代表される、「外部とのやり取りまたは外部通信のための明示的な契約の定義」が続きます。最後の定義はセル (セル) の比喩であり、マイクロサービス内の一連の操作が完全にカプセル化され、マイクロサービス内に外部と通信するためのレセプターが存在することを意味します。

そこで私たちはベルコンピュータの社員たちにこう言いました。「あなたにはお金がないので、あなたが引き起こした混乱を修正することはできません。しかし、サービスを 9 つだけ修正して、すべてがうまくいくようにします」センス。"ここでは、リクエストに XNUMX 分半より早く応答できるように、唯一のサービスをどのように修正したかを説明することから始めます。

22:30分

続きはまたすぐに…

いくつかの広告

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com