簡単なアーキテクチャパターンの変遷の階層構造からマイクロサービスアーキテクチャへ
6139 ワード
前言
ソフトウェアシステムの設計の方法論といえば、コードの面では、私たちがよく知っている23種類のデザインパターンがあり、アーキテクチャの面に対応すると、いわゆるアーキテクチャパターンがあります。それらはそれぞれミクロとマクロの観点から優れたソフトウェアシステムを設計するように指導しています。そのため、ソフトウェアエンジニアとして、設計モードを熟知するだけでなく、よくあるアーキテクチャモデルに対してもよく知っています。デザインモードの名前を見ていると、大体の構造図が頭に浮かびます。アーキテクチャモードの名前を見たら、すぐに対応するアーキテクチャ図と基本的な特徴を思い出します。例えば、階層構造については、どのようなアーキテクチャがどのように構成されているか、どのような優れたアーキテクチャ特徴があるか、システムがどのように配置されているか、データストアのポリシーがどのようなものか、などを思い出すべきである。
一般的には、アーキテクチャパターンは大きく2つの種類に分けられ、モノマーアーキテクチャと分散アーキテクチャに分けられる。このシリーズの記事では、以下の8つの一般的なアーキテクチャパターンを紹介します。
単体アーキテクチャ
階層構造（Layered architecture）
パイプラインアーキテクチャ（Pipeline architecture）
マイクロコアアーキテクチャ（Microkernel architecture）
分散アーキテクチャ
サービスに基づくアーキテクチャ（Service-based architecture）
イベント駆動アーキテクチャ（Event-driven architecture）
空間ベースのアーキテクチャ（Space-based architecture）
サービス向けのアーキテクチャ（Service-orented architecture）
マイクロサービスアーキテクチャ（Microsoft vices architecture）
ソフトウェア設計の誤り
アーキテクチャモードを紹介する前に、まずソフトウェア設計の誤り（fallacy）について話します。誤謬とは、ソフトウェアシステムを設計する時、特に分散システムを設計する時、私達は先入観でそれらが正しいと仮定していますが、実際にはこのようないくつかの観念ではありません。これらの観念はすべて私達がソフトウェアを設計する時考慮しきれない体現です。
誤り1：ネットは信頼できるものです。
ネットは頼りないです。
多くのソフトウェアエンジニアはしばしばネットワークが信頼できると仮定していますが、実際にはそうではありません。20年前に比べて、今のネットは信頼性が高いですが、まだ大きな不確実性があります。上記のように、Serivce Bは完全に正常に動作しているかもしれないが、ネットワークの問題でService Aからの要求はService Bに到達しない。より悪いシーンは、Service BがService Aの要求を受信し、関連データを処理することができるが、ネットワークの問題はService AがService Bの応答を受信できなくなり、データが一致しないことをもたらす。ネットワークの信頼性が低いのも、サービス通信のタイムアウトやサービスの溶断などの原因が多いからです。
要するに、もしネットが信頼できると仮定したら、私達が設計したソフトウェアシステムは信頼できないです。
エラー2：遅延は0です
遅延は0ではない
上の図に示すように、サービス内のコンポーネント間の関数／方法レベルの呼び出しは、時間消費はマイクロ秒、さらにはナノ秒レベルである。しかし、サービス間のリモート呼び出し（例えば、REST、メッセージキュー、RPC）は、時間がかかりミリ秒レベル、さらには異常シーンでは秒レベルに達します。設計システムでは、特に分散システムの場合、遅延は無視できない要素であり、システムの平均遅延を明確にしなければならない。例えば、システムにおけるサービス間通信の遅延が100 msであると仮定し、要求された起動チェーンが10のサービスに関連している場合、その要求の待ち時間は1000 msである。このような平均遅延は一般システムにとっては全く受け入れられません。
システム設計をする時、平均遅延がまだ足りないと考えて、もっと重要なのは95 thと99 thポイントです。一つのシステムの平均遅延は数十ミリ秒しかないかもしれませんが、95 thポイントの遅延は数百ミリ秒に達しています。多くの場合、これはちょうどシステムの性能を崩す「ショートボード」になります。
エラー3：帯域幅は無限です。
帯域幅は限られています
単一体アーキテクチャでは、トラフィックフローは単一サービス内で閉ループし、消費帯域幅は少なく、ひいては0であるので、帯域幅は主要な注目点ではない。システムを構成要素布式アーキテクチャに分割すると、1つのトラフィックフローは、複数のサービス間の通信を含み、帯域幅は考慮されるべき要因となる。帯域幅が足りないと、ネットワークが遅くなり、システムの遅延（エラー2：遅延は0）と信頼性（エラー1：ネットワークは信頼できる）に影響を与えます。
上の図に示すように、Service Aはフロントエンド要求の処理を担当していると仮定し、Service Bはユーザ情報（名前、性別、年齢など45の属性を含む）の管理を担当している。Service Aは、一つの要求を処理するたびに、ユーザー名（200 bytes）をService Bに問い合わせる必要がありますが、一回の要求では、Service Bはユーザのすべての情報（500 kb）を返します。システムが毎秒2000回の要求を処理すると、要求毎に500 kbの帯域幅が消費され、毎秒消費される総帯域幅は1 Gbになる。Service Bが必要な名前だけを返すと、同じ条件では、毎秒消費する総帯域幅は400 kbにすぎない。
このような問題はいわゆるstamp coupllingであり、解決方法も多く、例えば要求に属性選択を追加し、RESTの代わりにGraphQLを使用する。これらの技術的手段に比べて、サービス間通信に必要な最小データセットを決定し、システム設計を行う際に重要な関心を持つ要素とする。
誤り4：インターネットは安全です。
インターネットは安全ではないです。
VPN、ファイアウォールなどの広く使われているので、多くのエンジニアがシステムを設計する時に「ネットワークは安全ではない」という重要な原則を見落としました。特に、単体アーキテクチャから分散アーキテクチャに進化すると、システムが攻撃される確率が大きく増加します。したがって、分散システムでは、各サービスは安全なendpointでなければならない。これによって、未知または悪意のある要求がブロックされることを確実にすることができる。もちろん、安全は有料であり、これもマイクロサービスアーキテクチャのような微細サービス粒度のシステムであり、一回の業務要求でチェーンが長すぎると性能が急激に低下する重要な原因である。
誤り5：ネットワークトポロジは不変です。
ネットワークトポロジは常に変化します。
ここのネットワークトポロジとは、システムの実行時に関連するネットワークデバイスを指し、ルータ、ファイアウォール、ハブ、スイッチなどを含む。多くのエンジニアはネットワークトポロジが固定されていると仮定しますが、そうではありません。
もし次のような場面があるとして、構築者のあなたが月曜日の朝に会社に戻ってきたら、グループ内の同僚はシステム中のすべてのサービス間通信に絶えず応答タイムアウト現象が発生しています。数時間の通関後、月曜日の午前2時にネットのアップグレードがありました。今回の「セカンド」のアップグレードは、以前の設計システムの遅延仮説を覆すことによって、今回の事故を引き起こしました。
そのため、ソフトウェアエンジニアもネットワーク管理者と常に連絡して、アップグレードするたびにネットワークトポロジの変更点を明確にして、対応する調整を行う必要があります。
エラー6：ネットワーク管理者は一人しかいません。
ネットワーク管理者は一人だけではありません。
ネット管理者は一つだけではなく、特に「雲」の時代には、データセンターが複数の地域に分散しています。当然、複数のローカルエリアも存在します。「クラウド」上で動作するシステムは複数のデータセンターを越える可能性が高いので、エンジニア達は各データセンターのネットワーク管理者がネットワークに関する操作を感知し、事前に対応し、ネットワークトポロジの変更（誤謬5：ネットワークトポロジの1割が不変）によるサービス通信のタイムアウトを回避し、さらにサービスの溶断をトリガしなければならない。
誤り7：通信コストは0
通信コストは0ではない
ここでの通信コストは、ネットワークの遅延を意味するのではなく、サービス間の呼び出しが増加するたびに生じるお金の消費を意味する。多くのエンジニアはシステムを設計する時、通信コストを軽視しています。みんなは分散アーキテクチャを宣伝して、単体アーキテクチャの優越性に対して、それが持ってきたサーバー、ファイアウォール、ゲートウェイなどのハードウェアの数が増加したことを忘れました。
したがって、システム設計を行う際には、ハードウェアリソースとネットワークトポロジを考慮要素に組み入れるべきである。
誤り8：ネットは同質です。
ネットワークは同質ではありません。
多くのエンジニアは、ネットワークが同質であると仮定しています。つまり、すべてのネットワークデバイスは同じハードウェアメーカーから来ています。これも間違いです。実際には、大きな通信ネットワークでは、ハードウェアデバイスは、ネットワークプロトコル標準の統一のおかげで、異なるメーカーから頻繁に生まれています。メーカー間の設備の連携テストは結局十分ではないので、いくつかの特殊な場面では、ネットワークの信頼性に影響を与える可能性が高いです。（エラー1：ネットワークは信頼性があります。）、遅延（エラー2：遅延は0です。）及び帯域幅（エラー3：帯域幅は無限です。）。
すべては「泥球」から始まります。
「大泥球」アーキテクチャ
「大泥球」の構造は有名な反モード構造で、最初は1997年にBrian FooteとJoseph Yoderによって提出されました。「大泥球」アーキテクチャでは、システムは内部モジュールの区分を行わず、コードの結合が激しく、大きな泥球のように関係が乱れて呼び出されます。上の図に示すように、各点はクラスを表し、赤い線はクラス間の結合関係を表します。このようなアーキテクチャは需要の変更に対して極めて友好的ではなく、往々にして引っ张って全身を动かし、しかも配置、テスト性、性能などの面でも多くの问题が存在している。すべての架設師は「泥の玉」の出現を極力避けていますが、残念なことに、まだ実際のプロジェクトでよく見られています。特にプロジェクトの始めに、コードの品質と構造はまだ厳しく管理されていません。
逆モードの出現によって、必然的にその解決方法があります。これはアーキテクチャモードです。次の記事から、一般的な8つのアーキテクチャパターンを紹介します。
締め括りをつける
デザインモードと似ています。アーキテクチャモードはソフトウェアエンジニアたちが長年にわたってアーキテクチャ設計に関する経験をまとめたものです。各アーキテクチャモードには絶対的な優劣の区別はなく、マイクロサービスアーキテクチャは単体階層構造よりも優れているとは言えません。それぞれのアプリケーションシーンがあります。分散型アーキテクチャは、単体アーキテクチャよりも、より良い拡張性、フォールト性を持っていますが、分散型事務など、より高い複雑性をもたらしています。したがって、特定のビジネスシーンで適切なアーキテクチャパターンを使用することができるように、各アーキテクチャモードの特徴を熟知しなければならない。
以上は、階層構造からマイクロサービスアーキテクチャまでの詳細な内容を簡単に述べたもので、より多くのアーキテクチャパターンの変遷に関する階層構造からマイクロサービスアーキテクチャまでの資料は他の関連記事に注目してください。
ソフトウェアシステムの設計の方法論といえば、コードの面では、私たちがよく知っている23種類のデザインパターンがあり、アーキテクチャの面に対応すると、いわゆるアーキテクチャパターンがあります。それらはそれぞれミクロとマクロの観点から優れたソフトウェアシステムを設計するように指導しています。そのため、ソフトウェアエンジニアとして、設計モードを熟知するだけでなく、よくあるアーキテクチャモデルに対してもよく知っています。デザインモードの名前を見ていると、大体の構造図が頭に浮かびます。アーキテクチャモードの名前を見たら、すぐに対応するアーキテクチャ図と基本的な特徴を思い出します。例えば、階層構造については、どのようなアーキテクチャがどのように構成されているか、どのような優れたアーキテクチャ特徴があるか、システムがどのように配置されているか、データストアのポリシーがどのようなものか、などを思い出すべきである。
一般的には、アーキテクチャパターンは大きく2つの種類に分けられ、モノマーアーキテクチャと分散アーキテクチャに分けられる。このシリーズの記事では、以下の8つの一般的なアーキテクチャパターンを紹介します。
単体アーキテクチャ
階層構造（Layered architecture）
パイプラインアーキテクチャ（Pipeline architecture）
マイクロコアアーキテクチャ（Microkernel architecture）
分散アーキテクチャ
サービスに基づくアーキテクチャ（Service-based architecture）
イベント駆動アーキテクチャ（Event-driven architecture）
空間ベースのアーキテクチャ（Space-based architecture）
サービス向けのアーキテクチャ（Service-orented architecture）
マイクロサービスアーキテクチャ（Microsoft vices architecture）
ソフトウェア設計の誤り
アーキテクチャモードを紹介する前に、まずソフトウェア設計の誤り（fallacy）について話します。誤謬とは、ソフトウェアシステムを設計する時、特に分散システムを設計する時、私達は先入観でそれらが正しいと仮定していますが、実際にはこのようないくつかの観念ではありません。これらの観念はすべて私達がソフトウェアを設計する時考慮しきれない体現です。
誤り1：ネットは信頼できるものです。
ネットは頼りないです。
多くのソフトウェアエンジニアはしばしばネットワークが信頼できると仮定していますが、実際にはそうではありません。20年前に比べて、今のネットは信頼性が高いですが、まだ大きな不確実性があります。上記のように、Serivce Bは完全に正常に動作しているかもしれないが、ネットワークの問題でService Aからの要求はService Bに到達しない。より悪いシーンは、Service BがService Aの要求を受信し、関連データを処理することができるが、ネットワークの問題はService AがService Bの応答を受信できなくなり、データが一致しないことをもたらす。ネットワークの信頼性が低いのも、サービス通信のタイムアウトやサービスの溶断などの原因が多いからです。
要するに、もしネットが信頼できると仮定したら、私達が設計したソフトウェアシステムは信頼できないです。
エラー2：遅延は0です
遅延は0ではない
上の図に示すように、サービス内のコンポーネント間の関数／方法レベルの呼び出しは、時間消費はマイクロ秒、さらにはナノ秒レベルである。しかし、サービス間のリモート呼び出し（例えば、REST、メッセージキュー、RPC）は、時間がかかりミリ秒レベル、さらには異常シーンでは秒レベルに達します。設計システムでは、特に分散システムの場合、遅延は無視できない要素であり、システムの平均遅延を明確にしなければならない。例えば、システムにおけるサービス間通信の遅延が100 msであると仮定し、要求された起動チェーンが10のサービスに関連している場合、その要求の待ち時間は1000 msである。このような平均遅延は一般システムにとっては全く受け入れられません。
システム設計をする時、平均遅延がまだ足りないと考えて、もっと重要なのは95 thと99 thポイントです。一つのシステムの平均遅延は数十ミリ秒しかないかもしれませんが、95 thポイントの遅延は数百ミリ秒に達しています。多くの場合、これはちょうどシステムの性能を崩す「ショートボード」になります。
エラー3：帯域幅は無限です。
帯域幅は限られています
単一体アーキテクチャでは、トラフィックフローは単一サービス内で閉ループし、消費帯域幅は少なく、ひいては0であるので、帯域幅は主要な注目点ではない。システムを構成要素布式アーキテクチャに分割すると、1つのトラフィックフローは、複数のサービス間の通信を含み、帯域幅は考慮されるべき要因となる。帯域幅が足りないと、ネットワークが遅くなり、システムの遅延（エラー2：遅延は0）と信頼性（エラー1：ネットワークは信頼できる）に影響を与えます。
上の図に示すように、Service Aはフロントエンド要求の処理を担当していると仮定し、Service Bはユーザ情報（名前、性別、年齢など45の属性を含む）の管理を担当している。Service Aは、一つの要求を処理するたびに、ユーザー名（200 bytes）をService Bに問い合わせる必要がありますが、一回の要求では、Service Bはユーザのすべての情報（500 kb）を返します。システムが毎秒2000回の要求を処理すると、要求毎に500 kbの帯域幅が消費され、毎秒消費される総帯域幅は1 Gbになる。Service Bが必要な名前だけを返すと、同じ条件では、毎秒消費する総帯域幅は400 kbにすぎない。
このような問題はいわゆるstamp coupllingであり、解決方法も多く、例えば要求に属性選択を追加し、RESTの代わりにGraphQLを使用する。これらの技術的手段に比べて、サービス間通信に必要な最小データセットを決定し、システム設計を行う際に重要な関心を持つ要素とする。
誤り4：インターネットは安全です。
インターネットは安全ではないです。
VPN、ファイアウォールなどの広く使われているので、多くのエンジニアがシステムを設計する時に「ネットワークは安全ではない」という重要な原則を見落としました。特に、単体アーキテクチャから分散アーキテクチャに進化すると、システムが攻撃される確率が大きく増加します。したがって、分散システムでは、各サービスは安全なendpointでなければならない。これによって、未知または悪意のある要求がブロックされることを確実にすることができる。もちろん、安全は有料であり、これもマイクロサービスアーキテクチャのような微細サービス粒度のシステムであり、一回の業務要求でチェーンが長すぎると性能が急激に低下する重要な原因である。
誤り5：ネットワークトポロジは不変です。
ネットワークトポロジは常に変化します。
ここのネットワークトポロジとは、システムの実行時に関連するネットワークデバイスを指し、ルータ、ファイアウォール、ハブ、スイッチなどを含む。多くのエンジニアはネットワークトポロジが固定されていると仮定しますが、そうではありません。
もし次のような場面があるとして、構築者のあなたが月曜日の朝に会社に戻ってきたら、グループ内の同僚はシステム中のすべてのサービス間通信に絶えず応答タイムアウト現象が発生しています。数時間の通関後、月曜日の午前2時にネットのアップグレードがありました。今回の「セカンド」のアップグレードは、以前の設計システムの遅延仮説を覆すことによって、今回の事故を引き起こしました。
そのため、ソフトウェアエンジニアもネットワーク管理者と常に連絡して、アップグレードするたびにネットワークトポロジの変更点を明確にして、対応する調整を行う必要があります。
エラー6：ネットワーク管理者は一人しかいません。
ネットワーク管理者は一人だけではありません。
ネット管理者は一つだけではなく、特に「雲」の時代には、データセンターが複数の地域に分散しています。当然、複数のローカルエリアも存在します。「クラウド」上で動作するシステムは複数のデータセンターを越える可能性が高いので、エンジニア達は各データセンターのネットワーク管理者がネットワークに関する操作を感知し、事前に対応し、ネットワークトポロジの変更（誤謬5：ネットワークトポロジの1割が不変）によるサービス通信のタイムアウトを回避し、さらにサービスの溶断をトリガしなければならない。
誤り7：通信コストは0
通信コストは0ではない
ここでの通信コストは、ネットワークの遅延を意味するのではなく、サービス間の呼び出しが増加するたびに生じるお金の消費を意味する。多くのエンジニアはシステムを設計する時、通信コストを軽視しています。みんなは分散アーキテクチャを宣伝して、単体アーキテクチャの優越性に対して、それが持ってきたサーバー、ファイアウォール、ゲートウェイなどのハードウェアの数が増加したことを忘れました。
したがって、システム設計を行う際には、ハードウェアリソースとネットワークトポロジを考慮要素に組み入れるべきである。
誤り8：ネットは同質です。
ネットワークは同質ではありません。
多くのエンジニアは、ネットワークが同質であると仮定しています。つまり、すべてのネットワークデバイスは同じハードウェアメーカーから来ています。これも間違いです。実際には、大きな通信ネットワークでは、ハードウェアデバイスは、ネットワークプロトコル標準の統一のおかげで、異なるメーカーから頻繁に生まれています。メーカー間の設備の連携テストは結局十分ではないので、いくつかの特殊な場面では、ネットワークの信頼性に影響を与える可能性が高いです。（エラー1：ネットワークは信頼性があります。）、遅延（エラー2：遅延は0です。）及び帯域幅（エラー3：帯域幅は無限です。）。
すべては「泥球」から始まります。
「大泥球」アーキテクチャ
「大泥球」の構造は有名な反モード構造で、最初は1997年にBrian FooteとJoseph Yoderによって提出されました。「大泥球」アーキテクチャでは、システムは内部モジュールの区分を行わず、コードの結合が激しく、大きな泥球のように関係が乱れて呼び出されます。上の図に示すように、各点はクラスを表し、赤い線はクラス間の結合関係を表します。このようなアーキテクチャは需要の変更に対して極めて友好的ではなく、往々にして引っ张って全身を动かし、しかも配置、テスト性、性能などの面でも多くの问题が存在している。すべての架設師は「泥の玉」の出現を極力避けていますが、残念なことに、まだ実際のプロジェクトでよく見られています。特にプロジェクトの始めに、コードの品質と構造はまだ厳しく管理されていません。
逆モードの出現によって、必然的にその解決方法があります。これはアーキテクチャモードです。次の記事から、一般的な8つのアーキテクチャパターンを紹介します。
締め括りをつける
デザインモードと似ています。アーキテクチャモードはソフトウェアエンジニアたちが長年にわたってアーキテクチャ設計に関する経験をまとめたものです。各アーキテクチャモードには絶対的な優劣の区別はなく、マイクロサービスアーキテクチャは単体階層構造よりも優れているとは言えません。それぞれのアプリケーションシーンがあります。分散型アーキテクチャは、単体アーキテクチャよりも、より良い拡張性、フォールト性を持っていますが、分散型事務など、より高い複雑性をもたらしています。したがって、特定のビジネスシーンで適切なアーキテクチャパターンを使用することができるように、各アーキテクチャモードの特徴を熟知しなければならない。
以上は、階層構造からマイクロサービスアーキテクチャまでの詳細な内容を簡単に述べたもので、より多くのアーキテクチャパターンの変遷に関する階層構造からマイクロサービスアーキテクチャまでの資料は他の関連記事に注目してください。