리서치

[MSA] 11번가 Spring Cloud 기반 MSA로의 전환 정리

꾸준함. 2022. 10. 29. 09:45

개요

이전 게시글 https://jaimemin.tistory.com/2200에 이어서 이번 게시글에서도 인상 깊게 본 MSA 관련 유튜브 영상을 요약/정리해보겠습니다.

 

[MSA] 우아콘 2020 배달의민족 마이크로서비스 여행기 정리

개요 MSA 관련 리서치를 맡게 돼서 공부하는 도중 김영한 강사님이 발표해주신 우아콘 2020 영상을 인상 깊게 봐서 간단하게 요약/정리했습니다. 인프런 강의를 시청할 때도 느꼈지만 김영한 강사

jaimemin.tistory.com

이번 영상은 Naver D2에서 올려준 [11번가 Spring Cloud 기반 MSA로의 전환]이고 기존의 거대 Monolithic 한 프로젝트를 2017년부터 MSA 기반으로 마이그레이셔하면서 알게 된 기술적 내용과 현재 어떻게 시스템을 어떻게 운용하고 있는지 그리고 MSA 환경에 도움받았던 tool과 사용했던 코어 개념을 설명해주는 영상이었습니다.

Spring Cloud 2020 버전부터는 Sping Cloud Hystrix가 Resilience4J로 대체되었고 Spring Cloud Zuul 또한 Spring Cloud Gateway로 대체되었지만 기본적인 개념은 비슷하기 때문에 글이나 영상을 참고하여 현재 버전에 직접 도입하는데 어려움은 없을 것 같습니다.

 

Spring Cloud 기반 MSA 프로젝트에 투입되실 분들이나 혹은 개발 진행 중인 분들께 많은 도움이 되는 영상일 것 같습니다.

해당 영상 역시 풀 영상 시청 추천드립니다.

https://www.youtube.com/watch?v=J-VP0WFEQsY&t=71&ab_channel=naverd2 

11번가 Spring Cloud 기반 MSA로의 전환 - 지난 1년간의 이야기

 

 

1. MSA 전환 전

 

2016년 말 11번가

 

  1. 초대형 거대 Monolithic System
  2. 8년 넘게 사용해 온 낙후된 S/W Stack (경쟁사가 워낙 많았기 때문에 Monolithic 하게 퀵하게 개발할 수밖에 없었던 환경)
  3. 너무나 커진 200만 라인의 공통 모듈
  4. 폭증하는 트래픽으로 수년 내에 감당하기 힘들 것으로 예상되는 부하
  5. 많은 개발팀의 코드를 한 번에 배포
    • 매주 목요일 밤샘 정기 배포, 잦은 장애
    • 한 명의 실수 때문에 모든 시스템 롤백하는 상황 발생
  6. 개발자들이 새로운 기술을 접해 볼 기회 원천 봉쇄
    • Java 1.6, Spring 2.X 버전 or 외주 개발 Framework
    • 시스템끼리 강한 dependency가 있어 새로운 기술을 도입했을 때 어떠한 영향을 끼칠지 모르는 상태라 도전하기 힘든 환경
    • "나의 과감한 수정은 전사 장애다!"라는 말이 나올 정도로 새로운 기술 도입하기 위한 도전을 하기 힘든 환경
  7. IDE에 띄우는 것조차 버거운 개발 환경
    • 200만 라인의 공통 코드로 인해 항상 메모리 부족
  8. 나쁜 시스템이 나쁜 개발 문화를 양성하고 있어 MSA로 전환할 필요성을 절실하게 느낌

 

어떻게 MSA를 도입할 것인가를 고민 (어떻게 서버 분리를 진행할 것인가?)

 

  1. 잘 사용되지 않는 코드까지 수정할 필요가 있을까?
  2. 새로운 Architecture에 대한 검증과 운영 경험 축적 필요
  3. 재개발 중에도 Biz 요구사항은 계속 반영되어야 함

 

2. MSA 전환 시작 및 주요 개념 설명

 

