마이크로서비스 아키텍처 와 MSA 패턴의 이해

개요

인프런의 마이크로서비스 아키텍처와 MSA 패턴 이해라는 강의를 들으면서 이해했던 내용들을 요약 정리

 

마이크로서비스의 등장배경

성공한 기업들의 공통점

기존 서비스에 온라인 기술을 접목시켜 새로운 서비스 창출해 낸다. 이렇게 창출해낸 서비스를 배포하는 빈도와 속도가 상당히 빠르다. 서비스 변경 빈도가 잦다는 것은 변화된 비지니스 환경에 민첩한게 대응할 수 있다는 것으로 이어지며 이는 기업의 성공에도 이어진다.

(실제로 아마존에서는 본인들의 성공이유가 잦은 배포(11초에 한번)에 있었다고 한다.)

 

클라우드 인프라의 등장

과거의 인프라 구축은 많은 시간이 소요되었지만, 클라우드 인프라의 등장으로 내가 원하는 시점에 내가 원하는 컴퓨팅 서비스를 제공받을 수 있게 되므로 서비스의 빠른 배포를 할 수 있게 되었다.

 

트래픽이 폭증할때?

이때 우리는 흔히들 클라우드 인프라에서 제공하는 스케일 업과 스케일 아웃으로 폭증된 트래픽을 대응하는데 이때 조금 더 효율적으로 스케일 업과 아웃을 할 수 있는 방법은 없을까? 라는 생각에서 등장한 것이 마이크로서비스이다.

 

효울적인 스케일 아웃이 가능한 마이크로서비스

전체 인스턴스를 한꺼번에 확장하는 것보다 필요한 일부기능만 리소스를 확장하는것이 가장 효율적인데 그렇다면 시스템은 한 부분만 변경 가능하게 나눠진 형태(마이크로서비스)로 되어있는게 가장 바람직하다.

마이크로서비스란?

하나의 어플리케이션이 여러개의 서비스 조각으로 구성되어진 것

• 서비스는 각각 독립적인 기능을 제공한다.
• 서비스가 사용하는 저장소는 다른 서비스와 완벽히 격리된다.
• 따라서 독립적으로 수정 가능하며 별도 배포, 확장 가능하다.
• 하나의 서비스 실패는 전체 실패가 아닌 부분적인 실패를 의미한다.
• 서비스간의 통신은 HTTP 자원 API 같은 가벼운 수단을 사용할 수 있다. 

이렇게 나누어 놓은 형태가 마이크로서비스라고 할 수는 있다. 근데 이런식의 마이크로서비스로 한다고 해도 이게 성공적인 마이크로서비스라고 할 수 있을까? 라고 한다면 그렇지 않다.

 

성공적인 마이크로서비스

클라우드 서비스를 적용할 때 마이크로 서비스가 가장 이상적이지만, 이러한 기술적인 부분에 국한되지 않은 부분의 밑의 요소들이 제대로 작동할 때 성공적인 마이크로서비스가 될 수 있다.

• 조직: 특정 도메인에 자율적인 권한과 책임을 지는 조직
• 인프라: 언제나 쉽게 확장 가능한 유연한 인프라 구성
• 자동화: 개발지원 도구 자동화(CI CD)
• 개발 프로세스: 피드백 기반의 개발 프로세스, 반복/점진적인 애자일 프로세스
• 개발 문화: 공유/협업하고 학습하여 계속 진화하는 개발 문화
• 설계 방식: 데이터 중복, 결과적 일관성 추구 -> 아직 잘 이해가 되지 않은 부분인데 추후에 조금 더 깊게 파보자

성공적인 마이크로서비스를 위한 일부 조건에 대해 조금 더 자세하게 알아보자

성공적인 마이크로서비스의 조건

조직

SI로 개발자를 시작했을 때 개발팀으로 들어가서 개발만 하고 운영자체는 다른팀에게 맡기는 식으로 조직문화가 구성되어 있었다. 하지만 이러한 조직의 구성은 개발팀과 운영팀 사이에 아주 많은 의사소통 비용이 발생하고 이는 빠르게 변하는 비지니스 환경에 민첩하게 대응할 수 없게될 가능성이 높아진다.

 

