2024 OSSCA 표준 프레임워크 및 MSA, 쿠버네티스 환경 살펴보기

 

 

9월 11일 발대식을 시작으로, 2024 OSSCA 표준 프레임워크 및 MSA 멘티로 활동을 시작하게 되었습니다. 현재는 3주차를 앞두고 Kubernetes 환경을 주제로 발표를 준비하며 eGovFramework의 Kubernetes 환경 구성을 분석해 보았습니다.

분석할 레포지토리 소개: egovframe-msa-edu

오늘 분석할 레포지토리는 eGovFramework organization의 egovframe-msa-edu입니다. 이 프로젝트는 클라우드 네이티브 기반의 행정 및 공공기관 서비스 확산을 지원하기 위해 설계되었으며, 다양한 MSA(Microservices Architecture) 교육 자료를 제공합니다.

 

Kubernetes 환경 구성 분석

먼저, 레포지토리의 k8s 폴더 구조를 살펴보겠습니다. k8s 폴더는 크게 세 가지 디렉터리로 나뉩니다: applications, environments, storage. 이 구조는 각 서비스와 환경 설정, 그리고 스토리지 관리를 별도로 모듈화하여 관리하고 있습니다.

└─k8s
├─applications
│  ├─backend
│  │  ├─apigateway
│  │  │  └─ingress
│  │  ├─board-service
│  │  ├─config
│  │  ├─discovery
│  │  │  └─ingress
│  │  ├─portal-service
│  │  ├─reserve-check-service
│  │  ├─reserve-item-service
│  │  ├─reserve-request-service
│  │  └─user-service
│  └─frontend
│      ├─admin
│      │  └─ingress
│      └─portal
│          └─ingress
├─environments
│  ├─configmaps
│  ├─databases
│  │  └─mysql
│  │      └─init
│  ├─jenkins
│  ├─logging
│  │  └─elk
│  │      ├─elasticsearch
│  │      ├─kibana
│  │      │  └─ingress
│  │      └─logstash
│  ├─nfs
│  ├─rabbitmq
│  │  └─ingress
│  ├─vagrant
│  └─zipkin
│      └─ingress
└─storage

 

이를 아키텍처로 간단하게 나타내보면 다음과 같습니다.

Ingress의 역할

Kubernetes 클러스터 외부에서 내부 서비스로 HTTP와 HTTPS 경로를 노출할 때, Ingress 리소스를 사용합니다. 이 리소스는 외부 요청을 클러스터 내부의 적절한 서비스로 라우팅하는 역할을 하며, 복잡한 네트워크 설정 없이도 외부 접근을 쉽게 관리할 수 있습니다. 예를 들어, 호텔의 프론트 데스크처럼 모든 외부 요청을 적절한 내부 서비스로 안내하는 것과 비슷한 역할을 합니다.

참고: Ingress 공식 문서

Kustomize로 구성 관리하기

eGovFramework 레포지토리에서 눈에 띄는 또 다른 구성 요소는 kustomize입니다. kustomize는 Kubernetes 매니페스트 파일을 사용자 정의하고 관리하기 위한 도구로, 다양한 환경에 대한 구성 관리가 용이합니다.

kustomize.yaml 파일 구조 분석

각각의 kustomization.yaml 파일은 애플리케이션의 다양한 계층 또는 구성 요소를 관리합니다. 아래는 applications 디렉터리의 예시입니다:

1. applications/kustomization.yaml
   • 역할: 전체 애플리케이션의 최상위 구성을 정의하며, 프론트엔드와 백엔드 구성을 하나로 묶어 전체 구조를 정의합니다.
2. applications/backend/kustomization.yaml
   • 역할: 백엔드 서비스의 세부 구성을 정의하고, 사용될 Docker 이미지와 인그레스 설정 등을 관리합니다.
3. applications/frontend/kustomization.yaml
   • 역할: 프론트엔드 애플리케이션의 구성을 정의하며, 프론트엔드 Docker 이미지와 인그레스 설정 등을 관리합니다.

이러한 구조는 마이크로서비스 아키텍처에서 구성 요소를 모듈화하고 관리하기 쉽게 만듭니다.

Kubernetes 구성 관리 도구 비교

Kubernetes 환경에서 구성 관리 도구를 선택하는 것은 매우 중요합니다. Kustomize 외에도 다양한 도구가 존재하며, 프로젝트 요구사항에 따라 적절한 도구를 선택해야 합니다. 아래는 대표적인 도구들의 특징을 정리한 표입니다.

특징 Kustomize Helm Jsonnet Ansible

유형	네이티브 K8s 도구	패키지 관리자	데이터 템플릿 언어	자동화 도구
설정 방식	YAML	YAML + Go 템플릿	Jsonnet	YAML
학습 곡선	낮음	중간	높음	중간
템플릿 사용	아니오 (순수 YAML)	예	예	제한적
패키징 & 배포	제한적	강력함	제한적	강력함
버전 관리	Git 통합	차트 버전 관리	Git 통합	Git 통합
플러그인 생태계	제한적	풍부함	제한적	매우 풍부함
환경별 구성	오버레이로 쉬움	values.yaml로 관리	환경별 파일 필요	인벤토리로 관리
복잡성 관리	모듈화로 관리	차트와 서브차트	함수와 라이브러리	역할과 플레이북
주요 장점	간단함, K8s 네이티브	강력한 패키징	유연한 템플릿	광범위한 자동화
주요 단점	고급 기능 제한적	복잡한 템플릿	학습 곡선 높음	K8s에 특화되지 않음

