SOA、マイクロサービス、サーバーレス アーキテクチャ

この記事の転載場所:分散ソフトウェア アーキテクチャ - SOA アーキテクチャ / マイクロサービス アーキテクチャ / サーバーレス アーキテクチャ

記録のためにのみ。

---

SOAアーキテクチャ

サービス指向アーキテクチャ、サービス指向アーキテクチャ。サービス指向アーキテクチャは、分散サービスの主な問題を具体的かつ体系的な方法で解決するアーキテクチャ パターンです。SOA アーキテクチャを理解する前に、サービス分割の 3 つの代表的なアーキテクチャ パターンを理解してください。これらのアーキテクチャ パターンは、SOA進化プロセスの中間生成物であり、SOA アーキテクチャの出現に必要な前提条件です。

煙突アーキテクチャ (情報サイロ アーキテクチャ)

情報チムニーは情報アイランドとも呼ばれ、このアーキテクチャを使用したシステムは、孤立した情報システムまたはチムニー情報システムとも呼ばれます。これは、他の関連情報システムとの相互運用や調和がまったく行われない設計パターンを指します。このようなシステムには、実際には「アーキテクチャ設計」がまったくありません。前のセクションの企業と部門の例に続いて、2 つの部門が実際にまったく対話しない場合、強制的に同じ建物内で作業する理由はありません。対話しない 2 つの情報システムを使用させます。しかし、唯一の問題、そして致命的な問題は、社内にまったく対話しない部門が本当に存在するのかということです。２つの情報システムは、実際には取引関係がないとしても、人事、組織、権限などのシステムのマスターデータは重複することなく完全に独立しているのでしょうか？このような「独立分割」および「独立」システムは、企業が望むことは明らかに不可能です。

マイクロカーネルアーキテクチャ

マイクロカーネル アーキテクチャは、プラグイン アーキテクチャ (プラグイン アーキテクチャ) とも呼ばれます。チムニー アーキテクチャでは、ビジネス関係のないシステムでも、人員、組織、権限などの一部のパブリック マスター データを共有する必要がある場合があるため、これらのマスター データを、さまざまな企業が使用する可能性のある他のパブリック サービスと一緒に使用することをお勧めします。サブシステム、データ、リソースが集まってコア (カーネル、コア システムとも呼ばれる) となり、すべてのビジネス システムが共通に依存します。特定のビジネス システムはプラグイン モジュール (プラグイン モジュール) の形で存在します。拡張され、柔軟で、自然に分離された機能特性、つまりマイクロカーネル アーキテクチャを図に示します。

このパターンはデスクトップ アプリケーションに適しており、Web アプリケーションでもよく使用されます。コンピュータシステムは、さまざまなソフトウェアが連携して特定の機能を実現することで実現されていますが、ここで挙げたさまざまなアーキテクチャで実現されるソフトウェアは、システム全体の一種のプラグインとみなすことができます。プラットフォーム アプリケーションの場合、システムに新しい機能をタイムリーに追加したい場合は、マイクロカーネル アーキテクチャが優れたソリューションになります。マイクロカーネル アーキテクチャは、他のアーキテクチャ モデルに埋め込むこともでき、プラグインを通じて新しい機能のカスタマイズされた開発機能を提供することもできます。二次開発をサポートできるソフトウェア システムを実装する予定がある場合は、マイクロカーネルも適切な選択となります。ただし、マイクロカーネル アーキテクチャにも制限と前提条件があり、システム内のプラグイン モジュールがお互いを知らないことを前提としており、どのモジュールがシステムにインストールされるかは予測できません。そのため、これらのプラグインはアクセスできます。カーネル内の一部のパブリック リソースですが、直接対話することはありません。しかし、企業情報システムであれ、インターネット アプリケーションであれ、多くのシナリオではこの前提が当てはまらないため、独立したシステムを分割するだけでなく、分割されたサブシステム間でスムーズな通信を可能にする方法を見つける必要があります。コミュニケーションをとること。

イベント駆動型アーキテクチャ (イベント駆動型アーキテクチャ)

サブシステムが相互に通信できるようにするための実現可能な解決策は、サブシステム間に一連のイベント キュー パイプライン (イベント キュー) を確立することです。システムの外部からのメッセージは、イベントの形式でパイプラインに送信されます。イベントを取得します。また、イベントの追加情報を追加または変更したり、新しいイベントを自分でパイプライン キューに発行したりすることもできます。このようにして、各メッセージのプロセッサは独立しており、高度に分離されています。ただし、図に示すように、イベント パイプラインを通じて他のハンドラーと対話することはできます (メッセージ ハンドラーが存在する場合)。

SOA アーキテクチャ時代の探求

SOA の概念は、1994 年に Gartner によって初めて提案されました。当時、SOA は開発の条件が整っていませんでした。状況が変化したのは 2006 年になってからでした。IBM、Oracle、SAP などの企業が共同で OSOA Alliance (オープン) を設立しました。サービス指向アーキテクチャ)。SOA 関連の業界標準を共同で策定および推進するために使用されます。2007 年、構造化情報標準推進機構 (OASIS) の主導と支援のもと、OSOA はソフトウェア ベンダーの緩やかな同盟から業界標準を設定する国際組織に変わりました。新しく設立された Open CSA 組織 (Open Composite Services Architecture) は、SOA の正式な管理組織です。

