2018マイクロサービスマッドネスデス

ご注意 perev。 ：経験豊富な開発者によって書かれたこの資料は、タイトルを見て、ご想像のとおり、マイクロサービスの概念を埋めることを目的としていません。 この記事は、マイクロサービスが「銀の弾丸」であり、それ自体がすべてのアーキテクチャおよび運用上の問題を解決することを決定した人々に対する合理的な警告です。 これを実証するために、著者は、すでにマイクロサービスを使用している、またはマイクロサービスに移行している今日のプロジェクトでよく遭遇する一般的な問題を収集して体系化しました。







近年、マイクロサービスは非常に人気のあるトピックになりました。 マイクロサービスマッドネスは次のようになります。

「NetflixはDevOpsが得意です。 Netflixはマイクロサービスを作成します。 そうすれば、マイクロサービスをやっているなら、DevOpsが得意です。」

マイクロサービスパターンを導入するために、特定の問題のコンテキストでマイナスとプラスが何をもたらすかを必ずしも理解せずに多大な努力が払われた非常に多くの場合があります。



マイクロサービスとは何か、そのパターンが非常に魅力的である理由、およびその使用方法の主な難点について詳しく説明します。 最後に、 お客様のニーズに対するマイクロサービスパターンの関連性を検討する際に自問する必要がある簡単な質問で終わります。 これらの質問は、記事の最後に記載されています。

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

基本から始めましょう。 仮想ビデオ共有プラットフォームの可能な実装の例を次に示します。最初にモノリシック表現（1つの大きなブロック）で、次にマイクロサービスで。







2つのシステムの違いは、最初のシステムが単一の大きなブロックであるということです。 モノリス。 2番目は、小さな特定のサービスのセットです。 各サービスには固有の役割があります。



ダイアグラムがこのような詳細レベルで表示されると、その魅力がわかりやすくなります。 すべての潜在的な利点があります。



独立した開発 。 小さな独立したコンポーネントは、小さな独立したチームによって作成できます。 グループは、 トランスコードサービスに影響を与えることなく、またそれを知らなくても、 アップロードサービスの変更に取り組むことができます。 コンポーネントの調査に必要な時間が大幅に短縮され、新しい機能の開発が容易になります。



独立展開 。 個々のコンポーネントはそれぞれ独立してデプロイできます。 これにより、新機能を迅速にリリースし、リスクを軽減できます。 ストリーミングコンポーネントの修正または機能は、他のコンポーネントを展開することなく展開できます。



独立したスケーラビリティ 。 各コンポーネントは、互いに独立してスケーリングできます。 ユーザーの需要が高いときに、新しい転送が発生する場合、各コンポーネントをスケーリングする必要なく、 ダウンロードコンポーネントをスケーリングして負荷を増やすことができるため、スケーリングが柔軟になり、コストが削減されます。



再利用可能です。 コンポーネントは小さな特定の機能を実装します。 これは、他のシステム、サービス、または製品での使用に容易に適応できることを意味します。 トランスコードコンポーネントは、他のビジネス部門で使用したり、別のユーザーにトランスコーディングサービスを提供する新しいビジネスに変えたりすることもできます。



このレベルの詳細では、モノリシックモデルに対するマイクロサービスモデルの利点は明らかです。 もしそうなら、なぜパターンは今流行していますか？ 彼は私の人生のどこにいましたか？

すべてがとてもクールな場合、なぜこれまで誰もこれをやったことがないのですか？

この質問には2つの答えがあります。 最初の-彼らは実際に 、技術的な能力の範囲でした。 第二に、最近の技術的改善により、このアプローチを新しいレベルに引き上げることができました。



この質問への回答の準備を始めたとき、 長い説明があったので、別の記事でそれを選び出し、少し後で公開する方が良いでしょう。 ここでは、1つのプログラムから多くのプログラムへのパス、ESB （エンタープライズサービスバス、つまり「エンタープライズサービスバス」-約Transl。）とSOA （サービス指向アーキテクチャ、すなわち「サービス指向アーキテクチャ」 ）は省略されます。 -約Transl。） 、コンポーネント設計および境界付きコンテキスト（「制限されたコンテキスト」-ドメイン駆動設計からのパターン-約Transl。）など



