Puppeteer 최적화 작업 기록 (feat. Browserless)

최근 회사에서 온 힘을 쏟고있는 프로젝트의 최적화 작업을 맡게 되었었다.

임무는 다음과같았다.

• puppeteer를 통해 이루어지는 작업이 있는데, 최대한 빨라야한다.
• 서버가 계속적으로 중단 및 재시작 되는 이슈를 잡아야한다.
  우리회사는 독특하게 이미지를 생성하기위해 puppeteer를 사용한다. 이는 자동화 이미지 생성을 위해 새로운 개발자를 채용하기 보다, 기존 인력에서 html+css와 js를 추가 활용하여 적합한 이미지를 생성하기 위함이다.

나는 곧바로 문제 분석에 들어가게 되었고, 가장 직관적으로 문제를 확인할 수 있는 코드 분석 부터 진행 해 보기로 했다. 그리고 파악한 상황은 아래와 같았다.

• 이미지 작업을 위해 puppeteer를 사용한다.
• 각 이미지 작업은 수없이 많은 js코드를 실행 해야 하는 cpu intensive 한 작업들이다.
• puppeteer에서 browser instance 한개를 받고, 거기에서 동시에의 page를 생성하여 8개씩 작업했다.
• 그렇게 돌아가는 browser가 동시에 4개였다.
  여기에서 문제를 찾아낼 수 있었다.
  동시에 작업이 돌아가는 것이 32개의 페이지이다.(8개의 페이지를 가진 브라우저 4개)

여기에서 이것이 궁금했다.

• 브라우저 안에는 페이지들이 있을것이고 이는 싱글쓰레드일까 멀티쓰레드일까?
  • 싱글쓰레드일 경우에는 여러개의 페이지를 한번에 동작시켰을 때 1개씩만 진행이 되던지, Node처럼 논블로킹으로 하나씩 순차적으로 작업하는 방식 일 것이다.
  • 멀티쓰레드일 경우에는 여러개의 코어를 활용할 수 있을 것이다.

ChatGPT에 따르면 페이지(탭)들은 별도의 개별 프로세스로 될 수 있다고 한다.
그래서 내 맥북에서 활성상태보기를 통해 확인을 해보았다.

활성상태보기에는 한개의 Google Chrome 프로세스가 있고, Google Chrome Helper 프로세스가 여러개가 있다.

ps aux | grep '/Applications/Google Chrome.app'

위 명령어를 통해 확인 해 본 결과에도 동일했다.

마찬가지로 한개의 Google Chrome 프로세스가 있고, Google Chrome Helper 프로세스가 여러개가 보여졌다.
Google Chrome과 Google Chrome Helper의 차이를 ChatGPT에 물어보았다.

 

따라서 Chrome에 한개의 탭이 응답없음 되어도 다른탭에 영향을 주지 않는경우는 렌더러 프로세스가 응답중지 된 것 이라고 이해하면 될 것 같다.

아무튼 다시 작업 내용으로 돌아와서, 결론은 아래와 같다.

1. 브라우저는 별도의 프로세스이다.
2. 개별 탭들은 별도의 렌더러 프로세스에 의해 실제 JS들이 작동한다. 따라서 브라우저를 분리하여 개별 탭을 구성하던, 한개의 브라우저가 여러개의 탭을 가지고있던 큰 차이가 없다.

나는 속도가 중요한 현재 기존 코드를 크게 수정하지 않으면서 1개의 유저가 모든 서버 리소스를 차지할 수 있는 상황을 기피할 수 있는 방법을 찾아보았다.
Browserless라는 puppeteer를 운영하는 툴이 있는데, 동시에 브라우저 생성량 제한을 할 수 있는 툴이 있다. 게다가 대기열의 기능도 지원한다.
최대 브라우저 개수를 서버 코어수에 맞게 설정하여 유휴프로세스의 양을 조절한다면, 작동 속도를 향상 시키고 cpu를 조금 더 한개의 작업에 집중하게 할 수 있을것이라 생각했다.

나의 계획은 이렇게 되었다.
기존 동시에 작업이 돌아가는 것이 32개의 페이지이다.(8개의 페이지를 가진 브라우저 4개) 를 내가 컨트롤 해 주고 싶었다.
안정성을 높이기 위하여, 개별 이미지 작업들을 잘게 분리하고, BullMQ를 사용하여 브라우저 및 탭의 개수를 제한, 그리고 다른 서버에서 작업도 가능할 수 있도록 확장가능성도 열어두었다.

