spring msa에 관해

이 글은 11번가 spring cloud 기반 msa로의 전환을 보고 개인적인 느낀점을 적은 글입니다

동영상은 https://www.youtube.com/watch?v=J-VP0WFEQsY 에서 볼 수 있습니다

 

"나쁜 시스템이 나쁜 개발 문화를 만든다" 라는 말이 가장 인상 깊었습니다. 11번가는 모놀리식 기반에서 MSA로 전환하는 과정을 거쳤습니다. 기존의 문제점은 서비스에도 악영향을 미칠 뿐만 아니라 개발 문화에도 영향을 주었습니다.

 

기존 시스템은 모놀리식 구조 였기 때문에 많은 개발 팀들이 코드를 한번에 배포해야 했고 이로 인해 일어나는 문제점이 생겼습니다. 한 개발자의 잘못이 전체 배포과정에 있어 영향을 주게 되었고, 개발자들이 새로운 기술에 도입에 있어 기존의 모듈의 의존관계 때문에 적극적으로 사용할 수 없었습니다. 이는 개발 능률을 저해할 수 있는 환경이라고 생각됩니다.

 

따라서 11번가는 MSA를 도입하기로 했습니다. 기존의 코드들이 코드 분석하기 어려웠기 때문에 점진적으로 바꿔나가는 방식을 차용했습니다. 

 

개인적으로 MSA를 공부하면서 몰랐던 부분이 많았습니다. 11번가 강의를 보면서 느낀 가장 인상 깊었던 것은 Resilience와 모니터링이었습니다. MSA는 하나의 서비스를 여러개의 작은 서비스로 분리하는 구조이기 때문에 하나의 서버가 아닌 수 많은 서버 인스턴스들이 존재합니다. 따라서 이들을 통합적으로 관리할 수 있는 모니터링이 필요하고 하나의 서버가 실패하더라도 반응할 수 있는 시스템을 구축해야 하는 것을 깨달았습니다.

 

Spring Cloud에서 resilience를 제공한다 (현재는 Hystrix  ->Resilience4j로 변경 권장)

Hystrix가 호출될때

• 메소드를 intercept 해서 대신 실행한다. 실행은 다른 thread에서 되므로 쓰레드가 격리되어 있음
• 메소드의 실행 결과를 성공 혹은 실패 여부를 기록하고 통계를 낸다. 통계에 따라 Circuit Open여부를 결정한다
  • Circuit Open 호출 차단, Circuit close 호출 허용
• 실패할 경우 사용자가 제공한 메소드를 대신 실행한다

이로 인해 서버 인스턴스의 상태에 따라 실패 처리 및 대응을 할 수 있다. 

 

Spring Cloud에서 모니터링을 할 수 있게 한다(Spring Cloud Sleuth)

서버간의 이동 경로를 알고 싶을 때 서버간 Trace 정보를 전달해야 한다. 보통 Threadlocal에 이 정보를 저장하기 때문에 어려운 점이 있다. 하지만 spring cloud sleuth을 사용하면 서버에서 필요한 분산 정보를 생성해서 컴포넌트 전달 뿐만아니라 다른 서버 까지 전달한다. 

* keyworld : 분산 Tracing, distribute tracing