ソフトウェア アーキテクチャは SOA 時代を迎えており、サービス間の疎結合、登録、検出、ガバナンス、分離、オーケストレーションなど、多くの概念やアイデアが今日のマイクロサービスですでに見られます。今日のマイクロサービスにおけるこれらのよく知られた名詞概念のほとんどは、分散サービスが最初に提案されたときにも予見できた困難でした。SOA は、これらの問題、さらには「ソフトウェア開発」自体の問題について、より体系的かつ具体的な調査を実行しました。

1. より具体的な
   「より具体的な」とは、SOA 自体がまだ具体的な技術ではなく抽象的な概念であるにもかかわらず、単一のアーキテクチャや上記の 3 つのアーキテクチャ モデルよりも操作性が高く、単純にアーキテクチャ スタイルとして捉えることができないことを表しています。ソフトウェア設計の基本プラットフォームとも言えます。技術標準の開発を主導する組織である Open CSA があり、サービスのカプセル化、自律性、疎結合、再利用性、構成可能性、ステートレス性などのソフトウェア設計の明確な指針があり、プロトコルは SOAP プロトコルに依存しています。サービスの公開、検出、および管理を完了するためのファミリー (WSDL、UDDI、および多数の WS-* プロトコル)、エンタープライズ サービス バス (エンタープライズ サービス バス、ESB) と呼ばれるメッセージ パイプラインを使用した各サブシステム間の通信と対話の実装ESB スケジューリングに基づいてサービスが相互依存せずに相互に通信できるようにし、疎結合サービスの利点をもたらすだけでなく、将来のビジネス プロセス管理 (BPM) のさらなる実装を促進します。基盤を提供します。サービス データ オブジェクトを使用します (サービス データ オブジェクト (SDO) を使用してデータにアクセスして表現し、サービス コンポーネント アーキテクチャ (サービス コンポーネント アーキテクチャ、SCA) を使用してサービスのカプセル化の形式やサービスが実行されるコンテナなどを定義します。互いに密接に連携できるこの一連の技術コンポーネントのサポートにより、技術的な実現可能性の観点からのみ判断した場合、SOA は分散環境における主要な技術的問題を首尾よく解決すると見なすことができます。

2. より体系的
   「より体系的」とは、SOA の壮大な理想を指します。その最終目標は、一連のトップダウンのソフトウェア開発方法論を要約することであり、企業がこの考え方に従うだけで、パッケージ内のソフトウェアの問題を解決できることを期待しています。 SOA: 要件を掘り出す方法、要件をビジネス機能に分解する方法、既存のサービスを調整する方法、新しい機能を開発、テスト、展開する方法など、開発プロセスにおけるすべての問題。技術的な問題は確かに重要で難しいものですが、それらはそのうちの 1 つにすぎません。SOA は技術だけでなく、要件、管理、プロセス、研究開発プロセスに関わる組織にも焦点を当てます。この目標が本当に達成できれば、ソフトウェア開発は工業化された大量生産の段階に入るかもしれません。顧客のニーズを満たすソフトウェアを作成する日が、型にはまったエッセイを作成するのと同じくらい追跡可能で法に基づいたものになる日が来ることを想像してみてください。ソフトウェア開発者にとっては退屈かもしれません。 、しかし、社会全体の情報化の導入効率は間違いなく大幅に向上します。

SOA は 21 世紀の最初の 10 年間にかつて流行し、IBM などの多くの業界大手が SOA を叫び、多くのソフトウェア開発者、特にエンタープライズ レベルのソフトウェア開発者を引きつけましたが、最終的には下火になり、沈黙してしまいました。リモート サービス呼び出しの後のセクションで、著者は、SOAP プロトコルが徐々に疎外されていく本質的な理由について言及します。それは、厳密すぎる仕様定義が過度の複雑さをもたらすことです。そして、SOAP に基づいて構築された ESB、BPM、SCA、SDO などの多くの上部構造が、この複雑さをさらに悪化させています。結局のところ、情報システムの開発は定型的な記事ではなく、過度に洗練されたプロセスや理論を制御するには、複雑な概念を理解する専門家も必要となります。SOA は誕生した当初から、少数のシステムの贅沢なものとなる運命にあり、複数の異種大規模システム間の複雑な統合と相互作用を実現できますが、広く適用可能なシステムとして使用することは困難です。ソフトウェアアーキテクチャスタイル。SOA が最終的に失敗するという致命的な欠陥は当時のEJB とまったく同じであり、 EJB は Sun Microsystems や IBM などの巨人の支援にもかかわらず、依然として Spring や Hibernate に代表される「草の根フレームワーク」に敗北する可能性があります。一旦人々から切り離されると、やがて大衆の海に沈んでしまうのが目に見えていますが、それは情報技術であっても例外ではありません。

これを読んだ後は、「複数の独立した分散サービスを使用して、より大きなシステムを共同で構築するにはどうすればよいか」という問いを思い出し、Unix DCE が「元の分散時代」で提案した分散サービスの設計要点を思い出してください。 " : "開発者はサービスがリモートかローカルかを気にせず、透過的にサービスを呼び出したり、リソースにアクセスしたりできます。" 30 年間の技術進歩を経て、情報システムは、岩、煙突、プラグイン、イベント、SOA などのアーキテクチャ パターンを経験してきましたが、アプリケーションはアーキテクチャの複雑さによってますます妨げられており、「透明性」という言葉はますます遠ざかっています。 . どんどん遠くなっていくのですが、これは無意識に今年の初心を忘れているということでしょうか？私たちが次に話しているマイクロサービスの時代は、このような内省的な問いから幕を開けるように思えます。

マイクロサービスアーキテクチャ

実際、「マイクロサービス」という用語は、2005 年の Cloud Computing Expo (Web Services Edge 2005) で Peter Rodgers 博士によって提案され、使用されました。当時の用語は「マイクロ Web サービス」で、単一の責任に焦点を当て、言語に依存せず、粒度の細かい Web サービス (Granular Web Services) を指しました。「マイクロサービス」という用語は、Peter Rodgers によって何もないところから直接生み出された概念ではありません。Spring や Hibernate フレームワークが EJB の推進の中で生まれたように、初期のマイクロサービスは SOA の発展の中で生まれた製品であると言えます。現段階のマイクロサービスは、SOA に対する軽量な解決策として提案されています。現在でも、英語版の Wikipedia ではマイクロサービスを SOA の一種として定義しています。したがって、マイクロサービスがその誕生や開発の初期段階で SOA や Web サービスなどの概念に関与していることは十分に理解できます。

マイクロサービスとはマイクロサービスはソフトウェア開発手法であり、サービス指向アーキテクチャ (SOA) 構造スタイルの一種です。 — Wikipedia、マイクロサービス

しかし、今見てみると、Wikipedia のマイクロサービスの定義は実際には少し時代遅れです。マイクロサービスという概念が提唱されてからここ10年はあまり注目されておらず、既存のSOAアーキテクチャをいじるだけでは、技術者の熱意をさらに呼び起こすのは確かに難しい。しかし、ここ 10 年でマイクロサービス自体も考えられ、変化してきました。
2012年、ポーランドのクラクフで開催された「33rd Degree Conference」で、ThoughtworksのチーフコンサルタントであるJames Lewis氏は、「マイクロサービス - Java、Unix Way」と題した基調講演を行い、単一サービス責任、コンウェイの法則、自動拡張について言及しました。 、ドメイン駆動設計などの原理を主張しているが、SOAについては全く触れていないが、Unixの設計思想（As Well Behaved Unix Services）を取り戻すべきだと主張しており、これは前節で著者が述べたことと同じと思われる. 自省」という声が遠くから響く。マイクロサービスは、SOA の家臣から脱却し、独立したアーキテクチャ スタイルになることを待ち望んでおり、おそらく SOA の革命家でもあるでしょう。

マイクロサービスが本格的に台頭したのは 2014 年です。この記事を読んだほとんどの読者も、Martin Fowler と James Lewis の共著「マイクロサービス: この新しいアーキテクチャ用語の定義」という記事で初めてマイクロサービスについて学んだと思います。これは、この記事を読んでいる必要があるという意味ではありません。正確に言えば、今日あなたが知っている「マイクロサービス」が、この記事で提案されている「マイクロサービス」であるという意味ではありません。このペーパーでは、最新のマイクロサービスの概念が次のように定義されています。「マイクロサービスは、特定の技術標準ではなくビジネス機能を中心に構築された多数の小さなサービスの構成を通じて単一のアプリケーションを構築するためのアーキテクチャ スタイルです。個々のサービスは異なるプログラミング言語を使用できます」 「異なるデータ ストレージ テクノロジは異なるプロセスで実行されます。このサービスは、軽量な通信メカニズムと自動展開メカニズムを採用し、通信と運用保守を実現します。」さらに、記事ではマイクロサービスの中核となるビジネスおよび技術的特徴を 9 つ挙げていますが、著者はこれらを列挙し、次のように解釈しています。

1. ビジネス能力を中心に組織化 (ビジネス能力を中心に組織化)
   ここでは、コンウェイの法則の重要性を再度強調しています。どのような構造、規模、能力を持つチームでも、対応する構造、規模、能力を備えた製品が生産されます。この結論は、特定のチームや特定の企業が遭遇した偶然ではなく、進化の必然の結果です。同じ製品に属するべき機能が複数のチームに分かれている場合、必然的にチームを越えた大量のコミュニケーションやコラボレーションが発生し、チームの境界を越えると管理やコミュニケーション、作業調整などのコストが高くなります。チームは自然と改善され、チームとプロダクトが調整され安定すると、チームとプロダクトは一貫した構造になります。
2. 分散型ガバナンス（Decentralized Governance）
   「誰の子が担当するのか」という意味を表すもので、サービスに対応する開発チームはサービス運営の品質に直接責任を持ち、サービスのあらゆる側面をコントロールする権限も持つべきである。外部干渉のないサービス (独自のサービスを実装するために他のサービスと異種混合のテクノロジを選択するなど)。実際には、この点についてはある程度の余地があります。ほとんどの企業は、あるサービスに Java、別のサービスに Python、次のサービスに Golang を使用することはありません。通常、主流の言語を統一し、統一されたテクノロジー スタックさえ持っています。または独自のテクノロジー プラットフォームさえあります。マイクロサービスは、この種の「統合」を支持することも反対することもありません。基本的なテクノロジー スタックの提供と保守を担当するチームが、すべての関係者から信頼されているという意識を持ち、「頻繁に起こされる」という心の準備ができていなければなりません。午前3時に目覚まし時計」、いいですね。マイクロサービスは、技術的な異質性が本当に必要な場合、「不均一性」を選択する権利を持つべきであることをさらに強調しています。たとえば、Node.js はレポート ページの開発を強制されるべきではなく、人工知能を実行する場合は Python が選択できるべきです。計算などは待ちます。
3. サービスによるコンポーネント化が
   「ライブラリ」ではなく「サービス」を介してコンポーネントを構築することを強調する理由は、クラス ライブラリがコンパイル時にプログラムに静的にリンクされるためです。関数はローカル呼び出しを通じて提供されますが、サービスはプロセス外のコンポーネントであり、リモート呼び出しを通じて機能を提供します。前回の記事では、リモート サービスの呼び出しコストは高くなりますが、これはコンポーネントに分離性と自律性をもたらすために必要な代償であると分析しました。
4. 製品思考 (プロジェクトではなく製品) は、
   継続的な改善と改善のプロセスとしてのソフトウェア開発を回避します。たとえば、運用と保守は運用保守チームの仕事とみなされるべきではありませんが、開発は開発チームの仕事とみなされ、チームはソフトウェア製品のライフサイクル全体に責任を負う必要があります。ソフトウェアがどのように開発されるかを知っているだけでなく、それがどのように機能するか、ユーザーがどのようにフィードバックを提供するか、およびアフターサポート作業がどのように実行されるかについても知っています。ここでサービスを受けるユーザーは、必ずしもエンドユーザーであるとは限りませんが、このサービスを利用する別のサービスでもあります。従来、モノリシックアーキテクチャ下では、プログラムの規模からして全員が完成品に気を配ることは不可能で、開発、運用、保守など細かく分業していた組織内のメンバーと、サポートは自分たちの仕事だけに焦点を当てていましたが、マイクロサービスの下では、チームの全員がプロダクト思考を持っていることを期待することをお勧めします。
5. 分散型データ管理 (分散型データ管理)
   マイクロサービスは、データが分散型で管理、更新、保守、保存されるべきであることを明確に主張しています。単一のサービスでは、システムの各機能モジュールは通常、同じデータベースを使用します。ストレージは本質的に一貫性の問題を回避するのが簡単ですが、同じデータ エンティティの抽象形式は、異なるサービスの観点からは異なることがよくあります。例えば、書店アプリケーションの本は、販売フィールドでは価格、倉庫フィールドでは在庫数量、商品陳列フィールドでは書籍の紹介情報に注目し、集中ストレージとして利用する場合には、これらすべてのフィールドを表示します。すべてを変更して同じエンティティにマッピングする必要があるため、異なるサービスが相互に影響を及ぼし、独立性を失う可能性があります。分散環境で一貫性の問題に対処するのは非常に難しく、多くの場合、従来のトランザクション処理を使用して一貫性を保証することはできません。しかし、2 つの弊害のうち小さい方には、支払う価値のある必要なコストがいくつかあります。
6. スマート エンドポイントとダム パイプ (スマート エンドポイントとダム パイプ)
   弱いパイプ (ダム パイプ) は、SOAP や ESB の複雑な通信メカニズムと名前からほぼ真っ向から対立します。ESB はメッセージのエンコード処理、ビジネス ルールの変換などを処理できます。BPM は、エンタープライズ ビジネス サービスを一元的に調整するため、SOAP にはトランザクション、一貫性、認証、承認などの一連のタスクを処理する数十の WS-* プロトコル ファミリがあり、通信チャネル上に構築されたこれらの機能には、特定のシステムでいくつかのサービスが必要になる場合があります。しかし、それはより多くのサービスに対して課せられる負担です。サービスで上記の機能のいずれかが必要な場合は、通信チャネルでのオールインワン処理ではなく、サービス独自のエンドポイントで解決する必要があります。マイクロサービスは、従来の Unix フィルターに似たシンプルで直接的な通信方法を提唱しており、RESTful 通信はマイクロサービスにより適した選択肢です。
7. フォールトトレラント設計 (Design for Failure) は、
   もはやサービスの永続的な安定性を幻想的に追求するのではなく、サービスが常に失敗するという現実を受け入れます。マイクロサービスの設計には、迅速な障害検出のための自動メカニズムが必要です。エラーが継続する場合は分離し、サービスが復元されたら再接続します。したがって、「サーキットブレーカー」などの設備は、実際の本番環境におけるマイクロサービスのオプションの周辺コンポーネントではなく、必要なサポートポイントであり、フォールトトレラントな設計がされていない場合、1つまたは2つの雪崩によってシステムは簡単に損傷します。サービスの崩壊によってもたらされる影響は計り知れません。信頼性の高いシステムは、エラーが発生しやすいサービスだけで構成することができます。これがマイクロサービスの最大の価値であり、このオープンソース ドキュメントのタイトル「The Fenix Project」の意味でもあります。
8. 進化的設計 (進化的設計)
   フォールトトレラント設計はサービスが失敗することを認め、進化的設計はサービスが時代遅れになることを認めます。よく設計されたサービスは、長期間開発されることを期待するのではなく、廃棄できるはずです システムの中に、かけがえのないかけがえのないサービスがある場合、それはサービスの重要性を意味するのではなく、システムのパフォーマンスを意味します設計の脆弱性、マイクロサービスによってもたらされる独立性と自律性は、この脆弱性に対する反対の表れでもあります。
9. インフラストラクチャの自動化 (インフラストラクチャ オートメーション)
   CI/CD の迅速な開発などのインフラストラクチャの自動化により、構築、リリース、運用保守作業の複雑さが大幅に軽減されました。モノリシックアーキテクチャに比べて運用・保守すべきサービスの数が桁違いに増えるため、マイクロサービスを利用するチームはインフラの自動化への依存度が高く、人間が数十万、さらには数千のサービスを運用・保守することは不可能です。サービスの。

記事「マイクロサービス」のマイクロサービスの特性の説明は非常に具体的です。この記事では、マイクロサービスとは何かを定義するだけでなく、マイクロサービスではないものについても具体的に宣言しています。マイクロサービスは SOA の変形や派生ではなく、明確に定義する必要があります。 SOA と明確な線を引き、SOA にラベルを付ける必要はありません。このように、マイクロサービスの概念は、真にふくよかで独立した具体的なアーキテクチャ スタイルとみなすことができ、今後数年間でテクノロジーの舞台で星のように輝くための理論的基盤を築きます。

マイクロサービスと SOA
このような SOA の共通の現れにより、一部のマイクロサービス支持者は SOA というラベルを完全に拒否するようになりましたが、マイクロサービスを SOA の 1 つの形式と考え、おそらくサービス指向は正しく行われていると考える人もいます。このアーキテクチャ スタイルをより明確に定義する用語があることは貴重です
。この用語は SOA と一貫して表現されているため、マイクロサービスの支持者は SOA としてラベル付けされることをより緊急に拒否するようになります。ただし、マイクロサービスは SOA の本質であると主張する人もいます。これはサービス指向の側からは真実ですが、いずれにせよ、SOA とマイクロサービスは 2 つの異なるものであるため、このアーキテクチャ スタイルを簡潔に定義するには別の名前を使用することがさらに必要です。
- Martin Fowler / James Lewis、マイクロサービス

上記のマイクロサービスの定義と特徴からも、マイクロサービスはSOAで捨てられる制約や規制をほぼ全て放棄し、より自由なアーキテクチャスタイルを追求し、「規範標準」ではなく「実践標準」を提唱していることもはっきりと感じられます。 。」。**しかし、統一された仕様や制約がなければ、SOA によって解決された分散サービスの問題が突然再発するのではないか? **実際、サービス登録の検出、トラッキング ガバナンス、ロード バランシング、障害の分離、認証と承認、スケーリング、送信と通信、トランザクション処理など、これらの問題は、マイクロサービスには、たとえ単なるものであっても、統合されたソリューションはもう存在しません。 Java の範囲内で使用されるマイクロサービスについて議論します。サービス間通信の問題は、解決策の候補リストに 1 つだけ含めることができます: RMI (Sun/Oracle)、Thrift (Facebook)、gRPC (Google)、Motan2 (Sina) )、Finagle (Twitter)、Arvo (Hadoop)、JSON-RPC、REST など。サービス検出の問題を 1 つだけ選択できます: Eureka (Netflix)、Consul (HashiCorp)、Zookeeper (Apache)、Etcd (CoreOS) 、CoreDNS (CNCF) など 他の分野でも同様の状況であり、要するに八仙が海を渡り、それぞれの魔力を発揮するという状況である。

