分散システム。 デザインパターン。 書評

こんにちは同僚。 本日、次のレビューの翻訳をBen Neidelのサイトから公開します。このサイトは確かにオリジナルに興味を持っています。 今回は、「 Distributed Systems。Design Patterns 」という本についてお話します。これは、今年の初めに出版された「 Master Kubernetes 」という本を補完するもので、本質的には、分散システムの設計におけるGoFの類似物です。







良い読書をしてください。



週末、分散システムという本を読みました。 デザインパターン、 Brendan Burns著。 私は本が本当に好きでしたが、認めなければなりませんが、私はその中に少し異なる資料を見つけることを期待していました。 そのため、本の説明では、コンテナのみが記載されています。 同時に、本で説明されているパターンはコンテナー化だけでなく適用可能ですが、ここで説明されているほとんどすべてのパターンはコンテナーコンテキストで提供され、その後Kubernetes展開パイプラインで考慮されます。 ところで判明した。 私はコンテナ指向の開発と展開に精通し始めたばかりで、そのような「コンテナ」の観点からアーキテクチャパターンを議論することは私にとって啓示でした。 このアプローチは、マイクロサービスの状況で、小さなサービスがどのように正しく識別され、それぞれに特定の機会があるかをよく理解するのに役立ちました。



この本の著者であるブレンダン・バーンズは、オープンソースプロジェクトであるKubernetesの共同設立者です。 したがって、そのアプリケーション例のすべてがKubernetes構成ファイルに基づいたコンテナーの展開を中心に構築されていることは驚くことではありません。 この本を読んだとき、私はDockerに少し精通していて、Kubernetesについて何も知りませんでした。 そのため、Kubernetes構成ファイルの「目的」を読み取るだけで理解しようとしました。 ただし、読者が少なくともKubernetesを使用した経験がある場合は、この本の方が役立つと思います。



この本を読んで、グレゴール・ホープとボビー・ウルフの作品「 エンタープライズ・アプリケーション用の統合テンプレート 」との関連を取り除くことができませんでした。 Burnsが説明したパターンの多くは、HopeとWolfeが説明したメッセージキューパターンに非常に似ています。 実際、両方の本で同じ方法で多くのパターンが参照されていることにも注意する必要があります（たとえば、Scatter / Gather）。 両方の本のテーマは、複雑なモノリシックシステムを一連の小さな、きめ細かく再利用可能なサービスに分割することであるため、これは論理的です。 Burnsは、「Enterprise Application Integration Templates」という本で説明されているものと同じ、メッセージベースのワークフローの機能に関与するProducerサービスとConsumerサービスの実装に役立つ特定のアプローチを設定しているとさえ言えると思います。



繰り返しますが、これら2冊の本の間にある類似点は、設計パターンの力を証明していると思います。 実績のあるソリューションにどれだけうまく導いてくれるか、そして共通言語で推論できるように設計パターンが技術的なコミュニケーションを促進するという事実の両方で。



同時に、私が最も気に入ったアプローチの1つは、Distributed Systemsという本で説明されています。 設計パターン」は、メッセージキューの消費に正確に関連しています。 Burnsは、作業コンテナにシステムからメッセージを直接プルさせるのではなく（AmazonのSimple Queue Service（SQS）システムで行われる方法と同様）、「アンバサダー」（アンバサダーパターン）を作成することをお勧めします。 このような「アンバサダー」コンテナは、作業コンテナとともにデプロイされ、キューを操作するための汎用APIを提供します。 Ambassadorコンテナを使用すると、メッセージキュー内の要素の永続的なストレージに関連する実装の詳細を抽象化できるため、作業コンテナは特定の技術的ソリューションから完全に独立しています。



「ワークキューのコンテナソースの大使」は、赤い糸として本を駆け抜ける横断的トピックのほんの一例です。小さなコンテナのコレクションを使用して、個々のコンテナが特定のタスクに集中し、可能な限り再利用できるようにします。 Burnsは、この概念を個々のコンテナーレベルで検討し、コマンドライン引数と環境変数を使用したコンテナーのパラメーター化について説明します。 その後、彼は1つ上のレベルに進み、シングルノードコンテキストでのマルチコンテナサイドカーとアンバサダーパターンについて話します。 最後に、マルチコンテナパターンを使用して強力なマイクロサービスアーキテクチャを作成する方法を示します。



Burnsは、マイクロサービス全体の「夢」を完璧に表現できたと思います。

マイクロサービスのアプローチには多くの利点があり、その多くは信頼性と柔軟性に関連しています。 マイクロサービスはアプリケーションを小さな部分に分割し、各部分が特定のサービスの提供を担当します。 サービスの範囲を狭めることにより、各サービスは2つのピザを提供できるチームを開発および維持できます。



チームの規模を縮小すると、活動を維持するためのコストも削減されます。