Project Vine (11번가 점진적 MSA 전환 Project)

 

  1. Strangler Application Pattern
  2. 열대 우림 지역의 Strangler Vine에 차용
  3. Legacy 교살 전략
    • 새로운 Application은 독립된 API 서버로 개발
    • Legacy와 함께 운영
    • 위의 과정을 반복
  4.  Legacy 서버는 거대한 WAS 속에 모든 코드가 존재하는 구조였음 (장애에 취약)
    • MSA Platform을 만들면서 기존 코드는 놔둔 상태로 Rest Api로 때서 새로운 코드를 호출하는 구조로 점진적으로 변화를 가져감
    • 업무 도메인 별로 (혹은 더 잘게) 서버 분리
    • Legacy 코드에서는 새로운 API 서버들을 호출
    • 기존 코드와 새로운 API 호출은 DB Flag를 통해서 Switchable 하게 가져감

 

MSA 플랫폼 Solutions 선정

 

  1. 개발자들이 가장 친숙해하는 환경 SpringBoot에서 개발 진행
  2. MSA를 위한 Best Practice를 빠르게 적용하는 것이 필요했기 때문에 Production에서 검증된 Netfilx OSS 오픈소스 사용 (Spring Cloud Netflix)
  3. Spring Cloud Netflix에서 가장 중요한 개념 세 가지인 Hystrix, Ribbon, 그리고 Eureka를 중점적으로 설명 진행할 예정

 

