[토이프로젝트] 스프링 클라우드 기반 MSA 앨범 판매 사이트

작년 초에 MSA에 대해 공부를 진행 했었다.

실습용으로 가벼운 프로젝트를 하나 생성했다.

0. 프로젝트로 얻은 경험

1. 도커에 대한 두려움이 많이 사라졌다.

-> 도커허브에서 필요한 이미지를 사용, 빌드, 허브에 커밋 정도..

 

2. 도커와 도커의 네트워크에 대한 기초 지식을 조금이나마 쌓을 수 있었다.

-> 도커 네트워크를 호스트외에 브릿지로 구성하여 포트 충돌 방지

 

3. 도커를 어느 부분에 사용해야 할지 어느정도 알 수 있었다.

-> 주로 배포를 목적 이미지 빌드용으로 사용한다.

 

4. MSA SAGA 패턴 학습

-> 트랜잭션 기반에서 이벤트 기반으로 서로 다른 서버간의 데이터 처리

예시로 서버가 서로 다르기 때문에 하나의 트랜잭션에서 작업이 불가하고 롤백도 구성하기 어려워 에러 발생시 보상 이벤트를 발행

 

5. 카프카 기본 학습

 

5.1 서버가 서비스 별로 존재하며 각 서비스 마다 DB 사용 시 Pub, Sub를 통해서 동기화 처리 ( 고려할게 너무 많아서 실제로 적용 하기는 많이 힘들 것 같다 )

정합성이 깨진다면 속도가 빨라도 의미가 없듯이 그냥 마음 편하게 비관,낙관 락을 거는게 낫다고 생각한다.

예시로 한개의 서비스에서 DB변화가 일어나면 해당 정보를 다른 서비스 DB에 반영 하여 추가해준다.

 

5.2 서버는 서비스 별로 존재하지만 하나의 DB로 구성 ( Kafka DB connector )

DB는 단일로 두며 여러 서비스에 DB에 접근시 하나의 통로를 두어 이벤트를 수신

 

6. resilience4j

서킷 브레이크 관리 

-> MSA에서 제일 중요한 부분 중 하나이다. 특정 서비스에서 이벤트를 수신하지 못할 경우 무한 호출을 방지 하고 어떤 방법으로 대응할지 설정한다.

 

7. zipkin, prometheus, grafana

 

7.1 zipkin은 traceId를 통해서 서비스간의 오류를 추적할 수 있다.

7.2 prometheus 매트릭 정보를 수집 ( 특정 시간 마다 서버의 정보 수집 시간 조정 필요 부하를 줄 수 있음 )

7.3 grafana prometheus로 수집한 정보 시각화하는 툴 ( 특정 서비스 호출 횟수, 클러스터 리소스 수집 등.. )

 

1. MSA 장점 ( 개인 생각 )

1. 서비스 별로 관리 되어 원하는 서비스 인스턴스를 증가 시킬 수 있고 특정 서비스가 죽었다고 해서 큰 지장이 없을 수 있다.

2. 특정 서비스 단위에서만 배포사항이면 다른 서비스와 같이 배포 할 필요가 없다.

( 장점이자 단점이 될 수 있을 구조인 것 같다 만일 여러 서비스가 같이 배포 되야 하는 작업인 경우 배포 방법은 선택이 아닌 강제 카나리 배포가 되지 않을까 싶다.)

3. 객체지향에서 책임과 역할의 분리에서 서버 구조를 본다면 매우 이상적인 것 같다.

 

2. MSA 단점 ( 개인 생각 )

1. 모놀리식 구조 보다 훨씬 복잡하고 정확히 구성 되어 있지 않으면 예상치 못한 문제가 발생해도 블랙홀 예외 처럼 해결 하기 쉽지않을 것 같다. (zipkin 활용)

2. 구성은 모놀리식보다 조금 더 어렵다. 다만 관리가 어렵다. 쿠버네티스를 안쓴고 스프링 클라우드면 더 수동적으로 힘들지 않을까 생각이 된다.

3. 모놀리식에 비해 복잡하고 구성하기 어렵다는게 단점이다.

