[대규모 시스템 설계 기초2] 3장 구글맵(SSE, ws)

포인트

• 3차원 -> 2차원: 메르카토르 도법의 변형
• 지오코딩: 주소를 위/경도로 변환
• 지오해싱: 2차원의 평면 공간으로 표현된 지리적 위치
• 지도 확대/축소: 사이즈 별로 타일 준비해서 붙여서 보여줌. 완전 줌아웃된 건 지도 한 장으로 가능(이미지)
• 확대 수준이 증가함에 따라 4장씩 사진이 더 필요하다고 하면 0~21확대 수준까지 대략 440PB만큼 필요한데.. 인간이 살지 않는 지구의 90% 지역은 압축을 할 수 있으므로 지도이미지에 대략 50PB가 필요하다. 추가정보까지 하면 약 100PB가 필요하다.
• 경로 안내 알고리즘: 교차로를 노드; 도로는 선. 성능은 그래프의 크기에 민감하기 때문에 세계를 작은 격자로 나누고 각 격자 안의 도로망을 노드와 선으로 구성된 그래프 자료구조로 변환한다. 이 때 각 격자는 routing tile이라고 부른다. 각 타일은 도로로 연결된 다른 타일에 대한 참조를 가지고 있다. 이렇게 타일로 분할해 놓으면 메모리 요구량을 낮출 수 있고 한 번에 처리하는 경로의 양이 줄어 성능이 좋아진다.
• routing tile은 구체성에 따라 상/중/하로 나누어 준비

위치 서비스

• 사용자의 위치를 기록
• 사용자가 주기적으로 위치 정보를 전송
• 해당 데이터 스트림을 활용하여 시스템을 개선, 실시간 교통 모니터링, 새로만들어진 도로, 폐쇄된 도로 탐지 가능
• 위치정보가 실시간에 가까우므로 ETA를 더 정확하게 산출할 수 있고 교통상황에 따라 다른 길을 안내할 수 있다.
• 위치 갱신의 경우 1초마다 서버로 현재 좌표를 보낼수도 있지만 이 요청을 클라이언트에서 모았다가 15초마다 한 번씩 보내 쓰기 QPS를 낮춘다. 몇 초마다 갱신하는지는 사용자의 현재 상태에 따라 달라진다.
• 쓰기에 최적화되고 규모 확장이 용이한 카산드라와 같은 디비가 필요
  • 사용자 위치는 계속 변화하기 때문에 일관성보다는 가용성이 더 중요
  • CAP 정리: 가용성과 분할 내성 두 가지 만족시키도록
• 카프카와 같은 스트림 처리 엔친으로 위치 데이터를 로깅하는 게 좋다
• 프로토콜은 http keep alive로
• 데이터: 유저아이디(파티션 키), 타임스탬프(컬러스터링 키), 위도, 경도, 사용자 모드

지도 표시

• 현재 위치와 인접한 지도 타일을(지오 해싱 기반) url로 준비해 두고 CDN으로 제공
• 맵 타일 인코딩(지오 해싱)이 바뀌거나 할 때를 대비하여
• 위/경도 확대 수준을 던지면(새로운 위치로 이동하거나 확대 수준을 변경하면) 필요한 타일들을 결정하여 타일 url을 생성하는 서비스를 별도로 두어 운영 유연성을 높일 수도 있다. 표시할 1개의 타일과 주변 8개의 타일이 포함된다.
• 최적화 필요 시 벡터 사용; webGL 자바스크립트 사용

경로 안내 서비스

1. 지오코딩 서비스: 주소 -> 위도/경도로 표현
2. 경로 계획 서비스: 최적화 된 경로 제안
3. 최단 경로 서비스: 출발지/목적지 위도/경도받아서 k개의 경로 반환; 교통이나 도로 상황 고려하지 않고 도로 구조에만 의존하여 계산
4. 출발지 타일부터 시작하여 그래프 자료 구조를 탐색해 나가면서 주변 타일을 저장소에서 가져와 연결하여 그래프를 탐색한다.
5. 예상 도착 시간(ETA) 서비스: 위 결과에 대해 각 경로에 대한 소요 시간 추정치를 구한다. 머신러닝 활용하여 현재/과거 이력에 근거하여 예상 도착 시간을 계산한다. 미래 예측에 대한 것은 알고리즘 차원에서 풀어야 한다.
6. 순위 결정 서비스: ETA를 구한 후 사용자가 정의한 필터링 조건(무료도로, 고속도로 제외 등)을 적용, 소요시간 순으로 정렬하여 top k 개를 구한 후 반환
7. 위 서비스들은 카프카 위치 데이터 스트림을 구독하고 있다가 비동기로 데이터를 업데이트하여 그 상태를 항상 최신으로 유지한다.
8. 적응형 ETA 경로 변경: 활성화 사태 유저의 위치 데이터 스트림에서 상황정보를 추출하여 실시간 교통상황에 반영; 이용가능한 경로의 ETA를 주기적으로 재계산하여 더 짧은 ETA를 갖는 경로가 발견되면 알림
9. 전송 프로토콜: 롱폴링, 웹소켓, SSE 가능하나 양방향 통신이 필요한 경우도 있어 웹소켓 사용

