DevOps 플랫폼 구축기

• DevOps 플랫폼 소개
  ・ 왜 플랫폼이 필요한가요?
  ┗ Self Service
  ┗ 일관된 사용자 경험
  ・ 웹 포털을 제공하자
  ・ Why BackStage?
  ┗ 플러그인 아키텍처
  ┗ API Proxy

• 이런 걸 하고 있습니다
  ・ OAS 문서 포털
  ┗ Background
  ┗ OpenAPI 문서 공유 자동화하기
  ・ Deploy Center
  ・ 무한 확장성

• 마치며

• Ref.

  
  

안녕하세요 쿼타랩의 DevOps 엔지니어 김철현입니다.

현재 쿼타랩 DevOps 챕터는 제품팀의 생산성을 끌어올리기 위해 사내 플랫폼을 구축하고 있는데요.

플랫폼을 구축하면서 어떤 문제를 해결하고자 했는지, 어떻게 구축해나가고 있는지 공유하려고 합니다.

DevOps 플랫폼 소개

왜 플랫폼이 필요한가요?

CNCF 플랫폼 백서를 읽어보셨나요?

쿼타랩 DevOps 챕터는 플랫폼 백서에서 언급하는 플랫폼이 제공하는 가치를 구현하기 위해 열심히 DevOps 플랫폼을 구축하고 있는데요. 쿼타랩의 DevOps 챕터가 그중에서 어떤 가치를 중요시하고 왜 플랫폼을 구축하게 되었는지 소개하려고 합니다.

Self Service

제품팀의 엔지니어들은 애플리케이션을 테스트하고 배포하기 위해서 새로운 인프라를 프로비저닝하고 배포 파이프라인을 구축해야 하는데요. 보통 제품팀 엔지니어들은 이러한 작업들을 DevOps팀에 요청하게 되고, 이후 DevOps 엔지니어가 이 작업을 완료할 때까지 대기해야 한다는 비효율이 발생합니다.

만약 DevOps 엔지니어가 다른 업무를 수행하느라 제품팀의 요청을 빠르게 처리하지 못한다면 그만큼 업무의 병목이 발생하고 결과적으로 정해진 일정에 차질이 생기게 되기 때문에 DevOps 챕터는 제품팀의 엔지니어들이 언제 어디서든 테스트 환경이 필요하면 쉽고 빠르게 테스트 환경을 생성하여 병목없이 빠르게 서비스를 개발할 수 있는 환경을 제공해야 합니다.

DevOps 엔지니어들은 클라우드 인프라를 프로비저닝하고 데이터베이스나 스토리지를 생성하여 제공하는 등 다양한 업무를 수행하다 보니 항상 많은 컨텍스트를 동시에 다루기 때문에 작업 효율이 떨어지거나 휴먼 에러가 발생하는 등의 문제가 발생하거나 혹은 Ops의 늪에 빠져 더 중요한 업무를 처리하지 못하는 상황이 발생하기도 합니다.

이러한 문제를 해결할 수 있는 방법 중 하나는 Self-Service를 제공하는 것입니다. Self-Service는 사용자가 원하는 서비스를 언제든 요청하고 제공받을 수 있도록 하는 환경을 의미합니다. Self-Service를 통해 운영 업무를 자동화한다면 Ops의 늪에서 벗어나 더 중요한 업무에 집중할 수 있고 휴먼 에러를 줄일 수 있습니다.

이렇게 DevOps 플랫폼을 통해 인프라를 프로비저닝하고 애플리케이션을 배포하는 등 많은 작업을 자동화하여 얻을 수 있는 가치들을 추구하는 것, 그것이 바로 쿼타랩 DevOps 챕터가 중요시하는 가치입니다.

쿼타랩의 코어 밸류인 Speed & Quality와도 일맥상통하는 부분이죠.

일관된 사용자 경험

엔지니어들을 위한 Self-Service를 제공하는 방법은 다양합니다. 요즘 많이 도입되고 있는 GitOps나 CLI 도구를 이용하여 제공할 수도 있고 웹 포털을 통해 제공할 수도 있습니다.

만약 인프라에서 제공하는 도구가 파편화되어 알아야 할 도구의 수가 수십 가지가 된다면 어떨까요?