マイクロサービスによってもたらされる自由は両刃の剣であり、ソフトウェア アーキテクトがこの剣を手に取ると、一方の刃は SOA によって設定された複雑な技術標準を指し、彼らが選択の力を取り戻すと同時に、もう一方の刃も向けられます。また、それ自体に冷たい光を反射します。マイクロサービスの時代では、ソフトウェア開発自体の複雑さは軽減されたと言えますが、単純なサービスが分散のすべての問題に同時に直面するとは限りませんし、SOA という重い宝袋を持ち歩く必要もありません。 . 技術的な荷物。解決する必要がある問題が何であれ、どんなツールでも導入し、チームが精通しているテクノロジーであれ、どんなフレームワークでも使用します。さらに、Spring Cloud のような接着剤スタイルのファミリー バケット ツール セットは、一貫したインターフェイス、宣言、構成を通じて特定のツールやフレームワークの複雑さをさらに保護し、異なるツールやフレームワーク間の切り替えコストを削減します。 「スクリュー」プログラマにとって、マイクロサービス アーキテクチャは親しみやすいものです。しかし、マイクロサービスはアーキテクトにとって悪意に満ちており、アーキテクチャの能力に対する要件は前例のないレベルに引き上げられており、テクニカル アーキテクトの最初の責任は意思決定であることを著者は本書の多くの場所で繰り返し強調しています。デメリットにはデメリットが必要で、トレードオフにはトレードオフが必要であり、建築家自身の知識だけでは必要な意思決定の内容をカバーできず、メリットとデメリットが明確でないと、必然的に転倒する可能性があります。選択の難しさのジレンマに陥る。