각 도구는 고유한 강점이 있으며, 프로젝트 요구사항과 팀 역량에 따라 적절한 도구를 선택해야 합니다.

Frontend와 Backend 서비스 구성

Frontend 구성 요소

frontend/admin
│
├── ingress/
│   └── ingress.yaml
│
├── autoscaler.yaml
│
├── deployment.yaml
│
└── service.yaml

frontend/portal
│
├── ingress/
│   └── ingress.yaml
│
├── autoscaler.yaml
│
├── deployment.yaml
│
└── service.yaml

frontend/admin과 frontend/portal 디렉터리에는 인그레스, 오토스케일러, 배포 및 서비스 설정이 포함된 여러 YAML 파일이 있습니다.

• Ingress: 외부 트래픽을 프론트엔드 애플리케이션으로 라우팅하며, 관리자 UI 접근을 관리합니다.
• HorizontalPodAutoscaler: 트래픽 증가에 따라 Pod 수를 자동으로 조절하여 성능을 유지합니다.
• Deployment: 실제 프론트엔드 애플리케이션을 실행하고 관리합니다.
• Service: 네트워크 접근을 관리하며, 외부 및 클러스터 내부 접근을 제공합니다.

Backend 구성 요소

backend/
├── apigateway/
│   └── ingress/
├── board-service/
├── config/
├── discovery/
│   └── ingress/
├── portal-service/
├── reserve-check-service/
├── reserve-item-service/
├── reserve-request-service/
└── user-service/

backend 디렉터리는 다양한 마이크로서비스로 구성되어 있으며, apigateway와 discovery 서비스가 핵심적인 역할을 합니다.

• API Gateway: 모든 API 서버들의 엔드포인트를 단일화하고, 인증 및 인가를 관리합니다.

• Discovery: 분산 환경에서 동적으로 변경되는 서비스의 위치를 관리하며, 클라이언트가 서비스를 호출할 때 필요한 정보를 제공합니다.

Environments 구성 요소

environments 디렉터리는 Kubernetes 클러스터의 다양한 환경 설정을 포함하고 있습니다. 여기에는 데이터베이스 설정, 로깅 및 모니터링 시스템, 메시지 브로커 설정 등이 포함되어 있습니다. 각 환경 구성 요소를 살펴보겠습니다.

Databases

이 섹션에서는 MySQL 데이터베이스의 Kubernetes 리소스가 정의되어 있습니다. 주요 구성 요소는 다음과 같습니다:

• PersistentVolumeClaim: MySQL 데이터를 위한 5Gi NFS 스토리지를 요청합니다.
• Secret: MySQL 데이터베이스의 비밀번호를 안전하게 저장하기 위해 사용되며, base64로 인코딩된 'msaportal' 비밀번호를 포함합니다.
• Service: MySQL 포드에 대한 3306 포트 접근을 제공합니다.
• ConfigMap: MySQL 사용자, 데이터베이스 이름, 타임존 등의 구성 정보를 저장합니다.
• StatefulSet: Kubernetes StatefulSet을 사용하여 MySQL 데이터베이스를 배포하며, 데이터를 영구적으로 저장하기 위해 PersistentVolumeClaim을 사용합니다.

이러한 구성을 통해 안정적이고 확장 가능한 데이터베이스 환경을 제공하며, 마이크로서비스 아키텍처의 중요한 데이터 저장소 역할을 수행합니다.

Logging: ELK 스택

로깅 시스템은 ELK (Elasticsearch, Logstash, Kibana) 스택으로 구성되어 있습니다.

• Elasticsearch: 로그 데이터를 저장하고 검색할 수 있는 강력한 검색 및 분석 엔진입니다.
• Logstash: 로그를 수집하고 Elasticsearch로 전달하기 전에 필터링하고 변환합니다.
• Kibana: Elasticsearch에 저장된 로그 데이터를 시각화하고 분석할 수 있는 도구입니다.

이 구성은 마이크로서비스 아키텍처에서 로그 데이터를 효율적으로 수집하고 분석할 수 있게 해주며, 문제 발생 시 빠르게 원인을 파악할 수 있는 환경을 제공합니다.

RabbitMQ

메시지 브로커인 RabbitMQ는 마이크로서비스 간의 비동기 통신을 담당합니다. Ingress 설정을 통해 외부 접근을 관리하고, 안정적인 메시징 환경을 제공합니다.

Zipkin

Zipkin은 분산 추적 시스템으로, 마이크로서비스 간의 호출 관계를 추적하고 분석하는 데 사용됩니다. 이를 통해 서비스 호출 시 지연 발생 원인을 파악하고, 성능 최적화에 기여할 수 있습니다.

