왜 MSA?
delivery-jumper는 주문 배달 애플리케이션입니다. 일반적으로 음식 배달 애플리케이션은 특정 시점에 특정 서비스에 트래픽이 집중될 것으로 예상할 수 있습니다. 아마도 식사 시간이 그 시점이 될 것입니다. 배가 고픈 시점에서 주문 버튼을 누르고 보이는 화면에 오류 메시지가 있다면, 그것이 빈번하게 발생한다면, 그 경험은 애플리케이션을 지우는 결과로 이어지게 될 겁니다.
위와 같은 결과가 발생하지 않도록, 무거운 트래픽에도 충분히 견딜 수 있는 시스템에 대한 고민을 하게 되었습니다. 이를 위해 서버의 확장 방법에 대한 공부를 시작하였습니다.
서버를 확장하는 방법은 크게 수직적 확장(scale-up)과 수평적 확장(scale-out)이 있습니다.
수직적 확장은 서버 한 대의 성능 자체를 향상하는 방법입니다. RAM추가가 대표적입니다. 하드웨어 하나를 추가하면 되는 가능하기 때문에 상대적으로 쉬운 방법입니다.
그런데 몇 가지 문제가 보입니다. 평소에 10의 트래픽이 발생하는 서비스가 점심, 저녁 시간 한정으로 10배인 100의 트래픽이 1시간 동안 발생한다고 서버의 성능을 100으로 유지하는 것이 경제적으로 보이지 않습니다.
만약 서비스가 조금 더 성장하여 105의 트래픽이 발생한다면? 매번 증가하는 트래픽에 맞춰서 계속 하드웨어를 추가할 수는 없습니다.
또한 만약 그 서버가 있는 장소에 번개가 떨어진다면? 지진이 발생한다면? 정전이 발생한다면? 시스템 전체가 다운될 것입니다. 힘들게 확장하고 키워온 애플리케이션이 위험에 노출될 수 있습니다. 지켜줘야 합니다.
그렇기 때문에 수평적 확장이 필요합니다.
수평적 확장은 서버 개수를 늘리는 방법입니다. 트래픽의 발생 규모에 따라서 서버 개수를 증가시키고 감소시킬 수 있기 때문에 경제적이며, 한대의 서버가 다운되더라도 시스템은 운영될 것이며, 증가하는 트래픽을 견딜 수 있습니다.
그런데 말입니다. 그 확장한 서버가 다 죽으면 어떻게 될까요?
극단적인 예시이나 충분히 가능성은 있습니다. 여기서 주된 관심사는 가용성과 확장성입니다. 등장하는 문제들이 계속 시스템 전체에 영향을 미치고 있습니다. 그렇다면 하나의 애플리케이션을 서비스 단위로 쪼갠다면 어떨까요? 그 쪼개진 서비스가 각각 수평적 확장이 가능한 상태로 서버에서 실행된다면요?
MSA는 앞선 예시와 같은 특정 지점에서 발생되는 결함이 시스템 전체에 번지는 것을 막아줍니다. 결함 격리(fault isolation)라고도 합니다. 애플리케이션 속 명예 소방관님 이신겁니다. 또한 서비스 단위로 모듈화 되어있기 때문에 결함이 발생하더라도 범위를 특정하기가 쉽습니다.
서비스 단위로 확장 가능한 서버 풀(cluster)을 가지고 있기 때문에 개별적인 배포도 가능합니다. 작은 버그 하나를 고치기 위해서 전체 애플리케이션을 다시 빌드하고 테스트하고 배포하는 비용이 절감될 수 있습니다.
하나의 서비스가 중단되어도 그것이 시스템 전체에 영향을 미치지 않기 때문에 장애 허용(fault tolerance)된 애플리케이션을 제공할 수 있습니다.
물론 단점 또한 존재합니다.
서비스 단위로 전담 팀이 필요할 수 있습니다. 또한 분산 로깅, 모니터링, 서비스 간 통신, 서비스 검색, 경고, 추적, 빌드, 릴리스 파이프라인 상태 확인 등 설정하고 관리해야 하는 부분이 많아집니다.
그럼에도 불구하고
뛰어난 확장성과 높은 가용성을 통해 안정적인 사용자 경험을 제공할 수 있기 때문에 Micro Service Architecture 방식의 설계로 결정하게 되었습니다.