マイクロサービスの時代は自由に満ちていますが、マイクロサービスの時代は混乱した選択肢に満ちています。ソフトウェア アーキテクチャは自由にとどまらず、マイクロサービスもまだアーキテクチャの探求の終わりではありません。次の時代があるなら、情報システムも同時にマイクロサービスの自由を持ち、ビジネス機能を中心に独自のサービスを構築できるようになることを願っています技術仕様に制限されることなく、同時に、分散された問題を自分で解決する責任を負うという犠牲を払う必要もありません。彼のトレードオフなんて誰が気にするだろう！子どもたちは選択問題しかやらないが、大人はみんなやるんだ！

ポストマイクロサービス時代

マイクロサービスアーキテクチャでは、登録の検出、追跡管理、負荷分散、送信通信など、解決しなければならない問題がいくつか発生します。しかし、これらの問題は、元々の分散時代には常に存在していました。最も一般的な解決策は次のとおりです。

• システムのスケーリングと拡張が必要な​​場合、通常は新しいサーバーを購入し、いくつかのレプリカ インスタンスのセットをデプロイして負担を分散します。
• システムがロード バランシングの問題を解決する必要がある場合、通常、ロード バランサーを配置し、トラフィックを迂回する適切なバランシング アルゴリズムを選択します。
• 安全な伝送の問題を解決する必要がある場合、通常、通信が盗聴されたり改ざんされたりしないように、TLS 伝送リンクを手配し、CA 証明書を構成します。
• サービス検出の問題を解決する必要がある場合は、通常、サービスへのアクセスが不安定な IP アドレスではなく安定したレコード名に依存するように DNS サーバーをセットアップします。
• … …

