warm up

개요

성능이 중요한 서비스라면 배포 후 서비스로 트래픽을 받기 전에 웜업 과정을 거치는 것이 필수적이다.

애플리케이션 배포 직후에는 다양한 자원들이 초기화되지 않은 상태이므로, 웜업 없이 즉시 트래픽을 받게 되면 성능 저하나 서비스 중단으로도 이어질 수 있다.

웜업은 특히 레이턴시(Latency)가 짧고 스루풋(Throughput)이 높은 성능 중심의 서비스에서 반드시 고려되어야 한다.

애플리케이션 배포 웜업을 하지 않으면 다음과 같은 성능 저하가 발생할 수 있다.

캐시(Cache) 미스 및 원본 저장소 부하

@Cacheable("items")
public Item getItem(String id) {
	return repository.findById(id);
}

스프링부트 애플리케이션을 예시로, Cacheable 어노테이션을 사용해서 자주 조회되는 데이터를 캐싱하곤 한다. 캐시를 이용하면 원본 저장소에서 데이터를 조회하지 않고 빠르게 응답할 수 있다.

문제:

• 웜업 없이 트래픽을 받으면 초기 요청들이 모두 캐시 미스로 이어져 원본 DB에서 직접 데이터를 조회하게 된다.

성능 저하:

• DB에 불필요한 부하가 몰리게된다.

• 요청에 대한 응답 레이턴시가 증가하게 되고, 시스템 전체의 스루풋이 저하될 수 있다.

웜업 역할:

• 웜업을 통해 미리 캐시를 채워두면(Pre-warming), 초기 요청들이 캐시에서 빠르게 처리되어 원본 저장소의 부하를 줄이고 응답 속도 향상이 가능해진다.

• 이를 통해 낮아진 레이턴시 만큼 남는 자원으로 스루풋을 키울 수 있다.

커넥션 풀(Connection Pool) 고갈 및 DB 부하

스프링부트 애플리케이션은 보통 Hikari CP같은 커넥션 풀을 사용한다.

커넥션 풀은 DB 커넥션들을 효율적으로 관리해서 애플리케이션 성능을 크게 향상시키는 데 도움을 준다. 이 역시 웜업을 진행하지 않으면 새로운 인스턴스들이 동시에 DB 연결을 요청하게 되고, 연결 풀이 순식간에 고갈될 수 있다.

문제:

• 웜업 없이 새로운 인스턴스가 트래픽을 받게 되면, 동시에 많은 DB 연결 요청이 발생하여 커넥션 풀이 순식간에 고갈될 수 있다.

• 설정에 따라서 커넥션 풀의 커넥션 숫자 자체가 DB쪽에 연결할 수 있는 것보다 많게 되면 커넥션을 생성 못하는 경우도 발생할 수 있다.

성능 저하:

• 커넥션 풀이 고갈되면 애플리케이션은 DB 연결을 확보하지 못한다.

• 이로 인해, 요청 처리가 지연되거나 실패할 가능성이 커진다.

• DB 서버에도 갑작스러운 부하를 유발할 수 있다.

웜업 역할:

• 애플리케이션 시작 시 커넥션 풀의 연결 수를 점진적으로 늘려주고, DB 연결에 대한 부하를 분산시켜 안정적인 서비스 시작이 가능하게 한다.

특히 블루-그린 배포 같은 경우에도 기존에 떠 있던 서버들 역시도 커넥션 풀을 가지고 커넥션을 맺고 있기 때문에 마찬가지로 고려해야 할 부분이다.

연결된 외부 서비스 과부화

현대 애플리케이션들은 대부분 다양한 외부 서비스 혹은 API와 연동이 되어있다.

결제 시스템, 인증 시스템, 데이터 분석 도구와 같이 여러 외부 서비스들이 애플리케이션에서 중요한 역할을 차지하고 있다.

문제:

• 외부 서비스 호출을 고려하지 않으면, 배포된 여러 인스턴스가 동시에 외부 API를 호출하여 해당 외부 서비스에 갑작스러운 과부하를 유발할 수 있다.

성능 저하:

• 외부 서비스의 부하 증가는 응답 지연이나 오류로 이어져 애플리케이션 기능에 영향을 줄 수 있으며, 전체 서비스의 성능 저하로도 이어질 수 있다.

웜업 역할:

• 일부 인스턴스부터 서서히 점진적인 웜업을 통해 외부 서비스에 대한 부하를 분산시킨다.

• 방법으로는, 서킷 브레이커 패턴을 도입하여 외부 서비스 장애가 애플리케이션 전체로 전파되는 것을 방지할 수 있다.