2.1 Hystrix

 

  1. Netflix가 만든 Fault Tolerance Libray (장애 전파 방지 & Resilience)
  2. 기능적 관점에서 본 Hystrix의 주요 4가지 기능
    • Circuit Breaker
    • Fallback
    • Thread Isolation
    • Timeout
  3. Hystrix 적용하기
    • Hystrix Annotation 사용 (Hystrix Javanica, Spring Cloud Netflix에 포함)
    • @HystrixCommand와 같이 Annotation으로 사용할 수도 있고 HystrixCommand 클래스를 상속받아서 사용할 수도 있음
    • Hystrix Command를 호출할 때 벌어지는 일
      • 이 메서드를 Intercept 하여 대신 실행한다 (Thread Isolation)
        • 다른 Thread에서 실행
      • 메서드의 실행 결과 성공 혹은 실패(Exception) 발생 여부를 기록하고 통계를 냄 (통계에 따라 Circuit Open 여부를 결정) -> Circuit Breaker
      • 실패한 경우(Exception) 사용자가 제공한 메서드를 대신 실행 (Fallback)
      • 특정 시간 동안 메서드가 종료되지 않는 경우 Exception을 발생시킨다. (Timeout)
        • 대부분의 사용하는 Library에 timeout이 있는데 별도의 인터셉트하는 layer에서 timeout을 부여해야 하는가?
        • 사용하는 Socket Connect Timeout 값이 개발자가 부여한 timeout 값 대로 적용되지 않는 케이스가 많음, 많은 Library를 사용하는 경우 판단하기 어려움
  4. Hystrix - Circuit Breaker
    • (1) 일정 시간 동안 (2) 일정 개수 이상의 호출이 발생한 경우, (3) 일정 비율 이상의 에러가 발생하면 Circuit Open (호출 차단)
    • (4) 일정 시간 경과 후에 단 한 개의 요청에 대해서 호출을 허용하면 (Half Open)
    • 해당 호출이 성공하면 Circuit Close (호출 허용)
    • Hystrix Circuit Breaker는 한 프로세스 내에서 주어진 CommandKey 단위로 통계를 내고 동작
      • 즉, Circuit Breaker는 CommandKey 단위로 생성
      • 비즈니스 로직을 작성한 사람이 Circuit Breaker를 어떤 단위로 가져갈지가 중요 (너무 크게 잡지도 작게 잡지도 않아야 함)
    • 디폴트 설정으로는 10초간 20개 이상의 호출이 발생한 경우 50% 이상의 에러가 발생하면 5초간 Circuit Open 되어 호출 차단
  5. Hystrix - Fallback
    • Fallback으로 지정된 메서드는 다음의 경우에 원본 메서드를 대신 실행된다
      • Circuit Open
      • Any Exception (HystrixBadRequestException 제외)
      • Semapore/ThreadPool Rejection
      • Timeout\
    • 성능 테스트를 할 때 장애를 감추는 현상이 발생할 수 있으니 주의 필요
      • 11번가에서 실제 있었던 상황은 아래와 같음
      • 맨 앞 단의 Business Logic에서 장애가 발생해 Fallback 발생할 경우 어떠한 비즈니스 로직도 발생하지 않지만 정상적으로 수행한 것으로 보이는 케이스가 발생할 수도 있음
    • HystrixBadRequestException
      • 사용자의 코드에서 HystrixBadRequestException을 발생시키면 이 오류는 Fallback을 실행하지 않으며, Circuit Open을 위한 통계에도 집계되지 않음
      • 비즈니스 로직에서 문제가 발생하는 것이 아니라 Api를 호출하는 측에서 잘못된 파라미터의 전달과 같은 실수를 한 경우 HystrixBadRequestException을 Throw 하게 작성 필요
        • Circuit Breaker의 통계에 집계되어 Caller의 잘못으로 Circuit이 Open 되어 Fallback이 실행될 경우 개발 과정에서 오류를 인지하지 못할 수 있음
  6. Hystrix - Timeout
    • Hystreix에서는 Circuit Breaker 단위로 (CommandKey 단위로) Timeout을 설정할 수 있음
    • Default는 1초이기 때문에 api 응답 속도를 고려해서 timeout 설정 필요
      • Semaphore Isolation인 경우 - 제시간에 Timeout이 발생하지 않는 경우가 대부분
      • 간혹 여러 서버를 거쳐 api를 호출하는 구조일 경우 1초보다 더 오래 걸리는 케이스도 존재하기 때문에 적절하게 판단하여 설정
  7. Hystrix - Isolation
    • 두 가지 Isolation 방식을 Circuit Breaker 별도 지정 가능
      • Semaphore Isolation
        • Circuit Breaker마다 Semaphore가 붙어 있는 구조
        • 연동 시스템마다 최대 호출 횟수를 제어할 수 있음 (Semaphore 별로 최대 동시 요청 개수 지정)
        • Traffic 제어를 위해 사용됨
        • 최대 개수 초과 시 Sempahore Rejection 발생 (Fallback 실행)
        • Command를 호출한 Caller Thread에서 메서드 실행
        • Timeout이 제시간에 발생하지 못하는 문제 있음
          • 자바 1.0 시대에는 Thread.stop() 메서드가 존재했지만 지금은 존재하지 않음 (남이 Thread를 멈출 수 있었다. 현재는 시스템 불안정성을 야기할 수 있기 때문에 Deprecated)
          • 현재 자바 버전에서는 남의 Thread를 인위적으로 중단시킬 방법이 없고 유일한 방법은 Thread.interrupt() 호출
            • 실제 실행하는 로직이 Thread interrupt를 감지하고 InterruptedException을 발생시키는 경우만 Thread 중단 가능
            • Netflix Hystrix도 timeout 값이 지났다고 복잡한 루프를 돌고 있는데 중단 명령을 받고 Thread를 리턴하는 기능 제공할 수가 없음
      • Thread Isolation (Default)
        • Circuit Breaker 별로 사용할 Thread Pool을 지정 (ThreadPoolKey)
        • Circuit Breaker : ThreadPool = N : 1 관계 가능
        • 최대 개수 초과 시 Thread Pool Rejection 발생 - Fallback 실행
        • Command를 호출한 Thread가 아닌 Thread Pool에서 메서드 실행
        • "실제 메서드의 실행은 다른 Thread에서 실행되므로 Thread Local 사용 시 주의 필요"

 

