[k8s] 2024 당근 테크밋업 후기 - 1 (k8s, Kafka, Alert, Monitoring)

지인이 당근 테크밋업이라는 세미나를 알려줘서 세션들을 확인해보니 D플랫폼에 흥미가 많이 가게 됐다.

D플랫폼의 세션들을 보자면

1~2개 세션 말고는 전부 흥미가 가는 세션들로만 이루어진 D플랫폼을 신청~2개 세션 말고는 전부 흥미가 가는 세션들로만 이루어진 D플랫폼을 신청하고 운 좋게 참석했다.

주변 지인 중 떨어진 분들도 있긴 했지만, DevOps와 유사한 D플랫폼은 생각보다 경쟁률이 낮은 것 같았다.

세션에 대한 내용은 아래 링크를 확인하면 된다.

당근은 AWS EKS만을 사용하고 있는 것 같고, 서비스(당근마켓)용으로 단독 클러스터를 구축해서 사용하고 있다고 들었다.

이 부분은 우리와도 비슷했는데, 물론 개발/검수/운영 환경에 각각 서비스용 클러스터가 존재하지만, 하나의 환경에 서비스용으로는 1개 클러스터만 구축해서 사용하고 있다.

이 부분은 일장일단이 있는 것 같은데, 팀의 정책과 서비스의 특성에 따라 다를 듯 하다.

당연하게도 Muilti Zone으로 구성되어 있으며 네임스페이스는 300개 이상으로 꽤 많았다.

어떤 기준으로 네임스페이스를 구분했는지가 궁금했지만, 시간이 없어서 여쭤보지를 못했다. ㅠㅠ

k8s내에 MongoDB를 올려서 사용하고 있다는데, 고성능 볼륨을 장착해 IOPS를 보장해주면 컨테이너로 올려도 성능차이가 없다는 테스트 결과를 얻었다고 한다.

물론 RDB의 경우에는 조금 다를 수 있을텐데, MongoDB를 사용해야하는 상황이 오면 나도 한 번 k8s에 올려서 사용해보고 싶다.

사실 k8s에 제일 큰 걸림돌은 DB이지 않을까라는 생각이 들기도 하다.

CSP의 DB Service를 쓰지 않는 이상 대부분은 VM에 DB를 구축할텐데 이 부분을 어떻게 운영하는 지가 많이 궁금하다.

현재 아키텍처상으로 Kafka를 생각하고 있지는 않지만, 대규모 서비스에는 당연하게도 많이 사용 되는 것이 Kafka다.

테크밋업에서는 Kafka의 마이그레이션을 주제로 발표했으며, Kafka를 잘 모르지만 되게 중요한 내용인 듯 했다.

크게는 Kafka Wire Proxy, Mirror Maker2 를 이용하여 거의 무중단 마이그레이션으로 진행 후 완료했다는 내용이였고,

다른 사람들에게도 유용한 세션인 것 같았다.

많은 분들이 관심을 가질만한 주제인데, 세션을 들으면서 사람 사는 건 다 똑같구나 라는 생각을 들게 해줬다.

다들 같은 고민과 같은 해답을 향해 나아가고 있었고, 그 해답에 어느정도 시간을 투자해서 성과를 만드는지가 조금 다르게 느껴졌다.

예를 들자면 당근에서 대부분의 Alert는 Grafana에서 발생시키고 있지만 Grafana에서 발생시키는 임계치에 대한 Alert로는 한계가 있다.

그렇기 때문에 나를 포함해서 대부분의 DevOps들은 Grafana – 엔지니어 사이에 Grafana – Server – 엔지니어처럼 Server를 하나 둬서 알람을 정제하고, 특정 로직을 추가하여 엔지니어한테 발송되게 끔 하는 것을 목표로 했을 것이다.

하지만 Server를 개발하는데에는 공수도 많이 들고, 이것보다 중요한 일들이 많기 때문에 어떻게 보면 우선순위가 낮게 측정되는 것이 안타까웠다.

당근은 특정 멤버들이 이러한 Server를 개발하는데에 충분히 시간을 들일 수 있다는 것이 부러웠다.

당근의 Server에서는 알람을 로직적으로 판단하여 위험도를 재산정하고, Slack을 통해서 받고 있다.

모니터링은 Prometheus 기반이며, 추후에는 Thanos를 생각하고 있다고 하셨는데 Thanos…. 언제쯤 다뤄 볼수 있는 시간이 되려나 싶다.

글 내용이 너무 길어질 것 같아서 빌드&배포 관련이랑 비용, 기타 내용은 다음 글에 작성해야겠다.

[k8s] 2024 당근 테크밋업 후기 – 1 (k8s, Kafka, Alert, Monitoring)