JIT 컴파일러

Java에서는 JIT 컴파일러를 사용한다. 이는 자바 애플리케이션이 실행되는 동안에 자바 바이트코드를 기계어로 변환하는 책임을 갖는다.

컴파일러는 프로세스 실행 중 자주 사용되는 코드를 식별하고 최적화해서 전반적인 실행 성능을 향상시킨다.

문제:

• 애플리케이션이 처음 실행될 때, JIT 컴파일러가 아직 최적화를 진행하기 전이므로, 상대적으로 느리게 동작한다.

성능 저하:

• 웜업 없이 초기 트래픽을 받으면, 최적화되지 않은 코드가 실행되어 응답 시간이 길어지고 처리량이 낮아질 수 있다.

웜업 역할:

• 웜업 과정에서 애플리케이션 코드를 미리 실행시켜 JIT 컴파일러가 코드를 최적화 하도록 한다.

  • 한 번 실행된 코드는 더 빠르게 실행되는 이점을 얻는다.

  • 이미 한번 실행된 코드들은 JIT 컴파일러에 의해 어딘가에 캐시로 저장된다.

• 트래픽이 본격적으로 유입될 때 더 높은 성능으로 서비스를 제공할 수 있다.

추천하는 웜업 방법

웜업을 효과적으로 수행하기 위해서는 실제 운영환경과 최대한 유사한 조건을 만드는 게 중요하다.

이렇게 하기 위해서 가장 추천하는 방법은 애플리케이션이 실제로 받는 트래픽과 유사한 형태와 양으로 점진적으로 부하를 늘려나가는 웜업 스크립트를 작성하는 것이다.

기술적으로 어려운 서비스들도 존재한다. 실제 동작을 수행하는 게 사이드 이펙트가 존재한다면 진행하기 어려울 수 있다. (ex: 결제)

• 결제 API를 제공해주는 곳에서 테스트 API를 제공해 줄 수 있지만, 실제와 동일하다고는 이야기할 수 없다.

점진적 부하 증가 스크립트 작성

애플리케이션이 실제로 받는 트래픽과 유사한 형태와 양으로 점진적으로 부하를 늘려나가는 웜업 스크립트를 작성하는 것이 가장 이상적이다.

• 애플리케이션 개발 단계부터 웜업/테스트 모드를 고려하여 사이드 이펙트 없이 핵심 로직을 테스트 할 수 있도록 설계하는 것도 중요하다.

• 단순히 GET 요청으로만 웜업하는 것이 아니라, POST, PUT 등 실제 사용자가 발생시키는 데이터 패턴을 따르는 것이 중요하다.

따라서 최대한 실제 애플리케이션이 받는 동작과 유사하게 API를 테스트할 수 있도록 만드는것이 좋다. 이는 애플리케이션 개발 과정에서 고려되면 좋다.

블루-그린 배포:

• 그린 환경이 준비되면, 실제 트래픽을 전환하기 전에 성능 테스트용 부하 발생 서버나 스크립트를 이용하여 그린 환경에 미리 실제 트래픽에 가까운 부하를 주어 웜업을 진행한다.

• 웜업이 완료되면 트래픽을 전환하여 웜업된 상태로 서비스를 시작한다.

롤링 배포:

• 각 서버가 새 버전으로 전환될 때마다 해당 서버에 대해 개별적으로 웜업 프로세스를 적용한다.

• 웜업이 완료되면 트래픽을 받을 수 있도록 설정한다.

배포 전략과의 연계(ex: 블루-그린에서의 웜업)

블루-그린 배포:

• 그린 환경이 준비되면, 실제 트래픽을 전환하기 전에 성능 테스트용 부하 발생 서버나 스크립트를 이용하여 그린 환경에 미리 실제 트래픽에 가까운 부하를 주어 웜업을 진행한다.

• 웜업이 완료되면 트래픽을 전환하여 웜업된 상태로 서비스를 시작한다.

롤링 배포:

• 각 서버가 새 버전으로 전환될 때마다 해당 서버에 대해 개별적으로 웜업 프로세스를 적용한다.

• 웜업이 완료되면 트래픽을 받을 수 있도록 설정한다.

블루-그린이 아니더라도 롤링 배포에서도 동일하게 배포 대상인 서버들은 모두 웜업이 되지 않은 상태이기 때문에, 실제 트래픽으로 부하를 줘서 웜업을 시키고 트래픽을 전환하여 트래픽을 받을 수 있는 상태로 만드는 게 중요하다.