[DevOps] 내부 개발자 플랫폼 (IDP) : 조직이 더 효율적으로 일하는 방법

최근 많은 기업에서 퍼블릭 클라우드 환경에서 인프라를 구축하고, DevOps 문화를 실천하려고 노력합니다. DevOps 문화를 실천하는 방법도 여러 가지인데, 기존 일하던 방식에서 개선해야 할 점들이 보였고 이를 개선하기 위한 접근법이 여러가지 생겼습니다.

 

 

위 그림처럼, 일반적으로 온프레미스 환경에서는 다음과 같은 방식으로 업무를 진행합니다.

 

1. 주로 개발자가 인프라에 대한 변경을 요청한다.
2. 시스템 엔지니어 혹은 어드민이 변경 작업을 한다.
3. 결과를 개발자에게 전달한다.

 

서버 구매, 네트워크 연결, 데이터센터 작업 등 물리적인 작업이 필요하기 때문에 요청 기반의 업무 방식이 잘 동작하는 환경입니다.

하지만, 퍼블릭 클라우드 환경에서도 여전히 같은 방식으로 일하는 방식은 비효율적입니다. 이를 대응하기 위해 나온 대안 중 하나가 바로 내부 개발자 플랫폼(IDP) 입니다.

IDP는 기본적으로 운영 팀에서 만들고 개발팀에서 사용합니다. 운영 팀은 어떤 리소스가 어떤 환경에서 어떤 요청으로 시작되는지 지정하고, 애플리케이션 구성을 위해 기본 템플릿을 설정하고 권한을 관리합니다.

 

IDP는 5가지 핵심 구성 요소를 중심으로 구축되어야 합니다. 그 5가지에 대해 살펴 보겠습니다.

---

1. 애플리케이션 구성 관리 (Application Configuration Management)

 

IDP는 소스 코드를 관리하고 버전을 지정하는 방식(Git)과 유사한 방식으로 애플리케이션 구성을 관리할 수 있게 함으로써 애플리케이션 구성 관리의 문제를 해결합니다. 보통의 애플리케이션 구성 관리에서는. sh나. yaml 같은 파일로 구성이 되는데, 이런 파일들을 유지 관리하는 일은 까다로운 일입니다. 또, 기존과 같은 방식에서는 새로운 feature 기능 개발, QA 테스트를 위해 새 환경을 설정하려면 DevOps팀원이 일일이 참가해서 같은 유형의 작업을 반복해주어야 합니다. 이런 반복적인 일을 개선시키고 자동화하는 일이 DevOps팀의 역할 아닐까요?

 

IDP는 이를 해결하기 위해 다음과 같은 방식으로 해결합니다.

IDP를 사용하지 않는 방식

 

IDP를 통한 애플리케이션 구성 관리

Ops팀이 구조화되지 않은 매니페스트 파일을 업데이트하고 Git Repo에 저장하면 수동으로 리소스를 생성하는 방식에서,

Ops팀이 기본적인 템플릿을 설정해 놓으면, 개발팀은 간단한 CLI/API/UI를 통해 즉시 자동으로 표준 매니페스트 파일을 생성할 수 있고 개발을 진행할 수 있습니다. 작업이 완료되면 Git Repo에 저장되고 IDP가 해당 리소스를 구성하는 방식으로 개선합니다.

 

2. 인프라 오케스트레이션 (Infrastructure Orchestration)

 

DevOps팀은 새 환경이 생성될 때마다 사용될 인프라를 정의하고, CI/CD 파이프라인을 활성화하며 현재, 그리고 미래의 인프라를 오케스트레이션 할 수 있어야 합니다.

따라서 IDP는 다음과 같은 구성요소를 잘 통합해 제공해야 합니다.  먼저, CI/CD 파이프라인입니다. IDP는 파이프라인과 연결되어 원활한 CI/CD가 이뤄지도록 해야 합니다. 또한 컨테이너화 된 설정을 구조화하고 실행하는 클러스터 (일반적으로는 Kubernetes Cluster가 해당됩니다.)를 잘 제어하고 통합해야 합니다. 또한 MQ, Cache DataBase 등의 리소스들을 인프라 상에서 즉시 사용되거나 간단한 통합이 가능하도록 설계해야 하고, IaC도구를 활용해 인프라를 코드로 관리하는 것이 좋습니다.

 