このすべての代わりに、さまざまな方法でこれまですべてのことを行ってきましたが、最近の爆発的な成長を遂げたコンテナテクノロジー（特にDocker）およびオーケストレーションテクノロジー（Kubernetes、Mesos、Consulなど）によってのみパターンが大きくなりました技術的な観点から実装するのがより適切です。



マイクロサービスアプローチを実装する可能性を当然と考える場合、その必要性について慎重に検討する必要があります。 高度な理論的利点がありましたが、難点はどうですか？

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

マイクロサービスが非常に美しい場合、問題は何ですか？ 私が見た最も重要な問題のいくつかを以下に示します。

開発者の複雑さの増加

開発者の人生はずっと難しくなる可能性があります。 開発者が多くのサービス[ジャーニー]に影響する機能で作業したい場合、彼はすべてのサービスを自分のマシンで実行し、それらに接続する必要があります。 多くの場合、これは単一のプログラムを実行するよりも困難です。



この複雑さは、適切なツールの助けを借りて部分的に軽減できますが、システムを構成するサービスの数が増えるほど、システム全体の起動時に開発者が抱える困難が増えます。

運用の複雑さの増加

サービスを開発しないがサポートするチームは、潜在的な複雑さの爆発を経験します。 実行中の複数のサービスを管理する代わりに、数十、数百、数千のサービスを使用する必要があります。 より多くのサービス、相互作用するより多くの方法、潜在的な問題に対するより多くの機会。

DevOpsの複雑さの増加

前の2つのポイントを見ると、特に、DevOpsがプラクティスとして人気を博しているため（私は大きな支持者です）、運用と開発は別々に考えられているように見えます。 それでは、DevOpsのおかげで良くなっていませんか？



困難なのは、多くの組織がまだ開発チームと運用チームを分けていることであり、そのような場合、マイクロサービスの適応に苦労する可能性が高いでしょう。



すでにDevOpsを使用している組織の場合、事態はそれほど単純でもありません。 開発者とシステム管理者の両方になることはすでに困難ですが（優れたソフトウェアを作成するために重要です）、コンテナーオーケストレーションシステム、特に急速に開発されているシステムのニュアンスも理解する必要があります。 だから私は次のポイントに来ます。

必要な深刻な能力

作業が専門家によって行われた場合、結果は素晴らしいものになります。 しかし、単一のモノリシックシステムの作業ですべてが完璧ではない組織を想像してください。 システムの数が増えると、操作が複雑になり、状況が改善されるのはなぜですか？



はい、効率的な自動化、監視、オーケストレーションなどを備えています -これはすべて可能です。 ただし、技術が困難になることはめったにありません。通常、技術を効果的に使用できる人を探すことです。 そのようなスキルの需要は現在非常に大きく、それらを見つけることは容易ではありません。

通常、実際のシステムには明確に定義された境界がありません

マイクロサービスの利点を説明するために使用されるすべての例では、独立したコンポーネントについて話していました。 ただし、多くの場合、コンポーネントは単純に独立しているわけではありません。 紙の特定の領域がつながっているように見える場合、実際には、すべての詳細を掘り下げると、提案されたモデルよりもすべてがはるかに複雑であることが簡単にわかります。



ここですべてが非常に複雑になります。 境界が実際に明確に定義されていない場合、サービスの孤立したデプロイの理論的な可能性の場合でも、サービス間の相互依存関係がポップアップします。そのため、サービスセットをグループとしてデプロイする必要があります。



言い換えると、これは、互いに連携して検証およびテストされたサービスの一貫したバージョンを維持する必要があることを意味します。 新しい機能を展開するには、多くのサービスの展開を慎重に管理する必要があるため、実際にはシステムの一部は個別に展開できません。

