Docker実装のマイクロサービス

Amazon fargateを使用したDockerコンテナーを使用した最初のマイクロサービスを作成しています。Spring Bootを使用した実装レベルには多くの疑問があります

私たちはプロジェクトに複数のマイクロサービスを用意します。すべてのマイクロサービスを単一のコンテナーで作成することは良い習慣ですか、それとも個別のマイクロサービス用に個別のDockerコンテナーを作成する必要がありますか。費用対効果の高い方法で単一のコンテナを使用していますが、それが将来のプロジェクト構造に問題を引き起こすのでしょうか？

私たちはアプリケーションをAWSファーゲートにデプロイすることを計画しており、私たちのアプリケーションは将来拡張する大きなオプションがあり、約100から150の異なるマイクロサービスを期待しています。この場合、これらのすべてのマイクロサービスを別のコンテナーにアップロードするのも費用対効果が高いですか？

マイクロサービスで覚えておくべき最も重要なことは、マイクロサービスは主に技術的な問題を解決することではなく、組織の問題を解決することです。したがって、組織でマイクロサービスを使用する必要があるかどうか、およびそれらのサービスをどのように展開するかを検討するときは、組織にマイクロサービススタイルで解決される問題があるかどうかを確認する必要があります。

アーキテクチャに関する質問への答えは、テクノロジチームの規模、組織構造、製品の古さ、現在の展開方法、およびそれらが中期的にどのように変化するかによって大きく異なります。

例として、あなたの組織が：

• 技術スタッフは25人未満で、
• 1つまたは2つのチームに編成され、
• それぞれが製品のどの部分でも機能します
• 生後12ヶ月未満で
• そして定期的に（例えば、毎日、毎週、毎月）一度にすべて展開されます、
• そして組織は急速に成長するつもりはありません、

次に、ほぼ間違いなく今のところマイクロサービスを忘れたいと思います。このような状況では、チームはまだドメインについて学習しているので、システムを分散アーキテクチャに分割するための優れた方法を実際に理解するために知っておく必要があるすべてを知っているとは限りません。つまり、彼らが今それを分割した場合、おそらく境界を後で変更したいと思うでしょう。それは、すでに分散システムがある場合、モノリスでははるかに単純ですが、非常に高価になります。さらに、システムのどの部分でもすべて作業（およびサポート）できる小さなチームしかいないため、個々のチームが個々のサービスを展開および保守できるプラットフォームの構築に投資する理由はほとんどありません。この段階の組織は通常、チームを自律的にして高スケーリングで復元力のあるアーキテクチャを構築するのではなく、顧客を見つけて製品をすばやく反復すること、おそらく製品をピボットすることさえはるかに重視します。現時点ではモノリシックアーキテクチャは理にかなっていますが、APIによって適用される明確なコンポーネント境界とカプセル化されたデータアクセスを備えた適切に設計されたモノリスは、後でサービスを個別のプロセスに簡単に引き出すことができます。

もう少し詳しく見て、次のような組織について考えてみましょう...

• 50人以上の技術スタッフ、
• 7チームに編成され、
• それぞれが製品の特定の領域でのみ機能し、
• 3歳です
• また、他のチームが行っていることとは無関係に作業を展開したいチームがあります。

そのような組織は間違いなく分散型アーキテクチャを構築する必要があります。そうしないと、代わりにこれらのすべてのチームがモノリスで作業していると、チームは作業を調整する必要があり、1つのチームが新機能のQAを完了するまでリリースが遅れ、パッチが適用されるなど、あらゆる種類の組織上の問題が発生します。スタッフと顧客にとって大きな手間となる展開。さらに、成熟した製品の場合、組織は、ドメインとチームの両方（この順序で、Conwayの法則を参照）を賢く自律的なユニットに分割して、調整を最小限に抑えながら進歩できるようにするために、ドメインについて十分に知っている必要があります。

すでにマイクロサービスを選択しているようです。上のスケールのどこに座っているかによって、その決定をもう一度見たいと思うかもしれません。

マイクロサービスを使用して開発を続け、それらをすべて1つのコンテナーにデプロイする場合は、何も問題がないことを確認してくださいそれがあなたの組織の現在の働き方に合っているかどうか。今後、プロジェクト構造に問題が発生しますか？まあ、あなたが成功して組織が成長した場合、特にチームがサービスの所有を開始し、アプリケーション全体をデプロイせずにサービスだけをデプロイしたい場合、おそらくこの単一コンテナのデプロイメントが最適ではなくなる時期が来るでしょう。 。しかし、その自律性は余分な作業と複雑さを犠牲にして得られ、現時点ではメリットがないかもしれません。それが将来のシステムにとって適切なアプローチではないからといって、それが今日の適切なアプローチではないという意味ではありません。秘訣は、それを監視し、追加の投資をいつ行うべきかを知ることです。

マイクロサービスに単一のコンテナーを使用している場合は問題ありませんが、マイクロサービスの主な目的は、各サービスを個別に維持することであり、各サービスは疎結合であり、各サービスには個別のデータベースが必要です（サービスアーキテクチャごとにデータベースを実現する場合）。したがって、このことを実現するために、別のコンテナーでサービスを実行し、Docker SwarmまたはKubernetesを使用してそれらのサービスを調整してください。私はコストの問題を知っていますが、正しく行うと、マイクロサービスアーキテクチャの威力がわかります。