Spring Cloud - MSA
이전에 몇개의 포스팅에서 msa 에대해 많이 알아봤다.
다시한번 훑어 보고 가보자.
ㅇ MicroService?
모놀리식 구조는 한 프로젝트 내에 모든 서비스가 같이 존재해, 한서비스에서 장애가 발생하면 다른서비스까지 멈추는 그런 구조고, 우측의 msa는 한 프로젝트가 다양한 서비스로 나뉘어서 서비스간 통신하며 한 서비스에서 장애가 나도 다른서비스는 정상작동이 되는 구조다.
ㅇ Cloud Native Architecture
2010년대 이후부터 IT시스템은 anti-fragile 또는 클라우드 네이티브 아키텍처 형태로 발전되어 왔다.
ㅁ Anti-fragile : 충격이나 변화에 손상되지 않고 오히려 강해지는 시스템을 의미한다. 예시로는 오토 스케일링(클라우드 환경에서 트래픽이 급증하면 자동으로 더 많은 서버를 할당해 성능을 유지하는 방식), 카오스 엔지니어링(넷플릭스에서 사용하는 방법으로, 인위적으로 시스템에 장애를 일으켜 어떻게 대응되는지 테스트)
ㅁ 클라우드 네이티브 : 클라우드 환경을 최대한 활용해 설계된 애플리케이션 및 시스템을 의미한다. 주요 특징으로는 컨테이너 기반(앱과 환경을 하나로 패키징해 어디서든 일관적으로 실행될수 있게 하는 기술), MSA(애플리케이션을 작은 독립적인 서비스로 나눔), 자동화와 오케스트레이션(쿠버네티스같은 도구로 컨테이너의 배포, 확장, 관리를 자동으로 처리), CI/CD(배포주기를 짧게 자동화 파이프라인)
두 개념은 서로 보완적인 역할을 한다.
ㅇ Cloud Native Application
마이크로 서비스로 개발되고, CI/CD 시스템을 통해 빌드, 배포라는 과정을 거치게 됨. 마이크로 서비스에 문제가 발생했을 경우 바로바로 수정해서 다시 배포하는 과정을 반복할 수 있는데, 이걸 DevOps 라고함. 시스템이 기획, 구현, 테스트, 배포되는 과정을 시스템이 종료될 때 까지 계속 반복해줌으로써 최상의 결과를 만들어준다. 마이크로 서비스들을 클라우드 환경에 배포,사용하기 위해 컨테이너 가상화 기술을 사용함.
ㅁ CI/CD(Continuous Integration/Continous Deployment) : 지속적 통합/지속적 배포라는 의미로 CI는 여러 개발자들이 개발을 할 때, 결과물을 자주 통합하는 형상관리, 이렇게 통합된 코드를 빌드, 테스트하는 과정이다. 젠킨스, Team CI, Travis CI가 자주쓰인다.
CD는 두가지의미로 Continuous Delivery, Continuous Deployment 지속적인 전달과 지속적인 배포다. 소스 저장소에서 코드를 가져와 패키지화 된 형태의 결과물을 실행 환경에 어떻게 배포하냐에 따라 달라짐. 실행환경에 수작업으로 배포하는 과정이 필요하면 Continuous Delivery, 실행환경까지 자동화 되어있는 배포를 사용하면 Continuous Deployment가 된다.
ㅁ 데브옵스 : Development와 Operations 가 합쳐진말로, 개발 과 운영의 통합이다. 고객의 요구사항을 빠르게 반영해 결과물을 제시하는 목적이다. 자주 테스트하고, 자주 피드백을 받고 자주 업데이트하는과정을 계속해서 해나가는게 DevOps라고 할 수 있다.
ㅁ 컨테이너 가상화 : 도커를 사용해봤으면 무슨 서비스인지 알것이다. 컨테이너 가상화에선 공통적인 라이브러리나 리소스를 공유해서 사용해 부담이 적고 가볍고 빠르게 운영 가능하다.
ㅇ 마이크로 서비스의 특징
서비스 경계를 잘 구분해야함. 경계에 따라 여러개의 서비스가 하나의 서비스가 되기도 한다. 각각의 서비스는 상태에 대해서 Rest API로 통신해야 한다. 서비스들이 갖고있는 환경에 대한 정보, 설정 코드는 외부에 있는 시스템에 의해 관리 되어야 한다. 클라우드 네이티브 기술을 최대한 활용해야 한다. 시각화할 수 있는 도구를 가지고 있어야 함.
ㅇ MSA와 SOA
SOA는 서비스 지향 아키텍처로, 하나의 대규모 애플리케이션을 여러 재사용 가능한 서비스로 분리해서 각 서비스를 독립적으로 설계하고 통합하는 방식이다. 여기서 서비스는 특정 비즈니스 기능을 수행하는 독립적인 모듈로, 다른 서비스들과 느슨하게 결합된다.
MSA는 SOA의 개념을 더 발전시켜 각 서비스를 더 작은 단위로 쪼개는 방식이다. 각 마이크로서비스는 특정 비즈니스 기능을 담당하고 독립적으로 배포 및 운영될 수 있다.
서비스공유를 최소화 하는게 MSA, 최대화 하는게 SOA방식
SOA는 서비스를 ESB에 모아 제공하고, MSA는 각 서비스가 REST API를 사용한다.
ㅇ MSA의 구조
클라이언트들의 요청은 api gateway라는 접속점을 통해서 서비스 라우터에게 어디로 가야할지 물어보고 필요한 마이크로 서비스가 어디에 저장되어있는지 서비스 디스커버리의 등록 서비스에 물어보게되고 알게되면 서비스로 이동하게 된다. 분산되어있으면 로드 밸런서를 통해 접근하게 된다. 완성된 어플리케이션은 배포를 위해 CI/CD기술을 사용한다. Backing services는 마이크로 서비스에 저장되어 이쓴 다양한 스토리지들을 모아서 사용할 수 있는 방법들이다. MOM(메시징 시스템)을 통해서 하나의 서비스와 다른 서비스를 같이 연결할 수도 있다. Telemetry 는 마이크로 서비스의 모니터링 기능, 진단 기능을 가지고 있다.
Service Mesh는 MSA를 적용한 시스템의 내부 통신을 말한다. URI 경로, 호스트헤더 등 응용프로그램의 규칙을 기반으로 하는 네트워크 레이어. 또한 서비스간 통신에 연관된 기능뿐 아니라 서비스의 배포전략에도 도움을 줄 수 있다.