マイクロサービスの時代において、これらの分散問題をインフラストラクチャレベルではなくアプリケーションサービスレベルで解決しなければならない理由は、ひとえにハードウェアで構成されるインフラストラクチャがソフトウェアで構成されるアプリケーションサービスの柔軟性に追いつけないためです。

登録の検出、ガバナンスの追跡などの問題の解決策は、仮想化テクノロジとコンテナ化テクノロジに依存します。マイクロサービス時代の成果は、Docker に代表される初期のコンテナ化テクノロジーの多大な貢献と切り離すことができません。

コンテナ戦争

初期のコンテナは単に高速に起動できるサービスの動作環境とみなされ、その使用の目的はプログラムの配布と展開を容易にすることでした。したがって、初期段階の単一サービスのコンテナは、分散問題の解決には実際には関与していませんでした。

2017年はコンテナエコロジー開発の歴史において節目の年と言えるでしょう。

Docker Swarm、Apache Mesos、Kubernetes が「コンテナ戦争」の主な競争相手です。Kubernetes はついに多くのコンテナ管理システムから抜きん出て「戴冠」しました。これはコンテナ開発における一時代の終わりを意味しました。そして、それがもたらすコンテナ間ネットワーキング、サービス、負荷分散、構成などの仮想化インフラストラクチャも、次の時代のソフトウェア アーキテクチャ開発の鍵となると言えます。