제품팀 엔지니어들은 각 도구의 사용법부터 Best Practice까지 학습해야 하기 때문에 학습 부하가 발생하게 되고 제품 개발에 집중할 시간이 줄어들어 생산성이 저하될 것입니다. 특히 신규 입사자는 온보딩을 진행하면서 팀에서 사용하는 도구들을 익히게 되는데 도구가 너무 많으면 파악하는 데 시간이 오래 걸리고 각 도구별로 어떤 문서를 확인해야 하는지 혼란스러울 것입니다.

그래서 DevOps 엔지니어들은 인프라나 배포 파이프라인 등 엔지니어링 조직이 사용하는 모든 도구들을 통합하여 제품팀 엔지니어들에게 일관된 사용자 경험을 제공해야 합니다. 제품팀 엔지니어들은 일관된 사용자 경험을 제공받으면 도구를 학습하는데 사용하는 시간과 비용을 줄여 개발에 집중할 수 있기 때문입니다.

웹 포털을 제공하자

앞서 언급한 바와 같이 개발팀에서 사용하는 도구가 다양해지고 파편화되면 그에 비례해서 학습 비용이 증가합니다. 그만큼 중요한 비즈니스 feature를 개발하는 데 집중하기 어렵다는 것을 뜻하기도 하는데요.

쿼타랩 DevOps 챕터는 이 문제를 해결하기 위해 애플리케이션 배포, 문서 공유, 인프라 생성 등의 요청을 하나의 인터페이스로 처리할 수 있는 웹 포털을 제공하여 개발자들이 이러한 학습 비용을 지불하지 않고도 편하게 인프라에 접근할 수 있도록 지원하고 있습니다.

하지만 쿼타랩 DevOps 챕터에는 FE 기술에 익숙한 엔지니어가 없었기 때문에 가급적이면 FE 학습을 최소화할 수 있는 기술을 선택하여 도입 비용을 줄이기 위해 다음의 선택지를 두고 고민했습니다.

1. FE 프레임워크를 학습하여 직접 개발한다

2. 노코드 도구를 이용해 개발한다

3. FE 챕터에 도움을 요청한다

4. BackStage를 이용한다

많은 고민 끝에 쿼타랩 DevOps 챕터는 Spotify에서 공개한 오픈소스인 BackStage를 선택하여 웹 포털을 개발하기로 결정했습니다.

Why BackStage?

출처: CNCF BackStage

BackStage는 Spotify에서 공개한 개발자 통합 오픈소스이고 현재는 CNCF에 편입된 프로젝트이며, 팀 내에서 사용 중인 모든 서비스 카탈로그나 컴포넌트, SaaS 제품, 기술 문서 등을 한곳에 모아 관리할 수 있는 웹 포털을 제공해주는 솔루션입니다.

소프트웨어의 복잡도는 비즈니스의 성장과 비례하기 때문에, 빠르게 성장하는 비즈니스를 경험하는 개발자들은 점점 더 소프트웨어의 구조를 파악하는 것이 어려워집니다.

또한 소프트웨어의 구조가 복잡할수록 이를 설명하는 조직 내 문서도 많아지기 때문에 개발자가 제대로 개발하기 위해 읽고 기억해야 할 정보의 양도 많아지죠.

그래서 쿼타랩 DevOps 챕터는 엔지니어들이 모든 소프트웨어의 구조를 한 번에 파악할 수 있고 필요한 기술 문서나 도구들을 한 곳에서 관리할 수 있는 웹 포털을 BackStage를 통해 구축하기로 했습니다.

BackStage는 웹 포털에 Component나 API 등의 서비스 카탈로그의 정보와 각 서비스 카탈로그 간 관계를 파악할 수 있는 다이어그램 등을 렌더링해주어 쉽게 파악할 수 있도록 해줍니다. 또 자체 Market Place를 갖추고 있어서 많이 사용되고 있는 Kubernetes, Jenkins, Argo CD 등을 지원하는 플러그인들이 제공되고 있고 필요한 경우는 직접 구현해서 사용할 수 있습니다.

플러그인 아키텍처

BackStage는 필요한 기능이 있다면 언제든 커스텀 플러그인을 추가할 수 있는 기능을 제공합니다. 뿐만 아니라 React의 Material UI 기반으로 구현된 컴포넌트를 재사용할 수 있도록 제공하여 간단한 코드 수정만으로도 자체 컴포넌트를 생성할 수 있도록 지원하고 있습니다.

위의 코드처럼 BackStage가 제공하는 @backstage/core-plugin-api와 컴포넌트를 이용하면 쉽게 플러그인을 구현하여 기능을 추가할 수 있고, 해당 패키지는 이미 잘 갖춰진 컴포넌트를 제공하기 때문에 잘 조합한다면 React에 대한 깊은 이해 없이도 좋은 인터페이스를 제공할 수 있습니다.

