당근 테크 밋업
일정: 2024.10.07(월) 11:00 ~ 17:00
장소: 삼성동 코엑스 컨퍼런스룸(남)
Agenda
온콜, 알림만 보다가 죽겠어요
당근에서 Alert Delivery를 활용한 온콜 프로세스를 도입하고 겪게된 문제점들과 해결 방법을 엿볼 수 있었습니다.
지속중인 이슈와 새로 발생한 것을 구분하기 어려운 점과 최근 배포가 있었는지 등 프로젝트의 정보를 알 수 없는 문제로 대응에 어려움을 겪었던 점들이 공감되었습니다.
멘션이 너무 많이와서 봐야하는 알림이 너무 많고 Verbose한 알림이 너무 많아 당장 대응이 필요한가? 의문이 되는 것들도 존재했고 임계점 기반 알림 이외에 추세 기반의 알림도 필요하다는 것, 진행중인 알림을 구분하기 어려운 것들을 문제로 Alert Delivery V2 구상으로 severity leveling 도입, 알림 시간과 레벨링 정책에 대한 도큐먼트 작성, 스레드 방식의 알림 도입으로 알림 시스템을 개선한 경험을 보았습니다.
severity leveling에 대한 기준을 정하기 쉽지 않다고 생각하는데 이 부분에 대한 기준치를 엿볼 수 있어서 좋았고 같은 알림이 3번 이상 발생하고 빈도 수 등 알림의 추세가 상향할 경우 온콜 & 담당자 멘션하는 프로세스가 인상 깊었던 것 같습니다.
문제가 발생하면 파드의 수 만큼 알림이 발생하여 상태를 관리하기 어려운 문제를 인지하고 있었는데 문제 해결에 도움이되는 길을 알게된 것 같습니다.
영상 플랫폼 운행 시작합니다.
헥사고날 아키텍처의 장점을 살리기 위한 노력들을 엿볼 수 있어 좋았고 성과지표로 최대 4580ms 걸리던 영상 업로드 속도를 931ms로 P99 기준 약 4배의 속도를 개선한 경험을 인상깊게 보았습니다.
Kafka 뉴비의 마이그레이션, 산 넘고 물 건너
Topic 1100, Consumer member 2000, message / day 수백만개를 서비스 / 광고 / 데이터로 분류하여 AWS MSK로 사용하고 있는 당근의 현황과 약 60% 정도를 사용하는서비스 카프카 클러스터를 마이그레이션 하기 위한 난관들을 보았습니다.
Static Broker Host 문제를 해결하기 위한 Kafka Wire Proxy 서버를 직접 개발한 것과 헤더 기반 라우팅을 통한 카프카 클라이언트별 세밀한 전환을 가져온 점, 메시지 동기화를 해결하기 위해 Topic Configuration, Message Offset Sync, Renaming Topic 과정을 보았고 GCP에서 AWS로 마이그레이션을 필요로 할 때 많은 인사이트를 가져다 줄 수 있는 내용들이었던 것 같습니다.
잃어버린 시간, 인프라 자동화로 되찾다
Okta, DB, Admin, GitHub 운영을 자동화 한 과정에 대해 소개하는 시간이었고 운영에 사용하는 시간을 감소한 사례들을 보며 공감되는 부분들이 있었던 것 같습니다.
수동 대응해야 하는 업무가 감소한다는 것은 지속 가능한 팀이 된다는 점을 다시 한번 느꼈던 시간이었습니다.
MongoDB On Kubernetes
MongoDB를 운영하기 위한 여러 방법을 검토하고 결정한 부분과 이를 도입하기 위한 과정들에 대해 알게되었습니다.
쿠버네티스 상에서 운영하게 된다면 EKS 버전 업그레이드, 노드 버전 업그레이드 등 고려해야 할 사항들이 많은데 이러한 부분들을 어떻게 해결했는지 알게 된 시간이었고 Atlas를 사용하고 있는 입장에서 비용적으로나 안정성 측면에서 도전해 볼 만한 주제라고 느꼈습니다.
Percona Operator에 대해 검토하고 분석해보자는 생각이 들게 하는 시간이었습니다.
궁극의 CI 환경을 만들기 위한 여정
빌드 속도를 개선하기 위한 캐시 관리 방법에 대해 알게된 시간이었습니다.
kaniko, buildkit 등 여러 툴을 통해 Remote cache할 수 있지만 여기서 발생하는 빌드 시간에 비례하여 늘어나는 오버헤드와 캐시 히트율이 떨어지는 문제를 직면하고 해결하게 된 과정들을 보았고 결과적으로 회사 전체 빌드 소요시간이 평균 30% 수준 감소한 것과 개발자들이 직접 빌드 시간 개선에 적극적으로 참여하게 된 점을 가져온 것이 인상깊었습니다.
기본적으로 Dockerfile을 잘 작성하여 사용하는 것이 제일 중요하다고 보고 해당 기능이 동작할 수 없더라도 빌드 가능한 환경으로 제공한 것이 확장이 편리하고 영향도 최소화를 가져왔다고 느꼈습니다.
비용이 왜 튀었는지 저도 몰라요
MAU 증가에 비해 인프라 비용이 더 많이 증가한 경험으로 우리가 클라우드를 잘 쓰고 있나? 라는 의문을 가지게 되었고 비용 가시성 확보의 필요성을 느껴 적용한 방식과 늘어나는 서비스들을 지속 가능한 서비스가 될 수 있도록 Netflix의 Full Cycle Developer를 참조하여 직접 만든 것은 직접 운영할 수 있도록 하는 구성을 만든 것이 인상 깊었습니다.
개발팀에서 직접 비용 최적화를 하게된 결과를 보며 많은 생각이 들게했던 시간이었다고 생각합니다.