さらに、マイクロサービス間の正式なインターフェースの出現により、チームの相互依存性が弱まり、サービス間の信頼できる契約が確立されます。 このような正式な契約は、APIを提供するチームが互換性を確保するために必要な範囲を理解しているため、緊密なチーム同期の必要性を減らします。 このような分解により、チームは開発のペースと新しいバージョンのリリースのスケジュールを独立して制御できるため、反復を実行できるようになり、サービスコードが改善されます。



最後に、マイクロサービスに分割すると、スケーラビリティが向上します。 各コンポーネントは個別のサービスに割り当てられるため、他のコンポーネントとは独立してスケーリングできます

（ロシア語翻訳の79-80ページ）



バーンズ自身が認めているように、マイクロサービスシステムを設計し、そのアーキテクチャを設計することは難しいため、私は「夢」について話している。 そして、そのようなシステムの監視とデバッグは、モノリシックなアナログの監視とデバッグよりもはるかに複雑です。 これだけで簡単に同意できます。 マイクロサービスでの私自身の限られた経験から、共有サービスが急速に高度に接続されるようになり、サービス間の「信頼できる契約」が急速に動いているターゲットに変わり、ますます多くの新しい変更が行われていることを確認しています。



結論として、FaaSの概念である「サービスとしての機能」に触れたいと思います。 AmazonのLambda Serviceのようなシステムは、私を混乱させます。 非常に抽象的な意味で、私はそのようなシステムが好きですが、それらが特定のアプリケーションでどのように現れるのか分かりません。 Burnsは、「サービングシステムの設計パターン」のパートIIでFaaSに触れていますが、残念ながら、私にとってFaasの問題を完全には明らかにしていません。



Burnsは、FaaSを使用して既知の問題のサブセットのみを解決することを推奨していることを本当に気に入っています。

分散システムを開発するための他のツールと同様に、特定のソリューション（イベント指向処理など）を汎用ツールとして使用することもできます。 真実は、通常、特定のソリューションが特定の問題を解決するということです。 特定のコンテキストでは、強力なツールであることが証明されますが、耳で引っ張って一般的な問題を解決すると、複雑で脆弱なアーキテクチャが発生します。

（p。135ロシア語翻訳）



さらに、FaaSを使用するときに生じる困難について言及してくれた彼に感謝します。

前のセクションで述べたように、FaaSアプローチを使用したシステム開発では、システムコンポーネントを疎結合にする必要があります。 各機能は定義により独立しています。 すべての対話はネットワークを介して実行されます。 関数インスタンスには独自のメモリがないため、状態を保存するための共通ストアが必要です。 システム要素の接続を強制的に弱めると、サービス開発の柔軟性と速度が向上しますが、同時にそのサポートが大幅に複雑になる可能性があります。

特に、サービスの包括的な構造を確認したり、機能が互いにどのように統合されているかを判断したり、障害が発生した場合に何がなぜ失敗したのかを把握したりすることは非常に困難です。 さらに、関数のクエリ指向でサーバーレスの性質は、いくつかの問題を検出するのが難しいことを意味します。

（ロシア語訳のp.136-137）



繰り返しになりますが、ほとんどのFaaSシステムは、アクティブな処理を必要とするタスクを解決するにはあまり良くないという事実に驚きました。

...さらに、サービスのサーバーレス実装のため、関数インスタンスの実行時間は通常制限されます。 つまり、FaaSアプローチは通常、バックグラウンドの長時間のデータ処理を必要とするアプリケーションには適していません。 （ロシア語訳のP.138）

最後に、プロセッサの長時間連続した動作を保証することが不可能な場合、FaaSが経済的に不便になっているという発言に満足しました。

ただし、機能が常にアクティブになるほど多くのリクエストがある場合、処理されたリクエストの数を超過する可能性があります。



...サービスが拡大するにつれて、処理されるリクエストの数は、プロセッサが常にそれらの処理でビジー状態になるほどのレベルまで増加します。 この時点で、リクエスト数に対する料金が不採算になり始めます。 クラウド仮想マシンのプロセッサ時間の単位あたりのコストは、コアを追加するとともに、長期使用のためにリソースと割引を予約することにより削減されます。 通常、リクエストの数に対して支払うコストは、リクエストの数とともに増加します。

（ロシア語翻訳の139-140ページ）



その結果、私はまだ理解していませんでした：「サービスとしての機能」を使用する方が良いのはいつですか？ Burnsでは、2要素認証（2FA）など、プロセッサに大きな負荷をかけないイベント指向の短期タスクの操作について簡単に説明しています。 しかし、低コストで小さな短期タスクについて話していることを考えると、疑問が生じます。なぜそれらを独立してスケーリングする必要があるのでしょうか？ これらの機能を最初のコンテナサービスに密接に関連する別のコンテナサービスに含めるだけではどうですか？



実際にFaaSテクノロジーを使用するようになったら、これらの問題をより適切に処理したいと考えています。



FaaSとの混乱を除けば、この本は本当に気に入りました。 高速で読みやすい。 アプリケーション開発のすべてのレベルでコンポーネント間の接続を弱体化させる大きな可能性を改めて思い起こさせます。 最後に、「サイドカーコンテナー」などのトピックに関する同僚との会話を簡単に維持できるようになりました。