3. 환경 관리 (Environment Management) 

 

사실 1번과 2번까지의 구성요소를 보면 기존 DevOps팀의 역할과 크게 다른 게 없어 보입니다. 하지만 3번이 IDP의 핵심적인 구성 요소입니다. 개발자는 IDP를 통해 필요에 따라 새로운 환경을 자체적으로 바로 개발할 수 있게 됩니다. 이는 많은 병목현상을 해결하고 더 빠른 애자일한 개발이 가능해집니다. 이 환경들은 DevOps팀에서 정의한 대로 프로비저닝 되죠.

기존의 DevOps팀이 일하는 방식은, 예를 들어 새로운 환경(핫픽스 혹은 QA)을 설정해야 할 때는 DevOps팀이 새 환경을 만들고 구설 할 때까지 개발팀은 기다려야 합니다. 이는 모든 사람들에게 귀찮은 일이고 시간적 비용이 발생합니다. IDP는 이 모든 수동 단계를 제거하고 개발자가 필요할 때마다 새로운 환경을 가동할 수 있도록 Self-Service를 가능하게 합니다.

구체적으로 IDP가 없을 때의 예시를 들어볼까요?

 

• 일반적으로 새 환경을 설정하려면 다른 팀(예: DevOps 또는 플랫폼 팀)에 연락해야 합니다. 그런 다음 다른 팀이 요청한 환경을 제공할 때까지 기다려야 합니다. 모든 것이 잘 구성되어 있으면 몇 시간이 걸릴 수 있지만 팀이 다른 우선순위에 대해 작업하는 경우 며칠 또는 몇 주가 걸릴 수도 있습니다.
• 새로운 환경을 설정하는 것이 낯설고 어려울 때, 당장 사용하지 않는 리소스들을 제거하지 않고 두는 경향이 있습니다. 새로 만들기 까다롭고 번거로우니 다시 필요할 때를 대비하여 보관하기 때문이죠. 이로 인해 리소스가 비용이 계속 나오는 상태가 됩니다.
• 필요할 때 새로운 환경을 만들 수 없다는 것은 전체적 개발 속도에 상당한 영향을 미칠 수 있습니다. 한 팀이 최대한 빨리 적용해야 하는 핫픽스를 테스트 해거나, production 하거나, QA가 테스트하기 어렵습니다. 또한 시간이 많이 걸리는 새로운 기능을 테스트하기 때문에 공유 환경이 며칠 또는 몇 주 동안 차단되는 경우를 들 수 있습니다. 이러한 환경이 차단되는 동안 다른 팀은 자체적으로 새로운 서비스나 기능을 테스트할 수 없습니다. 

IDP가 없을 때의 개발 방식

하지만 IDP는 인프라 오케스트레이션과 애플리케이션 구성 관리를 모두 환경 관리 방식으로 묶어 개발자 경험(DX)을 향상합니다.

IDP가 환경 관리를 지원하는 방식에는 다양한 요소들이 있습니다.

 

• 셀프서비스:IDP를 통해 개발자나 팀은 필요할 때마다 새로운 환경을 만들 수 있습니다. 일반적으로 기존 배포를 새 환경에 복제하여 애플리케이션 컨텍스트 내에서 새 환경을 만듭니다. 그런 다음 개발자는 필요에 따라 새로 생성된 환경을 변경할 수 있습니다(예: 새 서비스 또는 기능 분기를 테스트하기 위해). 이 모든 것은 DevOps 팀에서 제공, 유지 관리하는 인프라를 기반으로 이루어져야 합니다. IDP는 일반적으로 완전히 자동화된 환경 생성을 위해  사용자 인터페이스(UI), 명령줄 인터페이스(CLI) 또는 API를 통해 새로운 환경을 생성하는 다양한 방법을 제공합니다.
• 환경 유형: 일반적으로 IDP를 통해 DevOps 팀은 앞서 설명드린 인프라 오케스트레이션(2)을 통해 다양한 유형의 환경을 정의할 수 있습니다. 이를 통해 상황에 적합한 인프라 요구 사항(예: Dev 환경을 위한 t2.micro 머신 또는 production 환경을 위한 큰 규모의 인스턴스 설정)으로 새로운 환경이 생성됩니다.

 

