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]を参照してください。

歴史を振り返る

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