同じ分散サービスの問題について、Spring Cloud が提供するアプリケーション レベルのソリューションと Kubernetes が提供するインフラストラクチャ レベルのソリューションを比較してください。Spring Cloud と Kubernetes の出発点は異なり、問題解決の方法と効果も異なりますが、Kubernetes は新しく、より有望な問題解決のアイデアを提供します。

仮想化インフラストラクチャが単一のサービス コンテナから、複数のコンテナとクラスタに必要なすべての通信およびストレージ機能で構成されるサービス クラスタに開発され始めると、ソフトウェアとハ​​ードウェアの境界があいまいになり始めます。

ハードウェアがソフトウェアの柔軟性に追いつくことができれば、ビジネスとは関係のないこれらの技術的問題はソフトウェア レベルから分離され、ハードウェア インフラストラクチャ内で静かに解決される可能性が高く、ソフトウェアは問題のみに集中できるようになります。ビジネス、真に「ビジネス機能を中心に構築」するチームと製品。したがって、分散アーキテクチャの問題はソフトウェア レベルでのみ解決できるため、別の解決策があります。それは、アプリケーション コードとインフラストラクチャ ソフトウェアおよびハードウェアが統合され、それらが連携して問題に対処することです。

これにより、メディアの記事でもよく取り上げられる「クラウドネイティブ」の時代が到来しました。

