[OpenStack 기반 CSP 구축 #5] RCP 요구사항 정의와 백엔드 설계

Об этом предложении

OpenStack을 구축하고 VM 생성과 SSH 접속까지 확인했다. 다음 단계는 이 기능을 사용자가 이용할 수 있는 서비스로 제공하는 것이었다. RCP(Return Cloud Platform)는 사용자가 OpenStack의 개별 리소스를 직접 구성하지 않아도 VM을 생성하고 접속할 수 있도록 만드는 서비스다. 이를 위해 OpenStack 앞단에 별도의 백엔드를 두고, 사용자 인증과 리소스 소유 관계, VM 생성·삭제 요청을 관리하기로 했다. 이번 글에서는 초기 요구사항과 기술 스택, 데이터 모델, API 구조를 정리한다. 1. RCP 백엔드의 역할 OpenStack에서 VM을 생성하려면 Image, Flavor, Network, Security Group, Key Pair, Project 등 여러 리소스를 지정해야 한다. 외부 접속을 제공하려면 Floating IP와 네트워크 접근 규칙도 구성해야 한다. RCP에서는 이 중 서비스가 공통으로 결정할 설정을 백엔드에서 처리하고, 사용자는 필요한 사양을 선택하는 데 집중하도록 설계했다. 초기에 정의한 사용 흐름은 다음과 같다. 로그인 ↓ VM 사양 선택 ↓ VM 생성 요청 ↓ 생성 상태 확인 ↓ 접속 정보 확인 및 SSH 접속 사용자는 RCP API를 호출하고, RCP 백엔드가 내부적으로 OpenStack API를 호출한다. 사용자 │ RCP Frontend │ RCP Backend API ── PostgreSQL │ OpenStack API │ Nova / Neutron / Glance 등 역할은 다음과 같이 나누었다. 구분 역할 RCP 사용자 인증, 요청 권한 확인, 사용자와 리소스의 관계 관리, 서비스 API 제공 OpenStack VM과 네트워크 등 인프라 리소스의 생성 및 관리 Horizon에서 제공하는 기능을 모두 구현하기보다는, RCP의 사용 흐름에 필요한 기능부터 제공하는 방향으로 범위를 정했다. 2. 초기 기능 요구사항 VM 생성과 삭제 초기 구현 범위는 VM의 기본적인 생명주기 관리로 제한했다. 기능 요구사항 VM 생성 사용자가 선택한 사양으로 인스턴스 생성 VM 삭제 사용자가 소유한 인스턴스 삭제 접속 정보 제공 생성된 VM에 접근할 수 있는 주소 제공 SSH 접속 TCP 22번 포트 접근 규칙과 SSH 인증 수단 구성 VM이 생성되는 것과 사용자가 접속할 수 있는 것은 별개의 조건이다. 따라서 생성 기능에는 네트워크 연결과 접속 정보 제공까지 포함했다. 사용자 인증과 인가 초기 인증 요구사항은 회원가입과 로그인이었다. 개발 초기에는 Google OAuth2 기반 로그인부터 구현하기 시작했다. 초기 대상 사용자는 경희대학교 내부 사용자였기 때문에, 이후 학교 구성원 여부를 확인하는 방식도 검토하기로 했다. OpenStack 인증 정보는 백엔드에서만 관리하고, 사용자는 RCP의 인증 체계를 통해 요청하도록 했다. 또한 로그인 여부와 리소스에 대한 권한은 구분해야 한다. VM 조회나 삭제 요청을 처리할 때는 해당 인스턴스가 요청한 사용자의 소유인지 확인하는 구조가 필요했다. 3. 리소스 제한과 사용 기록 초기 클러스터는 동아리방의 물리 서버 몇 대로 구성되어 있었다. 사용자의 VM 생성 요청을 제한 없이 처리할 수 있는 환경은 아니었다. 따라서 VM 생성 요청을 처리하기 전에 클러스터의 자원 상황을 확인하고, 서비스에서 허용하는 범위 안에서 요청을 받아야 했다. 주요 관리 대상은 다음과 같다. CPU 메모리 스토리지 클러스터 전체의 가용 자원과 사용자별 할당 한도는 구분해서 관리할 필요가 있었다. 전체 자원이 남아 있더라도 특정 사용자가 대부분을 점유하지 않도록 제한할 수 있어야 하기 때문이다. 또한 인스턴스의 생성 시점과 사용 시간을 기록하는 요구사항을 포함했다. 정보 활용 목적 인스턴스 생성 시점 리소스 생성 이력 관리 인스턴스 사용 시간 사용 기간 확인 및 향후 과금 기준 검토 할당된 리소스 사용자별 자원 할당량 관리 Quota와 Billing은 초기 구현 범위에 모두 포함하기보다, 이후 확장할 수 있도록 필요한 데이터를 정의하는 수준에서 고려했다. 4. 백엔드 기술 스택 백엔드는 Go, 데이터베이스는 PostgreSQL, ORM은 ent를 사용하기로 했다. 기술 용도 Go RCP API 서버 구현 PostgreSQL 사용자와 서비스 리소스 정보 저장 ent 데이터 스키마와 DB 접근 코드 관리 OpenStack API 인프라 리소스 제어 Google OAuth2 초기 로그인 연동 Go를 선택한 이유는 API 서버뿐 아니라 이후 검토하고 있던 네트워크 기능과도 연결하기 좋다고 판단했기 때문이다. 당시 추가 가능성을 고려한 기능은 SSH Relay, WebSocket, 각종 인프라 API 연동 등이었다. 단일 바이너리 형태로 배포할 수 있다는 점도 선택에 영향을 주었다. 이 기능들을 처음부터 모두 구현한 것은 아니며, 초기에는 인증과 VM 관리 API를 중심으로 개발 범위를 잡았다. 5. OpenStack과 서비스 DB의 데이터 구분 데이터 모델을 설계하면서 먼저 정해야 했던 것은 OpenStack이 관리하는 정보와 RCP가 관리하는 정보의 경계였다. 인스턴스 자체는 Nova에 존재하지만, RCP에는 별도로 관리해야 할 정보가 있다. 어떤 사용자가 생성한 인스턴스인지 RCP에서 언제 생성 요청을 했는지 서비스에서 어떤 상태로 관리하는지 사용자에게 어떤 접속 정보를 제공하는지 따라서 OpenStack 리소스 ID를 RCP 데이터베이스에 저장하고, 이를 사용자와 서비스 정보에 연결하기로 했다. RCP 사용자 │ RCP 인스턴스 정보 │ OpenStack 인스턴스 ID │ Nova 인스턴스 이렇게 하면 RCP 사용자와 OpenStack 인스턴스의 소유 관계를 관리하면서, 실제 리소스를 조회하거나 삭제할 때 OpenStack ID를 사용할 수 있다. 초기 엔티티 구성 초기 ERD에는 다음 엔티티를 포함했다. 엔티티 설계 목적 User RCP 사용자 정보 관리 Instance 사용자 소유 관계와 OpenStack 인스턴스 연결 Flavor VM 사양 정보 관리 Image VM 생성에 사용할 이미지 정보 관리 Security Group 인스턴스 접근 규칙과의 연결 Network 인스턴스 네트워크와의 연결 관계를 단순화하면 다음과 같다. 아래 구조는 연결 대상을 설명하기 위한 개념도이며, 관계의 상세한 카디널리티를 표현한 것은 아니다. User │ └── Instance ├── Flavor ├── Image ├── Security Group └── Network 인스턴스와 관련해 저장을 검토한 식별자 및 접속 정보는 다음과 같다. instance_id flavor_id security_group_id network_id internal_ip external_access_domain 이 구조는 초기 설계안으로, 실제 개발 과정에서 변경되었다. OpenStack의 데이터 모델 전체를 복제하기보다는 사용자 서비스에 필요한 관계와 정보를 먼저 정의하는 데 목적이 있었다. 📷 사진 삽입: ERDCloud 초기 ERD 6. OpenStack 인증 정보 관리 초기 RCP 백엔드는 관리자 자격 증명을 이용해 OpenStack API에 접근하는 방식으로 구성했다. OpenStack API를 호출하기 위해서는 먼저 Keystone 인증을 거쳐야 한다. CLI에서는 다음과 같이 관리자 환경을 불러왔다. source /etc/kolla/admin-openrc.sh 백엔드에서는 필요한 인증 설정을 환경 변수로 전달하도록 했다. 아래는 인증 정보 형식을 설명하기 위한 일부 예시다. OS_AUTH_URL=https://api.example.com/v3 OS_USERNAME=admin OS_PASSWORD=<REDACTED> OpenStack 비밀번호와 OAuth Client Secret 같은 값은 저장소에 커밋하지 않고, 로컬 개발 환경의 .env 또는 배포 환경의 Secret Store로 관리하도록 구성했다. 공개 저장소에는 실제 값을 제외한 설정 예시만 제공한다. .env 를 사용하는 경우에도 해당 파일이 Git 추적 대상에 포함되지 않도록 해야 한다. 사용자는 이 인증 정보를 전달받지 않는다. RCP 백엔드가 사용자 요청의 권한을 확인한 뒤 OpenStack API를 호출하는 구조다. 7. API 경로 규칙 프론트엔드와 백엔드를 함께 개발하기 위해 API 경로의 공통 규칙도 정했다. 기본 접두사는 다음과 같다. /api/v1 그 아래에 인증과 인스턴스 관련 경로를 구분했다. /api/v1/auth/... /api/v1/instances/... 리소스 중심으로 경로를 구성하고, 버전 접두사를 두어 향후 호환되지 않는 변경이 필요할 때 별도 버전으로 제공할 수 있도록 했다. /api/v1/... /api/v2/... 버전 경로를 나누는 것만으로 호환성이 보장되는 것은 아니다. 기존 클라이언트가 사용하는 요청과 응답 형식을 유지하는 정책도 함께 필요하다. 8. 초기 설계의 범위 이번 단계에서는 OpenStack의 VM 생성 기능을 RCP의 사용자 흐름과 연결하는 데 필요한 구조를 정의했다. 핵심은 다음 세 가지였다. 사용자에게 필요한 VM 생성·삭제·접속 기능을 우선 제공한다. 사용자 소유 관계와 서비스 정보는 RCP에서 관리하고, 실제 인프라 리소스는 OpenStack API로 제어한다. 제한된 물리 자원을 고려해 리소스 제한과 사용 기록을 설계에 포함한다. SSH Relay, Billing, 학교 인증 등은 이후 확장 대상으로 남겨두었다. 초기에는 인증, 인스턴스 관리, 데이터베이스 연동을 중심으로 구현을 진행하기로 했다. 다음 글: 외부 접근을 위한 네트워크 구성 당시 OpenStack 클러스터는 동아리방 내부의 192.168.0.x 네트워크에 있었다. 서비스를 외부에 제공하려면 RCP API에 접근하는 경로와 사용자가 VM에 SSH로 접속하는 경로를 각각 설계해야 했다. 다음 글에서는 이를 위해 검토하고 적용한 네트워크 구성을 정리할 예정이다. Network Node 분리 Cloudflare Tunnel과 Reverse Proxy 공인 IP 제약 Bastion Host 이중 공유기 구성 정리 및 허브화