AWSKRUG 플랫폼 엔지니어링 소모임 일시: 2024.02.06 화요일 19:00 ~ 21:00

Prologue

다양한 IT 관련 행사를 참여하고나면, 후기 써야지… 배운거 정리해야지… 해놓고 미뤄둔지 한 세월…외부에서 진행하는 컨퍼런스나 네트워킹 경험을 기록하고 공유하기위한 우물 밖 개구리 시리즈를 시작하려 합니다.

첫 기록은 기존에 관심이 있던 플랫폼 엔지니어링과 관련한 세션을 들을 수 있었던 AWSKRUG 플랫폼 엔지니어링 소모임 경험입니다. 행사는 플랫폼 엔지니어링과 관련한 세션발표와 네트워킹으로 진행되었습니다.

AWSKRUG? AWSKRUG는 AWS한국사용자모임으로 분야 별, 지역 별 다양한 소모임을 운영하는 기술자 커뮤니티 입니다.

세션 발표

컨테이너 환경 시스템에서 개발자 생산성 플랫폼을 목표로

세션은 크게 3가지의 주제로 진행되었습니다.

1. 컨테이너 환경 플랫폼들을 구축한 과정
2. 회고
3. 개선

1. 컨테이너 환경 플랫폼들을 구축한 과정

# 컨테이너 환경 도입
쿠버네티스에 대한 레퍼런스가 없던 초기에, 서버 비용 절감과 효율적인 작업을 위해 컨테이너 기술을 도입했습니다. 물리서버에서 수행되던 소프트웨어 개발과 릴리즈 과정을 컨테이너 환경으로 이전하고자 했습니다. 초기에는 개발자가 k8s manifest를 업데이트하면, SRE 및 DevOps 팀(이하 플랫폼 팀)이 확인하고 적용하는 수동 프로세스로 구성되어있었습니다.

# CI/CD 자동화
시간이 지날수록 관리해야하는 manifest의 수는 늘어갔고, 매번 manifest를 확인하는 것이 번거로워져 컨테이너 시스템을 관리하기 위한 플랫폼을 고려하게 되었습니다. 플랫폼의 주요 목적은 CI/CD를 명확하게 분리하고 자동화하는 것이었습니다. 이를 위해 젠킨스 파이프라인을 도입하여 배포 자동화를 구현했습니다. CI/CD를 자동화 시킨 후 운영을 위한 로킹, 매트릭 체크 및 컨테이너 상태를 볼 수 있는 관리 방안을 고려하게 되었고, grafana, fluentd, kafka, es 등을 사용하여 로깅을 구현했습니다.

# 자체 개발 이벤트 시스템 도입
개발자는 내가 배포한 컨테이너에서 무슨일이 일어나는지, 배포 실패의 원인이 무엇인지를 궁금해 했습니다. 쿠버네티스에서 발생하는 이벤트 뿐만 아니라, 배포에서 생성되는 실시간 이벤트를 전부 수집하기 위해서 내부 이벤트 시스템을 구성하여 배포 과정 및 실패 원인에 대한 정보를 제공하고자 했습니다. 개인화된 설정을 통해 알람을 받을 수 있는 UI를 제공하고, 개발팀이 자체 API를 활용하여 능동적으로 사용할 수 있도록 했습니다.

# 자체 개발 k8s 멀티 클러스터 API 프록시 서버 도입
이 후 운영을 하면서, 다양한 클라우드 환경과 다수의 클러스터를 관리하는 데 어려움을 겪게 되었습니다. 온프레미스 또는 클라우드에 따라 권한체계와 세팅 구조가 상이하였고, 이를 해결하기 위해 go로 개발한 프록시 서버를 도입하여 k8s API 서버의 요청을 가로채고 권한 유효성을 체크하는 시스템을 구축했습니다.

API 프록시 서버를 도입하기전 다음과 같은 해결방안을 고민하셨다 함..
1. kubectl 설정 용이
2. 쿠버네티스 공식문서와 같이 쉽게 따라할 수 있어야 한다.
3. 권한을 셀프로 설정할 수 있어야 한다.
4. 리소스 변경에 대한 개발자의 권한을 뺏는 것은 개발자의 창의성과 생산성을 막는 것으로 적절한 제어 방식을 적용하고자 했다. 
=> 정말 개발자를 위한 플랫폼에 진심이시구나..를 느낄 수 있던 대목이었다..

# 그래서?
플랫폼을 구축한 결과, CI는 젠킨스를 통해 자동화되었고, CD는 자체 개발 이벤트 시스템과 API 프록시가 관리하고 있습니다. 이로써 개발자들은 보다 편리하게 작업할 수 있게 되었습니다…?

아니었다… 😢
클라우드 네이티브 시대에서 개발자에게 컨테이너와 클라우드 지식은 당연하게 되었습니다. 이러한 여러 툴을 신입이 다 배우고 쓸 수 있을까? 배우면 플러스가 되지만 몰라도 배포할 수 있고 개발할 수 있어야하지 않나?

2. 회고

# 개발팀과 플랫폼팀의 간극 구축된 플랫폼을 열심히 만들었으니 잘 알고 써주면 좋겠으나, 개발자는 그 툴에 대한 이해보다 코드를 잘 짜는것에 집중하고 싶어합니다. beta까지는 개발자가 배포할 수 있지만, 운영 환경은 개발자가 할 필요가 없습니다.

