10. 플랫폼 엔지니어링을 읽으며 남기는 기록들

용어 정리

• 플랫폼이란
  • foundation. 토대
  • 애플리케이션 팀들은 플랫폼을 활용하여 팀 간 조정비용을 줄이고, 더 빠른 속도로 제품 기능을 딜리버리 할 수 있음.
• 플랫폼 엔지니어링이란
  • 애플리케이션 개발자층을 위한 소프트웨어 기반 추상화로서의 플랫폼을 개발하고, 이를 비즈니스의 토대로 운영하는 큐레이션 제품 접근방식을 통해 목표 달성.
• 레버리지
  • 플랫폼 엔지니어링의 핵심가치는 레버리지 개념에 있음.
  • 요 맥락에서의 레버리지는, 소수의 플랫폼 팀 엔지니어들의 작업이 조직 전체의 업무를 줄여주는 것을 의미.
• 제품
  • 플랫폼을 하나의 제품으로 보는 것이 중요하다.
  • 플랫폼을 매력적인 제품으로 개발한다 = 플랫폼의 기능을 결정할 때, 고객 중심적인 접근 방식을 취한다는 것.
• snowflake decision
  • 소프트웨어 개발,시스템 관리에서 어떤 고유하고 독특한 상황에 대한 임시적인 해결책을 의미한다.
  • 마치 눈송이 처럼 각각 결정이 서로 다르고 예측 불가능하다는 의미.

과도한 일반화의 늪

• 늘어난 primitive 계층
  • primitive 계층은, 광범위한 기능을 제공하지만 서로 통합되어있지 않은 범용 구성요소들.
  • 이들이 제대로 동작하려면 접착제(glue)가 필요하다.
    • 접착제란, 통합 코드, 일회성 자동화, 구성, 관리 도구 등등.
  • 이 접착제는 모든걸 하나로 묶어주지만, 동시에 미래 변경을 매우 어렵게 만드는 끈적임의 원인이 된다.
• 접착제가 확산되며, 과도한 일반화의 늪이 만들어진다.
  • 애플리케이션 팀들은 primitive 의 배열에서 애플리케이션을 빠르게 구축할 수 있는 것들을 택하는데, 이 중에서도 최신기능을 선호함.
  • 전달을 서두르는 마음에서, 팀은 그런것들을 하나로 묶는 맞춤형 접착제를 만들어냄.
  • 이 과정이 반복되며 아키텍쳐는 복잡해진다.
• 시간이 지나면서 이 끈적이는 혼란을 변경하기가 대단히 어려워짐.
  • 접착제가 도처에 퍼져있으므로, 기본요소들의 사소한 업데이트도 광범위한 조직차원의 엔지니어링 시간을 필요로한다.
• '접착제의 양을 제한하기' -> 상자는 늘리고, 연결선은 줄인다. (more boxes, lower lines)
  • OSS와 벤더의 선택을 조직의 필요에 맞게 제한된 집합으로 추상화하고, 강력한 의 견을 제공하여 관심사 분리를 가능하게 하기.
• 플랫폼은, 추상화와 캡슐화의 개념을 구현하고, 사용자를 바탕(underlying) 복잡성으로부터 보호하는 인터페이스를 구축하여 필요한 접착제의 양을 제한한다.

애플리케이션 개발자의 자체 운영권한

• 성숙한 데브옵스의 목표는 "만든 사람이 소유한다."라는 접근방식으로, 책임소재를 단순화 하는것.
• 바탕 시스템의 운영 복잡성 대부분을 플랫폼 추상화 뒤로 숨기면, 그러한 복잡성을 플랫폼 팀이 소유하고 관리하는 것이 가능해진다.
  • 이를 위해서는 지원하는 옵션을 제한해야한다.
  • 그래야 추상화 경계선(abstraction boundary)을 핵심 서비스 집합으로 상향 이동 할 수 잇으며, 각 서비스는 광범위한 애플리케이션 유즈케이스를 처리할 수 있다.
• 또한, 플랫폼 팀 내에서 높은 운영 표준을 유지하여 애플리케이션 팀이 안심하고 의존할 수 있도록 하는 것도 중요하다.

플랫폼 엔지니어링 기둥 1- 큐레이션 제품 접근 방식

• 제품 접근방식
  • 개발자들이 순수하게 기술적인 사고방식에서 벗어나, 고객이 시스템에 대해 원하는 바와 시스템을 사용하는 경험에 초점을 맞추는 것
