<가상 면접 사례로 배우는 대규모 시스템 설계 기초> 책 읽고 사례 탐구 [1장, 2장]

1. Scale up & Scale out

Q. L4와 L7 로드밸런서의 차이점과 사용 사례를 설명해주세요.

L4 로드밸런서는 OSI 7계층 중 4계층인 전송 계층에서 작동하며, IP 주소와 포트 번호를 기반으로 트래픽을 분산합니다.

이는 패킷의 헤더 정보만을 이용하므로 처리 속도가 빠르며, 주로 TCP 및 UDP 프로토콜을 사용하는 서비스에 적합합니다.

예를 들어, 온라인 게임이나 스트리밍 서비스 등 실시간 트래픽 처리가 중요한 서비스에서 사용됩니다.

 

L7 로드밸런서는 OSI 7계층 중 7계층인 응용 계층에서 작동하며, HTTP 헤더, 쿠키, URL 등 요청의 내용을 기반으로 트래픽을 분산합니다. 이러한 방식은 다양한 기능과 유연성을 제공하지만, 패킷의 내용을 분석해야 하므로 처리 속도가 상대적으로 느립니다. 웹 서비스, API 게이트웨이, 콘텐츠 전송 네트워크(CDN) 등에서 주로 사용됩니다.

 

 

Q2. 하루 1억 건의 요청을 처리해야 하는 웹 서비스를 설계하려고 합니다. 높은 가용성과 균등한 부하 분산을 보장하기 위해 로드밸런서가 필요합니다.

Q2-1. 로드밸런싱 아키텍처를 어떻게 설계할 것인지 설명하세요.

1. 클라이언트의 요청을 L4 로드밸런서로 받아 IP와 포트 기반으로 분산합니다.
2. 수평적 확장: 서버의 수를 늘려 부하를 분산시키고, 오토스케일링(auto-scaling)을 통해 트래픽 변화에 따라 서버 수를 동적으로 조절합니다.
3. 지리적 분산: 전 세계 여러 지역에 데이터 센터를 배치하고, 지리적 로드밸런싱을 통해 사용자의 위치에 가장 가까운 서버로 트래픽을 분산시켜 지연 시간을 최소화합니다.

Q2-2. Round Robin, Least Connections, IP Hashing 부하 분산 알고리즘을 비교하세요.

• Round Robin: 클라이언트의 요청을 서버 목록에 따라 순차적으로 분배하는 방식입니다. 구현이 간단하며, 서버의 성능이 유사하고 서버와의 연결이 오래 지속되지 않는 경우에 효과적입니다.
• Least Connections: 현재 연결된 세션 수가 가장 적은 서버에 새로운 요청을 분배하는 방식입니다. 각 서버의 부하를 실시간으로 고려하므로, 세션 시간이 길거나 불균형한 트래픽 상황에서 유용합니다.
• IP Hashing: 클라이언트의 IP 주소를 해싱하여 특정 서버에 매핑하는 방식입니다. 동일한 클라이언트는 항상 같은 서버로 연결되므로, 세션 일관성이 필요한 경우에 사용됩니다.

Q2-3. 로드밸런서가 장애 조치(Failover) 상황과 헬스 체크(Health Check)를 어떻게 처리하는지 설명하세요.

1. 로드 밸런서는 등록된 모든 인스턴스에 대해 주기적으로 헬스 체크를 수행합니다.
2. 비정상으로 판단된 인스턴스에는 트래픽을 전달하지 않습니다.
3. 비정상 인스턴스가 복구되어 정상으로 판단되면 다시 트래픽을 전달합니다.

헬스 체크 동작 원리

1. 로드 밸런서는 설정한 간격(Interval)으로 각 인스턴스에 헬스 체크를 보냅니다.
2. HTTP/HTTPS 헬스 체크 → 응답 코드가 200 OK일 때 성공
3. TCP 헬스 체크 → TCP 연결 성공 시 성공
4. SSL 헬스 체크 → SSL 핸드셰이크가 성공하면 성공
5. 연속 실패 횟수가 Unhealthy Threshold를 초과하면 인스턴스를 비정상으로 판별
6. 연속 성공 횟수가 Healthy Threshold를 초과하면 인스턴스를 정상으로 복구

인스턴스가 헬스 체크에 실패하는 일반적인 원인:

