플랫폼 엔지니어링의 모든 것

플랫폼 엔지니어링이 존재하는 이유

과잉 일반화 늪 (Over-General Swamp)

클라우드와 OSS가 큐, 오브젝트 스토어, 데이터베이스, CI 러너, 서비스 메시 등 무한한 프리미티브를 제공하면서 각 애플리케이션 팀이 서로 다른 선택을 하게 됨

모든 서비스가 자체 배포 파이프라인, 재시도 로직, 모니터링 관례, 미묘하게 잘못된 IAM 바인딩을 갖는 "글루 코드의 늪"으로 변질

 

 

플랫폼 엔지니어링이 실제로하는 네 가지

개발자가 보는 프리미티브를 제한하여 큐레이션된 방식으로만 사용하도록 유도

반복적 배관 작업을 공유 서비스로 흡수해 애플리케이션 별 글루 코드를 감소

기반 프리미티브 변경 시 플랫폼 팀이 한 번만 처리하여 마이그레이션 비용을 중앙화

개발자가 리눅스 커널 전문가가 되지 않고도 자신이 만든 것을 직접 운영할 수 있도록 지원

DevOps는 "개발자가 운영을 소유하라" 였고, 플랫폼 엔지니어링은 "그 운영을 위한 좋은 도구를 실제 제품으로 제공하겠다"는 것

 

 

 

 

다섯가지 기둥

큐레이션된 제품 접근 (Curated Prodect Approach)

플랫폼이 지원하는 것과 지원하지 않는 것을 의도를 가지고 결정

팀이 원하는 것을 거절하는 것도 업무의 일부

 

 

소프트웨어 기반 추상화 (Software-Based Abstractions)

플랫폼은 위키가 아닌 소프트웨어이며, 인터페이스는 API, CLI, SDK

개발자가 작은 선언적 파일을 작성하는 것만으로 프로덕션급 서비스를 프로비저닝 할 수 있어야함

CNCF 산하 Score 프로젝트가 대표적 사례

워크로드 스펙 하나로 데이터베이스, 토픽, 서비스 계정, 배포를 자동 프로비저닝

(개발자는 내부적으로 Cloud SQL, Pub/Sub, Cloud Run인지 알 필요 없음)

 

 

OSS 커스터마이징과 메타데이터 레지스트리

바닐라 Argo CD나 Backstate를 그대로 쓰지않고, 조직에 맞는 플러그인, 기본 정책, 통합을 적용해 운영

메타데이터 레지스트리 (서비스 카탈로그)가 없으면 누가 무엇을 소유하고, 의존 관계가 어떻고, 실제 무엇이 실행 중인지 파악 불가

Backstage가 이 레이어의 사실상 표준 OSS 프레임워크로, 270개 이상 프로덕션에서 운영

 

 

광범위한 사용자 기반 서비스

내부 플랫폼은 소수의 매우 목소리 큰 고객을 보유하지만, 중간 값 개발자의 중간 값 작업을 잘 지원하는 것이 목적

엘리트 사용자만을 위해 구축하면 나머지 팀이 플랫폼을 우회하면서 섀도우 플랫폼이 탄생

 

 

파운데이션으로 운영

플랫폼이 다운되면 회사가 다운되므로, 24/7 온콜, 실제 SLO, 실제 변경 관리, 지원 부담이 수반

"도구"가 아닌 "바닥" 역할이며, 위에 구축되는 모든 것이 바닥이 견딘다고 가정

 

 

 

 

 

시작 시기와 방법

플랫폼 팀을 너무 일찍 만들지 말 것

엔지니어 10명 규모에서는 플랫폼 팀이 아닌 협력이 필요

(한 명이 배포 스크립트, 다른 한명이 테라폼을 관리하고, 관례에 합의하면 충분)

 

 

기존 인프라 조직 전환

인프라/SRE 팀을 플랫폼 조직으로 전환할 때 가장 어려운 부분은 기술이 아닌 문화

인프라 담당자는 "안된다"의 게이트키퍼 역할이지만, 플랫폼 담당자는 "쉬운 예스를 제공하는 사람"이 되어야함

PM을 위에 뿌리고 끝내는 것이 가장 흔한 실패 모드이며, 이는 플랫폼이 아닌 연극을 만들어냄

 

 

 

 

 

플랫폼 팀 구축

네 가지 역할

소프트웨어 집중이 과하면 아름다운 포털이 실제 부하에서 무너지고, 시스템 집중이 과하면 견고한 클러스터를 아무도 티켓 없이 사용 불가

 

- Software Engineer

API, SDK, 포털 등 플랫폼의 제품 표면 구축

 

- Systems Engineer

쿠버네티스, 리눅스, 네트워킹, 클라우드 컨트롤 플래인 등 기반 프리미티브에 정통

 

- Reliability Engineer

운영 품질, 온콜, SLO, 관측성에 집중

 

- Systems Specialist

데이터베이스, 보안, 네트워킹 등 깊은 도메인 전문가

 

 

채용

고객 공감을 최우선으로 채용해야함

좌절한 앱 개발자와 통화 후 문제를 명확히 이해하고 나올 수 없는 엔지니어는 적합하지 않음

공감 없는 기술적 탁월함은 정확하지만 아무도 쓰지 못하는 플랫폼을 만들어냄

소프트웨어 역할에는 동일한 레벨 매트릭스를 쓰되, 시스템 스페셜리스트는 시장 가치와 스킬이 소프트웨어 엔지니어 래더에 깔끔하게 매핑되지 않으므로 유연한 직함 적용

 

 

관리자 및 기타 역할

- 훌륭한 플랫폼 엔지니어링 관리자의 세 가지 공통 특성

> 실제 플랫폼 운영 경험

> 장기 멀티 쿼터 프로젝트 배포 경험

> 디테일에 대한 집착

 

PM, 테크니컬 라이터, 개발자 애드보킷, 지원 엔지니어 모두 중요하지만 엔지니어링 팀이 충분히 성숙한 후에 채용

 

 

 

 

 

실제 우선순위

1순위

지원 범위를 결정하고 문서화하며 방어

 

2순위

위키가 아닌 소프트웨어 추상화에 투자 (Score, Crossplane, 자체 SDK 등 실제 API가 있는 소프트웨어)

 

3순위

메타데이터 레지스트리 구축 (Backstage 등으로 무엇이 어디서 실행되고 누가 소유하는지 파악)

 

4순위

가장 시끄러운 팀이 아닌 중간값 팀을 위해 구축

 

5순위

SLO, 온콜, 지원 티어 등 운영을 일급 기능으로 취급

 

6순위

시스템 역량만큼 공감 능력을 기준으로 채용

 

7순위

격주 성과·도전, 투명한 로드맵, 솔직한 이해관계자 관리 등 무자비한 소통

 

8순위

필요 없는 것을 종료, 통합, 거절

 

 

 

 

 

 

 

Reference

https://news.hada.io/topic?id=29603

플랫폼 엔지니어링의 모든 것: 왜 필요하고, 어떻게 구축하며, 성공은 어떤 모습인가 | GeekNews