2024 당근 밋업 후기

5 minute read

개요

최근 당근에서 기술 밋업을 진행했습니다. 그 밋업에서 인상 깊었고 팀에서 도입하면 도움이 될것 같다고 생각하는 내용들을 공유하려고 합니다.

당근 밋업은 4개 영역(프론트앤드, 서버, 데이터/AI, 플랫폼)중에 하나를 선택해서 추첨을 통해서 티켓을 받는 구조였습니다. 저는 현재 있는 팀이 사내에서 플랫폼팀이기 때문에 해당 영역을 선택했고 티켓을 받을 수 있게 되었습니다.

발표 내용

온콜. 알람만 보다가 죽겠어요.

개요

발표 중에 이전에 팀에서 만든 alert을 받고 핸들링하는데 있어서 문제가 있었고 그것에 대한 문제를 해결해주는 컴포넌트를 만들었다는 내용이 앞에 있었습니다. 그리고 그 이후에 팀에 oncall이 시작되면서 발견했던 추가적인 문제를 해결해 나가는 과정에 대한 발표였습니다.

주요 내용

팀내 oncall 시작하게 되면서 크게 3가지 정도 불편한 점들이 나왔다고 한다.

  • verbose한 알림(멘션)이 너무 많다.
  • 임계점 기반 알림 이외에 ‘추세 기반’ 알림도 필요하다.
  • 진행중인 알림을 구분하기 어렵다

verbose한 알림(멘션) -> Alert Severity Leveling

alert 별로 leveling을 설정하여서 정말로 큰 문제가 있는 경우에 대해서만 멘션을 하기로 하고 그 leveling을 통해서 현재 알람에 대한 중요도를 바로 판단할 수 있게 한다.

팀원분들과 leveling에 대한 정의를 진행한 이후에 실제로 현재 우리가 마주치는 alert들에 대해서 leveling을 나눴다고 합니다.

Low
• 임계치에 넘었지만 당장 바른 대응이 필요하지 않다.
Medium
• 임계치를 벗어나서 유지중이거나 증가했다. 때로는 빠른 대응이 필요할 수 있다.
• 필요시 담당자나 sre-oncall을 멘션한다.
High
• 일부 유저에게 미치는 영향도가 크며 SRE가 빠르게 확인해야 한다.
Critical
• 모든 유저에게 영향을 미치는 상태. EMERGENCY!

실제 발표자료를 보면 엄청나게 디테일하고 현재 가지고 있는 alert들을 나눴고 문제라고 생각되지 않는 alert을 없애거나 관심사가 달라지는 것들에 대해서는 채널을 나누는 식으로 최대한 알림에 대해서 빠르게 판단하고 관심을 가지도록 했다고 생각한다.

슬랙 스레드 방식 도입

이전에는 어떤 alert이 현재 아직도 문제가 진행중인지 파악하기 어려웠는데 슬랙 쓰레드로 문제들을 모두 연결시켜서 문제가 해결되면 해당 alert 쓰레드에 내용을 완전히 해결로 바꿔버려서 보지 않도록 만들어버렸다.

이것을 통해서 슬랙을 메시지를 봤을때 어떤 alert들이 아직도 진행중인것이 한눈에 알아볼 수 있도록 했다.

알림에 배포 이력을 추가

알림이 울렸을때 최근에 배포가 되었던 이력을 같이 보여줘서 실제로 해당 배포가 문제였다고 빠르고 알아낼수 있거나 만약 굉장히 예전에 릴리즈했더라도 또 다른 방식으로 문제를 접근할수도 있기 때문에 흥미로운 기능이라고 생각했다.

나에게 중요 내용

  • 온콜을 도입한 이유 온콜 -> 알림 이해도를 올리고, 이슈 대응 역량의 차이를 줄이자. -> 팀의 운영지식 전파와 개발자 소통
  • 자주 발생하는 문제이거나 어떤 액션이 필요한 것을 완전히 원클릭으로 해결할 수 있도록 한것 -> 이것은 되는것도 있고 안되는 것도 있기 때문에 애매하지만…
  • 최대한 oncall을 하는것에 대한 부담을 줄이기 위한 기능들을 추가하려고 한것들.