2.2 Ribbon

 

  1. Netflix가 만든 Software Load Balancer를 내장한 RPC(REST) Library
    • Client Load Balancer with HTTP Client
  2. Spring Cloud에서는 Ribbon 클라이언트를 사용자가 직접 사용하지 않음
    • Spring Cloud의 HTTP 통신이 필요한 요소에 내장되어 있음
      • Zuul API Gateway
      • RestTemplate (@LoadBalanced)
      • Spring Cloud Feign - 선언적 Http Client
  3. L4 스위치, L7 잘되어있고 Amazon 환경에서 ELB 잘 되어 있는데 Ribbon을 왜 써야 하는가?
    • Ribbon은 대부분의 동작은 Programmable 함
      • Spring Cloud에서는 아래와 같은 BeanType으로 (Ribbon Client마다 모든 동작을 구현 가능) 
        • IRule - 주어진 서버 목록에서 어떤 서버를 선택할 것인가
          • Weight 부여 가능
          • 다양한 상황에서 현명하게 Load Balance 할 수 있도록 다양한 기능 제공
        • IPing - 각 서버가 살아있는가를 검사
        • ServerList<Server> - 대상 서버 목록 제공
        • ServerListFilter<Server> - 대상 서버들 중 호출할 대상 Filter
        • ServerListUpdater
        • IClientConfig
        • ILoadBalancer

 

2.3 Eureka

 

  1. Neflix가 만든 Dynamic Service Discovery
  2. 등록: 서버가 자신의 서비스 이름 (종류)와 IP 주소, 포트를 등록
  3. 조회: 서비스 이름 (종류)을 갖고 서버 목록을 조회
  4. 위 개념이 Ribbon과 결합되어 Ribbon이 서버 목록을 가져올 수 있도록 지원
  5. Eureka가 Enable 된 Spring Cloud Applicationd은
    • Server 시작 시 Eureka 서버에 자동으로 자신의 상태 등록 (UP)
    • 주기적 HeartBeat으로 Eureka Server에 자신이 살아 있음을 알림
    • Server 종료 시 Eureka 서버에 자신의 상태 변경(DOWN) 혹은 자신의 목록 삭제
    • Eureka 상에 등록된 이름은 'spring.application.name'
  6. Eureka + Ribbon in Spring Cloud
    • 하나의 서버에 Eureka Client와 Ribbon Client가 함께 설정되면 Spring Cloud는 다음의 Ribbon Bean을 대체
      • ServerList<Server>
        • 기본: ConfigurationBasedServerList
        • 변경: DiscoveryEnabledNIWSServerList
      • IPing
        • 기본: DummyPing
        • 변경: NIWSDiscoveryPing
    • 서버의 목록을 설정으로 명시하는 대신 Eureka를 통해서 Look Up 해오는 구현 (Infra Dependency 제거에 매우 유용)

 

