[당근마켓]당근 SRE 밋업 2회 - 배포시스템 유투브 영상

2회 당근마켓은 왜 배포 시스템을 만드는가?  아래 유투브 영상입니다. 

배포 시스템을 만든다고 하니 뭘까 싶어서 보기로 했습니다. 저는 그냥 제공되어야 하고 제공 되면 쓴다 인데

만들어서 쓰나 봅니다.  회사 마다 상황이 틀리겠죠.  저희는 개발팀이다 보니 쓰는 입장이라 제공하는 부서 입장에서는

이부분이 중요할꺼 같고 쓰는 부서 입장에서도 잘 제공 되길 바라는건 매 한가지이니 이부분은 중요한 사항입니다.

 

잘 제공해주세요~ 감사합니다.    이부분은 회사 마다  각 부서의 역활에 따라 상황이 다른거 같네요. 

https://youtu.be/pc3H9i6Yv2Y

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Circle CI 광고 많이 하던데 쓰는데가 있긴 하군요. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

오래기간 사용 하다보니 쿠버네티스 manifest의 파편화가 발생함.

자신만의 디렉토리가 있다 보니 별도 운영이 되고 

전체를 아우르는 공통된 베이스가 없다 보니 

각 프로젝트 마다 다른 형태의 manifest에서 수정 하고 어떤 프로젝트는 상속 받은데서 변경하거나 

SRE 내에서도 여러 사람이 작업 하다보니 파편화가 발생하고 변경된 정책이 아직 다 전달이 안되었거나 할때도

발생하고 쿠버네티스 manifest대한 이해도와 배포에 대한 이해도가 낮다 보니 옆에서는 또 복사해서 사용하다보니 문제가 생각고

이정책이 서로 복사 하다보니 왜 필요한지 어떻게 되어 있는지 모르다 보니 문제가 있엇구요. 

 

 

 

 

 

 

각 배포가 달려 서로 영향을 미치고 모노 레포를 프로젝트별로 달리 별도 사용하다니 보니 충돌이 발생함.

 

 

 

 

 

 

음.. SRE 팀이 바쁘거나 일이 밀리면 아래 부분이 늦어지거나 해서 문제도 생김 

 

 

설정을 SRE 팀이 변경 했을때 개발팀 프로젝트에 영향을 미치는데 개발팀에 공지 혹은 작업 시간을 알리고 협의 하는 문제점 발생

같은곳에서 같이 작업 하다 보니 발생 하는 문제가 있었음. 

 

 

 

 

 

 

짧은 기간내 조직 규모가 성장하고 클러스터에 들어간 서비스도 120여개 이고

당근 마켓이 글로벌 서비스를 위한 대륙별 4개 리전에 8개 클러스터가 나가 있는데

지역별 서비스를 하므로 리젼간에는 서로 통신을 하지 않으므로 8개의 별도의 리전이 존재하는 상황이었음. 

 

 

 

 

 

 

SRE 팀에서 클러스터를 업데이트를 할때 새로운 클러스터를 준비해서 버젼 업그레이드 하고 클러스터를 갈아치우는 방식을 사용함. 

멀티 클러스터 업그레이드 방식을 취하므로 일시적으로 8개의 추가적인 클러스터가 생길수 있는 부분이 있음. 

1회때 왜 멀티 클러스터를 구성했는지는 나와 있으니 참조 바람. 

 

 

 

 

 

 

 

 

 

 

 

 

 

이번주에 입사한 개발자가 배포해야 하는 상황이 발생하면 배포 할수 있어야 한다는 목표로 

모르는 사람이 배포 해도 문제가 없어야 하는게 배포가 제대로 되는거로봄. 

 

 

 

 

SRE와 개발팀간의 영향이 없도록 분리 해야 한다. 

이런걸 시스템이 제공 하면 된다고 생각함. 

 

 

 

 

 

 

 

 

 

 

 

 

 

그래서 결론 완전 새롭게 만들자. 

그래서 아래와 같이 Control -> Kontrol 이라고 이름을 붙여서 새롭게 만듦

 

 

 

 

 

 

 

 

에이전트 = 러너 

Go CD의 기본 UI는 아래와 같음.   여기다 100개 프로젝트를 넣고 관리하면 좋을까 생각 했을때 아니다라고 결론 남. 

 

 

 

 

고민하다.  앞에 서버 두고 Go CD를 감싸 버리기로함. 

 

 

 

 

 

 

Git Hub 의 일부 컴포넌트를 가져와서 Git Hub 처럼 만들어서 제공함. 

 

 

 

 

 

아래와 같이 하여 개발자는 Kontrol 이라는 앞에 만든 서버를 보고 있는 상태이고 실제 일은 뒤에 있는 Go CD가 해줌 

 

 

 

 

 

 