ステートフルな複雑さはしばしば無視されます

前の例では、機能の展開時に複数のサービスの複数のバージョンを展開する必要が生じることがあります。 思いやりのある展開手法により、人生が楽になります。たとえば、青緑の展開[青/緑の展開] （サービスを調整するためにほとんどのプラットフォームで最小限の労力が必要です）や、ユーザーに適切なものを選択するオプションを備えたサービスの多くのバージョンの並行起動です。



サービスがステートレスである場合、これらの手法は多くの障害を取り除きます。 しかし、ステートレスサービスの操作は実際には非常に簡単です。 実際、ステートレスサービスがある場合、これらすべてのマイクロサービスをスキップし、サーバーレスモデルを使用することを検討することをお勧めします。



実際には、多くのサービスが状態を保存する必要があります。 ビデオ共有プラットフォームの例は、サブスクリプションサービスです。 サブスクリプションサービスの新しいバージョンが、新しい種類のデータベースにデータを保存するようにします。 両方のサービスが並行して実行されている場合、2つのスキームを同時に使用するシステムがあります。 青緑色の展開を行い、他のサービスが新しいフォームのデータに依存している場合は、それらを同時に更新する必要があります。 サブスクリプションサービスの展開が失敗してロールバックした場合は、これらのサービスもロールバックしてから「カスケード」する必要があります。



繰り返しますが、NoSQLの世界のデータベースでは、同様のスキーマ関連の問題はなくなると思われがちですが、そうではありません。 厳密なスキーマを必要としないデータベースは、システムにスキーマがないことを意味しません。本質的には、DBMSレベルではなく、アプリケーションレベルでスキーマを管理する必要があるからです。 データの性質とその変化を理解するという根本的な問題を根絶することはできません。

相互作用の複雑さはしばしば無視されます。

相互に依存するサービスの大規模なネットワークを作成しているため、サービス間相互作用のための広いフィールドが存在する可能性があります。 多くの困難があります。 まず、潜在的な障害が発生する場所がさらにあります。 ネットワークコールが機能しない可能性を予測する必要があります。つまり、あるサービスが別のサービスにアクセスするたびに、少なくとも試行を繰り返すようにする必要があります。 サービスが多くのサービスにアクセスする必要がある場合、状況はさらに複雑になります。



ユーザーが共有サービスにビデオをアップロードすることを想像してください。 ダウンロードサービスを開始し、データをトランスコードサービスに転送し、サブスクリプションを更新し、推奨事項を更新する必要があります。 これらすべての課題には特定のオーケストレーションが必要であり、何かが壊れた場合は、アクションを繰り返す必要があります。



繰り返し呼び出しのロジックは、管理が難しくなる可能性があります。 失敗点が多すぎるため、すべてを同期的に実行しようとすると失敗することがよくあります。 この場合、非同期相互作用パターンの使用がより信頼できるソリューションになります。 しかし、問題は非同期パターンのためにシステムがステートフルになることです。 そして最後の段落で述べたように、ステートフルシステムおよび分散状態のシステムを管理することは非常に困難です。



サービス間通信のためにマイクロサービスシステムでメッセージキューが使用される場合、基本的にすべてのサービスを結び付ける大きなデータベース（メッセージキューまたはブローカー）があります。 繰り返しますが、これは最初はすべて問題ではないように見えますが、回路はあなたに追いつき、自分自身に思い出させます。 サービスバージョンXは特定の形式でメッセージを書き込むことができるため、そのようなメッセージに依存するサービスも、送信サービスがメッセージ内の何かを変更したときに更新する必要があります。



多くの異なる形式のメッセージを処理するサービスを使用できますが、管理は困難です。 サービスの新しいバージョンをデプロイすると、2つのバージョンのサービスが同じキューからのメッセージを処理しようとし、場合によっては異なるバージョンの送信者サービスからもメッセージを処理しようとします。 これは、混乱した不適切な状況につながる可能性があります。 それらを回避するために、特定のバージョンのメッセージのみを許可する方が簡単であることが判明する場合があります。これは、サービスのセットに対して一貫したバージョンのセットをデプロイする必要があることを意味します。



