[Project] Cloud Migration 도전기

 

왜 마이그레이션을 하려고 하는가?

이커머스 메인페이지

MSA 기반 도서 이커머스 서비스를 제작했는데,

그 당시 요구사항과 데드라인이 있어 개인적으로 고도화를 하지 못해 아쉬운 부분이 많았다. 

그런 아쉬움을 해소하고자, 리펙토링 및 고도화를 진행해보려고 한다. 

진행하기 위해서, 우선 배포를 해야 하는데 기존 무료로 제공하던 NHN Cloud 사용 기간이 종료되었다.

 

---

 

NHH Cloud에서 AWS로 이전 

 

왜 AWS를 선택했는가?

AWS를 사용하는 기업이 점차 늘어가고 있다.

뿐만 아니라, AWS 사용할 경우 자체적으로 제공하는 서비스(RDS, EKS, MQ)들이 많아져

개발자들은 개발에만 집중할 수 있다는 장점이 있다. 

다만, 비용이 비싸다는 단점이 있지만 AWS 경험을 우대하는 기업이 점점 많아지고 있어 공부하는 겸 사용하기로 결정했다. 

 

 

---

 

 

기존 아키텍처 소개

• MSA 기반 도서 이커머스 프로젝트
• NHN Cloud에서 제공하는 Service 들을 (logging, image bucket, config server) 전반적으로 의존하고 있음.
• 쉘 스크립트를 통한 무중단 배포 및 실행
• Spring Cloud를 사용한 서버 통신 방식

아키텍처

 

기존 아키텍처에서는 서버를 확장할 때 직접 쉘 스크립트를 사용하여 새로운 서버를 추가하고, 각 서버의 포트 번호를 개별적으로 관리해야 했다.

그러나 이러한 방식은 개발자가 서비스 등록과 로드 밸런싱을 위해 Eureka 등의 설정을 코드에 직접 추가하고 유지해야 하는 부담이 있었다.

 

 

결론

이에 따라 Kubernetes를 도입하여 로드 밸런싱과 환경 구성(Config) 관리를 인프라 레벨에서 담당하도록 분리했다.

또한, 개발과 직접적인 관련이 있는 라우팅(@FeignClient 등)은 Gateway를 함께 사용하여, 애플리케이션 코드에서의 변경을 최소화하면서도 유연한 MSA 아키텍처를 구축하도록 결정했다.

 

 

함께 사용하는 것에 대해 중복되는 기능이 많은 것 같아. 고민을 많이 했지만,

아래 포스트를 통해 함께 사용하도록 결정했다. 

2025.01.11 - [Development] - [MSA] Spring Cloud vs Kubernetes

 

 

Migration 아키텍처

• EKS Node 2개 운영
• K8s Secret, ConfigMap 환경 사용
• Image 저장 S3 Bucket
• Elastic Load Balancing 을 통한 Front 서버 접속

 

기존에는 EC2에 직접 서비스를 구축하여 운영했지만, 직접 내부로 들어가서 설정을 해야 했고 실패 지점이 될 수 있어서 프로젝트를 안정적으로 운영할 수 없었다.

그래서 운영을 집중할 수 있도록 비용이 들더라도 효율적인 관리와 확장성을 고려해 AWS에서 제공하는 서비스(EKS, RDS, S3 등)를 활용했다.

 

 

추가 기능

• 그라파나 & 프로메테우스

 

 

프로젝트 목표

• 성능 개선
• 자잘한 버그 수정
• 리펙토링 

 

 

성과

추가예정