Posthog - 코호트 사용시 주의사항

분석도구인 Posthog를 사용할 때 Dynamic Cohort는 Posthog를 죽인다.

원래는 진작부터 했었어야하는 일을 잡고 있었다. 반년 혹은 사용하기 시작할 때부터 유심히 봤었어야하지만 잘 다루는 사람들이 있어서 약간 미룬 것도 있긴하다.

Posthog를 사용할 때 자주 죽었는데 하루에도 몇번씩 죽을 때가 있었고 그 때마다 다시 시작하는 것으로 꾸역꾸역 쓰고 있었다. 나는 가끔 봤지만 매일 보는 사람들은 꽤나 괴로웠을 것 같다.

최근에 관련 인프라를 담당하는 분들께 앓는 소리를 조금 했다. 너무 느리니 같이 보자고.

한 며칠 헤맨 결과 실제로 문제는 코호트에 있었다.

기본적으로 Dynamic으로 설정되어있는데, 사용자나 이벤트가 많을 수록 매 순간순간 코호트를 업데이트 하려고 비동기 태스크가 발생한다. 정확히는 Posthog -> Celery -> ClickHouse 흐름이지만 중요한건 아니고, 이벤트가 발생할 때 이런 일이 일어나는게 문제였다.

Dynamic 코호트는 적어도 1억개 이상의 로그를 훑는다. 재수없으면 600억개 이상도 훑고 있었다. 그러니 죽을수밖에 없었다. 그리고 문제가 되는 코호트는 백그라운드에서 계속 실행중이니 삭제할 수도 없다. 인프라 담당자분이 Posthog를 재시작하는 사이에 지웠더니 그제서야 삭제되었다.

이후에는 서버 사양을 조금 낮추었는데도 쾌적하게 동작했다. 동시에 진작 했었을걸 하는 마음이 들었다.

사람들과 함께 이런 지표를 보곤 하는데, 실제로 의견을 주는 사람은 많지는 않다. 다만 조금씩 관심을 가져주는게 다행이라고 생각했다. 그리고 나는 필요없는거 없애면 좋겠다는 의견을 지속적으로 내고 있다.

다시한번 진작할걸 생각했다.

추가로, Posthog는 시간 범위를 다루는데 약하다. 정확히는 ClickHouse가 잘 못하는 것 같은데 조건이 많아지면 여지없이 쿼리하다 죽어버린다. 기존에 남아있던 쿼리들을 필요할 때마다 살펴보면 좋을 것 같다.

그동안은 왜 데이터를 이용한 개선을 못했을까.


Posthog 성능이 좋아져서인지 원래 주로 봐주던 분들이 안계셔서 그런지 모르겠는데 이 사람 저 사람 퍼널 만들어봤다고 보여준다.

성능이 좋아져서 보기 편해져서 그런거겠지 생각해본다.

최근 이직을 준비하는 분의 이야기를 들어보면 왜 했는지, 어떻게 했는지, 얼마나 힘을 덜 들였는지, 그래서 결과는 어땠는지 같은걸 물어봤다고 한다.

당연한건데 어려운거였다

Subscribe to Half-Built Life

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe