☁️Naver Cloud Platform을 활용한 배포 전략
처음에는 빠르게 개발 및 배포 환경을 구축하기 위해 단일 인스턴스에 Nginx(프론트엔드), API 서버, 데이터베이스 등 모든 것을 설치했습니다. 하지만 서비스가 확장됨에 따라 인프라의 안정성과 확장성에 대한 필요성이 커졌습니다. 이에 따라 더욱 효율적이고 안정적인 배포 전략을 모색하게 되었습니다. 🚀
단일 인스턴스 구조와 NKS 구조의 성능 비교는 여기를 참고해 주세요!
다이어그램 접기/펼치기
Infra(인프라)를 개선하기 위해 먼저 VPC(Virtual Private Cloud)와 Subnet에 대해 학습했습니다.
- VPC: 가상 네트워크 환경으로, 클라우드 자원을 안전하게 관리하고 네트워크를 세분화할 수 있습니다.
- Subnet: VPC 내에서 IP 주소 범위를 지정하여 네트워크를 구분하고, 보안과 트래픽 관리를 용이하게 합니다.
이를 통해 퍼블릭 및 프라이빗 서브넷을 구성하여 보안성과 관리 효율성을 향상시켰습니다.
- 보안 강화: 외부로부터의 접근을 제어하여 민감한 데이터와 서비스를 보호합니다.
- 네트워크 관리: 트래픽을 효과적으로 분산하고 관리할 수 있습니다.
- 유연성: 서비스별로 서브넷을 구분하여 확장성과 유지 보수성을 높입니다.
Kubernetes(K8s)는 컨테이너화된 애플리케이션의 배포, 스케일링 및 관리를 자동화하는 오픈 소스 플랫폼입니다.
- Cluster: Kubernetes의 기본 단위로, 컨트롤 플레인과 여러 Node로 구성됩니다.
- Node Pool: 유사한 특성을 가진 Node들의 그룹으로, 워크로드의 효율적인 분산을 도와줍니다.
- Node: 컨테이너를 실행하는 물리적 또는 가상 머신입니다.
- Pod: 하나 이상의 컨테이너를 담고 있는 Kubernetes의 최소 배포 단위입니다.
- Service: Pod에 대한 네트워크 서비스를 정의하여 안정적인 접근을 제공합니다.
- Ingress: 외부 트래픽을 Service로 라우팅하는 규칙을 설정합니다.
- 오토스케일링: 부하에 따라 자동으로 리소스를 할당하여 서비스의 안정성을 높였습니다.
- 롤링 업데이트: 무중단 배포를 통해 서비스 가용성을 유지했습니다.
처음에는 다음과 같은 방식으로 배포를 구성했습니다:
- GitHub의 main 브랜치에 Push하면, Naver Cloud Platform의 SourceCommit Repo로 데이터를 동기화했습니다.
- SourceCommit에 Push 이벤트가 트리거되면 SourcePipeline에서 SourceBuild를 통해 각 서버를 빌드했습니다.
- 빌드된 이미지는 ContainerRegistry에 저장되었습니다.
- 모든 서버의 빌드가 완료되면 SourceDeploy를 통해 NKS(Naver Kubernetes Service)에 배포되었습니다.
- 문제 상황: SourceBuild에서 빌드한 이미지는 실행할 수 없는 상태였습니다.
-
증상:
- 빌드 및 ContainerRegistry 업로드는 성공하였으나, SourceDeploy에서 배포된 컨테이너가 실행 오류를 발생시켰습니다.
- 로컬에서 해당 이미지를 pull하여 실행해도 동일한 오류가 발생했습니다.
-
환경 차이: 로컬 환경과 SourceBuild 환경의 차이로 인해 빌드된 이미지에 문제가 발생했습니다.
-
디버깅 결과: 빌드된 이미지 자체에 문제가 있음을 확인했습니다.
하지만 여전히 왜 이러한 차이가 발생하고, 어떻게 해결할 수 있는지는 조사중입니다.
- GitHub Actions 활용: 이미지 빌드와 ContainerRegistry에 푸시하는 과정을 NCP의 SourceBuild 대신 GitHub Actions로 전환했습니다.
-
결과:
- 일관된 빌드 환경을 확보하여 이미지 빌드 오류를 해결했습니다.
- NKS(Naver Kubernetes Service)를 통해 Kubernetes Cluster를 구성하였습니다.
- Node Pool을 서비스별로 분리하여 리소스 관리를 최적화했습니다.
- 오토스케일링을 적용하여 트래픽 부하에 따라 유연하게 대응할 수 있게 되었습니다.
- 음성 처리 서버와 같이 부하가 큰 서비스에는 오토스케일링을 적용했습니다.
- Horizontal Pod Autoscaler(HPA)를 사용하여 CPU 사용량에 따라 Pod 수를 자동으로 조절했습니다.
- 이를 통해 사용자 경험을 향상시키고, 리소스 사용 효율을 높였습니다.
- 확장성: 서비스별로 독립적인 스케일링이 가능하여 높은 트래픽에도 안정적으로 대응할 수 있습니다.
- 안정성: 한 서비스에 문제가 발생해도 다른 서비스에 영향이 미치지 않습니다.
- 유지 보수성: 서비스별로 배포 및 관리가 용이하여 개발 생산성이 향상되었습니다.
서비스의 전체적인 구조는 다음과 같습니다:
클릭하여 아키텍처 다이어그램 보기 🖼️
클릭하여 배포 파이프라인 다이어그램 보기 🖼️
클릭하여 VPC와 Subnet 다이어그램 보기 🖼️
이번 프로젝트를 통해 Naver Cloud Platform과 Kubernetes를 활용하여 안정적이고 확장 가능한 인프라를 구축할 수 있었습니다.
- 기술적 성장: Infra와 Kubernetes에 대한 심층적인 학습을 통해 전문성을 향상시켰습니다.
- 문제 해결 능력 강화: 빌드 및 배포 과정에서 발생한 문제를 분석하고 효과적으로 해결했습니다.
- 서비스 품질 향상: 오토스케일링 등을 통해 사용자에게 더 나은 서비스를 제공하게 되었습니다.
앞으로도 지속적인 학습과 개선을 통해 더욱 성장하는 개발자가 되겠습니다. 😊
Certificate Manager(Let's Encrypt, Certbot 대체)
Load Balancer
Container Registry
SourceDeploy
SourcePipeline
Ncloud Kubernetes Service