가상면접 사례로 배우는 대규모 시스템 설계 기초 9장~10장 정리

[9장] 웹 크롤러 설계

크롤러 설계 시 주의사항

• 규모 확장성: 병행성을 활용하여 더 효과적으로 웹 크롤링을 할 수 있어야 한다.
• 안정성: 잘못 작성된 HTML, 아무 반응 없는 서버, 악성 코드가 붙은 링크 등 비정상적인 환경에 잘 대응할 수 있어야 한다.
• 예절: 크롤러는 수집 대상 웹 사이트에 짧은 시간 너무 많은 요청을 보내서는 안된다.
• 확장성: 새로운 형태의 콘텐츠를 지원하기 쉬워야 한다.

크롤러의 작업 흐름

1. 시작 URL들을 미수집 URL 저장소에 저장
2. HTML 다운로더는 미수집 URL 저장소에서 URL 목록을 가져옴
3. 도메인 이름 변환기를 이용하여 가져온 URL의 IP주소를 알아내고 해당 주소로 접속하여 웹 페이지를 다운로드 받음
4. 콘텐츠 파서에서 다운받은 HTML 페이지를 파싱해서 올바른 형식인지 검증
5. 중복컨텐츠인지 확인하기 위해 이미 저장소에 있는지 확인하여 있으면 버림
6. URL 추출기는 해당 HTML 페이지에서 URL 추출
7. 골라낸 URL을 URL 필터로 전달
8. 필터링 이후 남은 URL들을 중복 URL인지 판별(저장소에 저장되어 있는지 확인)
9. 중복 URL이 아니면 URL 저장소에 저장 및 미수집 URL 저장소에 전달

핵심 컴포넌트와 적용된 기술

• DFS vs BFS → BFS
• 미수집 URL 저장소
  • 만약 아무 안전장치가 없다면 한 페이지에 매우 많은 요청을 보내게 됨 → 동일 웹사이트에 대해서는 한 번에 한 페이지만 다운로드 각 다운로드 스레드는 별도 FIFO 큐를 두고 해당 큐에서 꺼낸 URL만 다운로드
    
  • 큐 라우터는 매핑테이블을 참고하여 같은 웹사이트에 대한 요청은 같은 큐로 보냄
  • 큐 선택기는 큐들을 순회하며 URL을 꺼내서 각 작업 스레드에 전달
• HTML 다운로더
  • 크롤러가 이 웹사이트에서 지켜야할 규칙을 넣어둔 Robots.txt 캐싱
  • 분산 크롤링: 각 서버는 여러 스레드를 돌려 다운로드 작업 처리
  • 도메인 이름 변환 결과 캐시: DNS 요청을 보내고 결과를 받는 작업이 동기적이므로 병목 현상 발생 → 도메인 이름과 IP 주소 사이 관계를 캐시에 보관 & 크론 잡을 돌려 주기적으로 갱신하여 성능 향상
  • 짧은 타임아웃: 어떤 웹서버는 응답이 느리거나 없으므로 타임아웃 제한 두기

[10장] 알림 시스템 설계

알림 매커니즘

• iOS 푸시 알림
  • 알림 제공자가 알림 요청을 만들어 애플 푸시 알림 서비스(APNS)로 보냄
    • 알림 요청에는 단말 토큰과 페이로드가 필요
  • APNS는 애플이 제공하는 원격 서비스로, 푸시 알림을 iOS 장치로 보내는 역할 담당
• 안드로이드 푸시 알림
  • iOS와 거의 동일하나 APNS대신 FCM(Firebase Cloud Messaging)을 사용
• SMS 메시지
  • 제 3 사업자의 서비스를 많이 이용
• 이메일
  • 제 3 사업자의 서비스를 많이 이용

연락처 정보 수집

사용자가 계정 등록 시 연락처를 수집하여 DB에 저장

알림 전송 및 수신 절차

• 데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리
  • 캐시에는 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시
  • DB에는 사용자, 알림, 설정 등 저장
• 알림 서버를 증설하고 자동으로 스케일 아웃이 이루어질 수 있도록 함
• 메시지 큐를 이용하여 시스템 컴포넌트 사이의 결합 끊음
  • 컴포넌트간의 의존성을 제거
  • 다량의 알림이 전송될 경우를 대비한 버퍼의 역할도 함
  • 각 제 3자 서비스 별로 별도의 메시지 큐를 사용하여 하나의 서비스에서 장애가 발생해도 다른 알림은 정상 동작
• 작업 서버에서 메시지 큐에서 전송할 알림을 꺼내서 제 3자 서비스로 전달

상세 설계

• 안정성
  • 데이터 손실 방지: 알림이 지연되거나 순서가 바뀌는 것은 괜찮지만 소실되면 안됨
    → 알림 시스템은 알림 데이터를 DB에 보관하고, 재시도 메커니즘을 구현해야 함
• 알림 템플릿
• 알림 설정
• 전송률 제한: 너무 많은 알림을 보내지 않도록 하기위해 필요
• 재시도 방법: 제 3자 서비스가 알림 전송 실패 시 해당 알림을 재시도 전용 큐에 넣고, 같은 문제가 계속 발생하면 개발자에게 통지
• 큐 모니터링: 큐에 쌓인 알림의 개수가 너무 많으면 작업 서버들이 이벤트를 빠르게 처리하지 못하고 있다는 것 → 작업 서버 증설

최종 설계