이렇게 되면 작업 속도가 떨어질 수 도 있다고 생각한다. 하지만, 여러가지의 이점이 생긴다.

• 최대 Browser개수를 제한하게 되었으므로, 여러명의 유저가 요청을 한다고 해도 서버가 터지는 이슈를 막을 수 있어 안정적인 서비스 운영이 가능했다.
• 기존에는 Node CPU가 항상 100%였으며, 빠르게 작동해야하는데 다른 작업들 때문에 오래걸리는 이유로 설정되어있던 Timeout이 줄곧 발생했었는데, 이제는 개별 작업들의 속도가 개선되어 에러율이 크게 감소했다.
• 그렇게 오래걸리지 않는다. 결국에는 모든 코어를 효율적 그리고 집중적으로 사용하게 되는 것 이므로 전체적인 속도에서 큰 문제가 되지 않는다.

이 수정으로, 서버 안정성 및 에러율에 큰 개선이 있었다.
서버가 리소스 부족으로 다운되는 일은 다시는 없었고, 에러율 또한 기존 약 50%에서 1% 내외로 크게 감소하게 되었다.

하지만 여전히 속도에 개선이 이루어지지 않았다. 아니 사실은 오히려 더 느려졌다.
기존에는 100개의 작업이 있으면, 동시에 32개의 작업이 들어가고 그중 16개는 실패하고 16개만 성공했다. 이렇게 세번의 사이클을 돌면 사실상 종료되기 때문에 결과 자체만큼은 빠르게 나왔다. 하지만 수정 이후에는 동시 작업수에 제한이 있기 때문에 전체 결과만 따져보자면 오래걸릴 수 밖에 없는것이다.

안정성을 유지하며 속도를 개선하기 위해 서버 확장을 고려 해 보게 되었다.
현회사는 AWS 주력으로 사용하기 때문에 EC2 인스턴스를 증설 해야 하는데, 이는 비용 부담으로 다가왔다.

나는 AWS EC2의 장단점을 고려했을 때 Puppeteer 및 Browserless를 위한 CPU Intensive 한 작업을 굳이 비싼 서버인 EC2에서 운영 할 필요가 없다고 생각했다.
왜냐하면 EC2는 쉽게 증설 및 서버간의 연결이 쉬운 장점대비 인스턴스당 비용이 상당하기 때문이다.

 

단편적으로

	EC2(서울)	Contabo(일본)	Iwinv(서울)
Type	VPS	Dedicated Server	BareMetal Server
Name	m6i.xlarge	AMD RYZEN 12 CORES	RS16TA v1
Spec	4vCPU 16GB	24vCPU(12core) 64GB	16vCPU 64GB
Storage	Not Included	Nvme 1TB	SSD 500GB
Network	Free(내부망)	32TB Free(1Gbps) -> 초과시 100mbps 제한	1.2TB Free -> 초과시 30~70원/GB
Price(USD)	$175.584	$141.94	$95.62
Price(KRW) 1300원 환율	228,259원	184,522원	124,300원

 

심지어 EC2는 Shared CPU일 것이고 Contabo와 Iwinv는 dedicated cpu이다.
훨씬 저렴한 비용에 CPU를 온전히 사용할 수 있고, 훨씬 거대한 용량의 RAM에 여유로운 스토리지까지. 정말 단순 배치작업들을 위한 서버로는 제격이었다.

단순 비용적으로만 생각한다면, Contabo가 제격이지만, Dedicated Server에는 단점이 있다.
실제 서버를 해당 업체에서 구매 후 설치 해 줘야 하기 때문에, 실제 사용까지 영업일 기준 1일~2일 정도 걸렸던 것 같다.

우리가 비싼 비용을 주고 AWS와 같은 클라우드 서비스를 사용하는 이유 중 하나는 빠르고 손쉬운 확장성인데, 이 확장을 할 필요 없을 정도의 거대한 서버를 애초에 운영해버린다면, 이 또한 하나의 서버 문제를 해결하는 방법 일 것이다.

