[세미나] [플랫폼엔지니어링] 당근마켓

https://www.meetup.com/ko-KR/awskrug/events/298048627/

Login to Meetup | Meetup

 
 
좋은 배포란

• 누가 언제 무엇을 배포했는지 알 수 있어야 한다.
• 담당자를 찾기 어려운 문제가 있었음
• Argo CD의 배포 완료와 엔지니어가 기대하는 배포 완료에 차이가 있음 > Argo 날림
• kubernetes를 몰라도 배포할 수 있어야 한다(알면 더 잘 쓸 수 있긴 하다)
• 처음부터 끝까지 직접 할 수 있어야 한다(사람의 개입이 없었으면 좋겠다)
• 문서 없이도 사용할 수 있을 정도로 편해야 한다
• 설문 조사는 하지 않았음

 
해결 방안

• Opinionated
• Convention over Configuration - 관례를 만들자
• 90% 정도는 커버해야 한다 (10%는 나중에 생각)
• Kubernetes manifest 추상화
• Configuration files - UI는 많은 노력이 필요하므로 개발자에게 친화적인 config file을 사용 ⇒ CDK8S 사용
• CDK의 장점: 프로그램과 연동할 수 있다(찍어낼거면 테라폼이 낫지만)

어디까지 배포라고 할 것인가

• 그냥 도커파일만 작성해오면 나머지는 SRE팀에서 하는 걸로

배포 방식

• CLI → 배포 BackEnd → K8s
• HashiCorp WayPoint 참고 → CLI로 모든 배포
• 배포 백엔드 → GoCD 사용(템플릿으로 찍어내고자)
• GoCD 버리기로 함 (UI가 못생김 ㅠ)

• MockUp 작성 → Primer Design System: Github에서 제공하는 디자인 참고

 
Full Cycle Engineering

• 도구를 만들어주면 엔지니어가 배포를 전부 할 수 있어야 한다.

SRE란 운영팀을 위한 소프트웨어 엔지니어를 말한다.

끊임없이 엔지니어링을 추구하지 않으면 업무 부담이 증가하여 그 부담을 나누기 위해 더 많은 인력이 필요하게 되고 결국에는 서비스의 크기에 따라 전통적인 운영 업무를 담당하는 인력이 기하급수적으로 늘어나게 된다.
...중략...
이러한 숙명에서 벗어나려면 서비스를 관리하는 팀은 코드를 작성해야 한다. 그렇지 못하면 늘어나는 일감에 파묻히게 될 뿐이다. 그래서 구글은 SRE팀에 티켓, 전화 응대, 수작업 등, 소위 '운영' 업무에 최대 50%의 시간만 투입하도록 정해두고 있다.

 
프로젝트 소유권 관리 → 팀 이름 카탈로그 보이게 함

• AWS 리소스 관리 매핑 필요

비용

• 비용의 가시성을 높여야 한다 → 직접 만듦

사용성이 좋지 않은 K8s 크론잡

• Argo는 K8s의 모든 구성 요소가 다 보여서 크론잡을 찾기가 어려웠음
• 크론잡을 따로 볼 수 있도록 함

운영의 기능성 개선

• 이벤트 모아보기

클라우드 리소스의 소유권을 관리할 수 있으니 생성도 하고 싶다

• 생성 기능 추가

 
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=129407308

사이트 신뢰성 엔지니어링

읽고 싶은 책 한 권 추가