Kubernetes はコンテナ戦争の勝者となり、ポストマイクロサービス時代の始まりを示していますが、実際には Kubernetes がすべての分散問題を完全に解決しているわけではありません。

柔軟で強力な機能の観点から見ると、Kubernetes は以前の Spring Cloud ソリューションほど優れていません。問題の中にはアプリケーションシステムやインフラの末端に存在するものもあり、インフラレベルで完全に解決することが難しいためです。

たとえば、マイクロサービス A はマイクロサービス B で公開された 2 つのサービスを呼び出します。これらを B1 と B2 と呼びます。B1 は正常に動作するが、B2 には連続 500 エラーが発生すると仮定します。特定のしきい値を超えると、雪崩効果を避けるために B2 を融合する必要があります。 。

この種の問題は、Spring Cloud のようなアプリケーション コードで実装されたマイクロサービスで対処するのは実はそれほど難しくありません。とにかくコード (または設定) を使用して問題を解決します。論理的であれば、どのような機能でも使用できますが、開発者の想像力と技術力には限界があります。ただし、インフラストラクチャはコンテナ全体を一括して管理するため、強度は比較的粗いです。実は同様の状況はサーキットブレーカーに限らず、監視、認証、認可、セキュリティ、負荷分散などのサービスにおいても細やかな管理が必要となります。たとえば、サービス呼び出し中の負荷分散では、多くの場合、トラフィック特性に基づいて負荷分散のレベルとアルゴリズムを調整する必要があります。DNS はある程度の負荷分散を実現できますが、通常はこれらの追加要件を満たすことができません。

この種の問題を解決するために、マイクロサービス インフラストラクチャはすぐに第 2 の進化を遂げ、現在では「サービス メッシュ」と呼ばれる「サイドカー プロキシ」(Sidecar Proxy) が導入されました。

具体的には、現在のコンテキストでは、「サイドカー」とは、マイクロサービス インフラストラクチャが、システムによってサービスのリソース コンテナー (Kubernetes のポッドを参照) に通信プロキシ サーバー (サイドカーに相当) を自動的に挿入することを意味します。同様の方法を使用します。ネットワーク セキュリティにおける中間者攻撃は、トラフィックをハイジャックし、アプリケーションが気付かないうちにアプリケーションのすべての外部通信を静かに乗っ取ります。

本エージェントは、通常のサービスコール（データプレーン通信といいます）の実装に加え、コントローラからの指示（コントロールプレーン通信といいます）を受け付け、コントロールプレーンの設定に応じてデータプレーン通信の内容を解析し、さまざまな追加機能を実現します。ヒューズ、認証、測定、監視、負荷分散など。

このようにして、アプリケーション レベルで追加のコードを必要とせず、アプリケーション コードとほぼ同等の優れた管理機能を提供するという目標を達成します。

アプリケーション システムと同じリソース コンテナ内で実行されているプロキシ サービスをソフトウェアと見なすべきかインフラストラクチャと見なすべきかを概念的に判断することは困難ですが、アプリケーションに対して透過的である限り、ソフトウェア コードを変更する必要はありません。サービスガバナンスを実現できれば十分です。

サービスのない時代

最後に、ここ 1 ～ 2 年で登場したばかりの「サーバーレス アーキテクチャ」について話しましょう。業界では、2012年にiron.ioが率先して「サーバーレス」（Serverless、「サーバーレス」と訳すべきだが、今では「サービスレス」と訳すのが習慣になっている）という概念を提唱し、2014年からは、 AWS は、Lambda という名前の商用サーバーレス アプリケーションをリリースしましたが、その後数年で開発者によって徐々に認知され、世界最大のサーバーレス オペレーティング プラットフォームに発展しました。2019 年までに、中国の Alibaba Cloud、Tencent Cloud などのベンダーもサービスフリーの製品をリリースしました。「サービスなし」は、最近のテクノロジー界における「新しいインターネット有名人」の 1 つとなっています。

サーバーレスアーキテクチャの進化の背景も、前述したように複数の段階を経て進化しています。コンピューターの開発も、メインフレーム、ミニコンピューター、PC、仮想マシン、クラウド サーバーを経て行われてきました (ほとんどのクラウド サーバーも仮想マシンです)。

クラウド コンピューティングの時代では、クラウド サービス ベンダーは、ハードウェアからソフトウェアまで無料のホスティングとすぐに使用できる機能を実現する IaaS、PaaS、SaaS 機能を提供します。

サーバーレスアーキテクチャは、マイクロサービスアーキテクチャやSOAアーキテクチャほど複雑ではなく、シンプルであることが最大の特徴です。バックエンド機能 (Backend) と機能 (Function) のみが関係します。

