본문으로 건너뛰기

KMS 서비스 구성을 위한 스펙 및 HA 구성 절차 안내

개요​

본 문서는 KMS(Key Management System) 서비스의 On-Premise 구축을 위한 스펙 및 HA(High Availability) 구성 절차를 정의하고, 안정적인 서비스 운영을 위한 고려 사항을 안내합니다. 단, KMS와 관련된 최소한의 서비스를 제외한 모든 서비스는 SaaS에 존재합니다.

하드웨어 스펙 정의​

KMS만 설치하는 환경을 위한 서버당 권장 사양은 다음과 같습니다

서버당 최소 권장 사양 (세부 리소스 요구사항 포함)​

  • CPU : 8 Core 이상
    • Kubernetes Master Role: 2 Core
    • KMS: 1 Core
    • ElasticSearch: 3 Core
    • 여유분 20%: 약 1.2 Core
    • 합계: 기본 요구사항 6 Core + 여유분 = 약 8 Core
  • RAM : 32GB 이상
    • Kubernetes Master Role: 4GB
    • KMS: 2GB Memory
    • ElasticSearch: 8GB Memory
    • 여유분 20%: 약 3GB
    • 합계: 기본 요구사항 14GB + 여유분 = 약 17GB (안정성을 위해 32GB 권장)
  • 디스크 :
    • OS 및 Docker 영역: 300GB 이상
    • 데이터(Longhorn) 영역: 최소 300GB 이상
    • 총 디스크 공간: 최소 600GB 이상 권장

서버당 안정적 운영을 위한 권장 사양​

  • CPU : 16 Core
  • RAM : 64GB
  • 디스크 : 600GB - 1TB
    • Host OS & RKE 운영 공간: 300G (기존 200G + 폐쇄망 지원을 위한 Harbor 100G 추가)
    • Longhorn Storage 용량: 300G
      • ※ OS 및 RKE 운영 공간이 300G로 설정된 이유 폐쇄망 환경에서는 Harbor가 인터넷에서 컨테이너 이미지를 직접 다운로드할 수 없기 때문에, 로컬에 저장하여 서비스 재구동 시 Harbor에서 컨테이너 이미지를 불러와야 하기 때문입니다.

폐쇄망 Harbor란?

  • RKE의 기본 관련 모듈, Longhorn 등을 포함한 자체 서비스 컨테이너 이미지는 원래 인터넷에서 다운로드하여 사용하는 것이 일반적입니다.
  • 하지만 망분리(폐쇄망) 환경에서는 인터넷에서 직접 컨테이너 이미지를 다운로드할 수 없으므로, 서비스가 정상적으로 구동되지 못하는 문제가 발생할 수 있습니다.
  • 이를 해결하기 위해 OS 영역 내에 Container Registry(Harbor)를 설치하고, 필요한 컨테이너 이미지를 사전에 저장해야 합니다.
  • 이 과정에서 약 100G의 추가 저장 공간이 필요하며, 이렇게 저장된 이미지는 RKE2, Longhorn, Security365 등의 서비스에서 활용하여 정상적으로 운영될 수 있습니다.

디스크 산정 방식​

  • 기본 OVA 설치 및 운영 데이터 : 300GB
  • Longhorn 최소 300GB × 5대 (Node 개수에 따라 증가) = 1.5TB
  • Elasticsearch 데이터 저장 공간 (예상 증가분 포함) : 최소 1~2TB 이상
  • 이중화 및 확장성 고려하여 추가 여유 공간 확보 : 3TB 이상

Security365 Master OVA 이미지 사양​

해당 내용은 내부 사이트에만 기술 되어있음을 안내 드립니다. 내부 사이트 링크는 하단에 첨부되어 있습니다. ova

참고사항 : ElasticSearch는 데이터를 지속적으로 저장하므로, 데이터 영역은 충분히 확보하는 것이 좋습니다. 한번 제출된 스펙은 추후 증설이 불가능하고 축소만 가능하므로, 안정적인 운영을 위해 여유 있는 사양을 권장합니다.

