개요
새로운 시스템과 시스템이 결합하게 되면서 MSA로의 전환이 절실히 필요해진 문제들이 다수 발생하였다. 다만 최초부터 MSA로 설계된 시스템이 아니기 때문에 전환에는 많은 공수가 들 수 밖에 없고, 각 시스템 개발 담당자들로부터의 반대 여론이 굉장히 강한 편이다. 현재 시스템이 동기적으로 연결되어 있어 의존중인 시스템이 DDOS나, 장애 발생 시 동일한 장애가 발생하게 된다. 문제는 타이어픽 서비스의 경우 고객들의 재이용률이 굉장히 낮은데다, 그 텀이 굉장히 길다 (타이어의 경우 2-3년, 엔진오일의 경우 1년 내외).
한 번 고객이 이탈하면 다시 돌아오지 않을 가능성이 굉장히 높은데. 타이어픽 서비스의 자체 장애가 아닌 외부의 장애에도 영향을 받게 되면 매출에 영향이 없을 수가 없다.
투자자들에 빠르게 결과를 보여줘야하는 스타트업의 생태계상 설계 및 기획 개발이 느슨하게 될 순 없었지만 그 당시 전반적인 아키텍처를 구성 할 수 있는 사람도 없었고, 모두의 role 자체가 굉장히 불안정할 수 밖에 없었다. 서로의 시스템에 대해 나서서 왈가왈부 할 수 없는 애매한 상황이 처했다.
그런 연유에서 당장 시스템 담당자들간의 협의를 통해 가장 위험하지만 가장 빠른 방법을 통해 두 시스템의 주문 시스템을 연동하게 되었다.
하지만 시스템을 담당하고 있는 입장에서 자식이 이미 위험한 길을 갔다고해서 방치하는 것은 개발자의 올바른 태도는 아니다.
왜 MQ를 도입해야는지?
현재 주문 프로세스를 간단하게 표현하자면, 아래와 같다.
소비자가 결제완료된 시점에 타 시스템의 API를 호출하고, 그에 대한 응답에 맞게 처리해주는 아주 간단한 프로세스로 되어있으며 타 시스템이 장애가 발생하지 않는다면 문제가 없는 구조
문제는 아래와 같이 장애가 발생한 경우 주문생성이 되기 위해서는 반드시 타 시스템 Server의 응답을 받아야한다.
이 경우는 타 시스템이 장애 대비를 얼마나 잘했느냐에 따라 무난히 넘어갈 수 있는 부분이다.
예를 들어 특정 인스턴스가 문제가 발생했다고하면 오토스케일링 정책을 통해 문제가 발생했는지도 모를 수 있다.
RDS가 과도한 요청으로 인해 CPU 100%가 된 경우
서버가 오토스케일링이 되어 증설되었다고 해도 문제는 여전히 발생 할 수 있다. 요청이 기획전, 이벤트 등을 통해 Spike 트래픽이 발생한 경우 이미 요청이 들어간 서버는 과도한 요청을 받은 상태로 응답이 매우 늦거나 타임아웃이 발생 할 수 있으며 요청에 대한 쿼리를 해야하는 RDS를 클러스터링하지 않았다면 (참고로 클라우드 전체 비용 중 AWS RDS 비용의 비중은 매우 높은 편이다.) 장애 발생 소지가 높다.
이런 문제를 조금이나마 개선하기 위해서는 두 시스템 사이의 의존성을 줄일 필요가 있다.
결론은 개발여건상, 투자자들의 요구사항이 많건 적건 늦었지만 MQ를 도입해야한다는 것이다.
의존성을 줄이기 위해 아래와 같이 구성하려고 한다.
MQ 도입 후 구성도
1.
결제가 완료되면 주문을 먼저 생성한다.
2.
생성된 주문은 PENDING 상태로 대기하게 된다.
3.
MQ에 의해 요청이 정상처리된 경우 주문은 기존 오더 라이프사이클을 따르게 된다.
4.
실패한 경우, 고객에게 알림톡과 동시에 환불 처리 진행을 한다. ( 타 시스템의 장애가 길어지는 경우 배치를 통해 특정 기간 뒤에 환불을 해주는 프로세스를 고려해본다 )
어떤 MQ를 선택해야 유리할까?
기능 | Kafka | Redis | RabbitMQ | SQS |
매우 높음 | 높음 | 중간 | 높음 (표준 큐) | |
지연 시간 | 낮음 | 매우 낮음 | 중간 | 중간 |
메시지 지속성 | O (디스크 저장) | X (인메모리) | O | O |
순서 보장 | O (파티션 내) | X | O | FIFO 큐에서만 가능 |
확장성 | 높음 | 제한적 | 중간 | 높음 (완전 관리형) |
사용 편의성 | 복잡함 | 간단함 | 중간 | 매우 간단함 |
운영 부담 | 높음 | 중간 | 중간 | 없음 (완전 관리형) |
적합한 사용 사례 | 실시간 스트리밍, 대규모 데이터 | 캐싱, 간단한 메시징 | 비동기 작업 큐, 메시지 지속성 필요 | 클라우드 기반 애플리케이션 |
구성에 대해서는 구상이 완료되었지만 이제 어떤 MQ를 사용하는 것이 효율적인지에 대한 고민이 필요하다.
nestJS 레퍼런스가 존재하며, 가장 많이 사용되는 4가지 MQ를 정리해보았다.
투자자 외압(?)이 없거나 기한에 여유가 된다면 가장 안정적인 시스템을 선택하는 게 미래를 위해 좋다고 본다.
허나 예산은 항상 정해져있고 개발공수, 인력, 개발기간, Cloud 요금 등 모든 것이 비용이기 때문에 적절한 MQ를 선택하는 것은 매우 중요하다.
정해놓은 구성에서 가장 중요한 것은 데이터가 사라져선 안된다.
주문 데이터가 사라지는 것은 매우 크리티컬한 문제이며 유저의 신뢰는 바닥에 떨어지게 된다.
마치 어제 득템한 초고가의 아이템이 오늘 아침 사라진 것과 같다.
따라서 데이터의 영속성은 매우 중요하며, 주문이 취소 될 수 있으며 그 기준이 명확해야 하기 때문에 처리되는 순서 또한 중요하다.
그렇다면 영속성과 순서보장이 되지않는 Redis는 자연스레 제외된다.
Kafka의 경우 구성이 복잡한 편이며, 스타트업에서 사용하기에는 러닝커브가 있다고 판단되며 일 평균 300건 정도의 주문 건을 처리하는데엔 불필요하게 크다. 닭 잡는데 소잡는 칼은 필요하지 않다.
그렇다면 RabbitMQ와 SQS로 좁혀지게 되는데.
비용보다 중요한 부분이 데이터의 영속성과 스타트업 특성상 언제든 개발자와 인프라 관리자가 사라질 수 있는 서비스 유지차원에서는 SQS가 가장 적합다는 판단이 들었다.
결론
MQ는 만능이 아니기 때문에 현재 주문 정책과 문제가 없는지 검토를 해야한다.