マイクロサービスの狂気は2018年に開催されます

Dave Kerrが作成したこの論文で、1か月に90件のコメントを集めた記事がRedditとHacker Newsで激しい議論を引き起こしました。 2016年に最後に出版されたSam Newmanの創刊書籍The Creation of Microservicesの補足コピーが必要ですか、それともカー氏の懐疑は正当化されますか？



読んでコメントしてください！



ここ数年で、マイクロサービスのトピックは非常に人気があります。 マイクロサービス愛好家の「狂信」は、この三段論法のようなものになります。

Netflixには優れたdevopsプラクティスがあります。 Netfixはマイクロサービスを扱います。 したがって、マイクロサービスに関わるようになれば、devopsで成功するでしょう。

多大な労力を費やしてマイクロサービスパターンが導入された例がありますが、サポーターはこの作業のコストが何であるか、マイクロサービスがこの特定の問題の解決に非常に役立つかどうかを理解していませんでした。



ここでは、マイクロサービスとは何か、このパラダイムが非常に魅力的である理由、およびそれがあなたにもたらす主な課題について詳しく説明します。



最後に、いくつかの簡単な質問を作成します。おそらく、自分で答えるべきだと思います-マイクロサービスはあなたに適していますか？







マイクロサービスとは何ですか、なぜそんなに人気があるのですか？



基本から始めましょう。 ビデオ共有用の仮想プラットフォームを実装する方法は次のとおりです。最初にモノリス（単一の大きな構造）の形式で、次にマイクロサービスの形式で：







違いは、最初のケースでは1つの大きなデザインがあり、2番目のケースでは小さな特定のサービスのセットがあることです。 各サービスは特定の役割を果たします。

このような詳細で図を描くと、もちろん魅力的です。 継続的な潜在的な利点：



独立した開発 ：小さな独立したチームが小さな独立したコンポーネントを作成できます。 グループは、「Recode」サービスの開発を妨げることなく、またはそれを知らなくても、「Upload」サービスの変更を変更できます。 コンポーネントを理解するのに必要な時間が大幅に短縮され、新しい機能を開発するのが簡単になりました。



独立した展開 ：個々のコンポーネントは、それぞれ独立して展開できます。 したがって、新機能は、より少ないリスクでより迅速に展開できます。 ストリーミングビデオコンポーネントを変更または修正する場合、必要に応じて展開できます。このために他のコンポーネントを展開する必要はありません。



独立したスケーラビリティ ：すべてのコンポーネントは、互いに独立してスケーリングできます。 暑い季節には、新しいショーがリリースされると、ダウンロードコンポーネントを強化して負荷の増加に対応することができます。そのため、他のすべてのコンポーネントを増やす必要はありません。 弾性スケーリングは、実装がそれほど難しくなく、開発コストが削減されます。



再利用性 ：各コンポーネントは特定の小さな機能を実行します。 したがって、他のシステム、サービス、または製品での使用に簡単に適応できます。 そのため、「トランスコーディング」コンポーネントをビジネス要素で使用したり、ビジネスロジックの新しいコンポーネントに変えたりして、他のグループにトランスコーディング機能を提供できます。



この近似により、モノリスに対するマイクロサービスの優位性は明らかです。 それでは、問題は何ですか-なぜこのパラダイムは最近好意的ですか？ 彼女は以前どこにいましたか？



彼らがとてもクールなら、なぜ誰も彼らを前にやったことがないのですか？



この質問には2つの答えがあります。 最初： 彼らはそれをしました -私たちの技術的能力が許す限り。 第二に、マイクロサービス技術を新しいレベルに引き上げることができたのは、最新の技術的ブレークスルーのみでした。



この質問に対する答えを書き始めたとき、 長い説明があったので、別の記事に入れて後で公開することにしました。 この段階では、1つのプログラムから多くのプログラムへのパスについては説明しません。ESBおよびサービス指向アーキテクチャ、コンポーネント設計、限定されたコンテキストなどについては説明しません。