# 프로덕트 경험 부족 서비스에 문제가 생기면 비상이 걸리듯이 젠킨스와 같은 컨테이너 시스템 역시 하나의 제품으로서 중요하게 고려되어야 합니다.

프로덕트 중심 사고를 하기 위해서는 어떻게 해야할까?

1. 요청과 처리 중심으로 일하는 방식을 버리자.
   운영 업무는 로테이션을 통해 리소스를 최소화하고, 수동 작업들에 대해서는 왜 수동으로 처리하고 있는지 항상 고민해야 합니다.

2. 해결이 필요한 근본 원인에 집중하자. 수동작업이 편하다고 자동화 가능한 부분을 수동으로 하지말아야 합니다.

# 고객을 바라보는 관점 플랫폼팀의 고객은 개발자입니다. 이는 개발자가 사용하는 경험을 최적화하고자 함을 의미합니다. 개발자의 고객은 다시 사용자이며, 플랫폼 팀은 항상 개발자의 관점에서 그들이 무엇을 원하는지를 고려해야 합니다.

플랫폼의 기준

1. 추상화 자동화 뒤 편에 어떤 인프라와 툴이 있는지 개발자는 알 필요가 없고, 어떤 툴을 사용하든 언제든지 변경이 용이해야 합니다.

2. API 제공 개발자가 제공된 플랫폼을 능동적으로 사용하게하려면 API로 개발되어 개발적 내용이 선 순환 되어야 합니다.

3. 신뢰성 플랫폼을 프로덕트로 바라보고 SLO관리를 해야합니다.

4. 릴리즈 관리 플랫폼에 대한 가이드 및 Q&A 문서들을 개발자에게 적극적으로 공유해야 합니다.

5.제너럴리스트 관점 플랫폼은 신규 입사자도 사용할 수 있어야 합니다. 신규 툴 도입은 내가 하고싶은게 아닌, 개발자에게 익숙한 오픈소스를 도입할 수 있도록 노력해야 합니다.

3. 개선

# 배포라는 의미의 재정의
개발자에게 배포란 자동으로 테스트, 빌드, 푸시, 운영반영이 되고, 모니터링을 통해 상태 확인까지 할 수 있는 것, 버튼 하나로 배포의 진행상황 및 예상 시간, 최종 상태 등을 받아볼 수 있는 것 입니다.

배포를 위한 쿠버네티스 설정 중 리소스나 프로브 등은 개발자가 설정하기 여러움이 있으니 표준화해서 제공하였다고.. 
쿠버 고수를 위해서 커스텀 옵션도 넣을 수 있도록 플랫폼에 구현하셨다는데.. 사용자는 없었다고..한다..🤣

# 지속적인 프로덕트 관리
지속적인 프로덕트 관리를 위해서는 문서화와 함께 릴리즈 태그를 관리하고, 개발자들에게 튜토리얼이나 FAQ를 제공하는 것이 중요합니다. 배포의 과정은 쉽고, 하나의 플랫폼에서 수행되어야 하며, 프로젝트의 구조 및 환경에 상관없이 동일한 과정으로 배포할 수 있어야 합니다.

# 엔지니어링 생산성
중복과 비효율을 제거하고 개발자의 생산성과 병목을 측정하는 행위를 적극적으로 해야합니다.

목표

1. 병목 구간 측정 이러한 병목 구간은 툴 뿐만 아니라, 조직 간 요청 처리 등에서 발생하는 병목 또한 포함됩니다.

2. 적절한 플랫폼 제공 정보의 파편화를 어떻게 통합하고 연결할 수 잇을지, 자원의 통합을 위해서 라이프 사이클을 모두 하나의 플랫폼에 담을 수 있도록 해야합니다.

Q&A

1. 개발자들에게 어떻게 플랫폼을 알렸는지?
   • 개발자들 대상으로 관련 기술에 대한 테크톡을 진행하거나, 지속적인 서베이를 진행했습니다.
2. 개발자의 니즈는 어떻게 파악했는지?
   • 개발에 함께 참여하면서, 현장의 목소리를 듣곤 했습니다.
3. 운영업무가 몰리면 시간이 부족할텐데, 어느정도 자동화에 노력하고있는지?
   • 수동 작업 처리, 자동화 요건 파악, 자동화 구현으로 인력을 배분하여 진행하고 있습니다.
4. 가이드 작성할때, 사용자에게 모르는 개념이 나왔을 때, 어떻게 작성했는지?
   • 가이드를 사용자, 운영자 가이드 등 여러 구조로 나누어 작성하며, 궁극적 목표는 튜토리얼 제공입니다.

Review

플랫폼 엔지니어링을 위해선 어떤 관점을 가지고 있어야 하는지 정확하게 알 수 있었습니다. 기술에 집착하고, 고객이아닌 나를 위한 자동화, 개선을 하고있던건 아닌지.. 생각하게 되는 시간이었습니다. 세션 이후 카페에서 네트워킹도 진행되었는데, 편한 분위기에서 다른 회사 이야기도 들을 수 있었고, 항상 로망이었던 개발자 커뮤니티를 경험했다는게 너무 좋았습니다.👍 또 신청해야지 랄랄루~