시스템 디자인 인터뷰 준비 (5) - HLD 인터뷰 예제의 컴포넌트 뜯어보기

1) 시스템 디자인 인터뷰에 필요한 개념들을 확실히 함
2) 디자인 패턴/LLD
3) 시스템 디자인 시 각 컴포넌트의 역할 (HLD)
4) HLD 인터뷰 예제

5) HLD 인터뷰 예제의 컴포넌트 뜯어보기 <- NOW! & Finally Last

드디어 마지막 ㅎ

글또를 시작할때마다 글을 참.. 잘 읽히게 써보자! 하는데 결국은 조금 언프로페셔널하면서도 그냥 내가 말하듯이 일기쓰듯이 쓰게 되어버리네.. ㅎㅎ

-

서론. 왜 컴포넌트를 뜯어보는가?

시스템 디자인이 처음엔 쉽게ㅎ 느껴지다가 할수록 어려워진 이유는,

예를 들어 내가 데이터베이스를 넣겠소! 하면 데이터베이스도 여러 가지 종류가 있으니 Sql을 할지 NoSql을 할지, 관계형을 할지 계층형을 할지 이런 부분까지 정해야 하며 왜 그 데이터베이스를 선택했는지 이유도 설명할 수 있어야 하기 때문이다.

그냥 써드파티 쓰겠소! 라며 블랙박스처럼 처리해버리는 경우에도 어떤 써드파티를 쓸지, 예를 들면 aws s3을 쓸지 다른 걸 쓸지 왜 이걸 써드파티로 빼버려도 되는지 까지도 설명을 해야 한다. 

인터뷰 볼때 하나하나 설명을 다 해야한다는 건 아니고, 일단 중요한 부분들 위주로 내가 먼저 설명하되 어쨌든 질문이 들어오면 내가 왜 그런 선택을 했는지를 말할 수 있어야 하니까.. :)

정말 논리와 지식이 공존하는 순간이 아닐까 싶다.

 

 

Requirements

• 긴 URL을 입력 받아 짧은 URL 생성
• 짧은 URL을 통해 원본 URL로 리다이렉트
• 높은 가용성, 짧은 응답 시간, 트래픽 확장성, 사용 통계를 위한 클릭 수 추적

 

Flow:

1. 긴 URL을 입력받는다.

2. DB에 해당 긴 URL이 있는지 확인한다.

3. 있으면, DB에 기록된 짧은 URL을 반환한다.

4. 없으면, 새로운 ID를 생성한다.

5. ID를 짧은 URL로 변환한다.

6. ID, 긴 URL, 짧은 URL을 DB에 저장한다.

 

이렇게 흐름을 정리했을 때,

아.. 일단 DB 필요하고, 짧은 응답시간 있으면 좋으니 캐싱이 필요할거같고, 높은 가용성.. 하면 로드밸런싱도 하면 좋겠네.

라고 컴포넌트를 구성해볼 수 있다. 그렇게 플로우를 정리해보면 아래와 같은 아키텍처가 나올 것이다.

그럼 이제 드디어 컴포넌트를 하나씩 보자.

 

 

컴포넌트 분석 - 로드 밸런싱

API Gateway와 Load Balancer는 둘 다 트래픽을 관리하는 역할을 하는데.. 그럼 뭘 써야할까? 채대리에게 비교시켜봤다.

기능	API Gateway	Load Balancer
주요 역할	인증, 캐싱, 라우팅, 요청 검증	트래픽 분산, 서버 부하 균등화
캐싱 여부	응답 캐싱 가능 (주로 헤더 기반)	없음
트래픽 처리	요청 라우팅 및 일부 로드 분산 처리	모든 트래픽을 균등하게 분산
추가 기능	속도 제한 (Rate Limiting), 로깅	Health Check, Failover 지원
배포 위치	애플리케이션 앞단	API Gateway 또는 서버 앞단에 위치

• API Gateway도 로드 밸런싱이 가능하지만, 고성능 트래픽 분산이 필요한 경우 별도의 Load Balancer를 두어 더 효율적인 트래픽 처리와 장애 대응이 가능합니다.
• API Gateway는 주로 기능 중심 (인증, 라우팅, 캐싱) 역할에 집중하고, Load Balancer는 트래픽 분산에 최적화되어 있어 각자의 강점을 조합할 수 있습니다.

..라고 한다.

하.. 솔직히 둘중에 선택하라하면 잘 모르겠다. 내가 둘다 써보질 않아서.. ^^

어쨌든 간단한 서비스이긴 하지만 트래픽 관리를 정말 빡쎄게 하고싶다면 로드밸런서를 따로 두는게 나아보인다. 

 

 

 

컴포넌트 분석 - 캐싱 레이어

몰랐는데 API Gateway가 캐싱도 해서 채대리에게 Redis와 비교해달라고 해보았다.

기능	API Gateway 캐싱	Redis 캐싱
캐싱 위치	API 요청 앞단 (응답 데이터 캐싱)	백엔드 데이터 조회 결과 캐싱
주요 목적	동일 요청 반복 시 빠른 응답 제공	자주 조회되는 데이터 빠른 제공
TTL 지원	제한적 (주로 API 응답 헤더 기반)	세밀한 TTL(Time To Live) 설정 가능
확장성	API Gateway 부하 증가 시 한계	클러스터링으로 확장 가능 (Redis Cluster)

• API Gateway 캐싱은 응답 시간을 줄일 수 있지만, 대량 데이터 캐싱이나 세밀한 TTL 관리가 어렵습니다.
• Redis는 데이터 중심 캐싱에 강하고, 대규모 확장성과 세밀한 제어가 필요할 때 더 적합합니다.

라고 한다.

음.. 이 또한 모르겠다ㅎ 이 내용에 대해 쓰면서 이렇게 모르겠다 남발해도 되는건지..

일단 api gateway가 기능이 많다보니 너무 많은 일을 한번에 하는 것은 좋아보이지도 않고, url 종류의 가능성은 무궁무진하니까 확장이 가능한 Redis를 쓴다고 해보자 ㅎㅎ

 

 

 

 

컴포넌트 분석 - 데이터베이스

URL 데이터 저장/조회에 필요하다. 

데이터 구조:

• short_url -> long_url 맵핑
• long_url -> short_url 역방향 조회 지원 (중복 처리 목적)
• 클릭 수, 생성 날짜 등 메타데이터 포함

요구사항중에 빠른 응답이 포함되어있으므로 캐싱을 하더라도 또한 빠른 db 조회를 위해 아래와 같이 조합해볼 수 있겠다.

 

주요 DB: 문서 기반 NoSQL 데이터베이스 (ex. MongoDB, Amazon DocumentDB)

• 유연한 스키마로 메타데이터 확장 가능
• 복합 인덱스를 통한 양방향 조회 지원
• 수평적 확장성이 우수

캐싱: 위에서도 언급하긴 했지만, 추가로 Key-Value 데이터베이스인 Redis도 활용

• 자주 접근되는 URL에 대한 초고속 조회 제공
• 메인 DB 부하 감소
• 간단한 키-값 구조
  
  

-

해보니 분석할거 별로 없군; 머쓱타드

아무튼 드디어 끝!