모놀리식(Monolithic)에서 MSA으로 전환시 고려사항

Question: Java를 MSA로 구성할 때 고려해야할 점을 알려줘.

Answer:

1. 서비스 검색:
   • Kubernetes의 내장 서비스 검색이나 Consul 및 Eureka와 같은 도구와 같은 서비스 검색 메커니즘을 구현하여 마이크로서비스가 동적으로 서로 찾고 통신할 수 있도록 합니다.
2. API 게이트웨이:
   • API 라우팅, 인증, 요청/응답 변환을 관리하려면 API 게이트웨이(예: Netflix Zuul 또는 Spring Cloud Gateway) 사용을 고려하세요. API 게이트웨이는 마이크로서비스에 대한 수신 요청 처리를 단순화할 수 있습니다.
3. 구성 관리:
   • Spring Cloud Config 또는 HashiCorp Consul과 같은 중앙 집중식 구성 관리 도구를 사용하여 마이크로서비스 전체의 구성 설정을 관리하세요. 이를 통해 서비스를 재배포하지 않고도 구성을 수정할 수 있습니다.
4. 로깅 및 모니터링:
   • 강력한 로깅 및 모니터링 솔루션을 구현합니다. ELK Stack(Elasticsearch, Logstash, Kibana), Prometheus, Grafana와 같은 도구를 사용하면 Java 마이크로서비스에서 로그와 지표를 수집, 분석, 시각화할 수 있습니다.
5. 보안:
   • Java 마이크로서비스의 보안을 우선시하세요. OAuth2 또는 JWT와 같은 인증 및 권한 부여 메커니즘을 구현하고 전송 중인 데이터와 저장 중인 데이터에 암호화를 사용합니다. 코드 및 종속성의 취약성을 식별하려면 보안 검색 도구를 고려하십시오.
6. 데이터베이스 및 데이터 저장소:
   • 다중 언어 지속성과 같은 마이크로서비스 원칙에 부합하는 데이터베이스를 선택하세요. 특정 사용 사례에 따라 PostgreSQL, MySQL, MongoDB 또는 Cassandra와 같은 데이터베이스를 고려하세요. 필요에 따라 서비스별 데이터베이스 또는 공유 데이터베이스 전략을 사용합니다.
7. 이벤트 기반 아키텍처:
   • 마이크로서비스 간 비동기 통신을 위해 Apache Kafka, RabbitMQ 또는 AWS SNS/SQS와 같은 도구를 사용하는 이벤트 기반 아키텍처 채택을 고려해보세요. 이는 서비스를 분리하고 실시간 데이터 처리를 가능하게 하는 데 도움이 될 수 있습니다.
   • !!아래 장표는 배달의 민족 MSA 전환 사례입니다.
    

기존에는 API 기반으로 데이터 전달을 했다.

만약 리뷰 시스템 전달 기능이 장애가 나면 주문 시스템도 영향을 받는다.

 

주문을 이벤트 기반 데이터 전달로 변경했다.

뒷단 서비스에서는 원하는 데이터를 consume해서 사용한다.

만약 리뷰 시스템 전달 기능이 장애가 나도 주문 시스템은 전혀 영향을 받지 않고, 장애 복구가 된 후 다시 SQS의 이벤트를 consume하면 된다.

 

가게/업주가 RDB를 쓰고 있고 이벤트를 발행하면

성능이 중요한 가게 노출 서비스는 레디스, 다이나모디비를 쓰고, 광고 리스팅은 엘라스틱 서치를 쓴다.

MSA는 본인 서비스에 필요한 DB를 쓸 수 있다는 장점이 있다.

출처: https://www.youtube.com/watch?v=BnS6343GTkY

 

8. 테스트 및 CI/CD:

• 단위 테스트, 통합 테스트, 엔드투엔드 테스트를 포함한 강력한 테스트 방식을 확립합니다. CI/CD(지속적인 통합 및 지속적인 배포) 파이프라인을 구현하여 빌드, 테스트 및 배포 프로세스를 자동화합니다.

 

---

 

MSA를 적용하면 모듈을 여러개로 분할하는 것이기 때문에 모듈간 복잡도가 높아질 수 있다.

복잡도를 해결할 수 있는 방법에는 Istio, API Gateway가 있다.

 

고객사례

 

출처: https://www.youtube.com/watch?v=-PElvestvl4&t=3246s

 

 

---

 

총 정리) MSA 전환 시 개발자 고려사항

Stateless Application

• https://www.redhat.com/en/topics/cloud-native-apps/stateful-vs-stateless
• https://kubernetes.io/docs/tutorials/stateless-application/guestbook/

기능별로 서비스를 분리하고 DB를 분리
DB 분리를 하지 않으면 DB 장애가 전체 장애로 번지기 때문에 MSA가 아니다.

 

 

API Gateway, Message Queue(이벤트 기반) 도입 고려

• API Gateway Pattern: https://wonit.tistory.com/489
• Message Queue Pattern: https://wonit.tistory.com/491

 

 

환경 설정 파일을 kubernetes configmap, secret으로 관리

Cloud Native하게 개발하기 위해서는 Java Properties의 값을 kubernetes Configmap 또는 Secret으로 구성해야 한다. 이러한 환경 설정을 애플리케이션 레벨에서 관리하게 될 경우 소스코드와의 Dependency가 많아지고, 환경 설정의 변경이 발생할 때마다 매번 소스코드 체크아웃부터 시작한다면, Cloud Native Architure의 신속한 반영을 저해하는 요소가 될 수있기 때문이다.

출처: https://waspro.tistory.com/681

 

 

Health Check 페이지 생성 (readinessProbe)

• https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

 

무중단 배포를 위한 Deployment 설정

• https://jenakim47.tistory.com/80

 

Cloud Native Architecture 기본 3가지

1. 확장 가능한 아키텍처 확장 가능한 아키텍처란 시스템의 수평적 확장에 유연한 구성을 말한다. 즉, 많은 사용자들이 몰리더라도 확장된 서버로 시스템을 부하 분산하고 가용성을 보장할 수 있게 한다.
   방법) Node AutoScaling, Pod AutoScaling
2. 탄력적 아키텍처 탄력적 아키텍처는 어떻게 본다면 확장 가능한 아키텍처의 개념과도 닮아 있는데, 서비스의 통합, 배포, 생성의 시간을 단축 시키는 것을 뜻한다. 이에 대한 방법으로는 위에서 본 CI/CD를 이용하기도 한다. 이런 분할된 서비스 구조에서 각각의 서비스는 stateless한 특성을 이용해서 서비스간의 종속성을 줄인다.
   방법) CI/CD
3. 장애 격리 특정 서비스가 오류가 발생하더라도 앞서 본 탄력적 아키텍처 덕분에 다른 서비스에 영향을 주지 않는다. 이렇게 장애를 격리하고 장애를 쉽게 대응할 수 있도록 하는게 바로 클라우드 네이티브 아키텍처의 장점이라고 할 수 있다.
   방법) 서비스 분리, DB 분리, 종속성 제거