Kubernetes - 서비스 카탈로그와 서비스 브로커

☁️ 서비스 카탈로그와 서비스 브로커?

---

클라우드 네이티브 환경이 발전하면서 다양한 서비스의 프로비저닝, 관리, 연결은 점점 더 복잡해지고 있다. 이러한 복잡성을 해결하고 개발 생산성을 향상시키기 위해 서비스 카탈로그와 서비스 브로커라는 개념이 등장했으며, 이들은 Open Service Broker API (OSB API)라는 표준을 통해 상호작용한다. 이번에는 핵심 개념과 구현 방안에 대해서 다뤄보고자 한다.

📜 Open Service Broker API - 클라우드 서비스 자동화의 표준 프로토콜

---

OSB API

Open Service Broker API (OSB API)는 클라우드 플랫폼(예: 쿠버네티스, Cloud Foundry)과 외부 서비스 제공자 간의 통신을 위한 표준 규약이다. 마치 레스토랑에서 웨이터가 고객의 주문을 받아 주방에 전달하고, 완성된 요리를 고객에게 가져다주는 표준화된 절차와 유사하다. OSB API는 이러한 서비스 제공 과정을 자동화하고 일관성 있게 만들어, 개발자가 다양한 백엔드 서비스를 애플리케이션에 손쉽게 통합할 수 있도록 지원한다.

주요 특징 및 이점

OSB API는 RESTful API 형태로 정의되며, 서비스의 생성, 삭제, 연결, 연결 해제 등의 작업을 표준화된 방식으로 처리한다.

• 표준화된 인터페이스: 다양한 클라우드 환경과 서비스 제공자 간의 일관된 통합 방식을 제공한다.
• 자동화된 프로비저닝: 개발자는 OSB API를 통해 AWS RDS 데이터베이스, Google Cloud Storage, 메시지 큐 등과 같은 외부 서비스를 자신의 애플리케이션에 몇 가지 명령이나 클릭만으로 자동으로 연결하고 프로비저닝할 수 있다. 예를 들어, 쿠버네티스 클러스터에서 MySQL 데이터베이스 인스턴스를 생성 요청 시, OSB API를 구현한 서비스 브로커는 인스턴스 크기, 저장 공간, 접속 정보 설정 등을 자동으로 처리한다.
• 플랫폼 확장성: 클라우드 플랫폼은 OSB API를 통해 새로운 서비스를 쉽게 추가하고 관리할 수 있다.

OSB API의 역사

OSB API는 2015년 Cloud Foundry 커뮤니티에서 시작되었다. 이후 그 중요성과 유용성을 인정받아 현재는 레드햇(Red Hat), 구글(Google), IBM, SAP, Pivotal 등 주요 클라우드 기술 기업들이 참여하는 워킹 그룹에 의해 공동으로 개발되고 유지보수되고 있다. 이는 특정 벤더에 종속되지 않는 개방형 표준으로 자리매김했다.

🛒 서비스 카탈로그

서비스 카탈로그의 개념과 역할

서비스 카탈로그는 기업이나 조직 내에서 사용 가능하도록 승인된 클라우드 서비스들의 목록을 체계적으로 정리해 놓은 일종의 디지털 메뉴판이다. 대형 마트의 식품 코너가 다양한 제품을 카테고리별로 진열하여 고객이 쉽게 선택할 수 있도록 하는 것처럼, IT 부서는 서비스 카탈로그를 통해 개발자가 선택할 수 있는 표준화되고 승인된 서비스(예: 특정 규격의 가상 머신(VM) 인스턴스, 보안 설정이 완료된 관리형 데이터베이스, 메시징 큐 등)를 제공한다.

서비스 카탈로그의 실제 활용 예시

• AWS Service Catalog: 관리자는 AWS CloudFormation 템플릿을 사용하여 "금융 거래 분석용 고성능 MySQL 8.0 - 1TB 스토리지, 일일 자동 백업"과 같은 표준화된 제품을 정의할 수 있다. 개발자는 이 정의된 제품을 서비스 카탈로그에서 검색하여 클릭 몇 번으로 자신의 프로젝트 환경에 즉시 배포할 수 있다.
• Google Cloud Platform Service Catalog: Google Cloud에서는 배포 가능한 솔루션(예: LAMP 스택, 특정 데이터베이스 구성)을 서비스 카탈로그를 통해 폴더 및 프로젝트 수준에서 관리한다. 또한, 조직 정책(Organization Policies)과 연동하여 특정 서비스 사용에 대한 규정 준수를 강제하고 보안 가이드라인을 적용할 수 있다.

서비스 카탈로그 도입의 효과

서비스 카탈로그를 도입하면 다음과 같은 다양한 이점을 얻을 수 있다.

• 개발 속도 향상: 신입 개발자도 복잡한 인프라 구성 과정이나 내부 승인 절차 없이, 이미 정의된 표준 서비스를 사용하여 3분 이내에 필요한 테스트 환경이나 개발 환경을 신속하게 구축할 수 있다.
• 표준화 및 거버넌스 강화: IT 부서는 승인된 서비스만을 제공함으로써 기업의 보안 정책, 컴플라이언스 요구사항을 준수하고, 일관된 인프라 관리를 가능하게 한다.
• 비용 관리 및 최적화: 사전에 정의된 서비스 옵션(예: 인스턴스 크기, 스토리지 타입)을 통해 불필요한 고비용 리소스 사용을 방지하고, 리소스 사용 현황을 추적하여 비용을 효율적으로 관리할 수 있다.

👨 서비스 브로커

서비스 브로커의 정의와 기능

서비스 브로커는 앞서 설명한 Open Service Broker API(OSB API)를 실제로 구현한 소프트웨어 컴포넌트다. 서비스 카탈로그가 '무엇을 사용할 수 있는지'를 보여주는 메뉴판이라면, 서비스 브로커는 그 메뉴에서 선택된 항목을 실제로 '어떻게 제공하고 관리할지'를 처리하는 디지털 웨이터 또는 중개자 역할을 수행한다. 레스토랑에서 고객이 메뉴(서비스 카탈로그)를 보고 원하는 음식(서비스)을 선택하면, 웨이터(서비스 브로커)가 주방(실제 서비스 제공 시스템)에 주문을 전달하고, 조리가 완료되면 음식을 고객에게 가져다주는 것과 같다.

서비스 브로커의 작동 방식

개발자가 서비스 카탈로그를 통해 특정 서비스를 요청하면(예: "새로운 PostgreSQL 데이터베이스 인스턴스 생성"), 이 요청은 해당 서비스와 연결된 서비스 브로커에게 전달된다. 서비스 브로커는 이 요청을 받아 실제 클라우드 환경에서 해당 리소스를 생성, 구성, 관리하고, 완료되면 접속 정보 등을 다시 플랫폼을 통해 개발자에게 전달한다.

예를 들어, IBM Cloud의 서비스 브로커는 사용자가 카탈로그에서 서비스를 선택하면, 해당 서비스의 프로비저닝뿐만 아니라 자동으로 관련 메트릭 추적 시스템과 연동되어 사용량 모니터링 기능을 제공한다. 또한, Red Hat과 AWS가 공동으로 개발한 AWS Service Broker는 OpenShift 플랫폼에서 AWS 서비스를 손쉽게 사용할 수 있도록 지원한다. 개발자가 OpenShift 내에서 S3 버킷 생성을 요청하면, 이 브로커는 IAM 역할 자동 설정, 접근 키 발급, 보안 그룹 구성 등 복잡한 백엔드 작업을 자동으로 처리한다.

서비스 브로커의 핵심 API 엔드포인트

OSB API 사양에 따라 서비스 브로커는 최소한 다음과 같은 핵심 API 엔드포인트를 구현해야 한다.

1. GET /v2/catalog: 브로커가 제공하는 모든 서비스와 플랜의 목록(카탈로그 정보)을 반환한다.
2. PUT /v2/service_instances/{instance_id}: 명시된 ID로 새로운 서비스 인스턴스를 프로비저닝(생성)한다.
3. GET /v2/service_instances/{instance_id}/last_operation: 프로비저닝, 업데이트, 디프로비저닝과 같은 비동기 작업의 현재 상태를 조회한다.
4. DELETE /v2/service_instances/{instance_id}: 명시된 서비스 인스턴스를 디프로비저닝(삭제)한다.
5. PUT /v2/service_instances/{instance_id}/service_bindings/{binding_id}: 애플리케이션이 서비스 인스턴스를 사용할 수 있도록 바인딩(연결)하고, 필요한 자격 증명(credentials)을 생성한다.
6. DELETE /v2/service_instances/{instance_id}/service_bindings/{binding_id}: 기존 서비스 바인딩을 제거한다.
7. (선택 사항) PATCH /v2/service_instances/{instance_id}: 기존 서비스 인스턴스의 속성(예: 플랜)을 업데이트한다.