소감

나도 팀에서 oncall을 매우 많이 했지만 그리고 많은 프로세스를 개선하려고 했지만 다른 팀에서 어떤 식으로 oncall을 바라보고 그것을 이런 식으로 해결한다고 이야기를 하니 팀에 도입해ㅂ고 싶다는 생각을 했습니다.

Kafka 뉴비의 마이그레이션, 산넘고 물건너

개요

기존에 사내에서 사용하고 있던 kafka를 새로운 kafka로 옮기기 위해서 다양한 문제와 그것에 대한 고민과 해결에 대한 내용이었습니다.

주요내용

kafka를 엄청 크게 운영을 하고 있는 가장 높은 사용량을 보이는 cluster에 운영에 있어서 중요한 기능들이 빠진 상태였다.

  • No Rules - Schema Registry
  • No Rules - Topic Naming
  • No Rules - Topic 권한 관리

그래서 그것을 해결하기 위한 New cluster를 만들때 해당 기능을 넣고 migration 하기 위한 계획을 세웠다. 그리고 그 계획에 가장 큰 목표는 client 변경을 최소화하는 것이었다.

첫번째 문제: Static Broker Host

  1. Kafka Broker 전환의 어려움

configuration에 하드코딩된 Kafka Broker 정보를 client에서 모두 변경해야지 새로운 cluster에 접근하고 사용할수 있었다.

  • Kafka Wire Proxy

kafka protocol이라는 과정을 통해서 연결해야되는 kafka을 결정하게 되는데 kafka wire proxy는 그것을 중간에서 요청을 어떤 broker로 갈지 결정해주게 할수 있다고 한다.

  1. 점진적 전환

갑자기 특정 topic에 대해서 그것과 연관 topic을 사용하고 있는 모든 팀이 한번에 migration할 수 없을수도 있다.

  • kafka wire proxy에 data format 이용

header에 다양한 값들이 존재할 수 있는데 그 값들 중에 clientId 값에 routing에 대한 정보를 넣어서 그 clientId가 어떤 broker을 선택해야되는지를 정보를 줄 수 있도록 했다. 그 과정에서 External configuration를 이용해서 이 clientId는 어떤 broker을 접근해라는 정보를 넣었다.

두번째 난관: 메시지 동기화

3가지 측면에 대한 어려움이 있다고 합니다.

1) Topic Configuration -> 기존에 설정된 topic에 대한 설정. 이름, partition 값들과 같은 것들.
2) Message & Offset Sync -> 메시지가 들어왔을때 그것을 똑같이 새로운 cluster에 migration할 cluster에도 동일하게 처리되어야됨.
3) Renaming Topic -> 기존에 이름 룰이 없었기 때문에 그것을 전체적으로 변경할 수 있어야 됨.
  1. MirrorMaker2를 이용한 메시지 동기화
  • Kafka Connect 기반
  • 클러스터 간 데이터 복제 지원

Strimiz와 CR와 Helm Chart를 이용과 간단한 설정으로 메시지 동기화를 처리할 수 있음. Renaming Topic 빼고.

Renaming Topic에 대해서는 코드적으로는 지원해줬지만 잘 사용할수 있는 방법이 없어서 추가적인 extention을 만들어서 처리함.

Kick off migration

차근차근 실제로 user가 어떤 식으로 migration을 해야되는지에 대해서 설명했다. 사실 엄청나게 디테일하고 유저가 해야될것이 매우 명확해서 유저입장에서는 만약 migration한다면 엄청 쉽게 할 수 있을 것 같다는 생각을 했다.

그리고 무엇보다 유저 application이 어떤 상태일때 실제로 문제가 안일어날 수 있는지도 알려줘서 유저입장에서는 편했을것 같다는 생각을 한다.

나의 생각과 소감

일단 해당 발표에서는 문제에 대해서 차근차근 그리고 그것을 처리하기 위한 수단들에 대한 비교와 선택에 대한 이유들이 있었는데 그게 납득되는 범위여서 재미있었다.

