SOA からマイクロサービスまで、クラウドネイティブ時代にエンタープライズ分散アプリケーション アーキテクチャをどのように再構築できるでしょうか?

[[278362]]

10年以上前のさまざまな分散システムの研究開発から現在のコンテナクラウドまで、また既存ビジネスのサポートから新規ビジネスの育成まで、企業の発展は統一された最新の技術アーキテクチャと切り離せません。この記事では、エンタープライズ分散アプリケーション アーキテクチャの観点から、クラウド ネイティブ コンピューティング アーキテクチャによってもたらされる変化を紹介し、より多くの企業が IT を変革し、クラウド コンピューティング テクノロジを使用して市場競争で機敏な力を発揮できるように支援することを目的としています。

21 世紀初頭以来、エンタープライズ分散アプリケーション アーキテクチャは、SOA (サービス指向アーキテクチャ) からマイクロサービス アーキテクチャ、そしてクラウド ネイティブ アプリケーション アーキテクチャへと進化してきました。

エンタープライズ アーキテクチャの進化の背後にある考え方を説明するために、まず形而上学について説明しましょう。

• まず、企業の IT システムの複雑さ (エントロピー) は、熱力学の第二法則に準拠しています。時間が経ち、ビジネスが変化するにつれて、企業の IT システムの複雑さは増します。
• 第二に、コンピュータインタラクションデザインには複雑性保存の法則がよく知られています[1]。アプリケーション相互作用の複雑さはなくなるわけではなく、単に異なる形で存在するだけになります。この原則はソフトウェア アーキテクチャにも適用されます。新しいソフトウェア アーキテクチャを導入しても、IT システム全体の複雑さは軽減されません。

これを聞いて、私たちは人生で果てしなく苦労しながら、少し寒気を感じませんか？

現代のソフトウェア アーキテクチャの中心的なタスクの 1 つは、インフラストラクチャとアプリケーションの境界を定義し、複雑さを合理的に分割し、アプリケーション開発者が直面する必要がある複雑さを軽減することです。言い換えれば、開発者はコアバリューのイノベーションに集中し、一部の問題はより適切な人材やシステムに解決を任せることができるようになります。

エンタープライズ分散アプリケーション アーキテクチャの進化の背後にあるロジックを探るために、まず次の図から始めましょう。

この画像はビルギン・イブリアムのツイッターから引用[2]

変革の苦しみ: SOA

2004 年に IBM は SOA グローバル デザイン センターを設立しました。 R&D TL およびアーキテクトとして、私は世界中の顧客向けの一連のパイロット プロジェクトに参加し、Pepboys や Office Depot などの国際企業が SOA を使用して社内および企業間のビジネス プロセスを最適化し、ビジネスの俊敏性を向上させることを支援しました。

当時の一般的な背景は、経済のグローバル化が徐々に深まるにつれて、企業が直面する競争が激化し、ビジネスの変革が加速し始めたというものでした。大企業内の IT システムは数十年にわたって進化しており、メインフレーム システム上の CISC/COBOL トランザクション アプリケーション、ミニコンピュータ AS400 上の RPG ビジネス システム、X86/Power などの分散システム上の C/JEE/.Net アプリケーションなど、技術システム全体が極めて複雑になっています。

多数のアプリケーション システムはサードパーティ サプライヤーによって提供されており、一部のシステムはメンテナンスされなくなっています。さらに、ビジネスの反復により、新しいビジネス システムが継続的に構築されます。合理的な方法論的ガイダンスの欠如とシステム間の有機的なリンクの欠如により、多数の孤立した島が形成され、IT アーキテクチャの複雑さが継続的に悪化し、ビジネスの開発要求をサポートできなくなります。それはあたかも、負傷した霊湖崇を助けるために、さまざまな宗派の師が彼の体に別の種類の真気を注入したかのようだったが、それは短期間しか負傷を和らげることができなかった。しかし、複数の真気の流れは統合できず、互いに衝突し、長期間にわたってさらなる傷害を引き起こします。