바로 이 플러그인 아키텍처가 BackStage를 채택하게 된 결정적인 이유였습니다.

API Proxy

BackStage는 API proxy를 통해 BackStage에서 제공하는 Backend가 아닌 별도의 API 서버를 구현하여 proxy 서버로 등록할 수 있는 기능을 제공합니다. 이를 통해 BackStage Frontend 입장에서는 단 하나의 호스트로 다양한 API 서버들을 사용할 수 있다는 장점을 가져갈 수 있죠.

간단한 config 설정만으로 proxy 기능을 사용할 수 있습니다. 한번 아래 예시를 볼까요?

위의 예시처럼 proxy 필드에 원하는 Backend 서버의 엔드포인트를 추가해주면 BackStage의 proxy 서버로 등록할 수 있습니다.

이렇게 proxy 서버에 등록하고 나면 BackStage의 Backend 서버 Host에 /api/proxy/{PROXY_NAME} 경로로 API를 호출하면 원하는 서버로 라우팅됩니다.

이후 Frontend에서는 등록한 엔드포인트로 API를 호출하기만 하면 됩니다.

이렇게 BackStage에서 제공하는 API proxy를 통해 기능을 추가할 때 굳이 Express 기반 BackStage의 Backend를 이용하지 않아도 원하는 언어와 프레임워크를 선택하여 구현할 수 있다는 장점이 있습니다.

결과적으로 BackStage는 사용자 인터페이스만을 위한 용도로 사용하고 서비스 API 서버를 Source Of Truth로 사용하여 BackStage에 대한 의존성과 결합도를 줄이고 마음껏 기능 확장을 할 수 있게 되었습니다.

이런 걸 하고 있습니다

OAS 문서 포털

Background

현재 쿼타랩 제품팀은 빠르게 feature를 개발하고 엔지니어들 간 병목을 줄이기 위해 OpenAPI 스펙 문서를 먼저 공유한 후에 개발을 시작하고 있습니다.

그동안 제품팀의 BE들은 API 문서를 제공하기 위해서 Swagger 프레임워크를 이용해서 작성해왔습니다. 물론 Swagger 프레임워크는 간편하게 문서를 생성하고 공유할 수 있다는 장점이 있지만, 문서를 작성하기 위해서는 Dummy API를 먼저 작성한 후 개발 서버에 배포해야 하기 때문에 만약 API 스펙이 수정되는 경우에는 다시 빌드한 후 배포해야 하는 번거로움 또한 가지고 있습니다.

이러한 문제를 해결하기 위해 가장 먼저 시도했던 것은 OpenAPI를 json이나 yaml 형식으로 작성하여 FE에게 전달하는 것이었습니다. 이후 FE는 전달받은 json 파일을 IDE나 외부 사이트에서 제공하는 OpenAPI Viewer를 통해 문서를 확인하는 과정을 거칩니다.

하지만 이 방법은 여러 명의 개발자가 같은 문서를 공유하려는 경우 문서를 소유한 개발자가 직접 상대방에게 전달해주어야 하기 때문에 문서의 공유가 어렵고, 문서 원본에 대한 관리가 쉽지 않다는 단점이 있습니다.

또한 API 스펙이 변경되면 해당 문서를 이용 중인 모든 엔지니어들에게 매번 다시 갱신된 문서를 전달해야 하기 때문에 커뮤니케이션 비용이 지속적으로 지출됩니다.

BackStage는 이러한 문제점들을 시원하게 해결해줍니다.

BackStage는 OpenAPI 스펙에 맞는 yaml 파일을 다운로드할 수 있는 경로를 등록해두기만 하면 바로 웹 포털에서 API 문서를 확인할 수 있는 기능을 제공합니다.

BackStage를 사용하는 유저들은 이 기능을 통해 변경된 스펙을 즉시 또는 주기적으로 확인할 수 있기 때문에 별도의 파일을 전달하는 과정 없이 변경된 스펙을 바로 확인할 수 있습니다.

또한 API와 서비스 컴포넌트 간의 관계를 쉽게 파악할 수 있는 다이어그램을 렌더할 수 있는 React 컴포넌트도 제공하기 때문에, 이처럼 Swagger에 비해 더 강력한 기능들을 사용하여 개발자들의 생산성을 폭발적으로 증가시킬 수 있습니다.