🛍️ 적용 사례 예시

---

여기서 이해를 돕도록 예시를 들어보고자 한다. 한 빠르게 성장하는 전자상거래 기업이 신규 기능들을 더 신속하게 배포하고, 인프라 관리의 복잡성을 줄이기 위해 서비스 카탈로그와 서비스 브로커를 도입하기로 결정했다. 특히, 결제 처리 시스템을 위한 안정적이고 확장 가능한 데이터베이스 환경 구축이 시급한 과제였다.

문제 상황 및 도입 배경

• 새로운 데이터베이스 인스턴스 생성 및 구성에 평균 2~3일 소요.
• 개발팀마다 서로 다른 방식으로 데이터베이스를 설정하여 일관성 및 보안 표준 준수 어려움.
• 인프라팀의 업무 부담 가중 및 병목 현상 발생.

서비스 카탈로그 및 브로커를 통한 해결 과정

이 기업은 서비스 카탈로그에 "결제 처리용 고가용성 PostgreSQL 클러스터 (v14, 200GB SSD, 자동 백업)"라는 표준 서비스를 등록했다. 개발팀이 카탈로그에서 해당 서비스를 선택하면 다음과 같은 과정이 자동으로 진행된다.

1. 서비스 등록 및 선택: IT 운영팀은 사전에 정의된 보안 및 성능 기준을 만족하는 PostgreSQL 클러스터 구성을 서비스 카탈로그에 "제품"으로 등록한다. 개발팀은 웹 기반 카탈로그 포털에서 이 서비스를 선택하고 필요한 기본 정보(예: 애플리케이션 이름)만 입력한다.
2. 자동화된 프로비저닝:
   • 요청을 받은 서비스 브로커는 OSB API를 통해 백엔드 클라우드 플랫폼(예: AWS, Azure, GCP 또는 사내 프라이빗 클라우드)에 3개의 노드로 구성된 PostgreSQL 클러스터 프로비저닝을 요청한다.
   • 자동으로 전용 Virtual Private Cloud (VPC) 서브넷 구성, 데이터 암호화를 위한 SSL/TLS 인증서 생성 및 적용, 매일 특정 시간에 실행되는 자동 백업 스케줄을 설정한다.
   • 필요한 방화벽 규칙과 네트워크 접근 제어 목록(ACL)도 표준 정책에 따라 구성된다.
3. 애플리케이션 연동: 프로비저닝이 완료되면(보통 수 분 내), 서비스 브로커는 생성된 데이터베이스의 주소, 포트, 사용자 이름, 암호 등의 연결 정보를 안전한 방식으로(예: 쿠버네티스 시크릿 형태) 해당 서비스를 요청한 애플리케이션 환경(예: 쿠버네티스 파드)에 자동으로 전달한다.
4. 모니터링 및 관리: 생성된 PostgreSQL 클러스터는 즉시 중앙 모니터링 시스템(예: Prometheus, Datadog)과 연동되어 CPU 사용률, 메모리 사용량, 디스크 I/O, 활성 연결 수 등의 주요 지표를 실시간으로 추적한다. 또한, 월별 리소스 사용량 기반의 비용 보고서가 자동으로 생성되어 관련 부서에 전달된다.

도입 결과 및 성과

• 배포 시간 단축: 개발자는 과거 며칠씩 걸리던 프로덕션급 데이터베이스 배포를 단 15분 만에 완료할 수 있게 되었다.
• 보안 및 표준 준수: 보안팀은 모든 데이터베이스 인스턴스에 표준화된 암호화 정책(예: 저장 데이터 암호화, 전송 중 데이터 암호화)과 접근 제어 정책이 예외 없이 자동 적용됨을 확인할 수 있었다.
• 운영 효율성 증대: 서비스 브로커는 주기적으로 PostgreSQL의 마이너 버전 패치를 검사하여 운영팀의 승인 하에 자동으로 업데이트를 수행한다. 또한, 특정 기간(예: 30일) 동안 사용되지 않는 테스트용 인스턴스는 알림 후 자동으로 삭제되어 리소스 낭비를 방지한다.

🛠️ Spring Cloud Open Service Broker

---

