OpenCSP MVP 개발 후기 (Core + Console 프로토타입)

 

들어가며

프로젝트를 작년(25년) 11월 정도에 시작했던 것 같은데 벌써 5개월이 흘렀다.
 
처음엔 단순한 VPS 서비스를 만들어서 밥 값이라도 벌어보려고 했었는데
만들다 보니까 이것저것 추가로 필요해지기도 했고
기획도 살을 붙이다보니까 생각보다 규모가 많이 커진거 같다.
 
'VPS 만들어서 VM 제공하고 돈받자' 에서
'VM 이미지만 잘 준비해두면 AWS처럼 해줄 수 있을 것 같은데?' 가 됐고
'추상화만 잘하면 다른 사람도 사용할 수 있겠다. (프레임워크)'는 생각이 들었다.
 
그래서 여러 CSP들의 철학과 구조를 찾아봤고
각자 구성한 방법도 철학도 다르지만 공통된 조건들은 있다는 걸 알게됐다.(NIST의 클라우드 컴퓨팅 정의같은)

그걸 기준으로 내가 아는 방식대로 설계하고 만들어봤음
 
 

구성

초기엔 거의 대부분을 혼자 만들고 운영해야 할테니
기존에 있는 성능 좋은 OSS, SDK, 라이브러리 등을 최대한 사용하자고 생각했다. 
 
인프라 레벨에선 Proxmox, KVM, OpenStack 그리고 여러 하이퍼바이저들이 문제를 해결해줬고,
네트워크는 VPN(Wireguard), OVN/OVS 등 SDN과 CloudFlare가
스토리지는 인프라 노드 자체 볼륨 활용(하이퍼바이저, proxmox 등 인프라레벨에서 관리하되 스냅샷 백업만 외부)과 SeaweedFS(Object Storage)로 
멀티 테넌시(테넌트, 유저, 롤, 인증/인가, 로그인 등)는 Zitadel, 리소스 접근과 감사는 Teleport가
프로비저닝의 멱등성과 프로바이더는 Terraform과 Ansible이 해결해줬다.
(IaC, GitOps, 모니터링과 관측가능성, 보안, 빌링 등도 있지만 생략)
 

 
그리고 대부분의 1인이 가진 여유 인프라는 많아봐야 적당한 성능의 데스크탑 1~2대 정도일거라고 생각했다. (내 기준)
 
그래서 위에 모든 서비스들은 최대한 적은 리소스만 사용해서 동작해야 했고,
동시에 큰 규모의 인프라를 가진 사용자들이나 고가용성을 원하는 사용자를 위해서 확장도 가능해야했기 때문에 쿠버네티스에 모든 서비스를 배포했다. 
 
