世界は分散型
ヒント
このコンテンツは、 .NET Docs またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、.NET 開発者向け Dapr の電子ブックからの抜粋です。
"流行に敏感な子供" に聞いてみると、次のような答えが返ります: "はやりは最新の分散システム、モノリシック アプリはもうおしまい"
しかし、"流行に敏感な子供" だけではありません。最先端の IT リーダー、企業のアーキテクト、抜け目のない開発者も、最新の分散アプリケーションを調べて評価すると、同じ考えを持ちます。 多くの人が賛同しています。 分散マイクロサービス アプリケーションの原則、パターン、プラクティスに従って、新しいエンタープライズ アプリケーションの設計や、既存のものの再プラットフォーム化が行われています。
しかし、この進化によって多くの質問が発生します。
- 分散アプリケーションとは厳密にはどのようなものでしょう?
- なぜ人気が高まっているのでしょうか?
- コストはどうでしょう?
- そして、大事なこととして、どのようなトレードオフがあるでしょうか?
まず、過去 15 年間を振り返って見てみましょう。 この期間のアプリケーションは、通常、単一のモノリシック ユニットとして構築されました。 図 1-1 は、そのアーキテクチャを示したものです。
(図 1-1) 。 モノリシック アーキテクチャ。
注文、ID、マーケティング用のモジュールが、単一サーバー プロセスで実行されるしくみに注意してください。 アプリケーション データは、共有データベースに格納されます。 ビジネス機能は、HTML と RESTful のインターフェイスを介して公開されます。
多くの点で、モノリシック アプリは straightforward (簡単) です。 次のことが簡単にできます。
- ビルド
- テスト
- デプロイ
- トラブルシューティング
- 垂直方向のスケーリング (スケールアップ)
しかし、モノリシック アーキテクチャでは大きな課題が生じる可能性があります。
時間が経つにつれて、制御が失われ始めるようになる可能性があります。
- モノリスは非常に複雑になり、誰も理解できなくなりつつあります。
- 思いもよらないコストのかかる副作用が生じるため、変更するのが怖くなります。
- 新しい機能や修正を実装するのは、時間がかかり、コストもかかります。
- 最小限の変更でも、アプリケーション全体の完全な展開が必要であり、コストとリスクが伴います。
- 1 つの不安定なコンポーネントが原因で、システム全体がクラッシュする可能性があります。
- 新しいテクノロジやフレームワークの追加は、選択肢に入りません。
- アジャイル配信手法の実装は困難です。
- 終わりのない "特殊なケース" によってコード ベースが劣化すると、アーキテクチャの侵食が始まります。
- 最終的には、コンサルタントが登場し、作り直しを命じます。
IT 専門家は、このような状況を the Fear Cycle (恐怖サイクル) と呼びます。 テクノロジ ビジネスに携わっている時間が短くても、そのようなことを経験している可能性は十分あります。 それはストレスになり、IT 予算を食いつぶすことです。 新しい革新的なソリューションを構築するのではなく、ほとんどの予算がレガシ アプリの保守に費やされます。
ビジネスには、恐怖ではなく speed and agility (スピードと機敏性) が心配です。 市場の状況に迅速に対応できるアーキテクチャ スタイルが模索されています。 ライブ アプリケーションの小さな領域を瞬時に更新し、個別にスケーリングする必要があります。
スピードと機敏性を実現するための早期の試みは、サービス指向アーキテクチャ (SOA) の形になりました。 このモデルでは、サービス コンシューマーとサービス プロバイダーのコラボレーションは、ミドルウェア メッセージング コンポーネント (多くの場合、エンタープライズ サービス バス (ESB) と呼ばれます) を介して行われました。 図 1-2 は、そのアーキテクチャを示したものです。
図 1-2. SOA アーキテクチャ。
SOA では、一元化されたサービス プロバイダーは ESB に登録しました。 プロバイダーとコンシューマーを統合するため、ビジネス ロジックが ESB に組み込まれました。 サービス コンシューマーは、ESB を使用することで、これらのプロバイダーを見つけて通信することができました。
SOA の約束にもかかわらず、多くの場合、このアプローチを実装すると、複雑さが増し、ボトルネックが発生しました。 メンテナンス コストが高くなり、ESB ミドルウェアは高価になりました。 サービスは大規模になる傾向がありました。 多くの場合、依存関係とデータ ストレージは共有されました。 最終的に、SOA は、多くの場合、変更に抵抗する一元化されたサービスによる "分散モノリシック" 構造になってしまいました。
今日、多くの組織は、分散マイクロサービス アーキテクチャ アプローチを採用してシステムを構築することで、スピードと機敏性を実現しています。 図 1-3 は、分散の手法とプラクティスを使用して構築された同じシステムを示しています。
図 1-3. 分散アーキテクチャ。
同じアプリケーションが分散サービスのセットに分解されていることに注意してください。 それぞれは自己完結型であり、独自のコード、データ、依存関係がカプセル化されています。 それぞれがソフトウェア コンテナーにデプロイされ、コンテナー オーケストレーターによって管理されます。 1 つのデータベースが複数のサービスで共有されるのではなく、各サービスがプライベート データベースを所有します。 他のサービスは、このデータベースに直接アクセスできず、それを所有するサービスのパブリック API を介して公開されているデータのみを取得できます。 完全なリレーショナル データベースを必要とするサービスと、NoSQL データストアを必要とするサービスがあることに注意してください。 バスケット サービスの状態は、キーと値の分散キャッシュに格納されます。 受信トラフィックが API ゲートウェイ サービス経由でルーティングされるしくみに注意してください。 それによって、呼び出しがサービスに送られ、横断的な考慮事項が適用されます。 最も重要な点は、最新のクラウド プラットフォームに備わっているスケーラビリティ、可用性、回復性の機能をこのアプリケーションから最大限に活用できることです。
ただし、分散サービスによって機敏性とスピードを実現できますが、異なる一連の課題が発生します。 次のことを考えてみてください。
- 分散サービスで相互を検出し、同期的に通信するには、どうすればよいでしょう?
- 非同期メッセージングを実装するには、どうすればよいでしょう?
- トランザクションを通してコンテキスト情報を管理するには、どうすればよいでしょう?
- それらを障害に対する回復性があるものにするには、どうすればよいでしょう?
- 変動する需要に合わせてスケーリングするには、どうすればよいでしょう?
- それらを監視および観察するには、どうすればよいでしょう?
これらのどの課題についても、多くの場合、複数の製品を使用できます。 しかし、製品の違いからアプリケーションを保護し、コードの保守性と移植性を維持することは困難になります。
この記事では、Dapr を導入します。 Dapr は、分散アプリケーション ランタイムです。 これは、分散アプリケーションと共に発生する多くの課題に直接対応します。 今後 Dapr は、分散型アプリケーションの開発に大きな影響を与える可能性があります。
まとめ
この章では、分散アプリケーションの導入について説明しました。 モノリシック システムのアプローチと、分散サービスのそれを比較しました。 分散型アプローチを検討するときの一般的な課題の多くを指摘しました。
次に、Dapr の新しい世界を紹介します。