興味のある方は、このパスについて個別に読むことができます。 何らかの方法で以前にこれをやったと言いたいのですが、最近のコンテナ技術（特にDocker）とオーケストレーション（Kubernetes、Mesos、Consulなど）の人気の急増のおかげで、このパターンは実装がはるかに簡単になりました技術的な観点から。

したがって、マイクロサービスシステムを本当に構築できると当たり前のことだと思ったら、慎重に検討する必要があります。それが必要なのでしょうか。 理論的には、最も一般的な意味では、利点は明確ですが、課題は何ですか？



マイクロサービスの問題は何ですか？



マイクロサービスが非常に優れている場合、その取引は何ですか？ ここに私が見る重要な問題のいくつかがあります。



開発者のタスクは複雑です



開発者にとって、事態は非常に複雑になる可能性があります。 プログラマーがシーケンス全体、または潜在的に多くのサービスにまたがる機能を開発したい場合、同じマシン上でそれらをすべて実行するか、それらに接続する必要があります。 多くの場合、これは単一のプログラムを取得して実行するよりもはるかに複雑です。



この問題は適切なツールを使用して部分的に解決されますが、システム内のサービスの数が増えると、開発者がシステム全体を起動することがますます困難になります。



オペレーターのタスクが複雑になる



サービスを開発するのではなく、それらをサポートするチームにとって、複雑さの増大は爆発的なものになる可能性があります。 複数のサービスではなく、数十、数百、または数千を管理する必要があります。 より多くのサービス、より多くの通信パス、より多くの潜在的な障害点。



Devopsタスクが複雑になる



前の2つのパラグラフで、特にdevopsプラクティスの人気の高さを考えると、操作とサポートが別々に扱われているのかもしれません（ちなみに、私は両手を使っています）。 devopsはこれらの問題を解決しませんか？



問題は、多くの組織で操作とサポートがまだ別のチームによって実行されており、そのような組織ではマイクロサービスへの移行が停止する可能性が高いことです。



devopsをすでに実践している組織にとっては、すべてが複雑です。 開発者とオペレーターになることは同時に困難ですが（優れたプログラムを作成する必要があります）、コンテナーオーケストレーションシステム、特に急速に開発されているシステムのニュアンスも理解する必要がある場合は、非常に困難です。 ここで次のポイントに行きます。



私は真剣な経験が必要です



専門家がこの種の作業を行う場合、結果は素晴らしいものになります。 しかし、単一のモノリシックシステムの運用中に、すべてがスムーズではない組織を想像してください。 社内のシステムの数が増え、それによって運用が複雑になった場合に状況が良くなる理由の1つは何ですか？



はい、効果的な自動化、監視、オーケストレーションなどを備えています これはすべて可能です。 しかし、問題は通常、技術にあるのではなく、それを効果的に使用できる人々の不足にあります。 このようなスキルセットは今日大きな需要があり、優れた専門家を見つけるのは困難です。



実際のシステムでは、コンポーネント間の境界はしばしばあいまいです



マイクロサービスの長所を示すすべての例で、独立したコンポーネントについて説明しました。 ただし、多くの場合、単純に独立していません。 紙の上では、いくつかの主題領域は明確に描かれているように見えるかもしれませんが、特に掘り下げる価値があります-そして、問題は予想よりも複雑であることがわかります。



これは、物事が本当に複雑になる可能性がある場所です。 システム内のコンポーネントの境界が明確に定義されていない場合、これが起こります：理論的には、サービスは互いに独立してデプロイできますが、実際には相互依存関係によって接続されていることが判明しているため、サービスセットをグループ全体としてデプロイする必要があります。



これは、一貫したバージョンのサービス、つまり信頼性が証明され、相互作用が検証されたサービスを管理する必要があることを意味します。 しかし、この場合、新しい機能を開発するには、多くのサービスの同時展開を慎重に調整する必要があるため、独立して展開可能なシステムについてはもう話しません。



ステータスの問題はしばしば無視されます