3. Hystrix, Ribbon, Eureka 적용 in 11번가

  1. Hystrix, Ribbon, Eureka를 잘 적용하면 MSA 환경에서 Server 들간의 통신을 큰 문제없이 잘 될 것 같다는 생각을 함
  2. API Gateway
    • MSA 환경에서 API Gateway의 필요성
      • Single Endpoint 제공
        • API를 사용할 Client들은 API Gateway 주소만 인지
      • API의 공통 로직 구현
        • Logging, Authentication, Authorization
      • Traffic Control
        • API Quota, Throttling
  3. SK Planet은 자체 개발 API Gateway를 상용 운영 중이었던 상황
    1. 11번가를 제외한 서비스의 Open API를 제공
    2. Node.js / Koa Framework 기반
    3. 100% 자체 개발 from Scratch
    4. Logging, Authorization, Throttling 등등
    5. 100% 자체 개발한 API Gateway를 두고 Zuul을 도입해야 할까?
  4. Spring Cloud Zuul을 도입하기로 결심한 이유
    1. 여러 Benchmark를 돌린 결과 전환하기로 결심
    2. Spring Cloud Zuul은 Api Routing을 Hystrix, Ribbon, Eureka를 통해서 구현
    3. Spring Cloud와 가장 잘 Integration 되어있는 API Gateway
    4. Spring Cloud Zuul에서 routing 할 때 모든 API 호출은 Hystrix Command로 감싸서 호출되고 이 말은 즉슨 앞서 언급한 Hystrix의 4가지 장점을 고스란히 안게 됨
      • Hystrix Command 안에는 Ribbon Client가 존재하고
      • Ribbon Client는 Eureka Client로부터 실제 서버 목록을 얻어다 호출
      • API Gateway 입장에서 제일 귀찮은 점은 뒷단에 Endpoint 어느 서버에 traffic을 부여할지 관리하는 일인데 이를 Spring Cloud Zuul에서 자동으로 관리하고 뒷단 서비스가 죽더라도 앞단 API Gateway는 죽지 않는 최후의 보루가 생김 (Hystrix 덕분)
    5. API 요청들은 각각 HystrixCommand를 통해서 실행되며 각 API의 Routing은 Ribbon & Eureka의 조합으로 수행
    6. Spring Cloud Zuul에서 Hystrix ComandKey는
      • 각 서버군 이름 (Zuul 용어로 Service ID, Eureka에 등록된 서버군 이름)이 사용됨
    7. Spring Cloud Zuul에서 hystrix Isolation은 Semaphore Isolation을 기본으로 함 (Hystrix의 원래 Default는 Thread Isolation)
      • 특정 API 군의 장애(지연) 등이 발생하여도 Zuul 자체의 장애로 이어지지 않음
      • timeout이라는 기능을 잃게 되는 단점이 존재
    8. Timeout이라는 기능을 잃고 싶지 않아 Spring Cloud Zuul에서 우리는 Thread Isolation을 사용하고 싶다는 생각
      • Thread Isolation을 통해서 Hystrix Timeout을 통해서 특정 서버군의 장애 시에도 Zuul의 Container Worker Thread의 원활한 반환
      • 설정값으로 간단히 변경 완료
      • 초기에는 버그로 인해 Server 전체에 RibbonCommand라는 한 개의 Thread Pool이 생겨버리게 구현
        • 원래 Isolation과 어울리지 않는 개념 (오픈소스의 초기 버그)
        • 서버군(Service ID) 별로 Thread Pool을 분리해주는 것이 필요하다는 팀의 판단 하에 소스를 수정해서 운영했고 현재는 Spring Cloud Netflix 프로젝트에 Pull Request를 통해 해당 코드 수정된 상태
  5. 장애 시나리오
    1. Hystrix, Eureka, Ribbon을 사용한 우리 System은 어느 정도 Resillient 한 거야?
    2. 장애 유형별 동작 예
      • 서버군을 구축했는데 그중 한대가 맛이 간 경우 (특정 API 서버의 인스턴스가 한 개 DOWN 된 경우)
        • 서버 3대 중 한대가 맛이 감
        • EUREKA - Heartbeat 송신이 중단됨으로 일정 시간 후 목록에서 사라짐
          • 디폴트 설정으로는 서버가 UP/DOWN 돼도 EUREKA에 반영되는 속도가 느림
          • Netflix의 경우 전 세계에 정말 많은 서버가 존재하기 때문
          • 현재 서비스의 특성에 맞게 설정 값을 줄일 필요가 있음
        • RIBBON - IOException이 발생한 경우 다른 인스턴스로 Retry 
        • Hystrix - Circuit은 오픈되지 않음 (ERROR = 33%)
          • 50%가 넘어야 Hystrix 발동
          • Fallback, Timeout은 동작
      • API 하나가 잘 못 구현돼서 모든 서버에 영향을 끼치는 경우 (특정 API가 비정상 동작하는 경우 (지연, 에러))
        • Hystrix -  해당 API를 호출하는 Circuit Breaker 오픈
          • Fallback, Timeout도 동작

 

4. Server to Server 호출 in MSA

  1. MSA 플랫폼 외부의 호출은 API Gateway를 단일 창구로 사용
    • API Gateway가 Traffic을 고스란히 받는 구조
    • single endpoint라는 불안감
  2. "MSA 플랫폼 내부의 API Server 간의 호출은 어떻게 할 것인가?"
    • API Server 간 P2P 호출을 하기로 결정
    • Spring Cloud에서는 다음의 Ribbon + Eureka 기반의 HTTP 호출 방법 제공
      • @LoadBalanced Rest Template
        • @LoadBalanced 어노테이션을 붙이는 경우 RestTemplate이 Ribbon + Eureka 기능을 갖게 됨
        • RestTemplate이 Bean으로 선언된 것만 적용 가능
      • Spring Cloud Feign

 