これは、詳細に進むと、独立した展開が必ずしも意図したとおりに機能しないという考えを再確認します。

バージョン管理は複雑になる可能性があります

上記の障害を克服するには、バージョンを非常に慎重に管理する必要があります。 繰り返しますが、 semverのような標準に従うことで問題が解決すると信じる傾向があります。 そうではありません。 Semverは使用する価値のある契約ですが、相互作用する可能性のあるサービスとAPIのバージョンを追跡する必要があります。



すぐに重大な問題に直面し、実際にどのバージョンのサービスが実際に相互に連携しているかわからない状況に陥ることがあります。



NodeやJavaのモジュール、Cのライブラリなど、ソフトウェアシステムの依存関係を管理することがどれほど難しいかはよく知られています。 1つのエンティティが使用する独立したコンポーネントの競合に対処することは非常に困難です。



依存関係が静的であり、パッチの適用、更新、編集などが可能な場合、これらの問題に対処することは困難です。 稼働中のサービスが依存関係として機能する場合、それらを更新することはできません。複数のバージョンを実行する必要があります（上記の問題が発生します）。

分散トランザクション

操作中にトランザクションの整合性が必要な状況では、マイクロサービスが大きな痛みになる場合があります。 分散状態を扱うのは簡単ではなく、壊れる可能性のある多くの小さなコンポーネントはトランザクションオーケストレーションを本当に困難にします。



操作をi等にしたり、再試行メカニズムを提案したりするなどして、問題を回避しようとすることは魅力的に思えるかもしれません。 -多くの場合、それは動作します。 ただし、中間状態がなくても、成功または失敗したトランザクションが単に必要となるシナリオが存在する場合があります。 このタスクまたはマイクロサービスモデルでの実装の回避策の複雑さは非常に高くなる可能性があります。

マイクロサービスはマスクされたモノリスにすることができます

はい、特定のサービスとコンポーネントを分離してデプロイできますが、ほとんどの場合、Kubernetesなどのオーケストレーション用の何らかのプラットフォームが起動します。 GoogleのGKEやAmazonのEKSなどのマネージドサービスを使用すると、クラスターの管理の複雑さのほとんどが解決されます。



ただし、クラスターを自分で管理する場合は、大規模で複雑で重要なシステムで作業しています。 個々のサービスには上記のすべての利点がありますが、クラスターを慎重に管理する必要があります。 そのようなシステムの展開は困難であり、アップグレードは複雑であり、フェイルオーバーは複雑になる可能性があります。



多くの場合、全体的な利点は残りますが、別の大規模で複雑なシステムを管理することによって生じる追加の複雑さを単純化または過小評価しないことが重要です。 マネージドサービスは役立ちますが、多くの場合それらは若すぎます（たとえば、Amazon EKSは2017年末に発表されました）。

マイクロサービスの狂気の死！

慎重かつ慎重な決定を下すことで、狂気を避けてください。 そして、あなたがこれを行うのを助けるために、私はあなたがあなた自身に尋ねることができるいくつかの質問とそれらに対する答えの説明を準備しました。 ご注意 perev。 ：元の画像が翻訳され、以下のテキスト形式で表示されます。

1.チームサイズ

チーム全体を1つの大きなテーブルに着席させることは可能ですか？

• はい！ マイクロサービスはまだ必要ないかもしれません。 展開、開発、運用などに関連する困難は、おそらく優れたコミュニケーションと優れたアーキテクチャで簡単に解決され、マイクロサービスはあなたが抱えていない問題の解決策になることがあります。
• いや！ マイクロサービスが役立ちます。 大規模なチームまたは複数のチームがある場合、アーキテクチャのみを使用してコンポーネントの境界を厳密に定義することは困難です。 コンポーネントを分離されたサービスに分離すると、これらの境界を実現するのに役立ちます。

2.ステートレス/ステートフル