4. 모든 예외에 대해 비관적으로 좁혀서 모두 대응 할 수 있는 경우는 없다고 생각한다. 크리티컬한 문제는 좁혀 놓고 그 외에 예상치 못한 문제에 대해서는

해결 할 수 있도록 알림, 로그를 구성해야 MSA를 사용 할 준비가 되어 있다고 생각이 든다.

고려가 안되면 그냥 모놀리식 서버 인스턴스 증설로 버티는게 낫지 않나 싶다.

 

지금까지 도커를 사용하면 느낀점

 

1. 도커라는 컨테이너 내부에서 작업 가능 여부

이부분은 도커를 공부하면서 항상 생각했다.

물론 도커 내부에서 작업을 진행할 수 있다 볼륨 마운트를 통해서 변경 사항도 실시간으로 확인 할 수 있다.

환경에 따라 다르겠지만 사실상 로컬에서 개발 하고 도커 이미지로 빌드한 후에 배포용으로 사용하는게 제일 좋은 방법인 것 같다.

도커 내부에서 볼륨 마운트로 개발 하기에는 한계가 있다. 매번 필요한 정보를 마운트 해줘야하는데 정말 불필요한 작업이다.

로컬에서 빠르게 개발하고 도커를 빌드하는게 제일 좋은 방법인 것 같다.

 

2. 도커의 가장 큰 장점

도커는 컨테이너 기술이기 때문에 JVM과 유사하다고 생각한다.

어느 환경에서나 도커만 설치 되있다면 docker run 명령어 한줄로 실행이 가능하다.

또한 원하는 기술을 컨테이너에 접속해 세팅해두고 git 처럼 커밋후 허브에 푸쉬할 수 있다. 이런 점이 배포에서 큰 장점이된다.

이미지를 받을때 이미지가 레이어 구조로 구성되어 같은 레이어 정보가 있으면 무시하고 필요한 정보만 받아서 빠르게 이미지를 받을 수 있다.

예시 ) java 17을 처음 받을때보다 java 11을 받고 받으면 훨씬 빠르게 이미지를 내려 받는다.

 

3. 도커의 네트워크

도커 네트워크는 mac DeskTop용으로 사용하지만 않는다면(VM으로 돌기때문에 도커 네트워크 사용이 어렵다)

쉽게 호스트 네트워크와 분리하여 사용 가능하다.

브릿지 네트워크를 생성해 호스트 네트워크 대역과 포트 충돌을 어느정도 피할 수 있어 큰 장점이다.

원하는 포트만 호스트에 포워딩하여 사용 할 수 있다.

 

4. 쿠버네티스는 1.20버전 이후 도커를 지원하지 않는데 사용하는 이유

도커말고 다른 컨테이너 기술 사용해도 된다. 쿠버네티스는 CRI용으로 도커가 적합하지 않다고 판단했고 실제 성능에서 증명이 됬다.

도커는 충분히 좋은 컨테이너 툴이다 다만 도커 엔진에는 이미지 빌드, 공유, 실행 등을 하여 다른 CRI 보다 무겁다.

도커엔진에는 이런 불필요한 도구들이 존재하기때문에 쿠버네티스가 CRI-O, containerd를 사용한다.

CRI-O와 containered는 컨테이너 런타임 인터페이스로 컨테이너를 띄우기 위한 도구다 (이미지를 빌드 불가능)

따라서 쿠버네티스에서 젠킨스 사용시 Kaniko를 사용하여 도커 이미지를 빌드하고 허브에 푸쉬했다.

 

3. 인프런에서 참고한 강의

SpringCloud 강의

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4/dashboard

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의

 

 

REST API 강의 (HAL 구조)

https://www.inflearn.com/course/spring-boot-restful-web-services

[개정판 2023-11-27] Spring Boot 3.x 를 이용한 RESTful Web Services 개발 - 인프런 | 강의

 

도커 강의

https://www.inflearn.com/course/%EB%94%B0%EB%9D%BC%ED%95%98%EB%A9%B0-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%8F%84%EC%BB%A4-ci

따라하며 배우는 도커와 CI환경 [2023.11 업데이트] - 인프런 | 강의