1. 포트 차단: 보안 그룹/네트워크 ACL이 헬스 체크 포트를 차단
2. 잘못된 경로 설정: 헬스 체크 경로(Path)에 접근할 수 없음
3. 시간 초과: 인스턴스가 헬스 체크에 응답하지 않거나 응답이 늦음
4. 애플리케이션 오류: 애플리케이션이 200 응답을 반환하지 않음

해결 방법:

• 헬스 체크 경로에 브라우저에서 직접 접근해보기
• 인스턴스의 자원(CPU, 메모리) 부족 여부 확인
• 애플리케이션 로그를 확인하여 오류 발생 여부 확인
• 보안 그룹/네트워크 ACL을 확인하여 포트가 열려 있는지 확인

 

 

Q3. 초당 10,000건의 요청을 처리하는 플랫폼을 위해 고가용성을 갖춘 데이터베이스 시스템을 설계하세요.

Q3-1. 마스터-슬레이브(Master-Slave) 또는 다중 마스터(Multi-Master) 복제를 어떻게 구현할 것인지 설명하세요.

1. 마스터 설정: 쓰기 작업을 처리할 주 데이터베이스를 설정합니다.
2. 슬레이브 설정: 마스터 데이터베이스의 데이터를 복제할 보조 데이터베이스를 설정합니다.
3. 복제 설정: 슬레이브가 마스터의 변경 사항을 지속적으로 수신하도록 복제 메커니즘을 구성합니다.

Q3-2. 복제 지연(Replication Lag)을 어떻게 처리하고, 데이터 일관성(Data Consistency)을 어떻게 유지할 것인가요?

• 하드웨어 업그레이드: 슬레이브 서버의 성능을 향상시켜 복제 처리 속도를 높입니다.
• 애플리케이션 레벨 처리: 중요한 트랜잭션의 경우, 슬레이브가 아닌 마스터에서 직접 읽도록 애플리케이션을 구성하여 일관성을 보장합니다.

Q3-3. 기본 노드(Primary Node)에 장애가 발생했을 때, 장애 조치(Failover)는 어떻게 관리하나요?

1. 자동 장애 조치 시스템 구현: ZooKeeper와 같은 분산 코디네이션 서비스를 사용하여 마스터 노드의 상태를 모니터링하고, 장애 시 자동으로 새로운 마스터를 선출합니다.
2. 수동 장애 조치 절차 수립: 자동화 시스템이 없는 경우, 관리자가 수동으로 슬레이브를 마스터로 승격시키는 절차를 문서화하고 훈련합니다.
3. 데이터 일관성 검증: 새로운 마스터로 전환된 후, 데이터의 일관성을 확인하고 필요한 경우 복구 작업을 수행합니다.
4. 클라이언트 재구성: 애플리케이션이 새로운 마스터 노드에 연결하도록 구성 파일이나 서비스 디스커버리 메커니즘을 업데이트합니다.

Q3-4. 동기식(Synchronous)과 비동기식(Asynchronous) 복제의 장단점에 대해 논의하세요.

• 동기식 복제
  • 동기식 복제의 장점은 팔로워가 리더와 일관성 있게 최신 데이터 복사본을 가지는 것을 보장한다. 왜냐 팔로워의 OK 응답을 받아야지 리더가 클라이언트에게 OK을 보내기 때문
  • 동기식 복제를 사용하면 리더가 갑자기 작동하지 않아도 팔로워에게 모든 데이터가 있다는 것이 보장되기에 팔로워를 리더로 올리면 된다.
  • 단점으로는 여러 이유로 인해 동기로 작동하고 있는 팔로워가 응답을 하지 않으면 리더에서 쓰기가 처리될 수 없게 된다. 이때 리더는 모든 쓰기를 차단하고 동기 복제 서버가 다시 사용할 수 있을 때까지 기다려야 함
• 비동기식 복제 
  
  • 위와 같은 단점으로 인해 모든 팔로워를 동기식으로 작동하게 하는 건 비현실적이다. 한 노드가 장애가 발생하면 전체 시스템으로 장애가 퍼지기 때문이다.
  • 보통의 경우에는 완전히 비동기식으로 구성한다. 비동기식으로 구성하면 리더가 잘못되고 복구할 수 없으면 팔로워에 아직 복제되지 않은 모든 쓰기는 유실된다.
  • 하지만 비동기식으로 구성하면 모든 팔로워가 잘못되어도 리더가 쓰기 처리를 계속할 수 있는 장점이 있다.
  • 내구성을 약화시켜서 안 좋아 보이지만 많은 팔로워가 있거나 지리적으로 분산되었다면 비동기식 복제를 널리 사용함

 

 