システムは主にステートレスですか？

• はい！ サーバーレスを検討してください。 システムが基本的にステートレスである場合は、おそらくマイクロサービスフェーズをスキップして、少なくとも部分的にサーバーレスに直接進むことができます。
• いや！ マイクロサービスは複雑さをもたらします。 これは、マイクロサービスを使用してはならないという意味ではありませんが、特にシステムが時間とともに変化するため、マイクロサービスを実装および管理することは容易ではないことに注意してください。

3.システムの「ユーザー」

1つのアプリケーションまたはサービスのソリューションを構築していますか？

• はい！ 注意してください-「ぼやけた」主題領域があるかもしれません。 収集するすべてが同じユーザーアプリケーションを対象としている場合、機能の構築には複数のサービスを同時に更新する必要があることがわかります。 マイクロサービスは適切かもしれませんが、サブジェクト領域の設計には非常に注意してください。
• いや！ マイクロサービスは非常に便利です。 さまざまなアプリケーションで使用されるシステムを設計している場合、マイクロサービスは、新しい「ユーザー」アプリケーションに新しい機能を迅速に提供するための非常に適切なパターンになる可能性があります。

4.依存関係

モノリシックな依存関係がありますか？

• はい！ パフォーマンスは問題を引き起こす可能性があります。 この場合、独立したスケーラブルなサービスは、依存関係のパフォーマンスが残るため、役に立たないでしょう。 主な利点の1つは関係ないことがわかります。 さらに、サービスの境界がより明確に定義されない場合があります。
• いや！ マイクロサービスは非常に便利です。 モノリスで底につかない場合、マイクロサービスを効果的に拡張するために必要な高度な独立性を実現できます。

5.コンピテンシー

コンテナ、オーケストレーション、DevOpsの専門家はいますか？

• はい！ マイクロサービスは非常に便利です。 適切な人員がいる場合は、マイクロサービスを勉強する必要があります。 利用可能なスキルにより、潜在的な困難に対処し、活用することができます。
• いや！ 最初に土壌をテストしてください！ 適切な能力がない場合、またはDevOpsで既存の問題がある場合は、頭の上に飛び乗ることができます。 概念実証として1つの単純なサービスを適応させることを検討してください。 ビジネスに重要ではないプロジェクトで必要な最初の経験を取得します。

すべての質問と回答（英語）を含む元のPDFをここからダウンロードします 。

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

この記事では「a」という言葉を意図的に避けました。 しかし、私の友人であるゾルタンは彼女をチェックして、非常に良い点を指摘しました。



マイクロサービスアーキテクチャは存在しません。 マイクロサービスは、コンポーネントの単なる別のパターンまたは実装であり、それ以上でもそれ以下でもありません。 それらがシステムで表現されているかどうかは、システムアーキテクチャの準備が整っていることを意味しません。



マイクロサービスは、多くの点で、システムアーキテクチャ自体よりもパッケージングと運用に関連する技術プロセスに関連しています。 コンポーネントの適切な境界は、エンジニアリングシステムの主要な課題の1つのままです。



サービスのサイズに関係なく、サービスがDockerコンテナにあるかどうかに関係なく、システムをどのように組み合わせるかについて常に慎重に検討する必要があります。 正しい答えはありませんが、多くの選択肢があります。

翻訳者からのPS

ブログもご覧ください。

• 「 Kubernetesの実装の難しさに関する新しいスタック統計 」;
• 「 小規模プロジェクトでのKubernetesでの経験 」 （Kubernetesの技術デバイスの紹介を含むビデオレポート）;
• 「 手頃な価格のサービスとしてKubernetesを使用したインフラストラクチャ 」
• 「 Kubernetesが必要な理由とPaaSよりも大きい理由 ";
• 「 サービスは何をメッシュであり、なぜ私は[クラウドアプリケーションmikroservisami用]、それが必要なのですか？ ";
• 「 Kubernetesのオペレーター：ステートフルアプリケーションの実行方法 」