Storage 구성 요소

storage 디렉터리에는 다양한 스토리지 옵션이 포함되어 있습니다. 여기에는 NFS와 Cinder와 같은 스토리지 클래스가 있으며, 다양한 환경에서 사용할 수 있도록 유연하게 구성되어 있습니다.

NFS (Network File System)

NFS는 여러 노드에서 동시에 접근 가능한 공유 스토리지를 제공합니다.

• NFS Provisioner Deployment: NFS 프로비저너를 배포하여, 동적으로 PV를 생성할 수 있는 환경을 제공합니다.
• RBAC 설정: NFS 프로비저너에 필요한 권한을 부여하여 PV 생성 및 관리를 가능하게 합니다.
• StorageClass 정의: 'nfs'라는 이름의 StorageClass를 생성하여, PVC가 동적으로 NFS 기반의 PV를 요청할 수 있도록 설정합니다.

이 구성은 Kubernetes 클러스터에서 NFS 스토리지를 동적으로 프로비저닝할 수 있는 환경을 제공하며, 안전하고 효율적인 스토리지 관리가 가능합니다.

Vagrant 환경 설정

Vagrant를 사용하여 Kubernetes 클러스터를 손쉽게 구성할 수 있는 개발 및 테스트 환경을 제공합니다.

• 클러스터 구성: 1개의 control-plane과 2개의 worker 노드로 구성되며, 각 노드는 Ubuntu 20.04 이미지를 사용합니다.
• 네트워크 설정: 프라이빗 네트워크를 사용하여 노드 간 통신을 관리하며, 포트 포워딩을 통해 외부 접근을 지원합니다.
• 특징: VirtualBox 프로바이더를 사용하여 Ceph와 같은 분산 스토리지 시스템을 실험하기에 적합한 환경을 제공합니다.

OpenStack Cinder

NFS 스토리지 외에도 egovframe-msa-edu 레포지토리에서는 OpenStack 기반의 Cinder 스토리지도 사용됩니다. 이는 다양한 환경 요구 사항과 스토리지 사용 시나리오에 대응하기 위해서입니다.

• PersistentVolumeClaim (Cinder PVC): Cinder 스토리지는 단일 노드에서만 접근 가능한 블록 스토리지를 제공합니다. ReadWriteOnce 접근 모드로 5Gi의 스토리지를 요청하는 구성을 사용합니다.
• StorageClass: 'cinder'라는 이름의 StorageClass를 정의하여, Kubernetes 클러스터 내에서 Cinder 기반의 스토리지를 사용할 수 있게 합니다.

왜 NFS와 OpenStack Cinder를 함께 사용하는가?

NFS와 OpenStack Cinder를 함께 사용하는 이유는 각 스토리지의 장점을 활용하여 다양한 요구사항을 충족하기 위해서입니다.

• NFS의 장점:
  • 다중 접근: 여러 노드에서 동시에 접근할 수 있는 공유 스토리지를 제공하여, 분산 파일 시스템처럼 동작합니다.
  • 유연성: 다양한 애플리케이션에서 공통적으로 사용되는 데이터를 저장할 수 있어, 공유 자원 관리에 용이합니다.
• Cinder의 장점:
  • 블록 스토리지: 데이터베이스와 같은 단일 애플리케이션에 특화된 스토리지 요구사항을 충족합니다. 높은 I/O 성능을 요구하는 애플리케이션에 적합합니다.
  • 데이터 보안: 단일 노드에서만 접근 가능하도록 설정되어 있어, 특정 애플리케이션의 데이터 보안 요구 사항을 만족시킵니다.

이러한 구성을 통해, eGovFramework는 애플리케이션의 데이터 접근 패턴에 따라 적절한 스토리지 옵션을 선택할 수 있는 유연성을 제공합니다. 예를 들어, 여러 애플리케이션이 공통 데이터를 공유해야 하는 경우 NFS를 사용하고, 데이터베이스와 같이 고성능 I/O가 필요한 애플리케이션은 Cinder를 사용하는 방식입니다.

결론

이번 분석을 통해 eGovFramework의 egovframe-msa-edu 레포지토리가 MSA 기반의 공공기관 서비스 확산을 지원하기 위한 강력한 인프라를 제공하고 있음을 알 수 있었습니다. Kubernetes와 Kustomize를 활용한 구성 관리는 다양한 환경에서 일관된 배포를 가능하게 하며, 복잡한 시스템을 모듈화하여 관리하기 쉽게 만듭니다.

또한, environments 디렉터리의 다양한 환경 설정과 storage 디렉터리의 유연한 스토리지 관리 옵션을 통해 다양한 요구사항에 맞는 구성을 제공하고 있습니다. 앞으로 OSSCA 활동을 통해 더 깊이 있는 Kubernetes 환경 분석과 MSA 구성 노하우를 습득하여, 실제 프로젝트에 적용해볼 예정입니다. 이 블로그가 Kubernetes 및 MSA 구성에 대해 관심이 있는 분들께 도움이 되었기를 바랍니다. 감사합니다.