마이크로서비스 아키텍처 - 개념정리 (1)

마이크로 서비스  아키텍처 간단 정리

마이크로서비스란 하나의 큰 어플리케이션을 상대적으로 작게 쪼개어 서로 다른 역할을 수행하는 어플리케이션으로 분해해 해결하는 것, 이렇게 작게 나눈 각 서비스가 독립적으로 역할을 수행하게 만들고 변경과 조합이 가능하도록 만든 아키텍처를 마이크로 서비스 아키텍처라고 한다.

 

마이크로서비스 아키텍처는 언제 구축할까?

적은 인원으로 빠르게 시작해야하는 스타트업의 경우 어떤 서비스와 컴포넌트가 필요한지 정확한 로드맵이 없기 때문에 굳이 시스템을 여러개의 서비스로 분리할 필요가 없다. 마이크로서비스 아키텍처를 고려해야할 경우는 아래의 사항과 같다.

 

1. 애플리케이션의 배포에 오랜시간이 소요된다.
2. 단순한 버그 수정을 했을 때 side effect가 발생하여 오류를 잡는데 많은 시간이 소요된다.
3. 2번사항에 따른 테스트를 진행할때 side effect에 따른 전체 부분에 대한 테스트를 진행해야한다.
4. 현재의 서비스를 기능별로 나눈다고 가정했을 때 기능별로 마이크로서비스가 가능하다.

 

마이크로 서비스 아키텍처 특성

• 시스템을 둘 이상의 실행 단위 또는 컴포넌트로 구성, 각 컴포넌트는 결합도가 낮게 분리된 채 비즈니스 목적에 맞게 동작한다. 각 컴포넌트는 메시징 큐, HTTP 요청/응답 모델 등 미리 정의된 프로토콜을 기반으로 서로 통신
• 시스템은 특정 언어에 구애받지 않는다. 특정 서비스의 기술 플랫폼 선택 결정이 애플리케이션 아키텍처에 영향을 주지 않는다.
• 시스템에는 분산 데이터베이스가 있어야 한다. 이상적으로 각 컴포넌트 또는 마이크로서비스는 자신하고만 상호작용하는 자체 데이터베이스가 있고, 다른 컴포넌트나 서비스에서 해당 데이터베이스의 데이터를 읽거나 수정할 수 없다.
• 자동화된 테스트가 필요하다. 속도는 마이크로서비스 아키텍처에서 가장 중요한 특징이다. 빌드, 테스트, 출시라는 주기에서 자동화된 테스트가 없다면 원하는 목표를 달성할 수 없다.
• 모든 컴포넌트나 서비스의 실패는 격리돼야 하며, 특정 서비스가 실패해도 전체 애플리케이션이 중단되는 일은 없어야 한다. 서비스 실패가 다른 컴포넌트나 서비스에 영향을 미치지 않아야 하며, 실패에 대한 롤백 메커니즘이 있어야 한다. 즉 특정 서비스가 실패하면 이전에 작업했던 버전으로 쉽게 되돌릴 수 있어야 한다.

성공적인 마이크로 서비스 아키텍처의 구현을 위해 고려해야 할 요소

1. 로깅을 통한 디버깅 - 각 마이크로 서비스는 자체 로그를 생성하기 때문에 이러한 상황에서 특정 요청에 대한 잘못된 동작의 근본 원인을 찾는것은 개발자에게 어려운 일이다. 분산로깅 환경에서 문제를 디버깅하기는 어렵다. 또한 중앙에서 여러서비스로부터 로그를 수집하는 적절한 도구/스크립트 설정도 데브옵스팀에게는 어려운 문제가 될 수 있다.
2. 마이크로서비스 모니터링 - 모놀리스 어플리케이션은 모니터링이 비교적 쉽다. 모놀리스 어플리케이션 관점에서는 하나의 큰 서비스로 인식되기 때문에 모니터링해야할 지점이 많지 않다. 반면 마이크로서비스 아키텍처에서는 여려개의 서비스에 대해 모놀리스 어플리케이션에서 일반적으로 볼수 있는 것과 동일한 수만큼의 지점을 모니터링해야한다.
3. 공통 라이브러리 - 마이크로서비스에서는 여러 서비스에서 공유하는 라이브러리 사용은 좋지 않다. 동일한 라이브러리를 공유할 경우 동일한 언어 사용에 고착될수 밖에 없으며, 이 방식은 서비스간의 결합을 증가시키기 때문에 마이크로 서비스 원칙에 위배된다.
4. 서비스 간 메세징 - 외부로부터의 단일 요청을 처리하는 마이크로서비스 아키텍처에서는 서로 다른 마이크로서비스 사이에 이뤄지는 내부통신이 발생할 수 있으므로 네트워크 지연이 나타날 수 있다. 이를 해결하기 위해서는 Restful 웹 서비스 또는 비동기 메시징이 해결방안이 될 수 있다. 이를 해결하기 위한 방법은 카프카, SNS, 샐러리 등을 활용해서 이벤트를 큐에 게시하는 것이다.
5. 마이크로서비스 배포와 버전 관리 - 마이크로서비스는 여러 방식으로 배포할 수 있다. ami를 사용하여 배포할 수 있고, docker를 사용해서 배포할수 있지만 마이크로서비스를 작성하는데 도커가 시간이 더 빠르기 때문에 현재로서는 docker는 가장 적절한 도구라고 볼 수 있다.

마이크로 서비스의 미래

• 서버리스 아키텍처
• PaaS로서의 마이크로서비스

마이크로 서비스 와 전통 아키텍처 비교

모놀로스는 커다란 코드 베이스를 사용한다. 예를 들어서 신규입사자가 간단한 소스를 수정한다고 가정했을때 모놀로스 아키텍처는 코드를 변경해야하는 모듈을 파악하고, 코드를 복제하고, 로컬환경을 세팅하고, 서드파티 도구에 대한 종속성 문제들을 해결하는 등 많은 시간이 소요된다. 하지만 마이크로서비스 아키텍처는 수정해야하는 부분을 판단하고, 해당 부분의 코드를 복제하고 로컬환경에서 테스트를하고 배포를 하는등 적은 시간이 소요된다. 이러한 이점 때문에 현재는 마이크로서비스가 대두되고 있는 상황이다.