매스프레소 팀블로그 - Medium

image / pdf 를 만드는 과정
콴다에서는 수억 개의 질문(Question) & 답변(Answer) 데이터 이외에도 학생들에게 양질의 콘텐츠를 제공하기 위한 수십만 개의 문제 / 해설 데이터를 보유하고 있습니다. 이 데이터는 콴다 내의 여러 서비스들을 사용하는 사용자들에게 양질의 문제 / 해설을 제공하는 데 사용됩니다.
PDF, Image, 텍스트 등 어떤 형태로든 데이터를 수급받으면 이를 구조화된 객체(타이핑된 형태라는 의미로 이를 TypedFormat이라고 부르고 있습니다)의 형태로 Stringify하여 저장하고 있기 때문에, 실제로 사용자에게 이를 제공하기 위해서는 이를 다시 객체화 하여 사용자의 유즈케이스에 따라 사용자의 기기에 가장 적합한 형태 (image, pdf)로 변환하는 과정이 필요합니다. 콴다에서는 이 변환 과정을 Typed Format Renderer(이하 Renderer)라는 서비스를 만들어 처리하고 있습니다.
이번 글에서는 이 Renderer 서비스가 적게는 수천 개에서, 많게는 수만 개의 image / pdf 생성 요청을 감당하기 위해서 어떤 기술적인 고민을 거쳐왔는지를 살펴보고자 합니다.
Background
앞선 Overview에서 간략하게 설명했듯, Renderer는 문제나 해설에 대한 데이터와 메타데이터를 담고 있는 Stringify된 객체(TypedFormat) 스트링, 혹은 이들의 배열을 받아서 Image나 PDF를 렌더하는 Stateless Server 입니다.
수급된 콘텐츠의 품질을 유지하기 위한 검수 과정까지 마치게 되면, 해당 데이터들을 콴다의 모든 콘텐츠가 저장되는 “ContentHub” 라는 서버에 Publish 하게 됩니다. 이때 이 ContentHub는 Publish된 데이터들을 가지고 Renderer를 호출해서 수천, 수만 건의 Image와 PDF를 생성합니다.
서비스의 특성상, 지속적으로 특정 규모의 트래픽이 유입되는 것이 아니라 시험 기간과 같은 특정한 이벤트가 있을 때 비동기적으로 대량의 트래픽이 유입되기 때문에 평상시에는 최소 개수의 Instance 만을 유지하다가 갑자기 트래픽이 유입 되었을 때 이 요청들을 Drop하지 않고 안정적으로 서비스할 수 있는 구조를 고민하는 것이 중요했습니다.
또한 Renderer가 동작하는 방식으로 인해 하나의 요청을 처리하는데 걸리는 시간이 적게는 2~4초, 문제집 형태의 PDF의 경우 40~50초 가까이 걸리기도 하기 때문에, “처리하는데 오랜 시간이 걸리는 수천~수만 개의 요청을 안정적으로 서비스 하기 위한” 고민해야 했습니다.
How Renderer Works (Before)
기존의 Renderer는 NodeJS 런타임에서 Headless Browser(Puppeteer)를 사용해 콘텐츠를 하나의 Browsing Context에 렌더하고 전처리, 후처리 과정을 거쳐 Image / PDF를 생성한 뒤 이를 Stream의 형태로 반환합니다. 이를 조금 더 자세하게 살펴보면 다음과 같습니다
ContentHub로부터 넘어온 요청에 대한 Validation을 수행한다.
Validated된 객체(TypedFormat)을 화면에 그리기 위해서 서버에 Browser Instance 하나를 요청한다. (아래 그림과 같이 Renderer는 빠른 응답 속도를 위해 N개의 Browser Instance를 미리 만들어 Pool을 사용해서 관리하고 있으며, 요청이 오면 이미 생성된 Browser Instance를 Pool에서 꺼내서 주고, 요청을 다 처리하고 다면 Instance를 다시 초기화한 후 반환합니다.)
Image의 경우 렌더된 영역만큼 Screenshot으로 찍은 뒤 Stream의 형태로 요청한 서버에 반환한다.
PDF의 경우 PDF에 포함될 모든 문제를 일단 화면에 한번 렌더한 후, 렌더된 각 영역의 크기를 계산해서 한 페이지에 얼마만큼의 문제가 들어갈 수 있는지를 구하고, 이를 바탕으로 여러 페이지에 걸친 문제집 형태의 템플릿 안에 문제들을 배치한다. 이후 Stream의 형태로 요청한 서버에 반환한다.
위에서 살펴본 것처럼, Renderer는 기본적으로 여러 개의 Headless Browser Instance를 동작시켜 렌더하는 과정을 거치기 때문에 CPU Heavy한 작업이며, 아래 보이는 것과 같이 하나의 Instance안에 여러 개의 브라우저 프로세스가 동작하기 때문에 적지 않은 리소스를 사용하게 됩니다. 하지만, 이렇게 브라우저를 사용해서 Image / PDF를 생성하기 때문에 프론트엔드 엔지니어분들이 기술적으로 쉽게 Image / PDF의 레이아웃을 수정할 수 있다는 장점도 있습니다.
Renderer는 기존에 Cloud Run이라는 GCP Managed Service를 사용해서 서비스되고 있었습니다. 다른 여러 가지 방법들을 사용해서 배포할 수도 있지만, 처음 Renderer를 배포하는 당시에는 다음과 같은 사항들을 고려하여 Cloud Run을 사용하게 되었습니다.
Cloud Run은 Managed Service이기 때문에 배포 설정이 비교적 간단합니다. Renderer 서버의 컨테이너 이미지만 빌드해서 제공하면 나머지는 Cloud Run 에서 다 관리해준다는 장점이 있습니다.
GCP Console에서 Renderer가 제대로 동작하고 있는지를 알아보기 위한 여러 지표 및 로그들을 기본적으로 제공합니다. 서버로그 뿐 아니라, CPU / Memory / Concurrency / Status등의 여러 유용한 지표들을 별다른 설정 없이 기본적으로 제공되는 콘솔에서 확인할 수 있습니다.
요청이 간헐적으로 들어오는 서비스인만큼, 사용량이 없을 때 0개의 Instance로 운영하는 “Scale To Zero” 전략을 사용할 수 있었습니다.
처음에는 비교적 렌더링 속도가 빠른 이미지와 매우 단순한 형태의 가벼운 PDF를 생성하기 위한 서비스로 시작하였으므로 빠르게 개발 / 배포하여 서비스에 올리는 것이 중요했고, 프론트엔드 엔지니어가 빠르게 설정하여 배포하기에 용이했습니다.
Problems
하지만 이렇게 Render를 Cloud Run에서 서비스하는 기존의 방식에는 몇 가지 문제가 있었습니다.
Cloud Run의 Scale Up이 생각만큼 유연하게 잘 되지 않음:
Cloud Run에서 기본적으로 Scaling 옵션을 지원하긴 하지만, 이것이 갑자기 다량의 트래픽이 몰려드는 상황에서는 의도한 대로 동작하지 않을 때가 많았습니다. 
실제로 Production에서 Min Instance Count를 10으로, Max Instance Count를 150으로 잡아두었지만, 실제 다량의 트래픽(수천 개)이 몰리는 상황에서 40개 정도밖에 Scaling이 되지 않았고, Host Machine의 CPU / Memory 사양을 조절해 보거나, Concurrency를 조절해 보아도 원하는 만큼의 Scalability를 달성할 수 없었습니다.
요청을 처리하는 시간이 너무 오래 걸려서 요청을 보낸 서버도 Connection을 길게 유지하고 있어야 함:
특히 PDF를 생성하는 경우, 문제를 렌더하고 렌더된 크기에 맞게 문제를 재배치하고, 재배치된 문제들을 A4 Page 단위로 나누어 Template을 적용하는데 적지 않은 시간이 소요됩니다. 하나의 서버가 수천 개의 PDF 생성을 요청하는 경우 이 수천 개의 오래걸리는 커넥션들을 유지하고 있어야 하므로 안정적이지 않으며, 모종의 이유로 커넥션이 끊어진 경우 Retry의 책임이 요청하는 서버에 넘어가게 됩니다.
How TF Renderer Works (After)
위에서 제시된 문제를 해결하기 위해서 다음과 같은 변화를 주었습니다.
CloudRun에서 동작하던 Renderer를 Kubernetes Cluster 위에서 동작하도록 변경하였음.
Cloud Pub/Sub을 사용해서 요청을 보낸 서버(ContentHub)와 TF Renderer사이의 결합도를 낮추었음.
이를 통해 변경된 전반적인 구조는 다음과 같습니다.
기존의 Renderer를 tf-renderer-scheduler(이하 scheduler)와 tf-renderer-worker(이하 worker)의 2개로 분리합니다. scheduler는 요청을 받아서 Pub/Sub Topic에 Publish하는 역할을 하고, worker 는 Pub/Sub Topic을 Subscribe해서 요청을 처리하는 역할을 합니다.
ContentHub가 생성해야 하는 Image/ PDF에 대한 요청을 scheduler에게 전달합니다. scheduler는 이 요청에 대해 validation 작업을 수행한 후, 유효하다면 이 메시지를 Pub/Sub에 Publish한 후 ContentHub에 리턴합니다.
만약 scheduler 로 들어온 요청이 유효하지 않은 경우, (e.g callback Uri가 잘못되었다거나, 필수 옵션이 누락되었거나) scheduler는 Pub/Sub에 Publish하지 않고 바로 Error를 리턴합니다. 이렇게 해서 worker가 처리할 수 있는 메시지만 Pub/Sub에 쌓일 수 있도록 합니다.
worker는 Pub/Sub을 Streaming Pull 방식으로 구독하고 있다가 메시지가 넘어오면 이 메시지 안의 데이터를 사용해 Image / PDF를 렌더하고, 이 결과물을 stream으로 받아서 메시지 안에 들어있는 ContentHub의 Object Uri를 사용해서 ContentHub의 Storage에 streaming upload를 수행 합니다.
Upload가 완료되면, 메시지 안에 들어있는 ContentHub의 Callback Uri를 사용해서 요청 처리가 완료되었음을 알려줍니다.
Implementation Detail
Scaling:
Renderer를 Cluster 안으로 옮긴 가장 큰 이유 중 하나는 Instance를 Kubernetes의 관리 아래 두어 조금 더 자유로운 설정들을 제공하기 위해서 입니다. 특히 Cloud Run에서 Kubernetes Cluster로 넘어오면서 worker instance가 뜨는 Pod의 Scaling Metric을 num_undelivered_messages 즉 Message Queue의 잔여 메시지 개수 기준으로 설정할 수 있게 되었는데, 이는 Cloud Run에 비해 조금 더 명시적이고 안정적인 Scaling 처리를 제공합니다. (Cloud Run의 경우 60% 정도의 CPU Target이나 concurrency option을 통해 조절해야 하며, 이외의 옵션은 당시 시점에서는 제공하지 않아서 Scaling Metric을 원하는대로 설정하기 어려웠습니다.)
예를 들어 아래와 같이 Pod의 autoscale 조건을 targetAverageValue: 5 로 설정해 두었다면, Message Queue에 처리되지 않은 메시지가 100개인 경우 20개까지 Scaling이 됩니다.
...
resources:
    requests:
      cpu: 4000m
      memory: 4Gi
    limits:
      cpu: 4500m
      memory: 4Gi
            
    scaling:
      replicas: 1
      autoScaling:
        enabled: true
        minReplicas: 1
        maxReplicas: 50
        cpuTarget: 90
        custom:
          enabled: true
          metrics:
            - type: External
              metricName: pubsub.googleapis.com|subscription|num_undelivered_messages
              targetType: AverageValue
              targetAverageValue: 5
              matchLabels:
