SLASH 23 - 연결되면 비로소 보이는 것들

토스·토스 SLASH 23 2023·2023년

AI 요약

APM 핀포인트와 코틀린 코루틴을 함께 쓰면 분산 추적이 끊기는 문제를, 코루틴 내부 동작을 파헤쳐 직접 추적 플러그인을 만들어 해결한 토스의 SLASH 23 발표다. 코루틴의 컴파일 변형 원리부터 실제 성능 개선 성과까지 이어진다.

핵심 포인트

코루틴은 suspend 메소드를 Continuation·label 기반 스테이트 머신(CPS)으로 변형하므로 기존 추적 방식이 통하지 않음
추적의 세 지점(시발점=디스패처 dispatch, 활성화=resumeWith, 연결 매개체=코루틴 컨텍스트)을 찾아 핀포인트 코루틴 플러그인을 구현
추적으로 한 요청에서 파생된 328개 내부 요청을 발견·정리해 특정 API 응답 50%↑, 서비스 간 요청량 최대 90%↓ 개선

왜 읽나코루틴 기반 비동기 서버의 옵저버빌리티가 필요하거나, 코루틴 컴파일 동작과 APM 내부를 깊이 이해하려는 JVM/코틀린 개발자에게 알맞다.

챕터별 상세

010:00 – 2:24

핀포인트와 코루틴 — 끊긴 추적이라는 문제

토스 서버플랫폼 팀 구태진이 옵저빌리티(observability)를 확보한 노력과 그것으로 서비스를 개선한 사례를 발표한다. 토스는 네이버가 만든 오픈소스 APM 핀포인트(Pinpoint)를 쓰는데, 분산 추적에 강점이 있어 한 유저 요청에서 파생되는 모든 내부 요청을 한눈에 보고 어느 서비스가 느린지·문제인지 확인할 수 있다.

한편 토스는 서버 리소스를 최대한 활용하려 주로 비동기로 개발하며, 비동기 코드를 손쉽게 짜기 위해 코틀린의 코루틴(coroutine)을 주로 쓴다. 그런데 핀포인트와 코루틴을 함께 쓰면 모든 요청이 연결이 끊긴 채로 보여 기능 활용에 제한이 생긴다. 핀포인트가 코루틴 프레임워크를 지원하지 않기 때문이다. 옵저빌리티를 위해 핀포인트가, 리소스 활용을 위해 코루틴이 모두 필요하므로 직접 코루틴 플러그인을 만들기로 한다.

플러그인을 만들려면 대상 프레임워크의 특징을 알아야 한다. 먼저 더 단순한 비동기 라이브러리 AsyncRestTemplate으로 핀포인트의 비동기 추적 원리를 본다. executeAsync 메소드가 시발점이 되어 트레이스 컨텍스트를 생성해 연결 매개체에 저장하고, 스레드가 바뀐 곳에서 ListenableFuture의 set 메소드로 결과를 저장할 때 컨텍스트를 가져와 기록한다. 시발점과 의미 있는 동작 메소드의 공통점은 직간접적으로 ListenableFuture를 가진다는 것이고, 이를 컨텍스트를 옮기는 연결 매개체로 삼는다.

이 패턴을 코루틴에 적용하려면 코루틴이 동기 코드를 어떻게 변형하는지 이해해야 한다. 동기 메소드를 비동기로 바꾸려면 호출 지점은 코루틴 빌더로 감싸고 정의 지점은 suspend 키워드를 붙이면 되는데, 코틀린 컴파일러가 suspend 메소드를 다른 형태로 변형하기 때문이다. MBTI 콘텐츠 예제를 suspend로 변형한 디컴파일 결과를 보면 첫 부분에서 Continuation을 재정의하고 invokeSuspend가 구현되며, 그 뒤 label 값에 따라 실행 동작이 나뉘는 switch문이 등장한다. label 0은 유저 조회, 1은 MBTI 조회처럼 하나의 메소드 안에서 label에 따라 실제 동작이 분기되고, 재정의된 Continuation 객체가 실행에 필요한 변수를 선언·제공한다.

변형된 메소드 때문에 호출 방법도 바뀐다. 한 번 호출에 네 동작이 실행되던 것이, 이제 label을 바꾸며 네 번 호출하는 형태가 됐다. 각 분기가 다음 label을 미리 지정하므로 메소드를 호출하는 것만으로 기존과 같은 결과를 얻는다. 재정의된 Continuation이 label로 실행 상태를, 다른 변수가 필요한 값을 제공해 나뉜 로직에 영속성을 부여하는데, 코루틴은 이를 CPS(Continuation Passing Style)라 부르고 label에 따라 호출 메소드가 바뀌는 패턴을 스테이트 머신 패턴이라 한다.

Continuation의 resumeWith에서 invokeSuspend가 실행되며, COROUTINE_SUSPENDED를 반환하면 즉시 종료해 새 suspend 메소드가 실행됐음을 의미한다. 호출 지점에서는 launch·async·withContext 같은 코루틴 빌더가 코루틴 객체를 생성·실행하며, intercepted 메소드에서 Continuation을 DispatchedContinuation으로 감싸 디스패처의 dispatch로 지정된 스레드에 전달한다. 분석을 정리하면 트레이스 컨텍스트를 생성할 시발점은 디스패처의 dispatch, 비동기 스레드에서 활성화하는 지점은 Continuation의 resumeWith, 연결 매개체는 Continuation의 유일한 프로퍼티인 코루틴 컨텍스트다(고유한 Job을 더해 유일한 값이 되고 구조적 동시성을 지원한다). 이 세 지점으로 플러그인을 만들어 적용하니 정상 추적됐다.

추적이 가능해진 뒤 한 유저 요청을 보다가 캐시·DB 조회를 제외하고도 내부 요청이 328번이나 파생된 것을 발견했다. 모든 요청이 의미 있는지 따져보려고 핀포인트의 저장소인 HBase를 활용했다. HBase는 HDFS 위의 분산 컬럼 기반 키-값 DB로, ApplicationTraceIndex 테이블의 로우키가 애플리케이션 이름과 요청 발생 시간 조합이라 이름과 시간 범위만으로 수십만 건을 수초 만에 가져온다. 트랜잭션 아이디는 최초 요청을 받은 API 게이트웨이가 생성해 파생 요청에 전달되므로, 이를 기준으로 분류하면 동일 HTTP API의 호출 발생 여부와 양을 파악할 수 있다.

이를 통해 불필요한 요청을 많이 찾아냈고, 한 서비스 내부의 불필요한 요청은 코드 변경으로, 분산 환경에서 나뉘어 발생하는 것은 API 게이트웨이의 인터널 헤더 릴레이로 제거했다. 결과는 분명했다. 앱이 직접 호출하는 특정 API 응답 시간이 50% 이상 개선됐고, 서비스 간 요청량은 90% 이상 줄어드는 경우도 있었다. 연결되지 않던 곳을 하나의 점으로 전부 연결해 유저에게 시간을 돌려주고, 서버 리소스를 줄여 안정성을 강화하는 가치를 만들어냈다.