2. 콘텐츠 전송 네트워크 (CDN)

Q. 글로벌 영상 스트리밍 플랫폼을 구축하고 있습니다. 지연 시간(Latency)을 줄이고 사용자 경험을 개선하기 위해 CDN을 사용할 계획입니다.

Q1. 최적의 성능을 위해 CDN 아키텍처를 어떻게 설계하시겠습니까?

• 전 세계 주요 지역에 엣지 서버를 배치하여 사용자와 가장 가까운 서버에서 콘텐츠를 제공함으로써 지연 시간을 최소화합니다.
• 자주 요청되는 콘텐츠는 엣지 서버에 캐시하고, 덜 요청되는 콘텐츠는 원본 서버에서 제공하여 스토리지와 비용을 효율적으로 관리합니다.

Q2. 동적 콘텐츠나 사용자 맞춤형 콘텐츠를 캐싱하기 위한 전략은 무엇인가요?

• 캐시 키 분할: 사용자별로 캐시 키를 생성하여 개인화된 콘텐츠를 각각 캐시
• Edge Side Includes(ESI): 페이지의 정적 부분과 동적 부분을 분리하여, 정적 부분은 캐시하고 동적 부분만 원본 서버에서 가져오는 방식입니다.
• 참고: https://experienceleague.adobe.com/ko/docs/experience-manager-learn/dispatcher-tutorial/chapter-3

Q3. 전 세계 엣지 로케이션(Edge Location)에서 캐시 삭제(Cache Purging) 및 무효화(Cache Invalidation)를 어떻게 처리하시겠습니까?

• API 기반 캐시 무효화: CDN 제공업체의 API를 활용하여 특정 콘텐츠의 캐시를 실시간으로 무효화합니다.
• 패턴 매칭을 통한 무효화: URL 패턴을 지정하여 특정 그룹의 콘텐츠를 한 번에 무효화합니다.
• TTL 설정: 캐시의 유효 기간을 설정하여 자동으로 오래된 콘텐츠를 제거합니다.
• 참고 자료: https://epart.com/웹사이트-속도-향상을-위한-캐싱-전략의-모든-것-사용/

 

Q4. 콘텐츠 전송 지연이나 지리적 지연(Geographic Latency)과 같은 잠재적인 문제를 어떻게 해결하시겠습니까?

• 지역별 데이터 센터와의 연계: CDN과 함께 지역별 데이터 센터를 활용하여 동적 콘텐츠나 개인화된 콘텐츠를 신속하게 제공함으로써 전체적인 사용자 경험을 향상시킵니다.
• 네트워크 혼잡을 피하고 최적의 경로로 데이터를 전송하기 위해 지능형 라우팅을 적용합니다.
  • Anycast: 단일 IP 주소로 전 세계 여러 서버에 트래픽을 분산.
  • Geo-DNS: 사용자 위치 기반으로 가장 가까운 서버로 요청을 라우팅.
  • BGP 최적화: 최단 경로 대신 품질이 높은 경로를 선택.

 

 

 

3. 무상태 웹 계층

Q. 하루 수백만 건의 사용자 상호작용을 처리하는 소셜 네트워크용 확장 가능한 API를 설계하려고 합니다.

Q1. 수평 확장(Horizontal Scaling)을 위해 무상태 아키텍처(Stateless Architecture)가 왜 유리한가요?

무상태 아키텍처(Stateless Architecture)는 각 요청이 독립적으로 처리되며, 서버는 이전 요청의 상태를 저장하지 않는 구조를 의미합니다. 이러한 구조는 수평 확장에 다음과 같은 이점을 제공합니다:

• 서버 간 부하 분산 용이성: 요청이 특정 서버에 종속되지 않으므로, 로드 밸런서를 통해 트래픽을 여러 서버에 균등하게 분산할 수 있습니다.
• 확장성 향상: 서버 추가 또는 제거 시, 세션 정보의 동기화가 필요 없으므로 손쉽게 서버 풀을 조정할 수 있습니다.
• 복잡성 감소: 상태 정보를 관리하지 않으므로 서버 간 동기화나 세션 저장소 관리에 대한 부담이 줄어듭니다.

Q2. 무상태 시스템에서 사용자 세션(User Session)을 어떻게 관리하시겠습니까? (예: JWT 토큰, Redis 세션 스토어)

