이거 어디까지 올라가는 거예요? - 성능 테스트 환경 구축기

Ian
레몬베이스 팀블로그
10 min readMar 29, 2024

--

시작하며

안녕하세요, 레몬베이스 Engineering Group에서 Backend Engineer로 일하고 있는 Ian 입니다. 🍋

레몬베이스 엔지니어들은 고객에게 가치 있는 기능을 제공하는 것뿐 아니라, 더 빠르고 안정적인 서비스 제공을 위해 기술 과제에도 많은 노력을 쏟고 있어요. 각자 스쿼드 제품 개발 업무에도 바쁜 현실 속에서 기술 과제까지 해결한다는 것은 어렵습니다. 기술 부채가 쌓여가는 이유기도 하죠. 더군다나 혼자가 아닌 함께 해결해 간다는 사실이 조별 과제의 악몽을 떠오르게 합니다. 기여하고 싶은 마음은 크지만, 뭘 해야 할지 몰라 의기소침해지기도 하고요.

오늘 가져온 주제는 레몬베이스 백엔드 챕터의 2023년 하반기 기술 과제 중 하나였던 “성능 테스트 환경 구축하기”입니다. 그 과정에서 기술 과제에 참여한 모두가 과제에 기여하고 유의미한 결과를 만들어간 문화를 자랑하려 해요.

기술 과제 해결 이야기

왜 해야 하는 거야?

기술 과제를 시작하며 가장 먼저 시작한 논의는 “왜”라는 질문에 대답하는 것이었습니다. 평균나이 서른마흔다섯살 엔지니어들의 다소 MZ스러운 시작입니다. 하지만 “왜”는 가장 중요한 질문이고, 시작하기 가장 적절한 질문입니다. 우리가 해결하려고 하는 문제에 공감하고, 그 공감은 적절한 동기를 부여해주니까요. 무엇보다 왜라는 질문에 대답하지 못하는 과제보다 더 중요한 과제가 있을 수도 있어요!

성능 테스트 해야 할 명분이 없다 아입니까? 명분이…ㅎ

답을 찾기 위해 레몬베이스 서베이 제품을 통해 엔지니어들이 “성능 테스트 환경 구축”을 기술 과제로 선정한 이유를 조사했습니다. 레몬베이스의 사용자가 빠르게 늘어나는 상황이고, 성능 관련 문제를 사전에 판단할 수 있는 장치가 필요하다는 이유였죠. 모두가 납득했습니다. 꼭 해야겠는데? 🤩

첫 미팅 첫 아젠다

뭘 해야 하는 거야 ?

무엇을 해야 할지를 정하기 위해서는 성능 테스트에 대한 해상도를 높여야 했습니다. 사실 이 기술 과제를 시작할 때 어떤 성능 테스트를 해야 할지, 또 어떻게 해야 할 지도 명확하지 않았어요. 말 그대로 맨땅에 헤딩이었죠.

헤딩도 살살하면 안아파.

덜 아프게 헤딩하기 위해 우리는 머리를 모았어요. 매주 시간을 정해두고 서로 리서치한 것을 공유하며 우리가 다소 무지하다고 생각한 영역들을 밝혀나갔습니다. 이 과정에서 팀 지식을 쌓아 올리는 것은 물론, 자연스럽게 다음 스텝들로 무엇을 해야 하는지 맞출 수 있었습니다. 첫 시작은 ‘성능 테스트가 무엇인지’였어요.

성능 테스트 리서치

많은 종류의 성능 테스트 종류가 있지만 레몬베이스 제품에서 중요하다고 생각되는 성능 테스트 4~5가지로 종류를 추렸습니다. 그 종류로는 일정 시간 동안 특정 load를 주어 성능을 확인하는 loading test, 시스템의 한계를 파악하기 위해 점차 load를 늘려 한계점와 한계점에서의 시스템 동작을 확인하는 stress test, 순간적으로 늘어나는 load(peak)에서의 성능을 확인하기 위한 peak test 등이 있습니다.

성능 테스트 리서치

하지만 이런 테스트 유형에 사로잡히기보다, 우리가 주목해야 할 테스트 전략이 무엇인지를 고민하기 시작했습니다. 그중에서도 우리가 주목한 건 Stress Test였어요. 이 기술 과제를 시작한 큰 이유인 “얼마나 많은 사용자를 레몬베이스 서비스가 감당할 수 있는가”, “우리가 목표로 하는 시장의 규모를 레몬베이스 서비스가 안정적으로 제공할 수 있는가”를 적절히 테스트할 수 있습니다. 또, 레몬베이스 도메인 특성상 여러 규모의 회사가 유사한 시기에 리뷰 작성을 하는데요. 즉 항상 높은 load가 발생하기보다 특정 시기에 높은 load가 발생하는 것이죠. 그래서 이에 유용한 Stress Test 유형의 테스트가 필요하다 결론 내렸습니다.

