안녕하세요. 올리브영의 배포 문지기를 맡고 있는 QA 엔지니어 황소입니다.

이번 글에서는 Datadog을 올리브영 QA는 어떻게 활용하고 있는지에 대해서 공유합니다.

목차

• QA가 Datadog을 활용하게 된 이유
• 올리브영 QA는 Datadog을 어떻게 활용하고 있나요?
• 그밖에 사용되면 좋을 기능들은 무엇이 있나요?

QA가 Datadog을 활용하게 된 이유

Datadog은 주로 SRE 업무에서 사용된다는 인식이 강하지만, QA 측면에서도 서비스의 질 관리를 위한 모니터링 목적이 같아 유용하게 사용할 수 있다는 생각이 들었습니다.

Datadog을 활용하면 운영 중 발생하는 이슈를 더 빨리 파악하거나 현재의 운영 문제를 개선하는 데 도움이 될 것으로 보였습니다.

더 나아가 운영 배포 전 잠재적인 이슈를 미연에 방지할 수도 있다는 점에서 Datadog을 QA 과정에서도 활용하기 시작하게 되었습니다.

올리브영 QA는 Datadog을 어떻게 활용하고 있나요?

1. [로그 활용]

   현재 로그 확인은 두가지로 이루어지고 있습니다.

   1. APM Log 확인

      올리브영은 서비스별로 APM Log를 쌓고 있습니다.

      서비스별로 호출되는 것들에 대해서 기록되고 있고 이 과정에서 오류가 존재 할 경우 오류 로그를 남기게 됩니다. 오류 빈도수가 평소보다 많이 높게 올라간다면 시스템에 문제가 발생했다는 것을 인지할 수 있으며 어느 서비스에 문제가 있는지 바로 확인이 가능하게 됩니다. 그래서 이 부분을 이용하여 알람 설정까지 하여 운영 환경에서 문제가 생겼을 때에 바로 인지가 가능합니다.

      간헐적인 이슈 인입 시에도 APM Log를 사용하고 있습니다.

      재현이 되지 않는 이슈의 경우 로그에 의존할 수 밖에 없어 해당 시간의 로그를 확인하여 이상 로그가 없는지 검토 후 개발자분께 전달하게 됩니다. 또한 인입된 이슈가 해당 시간에 평시보다 높게 발생하는지, 평시와 동일한지, 배포 이후에 오류 빈도가 높아졌는지 등을 판단하여 서비스에 영향이 있는 것인지도 같이 판단하고 있습니다.

      

      또한 오류가 발생하였을 때 어느 부분에 문제가 발생한 것인지 파악하기 용이합니다

      테스트 한 시간의 범위를 지정 후에 그때 발생했던 APM 오류 로그를 확인합니다. 물론 오류마다 달라서 APM으로 확인하지 못하는 부분도 있습니다.

      특정 시간의 오류 로그를 확인 후 해당하는 오류의 상세 내용을 보면 어느 서비스에서 문제가 발생했고 어떤 오류가 발생했는지 상세 내용을 볼 수 있습니다. 좀 더 자세한 오류를 파악할 수 있어 담당자 찾기가 쉽겠죠?

      

   2. QA 테스트 서버 Log 확인

      Datadog은 커스텀한 로그에 대해서 가공 후 통계를 대시보드로 보거나 알림을 제공할 수 있습니다. QA 자체적인 서비스별로 API, 페이지의 Health 체크, 성능 로그를 필요에 따라 python으로 만들어 운영 환경에 이상이 없는지를 실시간으로 모니터링 하도록 만들었습니다.

      커스텀 로그의 통계를 보거나 하려면 로그를 파싱하는 작업이 필요합니다. Datadog에서 Log Pipelines을 설정하면 됩니다. 어떤 로그를 파싱하여 사용할지 조건을 먼저 걸어서 Pipeline를 생성하고서 그 Pipeline의 하위에 Processor를 생성하게 됩니다.

      파싱 룰 정의는 정규화식으로 작성하면 됩니다. 저희 같은 경우의 성능 로그를 확인해 보면

      2023-09-19 08:52:43,004 [INFO] (basic.py:161) - datadog_metric metric=qaMetric isReload=navigate, location=메인홈, url=https://m.oliveyoung.co.kr/m/mtn?menu=home, arch=new, htmlRequestResponseTime=100, renderTime=200, loadTime=1100, domContentLoaded=250, domContentLoadedTime=1000, lcpTime=1864, fcpTime=500, env=SKT_5G, userAgent=Mozilla/5.0 (Linux; Android 13; SM-G986N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Mobile Safari/537.36

      과 같이 로그를 찍고있습니다. 이걸 정규화식으로 범용적으로 하기위해서

      autoFilledRule %{date("yyyy-MM-dd HH:mm:ss,SSS"):date}\s+\[%{word:level}\]\s+\(%{notSpace}\.py\:%{integer}\)\s+-\s+datadog_metric\s+%{data::keyvalue("=","\"*\\[\\]")}

      과같이 규칙을 정해두었습니다. 정상적으로 규칙이 적용되었다면 로그를 확인했을 때 아래와 같이 key, value 값으로 연결된 것을 볼 수 있습니다.

      이렇게 가공한 로그를 바탕으로 성능 대시보드를 만들어 사용하고 있습니다.

      

      이러한 방식으로 QA에서도 필요한 정보들을 로그로 생성하여 Datadog에서 활용하고 있습니다.