• 큐레이션
  • 특정한 상호작용 패턴과 사용 규칙이 존재할 뿐 아니라, 이 플랫폼의 범위에 무엇이 포함/제외 되는지에 대한 나름의 관점을 가지고 그에 따라 제공 사항을 엄선한다는 것
• 왜 이 두가지가 다 필요할까?
  • 큐레이션이 없는 제품 접근방식은 고객 대응력이 뛰어나지만 일관된 전략이 없어 팀이 단순한 서비스 센터로 전락됨.
  • 제품을 고려하지 않고 큐레이션만 강조되면, 팀의 실제 요구를 충족시키지 못하는 경직된 서비스가 된다.

포장도로

• 일반적인 다중 시스템 작업흐름의 복잡성을 숨겨서, 애플리케이션 팀이 작업흐름을 편하게 따르게 만드는데서 온다.
• 사용성 측면의 지원활동.
• 파레토 원칙을 따라, 피료의 80%를 충족시키는 20%용례를 찾아내고, 그 20%가 매우 잘 작동하도록 하기.
• 애플리케이션 팀의 예외적인 요구사항은 거절.
  • 포장도로이지 강제된 서비스가 아니므로.
  • 특수한 요구사항이 있는 팀은 언제든지 도로에서 벗어나도록.

철도

• 기존 제품으로는 해결되지 않지만 여러 애플리케이션 팀에게 필요한, 유의미한 틈을 발견한 경우에 적합.
• 애플리케이션 팀들의 공통된 요구사항 패턴을 찾고, 팀들이 이러한 플랫폼의 부재를 어떻게 해결하고 있는지 조사하는 제품 발견 과정의 결과물.

메타데이터 레지스트리 통합

• 플랫폼 엔지니어링의 핵심
• 플랫폼 엔지니어링이 주는 기회중 하나는, 바탕 OSS/클라우드 기본요소의 문제점과 변경을 플랫폼이 사용자 대신 다룰 수 있다는 점.
  • 하지만, 이를 위해 각 기본 요소가 어디에 어떻게 쓰이는지, 누가 쓰는지 추론할 수 있게하는 메타데이터가 필요하다.
• 답해야할 질문들
  • 소유권 - 누가 이 서비스의 소유자?
  • 접근제어 - 이 서비스가 이 블롭 저장소 버킷에 그렇게 광범위한 접근권한을 가져야하나?
  • 비용 효율성 - 비용을 어느조직에 청구?
  • 마이그레이션 - 누구랑 이야기해야함?
• 플랫폼이 이러한 레지스트리와 얼마나 잘 통합되어, 메타데이터를 지속적으로 자동 캡쳐하고 레이블링할 수 있는가가 핵심.

플랫폼 엔지니어링 기둥 2

셀프서비스 - 사용자 관측성 (user observability)

• 개발자가 플랫폼을 이용하여 어플리케이션을 개발/운영하는 전체 수명주기 동안, 개발자 스스로 문제를 디버깅할수있도록 원격 측정 기능을 구축해야한다.
• 우리가 플랫폼 팀에 요구사는 목표 중 하나는, 플랫폼 사용자가 자신의 실수인지 플랫폼 문제인지 구분할 수 있어야한다는 것.

셀프서비스 - 가드레일

• 모든 사용자가 바탕 시스템에 통달하리라고 기대할 수 없다. 특히, 보안/규정준수/안정성/비용통제와 같은 세부사항에서.
• 따라서 가드레일 구현이 플랫폼 구축의 중요한 일부가 된다.

셀프서비스 - 멀티테넌트

• 플랫폼이 멀티테넌트를 지원해야한다.
• 즉, 동일한 런타임 구성요소 내에서 서로 다른 애플리케이션을 돌릴 수 있어야만 효율적이라는 것.
• 엔지니어링 시간의 경제적 효율성 확보.
• 즉, 애플리케이션별로 하나의 시스템을 운영하는게 아니라, 중앙 팀이 여러 애플리케이션을 지원하는 공유시스템을 제공하는 것.

플랫폼 엔지니어링 기둥 3 비즈니스 토대(foundation)로서 운영하기

• 플랫폼은 애플리케이션 엔지니어가 자신의 비즈니스를 믿고 맡길 수 있는 튼튼한 토대가 되어야함.
• 토대로 작용하려면 아래와 같은 세가지가 필요함

1. 플랫폼 엔지니어링 팀이 전체 플랫폼에 대한 운영책임을 지는것
2. 플랫폼 지원을 보장하는 것
3. 운영 실무에서 규율을 지키는 것