중견이상의 기업이라면 애플리케이션팀이 개발한 코드를 프로덕션으로 배포하는 표준화된 방법을 지원할 수 있는 플랫폼이 있어야 합니다. 이 플랫폼은 배포하려는 애플리케이션을 더 쉽게 유지보수하고 확장하며 강화된 보안과 비용 효율적으로 운영할 수 있도록 합니다. 플랫폼은 표준화된 개발환경, 자동화된 배포와 확장, 중앙화된 모니터링과 로깅, 비용 최적화를 제공합니다. 즉, 플랫폼은 애플리케이션 개발 및 배포의 과정의 질과 효율성을 개선할 수 있습니다.
쿠버네티스는 클라우드 인프라를 위한 공동의 언어를 제공합니다. 워크로드, 프로비져닝 디스크, 인그레스 설정, 애플리케이션 인증서 프로비져닝, 앱과 서비스의 확장 및 다양한 요구사항을 운영하기 위한 머신의 프로비져닝을 단일 인터페이스에서 가능하게 합니다. 즉, 쿠버네티스가 인프라의 진정한 근간이 될 수 있음을 뜻합니다. 그러나 쿠버네티스는 퍼블릭 클라우드와 매우 유사합니다. 개발자에게 클러스터에 접근할 수 있는 권한을 제한없이 줄 수는 없습니다. 개발팀이 안전하고(보안), 효율적이며 신뢰할 수 있는 방법으로 애플리케이션을 개발할 수 있는 어느정도는 추상화된 쿠버네티스 레이어가 필요합니다.
요약:
- 플랫폼 운영을 위해서는 쿠버네티스와 클러스터 애드온을 통해 SSL인증서, 클러스터 트래픽, 정책적용, 자원 사용량 모니터링 등을 관리합니다. 앱을 쿠버네티스 클러스터에 배포 및 운영하고 개발팀에 통합되고 일관된 피드백을 지속적으로 제공하며, 쿠버네티스가 모범관행을 따르도록 거버넌스가 필요합니다.
- 개발자가 쉽게 앱과 서비스를 배포하고 운영하며 모범관행을 따를 수 있도록 쿠버네티스 셀프 서비스를 강화해야 합니다. 셀프 서비스 강화의 순서는 다음과 같습니다:
- 1단계: 환경에 대한 파악 - 잘 되는것과 되지 않는 것에 대한 이슈 파악
- 2단계: 환경 파악을 통해 이슈 파악. 환경을 스캔하고 발견된 이슈를 SDLC의 개발초기 단계(시프트 레프트)로 이동하여 이미 사용중인 슬랙, 지라 등의 툴을 통해 개발팀의 피드백을 받아 차단할 이슈와 경고를 줄 이슈로 구분
- 3단계: 어드미션 컨트롤러를 통해 쿠버네티스 모범관행이 자동 적용될 수 있도록 가드레일을 설정. 개발팀이 확신을 가지고 코드를 더 빠르게 배포할 수 있도록 안전망 제공
- 4단계: 가드레일과 병행하여 환경에 대한 지속적 모니터링을 통해 개선 가능한 영역 파악 (보안, 신뢰성, 비용 효율성 영역) 및 개발자와 소통 통해 개발자 셀프 서비스 강화
- 5단계: 개발자 피드백을 요청하여 이슈를 파악하고 해결하기 위한 프로세스 개선이 필요
클러스터 애드온
신규 클러스터를 클라우드에 생성하면 (예: AWS에 EKS 또는 GCP에 GKE 생성) 아무것도 설치되지 않은 바닐라 쿠버네티스 클러스터가 만들어집니다. 많은 기능이 있지만 프로덕션 애플리케이션이 필요로하는 모든 기능을 다 가지고 있지는 않습니다.
쿠버네티스가 관여하지 않지만 추가로 필요한 기능에는 다음과 같은 것이 있습니다:
- 애플리케이션 배포
- SSL 인증서 프로비져닝
- 클러스터 내부로의 트래픽
- 정책 적용
- 사용되는 리소스 모니터링
배포
개발팀이 개발한 애플리케이션이 클러스터에 배포되고 운영될 수 있도록 해야합니다. 즉, 개발자가 코드를 배포하거나 특정 커밋을 태그하면 자동으로 CI/CD 과정이 시작되도록 해야 합니다. 아마도 Helm을 통해 이런 자원이 클러스터로 들어가도록 하고 있을 수도 있습니다. 플랫폼팀이 조직에 가장 적절한 방법을 찾아 제시해야 합니다.
피드백
클러스터 애드온을 통해 배포가 되고 운영이 시작되면, 어느정도 시점이 지난 후에 개발자는 배포가 일어나지 않거나 앱이 제대로 확장되지 않거나 앱이 멈추는 등의 이슈에 봉착하게 됩니다. 플랫폼팀은 개발팀에 이런 이슈를 해결 할 수 있는 방법을 제시해야 합니다.
- 발생한 이슈에 대한 트러블슈팅
- 애플리케이션의 환경 변수에 애드온을 추가하는 방법
- 문의사항이 있을 때 이슈를 등록하는 방법
개발팀은 풀리퀘스트, 슬랙, 지라 티켓 등과 같은 다양한 방식으로 이슈를 플랫폼팀에 알릴 수 있어야하고, 어떠한 방식으로든 상호작용을 통해 플랫폼팀과 함께 이런 문제들을 해결해야 합니다.
거버넌스
거버넌스와 피드백은 매우 비슷해 보이지만, 큰 차이가 있습니다. 거버넌스는 개발팀이 ‘절대로 하면 안되는 일을 하지 않도록’ 강제하고 동일한 문제가 반복되지 않도록 하는 것입니다. 피드백은 플랫폼팀에게 개발팀이 ‘이슈를 어떻게 알릴 것인가’에 대한 방법입니다.
거버넌스를 가장 잘 다루는 방법은 정책을 적옹하는 것입니다. 예를 들어:
- 워크로드는 루트에서 운영 불가
- 1개 워크로드는 포드당 5CPU만 요청 가능
개발팀이 프로덕션에 문제를 발생할 경우, 발생한 문제를 정책화하여 알림을 제공하거나 강제로 적용되어 미래에 동일한 이슈가 발생하지 않도록 하는데 도움이 될 수 있습니다.
더 나은 쿠버네티스 셀프 서비스
1. 환경에 대한 파악
현재 상태를 파악하는 것이 중요합니다. 아래의 질문을 통해 현황 파악이 가능합니다.
- 개발자들은 배포를 어떻게 하고 있는가
- 프로덕션은 어떤 상태인가
- 얼마나 일관된 상태인가
이런 질문에 대한 답변을 통해 필요한 정책을 정할 수 있습니다. 예를 들어, 모든 개발자가 오토 스케일링이 필요한 상황이며, 지금 현재 몇 명의 개발자가 오토 스케일링을 설정해둔 상태인지, 이를 정책으로 강제하면 얼마나 많은 개발자가 영향을 받을지 확인해야 합니다. 자동화된 감사툴을 돌려보면 개발팀이 어떤 방식으로 작업을 하는지 파악할 수 있습니다.
2. 발견된 내용을 개발 초기단계에 적용 (시프트 레프트)
1단계에서 환경에 대한 조사를 통해 다양한 이슈를 파악할 수 있습니다. 예를 들어, 개발자가 불필요하게 많은 리소스를 사용하고 있을 수도 있습니다. 오토스케일링을 적용하지 않았을 수도 있습니다. 도커 컨테이너에 보안 취약성이 포함되어 있을 수도 있습니다. 개발자에게 슬랙 메세지을 통해 개발 시 주의사항(하지 말아야 할 것들)을 알릴 수도 있습니다. 그러나 이런 방식은 한계가 있고 효율적이지도 않습니다.
CI/CD 파이프라인에 자동화된 감사툴을 적용하는 방법이 필요합니다. 모범관행과 관련된 이슈나 정책 위반에 대한 내용을 스캐닝하는 것부터 시작합니다. 초기에 스캐닝 가능한 것에는:
- Helm 차트
- 도커 이미지
- 테라폼
초기에는 개발자에게 이슈에 대해 알림을 제공합니다. 예를 들면, “신규 생성된 토커 이미지에는 10개의 취약성이 포함되어 있고, 2개는 매우 심각함” 등과 같은 메세지를 제공합니다. 시간이 지나면 플랫폼팀은 이 이슈를 차단하고 싶어합니다. 개발자가 새로운 이슈 또는 새로운 취약성을 더하는 풀 리퀘스트를 연다면 누군가의 승인 또는 이슈가 수정된 후에 통합할 수 있도록 해야 합니다.
3. 가드레일 적용
CI/CD를 우회하는 것은 쉽기 때문에, 개발팀은 머지 PR이나 kubectl, Helm 을 통해 CI/CD 과정없이 클러스터를 직접 수정할 수 있습니다. 그래서 개발팀이 CI/CD 단계에서 모범관행을 우회하지 못하도록 강제하는 정책이 필요합니다.
쿠버네티스 어드미션 컨트롤러를 통해 문제가 발생할 수 있는 이슈를 사전에 방지할 수 있습니다. 예를 들어, 어드미션 컨트롤러를 통해 메모리나 CPU 요청이 없는 자원은 거부되도록 설정할 수 있고, 이를 통해 이 문제가 다시는 프로덕션에서 발생하지 않는다는 확신을 가질 수 있습니다.
가드레일의 설정은 개발자가 의도하지 않게 문제를 만들 수 있는 잠재 요소를 제거하기 때문에 많은 플랫폼팀의 우려와는 달리 개발의 속도가 빨라집니다.
4. 피드백 전달
가드레일이 적용되면 환경에 대한 좋은 기준선이 만들어졌지만 SRE 가 환경에 대한 적절한 감사를 통해 애플리케이션의 헬스를 확인할 수 있어야 합니다. 여기서 알게된 내용을 통해 불필요한 비용이 자원에 투입되는 것은 아닌지 모니터링이 이뤄져야하며, 개발팀에 피드백을 공유해야 합니다. 팀이 보안, 안정성, 비용 효율성을 각자의 워크로드에서 직접 비교해 볼 수 있다면 플랫폼팀이 집중하는 영역이 무엇인지 쉽게 공유될 것입니다.
5. 피드백 요청
플랫폼팀의 의견을 개발팀에 전달하는 것도 중요하지만, 개발팀의 목소리를 플랫폼팀이 듣는것도 매우 중요합니다. 개발자 입장에서 제대로 되는 것과 되지 않는 것에 대해 물어보고 주기적으로 마주치는 문제가 무엇인지 파악해야 합니다. 성공적인 플랫폼을 측정하는 기준 중 하나는 개발 속도입니다. 개발자가 충분한 지원을 받고 있는지 확인해 볼 수 있는 몇 가지 질문입니다:
- 얼마나 자주 개발과정이 막히는가
- 신규 배포를 시작하는데 걸리는 시간
- 오토 스케일링 설정 변경과 같은 간단한 변경작업에 소요되는 시간
- 보안, 효율성의 관점에서 애플리케이션의 성능에 대한 개발자의 이해
개발자가 직면하는 문제를 표면화할 수 있는 창구를 만들어주는 것이 중요합니다. 그래서 피드백을 요청하는 것이 중요합니다. 쿠버네티스 셀프 서비스를 개선하려면 무엇보다 개발팀과의 소통이 개선되어야 합니다. 다시 말해서 정확한 피드백을 필요로 하는 사람에게 필요한 시점에 제공하는 것입니다.
또한 이 과정은 지속적으로 이뤄져야 하며, 한번 설정으로 완료되는 것은 아닙니다. 조직은 변하며 비즈니스 요구사항이나 컴플라이언스 표준도 변합니다. 지속적인 팀간의 소통을 통해 성공적인 셀프 서비스가 가능합니다.