...
물론 이렇게 설정한 경우에도 여러개의 인스턴스를 동시에 띄우기 위해서는 약간의 Starting Delay가 필요하지만, Cloud Run과는 다르게 결국 원하는 개수만큼 인스턴스 Scaling이 잘 되며, tf-renderer-worker가 가져갈 수 있는 만큼만 Message Queue로부터 가져가는 구조이기 때문에 요청이 너무 많아서 worker가 처리 불능이 되는 상태를 방지할 수 있습니다.
한 가지 주의할 점은, 서비스 특성상 평소에는 최소한의 Pod 개수만을 유지하다가 트래픽이 몰리는 특정 시점에 수십 개의 Pod가 떠야 하는 구조이므로, 이때 할당되는 리소스 사용량으로 인해, 콴다 서비스 내의 다른 애플리케이션이 영향을 받지 않아야 합니다. 따라서 DevOps Team과 논의하여 같은 클러스터 내에 별도의 Worker Node Pool을 할당해서 다른 애플리케이션들에 영향이 가지 않도록 설정했습니다.
Streaming Pull:
Pub/Sub의 Subscriber가 메시지를 가져오는 2가지 방식 (pull, streaming pull) 중, worker는 Streaming Pull 방식으로 메시지를 가져오도록 구현했습니다. 이때 worker가 한 번에 streaming할 수 있는 최대의 메시지 개수를 의미하는 Max Messages와 관련된 몇 가지 옵션을 worker쪽에서 설정할 수 있는데, 이때 max message count를 하나의 worker에서 띄우는 최대 instance 개수와 동일한 수준으로 맞춰두면, 실제로 message queue에는 수천 개의 message가 쌓이더라도 kubernetes가 worker pod를 스케줄링하는 동안 하나의 Worker에서는 처리할 수 있는 만큼만 처리하게 되므로, 요청이 몰려서 worker가 작업 불능 상태가 되고 Pod가 kill 되는 현상을 막을 수 있었습니다.
const subscription = pubSubClient.subscription(subscriptionName, {
  flowControl: {
    maxMessages: NUM_INSTANCES,
    allowExcessMessages: false,
  },
});
Dead Lettering:
Message Queue에 Scheduler가 감지하지 못한 잘못된 메시지가 Publish된 경우, 그것이 어떤 이유인지를 늘 정확하게 감지하기는 어렵기 때문에 exponential backoff delay를 적용해 최대 5번 정도 retry한 후, 그래도 실패한다면, 이 메시지는 DeadLetter Topic으로 보내도록 설정해 두었습니다. 이때, 명시적으로 로그를 남기고 DeadLetter를 수동으로 처리하게 함으로써, 문제가 될 만한 상황을 최대한 방지하도록 합니다.
Result
이렇게 구조를 변경한 후 1000개의 PDF 생성 요청을 scheduler로 보낸 결과입니다.
PDF 1000개가 모두 잘 생성되어 ContentHub에서 관리하는 GCS(Google Cloud Storage) Bucket에 업로드되었습니다.
Message Queue에 Message가 잘 publish 되었고, Message Queue를 Subscribe하는 worker에 의해 Message가 잘 소비되어 잔여 메시지들(unacked messages)의 수가 잘 줄어드는 것을 확인할 수 있습니다.
Message Queue의 잔여 메시지 수에 기반한 Scaling Metric에 의해 최대 개수(50개)까지 Scale up이 잘 되는 것을 확인할 수 있습니다.
Monitoring & Tuning
이제 Renderer가 의도한 대로 동작하게 되었으므로, 모니터링을 통해 최적의 리소스 할당을 해야 할 것입니다.
주요하게 살펴보았던 지표는 CPU Efficienty와 Memory Efficiency였고, PDF 1000개를 생성하면서 나타나는 정량적인 지표들을 통해 부족하다면 더 할당하고, 여유롭다면 줄이는 식으로 모니터링을 수행했습니다. Cluster 안에 배포했기 때문에, 기존에 콴다 팀이 Grafana를 사용해서 모니터링하던 방식을 그대로 사용할 수 있었습니다.
CPU Target: 
2000m로 요청한 Pod의 리소스(주황색 점선)가 요청을 최대로 처리하고 있을 때 리소스 quota를 넘어가서 CPU Throttling이 발생하고 있었습니다. CPU Throttling이 일어나면 worker가 PDF 를 생성하는 과정 자체가 느려지기 때문에, CPU 리소스를 조금 더 넉넉하게 받는 것이 필요하겠다는 판단을 하고 조금 더 넉넉하게 CPU Target Resource를 요청했습니다.
Memory Target:
부족하면 Throttling을 통해 처리 속도를 늦추는 방식을 사용할 수 있는 CPU와는 다르게, Memory의 경우 K8S 에 요청한 것보다 Application에서 사용하는 메모리의 양이 더 많으면 바로 OOM(Out Of Memory)에러가 나면서 Pod가 죽게 됩니다. 개발 환경에서 부하 테스트를 하다가 OOM 관련 에러가 발생하면서 Pod가 계속해서 재시작하는 현상을 파악한 후, worker 하나에 할당되는 메모리를 기존의 2Gi 보다 넉넉하게 요청했고, 그 결과 CPU / Memory 모두 80% 대의 Utilization을 보이면서 요청을 빠르게 처리할 수 있게 되었습니다.
Conclusion
지금까지 콴다 팀에서 대량의 Image / PDF 생성 요청을 안정적으로 처리하기 위해서 고려했던 여러 가지 사항들에 대해 살펴보았습니다. 문제를 정의하고, 해결해 나가는 과정에서 Renderer라는 하나의 서비스를 제대로 동작하게 하기 위해서 이해해야 할 것이 상당히 많았고, 문제를 해결해 나가는 과정 자체가 재미있었던 것 같습니다.
어쩌다 보니 흔히들 이야기되는 “프론트엔드”에 관련한 내용이 거의 없는 채로 프론트엔드 섹션에 올라갈 글을 쓰게 된 것 같습니다. 하지만 콴다 프론트엔드 챕터에서는 전반적으로 문제를 정의하고 이것을 해결하기 위한 넓은 시야를 갖는 것을 중요하게 생각하고 있고, 이런 시야를 제공할 수 있는 좋은 문제를 발견한다면 이것을 직접 여러 과정을 거쳐 해결하는 것을 권장하고 있습니다.
유저로부터 가장 가까운 지점에서 더 나은 경험을 주기 위해 문제를 정의하고 해결하는 것을 프론트엔드 엔지니어라고 정의한다면, Renderer를 개선하는 이 전반적인 과정 뿐 아니라, 유저의 목소리를 듣는 것도, 더 나은 경험을 제공하기 위해 DevOps Team께 질문하면서 인프라를 개선하는 것도, 모두 프론트엔드 엔지니어가 할 수 있는 일일 것입니다.
🌏글로벌 Top 교육 앱 QANDA(콴다)를 함께 만들어 갈 Frontend 개발자들을 기다리고 있습니다! ➡️ 공고 확인하기
콴다 팀의 Typed Format Renderer 서비스 개발기 was originally published in 콴다 팀블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

콴다 팀의 Typed Format Renderer 서비스 개발기

댓글