여기까지는 OpenCSP의 Core (https://github.com/h001-lab/OpenCSP-core) 에 대한 고민이었고
 
위에 모든 서비스들을 엮어서 하나로 동작하게 만들기 위해 Console이 필요해졌는데,
문제는 저 중에 하나라도 서비스가 deprecated 되거나 라이선스, 정책 등이 변경된다면
OpenCSP가 제대로 동작하기 어려워질테니 대부분의 연동 코드를 facade 구조로 설계해야 했다. (MVP에선 위에 구성된 도구들에 대해서만 구현되어서 다른 도구와의 연동은 검증되지 않음)
 
어차피 오픈소스로 만들면서 코드를 다 공개하고 있으니까
OpenCSP를 프레임워크처럼 사용해서 자체 클라우드 서비스(Public/ Private 또는 IDP)를 만들고 싶은 사용자들을 위해서,
그리고 각 레이어의 Scale-out을 위해서 FE(Front-end), BE(Back-end)를 분리해뒀고 (BE API만 사용하고 FE는 자체 개발이나 수정? -> Zitadel login 같은 패턴)
그래서 BE를 stateless하게 만들려고 최대한 고민해보긴 했다. (이 부분도 아직 검증되진 않음)
 
UI/ UX에도 고민이 좀 있었는데, AWS의 Dogfooding과 GCP 콘솔의 디자인 같은게 섞인걸 원했지만
1인이나 소규모 인원이 운영한다고 생각하면 다른 상용 솔루션 제품들처럼 별도의 Admin 페이지가 있는게 편할거 같았다.
그리고 i18n과 DB 기반 configuration 등을 지원해줘야 운영 편의성과 사용자 경험이 좋아질거 같았음
(i18n은 json 구조에서 키를 읽어서 UI에 보여주는 방식이므로 파일만 별도로 배포해두고 수정하면 console을 재시작하지 않고 수정이 가능)
 

언어별 json 파일만 추가해주면 다국어 지원됨

 
 
그리고 Console은 아래 그림처럼 Core 내부에 배포해주는게 보안/ 네트워크/ CICD 등에서 유리하다고 생각했다.
근데 개발은 서로 분리된 상태에서 했기때문에 Core와 Console을 별도로 구성 가능하다. (이 경우 각 서비스에 접근 가능한 외부 엔드포인트가 필요)

 
리소스의 프로비저닝과 연결은 아래처럼 가능한 상태고 (자세한 건 https://miiml.tistory.com/18 참고)

리소스 생성 및 프로비저닝(텔레포트 연결) 완료 상태

 

상세 페이지

연결 클릭 시

 

웹 콘솔

 

Terminal

 
리소스에 대한 연결은 텔레포트를 거쳐서 웹 콘솔과 console에서 제공하는 install 스크립트를 통해 로컬에서도 ssh 연결이 가능하다. (아직 인증 직접해야하는 문제는 있음)
 
웹 콘솔의 경우는 tbot 기반 자동 인증서 갱신 로직이 있기때문에 언제 연결해도 작동하긴 하고,
terminal 컴포넌트에 자체 명령어 버퍼와 터미널 모드 감지 기능이 있기때문에 (vi 등 상호작용? 모드 같은거) 사용자 입장에선 지연이 적다고 느낄만 한거 같다.
 

위에 모든 사용자 행위는 이미지처럼 Teleport의 Audit 과 Session Recordings에 남는다.

 
 
Billing은 아직 별 기능이 없지만 몇가지 메트릭으로 간단한 기능들만 테스트했다. (나중엔 이벤트 단위 리스트 필터링, 검색 등과 테넌트별 메트릭 기반 quota limits 같은게 들어가야됨)

 
 

구현된 기능과 아쉬운 점 

현재까지 구현된 기능은 https://miiml.tistory.com/19 에서 적었던 Basic 1단계의 아래 부분들은 다 어느정도 기본 틀은 잡힌거 같다. 
 

• Core 연동 부분 
  • Provisioning Flow (FE -> BE -> Terraform -> Ansible)
  • PAM (Teleport) 인증 및 SSH 릴레이
  • IAM (Zitadel) 서비스 기반 중앙 인증 및 사용자 데이터 연동
  • Billing 파이프라인(Lago) 연동 및 메트릭 가시화 페이지 개발
• Console UI/UX 및 백엔드 구조 부분
  • 싱글 테넌트 단위 UI 및 기능 개발 및 사용자 단위 리소스 격리 (2단계에서 고도화)
  • 직관적인 UI와 UX
    • 적은 레이턴시/화면 리프레시, 프로비저닝 진행 상황 모니터링, Dynamic Configuration(Integrations) 등
  • 각 영역의 다른 오픈소스 서비스 연동이 고려된 백엔드 구조 (파사드 패턴)
  • MSA 구조에서 데이터 안정성 및 백업/복구 정책 및 방법 구상
• CI/CD 파이프라인 구성
  • github OCI로 helm chart와 버전별 컨테이너를 Core 인프라 내부에 배포
• 도메인 구매 후 서비스 오픈 

 
아쉬운 부분들도 많은데 (다음 단계에서 해야되는 것들을 제외하고)
 
우선 운영자 입장에서 보면 컨테이너/ 패키지 버전 관리와 여러 서비스들의 의존성에 대한 관리 부담이 여전히 너무 많고 (1인 기준) 그것들에 대한 공급망 보안이 고려되지 않았다는 점인 거 같다.
 
(Harbor/Nexus 같은 내부 레지스트리와 Trivy 같은 걸 추가하면 어느정도 가능 하겠지만 OpenCSP에서 다룰 영역이 아니라고 생각했다 -> Core에서 사용자 환경에 맞게 커스텀)
 
그리고 들어간 기술이나 패턴, 툴은 많은데 아직 뽑아낸 플로우들이 적고 대시보드 같은 UI 퀄리티와 컴포넌트가 부족하다는 점과
 
전체적인 구조가 EDA가 아닌 API 연동 기반이고 별도의 API GW가 없어서 트래픽 처리의 한계값이 있다는 점이다. (물론 현재 규모에선 Scale-out으로 충분할거 같긴하고, 다음 단계에서 Temporal-NATS 를 도입해서 해결되면 좋을 듯)
 

다음 단계에서 해야되는 건

우선 테넌트 단위 격리, 네트워크 가상화, 클러스터/노드 오케스트레이션 같은 클라우드에서 핵심적인 기능들이 우선순위가 높고,
다음은 Temporal-NATS 로 사용자 요청을 이벤트 기반으로 처리 (이 경우 BE가 NATS 에 쌓인 이벤트를 병렬로 소비하고 그중 프로비저닝 같은 Transactional 이벤트들은 Temporal에 정의된 액션으로 처리 후 NATS를 통해 각 액션의 상태를 구독 받는 플로우)
 
그리고 여러 클라우드 이미지를 packer로 미리 만들어서 seaweed에 올려두고 위의 프로비저닝 로직을 활용해서
Managed services 배포하거나 인스턴스 타입들을 추가해주면 어느정도 사용 가능한 콘솔이 만들어 질 거 같다.
(이 때 teleport agent 같은게 들어 있는 이미지도 만들어주면 프로비저닝도 빨라짐)
 
추가로 아래에 있는 기능들도 제공해주면 좋을 거 같다.

• 사용자 인프라 조합을 미리 정의해서 사용하기
  • 이건 개발자를 위한 기능인데 Docker Compose 또는 Terraform Module 같은걸 opencsp-modules에 올려두고 불러와 사용하는 형태로 (한번에 외부 노출할 수 있는 3티어 인프라 구성 등) IDP에 가까워 질 수 있는 기능들이다
• admin > integraitions에 PG연동 UI 및 기능 추가
  • 티어, 플랜, 메트릭 같은 미터링과 빌링 기능은 lago가 해주고, 실제 청구는 사용자가 직접 연동하는 구조
• Core에 otel-collector gw 파드 추가
  • 나중에 obserbavility node 와 연동하기 편해지고, 별도의 모니터링 스택이 있으면 바로 연동이 가능함

 
위에 만든 것들을 우선 기존에 사용하던 도메인으로 배포해뒀다. 
(임시 도메인이므로 작성은 따로 하지 않고 아래 Console 레포지토리 우측 상단 링크에 남겨뒀음)

• https://github.com/h001-lab/OpenCSP-console