4. 배포 관리 (Deployment Management)

 

IDP는 또한 팀이 CI/CD 프로세스를 구축할 수 있도록 지원합니다. 일반적으로 DevOps팀이 행하는 CI/CD와 유사하지만 IDP만의 특징이 있습니다. DevOps팀은 개발 프로세스 과정에서, 개발자는 코드 작성과 실제 테스트에만 완전히 집중하도록 도와줘야 합니다. 반복되는 작업은 가능한 한 많이 자동화되어야 하죠. IDP를 통해 이 자동화를 고도화시켜줄 수 있습니다. IDP의 일반적인 프로세스는 다음과 같습니다.

 

• Git 푸시: 개발자가 새 코드를 버전 제어 시스템에 푸시합니다. 그런 다음 새 코드는 CI 파이프라인을 따라 이미지에 빌드됩니다. CI 프로세스에는 일반적으로 코드가 잘 작성되었는지 확인하기 위한 여러 자동화 테스트도 포함됩니다. CI 프로세스가 끝나면 IDP에 새 이미지를 사용할 수 있다는 알림이 전송됩니다.
• 자동화된 배포: 새로 빌드된 이미지가 특정 환경에 배포됩니다. IDP에 정의된 규칙 셋에 따라 해당 이미지가 배포되는 환경을 조정합니다. 여기서 전체 배포 프로세스는 개발자의 추가 작업 없이 완전히 자동화되어야 합니다.
• 트리거 이후 단계: IDP는 배포 프로세스 자체를 자동화할 뿐만 아니라 각 배포 후 다음 단계 정의도 지원합니다. 배포가 성공적일 경우 다음 단계는 (a) 성공적인 배포에 대한 메시지를 개발자에게 전송(예: Slack) 하거나 (b) 새로운 환경에 대한 E2E 테스트(종단 간 테스트)를 자동으로 트리거합니다. 이외에도 IDP는 지속적인 배포를 가능하게 하는 수많은 단계를 포함하여 보다 복잡한 프로세스를 지원해야 합니다.

 

이와 같이 더 나은 DX를 제공하는 것이 배포 관리의 핵심이지만 IDP가 지원하는 또 다른 중요한 특징이 있습니다.

 

• 디버깅 지원: 만약 배포가 실패하면 어떻게 될까요? 실패한 배포를 디버깅하는 작업은 서로 다른 여러 시스템에서 원인이 있을 수 있어 시간이 많이 소요되는 작업일 수 있습니다. IDP는 전체 배포 작업에서의 가장 중요한 디버깅 정보(예: 배포 로그, 컨테이너 로그)에 대한 통합 보기를 제공합니다. 이 중앙 집중식 정보는 문제 디버깅을 위해 많은 도움을 주며 많은 시간과 골칫거리를 절약할 수 있습니다.
• 버전 관리: 내부 개발자 플랫폼은 지금까지 이루어진 모든 배포에 대한 중앙 메모리 역할을 합니다. 일반적으로 수많은 배포를 반복하는 데 필요한 모든 정보를 저장합니다. 이는 두 배포를 비교하거나 배포용 패치를 만드는 것과 같은 Git과 유사한 작업을 가능하게 합니다. 또 "어떠한 서비스의 어떤 버전이 어디에서 실행되고 있습니까?", "특정 버전의 서비스가 프로덕션으로 출시되기 전에 어떤 환경에서 배포 및 테스트되었습니까?" 등과 같은 쿼리를 날리고 원하는 정보를 얻을 수도 있습니다.

 

5. 역할 기반 액세스 제어 (Role-Based Access Control)

 

IDP를 사용할 때는 조직의 많은 팀, 사람들이 업무를 보다 효율적으로 수행하게 됩니다. 인프라를 설정하는 DevOps 팀부터, 실제 프로덕션 환경에서 새 기능을 테스트하는 제품 관리자, 새 기능을 프로덕션에 릴리스하는 책임을 맡은 엔지니어에 이르기까지. IDP를 사용하는 다양한 역할의 다양한 사람들이 생기면서 IDP의 액세스 및 권한 관리가 중요해집니다.