각 프로젝트에서 APM / Grafana / 등등 여러 편의 및 부가 서비스를 붙여 나아가고 있음. 

음... 개발자들이 개발을 하기 편하도록  Paas Potal + CI/CD 합친다는 느낌으로 가져 가는것에 대해서

고민 해보는것도 의미 있을지도 모르겠네요 for only 개발자 포털용

 

 

 

 

 

 

 

 

 

음.. Paas Potal의 일분 기능 즉 쿠베등등 몇가지 관리를 합쳐 주거나 아니면 싱글 사이온으로 편리하게 왔다 갔다 할수 있게 하면

시간을 더 줄일수 있을듯 좀더 고민해봐야겠군요.  아니면 Paas 포털에서 개발자가 자주 쓰는 기능을 API로 연결되도록 하던지도 

효율성 향상을 할수 있을듯 한데... 고민이 되네요. 

 

 

 

 

 

각 클러스터의 Go CD Agent가 다 설치 되어 있음. 인증 관련 정보도 Agent로 관리 

 

 

 

 

 

 

 

모든 서버가 다 떠야 실제 배포가 끝난거니까 V1이 다 없어져야 배포가 완료 된것임. 아래 그림. 

 

 

 

 

 

아래 명령어로 해당 Rull out이 완전히 끝났는지 검증하는 명령어는 아래 명령어. 

 

 

 

 

 

 

우리와는 좀 다른 클라이언트 서비스의 관점이 있으므로

백엔드는 아래와같이 보면 되는데~ 프론트 앤스 사용자 측면의 클라이언트의 배포는 비주얼라이징 하는게 필요할듯 

그것까지 봐야 완벽한 고객 서비스로 보고 추가적인 고민이 필요할꺼 같다. 

 

 

 

 

누가 더 편한가 누가 더 불편해야 하는가???

 

균형점을 찾을 필요가 있음. 

 

 

 

 

 

 

 

 

 

 

아래 정책에 대해서 고민이...  필요하다고 봄. 

 

 

 

 

 

 

후자인 가드레일 방식의 정책으로 많이 만들어서 안전하게 배포하고 서비스를 운영해야 한다는 관점으로 가기로함. 

개발팀에 자유도를 더 주었고 SRE 팀의 관리 포인트와 권한을 분리 최소화한걸로 보임. 

 

네이밍 규칭등 물어 보는게 많았는데 그것도 줄이고자 함. 

빠른 배포를 하고자 하면 통제관리 조직의 권한과 프로세스를 줄일 필요는 있음. 

 

 

 

 

 

AWS IRSA를 사용했네요. 권한 컨트롤 시스템의 해당 부분을 SRE가 했는데 관리하기 피곤하고 어려움이 있음 

과도한 권한 여부에 대한 검증 및 승인 등의 단계가 필요하므로 이것도 중앙 통제 방식으로 너무 느리고 SRE 팀이 힘듦

 

 

 

 

 

 

 

아래와 같이 권한을 개발팀으로 Policy에 대해서 상속하는 방식으로 하위로 제공 되도록함. 

 

 

 

 

 

일단 기능 만들어야 할께 많은데 고민은 많았으나 현재 배포 가능한 기능이 있는 상태 이므로 일단 오픈 하고 

기능 추가 및 업그레이드 방식으로 가기로 함. 

 

 

 

 

 

급히 오픈을 하고 나고 보니 마이그레이션 해서 넘길려고 해보니 이후 실제로 해보니 노가다 반복적인 작업이 많았더라. 

 

 

 

 

 

그래서 결국 외면 당할번 했을듯.... 합니다. 일을 줄여 주지 않은 서비스 제공은 개발자들도 좋아 하진 않을텐데 

아마 당근은 그래야만 하는 목적과 목표가 있었을듯. 

 

 

그래서 아래와 같이 서비스 관점으로 홍보 및 제공 활동을 하고 있음. 

 

 

 

 

 

 

 

 

 

 

음. SRE팀에 배포 시스템의 개발 및 운영의 역활을 줄것인가?

그리고 배포에 대한 주요 정책 그리고 글로벌 변수로서의 형상 관리와 지역 변수로서의 형상관리가 SRE 팀과 개발팀/프로젝트팀간의 

정책과 운영관리를 어떻게 할껀가 등에 대한 고민이 필요하겠네요. 

 

Paas와 Paas 포털 , WEB/WAS/GeustOS/DB/네트워크와 클라이언트 프로그램 앱/웹/차량단말까지 연동에 따른 서비스 신뢰도 측면에서 어떻게 할껄지에 대한 관리도 즉 변경관리에 대한 총괄을 어떻게 할건지 영향도 분석과 체크리스트는 어떻게 할껀지도 같이 봐야겠네요.