어떤 유형의 테스트가 필요한지 정리했으니 이제 어떻게 테스트할지를 알아가기로 했습니다.

성능 테스트 도구 리서치

성능 테스트에서 많이 사용하는 오픈소스 도구 중 2가지 locustk6를 사용해 보기로 결정했습니다. 두 도구를 선정한 이유는 아래와 같습니다.

locust: Python 스크립트 기반의 도구.

  • Django과 함께 사용하기에 비교적 유용할 것으로 예상
  • 오픈 소스
  • GUI 제공

k6: Node.js 스크립트 기반의 도구.

  • Datadog, Grafana 등 다양한 툴과 연동
  • 오픈 소스
  • 문서화가 잘 되어 있음

선정한 두 도구를 실제로 사용해보면서 우리가 필요한 항목들로 비교해보았습니다.

locust vs. k6

레몬베이스가 이미 사용하고 있는 도구들과 쉽게 연동할 수 있고, stage별로 가상 사용자를 조절할 수 있어 다양한 테스트 시나리오를 커버하기도 좋다는 점에 기인해 k6를 사용하기로 결정했습니다! 커뮤니티와 오픈 소스 개발이 활발하게 이뤄진다는 점도 큰 장점이었죠.

환경 구축은 어디까지 해야 하는 거야 ?

이 기술 과제의 이름은 ‘성능테스트 환경 구축하기’입니다. 환경 구축은 어디까지 해야 하는 걸까요? 이 과제에서 꼭 해야 하는 Must Have와 하면 좋은 Nice to Have가 있다면, 각자의 생각은 조금씩 다를 겁니다. 적절한 임팩트를 낼 수 있는 범위로 의견을 일치하는 게 필요했어요.

환경 구축 범위정의

그래서 본격적으로 과제를 수행하기 전에 기술 과제의 범위를 다듬기로 했습니다. 목표를 다시 한번 정의하면서 말이죠. 그러면서 개발자가 성능 테스트를 할 수 있는 환경으로 범위를 제한했습니다. 테스트 스크립트를 만들고 테스트에 필요한 데이터를 마련하는 것 등은 테스트할 엔지니어에게 맡기기로 했어요. 😆

돌이켜보면 이런 과감한 결정을 한 것이 좋았습니다. 만약 전부를 해결하려고 했다면 과제를 마무리하지도 못했을 것이고 과제의 방향도 잃었을 거예요. 빠르게 시도하고 실험하며 계속 개선해 나가면서 더 빠르게 가치를 전달할 수 있습니다.

로컬 환경 구축

시작은 로컬 환경으로 한정해 구성해 나갔습니다. 먼저 테스트를 할 스크립트가 있어야겠죠. 예시처럼 제공할 스크립트는 실제 사용자의 플로우를 따라 만들었습니다. 사용자가 서비스를 사용하면서 마주하는 실제 성능을 추적하고 싶었기 때문에 로그인부터 제품을 마주했을 때까지의 시나리오를 담았고, k6 CLI를 통해 테스트했습니다.

k6 CLI 테스트 결과

CLI로 실행한 테스트는 여러 항목들에 대한 수치만 떨어질 뿐 큰 인사이트를 얻기 위해서는 가공을 해야 했습니다. 그래서 테스트 결과를 단순 수치가 아닌 그래프로 비교할 수 있는 도구가 필요했죠. k6는 수많은 도구와 연동을 지원하는데요. 그 중 연동이 간단한 Grafana와 레몬베이스가 사용하고 있는 도구인 Datadog를 연동해 더 충만한 결과를 얻을 수 있었습니다.

Grafana 연동 결과

이 일련의 과정을 다른 엔지니어들이 쉽게 테스트할 수 있도록, 필수 개념과 세팅법을 정리한 가이드를 만들었습니다.

지속 가능한 환경

하지만 로컬에서 성능 테스트를 하는 것은 분명한 한계가 있습니다. 각기 다른 로컬 환경에 의존하고 있고, 테스트를 실행하는 환경과 처리하는 환경이 동일하기 때문에 정확한 측정이 어렵죠. 더 나아가 지속적으로 관리할 수 있는 환경이 필요했습니다. 테스트 스크립트를 관리해 나가고, 로컬이 아닌 환경에서 손쉽게 테스트할 수 있는 환경 말이죠.