2. [실사용자 오류 확인]

   Datadog에는 RUM(Real User Monitoring)이라는 기능이 있습니다. 실제 사용자 기반으로 로그를 수집하게 됩니다. QA에서 주로 사용하는 기능은 Error Tracking 기능과 Sessions Explorer 기능이 있습니다.

   1. Error Tracking Error Tracking 기능의 경우 많이 발생하거나 신규로 발생하는 에러를 확인하는데 용이합니다.

      실제로 Error Tracking은 운영 서버뿐만 아니라 QA 서버에서의 오류도 Tracking 하고 있습니다. 그래서 QA 도중 신규 오류가 인입되거나 기존 존재하는 오류가 급증할 경우 알림이 발생하여 배포 이전에 오류를 확인 및 수정하고 배포할 수 있게 되었습니다.

      

      인시던트가 발생하였을 때 인시던트가 어느 시점부터 시작되었고 종료되었는지도 확인합니다.

      👉 인시던트에 대해서 좀 더 알고싶다면 바로가기

   2. Sessions Explorer

      Error가 발생한 것을 확인했다면 어떤 경우에 에러가 발생하였는지도 확인이 되어야 합니다.

      오류를 발생시킨 사용자의 action 및 페이지를 확인하여 동일한 현상 발생 빈도 및 오류 스텝을 확인합니다. QA 서버 테스트 중에도 갑자기 오류가 발생하였다면 내가 어떤 동작을 수행했는지 기억을 하기 어려울 수 있습니다. 그 경우 RUM의 Sessions Explorer를 통해서 내가 어떤 동작을 했는지 확인할 수 있습니다.

      아래 사용자를 확인해 보면 페이지 진입 후 "2 배송 완료" 버튼을 클릭하고서 페이지를 이동하더니 mtn 서비스 쪽에서 오류가 난 것을 보실 수 있습니다.

      오류 발생 session이 종료되지 않고 다른 페이지를 이동한 것으로 보아 서비스를 이용하는 것에는 문제가 없어 보이는 사용자입니다.

      

      또 다른 사용자를 보면 어떤 페이지를 로딩 후 계속 오류 메시지가 뜨고 있고 그 이후에 어떤 엑션을 하여도 페이지 이동한 기록은 없이 오류 메시지만 찍히고 있습니다.

      이러한 경우는 서비스를 이용할 수 없을 정도의 오류가 해당 사용자에게 발생하고 있다는 것을 알 수 있습니다.

      

      RUM은 실사용자의 실제 동작과 정보를 모두 수집합니다. 따라서 특정 콘텐츠나 상품에서 문제가 발생했을 때, 그 문제가 발생한 콘텐츠나 상품을 함께 알려주기 때문에 오류를 더 빠르게 찾아낼 수 있습니다.

      특히 RUM은 백엔드 이슈를 확인하는 것보다 프론트엔드 이슈를 확인하는 데 더 도움이 됩니다. 더 유용하게 사용하려면 에러 로그를 자세하게 수집하는 로직이 들어가야 문제의 원인을 더 쉽게 찾아 수정할 수 있습니다.

      RUM의 경우 로그 데이터 양에 따라 비용이 발생합니다. 따라서 접속 사용자가 많을수록 비용도 높아집니다.

      그래서 저희는 적은 비용으로 일반 사용자와 내부 테스터의 이슈를 모두 관찰하기 위해 로그 수집 비율을 지정하였고 특정 사용자의 로그만 100% 수집하도록 함으로써 비용 이슈를 해결하였습니다.

3. [성능 확인]

   RUM의 또 다른 기능 중에 하나로 성능을 확인 해볼 수 있습니다. Datadog에서는 수집된 사용자들에 대해서 Loading Time, FCP, DOM Interactive, LCP등 성능에 대한 정보를 제공하여 이를 바탕으로 성능을 확인하고 있습니다.

   올리브영에서 성능 확인 및 모니터링은 어떤 식으로 되고 있는지 다음에 작성하게 될 글에서 자세히 설명하겠습니다. (To be continued...)

4. [UI/UX 자동화 테스트]

   올리브영에서는 PC 플랫폼 자동화 테스트로 Synthetics 기능을 사용하고 있습니다. 정상 유무를 판단하는 것에도 사용하지만 Synthetics 기능에서도 성능을 확인 할 수 있습니다.

   

그밖에 사용되면 좋을 기능들은 무엇이 있나요?

1. [RUM > Session Replay]

   RUM에서 Session에 대한 Action을 수집해 준다고 하지만 글로 읽는 것과 현상이 발생하는 것을 동영상으로 확인하는 것은 인지 속도에 차이가 있습니다.

   Session Replay의 경우 동작과 결과를 모두 녹화하여 오류가 생겼을 때 어느 동작에서 생겼으며 어떤 현상이 발생하였는지 빠르게 알 수 있습니다.

   기존에는 PC만 지원했었는데 최근부터는 모바일 웹도 베타 버전으로 지원하기 시작하여 PC보다 모바일 웹 유저가 더 많은 올리브영의 경우 활용도가 더 높아질 것 같습니다.

   개인적으로 오류가 발생했을 때는 100% Session Replay 기능을 지원하는 등 특정 조건에 한해 100% Session Replay를 지원되면 좋을 것 같은데 replay 할 세션을 먼저 잡은 상태에서 오류를 기록하는 기능이라 불가능하다고 합니다.

2. [RUM > User Journeys]

   사용자들이 어떤 흐름으로 동작을 많이 하는지 파악할 수 있는 기능입니다. 이 부분은 어떤 기능을 중요하게 보아야 하는지 선정할 때 사용하면 좋을 것 같습니다.

마치며

올리브영 QA Enginner로 일하고 싶다면 지원하러 가기