SLASH 21 - 토스 서비스를 구성하는 서버 기술

트래픽 전환 지점의 트레이드오프부터 짚는다. L7에서 트래픽을 틀면 모든 트래픽이 한 번에 옮겨져 대부분 L7을 쓰고, 라우터단은 변경이 다른 라우터로 전파된 뒤 반영돼 시간이 오래 걸린다. 2019년 중순 DC/OS에서 쿠버네티스로 이동한 배경은, DC/OS의 카나리 배포 도구가 서비스 디스커버리에 한계가 있었기 때문이다. 한 번에 마이그레이션하면 롤백이 불가능하므로 DC2에 먼저 쿠버네티스를 도입하고 DC1은 DC/OS와 병행하다 일부 노드를 빼며 조금씩 옮기고 검증한 뒤 전환했다.

함께 도입한 Istio(서비스 메시)는 MSA로 가며 서버 간 네트워크 처리(서킷 브레이커·리트라이·폴백)를 애플리케이션에서 하던 것을, 프록시를 사이드카로 붙여 언어와 무관하게 인프라 차원에서 해결하는 점, 그리고 MSA의 많은 내부 요청을 중앙 집중이 아닌 클라이언트 사이드에서 처리하는 점이 매력적이었다. Istio 프록시는 Envoy를 래핑해 풍부한 통계를 제공하므로, 보내는 쪽과 받는 쪽 통계를 합쳐 보면 문제 지점을 쉽게 파악할 수 있어 과거 양쪽에서 패킷 덤프를 떠 분석하던 일을 대신해 주고 서비스 전체의 관측성(observability)이 높아졌다. 다만 네트워크 처리를 모두 인프라로 넘기진 못했다. 서킷 브레이커는 outlier 기반이라 세부 조정이 어렵고, 리트라이도 API의 트랜잭션 방식·응답 값에 따라 달리해야 해 세부 설정이 부족하므로 이런 부분은 여전히 애플리케이션에서 처리한다. 대신 서비스별 권한 적용, Envoy 필터로 애플리케이션 변경 없이 동적으로 헤더 처리·접근 제어를 더하는 데 활용한다. 카나리 측면에서도 인스턴스 단위는 1% 카나리에 인스턴스 100개가 필요하지만 Istio는 라우트 weight로 인스턴스 수와 무관하게 1% 배포가 가능하고, 특정 요청을 실패·지연시켜 실패 처리를 검증하는 폴트 인젝션 테스트, 한 인스턴스에 부하를 주는 스퀴즈 테스트도 가능하다.

스퀴즈 테스트는 라이브에서 진행하므로 절대 성능보다 어느 정도 요청부터 부하를 느끼는지 파악하고, 배포 전후 지표를 비교해 성능 하락을 확인하는 데 쓴다. API 게이트웨이로는 Zuul·Kong·스프링 클라우드 게이트웨이를 검토한 끝에, Reactor 운영 자신감과 검증된 성능 때문에 스프링 클라우드 게이트웨이를 골랐다. 커스텀 필터로 인증 등을 구현하고, 라우팅은 검증 프로세스가 아직 없어 대부분 static으로 추가하며, 내부는 리액터지만 유지보수 편의를 위해 코루틴을 쓴다. 게이트웨이는 처음엔 하나였다가 클라이언트별 처리가 늘며 무거워져 분리했고, 각 팀의 API를 플랫폼 팀이 승인하는 구조로 관리하며 공통 로직은 Zuul에서 처리한다. 데이터를 모아 보여 주는 I/O 많은 프로젝트는 WebFlux를 쓰고, R2DBC 지원이 좋아지며 WebFlux로 시작하는 프로젝트가 늘었다. 리액터는 오퍼레이터로 컨트롤 플로우를 짜야 해 러닝 커브가 높았는데, 코루틴을 도입해 다이렉트 스타일로 개발할 수 있게 되며 줄었다.

모니터링은 오픈소스를 많이 쓴다. Filebeat로 로그를 Kafka에 보내 Kibana에서 검색하고, 로그에 컨테이너 ID·서비스 ID·배포 ID·리퀘스트 ID·핀포인트 ID를 함께 쌓아 어느 데이터센터·서비스·배포 버전에서 난 문제인지 추적하며, 에러가 신규 배포에만 나면 즉시 롤백한다. APM은 핀포인트, 메트릭은 Prometheus에 장기 보관·HA를 위한 Thanos, 시각화는 Grafana를 쓰고, ES는 데이터센터당 약 50대씩 운영하며 하루 약 15TB 로그가 쌓인다. 알림은 Sentry와 ES 로그 기반 프로젝트, Grafana 알림을 조합해 Slack으로 보낸다. Kafka는 한 데이터센터 장애가 번지지 않도록 두 개의 클러스터로 운영하되, 컨슈머가 다른 데이터센터로 넘어갈 때 오프셋이 달라지는 문제를 막으려 두 Kafka의 오프셋을 싱크하는 애플리케이션을 자체 개발했고, 리트라이·데드레터 토픽을 스프링 카프카로 래핑했다. DB와 Kafka에 걸친 트랜잭션 문제는 아웃박스(Outbox) 패턴으로 대응한다. Redis는 보존이 필요 없는 단발성 데이터와 캐시에 쓰는데, 데이터센터가 둘이라 스플릿 브레인 가능성이 있어 세 번째 센터를 준비 중이며, 현재 마스터 3·슬레이브 3씩 12대 구성을 세 번째 센터가 생기면 9대로 바꿔 RedLock을 적용할 계획이다. 신기술을 무조건 도입하기보다 명확한 문제 정의 후 도입을 결정한다는 메시지로 발표를 맺는다.