• JWT(JSON Web Token): 사용자 인증 정보를 포함한 토큰을 생성하여 클라이언트에게 전달하고, 클라이언트는 이후 요청 시 이 토큰을 포함시켜 인증을 수행합니다. 서버는 토큰의 유효성만 검사하므로 상태를 저장할 필요가 없습니다.
  • 장점: 서버의 저장소 부담 감소, 확장성 향상, 다양한 도메인 간 인증 용이.
  • 단점: 토큰 탈취 시 보안 위험, 토큰 크기에 따른 네트워크 부하 증가.
• Redis와 같은 인메모리 데이터베이스를 활용한 세션 스토어: 세션 정보를 중앙 집중식 인메모리 데이터베이스에 저장하여, 모든 서버가 동일한 세션 정보를 공유하도록 합니다.
  • 장점: 빠른 데이터 접근 속도, 세션 데이터의 일관성 유지.
  • 단점: 별도의 세션 저장소 관리 필요, 무상태의 순수한 형태는 아님.

Q3. 무상태 환경에서 인증(Authentication)과 요청 제한(Rate Limiting)을 어떻게 처리하시겠습니까?

• 인증(Authentication): 클라이언트는 로그인 시 발급받은 JWT를 이후 요청의 헤더에 포함시켜 서버에 전달합니다. 서버는 각 요청마다 토큰의 유효성을 검사하여 인증을 수행합니다.
  • 장점: 서버 측 상태 저장이 필요 없으며, 확장성이 높습니다.
• 요청 제한(Rate Limiting): 클라이언트의 IP 주소나 API 키를 기준으로 일정 시간 내 허용된 요청 수를 제한합니다. Redis와 같은 인메모리 데이터베이스를 활용하여 각 클라이언트의 요청 횟수를 저장하고 관리할 수 있습니다.
  • 장점: 분산 환경에서도 빠르고 효율적인 요청 제한이 가능합니다.

Q4. 일부 마이크로서비스(Microservices)에 장애가 발생했을 때, 점진적 축소(Graceful Degradation)를 어떻게 구현하시겠습니까?

점진적 축소(Graceful Degradation)는 시스템의 일부 구성 요소에 장애가 발생하더라도 전체 시스템이 완전히 중단되지 않고, 핵심 기능을 유지하며 부분적인 서비스 저하로 대응하는 전략입니다. 이를 구현하기 위한 방법은 다음과 같습니다:

• 폴백(Fallback) 메커니즘: 장애가 발생한 서비스의 기능을 대체하거나 축소된 형태로 제공하는 대안을 마련합니다. 예를 들어, 추천 시스템이 장애를 일으킬 경우, 기본적인 인기 콘텐츠를 제공하는 방식입니다.
• 타임아웃 설정: 각 서비스 호출에 최대 대기 시간을 설정하여, 응답이 지연되는 서비스로 인해 전체 시스템의 응답성이 저하되지 않도록 합니다.

 

 

 

4. 데이터센터

Q. 여러 대륙에 걸쳐 있는 데이터센터를 활용하여 재해 복구에 강한 시스템을 설계해야 합니다.

Q1. 고가용성(High Availability)과 내결함성(Fault Tolerance)을 보장하기 위해 다중 리전(Multi-Region) 아키텍처를 어떻게 설계하시겠습니까?

각 데이터센터가 독립적으로 동작할 수 있도록 서비스를 분리하고, 필요 시 리전 간에 빠른 장애 전환(Failover)이 가능하도록 설계합니다.--> 각 대륙에 위치한 데이터센터를 Active-Active 또는 Active-Passive 형태로 구성하여, 한 리전에 장애가 발생하더라도 다른 리전이 자동으로 트래픽을 흡수할 수 있도록 합니다.

• Active-Active 아키텍처
  • Active-Active 아키텍처에서는 여러 데이터센터 또는 리전의 모든 인스턴스가 동시에 활성화되어 사용자 요청을 처리합니다.
  • 장점:
    • 부하 분산이 자연스럽게 이루어져, 각 노드에 균등하게 트래픽이 분산됩니다.
    • 하나의 노드에 장애가 발생해도 다른 노드가 지속적으로 서비스를 제공하므로 고가용성을 보장합니다.
    • 전반적인 응답 시간이 개선될 수 있으며, 글로벌 사용자에게 낮은 지연 시간을 제공합니다.
  • 단점:
    • 여러 위치에서 동시 업데이트가 이루어지므로, 데이터 동기화 및 일관성 유지가 복잡해질 수 있습니다.