OpenAPI 문서 공유 자동화하기

앞서 언급한 바와 같이 BackStage는 엔티티의 스펙을 yaml 파일로 작성하여 원격저장소에 올려놓고 해당 파일의 URL을 등록해주면 자동으로 문서를 파싱하고 포털에 렌더링하는 기능을 제공하고 있습니다.

원격저장소를 활용한다는 장점으로 인해 개발자들은 Git을 사용하여 API 문서를 쉽게 등록하고 관리할 수 있습니다.

하지만 여기에는 한 가지 단점도 존재하는데요. GitOps를 통해 문서를 관리하기 위해서는 문서를 작성하는 개발자가 직접 BackStage 엔티티 스펙을 학습해야 하기 때문에 의도치 않은 학습 부하가 발생한다는 점입니다.

이러한 문제를 해결하기 위해 DevOps 플랫폼은 BackStage 엔티티를 생성하기 위한 yaml 파일을 작성하고 파일을 다운로드할 수 있는 경로를 등록하는 기능을 제공합니다.

따라서 BE는 openapi.json 파일만 작성하고 생성된 웹 포털 링크만 FE에게 전달하면 되기 때문에 API 문서 등록 과정을 자동화할 수 있습니다.

DevOps 플랫폼을 통해 OpenAPI 스펙 문서를 등록하는 프로세스는 다음과 같습니다.

1. BE가 feature 브랜치를 생성한 후에 OpenAPI를 json 형식으로 작성한다

2. openapi.json 파일 작성이 완료되면 원격 브랜치에 푸시한다

3. Github Action은 푸시 이벤트를 감지하여 Workflow를 실행하고 DevOps 플랫폼 서버에 openapi.json을 등록한다

4. DevOps 플랫폼 서버는 openapi.json을 저장하고 BackStage에 yaml 파일의 다운로드 경로를 등록한다

BackStage에 경로를 등록하면 BackStage의 Backend는 등록된 경로로 API를 호출하여 API 스펙 문서를 다운로드하기 때문에 Controller를 구현해주어여 합니다.

다음은 API 스펙 문서를 다운로드할 수 있는 API의 코드입니다.

BackStage가 위의 API를 정상적으로 호출하면 웹 포털에서 API 스펙 문서를 확인할 수 있게 됩니다. 문서가 등록된 것을 확인하면 BE는 Backstage API 문서의 링크를 FE에게 전달하여 OpenAPI 스펙 문서를 기반으로 개발을 시작할 수 있게 됩니다.

이렇게 구축된 프로세스를 통해 BE는 openapi.json만 작성하여 푸시하면 FE에게 공유하기 위한 과정은 모두 자동화되기 때문에 매번 FE에게 기술 문서를 전달해주지 않아도 되고 문서를 생성하기 위해 빌드를 수행할 필요도 없습니다. 만약 API 스펙이 변경되더라도 json 파일만 수정해서 다시 푸시하면 문서가 자동으로 갱신되기 때문에 부담없이 수정할 수 있게 됩니다.

또 FE는 링크를 전달받지 못하더라도 API 문서의 이름은 서비스와 브랜치의 이름을 기반으로 생성되기 때문에 문서를 검색해서 찾아볼 수 있어 문서가 변경되었다는 사실만 알면 리프레시하여 변경된 문서를 바로 확인할 수 있기 때문에 업무 간 커뮤니케이션 비용을 최소화할 수 있습니다.

Deploy Center

제품팀 엔지니어들은 feature를 개발한 후 feature 환경을 생성하여 배포한 후 테스트 및 QA를 진행하고 있습니다. 쿼타랩은 Helm Chart를 구성하여 GitOps 기반 ArgoCD를 이용하여 애플리케이션을 배포하고 있습니다.

엔지니어들은 애플리케이션을 배포하려면 Chart에 입력한 values 파일에 필요한 설정값들을 입력하고 Vault에 secret을 입력해야 하고, DB가 필요한 경우에는 DevOps 챕터에 요청하여 DevOps 엔지니어가 프로비저닝한 후 접속 정보를 제공해줄 때까지 기다려야 합니다.

하지만 제품팀 엔지니어들이 쿠버네티스나 Helm에 익숙하지 않은 경우에는 DevOps 엔지니어가 애플리케이션에 필요한 설정값들을 입력하고 배포를 진행해야 합니다. 즉, 배포 파이프라인에서 사용하는 도구에 익숙하지 않은 개발자는 DevOps 엔지니어의 도움 없이는 feature 환경을 생성할 수 없기 때문에 feature가 정상적으로 동작하는지 테스트하지 못하고 결과적으로 작업이 지연되게 됩니다.