그래서 등장한게

개발을 하면 그대로 운영까지 하나의 팀에서 맡아서 하면 불필요한 의사소통이 줄며 빠른 개발 속도를 보장할 수 있으며, 자기가 만들고 자기가 운영을 함으로써 서비스에 대한 책임감도 증대되며 버그가 발생할 때 더욱 빠르게 대처할 수 있다.

 위와 같은 형태는 마이크로서비스에서 나누어진 하나의 서비스조각을 하나의 팀에서 맡고 개발,운영을 하는 형태가 되므로 각각의 서비스 조각들도 더욱 빠르고 활발하게 움직일 수 있게되며 성공적인 마이크로서비스의 하나의 요인이 될 수 있다.

 

개발 프로세스

개발 프로세스를 애자일 방식으로 진행한다면 더욱 성공적인 마이크로서비스가 될 수 있는 이유는 뭘까?

우선 애자일 프로세스는 밑과 같은 특징을 가지고 있다.

• 빠르고 유연한 소프트웨어 개발 방법론
• 짧은 개발 주기(스프린트)를 통해 지속적으로 제품을 개선하고, 변화하는 요구사항에 신속하게 대응할 수 있다.
• 이 방법론은 팀원 간의 긴밀한 협업, 지속적인 고객 피드백, 반복적인 개발을 중점에 둔다.

이러한 특징을 가지는 애자일 방식은 마이크로서비스와 같이 서비스별로 독립적으로 개발되고 배포되는 환경에서 서비스 별로 유연하게 새로운 기능을 추가하고 그걸 빠르게 고객에게 보여주고 피드백을 받고 개선해 나갈 수 있다. 그리고 애자일 방법론으로 개발을 하게 된다면 조직도 개발+운영을 하나의 팀에서 이끌고 나가야 하는 형태가 되어야 하는데 이를 통해 자연스렙게 조직적인 부분도 성공적인 마이크로서비스에 가까워 질 수 있게 된다.

 

결론적으로, 마이크로서비스와 애자일 방식은 추구하는 목표(민첩섭, 유연성 및 지속적인 개선)가 비슷하므로 같이 사용함으로써 더욱 강한 시너지 효과를 낼 수 있디고 생각한다.

 

어플리케이션 설계 방식

위에서 언급했던 설계 방식으로 데이터 중복, 결과적 일관성을 베이스로 설계를 해야 한다고 했는데 이에 대해 자세하게 알아보자

 

데이터 중복

분산 시스템(마이크로서비스) 특성상, 각각 독립된 데이터베이스를 가질 수 있는데 마스터 데이터의 경우에는 중복해서 가질 가능성이 크다. 즉 데이터의 중복을 의미하는데 일반적인 모노리식에서는 중복 데이터를 피하려고 하지만, 마이크로서비스에서는 데이터 중복이 일부 허용한다. 이를 통해 서비스 간의 결합도를 낮추고, 성능과 확장성을 향상시킬 수 있다.

 

결과적 일관성

데이터의 중복을 허용하는 순간 데이터의 일관성 유지에서 문제가 발생할 수 있다. 마이크로서비스에서는 서비스간의 즉각적인 일관성을 보장하기 어렵지만, 이를 대신해 결과적 일관성이라는 개념을 사용한다. 결과적 일관성은 시스템이 일정 시간이 지난후에 일관된 상태에 도달한다는 것을 의미하며 이는 메시지 기반의 통신을 사용하여 서비스 간에 데이터 변경 사항을 비동기적으로 일치시킨다.

 

결론적으로 데이터 중복의 문제점을 결과적 일관성이라는 개념이 해결하며 두 개념을 같이 사용함으로써 각각의 서비스가 독립적으로 움직이는 마이크로서비스에서 효과적인 데이터 관리를 가능하게 만든다. 그러므로 마이크로서비스의 성공적인 구현을 위해서는 이 설계 방법에 대해서 깊게 고려해 봐야 한다.