• Active-Passive 아키텍처
  • Active-Passive 아키텍처에서는 한 데이터센터 또는 리전이 활성 상태로 서비스를 제공하고, 다른 인스턴스들은 대기(standby) 상태를 유지합니다.
  • 장점:
    • 구현과 관리가 비교적 단순하며, 데이터 동기화 및 일관성 관리가 용이합니다.
    • 장애가 발생할 경우 대기 중인 노드가 활성화되어 서비스 연속성을 유지할 수 있습니다.
  • 단점:
    • 활성 노드에 장애가 발생할 때 전환 시간(RTO)이 발생하며, 일부 데이터 손실(RPO) 가능성이 있을 수 있습니다.
    • 자원의 활용도가 Active 상태인 노드에 집중되어, 대기 노드의 자원이 효율적으로 사용되지 않을 수 있습니다.
• 참고 링크
  • https://aws.amazon.com/ko/blogs/tech/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/

Q2. 재해 복구(Disaster Recovery)를 위한 전략(RTO와 RPO)과 리전 간 데이터 동기화(Data Synchronization) 방법을 설명하세요.

비즈니스 운영에 미치는 영향을 최소화하기 위해 RTO를 가능한 짧게 설정하는 것이 중요합니다.

중요한 데이터의 경우 RPO를 극한으로 낮춥니다. 예를 들어, RPO가 5분이면 장애 발생 시 최대 5분간의 데이터가 손실될 수 있음을 의미합니다.

• RTO (Recovery Time Objective): 장애 발생 후 서비스를 복구하여 정상 운영 상태로 전환하기까지 허용되는 최대 시간
• RPO (Recovery Point Objective):장애 발생 시 허용 가능한 최대 데이터 손실 범위를 시간 단위로 나타냄.

 

리전 간 데이터 동기화:

• 동기식 복제: 데이터 일관성이 필수적인 경우, 지연 시간이 허용 범위 내라면 동기식 복제를 적용하여 데이터의 완전한 일관성을 유지합니다.
• 비동기식 복제: 지리적 거리에 따른 네트워크 지연이 큰 경우, 비동기식 복제를 사용하여 성능과 가용성 사이의 균형을 맞춥니다.

Q3. 최종 사용자의 지연 시간(Latency)을 최소화하기 위해 지리적 라우팅(Geo-Routing)을 어떻게 구성하시겠습니까?

• 지리 기반 DNS 라우팅:
• 사용자의 IP 주소를 기반으로 가장 가까운 데이터센터로 트래픽을 분산시킵니다.
• Anycast IP 기술 활용:
• 단일 IP 주소를 전 세계 여러 데이터센터에 할당하여, 네트워크 최적 경로를 통해 가장 빠른 응답을 제공하도록 합니다.
• CDN(Content Delivery Network) 연계:
• 정적 콘텐츠의 경우, CDN을 통해 전 세계 캐시된 서버에서 제공하여 지연 시간을 더욱 줄입니다.

Q4. 데이터센터 간의 데이터 일관성(Data Consistency)을 어떻게 유지할 것인가요?

• 분산 합의 프로토콜:
  • Paxos, Raft와 같은 합의 알고리즘을 활용하여 다중 리전 간의 데이터 변경 사항을 동기화하고, 충돌 시 자동으로 조정합니다.
• 일관성 모델 선택:
  • 강력한 일관성(Strong Consistency): 중요한 트랜잭션에 대해 동기식 복제를 사용하여 모든 리전에서 동일한 데이터를 보장합니다.
  • 최종적 일관성(Eventual Consistency): 사용자 경험에 큰 영향을 주지 않는 경우, 비동기식 복제를 사용하여 지연 시간을 줄이고 가용성을 높입니다.
• 캐시 일관성 전략:
  • 각 리전의 로컬 캐시와 중앙 데이터베이스 간의 일관성을 유지하기 위한 Write-Through 또는 Write-Behind 기법을 사용합니다.

 

 

5. 메시지 큐

Q. 하루 수백만 건의 메시지를 처리하는 메시징 앱의 실시간 알림 시스템을 설계하려고 합니다.

Q1. Kafka, RabbitMQ, AWS SQS 등 어떤 메시지 큐를 선택할 것이며, 그 이유는 무엇인가요?