---

1. 롱폴링 (Long Polling)

동작 방식

• 요청-응답 사이클:
  1. 클라이언트가 서버에 HTTP 요청을 보냅니다.
  2. 서버는 즉시 응답하지 않고, 새로운 데이터가 발생할 때까지 연결을 열어둡니다.
  3. 데이터가 준비되면 응답을 보내고, 클라이언트는 응답을 수신한 후 즉시 다음 요청을 보내는 식으로 주기적으로 연결을 갱신합니다.

주요 특징

• 비동기/동기 구현 가능:
  • 기본 HTTP 요청-응답 메커니즘을 사용하므로, 서버와 클라이언트 모두 블로킹 I/O 방식으로 구현할 수 있지만, 비동기 방식으로도 구현이 가능합니다.
• 지속 연결 유지:
  • 각 요청이 데이터가 도착할 때까지 장시간 열려 있으므로, 풀이나 스레드가 해당 연결에 묶입니다.
• 단점:
  • 매번 새로운 요청을 보내야 하기 때문에 HTTP 헤더 등 오버헤드가 발생합니다.
  • 많은 클라이언트가 동시에 접속할 경우 서버의 커넥션/스레드 리소스가 빠르게 소진될 수 있습니다.

사용 사례

• 간단한 실시간 알림이나 업데이트가 필요한 경우
• 서버에서 데이터가 불규칙하게 발생할 때

2. 웹소켓 (WebSocket)

동작 방식

• 초기 핸드셰이크:
  • 클라이언트가 HTTP 업그레이드 요청을 보내고, 서버가 이를 승인하면 HTTP 연결이 웹소켓 프로토콜로 전환됩니다. ws://
• 전이중 통신:
  • 연결이 성립된 후, 클라이언트와 서버는 서로 자유롭게 데이터를 주고받을 수 있습니다.
  • 한 번 연결이 만들어지면, 양방향 통신을 위해 지속적으로 연결을 유지합니다.

주요 특징

• 양방향 통신(Full-Duplex):
  • 클라이언트와 서버 모두 언제든지 데이터를 전송할 수 있어 채팅, 실시간 게임, 협업 도구 등에 적합합니다.
• 낮은 오버헤드:
  • 초기 연결 설정 후에는 별도의 HTTP 요청/응답 없이 데이터 프레임만 주고받으므로, 반복적인 헤더 전송이 없습니다.
• 리소스 관리:
  • 비동기 I/O (예: Netty, Undertow 등)를 사용하면, 한정된 스레드로도 많은 연결을 효과적으로 처리할 수 있습니다.
• 단점:
  • 서버와 클라이언트 모두 웹소켓 프로토콜을 지원해야 하며, 방화벽이나 프록시 환경에서 제약이 있을 수 있습니다.
  • 초기 설정이 다소 복잡할 수 있습니다.

사용 사례

• 실시간 채팅, 게임, 협업 툴 등 양방향 데이터 교환이 필요한 애플리케이션

3. 서버 전송 이벤트 (SSE, Server-Sent Events)

동작 방식

• 단방향 스트리밍:
  • 클라이언트가 HTTP 요청을 보내고, 서버는 해당 연결을 통해 이벤트(텍스트 기반 데이터)를 지속적으로 스트리밍합니다.
  • 연결은 단방향으로 유지되며, 서버 → 클라이언트로 데이터만 전송합니다.
  • Last-Event-ID 헤더와 id 필드를 활용하여 중단된 연결 복구가 가능합니다.
  • SSE는 텍스트 기반 프로토콜이므로 이진 데이터 전송이 필요한 경우 Base64로 인코딩하거나 WebSocket 사용을 고려해야 합니다.
• 자동 재연결:
  • 연결이 끊어질 경우 클라이언트 측에서 자동으로 재연결을 시도하는 기능이 내장되어 있습니다.

주요 특징

• 단방향 통신:
  • 클라이언트에서 서버로 데이터를 보내려면 별도의 요청(예: AJAX)이 필요합니다.
• 구현 단순성:
  • HTTP 기반이므로 기존 인프라와 호환성이 좋고 구현이 비교적 간단합니다.
• 리소스 효율성:
  • 비동기 HTTP 클라이언트(예: Spring WebFlux의 WebClient, EventSource 등)를 사용하면 많은 연결을 효율적으로 관리할 수 있습니다.
• 단점:
  • 양방향 통신이 불가능하므로, 서버에서 클라이언트로만 데이터를 보내야 하는 경우에 한정됩니다.
  • 일부 브라우저(특히 오래된 버전)에서 지원이 제한적일 수 있습니다.

사용 사례

• 실시간 뉴스 업데이트, 주식 가격 모니터링, 알림 시스템 등 서버 → 클라이언트 단방향 데이터 스트리밍