BaaS (サービスとしてのバックエンド、サービスとしてのバックエンド)

バックエンド設備とは、ビジネス ロジックの動作をサポートするために使用されるデータベース、メッセージ キュー、ログ、ストレージなどを指しますが、ビジネス上の意味はありません。これらのバックエンド設備はすべてクラウド上で実行されます。」 「サービスとしてのバックエンド」 (サービスとしてのバックエンド、BaaS)。

FaaS（Function as a Service、サービスとしての機能）

関数とはビジネス ロジック コードを指します。ここでの関数の概念と粒度は、プログラム コーディングの観点からはすでに関数に非常に近いです。違いは、サービスなしの関数は、コンピューティング能力やキャパシティ プランニングを考慮せずにクラウド上で実行されることです (from You技術的な観点からは無視できますが、課金の観点からは考慮する必要があります)。これは、ノーサービスでは「Function as a Service」(Function as a Service、FaaS) と呼ばれます。

サーバーレスのビジョンは、開発者が純粋にビジネスに集中できるようにすることです。

1. 技術的なコンポーネントを考慮する必要はなく、購入、著作権、モデル選択のトラブルも発生しません。
2. 導入方法を考慮する必要はなく、導入プロセスは完全にクラウド上でホストされ、クラウドによって自動的に完了します。
3. コンピューティング能力を考慮する必要はありません。データセンター全体のサポートにより、コンピューティング能力は無制限であると考えることができます。
4. フレーバーについて心配する必要はありません。システムの継続的かつ安定した動作を維持するのはクラウド サービス プロバイダーの責任です。

モノリシック アーキテクチャやマイクロサービス アーキテクチャとは異なり、コールド スタート、ステートレス、実行時間の制限など、サーバーレス アーキテクチャに固有のいくつかの特性により、サーバーレス アーキテクチャがユニバーサル アーキテクチャ モデルではないことが決まります。

マイクロサービス アーキテクチャが分散システムの最終目標である場合、サーバーレス アーキテクチャは「非分散」クラウド システムの出発点となる可能性があります。

私たちはほんの少し先しか見えませんが、そこにはやるべきことがたくさん見えています
– アラン・マシソン・チューリング、コンピューティング機械とインテリジェンス、1950 年 – チューリング、コンピューティング機械とインテリジェンス、1950 年

IaaS/PaaS/SaaS

サーバーレスアーキテクチャにおけるIaaS、PaaS、SaaSの定義は以下のとおりです。

IaaS (サービスとしてのインフラストラクチャ) サービスとしてのインフラストラクチャ

コンピューティング インフラストラクチャ (サーバー、ネットワーク テクノロジ、ストレージ、データ センター スペース) をサービスとして顧客に提供します。リソースを管理するためのオペレーティング システムと仮想化テクノロジの提供も含まれます。消費者は、インターネットを介して、確立されたコンピュータ インフラストラクチャからサービスを取得できます。

アドバンテージ：

• 基礎となるハードウェア構造の原則を気にする必要はありません。
• 変化するワークロードをサポートするためにインフラストラクチャをオンデマンドで拡張します。
• 柔軟で革新的なオンデマンドのサービス。

PaaS (サービスとしてのプラットフォーム) サービスとしてのプラットフォーム

Platform-as-a-Service プロバイダーは、独自のインフラストラクチャ上でハードウェアとソフトウェアをホストし、そのプラットフォームをインターネット接続を介して統合ソリューション、ソリューション スタック、またはサービスとしてユーザーに提供します。

主に開発者とプログラマーを対象とした PaaS を使用すると、ユーザーはプロセスに通常関連付けられるインフラストラクチャを構築および維持することなく、独自のアプリケーションを開発、実行、管理できます。

開発者は、ソフトウェアの更新やハードウェアのメンテナンスに煩わされることなく、コードを記述し、アプリケーションを構築、管理するだけです。このシステムは、構築および展開環境を提供します。

アドバンテージ：

• アプリケーションを開発してより迅速に提供します。
• 新しい Web アプリケーションを数分でクラウドにデプロイします。
• サービスとしてのミドルウェアを使用して複雑さを軽減します。

SaaS (サービスとしてのソフトウェア) サービスとしてのソフトウェア

Software as a Service は、サービス プロバイダーによって実行および管理される完全な製品を提供します。よく人々がサービスとしてのソフトウェアと呼ぶものは、エンドユーザー アプリケーションです。SaaS製品を利用する場合、ユーザーはサービスの保守や基盤となるインフラの管理を気にする必要がなく、SaaSソフトウェアの利用方法を検討するだけで済みます。

アドバンテージ：

• 革新的なビジネス アプリケーションを登録してすぐに使用できます。
• アプリとデータには、接続されているどのコンピューターからもアクセスできます。
• データはクラウド上にあるため、コンピューターに障害が発生しても失われることはありません。
• 本サービスは、利用ニーズに応じて動的に拡張可能です。

3つの違い