したがって、企業の IT が直面する主な課題は、企業内の多数のサイロ化された IT システムを統合し、ますます複雑化するビジネス プロセスをサポートし、効率的なビジネス上の意思決定を行い、急速なビジネスの変化をサポートすることです。

このような状況の中で、IBM と他の企業は、アプリケーション システムを粗粒度のサービスに抽象化し、疎結合のサービス アーキテクチャを構築する SOA (サービス指向アーキテクチャ) の概念を提案しました。サービスはビジネス プロセスを通じて柔軟に組み合わせることができ、企業の IT 資産の再利用、システムの適応性、柔軟性、拡張性が向上し、「情報孤島」の問題が解決されます。

SOA は、分散システムを構築するための一連の原則を提案しましたが、これらは現在でも適用可能です。

• サービスには、明確に定義された標準化されたインターフェースがあります。サービス定義記述を通じて、サービス コンシューマーとサービス プロバイダーの実装が分離され、コードはコード ファーストではなくコントラクト ファーストで開発される必要があります。サービス間の通信では、特定の言語での RPC プロトコルではなく、ドキュメント指向のメッセージを採用します。一方で、サービスと実装言語の分離を解決でき、他方では、同期または非同期通信の実装を柔軟に選択して、システムの可用性とスケーラビリティを向上させることができます。
• サービスは疎結合である必要があり、時間、空間、テクノロジー、またはチームに関してサービス間の依存関係があってはなりません。
• サービスはステートレスであるべきであり、サービス呼び出しはセッション コンテキストの状態から切り離される必要があります。
• サービスは自律的かつ自己完結的である必要があり、サービスの実装は独立して展開可能、バージョン管理可能、自己管理可能、回復可能である必要があります。
• サービスは検出可能かつ構成可能です。たとえば、サービス レジストリを通じてサービス検出を実行すると、サービス コンシューマーとサービス プロバイダー間の動的なバインディングが可能になります。さまざまなシステムのビジネス サービスをビジネス プロセスに編成して組み立てることができます。

SOA システムを最初に構築するときは、ポイントツーポイントの通信接続が主に使用され、サービス呼び出しと統合ロジックがアプリケーション実装に組み込まれます。このアプローチは、サービスの数が比較的少ない場合には、実にシンプルで効率的な開発方法です。しかし、最大の問題は、サービスの規模が大きくなるにつれて、サービス間の通信がより複雑になり、接続パスと複雑さが劇的に増加し、サービスガバナンスに大きな課題が生じることです。

上記の課題を解決するために、エンタープライズ サービス バス (ESB) が導入され始めました。エンタープライズ サービス バスは、サービス間の接続、変換、仲介の機能を提供します。企業の内部およびさまざまなサービスをサービス バスに接続することで、情報システム間の疎結合アーキテクチャを実現し、システム統合の複雑さを隠蔽し、IT システム アーキテクチャの柔軟性を向上させ、企業内の情報共有コストを削減できます。

SOA 方法論の目標は易経のようなもので、さまざまな種類の真のエネルギーを分類して収集し、それらを統合して自分の利益のために使用するのに役立ちます。しかし、栽培プロセスは決して簡単ではありません。多くの野心的な SOA プロジェクトが期待された結果を達成できないのはなぜでしょうか?

あらゆる IT アーキテクチャの成功は、ビジネス目標、技術基盤、組織能力との調整によって決まります。

ビジネスの観点から見ると、当時の SOA はエンタープライズ IT の既存市場の問題を解決することに重点を置いていました。これにより、SOA 方法論はエンタープライズ アプリケーション統合 ​​(EAI) に大きく限定されました。

SOA コンセプトでは、情報システム間のチャネルを開くことは最初のステップにすぎません。また、社内のスキルの向上に努め、企業の IT アーキテクチャを継続的に再構築して反復することも必要です。この方法でのみ、エンタープライズ IT アーキテクチャは俊敏性と柔軟性を維持し、ビジネスの開発と変更を継続的にサポートできます。

組織構造の面では、当時のほとんどの企業の IT 部門は依然としてコスト センターであり、ビジネスの補助的なサポート部門でした。ほとんどの企業では長期的な IT 戦略計画が欠如しており、IT チームにも成長の認識が欠けていました。 SOA は、組織的な保証や継続的な投資のないプロジェクトベースの運用になりました。

