현재(AS-IS) 배포 환경을 나타낸 다이어그램으로, 서버와 Google Cloud Storage 간의 연동 구조를 보여준다.
- 서버에서는 Docker 컨테이너를 사용하고 있으며, 사용자는 서버에 접근하여 서비스를 이용한다.
- 서버에서 Google Cloud Storage와 데이터를 주고받는 구조이다.
- 현재 배포 환경의 문제점으로 On-premise 리소스 부족, Docker Container 관리 한계, Container Registry 부재가 언급되어 있다.
현재 배포 환경은 온프레미스(로컬 서버)에서 애플리케이션을 실행하고, Google Cloud Storage(GCS)를 데이터 저장소로 활용하는 하이브리드 구조입니다.
문제점
- 온프레미스 리소스 부족
- 로컬 서버의 성능이 제한적이며, 트래픽 증가 시 확장(Scaling)이 어려움.
- Docker Container 관리 한계
- 컨테이너 운영 및 배포를 수동으로 관리해야 해 유지보수 부담이 큼.
- Container Registry 부재
- 컨테이너 이미지를 체계적으로 저장·관리할 저장소가 없어 배포 및 버전 관리가 비효율적임.
TO-BE 배포 환경 설명
이 TO-BE 배포 환경은 GCP 기반의 Kubernetes 및 Container Registry를 활용한 클라우드 네이티브 아키텍처로 전환하는 것을 목표로 합니다.
구성 요소
- GCP Registry
- Docker 컨테이너 이미지를 저장 및 관리하는 GCP Artifact Registry를 사용.
- Helm을 활용해 Kubernetes 애플리케이션을 패키징하고 배포.
- GCP Kubernetes (GKE)
- Kubernetes 환경을 GCP에서 운영하여 자동 확장, 자동 복구, 배포 자동화 가능.
- 사용자 요청을 처리하고, GCS와 데이터를 주고받음.
- Google Cloud Storage
- 애플리케이션 데이터 및 기타 저장소 역할.
변경 및 개선점
✅ 온프레미스에서 GCP Kubernetes 환경으로 이전 → 확장성 및 안정성 강화
✅ GCP Registry 도입 → 컨테이너 이미지의 체계적인 관리 가능
✅ Helm을 활용한 Kubernetes App 배포 → 자동화된 배포 및 관리 효율성 향상
이전 AS-IS 환경의 문제점(온프레미스 리소스 부족, 수동 배포, 이미지 관리 부재)을 해결하며, 클라우드 네이티브 방식으로 운영을 최적화하는 방향입니다. 🚀
💡 TO-BE 방향
- 애플리케이션 실행 환경을 클라우드(GCP)로 이전하여 확장성과 운영 효율성을 개선.
- Kubernetes(GKE)와 Container Registry 도입으로 자동화된 배포 및 관리 체계 구축.
사용자와 각 구성 요소의 관계
- 사용자 → GCP Kubernetes (GKE) 접근
- 사용자는 웹 애플리케이션이나 API 등을 GCP Kubernetes에서 실행 중인 서비스에 요청합니다.
- GKE는 이러한 요청을 처리하고 필요한 리소스를 자동으로 할당합니다.
- GCP Kubernetes ↔ GCP Registry
- GKE에서 실행될 애플리케이션 컨테이너 이미지는 GCP Registry에서 가져옵니다.
- Helm을 사용하여 Kubernetes에 배포할 때, GCP Registry에서 최신 컨테이너 이미지를 다운로드하여 배포합니다.
- GCP Kubernetes ↔ Google Cloud Storage
- GKE에서 실행 중인 애플리케이션이 데이터를 저장하거나 불러올 때, Google Cloud Storage(GCS)를 활용합니다.
- 예를 들어, 애플리케이션이 사용자 업로드 파일을 저장할 경우 GCS에 저장됩니다.
즉, GCP Registry는 애플리케이션 실행을 위한 컨테이너 이미지를 저장하는 곳이고, GCS는 애플리케이션이 다루는 데이터(파일, 로그 등)를 저장하는 곳이에요! 🚀
결론
- 사용자는 GCP Kubernetes(GKE)에 배포된 애플리케이션을 사용하게 됩니다.
- Kubernetes는 GCP Registry에서 컨테이너 이미지를 가져와 실행하고,
- 데이터는 Google Cloud Storage(GCS)에 저장하여 효율적인 운영이 가능해집니다. 🚀
Autopilot 모드 (자동 관리 모드)
✅ 완전 관리형 Kubernetes → GCP가 클러스터 운영을 자동으로 관리
✅ 노드 및 인프라 자동 관리 → 사용자가 직접 노드를 생성하지 않아도 됨
✅ 운영 부담 최소화 → Kubernetes 설정, 리소스 할당, 스케일링 등을 GCP가 자동 처리
✅ 비용 최적화 → 사용한 리소스만큼만 과금
Standard 모드 (사용자 관리 모드)
✅ 사용자가 클러스터와 노드 풀을 직접 관리
✅ 노드 크기, 개수, 업그레이드 등을 수동으로 설정해야 함
✅ 운영의 유연성이 높지만 관리 부담이 있음
✅ 고정된 노드 비용이 부과됨
어떤 모드를 선택할까?
- 운영 부담을 줄이고 자동화를 원하면 → Autopilot 모드
- 세부적인 클러스터 설정과 관리가 필요하면 → Standard 모드
Autopilot 모드는 관리가 편리하지만 세부적인 설정이 제한적이고, Standard 모드는 관리 부담이 있지만 유연성이 높습니다.
GCP 콘솔에서 Kubernetes Engine → 클러스터 만들기 → Standard 모드 선택 → 기본 설정 후 생성하면 클러스터가 생성됩니다.
'시스템 개발 및 관리 > 이커머스 효율화: NLP 모델 적용' 카테고리의 다른 글
[Kubernetes 배포 환경 구축] Helm 생성 (0) | 2025.03.01 |
---|---|
[Kubernetes 배포 환경 구축] GCP Docker 이미지 빌드 (0) | 2025.03.01 |
Cloud Storage 기반 모델 관리 - 라이브러리 패키지 (0) | 2025.02.21 |
GCP Cloud Storage 기반 모델 관리 (0) | 2025.02.20 |
AI API Service (0) | 2025.02.20 |