マイクロサービスガイド

マイクロサービスアーキテクチャスタイルは、昨年話題になったトピックです。最近のO'Reillyソフトウェアアーキテクチャカンファレンスでは、すべてのセッションでマイクロサービスについて話されているようでした。皆の過剰な誇大広告検知器を点滅させるのに十分です。この結果の1つとして、チームがマイクロサービスを採用することに熱心になりすぎて、マイクロサービス自体が複雑さを導入するということに気づいていないことがわかりました。これは、プロジェクトのコストとリスクにプレミアムを追加します。多くの場合、プロジェクトを深刻な問題に陥らせるプレミアムです。

マイクロサービスアーキテクチャを使用しているチームの話を聞くと、共通のパターンに気づきました。

1. 成功したマイクロサービスストーリーのほとんどすべては、大きくなりすぎて分割されたモノリスから始まっています
2. 最初からマイクロサービスシステムとして構築されたシステムについて聞いたことがあるほとんどすべての場合、深刻な問題に陥っています。

このパターンにより、私の同僚の多くは、アプリケーションが大きくなって価値があることがわかっていても、新しいプロジェクトをマイクロサービスで開始すべきではないと主張しています。

ここ数か月で、成功するマイクロサービスアーキテクチャに到達する唯一の方法は、最初にモノリスから始めることだという話を繰り返し聞いてきました。Simon Brownの言葉を言い換えると、適切に構築されたモノリスを構築できない場合、適切に構築されたマイクロサービスのセットを構築できると考えるのはなぜでしょうか。この議論の最新の、そしていつものように非常に説得力のあるレンダリングは、このサイトのMartin Fowlerからのものです。以前の草案にコメントする機会があったので、これについて考える時間がありました。そして、私はそうしました。特に、私は通常彼に同意していることに気づき、私の見解を通常共有している他の人々も彼に同意しているように見えたからです。

モノリスから始めることは、通常、まさに間違ったことだと確信しています。

マイクロサービスアーキテクチャスタイルの使用について人々と話すと、多くの楽観主義が聞こえてきます。開発者は、より小さなユニットで作業することを楽しんでおり、モノリスよりも優れたモジュール性を期待しています。しかし、どのアーキテクチャ上の決定と同様に、トレードオフがあります。特にマイクロサービスでは、運用に深刻な影響があります。運用は、単一の明確に定義されたモノリスではなく、小さなサービスのエコシステムを処理する必要があります。したがって、特定の基本的な能力がない場合は、マイクロサービススタイルの使用を検討しないでください。

EAAのPで、「オブジェクトを分散しないでください」と言いました。このアドバイスは、マイクロサービスへの私の関心と矛盾していますか？

gotoカンファレンスは、Sam Newmanの著書「Monoliths to Microservices」についてインタビューするように依頼してきました。これは、マイクロサービスとそれらをいつ使用するかについての一般的な会話になりました。サムは、それらの主な理由は、独立したデプロイ可能性、データの分離、組織構造の反映であると考えています。私は最初のものについては懐疑的ですが、データと人々はソフトウェア開発の複雑な部分であると考えています。

ここ数年、サービスベースのアーキテクチャは、より小さく、より焦点を絞った「マイクロ」サービスへと移行しています。このアプローチには、各コンポーネントを個別にデプロイ、スケーリング、および保守できること、複数のチームで開発を並列化できることなど、多くの利点があります。ただし、これらの追加のネットワークパーティションが導入されると、モノリシックなインプロセスアプリケーションに適用されたテスト戦略を再検討する必要があります。ここでは、複数の独立してデプロイ可能なコンポーネントの追加のテストの複雑さを管理するためのいくつかのアプローチと、異なるサービスの保護者として行動する複数のチームがいるにもかかわらず、テストとアプリケーションを正しく保つ方法について説明します。

モノリシックシステムが大きすぎて扱えなくなると、多くの企業はそれらをマイクロサービスアーキテクチャスタイルに分解することを検討します。それは価値のある旅ですが、簡単なものではありません。私たちは、これをうまく行うには、単純なサービスから始める必要があるが、その後、ビジネスにとって重要であり、頻繁に変更される垂直方向の機能に基づいたサービスを引き出す必要があることを学びました。これらのサービスは、最初は大きく、できれば残りのモノリスに依存しないようにする必要があります。移行の各ステップが、アーキテクチャ全体のアトミックな改善を表すようにする必要があります。

優れたフロントエンド開発は困難です。多くのチームが大規模で複雑な製品を同時に処理できるようにフロントエンド開発を拡張することはさらに困難です。この記事では、フロントエンドモノリスをより小さく、より管理しやすい多くの部分に分割するという最近の傾向と、このアーキテクチャがフロントエンドコードに取り組むチームの有効性と効率を高める方法について説明します。さまざまな利点とコストについて説明するだけでなく、利用可能な実装オプションのいくつかについても説明し、この手法を実証する完全なサンプルアプリケーションを深く掘り下げます。

モノリスをより小さなサービスに分割する場合、最も難しい部分は、実際にはモノリスのデータベースに存在するデータを分割することです。データリッチサービスを抽出するには、常にデータの単一の書き込みコピーを保持する一連のステップに従うと便利です。ステップは、既存のモノリスで論理的な分離を行うことから始まります。サービスの動作を個別のモジュールに分割し、次にデータを個別のテーブルに分割します。これらの要素は、個別に新しい自律サービスに移動できます。

コードとしてのインフラストラクチャとは、ソースコードを通じてコンピューティングおよびネットワークインフラストラクチャを定義し、それを他のソフトウェアシステムと同様に扱うことができるアプローチです。このようなコードは、ソース管理に保存して、監査可能性と再現可能なビルドを可能にし、テストプラクティスと継続的デリバリーの完全な規律の対象とすることができます。これは、過去10年間、成長するクラウドコンピューティングプラットフォームに対処するために使用されてきたアプローチであり、今後、コンピューティングインフラストラクチャを処理するための支配的な方法になるでしょう。

アジャイルソフトウェア開発は、要件分析、テスト、開発の間のサイロをいくつか打破しました。デプロイメント、運用、保守は、ソフトウェア開発プロセスの他の部分から同様に切り離されてきた活動です。DevOpsムーブメントは、これらのサイロを取り除き、開発と運用の間の協調を促進することを目的としています。

ソフトウェアシステムが、異なるプロセスで実行されている、おそらくネットワークを介した異なるマシン上にあるソフトウェアにリモートコールを行うことは一般的です。インメモリコールとリモートコールの大きな違いの1つは、リモートコールは失敗するか、タイムアウト制限に達するまで応答なしでハングする可能性があることです。さらに悪いことに、応答のないサプライヤに多数の呼び出し元がいる場合、重要なリソースが不足し、複数のシステムにわたるカスケード障害が発生する可能性があります。Michael Nygard氏は、彼の優れた著書であるRelease Itの中で、この種の壊滅的なカスケードを防ぐためにサーキットブレーカーパターンを普及させました。

サーキットブレーカーの背後にある基本的な考え方は非常にシンプルです。保護された関数呼び出しをサーキットブレーカーオブジェクトでラップし、障害を監視します。障害が特定のしきい値に達すると、サーキットブレーカーがトリップし、サーキットブレーカーへのそれ以降のすべての呼び出しは、保護された呼び出しがまったく行われずにエラーで返されます。通常、サーキットブレーカーがトリップした場合、何らかのモニターアラートも必要になります。