当時は成功していたプロジェクトでも、時間の経過とともに複雑さが増し、徐々に活力を失っていきます。昨年、アメリカに住む友人から写真が送られてきました。 15年前に当社がクライアント向けに構築した業務システムは、現在も全国の既存店舗の業務を支えています。これはテクノロジー プロジェクトの成功ですが、企業のテクノロジー戦略の欠如を反映しています。

技術的には、ESB アーキテクチャはビジネス ロジックとサービス統合の分離を実現し、サービス ガバナンスをより適切に集中化できますが、いくつかの深刻な問題も発生します。

これは、エンタープライズ IT アーキテクチャのガバナンスと再構築よりも、ビジネス システムの再利用性に過度に重点が置かれているためです。大量のサービス統合実装ロジックが ESB に組み込まれています (上図の右端を参照)。これらのロジックは維持、移植、拡張が非常に難しく、ESB にとって耐え難い負担となっています。複雑さを単に移動させるのではなく、必要な場所で管理する必要があります。

ESB は集中型メッセージ処理システムに基づいていますが、インターネットの急速な発展により、ESB はエンタープライズ IT の大規模な成長の課題に対応できなくなりました。

ESB などのスマート パイプおよびダム エンドポイントのシステム アーキテクチャは、急速な変化や大規模なイノベーションに適応できません。

同様に、通信事業者はかつて、ビデオ通信やテレビ会議などの複雑な機能を通信インフラに組み込み、ダミーの電話端末だけで充実した通信サービスを享受したいと考えていました。しかし、スマートフォンの普及に伴い、WeChatやDingTalkなどの分散型コラボレーションツールの革新が人々のコミュニケーション方法を一変させ、通信ネットワークはパイプラインとしての運命に戻ってしまいました。

変身の美しさ：マイクロサービス

インターネットの発展、特にモバイルインターネット時代の到来により、世界全体の経済構造は大きな変化を遂げました。エンタープライズ IT の焦点は、従来の System of Record (ERP、SCM などのトランザクション システム) から System of Engagement (オムニチャネル マーケティングなどのインタラクティブ システム) へと進化しました。

これらのシステムは、インターネットの急速な成長に対応でき、低コストで迅速に反復して間違いを起こせる必要があります。エンタープライズ IT はイノベーションを推進する原動力の 1 つになりました。テクノロジーを活用してビジネスの境界を拡大するという理想は、IT チームの使命感をさらに強め、エンタープライズ IT の進化をさらに加速させるのにも役立っています。

Netflix や Alibaba が率いる一連のインターネット企業は、エンタープライズ アーキテクチャの新たな変革、つまりマイクロサービス アーキテクチャを主導してきました。 Apache Dubbo や Spring Cloud などのマイクロサービス フレームワークが広く使用されています。

マイクロサービスの中心的な考え方は、アプリケーション機能を分割および分離して、ビジネス システムの実装の複雑さを軽減することです。マイクロサービスでは、アプリケーション機能を疎結合された一連のサービスに分解することを重視しており、各サービスは単一責任の原則に準拠しています。マイクロサービス アーキテクチャは、従来のモノリシック アーキテクチャに固有のいくつかの問題を解決します。各サービスは独立してデプロイおよび配信できるため、ビジネスの俊敏性が大幅に向上します。各サービスは、インターネット規模の課題に対応するために、水平方向に独立して拡張/縮小できます。

元の画像はマーティン・ファウラーのマイクロサービスアーキテクチャの定義から引用したものです[3]

もちろん、大規模なモノリシック アプリケーションを複数のマイクロサービスに分割すると、IT システムの研究開発コラボレーション、配信、運用および保守の複雑さが増すのは間違いありません。このとき、マイクロサービス アーキテクチャは DevOps やコンテナと自然に融合し、クラウド ネイティブ アプリケーション アーキテクチャのプロトタイプを形成しました。