前の例で、機能を展開するには、異なるサービスの複数のバージョンを単一のグループとして同時に展開する必要があるかもしれないと述べました。 青/緑の展開オプション（ほとんどのオーケストレーションプラットフォームで簡単に実行されます）などの賢明な展開手法を使用する場合、または複数のバージョンのサービスが並行して使用される場合-チャンネル自体が消費するバージョンを決定する場合、この問題は削除されると思われがちです使用する。



サービスが状態を保持しない場合、このような手法は多くの問題を解決できます。 しかし、率直に言って、このようなサービスの操作は簡単です。 実際、ステートレスサービスを使用している場合は、マイクロサービスの設定を一切変更せずに、すぐにサーバーレスモデルを試してください。



実際、多くのサービスでは、 状態を維持する必要があります 。 ビデオ共有用のプラットフォームを使用して例を続けると、そのようなサービスの例としてはサブスクリプションがあります。 サブスクリプションサービスの新しいバージョンでは、異なる構成のサブスクリプションデータベースに情報を保存できます。 両方のサービスを並行して運用する場合、2つのスキームがシステムで同時に機能します。 緑/青の展開を実装しており、他のサービスがこの新しい構成で発行されたデータに依存している場合、それらを同時に更新する必要があります。 サブスクリプションサービスを展開できず、ロールバックする必要がある場合、依存サービスをすべてロールバックする必要があり、雪崩のような結果につながる可能性があります。



繰り返しになりますが、NoSQLデータベースを使用すると、スキーマに関するこのような問題はなくなると思われがちですが、そうではありません。 特定のスキーマを課さないデータベースは、回路なしのシステムを生成しません-通常、このようなスキーマの管理は、データベースレベルではなくアプリケーションレベルで実装されます。 この場合の重要な問題は、データの構成とその展開方法を理解することです。 どこからでも彼女から逃げることはできません。



コミュニケーションの困難はしばしば無視されます。



相互依存サービスの広範なネットワークを構築する場合、それらの間でアクティブな通信を提供する必要がある可能性があります。 さらにいくつかの問題があります。 まず、潜在的な障害点の数が大幅に増加しています。 一部のネットワークコールは通過しないことに注意してください。これは、あるサービスが別のサービスを呼び出す場合、最小限の試行回数でプログラムする必要があることを意味します。

サービスが他の多くのサービスを引き起こす可能性があるため、困難な状況に陥っています。



ユーザーがビデオプラットフォームに新しいビデオをアップロードしたとします。 ダウンロードサービスを開始し、データをトランスコードサービスに転送し、サブスクリプションを更新し、推奨事項を更新する必要があります。 これらのすべての課題にはある程度オーケストレーションが必要であり、通話が終了しない場合は、もう一度それを実現する必要があります。



この再試行ロジックは管理が難しい場合があります。 潜在的な障害点が多すぎるため、操作の同期実行は多くの場合実行不可能です。 この場合、非同期パターンを使用して通信を編成するのが最も合理的です。 この場合の最も難しいことは、定義上、非同期通信を備えたシステムでは、状態を保持したシステムを構築する必要があるということです。 前の段落で述べたように、ステートフルおよび分散状態システムの管理は非常に困難です。



マイクロサービスシステムのサービス間の通信がメッセージキューを使用して実行される場合、これらのサービスを「結合」する大きなデータベース（メッセージキューまたはブローカー）が基本的にあります。 繰り返しますが、一見すると、そのようなシステムは問題に思えないかもしれませんが、後であなたに戻ってきます。 バージョンXのサービスは特定の形式でメッセージを記録する場合があり、送信者サービスが送信されたメッセージの詳細を変更した場合、そのメッセージに依存する他のサービスも更新する必要があります。

多くの異なる形式のメッセージを処理できるサービスを作成できますが、これらのサービスの管理は困難です。 この場合、新しいバージョンのサービスをデプロイするときに、異なるサービスが同じキューからのメッセージを処理しようとする状況が発生する可能性があり、場合によっては異なるバージョンの送信サービスによって送信されます。 その後、複雑な境界線のケースが発生する可能性があります。 それらを回避するには、特定のバージョンのメッセージのみの存在を許可する方が簡単な場合があります。つまり、特定のサービスセットのバージョンセットを一貫した全体としてデプロイし、古いバージョンのメッセージが最初に破棄されるようにします。