• Apache Kafka는 대용량의 데이터 스트림을 처리하는 데 최적화된 분산형 메시징 시스템으로, 높은 처리량과 확장성을 제공합니다. 하루 수백만 건의 메시지를 처리해야 하는 실시간 알림 시스템에서는 이러한 특성이 중요한데, Kafka는 다음과 같은 이유로 적합한 선택이 될 수 있습니다:
  • 높은 처리량과 낮은 지연 시간: Kafka는 대량의 메시지를 낮은 지연 시간으로 처리할 수 있습니다.
  • 수평적 확장성: 브로커와 파티션을 추가하여 시스템을 쉽게 확장할 수 있습니다.
  • 내구성 및 안정성: 디스크에 데이터를 저장하여 내구성을 보장하며, 복제를 통해 데이터 손실을 방지합니다.
• RabbitMQ는 복잡한 라우팅과 다양한 프로토콜을 지원하는 범용 메시지 브로커로, 비교적 낮은 처리량을 요구하는 시스템에 적합합니다.
• AWS SQS는 관리형 서비스로서 인프라 관리 부담을 줄여주지만, 초당 수십만 건 이상의 메시지를 처리하는 데는 한계가 있을 수 있습니다.

Q2. 메시지 순서 보장(Message Ordering), 중복 제거(Deduplication), 정확히 한 번만 전달(Exactly-Once Delivery)을 어떻게 구현할 것인가요?

• 메시지 순서 보장 (Message Ordering):
  • Kafka: 파티션 단위로 메시지 순서를 보장합니다. 특정 키를 기반으로 파티션을 지정하여 관련된 메시지가 동일한 파티션에 저장되도록 하면 순서가 유지됩니다.
• 중복 제거 (Deduplication):
  • Kafka: 프로듀서에서 메시지 키를 사용하여 동일한 키의 중복 메시지를 식별하고 처리할 수 있습니다.
• 정확히 한 번만 전달 (Exactly-Once Delivery):
  • Kafka: 프로듀서와 컨슈머 설정을 통해 정확히 한 번 전달을 구현할 수 있습니다. 프로듀서는 acks=all 설정과 아이돌포텐트(idempotent) 프로듀서를 사용하고, 컨슈머는 오프셋을 적절히 관리하여 중복 처리를 방지합니다.

Q3. 갑작스러운 트래픽 급증에 대비해 메시지 큐를 확장하기 위한 전략은 무엇인가요?

• 파티션 추가: 토픽의 파티션 수를 늘려 병렬 처리를 향상시킵니다. 각 파티션은 별도의 컨슈머 스레드에 의해 처리되므로, 파티션 수를 늘리면 컨슈머 그룹의 처리량을 높일 수 있습니다.
• 브로커 추가: 클러스터에 브로커를 추가하여 저장 및 처리 용량을 확장합니다.

Q4. Apache Kafka: 내결함성(Fault Tolerance)을 어떻게 보장할 것이며, 데드 레터 큐(Dead-Letter Queue)를 어떻게 처리할 것인가요?

• 내결함성은 시스템에 일부 장애가 발생하더라도 전체 시스템이 중단되지 않고 정상적으로 동작할 수 있도록 하는 능력입니다. 이를 구현하기 위해 다음 전략을 사용할 수 있습니다
  • kafka:
    • replication.factor=3으로 설정 시, 최소 3개의 브로커에 동일한 데이터를 저장.
    • ISR(In-Sync Replicas) 내에서 리더 브로커에 장애가 발생하면 자동으로 팔로워 중 하나가 리더가 됨.
    • 실패한 메시지에 대해 재시도(Retry) 로직을 구현. Kafka에서는 retry.backoff.ms와 retries 설정을 활용.
• 데드 레터 큐(DLQ)는 처리 실패한 메시지를 저장하는 큐로, 무한 재시도로 인한 시스템 부하를 방지하고, 문제 해결 후 재처리를 가능하게 합니다.
  • Kafka에서는 별도의 DLQ 토픽을 생성하여, 재시도 횟수 초과 메시지를 이 토픽으로 전송.
  • DLQ에 쌓이는 메시지의 양을 지속적으로 모니터링.
  • Prometheus + Grafana를 사용하여 DLQ 상태 대시보드 생성 가능.
  • 특정 수의 메시지가 DLQ에 쌓이면 Slack, Email 등을 통해 알림 전송.

Q5. Apache Kafka: 어떤 방법으로 데이터 유실 문제를 방지할 수 있나요?