4.1 Spring Cloud Feign 도입

 

  1. Declarative Http Client
    • Java Interface + Spring MVC Annotation 선언으로 Http 호출이 가능한 Spring Bean을 자동 생성
    • OpenFeign 기반의 Spring Cloud 확장
    • Hystrix + Ribbon + Eureka와 연동되어 있음 (Ribbon + Eureka 자동 연동)
  2. RestTemplate보다 훨씬 간단하게 API 호출 가능
  3. Spring Cloud Feign with Hystrix
    • Hystrix 연동하기
      • Hystrix가 Classpath에 존재
      • feign.hystrix.enabled=true로 간단하게 설정
    • 주의: Spring Cloud Feign 사용 시 CircuitBreaker 단위, ThreadPool의 단위가 메서드 단위로 잘게 분해가 되기 때문에 Custom 한 코드나 설정을 통해서 비슷한 유형의 메서드들은 같은 CircuitBreaker를 사용하도록 설정 필요
  4. Spring Cloud Feign with Hystrix, Ribbon, Eureka
    • 호출하는 모든 메서드는 Hystrix Command로 실행
      • Circuit Breaker, Timeout, Isolation, Fallback 적용
    • 호출할 서버는 Eureka를 통해 얻어서, Ribbon으로 Load Balancing 되어 호출
      •  

 

5. 11번가 실제 Spring Cloud 환경 구성

  1. 깃 기반 pull request로 관리할 수 있어 application.yml 오타로 인한 config 장애를 피할 수 있음

 

6. 모니터링

  1. 분산 Tracing에서 서버 간 Trace 정보의 전달 (API -> API -> API -> API 같은 구조)
  2. 서버 간의 Trace 정보의 전달은 사용 Protocol의 헤더를 통해 전달 필요
    • ex) HTTP Header
  3. 다양한 Library에 의한 Thread 변경으로 인한 Trace 정보의 전달이 어려움
    • 단순한 Thread Local에 저장하는 방식을 사용하기 어렵다
    • Hystrix, RxJava, @Async, 등등
  4. Spring Cloud Sleuth
    • Spring Cloud에서 제공하는 Distributed Tracing 솔루션
      • 대부분의 내외부 호출 구간에서 Trace 정보를 생성 및 전달
      • Log에 남기거나 수집 서버(Zipkin)에 전송하여 검색/시각화
    • Spring Cloud Sleuth가 지원되는 Component
      • Zuul, Servlet, RestTemplate, Hystrix, Feign, RxJava 등등
    • Spring Cloud Sleuth - Logging
      • Spring Cloud Sleuth 사용 시 Application 로그에 Trace ID(UUID)가 함께 출력
      • Trace ID - 하나의 Request에 대해 서버 전체를 걸쳐 동일한 UUID
        • 분산 추적 가능
        • 로그 수집/검색 시스템이 있다면 동일 요청에 해당하는 전체 서버의 로그 분석 가능
  5. Spring Cloud Sleuth with Zipkin
    • 특정 서버에서 에러 날 경우 해당 서버가 빨간색으로 뜸
    • Spring Cloud Sleuth로는 DB 호출 구간은 표현 안됨
      • Spring AOP를 사용하여 Sleuth API로 Trace 정보를 직접 생성 (DB 호출 구간도 확인 가능)
  6. Spring Cloud Sleuth with Zipkin 필요성
    • API 호출이 너무 느려서 Zipkin으로 확인한 바 하나의 API 호출이 다른 API 혹은 DB Connection을 1000번 이상 호출하는 상황
      • 개발자 입장에서는 적절한 반복문을 통해 호출한다고 생각
      • Pull Request를 통해서도 확인 불가능했던 게 Stream을 통해 엄청 잘 짜여있던 코드였음
        • 실상은 서버 -> 서버 -> 서버 ->... -> 서버를 호출하는 구조라 사실상 1000번 이상 호출하는 구조였던 것
        • 이러한 오류는 Zipkin과 같은 모니터링 서비스 없이는 인사이트를 확인할 수 없음
    • Chrome 낸 Zipkin 용 plugin도 존재
      • UI 개발자들도 사용하기 유용
    • 노력 대비 간단하게 도입 가능하며 API 검증에 매우 유용