ここでも、実際には、詳細を見ると、独立した展開はそれほど単純ではないことがわかります。



バージョン管理には注意が必要です



上記の問題を部分的に除去するには、バージョン管理を慎重に管理する必要があります。 繰り返しますが、semserverのような標準に固執すれば、この問題は解決されるようです。 いいえ、解決しません。 Semserverに準拠することは合理的ですが、それでもサービスとAPIのバージョンを追跡する必要があり、どれが相互作用できるかを確認してください。



このような問題は非常にすぐに非常に複雑になり、どのサービスが相互に正常に相互作用するかを自分で想像することはできなくなります。

Javaモジュール、Cライブラリなどで構成されるシステムで依存関係を管理するのがどれほど難しいかは有名です。 特定のオブジェクトによって消費される独立したコンポーネント間の競合の問題を解決するのは非常に困難です。



依存関係が静的であっても、それらは複雑であり、パッチの適用、更新、編集などが可能です。 ただし、依存関係自体がライブサービスである場合、単純に更新することはおそらくすでに不可能です。 一度に多くのバージョンを駆動する必要があります（関連する問題については上記で説明しています）。完全に更新されて修正されるまでシステムを停止する必要があります。



分散トランザクション



操作全体でトランザクションの整合性を維持したい状況では、マイクロサービスが本当に頭痛の種になる可能性があります。 それぞれが失敗する可能性のある多くの小さなモジュールのオーケストレーション、分散状態で作業することは困難です-それは別のタスクです。



操作をべき等にすることでこの問題を回避しようとすることができ、再試行などの可能性を提供します。多くの場合、これは機能します。 ただし、トランザクションの2つの結果（「失敗」または「失敗」）のみを実装する必要があり、中間状態を提供しないシナリオがあります。 マイクロサービスを使用してこのようなシステムを実装しようとする、またはそのような操作の価格は非常に高くなる可能性があります。



マイクロサービスは偽装されたモノリスになります



はい、単一のサービスとコンポーネントを個別にデプロイできますが、ほとんどの場合、Kubernetesなどの何らかのオーケストレーションプラットフォームを使用する必要があります。 GoogleのGKEやAmazonのEKSなどのマネージドサービスを使用すると、複雑なクラスター管理を大幅に自動化できます。



ただし、クラスタを自分で管理する場合は、障害が許容できない大規模で複雑なシステムを扱っています。 はい、個別のサービスには上記のすべての利点がありますが、クラスターを非常に慎重に管理する必要があります。 そのようなシステムの展開は難しく、更新は困難であり、障害後の復元は困難などです。

多くの場合、基本的な利点は消えませんが、システムを単純化せず、別の大規模で複雑なシステムの管理に関連する追加の困難を過小評価しないことが重要です。 はい、マネージドサービスは便利ですが、その多くが登場したばかりです（たとえば、Amazon EKSは2017年末にのみ登場しました）。



最後に：マイクロサービスとアーキテクチャを混同しないでください



この記事では、「a」という言葉を使用しないように具体的に試みました。 しかし、この記事を読んだ（共著）私の友人Zoltanは、非常に重要なことに気づきました。

マイクロサービスアーキテクチャは存在しません。 マイクロサービスは、コンポーネントを実装するためのもう1つの原則にすぎません。 システム内のマイクロサービスの有無は、そのアーキテクチャ上の問題が解決されたことを意味するものではありません。



多くの点で、マイクロサービスは、システム設計そのものではなく、パッケージングと運用に関連付けられる可能性が高くなります。 そのようなシステムを設計するとき、最も重要なタスクの1つは、コンポーネントの有能な輪郭を描くことです。



サービスのサイズに関係なく、サービスがDockerコンテナにパッケージされているかどうかに関係なく、要素のシステムをどのようにまとめるかを常に考えることが重要です。 単一の答えはありません;常に多くのオプションがあります。