이에 따라 회사에서는 단순 CPU 작업을 위해 Contabo와 Iwinv 테스트를 진행했다.
홈서버를 구축하기위해 수없이 리눅스를 재설치 해 보았던 나는 새로운 서버 세팅에 전혀 문제가 없었다.

Contabo 장단점

장점

• 가성비가 정말 좋다.
• 트래픽이 말만 무제한이 아닌 정말 무제한이다. 32TB 제한이 있지만 넘어가면 100mbps로 속도제한이 걸릴 뿐 추가 과금은 없다.단점
• 셋업에 영업일 기준 1~2일의 시간이 걸린다.
• 가장 가까운 서버 위치가 일본이다.(나쁘지 않다.)
• Contabo측에서 제공하는 Monitoring 혹은 Metric은 전혀 없다. 심지어 사용한 트래픽양도 알 수 없다.
• 일할계산되지않고, 월단위 선불 결제가 들어간다.
• 기본적인 WAF조차 제공 해 주지 않는다.

Iwinv 장단점

장점

• 셋업이 바로 진행된다.(아마도? 테스트는 vps로 진행했다.)
• 비용이 일할계산이 되어 필요할 때에 만 증설 등의 작업이 가능하다.
• 한국서버가 있고 한국 고객센터가 있다. 필요할 경우 전화 및 즉각적인 대응을 받을 수 있다.단점
• Network - 작업 특성상 다운로드가 필요하여 순간 트래픽이 100Mbps도 초과하였다. 하지만 iwinv에는 한국의 네트워크가 비싼 이유로 아래의 제한이 있었다. 전화 상담을 받아보니 이 사용량이면 네트워크의 별도 계약이 필요한 수준이었다. 1Mbps당 7천원 수준이었던 것으로 기억한다.
  
• 트래픽 초과 비용이 꽤나 부담스럽다. 1TB만 초과(2.2TB사용시)하면 약 7만원의 트래픽 비용이 청구된다.
• lg회선을 사용하고 해외 트래픽에 대한 속도가 느리다는 소문이 있는데 믿거나 말거나이다. iwinv 국제망 속도 해명

회사에서는, 이미지 제작 용도의 서버의 목적으로는 Contabo를 사용하기로 결정했다.
이유는 아래와 같다

• 이정도 사이즈의 서버를 2개 가지고 있다면, 당분간은 확장을 할 일이 크게 없을 것이다.
• 네트워크가 실제로 무제한이기 때문에 외부망을 사용해도 문제 없다.
• 작업 진행 속도가 문제이지 Latency에는 상관이 없었기 때문에 일본지역에 서버가 위치해도 큰 문제가 없었다.
• Monitoring의 단점이 있지만, Elastic Search의 MetricBeat로 충분히 확인이 가능했다.

이렇게 서버 분리 테스트를 하며 예상치 못한 데이터를 볼 수 있었다.
contabo에서 테스트 할 때에는 확인할 수 없어 몰랐지만, iwinv에서 테스트를 하는데 네트워크 대역폭을 엄청나게 사용하고 있었다.(이 때는 metricbeat로 metric을 확인하기 이전이였다.)
다운로드를 받아야 할 사항이 거의 없다고 생각했었기 때문에 이 상황은 예상치 못했던 상황이었다.
로직을 디버거와 함께 자세히 들여다보니, 수없이 많은 필요 없는 웹폰트까지 다운로드를 받고있었고, 이것이 엄청난 속도저하와 불필요한 네트워크 소모를 야기하고 있었다.
테스트를 통해 또다른 문제를 해결 해 낼수 있었다.

이렇게 로직 개선 및 최적화 그리고 서버분리까지 작업 후 결과물은 아래와 같다.
비용에서는 월 약 40만원의 지출이 추가되었지만, 서비스 측면에서는 큰 소득이라고 생각된다.

• 에러율은 50%에서 1%내외로 낮아졌다.
• 각 이미지 제작에 소요 되던 시간은 15~16초에서 3~4초정도로 낮아졌다.(75~82% 향상)
• 기존 한번에 4개정도밖에 제작하지못했던 이미지는 이제 한번에 40여개를 동시에 제작한다.
• 수백명의 유저가 한번에 몰리더라도 즉각적이기는 어렵지만, 얼마든지 쉽게 서버 증설할 수 있도록 문서화 및 로직상 준비가 되어있다.