이를 위해 가장 널리 사용되는 접근 방식은 RBAC (역할 기반 액세스 제어, Role-Based Access Control)입니다. RBAC 접근 방식에서는 개별 직무에 대한 역할이 생성됩니다. 그런 다음 이러한 역할에 권한이 할당됩니다. 조직의 모든 사람에게는 하나 이상의 역할이 할당됩니다. 이 접근 방식은 개별 사용자에게 권한을 할당하는 것보다 훨씬 확장 가능하기에 대부분의 IDP는 역할 기반 액세스 제어를 제공합니다.

이상적인 RBAC에서 역할은 조직 역할과 애플리케이션별 역할로 분할되어야 합니다. 일반적인 조직 역할은 다음과 같습니다.

 

• Member: 팀에서 개발자의 역할을 가집니다. Member는 평상시 작업 중인 응용 프로그램에 액세스 할 수 있습니다.
• Machine: 이 역할은 다른 이름을 가질 수 있습니다. 이는 종종 인프라 통합에 사용할 수 있는 역할입니다(예: 이미지를 IDP를 푸시하는 CI 파이프라인의 경우). 엄격하게 제한된 권리를 가지고 있게 합니다.
• Manager: 엔지니어링 관리자의 역할입니다. 관리자는 일반적으로 사용자를 초대하고 팀이 담당하는 애플리케이션을 관리할 수 있습니다. 그 범위는 구현, 팀의 환경마다 다를 수 있습니다.
• Admin: DevOps 팀 또는 리드의 역할입니다. 관리자는 IDP의 전체 기능에 대한 액세스 권한을 가집니다.

 

특히 대규모 조직의 특정 요구 사항을 처리하기 위해 더 많은 역할이 있을 수 있습니다. 일반적인 애플리케이션별 역할은 다음과 같습니다.

 

• Viewer: 애플리케이션 또는 환경에 대한 읽기 전용 역할입니다.
• Contributor: 애플리케이션의 구성을 업데이트하고 새로운 환경을 생성할 수 있는 역할입니다. 이 역할은 일반적으로 위에서 언급한 Member 역할과 함께 사용됩니다.
• Owner: 전체 액세스 권한이 있는 특정 애플리케이션의 소유자 역할입니다. 일반적으로는 소유자만 애플리케이션을 삭제할 수 있습니다.

 

특히 앞서 정의한 환경 관리 수준에서 액세스를 관리하는 기능은 IDP에서 특히 중요합니다. 이를 통해 관리자는 production 환경에 대한 전체 액세스를 소수의 사람들로 제한할 수 있으며 거의 ​​모든 개발자들이 development 환경을 만들고 업데이트할 수 있습니다. 조직의 규모에 따라 회사의 디렉터리 정보 서비스(예: LDAP)에 대한 자동화된 매핑이 내부 개발자 플랫폼의 중요한 기능일 수 있습니다.

---

여기까지 IDP가 무엇이고, 5가지 핵심 구성요소를 통해 IDP를 사용해야 하는 이유에 대해 알아봤습니다. 이와 관련된 여러 서비스들이 존재하는데, Gremlin과 같은 카오스 엔지니어링 도구, Circle CI, Jenkins와 같은 CI 도구, DataDog과 Grapana와 같은 모니터링 도구들이 있습니다. 이에 대해서는 추후 포스팅을 이어나가기로 하고, 

클라우드에서도 IDP 역할을 하는 서비스들을 출시했습니다. 다음 포스팅에서는 AWS에서 IDP와 흡사한 역할을 수행 중인 AWS Service Catalog에 대해 알아보고, 실습을 진행해보도록 하겠습니다.

https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html

What Is AWS Service Catalog? - AWS Service Catalog

 

 

---

출처

• https://internaldeveloperplatform.org/
• https://blog.hubspot.com/website/configuration-management
• https://medium.com/daangn/%EB%8B%B9%EA%B7%BC%EB%A7%88%EC%BC%93-%EC%9D%B8%ED%94%84%EB%9D%BC%EC%8B%A4-%EC%83%88%EB%A1%9C%EC%9A%B4-%EB%B9%84%EC%A0%84%EC%9D%84-%EC%86%8C%EA%B0%9C-%ED%95%A9%EB%8B%88%EB%8B%A4-8f22e72d46d9