안녕하세요. GS리테일 홈쇼핑부문의 주문서비스팀 이민주 매니저(닉네임 Julee)입니다.
저는 GSShop에서 고객과 서비스, 서비스와 서비스를 연결하는 다양한 연계 업무를 담당하고 있으며,
주문서비스의 MSA 전환을 위한 주문구조개선에서는 시스템아키텍트 역할을 하고 있습니다.
IT종사자분들에게 흔히 겪을 수 있는 장애가 무엇인지 물어본다면,
과도한 요청으로 인하여 이를 처리하는 과정에서 발생하는 응답지연, 시스템 중단 등의 장애를 떠올리시는 분들이 많으실 겁니다.
e-Commerce 환경에서도 동일합니다.
홈쇼핑 방송, 모바일앱, 카카오톡 등 수많은 채널을 통하여 발생하는 고객의 주문은 수많은 행위의 서비스 요청(트래픽)을 발생시키게 됩니다.
트래픽이 늘어난다는 것은 고객의 관심과 매출이 증가하는 것이니 매우 즐거운 상황이죠.
문제는 트래픽이 안정적으로 서비스 가능한 범위(서비스 가용성)를 넘어버리면 어떻게 될까요?
증가한 트래픽으로 인하여 응답지연이나 심각한 경우 서비스가 멈춰버리는 시스템 장애가 발생할 수 있으며,
이는 고객 경험에 심각한 악영향을 주게 됩니다.
이러한 문제를 사전에 방지하기 위해서는 다양한 방법들이 있겠지만
급격하게 증가하는 트래픽을 예상하고 네트워크, CPU, 서버, 컨테이너 등등의 리소스를 충분히 확보하여 서비스 가용성을 늘리는 방법을 많이 사용하고 있습니다.
증가할 트래픽을 예상하는 것이 매우 중요한 포인트가 되는거죠.
주문구조개선을 진행하면서
"우리가 관리하는 영역에서 시스템 장애상황을 피하거나 예방할 수 없을까?"
라는 주제로 함께 고민을 하고, 여러 가지 의견들이 나누는 가운데
RateLimit에 대해 관심을 갖게 되었고, 이에 대한 검토 후 실제 서비스에 적용하게 되었습니다.
이후 해당 내용에 대해 공유하라고 강하게 요청하신 분이 계셔서 이렇게 글로 적게 되었네요.
(Darion 팀장님 보고 계신가요~?)
먼저 RateLimit 에 대해 알아보았습니다.
RateLimt란?
RateLimit(요청 제한)은 API 또는 웹 서비스에서 특정 시간 동안 허용되는 최대 요청 횟수를 제한하는 기능입니다.
일반적으로 서비스 제공자가 서비스의 과부하를 방지하고, 무제한적인 요청을 방지하기 위해 사용되며
서비스의 사용 계획에 따라 초당 요청 횟수, 분당 요청 횟수, 시간당 요청 횟수 등 다양하게 설정할 수 있습니다.
RateLimt 설정을 분당 요청 횟수 100으로 설정할 경우
서비스 요청이 분당 100회가 넘어가게 되면 이후에 발생하는 요청에 대해서는 실제 처리를 하지 않고, 바로 에러로 응답을 하게 됩니다.
RateLimit가 발생하게 되면 클라이언트들은 에러코드를 포함한 응답을 받게 되며, 서비스 요청이 거부되거나,
접근이 일시적으로 차단될 수 있으므로 상황에 맞게 적절하게 적용하는 것이 매우 중요합니다.
RateLimit 미적용 시) 과도한 트래픽은 서비스 장애로 이어지게 됨.
RateLimit 적용시) 과도한 트래픽을 처리하지 않고 바로 에러 응답으로 처리하여 시스템 장애가 발생하지 않음
Rate Limit의 장점은 우리의 친구 Chat-GPT에게 물어봤습니다.
- 서비스 안정성 확보: Rate Limit은 API 또는 웹 서비스에 대한 과도한 요청을 방지하여 서비스의 안정성을 확보할 수 있습니다.
과도한 요청은 서비스의 과부하를 초래하여 서비스의 성능을 저하시키거나, 서비스가 다운되는 등의 문제를 발생시킬 수 있습니다.
Rate Limit을 사용함으로써 이러한 과부하를 방지하여 서비스의 안정성을 향상할 수 있습니다. - 서비스 보안 강화: Rate Limit은 무단 악용을 방지하여 서비스의 보안을 강화할 수 있습니다. |
악의적인 공격자가 서비스를 악용하기 위해 과도한 요청을 보내는 것을 방지하여, 서비스에 대한 보안 위협을 줄일 수 있습니다.
예를 들어, DDoS(분산 서비스 거부 공격)와 같은 공격에 대한 방어를 강화할 수 있습니다. - 자원 관리 및 비용 절감: Rate Limit을 통해 서비스 사용자들이 과도하게 자원을 소비하는 것을 방지할 수 있습니다.
서비스 제공자는 자원을 효율적으로 관리하고, 비용을 절감할 수 있습니다. 너무 많은 요청을 허용하지 않음으로써,
서비스 제공자는 서버 리소스, 대역폭, 데이터베이스 접근 등의 비용을 관리하고 최적화할 수 있습니다. - 공정한 서비스 제공: Rate Limit은 모든 사용자들에게 공정한 서비스를 제공하기 위해 사용될 수 있습니다.
너무 많은 요청을 허용하지 않고, 모든 사용자들에게 일정한 요청량을 허용함으로써,
일부 사용자들이 서비스를 독점하거나 불필요하게 자원을 독점하는 것을 방지할 수 있습니다. - API 사용량 제어: Rate Limit은 API 사용량을 제어하고, 계획된 API 사용량을 준수하도록 도와줍니다.
서비스 제공자가 정의한 API 사용 계획에 따라 요청을 조절함으로써,
서비스 제공자와 사용자 간의 계약을 준수하고, API 사용량을 효과적으로 관리할 수 있습니다.
Rate Limit 란 개념을 알게 되었으니,
다음 단계로 우리의 서비스에 적용 시 이상이 없는지 검증하였습니다.
이제야 간신히 주문서비스에 대한 소개가 필요한 타이밍이 왔네요.
(이 내용이 포함되어 있어 MSA이야기 2탄으로 작성되었습니다.)
기존의 Legacy 시스템에서 MSA를 지향하는 주문서비스로 전환을 주문구조개선이라 명칭하고 있습니다.
주문구조개선을 통하여 주문서비스 API와 신) 주문서비스 API를 포함하는 애플리케이션 구조를 가지게 되었으며
이를 간략하게 도식화하면 아래와 같습니다.
(주문서비스 구조개선의 자세한 이야기는
엔터프라이즈 MSA 이야기 1탄 - 주문서비스(Milestone1) :: GS Retail Engineering (tistory.com)
에서 확인하실 수 있습니다.)
주문서비스 어플리케이션 구조를 보면 API-Gateway가 서비스 가장 앞에 위치하고 있으며,
API-Gateway는 오픈소스인 KONG Gateway를 사용하고 있습니다.
KONG Gateway에서는 확장 가능하고 유연한 플러그인 시스템을 제공하며,
RateLimit 기능을 제공하는 Plugin도 제공하고 있어 이를 적용하고 테스트를 진행하였습니다.
KONG Gateway의 Rate Limit Plugin 설정 추가하기
KONG Gateway를 관리하기 위해 KONG Admin을 사용하고 있었기에 RateLimit Plugin을 손쉽게 적용하였습니다.
관련 내용이 궁금하신 분들은 KONG 공식문서를 확인해 주세요.
참고자료) KONG 공식 문서 : Rate Limiting plugin | Kong Docs (konghq.com))
RateLimit 동작 검증하기
RateLimit 동작의 검증은 부하테스트 도구 중 하나인 JMeter를 사용하였으며,
주문 API 요청에 대한 다양한 CASE를 만들고 테스트를 진행하였습니다.
Rate Limit 미설정 전 / 후 테스트 결과
RateLimit 적용 후 테스트를 진행하였을 경우에는 일정 횟수 이상의 요청이 발생하면
클라이언트는 다음과 같이 429 "API rate limit exceeded" 응답을 받는 것을 확인할 수 있었습니다.
| { "message":"API rate limit exceeded" } |
이렇게 저희는 Rate Limit에 대한 동작 검증까지 완료하였고,
그동안 발생하였던 장애발생 건들을 분석하여,
적절하다고 판단되는 설정값을 정하여 개발 및 운영환경에 적용을 하였습니다.
당연히 RateLimit 발생 시에 담당자들이 인지하고 대응할 수 있도록 알람도 추가하였고요.
물론, 실제 환경에서는 결코 마주하고 싶지 않은 알람이긴 합니다.
이게 끝입니다.
위와 같이 저희의 서비스에 적합한 오픈소스를 도입하여 사용하고 있었기에
RateLimit를 손쉽게 적용하고 검증할 수 있었습니다.
사실 오늘 소개한 RateLimit 정책 적용은
신) 주문서비스의 심각한 장애를 예방하기 위해 적용한 하나의 방법일 뿐이며,
서비스 품질을 향상하기 위해서는 앞으로도 계속 개선해 나가야 합니다.
먼저 RateLimit 동작으로 인하여 중요한 요청들도 429 에러 응답을 받게 되는 문제가 있을 수 있습니다.
주문 생성, 확정, 취소 등의 비즈니스적으로 중요한 요청에 대한 에러가 발생하는 것을 방지하기 위하여
비교적 중요도가 낮은 조회성 API에 해당하는 URL Path를 식별하고 이에 대해서만 RateLimit 적용할 수 있도록 진행할 예정이며,
RateLimit 발생 시 조치를 위한 자동화 프로세스도 진행이 되어야 합니다.
앞으로 변경사항이 발생할 경우 지속적으로 업데이트하도록 하겠으며,
저희의 성공적인 MSA 전환을 위한 항해에 앞으로도 꾸준한 관심 부탁드립니다.
감사합니다.
이민주 | 디지털서비스본부 > 홈쇼핑서비스부문 > 주문서비스팀
GSSHOP 주문서비스 아키텍트 및 연계시스템 운영
Legacy Enterprise System의 구조개선에 관심이 많습니다.
'APP' 카테고리의 다른 글
| 엔터프라이즈 MSA 이야기 3탄 – SR 도메인 편 (9) | 2023.08.01 |
|---|---|
| 우리동네GS BFF 구현기 Step 1 - 도입 배경과 설계 (1) | 2023.07.28 |
| Flutter App 실시간 CDN 이미지 변경 상태 적용 방안 (1) | 2023.06.20 |
| GS SHOP App의 메모리 확보 (2) | 2023.05.12 |
| 안드로이드 포그라운드 서비스를 활용한 메모리부족으로 앱 종료되는 현상 개선 (3) | 2023.04.17 |