Spring Cloud Seluth with Zipkin

 

6.1 추가 모니터링 툴

 

  1. Hystrix 모니터링 with Turbine
    • Circuit Breaker 지표
      • 녹색 - 성공 횟수
      • 파란색 - 차단 횟수
      • 하늘색 - 사용자 입력 오류 (BadRequest)
        • 내 api를 호출하는 자의 잘못
      • 노란색 - 시간 초과
      • 보라색 - Rejected (Isolation 초과)
      • 빨간색 - 일반 오류
      • 회색 - 전체 에러 비율
      • 즉, 일반적인 모니터링과 다르게 MSA 환경에서 필수적인 값 (각각의 Circuit Breaker 단위로 평균 응답 속도, TPS 기록)
        • 서버와 서버 구간 단위로 분석할 수 있어 Turbine 대시보드 보는 것은 유의미
    • ThreadPool 상태
    • Real-time이라는 것이 아쉬운데 메트릭 정보를 Influx DB에 일주일치를 저장하고 그 데이터를 기반으로 Grafana를 연동하여 대시보드를 구성하여 과거 데이터 모니터링 가능
  2. Spring Boot Admin
    • Spring Cloud가 공식적으로 제공하는 Admin 툴은 아니지만 오픈소스
    • Spring Boot Actuator를 통해 Spring Boot로 구축된 모든 서버를 제어할 수 있는 기능 제공
    • Main Console로 사용
      • 운영 시 필요한 추가 기능 구현 
      • 각 서버의 다양한 메트릭 정보 확인 및 Eureka Server 상태 변경 감지
      • Zuul 내부 Eureka/Ribbon 상태 확인 강제 변경

 

7. 회고

  1. Open Source에 대한 인식 변경
    • 당연히 Bug도 있고, 문서도 부실하지만...
    • Source Code가 주어졌기 때문에 무엇이든 할 수 있다는 자신감
    • Bug Report, 수정과 문서 보관은 사용자의 몫
    • 문제를 부딪히고 해결해가는 과정에서 개발팀 스스로 성장하고 있는 모습을 발견
  2. Spring Cloud 덕분에 빠른 시간 안에 최소의 인원으로 프로젝트를 진행할 수 있었음

 

8. 비고

 

strangler application pattern

 

https://americanopeople.tistory.com/193

 

(Strangler Pattern/스트랭글러 패턴) 레거시 코드를 마이크로 서비스 아키텍처로 개선하기

Strangler Pattern 모놀리틱 아키텍처로 된 시스템이 계속 자라나면, 더이상 관리할 수 없는 수준이 된다. 그리고 아키텍처가 복잡해지거나, 비즈니스 로직이 파편화되면 코드를 관리하기 어려워진

americanopeople.tistory.com

 

반응형
저작자표시 비영리

'리서치' 카테고리의 다른 글

[Springboot] 멀티 데이터소스 (MyBatis, JPA)  (11) 2023.03.25
[MSA] CQRS 패턴과 실제 적용 사례  (4) 2022.10.31
[MSA] 우아콘 2020 배달의민족 마이크로서비스 여행기 정리  (4) 2022.10.27
[tus protocol] 재개 가능한 파일 업로드를 위한 오픈 프로토콜  (8) 2022.10.06
[SpringBoot + Fastexcel] 대용량 엑셀 생성 및 다운로드  (14) 2022.09.14

'리서치'의 다른글

  • 현재글[MSA] 11번가 Spring Cloud 기반 MSA로의 전환 정리

관련글

댓글

티스토리툴바