• 프로듀서: acks 설정
• 브로커: 각 토픽의 파티션을 복제하여 특정 브로커가 장애를 겪더라도 데이터가 손실되지 않도록 함.
• 컨수머: 수동 커밋 (메세지 처리가 완료된 후에 오프셋 커밋)

Q6. 큐의 병목현상(Bottleneck) 발생 시, 이를 해결할 수 있는 확장 전략에는 어떤 것들이 있나요?

• 수평 확장(Horizontal Scaling): 큐를 처리하는 컨슈머 인스턴스의 수를 늘려 병렬 처리를 강화합니다. Kafka와 RabbitMQ 모두 컨슈머 그룹을 통해 수평 확장이 가능합니다.
• 로드 밸런싱(Load Balancing): 메시지를 여러 큐나 컨슈머로 고르게 분산하여 특정 큐에 부하가 집중되지 않도록 합니다. RabbitMQ는 로드 밸런싱을 통해 메시지를 분산시킬 수 있습니다.
• 자동 스케일링(Auto Scaling): 트래픽 패턴을 모니터링하여 컨슈머 인스턴스의 수를 자동으로 조절합니다. AWS SQS는 Auto Scaling과 연계하여 동적으로 확장할 수 있습니다.

 

 

6. 로그, 매트릭, 자동화

Q. 마이크로서비스 아키텍처를 위한 실시간 모니터링 및 로그 수집 시스템을 설계해야 합니다.

Q1. 메트릭을 기반으로 실시간 경고 시스템을 설계할 때, 어떤 알림 기준과 임계값을 설정하시겠습니까?

• 시스템 자원 메트릭: CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 등. 예를 들어, CPU 사용률이 80% 초과 시 경고, 90% 초과 시 심각 알림. / 전체 메모리의 85% 사용 시 경고.
• 애플리케이션 성능 메트릭: 응답 시간, 처리량, 에러율 등. 특정 API의 에러율이 1%를 넘거나 응답 시간이 2초를 초과하는 경우 경고를 생성합니다.
• 인프라 메트릭: 서버 가용성, 데이터베이스 연결 수, 큐 대기 시간 등. 데이터베이스 연결 실패 횟수가 일정 수치를 넘으면 알림을 생성합니다.

 

7. 데이터베이스

Q. 수백만 개의 사용자 데이터를 저장하고 복잡한 쿼리를 지원하는 SaaS 플랫폼을 구축하려고 합니다.

Q1. 기능과 데이터 유형에 따라 SQL과 NoSQL 데이터베이스 중 어떤 것을 선택할지, 그리고 그 이유는 무엇인가요?

• 금융 트랜잭션은 SQL로, 사용자 행동 로그나 세션 정보는 NoSQL로 저장하는 식

Q2. 데이터베이스 샤딩(Sharding)**을 어떻게 구현할 것인지, 그리고 핫스팟(Hotspot) 문제를 어떻게 해결할 것인가요?

데이터베이스 샤딩(Sharding)  

• 대규모 데이터베이스를 작은 단위(Shard)로 분할하여 각 샤드에 데이터를 분산 저장하는 기술입니다. 이를 통해 데이터베이스의 확장성(Scalability)과 성능(Performance)을 향상시킬 수 있습니다.
• 수평 분할: 데이터를 여러 샤드(노드)로 나누어 저장하여 단일 노드의 부하를 줄입니다.
• 샤딩 키(Shard Key) 선택
  • 균등 분포 보장: 사용자 ID, 지리 정보, 타임스탬프 등 고르게 분포할 수 있는 키를 선택합니다.
  • 해시 기반 샤딩: 입력 키에 해시 함수를 적용하여 데이터가 고르게 분산되도록 하는 방법. 예를 들어, 사용자 ID에 대한 해시 값으로 샤드 결정.
  • 범위 기반 샤딩: 특정 범위(예: 날짜, 숫자 범위 등)를 기준으로 데이터를 분할하여 저장하는 방법.
  • 복합 키 샤딩: 두 개 이상의 필드를 조합하여 샤딩 키로 사용하면, 단일 필드만 사용하는 것보다 데이터 분포를 더욱 세밀하게 조정할 수 있습니다.

핫스팟(Hotspot)

