Docker実装のマイクロサービス
Amazon fargateを使用したDockerコンテナーを使用した最初のマイクロサービスを作成しています。 Spring Bootを使用した実装レベルには多くの疑問があります
プロジェクトには複数のマイクロサービスを用意します。すべてのマイクロサービスを1つのコンテナーで作成するのが良い方法ですか、それとも個別のマイクロサービス用に個別のDockerコンテナーを作成する必要がありますか費用対効果の高い方法で単一のコンテナを使用していますが、それが将来のプロジェクト構造に問題を引き起こすのでしょうか？
私たちはアプリケーションをAWSファーゲートにデプロイすることを計画しており、私たちのアプリケーションは将来拡張する大きなオプションがあり、約100から150の異なるマイクロサービスを期待しています。この場合、これらのすべてのマイクロサービスを別のコンテナーにアップロードするのも費用対効果が高いですか？
マイクロサービスで覚えておくべき最も重要なことは、マイクロサービスは主に技術的な問題を解決することではなく、組織の問題を解決することです。したがって、組織がマイクロサービスを使用する必要があるかどうか、およびそれらのサービスがどのようにデプロイされるかを調べる場合、組織にマイクロサービススタイルが解決する問題があるかどうかを調べる必要があります。
したがって、アーキテクチャに関する質問への答えは、主にテクノロジーチームの規模、組織構造、製品の古さ、現在の展開方法、およびそれらが中期的にどのように変化するかによって異なります。
例として、あなたの組織が：
- 25人未満の技術スタッフがいる
- 1つまたは2つのチームに編成され、
- それぞれが製品のどの部分でも機能します
- 生後12ヶ月未満で
- 定期的に（たとえば、毎日、毎週、毎月）一度にすべて展開されます。
- そして組織は急速に成長するつもりはありません、
次に、ほぼ間違いなく今のところマイクロサービスを忘れたいと思います。このような状況では、チームはまだドメインについて学習しているので、システムを分散アーキテクチャに分割するための優れた方法を実際に理解するために知っておく必要があるすべてを知っているとは限りません。つまり、彼らが今それを分割した場合、おそらく後で境界を変更したいと思うでしょうし、すでに分散システムを持っている場合は、モノリスではるかに単純である一方で、それは非常に高価になります。さらに、システムのどの部分でもすべて作業（およびサポート）できる小さなチームしかいないため、個々のチームが個々のサービスを展開および保守できるプラットフォームの構築に投資する理由はほとんどありません。この段階の組織は、通常、チームを自律的にして高スケーリングで復元力のあるアーキテクチャを構築するのではなく、顧客の発見と製品の迅速な反復、さらには製品のピボットにさえはるかに関心があります。現時点ではモノリシックアーキテクチャは理にかなっていますが、APIによって適用される明確なコンポーネント境界とカプセル化されたデータアクセスを備えた適切に設計されたモノリスは、後でサービスを個別のプロセスに簡単に引き出すことができます。
もう少し詳しく見て、次のような組織について考えてみましょう...
- 50人以上の技術スタッフ、
- 7チームに編成され、
- それぞれが製品の特定の領域でのみ機能し、
- 3歳です
- また、他のチームが行っていることとは無関係に作業を展開したいチームがあります。
そのような組織は間違いなく分散型アーキテクチャを構築する必要があります。そうしないと、代わりにこれらのすべてのチームがモノリスで作業していると、チームは作業を調整する必要があり、1つのチームが新機能のQAを完了するまでリリースが遅れ、パッチが適用されるなど、あらゆる種類の組織上の問題が発生します。スタッフと顧客にとって大きな手間となる展開。さらに、成熟した製品の場合、組織は、ドメインとチームの両方（この順序で、Conwayの法則を参照）を賢く自律的なユニットに分割して、調整を最小限に抑えながら進歩できるようにするために、ドメインについて十分に知っている必要があります。
すでにマイクロサービスを選択しているようです。上のスケールのどこに座っているかによって、その決定をもう一度見たいと思うかもしれません。
マイクロサービスを使用して開発を続けながら、すべてを1つのコンテナーにデプロイする場合は、それは何も問題ありませんが組織の現時点での動作に適している場合に注意してください。今後、プロジェクト構造に問題が発生しますか？まあ、あなたが成功して組織が成長した場合、特にチームがサービスの所有を開始し、アプリケーション全体をデプロイせずにサービスだけをデプロイしたい場合、おそらくこの単一コンテナのデプロイメントが最適ではなくなる時期が来るでしょう。 。しかし、その自律性は余分な作業と複雑さを犠牲にして得られ、現時点ではメリットが得られない可能性があります。それが将来のシステムにとって適切なアプローチではないからといって、それが今日の適切なアプローチではないという意味ではありません。秘訣は、それを監視し、追加の投資をいつ行うべきかを知ることです。
マイクロサービスに単一のコンテナーを使用している場合は問題ありませんが、マイクロサービスの主な目的は、各サービスを個別に維持することであり、各サービスは疎結合であり、各サービスには個別のデータベースが必要です（サービスアーキテクチャごとにデータベースを実現する場合）。したがって、このことを実現するために、別のコンテナーでサービスを実行し、Docker SwarmまたはKubernetesを使用してそれらのサービスを調整してください。私はコストの問題を知っていますが、正しく行うと、マイクロサービスアーキテクチャの威力がわかります。