Docker 구현의 마이크로 서비스

Amazon Fargate를 사용하는 Docker 컨테이너를 사용하여 첫 번째 마이크로 서비스를 작성 중입니다. 우리는 Spring Boot를 사용하는 구현 수준에 대해 많은 의구심을 가지고 있습니다.

우리는 프로젝트에 여러 개의 마이크로 서비스를 제공 할 것입니다. 모든 마이크로 서비스를 단일 컨테이너에 작성하는 것이 좋습니다. 또는 별도의 마이크로 서비스를 위해 별도의 Docker 컨테이너를 만들어야합니다. 비용 효율적인 방식으로 단일 컨테이너를 사용하지만 향후 프로젝트 구조에 문제가 있습니까?

AWS Fargate에 애플리케이션을 배포 할 계획이며 애플리케이션은 향후 확장 할 수있는 큰 옵션이 있으며 약 100 ~ 150 개의 서로 다른 마이크로 서비스가 필요합니다. 이 경우 모든 마이크로 서비스를 다른 컨테이너에 업로드하는 것이 비용 효과적입니까?

마이크로 서비스에서 기억해야 할 가장 중요한 것은 기술적 인 문제를 해결하는 것이 아니라 조직적인 문제를 해결한다는 것입니다. 따라서 조직에서 마이크로 서비스를 사용해야하는지 여부와 이러한 서비스가 어떻게 배포되는지를 살펴보면 조직에 마이크로 서비스 스타일이 해결하는 문제가 있는지 확인해야합니다.

그렇다면 아키텍처에 대한 질문에 대한 답변은 대부분 기술 팀의 규모, 조직 구조, 제품의 수명, 현재 배포 방식 및 중기 적으로 어떻게 변화 할 것인지에 달려 있습니다.

예를 들어 조직이 다음과 같은 경우 :

• 25 명 미만의 기술 직원이
• 1-2 개 팀으로 구성
• 제품의 어느 부분에서나 작동하는
• 12 개월도 안 된
• 정기적으로 (예 : 매일, 매주, 매월) 한 번에 모두 배포됩니다.
• 조직은 빠르게 성장하지 않을 것입니다.

그때 당신은 지금 당장 마이크로 서비스를 잊고 싶어합니다. 이와 같은 상황에서 팀은 여전히 ​​도메인에 대해 배우는 데 익숙하지 않으므로 시스템을 분산 아키텍처로 분할하는 데 좋은 방법이 무엇인지 실제로 이해하기 위해 알아야 할 모든 것을 모를 것입니다. 즉, 지금 분할하면 나중에 경계를 변경하고 싶을 것입니다. 이미 분산 시스템을 사용하면 모노리스에서 훨씬 간단하지만 비용이 많이 듭니다. 또한 시스템의 모든 부분을 작업하고 지원할 수있는 소규모 팀만 있으면 개별 팀이 개별 서비스를 배포하고 유지 관리 할 수있는 플랫폼을 구축하는 데 투자 할 이유가 거의 없습니다. 이 단계의 조직은 일반적으로 팀을 자율적으로 구축하고 확장 성이 뛰어난 탄력적 인 아키텍처를 구축하는 대신 고객을 찾고 제품을 신속하게 반복하고, 제품을 피봇 팅하는 데 훨씬 더 관심을 가질 것입니다. 이 시점에서 모 놀리 식 아키텍처가 의미가 있지만API에 의해 명확한 구성 요소 경계가 적용되고 데이터 액세스가 캡슐화되어 잘 설계된 모놀리스는 나중에 별도의 프로세스로 서비스를 쉽게 끌어낼 수 있습니다.

조금 더 살펴보고 다음과 같은 조직을 생각해 봅시다.

• 50 명 이상의 기술 직원,
• 7 개 팀으로 구성되어
• 각각은 제품의 특정 영역에서만 작동합니다.
• 3 살인데
• 팀이 다른 팀의 작업과 독립적으로 작업을 배포하려고합니다.

이러한 조직은 확실히 분산 아키텍처를 구축해야합니다. 그렇지 않고 모든 팀이 단일체로 작업하는 경우 팀은 업무를 조정해야하는 팀, 한 팀이 새로운 기능에 대해 QA를 마치는 동안 릴리스가 지연되는 등 모든 종류의 조직 문제를 겪게됩니다. 직원과 고객에게 큰 번거 로움을줍니다. 또한 성숙한 제품을 사용하면 조직은 도메인과 팀을 순서대로 (Conway 's Law 참조) 합리적이고 자율적 인 단위로 분할하여 조정을 최소화하면서 진보를 이룰 수있는 도메인에 대해 충분히 알고 있어야합니다.

이미 마이크로 서비스를 선택한 것 같습니다. 위의 저울에서 어디에 앉 느냐에 따라 그 결정을 다시 방문하고 싶을 수도 있습니다.

마이크로 서비스로 계속 개발하고 싶지만 하나의 컨테이너에 모두 배포하려는 경우 그에 아무런 문제가 없음을 알고 있습니다현재 조직의 운영 방식에 적합하다면 향후 프로젝트 구조에 문제가 있습니까? 글쎄, 당신이 성공하고 조직이 성장한다면, 특히 팀이 서비스를 소유하기 시작하고 전체 응용 프로그램을 배포하지 않고 서비스 만 배포하려는 경우이 단일 컨테이너 배포가 더 이상 적합하지 않을 때가 올 것입니다. . 그러나 그 자율성은 추가 작업과 복잡성의 대가를 치르며,이 시점에서는 아무런 이점도 제공하지 않을 수 있습니다. 미래에 시스템에 대한 올바른 접근 방식이 아니라고해서 이것이 오늘날의 올바른 접근 방식이 아님을 의미하지는 않습니다. 비결은이를 주시하고 언제 추가 투자를해야 하는지를 아는 것입니다.

마이크로 서비스에 단일 컨테이너를 사용하지만 마이크로 서비스의 주요 목표는 각 서비스를 개별적으로 유지 관리하는 것입니다. 각 서비스는 느슨하게 연결되고 각 서비스에는 별도의 데이터베이스가 있어야합니다 (서비스 아키텍처 당 데이터베이스를 달성하려는 경우). 따라서이 작업을 수행하려면 별도의 컨테이너에서 서비스를 실행하고 docker swarm 또는 Kubernetes를 사용하여 해당 서비스를 조정하십시오. 비용 문제는 알고 있지만 올바른 방식으로 수행하면 마이크로 서비스 아키텍처의 힘을 볼 수 있습니다.