マイクロサービス アーキテクチャは SOA のアーキテクチャ原則を継承しますが、実装レベルでは、スマート エンドポイントとダム パイプの分散型分散アーキテクチャ スタイルを構築することで ESB を置き換える傾向があります。

マイクロサービス アーキテクチャは、まず分散アーキテクチャに固有の複雑さに対処する必要があります。分散コンピューティングに関する誤解については[4]を参照してください。マイクロサービス フレームワークは、サービス検出、回路遮断、電流制限、フルリンク トレースなどの課題など、サービス通信とサービス ガバナンスの複雑さに対処できる必要があります。

HSF/Dubbo や Spring Cloud などのマイクロサービス フレームワークは、これらの機能をコード ライブラリの形式でカプセル化します。これらのコード ライブラリはアプリケーション自体に組み込まれ、アプリケーションとともにリリースおよび保守されます。

元画像出典: [5]

サービス通信とガバナンスは、本質的にビジネス ロジックとは直交する水平的なシステム レベルの問題です。しかし、マイクロサービス アーキテクチャでは、その実装とライフ サイクルはビジネス ロジックと結合されます。

マイクロサービス フレームワークをアップグレードすると、サービス アプリケーション全体の再構築と展開が行われます。さらに、コード ベースは通常特定の言語にバインドされているため、エンタープライズ アプリケーションの多言語実装をサポートすることは困難です。

進化の光：クラウドネイティブ

SOA は集中型サービス バス アーキテクチャを採用し、ビジネス ロジックとサービス ガバナンス ロジックを分離します。マイクロサービス アーキテクチャは、分散型のポイントツーポイント呼び出し方式に戻ります。これにより、ビジネス ロジックとサービス ガバナンス ロジックの分離によってもたらされる柔軟性は犠牲になりますが、俊敏性とスケーラビリティは向上します。

上記の課題に対処するために、コミュニティはサービス メッシュ アーキテクチャを提案しました。サービス ガバナンス機能をインフラストラクチャに戻し、サービス コンシューマー側とプロバイダー側​​の両方で独立したプロセスとして展開します。

これにより、分散化の目的が達成され、システムのスケーラビリティが確保されるだけでなく、サービス ガバナンスとビジネス ロジックが分離されます。これら 2 つは互いに干渉することなく独立して進化できるため、全体的なアーキテクチャ進化の柔軟性が向上します。同時に、サービス メッシュ アーキテクチャにより、ビジネス ロジックへの侵入が軽減され、多言語サポートの複雑さが軽減されます。

元画像出典: [5]

Google、IBM、Lyft が開始した Istio プロジェクトは、サービス メッシュ アーキテクチャの典型的な実装であり、新たな驚異的な「インターネット セレブ」プロジェクトとなっています。

上の図は、論理的にデータ プレーンとコントロール プレーンに分割された Istio のアーキテクチャを示しています。

• データ プレーンは、サイドカー方式で展開される一連のインテリジェント エージェントで構成され、アプリケーション ネットワーク トラフィックの傍受、テレメトリ データの収集、サービス ガバナンス ポリシーの実行を担当します。
• コントロール プレーンでは、Galley が構成管理を担当し、Pilot が構成の発行を担当し、Mixer がポリシー チェックとテレメトリ データの集約を担当し、Citadel が通信におけるセキュリティ証明書の管理を担当します。

Istio は、サービス検出と負荷分散、プログレッシブ配信 (グレースケール リリース)、カオス インジェクションと分析、フルリンク トレース、ゼロ トラスト ネットワーク セキュリティなどの一連の高度なサービス ガバナンス機能を提供します。これらの機能は、上位レベルのビジネス システムによって独自の IT アーキテクチャとリリース システムにオーケストレーションできます。

ただし、サービス メッシュは万能薬ではありません。そのアーキテクチャ上の選択は、アーキテクチャ上の柔軟性とシステムの進化性と引き換えに、展開の複雑さ (サイドカー) を増大させ、パフォーマンスを低下させる (2 つのホップを追加) ことです。

展開の複雑さという課題に対処するために、コミュニティとクラウド サービス プロバイダーが協力して取り組んでいます。