또 DevOps 엔지니어는 feature 환경의 개수가 늘어나면 관리 포인트도 함께 늘어나기 때문에 Ops의 늪에 빠지게 되어 다른 업무를 처리하기 힘들어지게 됩니다.

이럴 때 필요한 건 역시 자동화입니다..!

DevOps 챕터는 제품팀 엔지니어들이 언제든 필요하면 스스로 배포 환경을 생성하여 테스트나 QA를 진행할 수 있고 작업이 완료되면 다시 삭제할 수 있도록 Self-Service를 제공하기 위해 Deploy Center를 개발하고 있습니다. 여기서 중요한 포인트는 DevOps 엔지니어의 도움 없이 개발자가 필요한 배포 환경을 생성할 수 있도록 한다는 것입니다.

현재 개발을 진행중인 Deploy Center는 웹 포털에서 배포 환경을 생성할 수 있는 입력폼을 제공하는 UI 컴포넌트와 Github Action이나 ArgoCD와 연동하여 배포 프로세스를 실행하는 플랫폼 서버의 API로 구성될 예정입니다.

DevOps 챕터는 곧 Deploy Center를 제품팀에게 제공할 예정입니다.

추후 포스팅을 통해 Deploy Center에 대한 자세한 내용을 공유하도록 하겠습니다.

무한 확장성

현재 쿼타랩 DevOps 챕터가 구현하고 있는 기능 외에 BackStage를 통해 확장이 가능한 영역은 무궁무진합니다. 아래의 기능들은 바로 시도해볼 수 있는 기능입니다.

1. 권한 관리

2. DB 유저 관리

3. Kafka 토픽 관리

4. 인프라 비용 관리

5. 자산 관리 등

   
   

쿼타랩 DevOps 챕터는 플랫폼에 어떤 기능을 추가할지 아이디어를 도출하고 있는데요. 대표적인 예로 권한 관리 시스템이 있습니다.

BackStage가 제공하는 인증 시스템을 이용하면 외부 프로바이더의 SSO를 연동할 수도 있고 자체 인증을 이용할 수 있으며 BackStage의 인증 시스템을 통해 발급받은 JWT를 proxy 엔드포인트로 등록된 서버에 전달해줄 수 있기 때문에 별도의 인증을 구현하지 않고 권한 관리 시스템을 구현할 수 있습니다.

아래와 같이 BackStage의 config 파일에 Authorization 헤더를 추가해주면 발급받은 JWT를 서버로 전달해줄 수 있습니다.

이렇게 전달받은 JWT를 이용하여 사용자의 정보를 식별하여 권한을 부여하여 접근을 제어할 수 있는 시스템을 구현할 계획중입니다.

앞서 언급한 기능 외에도 BackStage를 통해 확장할 수 있는 기능은 이 글을 읽고 계신 여러분의 상상에 따라 더 많아질 수 있습니다. 핵심은 BackStage에서 제공하는 기능과 UI 컴포넌트를 잘 이용하면 원하는 기능을 마음껏 확장할 수 있다는 것입니다.

사내 웹 포털을 고민중이라면 BackStage를 통해 원하는 기능을 구현하여 사용해보는 걸 추천드립니다.

마치며

쿼타랩의 DevOps 챕터는 플랫폼을 통해 10x 생산성을 가질 수 있는 조직을 만드는 것이 목표입니다. 반복 작업을 자동화하고 더 나은 개발환경을 제공하여 엔지니어들이 비즈니스 feature를 개발하는 데 집중할 수 있도록 더 좋은 경험을 만들기 위해 노력하고 있습니다.

더 좋은 경험을 제공하기 위해서는 React나 Spring과 같은 익숙치 않은 프레임워크를 학습해야 할 때도 있는데요. 목표를 이룰 수 있다면 주저하지 않고 빠르게 학습하여 도입하고 있습니다.

아직은 많은 서비스를 제공하고 있진 않지만, 더 확장하여 재밌는 내용을 공유할 것을 약속하며 글을 마치도록 하겠습니다. 읽어주셔서 감사합니다.

Ref

• [1] CNCF BackStage

• [2] BackStage 공식문서

벤처금융 인프라를 함께 만들어 나갈 동료를 찾습니다.
쿼타랩 채용 바로가기