그러기 위해서 GitHub Actions를 활용했습니다. 익숙한 도구이며, 잘 갖춰져 있는 인프라도 충분히 사용할 수 있었죠. 😁

GitHub Actions 작업할 때는 모두가 정말 빠르게 맡은 것을 뚱땅뚱땅 완성해 오는 진풍경을 보았어요. 기본적인 GitHub Actions 워크플로우부터, 입력받은 민감정보 마스킹, Tailscale 환경에서 접근 가능하도록 하는 권한 수정까지 엄청난 집념으로 하루 만에 해결해 버렸답니다.

다 해버려서 더 재밌는걸 갈구하는 Limy

그리고 더 재밌는 걸 갈구하는 모습까지 🤣.

k6 GitHub Actions 연동

이제 엔지니어는 테스트 스크립트를 새로 구성하거나 기존에 생성되어 있던 테스트 스크립트를 GitHub CI에서 실행하면서 지속적으로 성능 테스트를 해볼 수 있는 환경을 갖추게 되었습니다. 👏

문서 정리 및 공유

성능 환경 테스트 환경 구축 산출물 !

한 분기 동안의 과제를 4개 문서로 깔끔하게 정리했어요. 그리고 이 산출물들은 매주 진행하는 백엔드 챕터 미팅에서 공유하며 엔지니어들이 성능 테스트를 자유롭게 시도해 볼 수 있도록 하였답니다! 😊

성능 테스트 사용기

레몬베이스 서비스 중 대규모의 사용자를 가정했을 때 특히 느린 API 뭉치가 있습니다. 아래 이미지는 많은 사용자를 만들어두고, 실제 서비스를 사용할 때 마주하는 시나리오대로 구현해 테스트한 결과입니다. P95 응답 시간이 5.6초로 아주 느린 상황이죠. 🥲

개선 전 성능테스트 결과

테스트를 통해 사용자가 마주하는 서비스가 어떨지 예상을 할 수 있었습니다. 테스트를 했으니 개선해 봐야겠죠! 최근 해당 API들의 성능 개선이 이뤄졌어요. 대규모 사용자를 가정한 상황에서도 서비스가 적절히 동작하도록 다른 기술 과제에서 API들을 개선했습니다. 개선 후 테스트 결과를 확인해 보면 0.6초로 상당히 빨라진 응답값을 보여줬습니다. 개선 이전의 테스트 결과가 벤치마크가 되어서, 개선 후에 결과를 비교할 때 비교 지표로서의 역할을 톡톡히 한 것 같습니다.

개선 후 성능테스트 결과

끝맺음

짧은 회고와 함께 “성능 테스트 환경 구축” 기술 과제를 마무리했습니다. 🎉 단순히 ‘기술 과제를 해결했다’에서 끝나는 것이 아니라 기술 과제를 진행함에서 있어 좋았던 것과 수정해 볼 것들을 얘기하며 마무리한 것이 인상깊었습니다.

Whatsup 혼자 3명 분량을 남긴, 짧은 회고

막연한 주제로 시작해서 결과를 잘 마무리한 것까지 즐거운 기술 과제였어요. 그중에서도 Simpson의 회고 중 ‘4명 모두 적극적인 참여로 막히는 부분들이 잘 해소돼서 좋았다’는 문장이 눈에 들어왔습니다.

세상에 혼자 할 수 있는 것들은 거의 없고, 그들이 나에게 도움을 주듯 나 또한 그들에게 도움을 주는 것 같아요. 비록 잘 모르더라도 생각을 전달하는 것만으로도 말이죠. ‘환경 구축이라는 게 어디까지 해야 하는 건지 잘 모르겠다.’는 별것 아닌 것처럼 보이는 의견으로 기술 과제 범위를 더 구체적으로 잡고 빠르게 실행할 수 있었던 것처럼요. 생각과 고민들을 자유롭게 내어놓고 의견을 맞춰가면서 더 많은 인사이트를 넣을 수 있고, 그 자체로 모두가 한 걸음 나아가는 것 같아요. 동료의 성장이 결국 팀의 성장으로 이어지고, 그것이 다시 나의 성장으로 이어지니까요! 이렇게 마무리 지은 성능 테스트 환경을 어떻게 활용하고 개선해 나갈지, 그리고 어떻게 다시 돌아와 성장의 길로 이끌지 기대하며 여기서 마무리하겠습니다. 😊

레몬베이스 팀은 엔지니어 채용을 적극적으로 진행 중입니다.

성장에 진심인 분들, 더 나은 세상을 만드는 좋은 제품을 만드는 데 관심이 있는 분들의 많은 지원을 기다립니다! :)

[채용 중인 포지션 바로 가기]

--

--