• 一方では、サービス メッシュの自動運用と保守が簡素化されます (たとえば、Alibaba Cloud は、オペレーターを通じて Istio のアップグレードと保守、およびクロス K8s クラスターの展開の複雑さを大幅に簡素化しました)。
• 一方、マネージド サービス メッシュ サービスを提供することで、ユーザーはインフラストラクチャの実装ではなく、ビジネス レベルでのサービス ガバナンスに集中できるようになります。

パフォーマンスの問題について:

• 一方で、サービス メッシュでは、ミキサーの負荷を可能な限りオフロードし、ガバナンス ポリシーの実行をデータ プレーンに移すなど、独自のコントロール プレーンとサービス プレーンのパフォーマンス オーバーヘッドを削減する必要があります。
• 一方、通信スタック全体におけるアプリケーションとネットワーク インフラストラクチャの境界を再考する必要もあります。

コンテナ アプリケーション間の相互接続を実現するために、Kubernetes コミュニティは、コンテナ ネットワーク接続を基盤となるネットワーク実装から切り離す CNI ネットワーク モデルを提案しました。同時に、K8s は、サービス、Ingress、ネットワーク ポリシーなどの基本的なプリミティブを提供し、アプリケーション層でのサービス通信とアクセス制御をサポートします。ただし、これらの機能は、アプリケーションのサービス ガバナンスのニーズを満たすにはほど遠いものです。

サービス メッシュには、トラフィック管理、フルリンクの可観測性、L4/L7 での安全な相互接続などの新しい機能が追加されています。これらは、ユーザー空間で実行される Envoy プロキシを導入することによって実現されます。柔軟性は向上しますが、パフォーマンスのオーバーヘッドも必然的に増加します。

この問題を体系的に解決するために、コミュニティは興味深い調査を行っています。たとえば、Cillium コンテナ ネットワークでは、オペレーティング システムと eBPF/XDP などの基盤となるネットワーク機能を使用して、アプリケーション層のサービス制御機能 (Kube-Proxy が提供するサービスやネットワーク ポリシーなど) をオペレーティング システム カーネルとネットワーク層にシンクして解決し、サービス メッシュ データ リンクを最適化してコンテキストの切り替えやデータのコピーを減らし、パフォーマンスのオーバーヘッドを効果的に削減できます。

現在、サービス メッシュ テクノロジーはまだ成熟曲線の初期段階にあります。コミュニティでは、L4/L7層で柔軟なサービス通信機能を提供することに加えて、ネットワークサービスメッシュ[6]を通じて柔軟なL2/L3ネットワーク機能の実装も検討しています。私たちは、これが将来のエンタープライズ分散アプリケーション通信インフラストラクチャになると信じています。

このプロセスでは、新しいコンセプトやプロジェクトが継続的に作成され、それらのビジネス価値と技術的な制限を合理的に分析できる必要があります。複雑さによる間違いを繰り返さないようにするには、サービス メッシュを万能薬として使用することは避け、アプリケーション統合やアプリケーション側のセキュリティなどのビジネス ロジックをサービス メッシュに組み込まないようにする必要があります。アプリケーションの安全性と正確性はIstioやサービスメッシュにオフロードできない[7]を参照してください。

歴史を振り返る

世界の一般的な傾向は、長い分裂の期間の後には統一があり、長い統一の期間の後には分裂があるということです。エンタープライズ分散アプリケーション アーキテクチャも、分離と統合の進化の道を経てきました。新しいテクノロジーが次々と登場する今日、私たちは新しいテクノロジーがもたらすアーキテクチャの変化を受け入れるだけでなく、その背後にある進化のロジックとコアバリューにさらに注意を払い、複雑さを体系的に制御する必要があります。

関連リンク:

[1] https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity

[2] https://twitter.com/bibryam/status/1026429379587567616

[3] https://martinfowler.com/articles/microservices.html

[4] https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

[5] https://philcalcado.com/2017/08/03/pattern_service_mesh.html

[6] https://networkservicemesh.io/

[7] https://blog.christianposta.com/microservices/application-safety-and-correctness-cannot-be-offloaded-to-istio-or-any-service-mesh/