앞서 언급했듯이, 서비스 브로커를 처음부터 구현하는 것은 OSB API 명세의 모든 세부 사항을 정확히 따라야 하므로 상당한 시간과 노력이 필요하다. Spring Cloud Open Service Broker는 Spring Boot 애플리케이션으로 OSB API를 준수하는 서비스 브로커를 보다 쉽게 개발할 수 있도록 도와주는 프레임워크다. 이 프레임워크는 OSB API의 각 엔드포인트에 대한 요청/응답 모델 객체, 컨트롤러 로직의 기본 구조 등을 제공하여 개발자가 실제 서비스 프로비저닝 로직에 집중할 수 있도록 한다.

기본 구현 개념

Spring Cloud Open Service Broker를 사용하여 서비스 브로커를 개발하는 것은 주로 다음과 같은 인터페이스들을 구현하는 것을 포함한다.

• CatalogService: /v2/catalog 엔드포인트 로직을 구현하여 브로커가 제공하는 서비스 및 플랜 정보를 반환한다.
• ServiceInstanceService: 서비스 인스턴스 생성 (createServiceInstance), 업데이트 (updateServiceInstance), 삭제 (deleteServiceInstance), 마지막 작업 상태 조회 (getLastOperation) 등의 로직을 구현한다.
• ServiceInstanceBindingService: 서비스 바인딩 생성 (createServiceInstanceBinding), 삭제 (deleteServiceInstanceBinding) 로직을 구현한다.

다음은 ServiceInstanceService의 일부를 구현하는 간략한 개념 코드 예시다.

import org.springframework.cloud.servicebroker.model.instance.*;
import org.springframework.cloud.servicebroker.service.ServiceInstanceService;
import org.springframework.stereotype.Service;
import reactor.core.publisher.Mono; // Spring WebFlux를 사용하는 경우 Reactor 타입 사용

@Service
public class MyDemoServiceInstanceService implements ServiceInstanceService {

    @Override
    public Mono<CreateServiceInstanceResponse> createServiceInstance(CreateServiceInstanceRequest request) {
        String instanceId = request.getServiceInstanceId();
        String serviceDefinitionId = request.getServiceDefinitionId();
        String planId = request.getPlanId();

        // 여기에 실제 서비스 프로비저닝 로직 구현
        // 예: 외부 클라우드 API 호출하여 DB 생성, 내부 시스템에 리소스 할당 등
        System.out.println("Creating service instance: " + instanceId + 
                           " for service: " + serviceDefinitionId + 
                           " with plan: " + planId);

        // 비동기 프로비저닝인 경우 accepted(true) 설정 가능
        // boolean asyncAccepted = true; 
        // return Mono.just(CreateServiceInstanceResponse.builder()
        //        .async(asyncAccepted) // 비동기 처리 여부
        //        .operation("provisioning-" + instanceId) // 비동기 작업 식별자
        //        .dashboardUrl("http://example-dashboard.com/" + instanceId)
        //        .build());

        // 동기 프로비저닝 완료 시
        return Mono.just(CreateServiceInstanceResponse.builder()
                .instanceExisted(false) // 이미 존재하는 인스턴스가 아닌 경우 false
                .build());
    }

    @Override
    public Mono<DeleteServiceInstanceResponse> deleteServiceInstance(DeleteServiceInstanceRequest request) {
        String instanceId = request.getServiceInstanceId();

        // 여기에 실제 서비스 디프로비저닝 로직 구현
        System.out.println("Deleting service instance: " + instanceId);

        return Mono.just(DeleteServiceInstanceResponse.builder().build());
    }

    // updateServiceInstance, getLastOperation 등의 메소드도 필요에 따라 구현
}

이처럼 Spring Cloud Open Service Broker는 복잡한 OSB API 명세를 추상화하여 개발자가 비즈니스 로직에 더 집중할 수 있게 해준다.

아래는 해당 라이브러리의 클래스 모음이다.

자체 구현의 어려움

만약 프레임워크 없이 OSB API 명세 전체를 직접 구현하려고 한다면, 각 API 엔드포인트의 정확한 HTTP 메소드, 경로, 요청/응답 본문 형식, 상태 코드, 에러 처리, 비동기 작업 처리 방식 등을 모두 고려해야 한다. 이는 상당한 개발 시간을 소요하게 되므로, 대부분의 경우 Spring Cloud Open Service Broker와 같은 기존 프레임워크를 활용하거나, 클라우드 플랫폼에서 제공하는 SDK를 사용하는 것이 효율적이다. 시간은 언제나 한정돼 있으므로 중요도가 크지 않은 부분은 단축할 필요가 있다.