2월 28일 시스템 설계 스터디

2026년 2월 28일

시스템 설계 스터디 시작

오늘 처음으로 지난번 시작된 시스템 설계 스터디의 첫 회차를 진행하게 되었습니다.

대부분은 클라우드 환경이나 다수 서버에서 대규모 서비스를 전개할 때 고려해야 하는 내용이었습니다.

클라이언트 또는 서비스가 보내는 트래픽의 처리 제어를 위한 장치입니다.

무한정 많은 처리 요청이나 서버 과부하를 방지하는 데 효과적인 방식으로,
여러 가지 방법론을 가지고 있습니다.

특정한 알고리즘에 국한된 개념이 아니므로 , 실제로 이 처리율 제한을 위해 구현하는 방식과 위치는 다양할 수 있습니다.
책에서 설명하는 것만 해도 5가지 정도 되었기에 여러가지 생각할 부분들이 많았습니다.

여러 선택지가 있어 직접 구현도 고려할 수 없지만 대중적으로 사용되는 상용 제품 선에서 만족하는게 일반적이라는 느낌이었습니다.

레디스 (Redis) 같은 상용 서비스가 이런 기능을 잘 지원해 주는 편입니다.

안정 해서는 주로 캐시 등을 균등하게 서버에 분산시키기 위해 키의 해시를 기준으로 해시 링 위에 배치하는 알고리즘입니다.

전통적인 해시 테이블과는 다르게, 모듈로 연산을 이용해 링의 형태로 해시 값들을 분배하고, 탐색을 통해서 샤딩된 이들을 탐색해 배치하는 방식입니다.

서버 오토스케일링, 세션이 자주 끊어지는 경우에 정보를 안전하게 저장하는 데 유효하게 사용할 수 있습니다.

대표적으로 예매 등의 상황에서 폭주하는 요청으로 서버가 다운되었을 때 예비 서버로의 라우팅으로 이어지는 경우를 생각할 수 있습니다.

사실 이것도 레디스가 해줍니다...(만능이네)

하지만 서버 노드마다 성능이 다를 수 있고, 이런 불균형으로 인해 재배치를 하는 데 큰 비용이 발생할 수 있습니다.
이런 경우 결정론적인 다른 해시 방식으로 재배치를 하는 방식도 고려를 할 수 있습니다.

이거저거 많이 주워들을 수 있는 시간이었습니다.

평소 업무 한계상 고려를 미처 해보지 못한 부분들이었는데 이런 것들도 고려해보면 좋겠다고 생각이 되네요.