1편에 이어서 2편을 작성한다.
CI/CD
현재 당근은 자사 CI/CD 서비스를 만들어 운영중에 있다.
다만 이 내용을 조금 더 여쭤보니 Back단에서 Argo Workflow를 위한 manifest파일들을 만들어준다고 한다.
어떤 분은 왜 굳이 CI/CD 서비스를 만들었냐고 물으시던데, 그 이유에 대한 건 당근의 성향인 것 같다.
자신들이 원하는 방향으로 만들면서 필요한 부분들을 채우기 위해 자사 서비스를 만든 것이 아닐까 싶다.
컨테이너 이미지 빌드 도구로는 Kaniko와 BuildKit 중 BuildKit을 선택했다고 한다.
물론 Kaniko가 인지도가 더 많지만, 모든 것은 Dockerfile로 이뤄져있기에 Docker 문법이 중요하다고 생각하여 Docker의 빌드 엔진인 BuildKit을 선택했다고 한다.
또한 Dockerfile내에 RUN 커맨드가 10개 이상일 경우 빌드 속도의 차이가 크다.
DinD (Dokcer in Docker) 방식으로 Build를 하는 듯 한데, 마찬가지로 Dockerfile내에 빌드 및 의존성관리가 다 되어 있어서 Dockerfile 1개만 있으면 이론적으로는 어디서든지 빌드가 가능하다.
다만 이 부분에 문제점은 Cache관리인데 Kaniko를 예로 들면, 빌드가 Pod에서 일어나기에 해당 Pod의 디스크는 휘발성이다.
따라서 Cache가 생긴다 하더라도 다음 배포에는 사라지기에 빌드속도가 비교적 오래 걸린다.
이 부분은 Remote Cache로 테스트 해봤지만 Cache가 클 경우 오히려 느린 테스트 결과가 있었다.
그렇게 생각된 바가 /var/lib/docker 를 EBS에 마운트하여 Cache 볼륨만 Pod에 붙여서 빌드하는 방법을 채택했다고 한다.
EBS를 씀으로서 동시 빌드가 안되고 Zone 종속성이 있는 이런 장단점이 있다고 생각하는데, 빌드 자체가 오래 걸리는 서비스에는 고려해봐야할 것 같다.
비용
비용도 마찬가지로 kubecost를 기반으로 직접 개발한 서비스를 사용하고 있다.
CPU, Memory, Disk와 같은 비용들을 계산하고, 이를 GUI로 표시해준다.
GKE를 운영하면서 문제되는 부분이 네트워크 비용인데, 이를 여쭤보니 당근 또한 골칫거리로 남아 있다고 한다.
조금 독특했던건 라벨링으로 비용을 각 팀별로 분류한 다음, 이를 해당 팀들에게 주기적으로 레포팅해준다고 한다.
그럼으로써 각 팀이 어느 정도의 인프라 자원을 사용하고 있는 지를 알게 되고, 이에 따른 피드백도 온다고 한다.
개인적으로 이 부분은 정말 마음에 든다고 생각한다.
비용 관리는 전체가 다 같이 해야 효율이 좋다고 생각하기에…. 팀별로 안내해주는 것도 좋다고 생각한다.
기타
당근에서는 EKS로 전부 되어있으며, GCP를 사용하긴 하지만 BigQuery를 ML용으로 사용하는 듯 했다.
소스코드 자체는 전부 GitHub로 관리하고 있는 듯한데 ISMS 같은 심사는 어떻게 되는지 궁금하다.
application.yaml을 configmap으로 관리하고 있고, 재기동 시 최신 configmap을 물고 올라간다고 한다.
후기
생각보다 많은 정보를 들을 수 있었고, 어떻게 보자면 생각하는 바는 다들 비슷하다고 느껴졌다.
다만 그러한 고민에 대해서 충분히 시간을 들일 수 있는 환경과 그런 인력들이 있다는 것이 조금 다르게 느껴졌다.
처음으로 쿠버네티스를 도입하는 만큼 타사 사례를 알 수 있는 계기가 되었으며, 앞으로도 당근을 포함한 타사들의 사례를 견식할 수 있는 기회가 되면 꼭 참여하고 싶다.