[가상면접 사례로 배우는 대규모 시스템 설계 기초] - Chapter 4

처리율 제한 장치의 설계

책에서 말하는 처리율 제한 장치는 API 요청 횟수가 특정 임계치를 초과하면 추가 요청을 차단하거나 지연시키는 기능이다.

이러한 장치는 DoS 공격을 방지하고, 서버의 과부하를 줄이며, 운영 비용을 절감하는 데 도움을 준다.

문제 이해 및 설계 범위 확정

처리율 제한 장치를 만들때 고려해야할 점

• 클라이언트를 위한 처리율 제한인가? 서버를 위한 처리율 제한 장치인가?? -> 서버를 위한 장치다.
• 어느 규모의 데이터를 제한하기 위한 것인가?? 스타트업인가??대규모 서비스 인가?? -> 대규모 서비스를 고려해야한다.
• 독립 서비스에서 동작하는 건가??? 애플리케이션에서 동작하는건가?? -> 애플리케이션에서 동작한다.

아키텍처

- 가장 기억에 남는 부분은 아키텍처 설계다. 특히 인상 깊었던 점은 처리율 제한 규칙을 관리하는 별도의 서비스가 존재한다는 것이다. API와 분리하여 독립적으로 제공되면서도 일관된 방식으로 작동할 수 있다는 점이 새로웠다. 이를 통해 요청을 효과적으로 제한하고 확장성을 확보할 수 있다는 것을 깨닫게 되었다.

 

읽고 난 후 

이 책을 통해 처리율 제한 장치가 단순히 특정 초당 요청 수를 제한하는 기능이 아니라, 서비스 안정성과 비용 관리, 보안까지 깊이 연결된 중요한 개념이라는 걸 배웠다. 처음에는 단순히 API 요청을 일정 수 이상 넘지 않게 차단하는 정도로만 생각했지만, 실제로는 트래픽 패턴을 분석하고, 사용자 경험을 고려하며, 서버 부하를 최소화하는 전략적인 접근이 필요하다는 걸 깨달았다.

 

특히, 사용자 경험과 서버 안정성 간의 균형을 맞추는 것이 가장 중요한 부분이라는 생각이 들었다. 예를 들어, 너무 엄격한 처리율 제한을 적용하면 사용자는 갑작스럽게 요청이 차단되는 불편을 겪을 수 있다. 반대로, 제한이 너무 느슨하면 서비스가 과부하로 인해 다운될 위험이 커진다. 책에서 소개된 견성과 연성 개념이 흥미로웠는데, 실제로 어떤 방식이 적절한지는 서비스 성격에 따라 다를 것 같다. 예를 들어, 로그인 시도 제한은 보안이 중요한 만큼 강하게 차단하는 것이 필요하지만, API 요청 제한은 사용자의 정상적인 활동을 방해하지 않도록 점진적으로 제한하는 방식이 더 적절해 보인다.

 

또한, 책을 읽으면서 이론적으로는 단순해 보이는 개념도 실제 환경에서는 여러 변수를 고려해야 한다는 점을 실감했다.
예를 들어, 하나의 서버에서 처리율 제한을 적용하는 건 어렵지 않지만, 마이크로서비스 환경에서는 여러 서버가 동일한 정책을 공유해야 하는 문제가 있다. 사용자가 여러 개의 장치(PC, 모바일, 태블릿)에서 동시에 요청을 보낼 수도 있고, 특정 순간에 트래픽이 폭증할 수도 있다.

 

이런 경우 분산 환경에서의 동기화 문제, 중앙 집중형 데이터 저장소 활용, 경쟁 조건 해결 방법 등을 고민해야 한다. 이론만 알고 있으면 쉽게 해결될 것 같지만, 현실에서는 데이터 일관성 문제나 성능 병목 현상이 발생할 수도 있다는 점을 고려해야겠다고 느꼈다.

 

추가 정리

서버의 처리율 제한은 단순히 DoS 방어를 위한 것 만이 아니라, 짧은 시간 내에 과도한 요청이 몰릴 때 서버가 과부하되지 않도록 보호하는 것이 핵심 목표이다. 결국, 모든 사용자가 일정한 속도로 안정적인 서비스를 이용할 수 있도록 하는 것이 중요하다.

예를들어) 요즘 유행하는 유튜버 등 방송를 할때 댓글을 생각해보면 편했다. 여러 사용자가 채팅을 통해 대화를 시작하는데 한 사용자가 채팅을 지배하게 되면 대화는 이루어지지 않고 쉽게 대화창을 장악할수가 있다. 토큰버킷 알고리즘과 이동 윈도 카운터에 대한 좋은 예시가 있어서 다음 주소를 참고하면 좋을것 같다.

https://smudge.ai/blog/ratelimit-algorithms?utm_source=oneoneone

 

토큰 버킷과 이동 윈도 카운터는 네트워크 트래픽 관리 및 서버 보호를 위해 필수적인 알고리즘이다.
단순한 공격 방어뿐만 아니라 서비스의 안정성과 공정성을 유지하는 데 중요한 역할을 한다.