그리고 무엇보다 차근차근 스토리가 있고 문제에 대해서 지속적으로 납득시키는 내용들이 있어서 더욱 해결방법이나 해당 일에 대해서 받아들일 수 있었던 것 같다.

나는 다른거보다 kick off가 정말 너무 디테일해서 진짜 나도 지금 바로 해당 플랫폼을 이용해서 migration을 할 수 있을것 같다는 생각을 했다.

이전에 개발자 고생하면 user가 편하다라는 이야기를 누가 했었는데 그 말과 딱 맞는 케이스가 아닌가 싶다.

궁극의 CI 환경을 만들기 위한 여정

개요

당근 내부적으로 build CI를 최적화하기 위한 도전기. docker에 remote cache와 kcontorl와 cache에 대한 생각들을 이야기해주는 발표

주요 내용

  • stateless하게 처리되는 build들 -> 확장성이 좋은건 알겠는데 빠르게할 수 없을까?
  • remote cache를 이용해서 docker build들을 최적화해보자!
  • 어떤 build툴이 좋지? Kaniko vs Buildkit -> Buildkit wins -> command가 많아지는 경우 압도적으로 성능차이가 발생함. 그리고 docker 기능들에 대한 지원.
  • 은총은 없었다… :(
  • 캐시가 작을때는 괜찮았지만 캐시가 커지니 캐시를 업로드하고 다운로드하는데 오랜 시간이 걸리고 준비시간도 오래 걸림 -> 실질적으로 캐시가 있는것이 더 느려짐.
  • 압축을 통해서 해결하였지만 cache hit 문제가 발생함.
  • Kontrol 이라는 당근 내부적으로 사용하는 서비스를 이용해서 CI를 동작하게 되는데 그것을 활용해서 캐시를 업로드와 다운로드하지 않도록 해보자!!
  • AWS EBS와 동적 프로비저너를 통해서 빌드를 하는 pod에 직접 프로비저닝하고 그곳에 있는 캐시를 이용함.

  • 그리고 프로비저닝된 도커 정보들을 이용해서 다른 배포에 대한 의존성을 없애고 docker 기능들을 이용해서 더욱 최적화했다.

  • 결과
    • 프로젝트별 빌드 소요 시간. 최대 91.4 % 감소
    • 회사 전체 빌드 소요 시간. 평균 30.71% 감소

나의 생각과 소감

잘 알지 못하는 내용이라서 조금 어렵다고 생각했는데 의사결정에 대해서 굉장히 자세한 설명을 같이 이야기해줘서 엄청 재미있게 들었다.

무엇보다 어떤 선택과 그것에 대한 사이드 임팩트로 인해서 다양한 문제가 발생할 수 있고 그리고 그것은 실제로 해보기 전에는 모른다는 것. 그럼에도 그런 상황에서 다른 방법을 찾아서 현재 팀내에서 활용할 수 있는 것들을 찾아서 최적화를 이뤘다는 것이 대게 신기하고 멋있다는 생각을 했다.

실제로 1년정도 만들었다고 했는데 풀타임으로 한것이 아니라 업무 중간중간 시간있을때나 퇴근하고 개발했다는 이야기를 질의응답 시간에서 해줘서 더 대단하다고 생각했다.

밋업에 대한 소감

당근 밋업에서 느꼈던 것은 발표내용에서는 실질적으로 기술적으로 엄청난 챌린지를 했던 내용보다 오히려 문제에 대한 접근을 더 강조했다는 생각을 많이 했습니다.

실제로 질문하고 싶은 내용이 있어서 질문을 했을때 오히려 기술적인 것에 대해서 굉장히 자세히 이야기해줘서 더 많은 이해가 되었고 실제로 엄청 큰 고민들과 시간들을 사용했구나 라는 생각을 했습니다.

개인적으로 당근 자체적으로 했지만 굿즈도 많이주고(개인적으로 중요한 부분…ㅎ) 내용도 너무 알차서 엄청 좋았습니다.

발표자료

Leave a comment

You may also enjoy