HA 구성 절차​

KMS 서비스 HA 구성을 위한 절차는 다음과 같습니다:

  1. Master OVA 1대 구성
    • 기본 Master 노드 설치
  2. IP/도메인 변경
    • 환경에 맞게 IP 및 도메인 설정
  3. KMS 관련 서비스만 활성화
    • 그 외 서비스는 비활성화 처리
  4. Slave OVA 4대 구성
    • 각 서버마다 IP 변경 필요하며 Master 노드 설치
  5. Node Join 작업
    • 4대 모두 ControlPlane 역할 수행으로 Join
    • kubectl join --control-plane 명령어 사용
  6. Longhorn 볼륨 Replicas 조정
    • 1 → 5로 조정
    • kubectl -n longhorn-system edit volume [볼륨명] 명령으로 numberOfReplicas: 5 설정
  7. Elasticsearch Replicas 조정
    • 1 → 5로 Scale 조정
    • kubectl -n logging scale statefulset elasticsearch-master --replicas=5
  8. Cloud 서비스 URL 변경 요청
    • KMS 서비스 URL 변경을 위해 Cloud연구부에 요청

구성 점검을 위한 체크리스트​

Master 노드 점검​

  • kubectl get nodes 명령어로 모든 노드가 Ready 상태인지 확인
  • kubectl get pods -A 명령어로 모든 Pod가 Running 상태인지 확인

KMS 서비스 점검​

  • kubectl -n kms get pods 명령어로 KMS 관련 Pod가 정상 실행 중인지 확인
  • kubectl -n kms get svc 명령어로 서비스 엔드포인트 확인

스토리지 및 로깅 점검​

  • kubectl -n longhorn-system get pods 명령어로 Longhorn 상태 확인
  • kubectl -n longhorn-system get volume 명령어로 볼륨 Replica 설정 확인
  • kubectl -n logging get pods 명령어로 ElasticSearch 상태 확인

고가용성 테스트​

  • 임의의 노드 1대 중단 후 서비스 정상 작동 확인
  • 부하 테스트를 통한 성능 및 안정성 확인

이중화 및 장애 대응 상세 안내​

이중화 구성 요구사항​

  • 최소 노드 수 : Master Role 장비 3대 이상 (5대 구성 권장)
  • 복제본 설정 :
  • KMS Replicas: Master Role 개수와 동일하게 설정 (5대 구성 시 5개)
  • ElasticSearch Replicas: Master Role 개수와 동일하게 설정 (5대 구성 시 5개)
  • Longhorn Replicas: Master Role 개수와 동일하게 설정 (5대 구성 시 5개)

장애 시나리오 및 대응 방안​

  • 1대 장애 시 : 서비스 정상 작동 (4/5 노드 가동, 과반수 이상 유지)
  • 2대 장애 시 : 서비스 정상 작동 (3/5 노드 가동, 과반수 이상 유지)
  • 3대 이상 장애 시 : 서비스 불안정 또는 중단 가능성 높음 (과반수 미만으로 etcd 쿼럼 손실)

중요 : etcd는 과반수 이상의 노드가 정상 작동해야 쿼럼(quorum)을 유지하고 서비스가 안정적으로 운영됩니다. 5대 구성 시 최소 3대는 정상 작동해야 합니다.

디스크 관리 고려사항​

  • 각 노드의 디스크는 KMS의 Replicas 개수에 맞게 충분히 확보되어야 함
  • 노드 수가 증가할수록 필요한 디스크 공간도 비례하여 증가

기술 지원​

  • KMS 정상 구동 안 될 경우, SaaS R&D 1본부 인력 지원 협조 요청 가능
  • 구성 과정에서 발생하는 기술적 문제는 Cloud연구본부에 문의 가능

참고 문서​