• 데이터베이스의 특정 파티션이나 샤드에 요청이 과도하게 집중되어 시스템 성능이 저하되는 현상을 의미합니다. 주로 비효율적인 샤딩 전략이나 특정 데이터 패턴으로 인해 발생합니다.
• 동적 리밸런싱:
• 모니터링 도구를 사용하여 특정 샤드에 부하가 집중되면 데이터를 재분배합니다.
• 추가 캐싱 계층:
  • Redis나 Memcached 같은 인메모리 캐시를 활용하여 인기 데이터에 대한 읽기 부하를 줄입니다.

•  

Q3. 읽기(Read)와 쓰기(Write) 성능을 확장하기 위해 읽기 전용 복제본(Read Replicas), 파티셔닝(Partitioning), 커넥션 풀링(Connection Pooling) 등의 기술을 어떻게 사용할 것인가요?

• 읽기 전용 복제본(Read Replicas)
  • 클라우드 서비스(AWS RDS, Google Cloud SQL 등)에서 기본 제공하는 복제 기능을 활용하거나, 자체적으로 복제 메커니즘을 구축합니다.
• 파티셔닝(Partitioning)
  • 날짜, 지역, 사용자 범위 등을 기준으로 테이블을 분할합니다.
  • 각 파티션에 대해 별도의 인덱스를 생성하여 쿼리 범위를 좁히고, 처리 속도를 높입니다. 쿼리 시 전체 데이터 집합을 스캔하는 대신 해당 파티션만 조회하게 되어 효율적입니다.
• 커넥션 풀링(Connection Pooling)
  • 데이터베이스 연결을 미리 생성해둔 풀에서 재사용함으로써, 매번 연결을 새로 생성하는 오버헤드를 줄입니다.

Q4. 실시간 트래픽 급증에 대비해 Auto-scaling이나 Load Balancing을 어떻게 설계할 것인가요?

• 데이터베이스 Auto-scaling 설계
  • 읽기 전용 복제(Read Replica) 기반 수평 확장
    • 트래픽이 급증할 경우 주 데이터베이스(Primary)에 대한 읽기 요청을 여러 읽기 전용 복제본(Read Replica)으로 분산시킵니다.
    • 복제본 추가 시 고려사항: 복제본이 늘어날수록 데이터 동기화 지연이나 연결 관리 이슈가 발생할 수 있으므로, 복제본의 상태와 응답 속도를 주기적으로 모니터링해야 합니다.
  • 쓰기 확장을 위한 샤딩(Sharding)
    • 쓰기 부하가 급증할 경우 하나의 데이터베이스 인스턴스에 모든 쓰기가 집중되지 않도록, 데이터를 특정 기준(예: 사용자 ID, 지역, 타임스탬프 등)에 따라 여러 샤드로 분할합니다.
    • 자동화 도구 및 오케스트레이션: 일부 클라우드 서비스나 오픈소스 솔루션은 샤드 간의 데이터를 자동으로 분배하거나, 신규 샤드를 추가할 때 데이터 재분배(리샤딩)를 지원합니다.
  • 메트릭 기반 스케일링 정책
    • AWS, GCP, Azure와 같은 클라우드 제공업체의 Auto Scaling 기능과 관리형 데이터베이스 서비스를 활용하면, 복잡한 스케일링 로직을 자체적으로 구현하지 않고도 자동화된 확장이 가능합니다.
• 데이터베이스 Load Balancing 설계
  • 트래픽 분리:
    • 쓰기 요청은 데이터 일관성을 위해 주 데이터베이스(Primary)로 직접 라우팅합니다.
    • 읽기 요청은 복제본(Read Replicas)이나 샤딩된 노드로 분산하여 부하를 줄입니다.
  • 데이터베이스 프록시 사용:ProxySQL, HAProxy, 또는 클라우드 기반의 데이터베이스 프록시(RDS Proxy 등)를 활용해, 쿼리의 종류(읽기 vs. 쓰기)를 감지한 후 적절한 서버로 라우팅할 수 있습니다.

Q5. 인기 계정의 트래픽을 분산시키기 위해 사용할 수 있는 아키텍처적 접근법에는 어떤 것들이 있나요?

인기 계정이나 특정 그룹의 트래픽이 집중되는 경우, 해당 데이터만을 위한 전용 샤드 또는 파티션을 구성합니다.

• 특정 VIP 계정의 데이터를 별도의 데이터베이스 클러스터에 저장
• 인기 계정의 콘텐츠 업데이트, 조회 등을 별도로 모니터링하여 자동 리밸런싱을 적용