안녕하세요
클라우드팀에서 전사 클라우드 관리 및 이관업무를 담당하고 있는 최삼열 입니다.
2020년 말부터 2021년 초 GSSHOP Mobile/Web 채널 서비스가 클라우드로 이관이 되었습니다.
시작부터 오픈까지 약 5개월정도 소요가 되었지만, 실제로는 그 전부터 이관을 위한 다양한 고민과 문제들에 대해 하나씩 해결해 나가는 과정이 있었습니다.
그 스토리를 공유해보려고 합니다.
참고 : 이번 기고는 전체적인 스토리를 다루었습니다. 기술적인 상세 내용은 추가적인 컨텐츠로 올라갈 예정입니다.
STEP0. PLAN
먼저 전체 일정입니다.
약 5개월의 일정으로 진행이 되었는데 잘 보시면 "분석 및 설계" 의 단계에 한달 남짓 되는 기간이 소요되었습니다.
물론 전체 시스템의 분석/설계가 한달만에 이루어질 리가 없죠.
한달만에 진행할 수 있었던 건 프로젝트에 들어가기 전에 대부분의 쟁점사항(DB의 거취에 대한 검토, 여러 클라우드에 대한 테스트, 타 업체 사례조사, 대략적인 아키텍처 정의)의 검토가 완료된 상태였기 때문입니다.
프로젝트 진행중에는 대부분 클라우드 자체의 기술과 특성에 따른 설계만 이루어졌습니다.
그러면 프로젝트 시작 전 단계에 진행되었던 내용부터 들어가보겠습니다.
STEP1. 무엇을 이동할것인가
기존 시스템 구조입니다.
Redis와 외부 연계처리를 위한 많은 시스템도 있지만, 인프라 입장에서 아주 단순화시켜보면 위와 같이 그려질 수 있습니다.
(아키텍처를 상세하게 그리면 blur 처리의 압박이 있습니다)
채널 자체로도 Front 에 10여개의 서비스, API 에도 비슷한 개수의 서비스가 별도로 존재하고 있습니다.
우선은 채널서비스의 범위 내에서 클라우드로의 이관 검토가 시작되었습니다.
기술적인 관점으로만 보면 대부분 가능하겠지만, 모든 프로젝트가 그렇든 합리적인 비용과 한정된 기간(이것도 결국 비용)으로 가능할 것인지가 중요했습니다.
업무 리소스를 고려하여 개발팀의 부하를 가능한 줄이기 위해, 가능한 인프라 관점에서 클라우드의 관리형 서비스를 활용하는 방안으로 진행되었습니다. 그러나 플랫폼의 변경과, 이슈 그리고 수많은 테스트로 끝에는 채널 관련 전체 팀이 모두 같이하는 프로젝트가 되었습니다.
DB 의 거취
클라우드로 이관하기 위한 가장 큰 고민은 오라클DB를 어떻게 옮길까 였습니다.
지금까지 매우 잘 써왔던 DB이지만 클라우드로 넘어가면서는 잘 사용했기 때문에 복잡해지고 수많은 연계가 만들어진 오라클 DB가 큰 고민거리가 되었습니다.
DB의 전환이 가능한지 검토한 결과로도, 예상했지만 클라우드 이관을 위해 몇 개월 내로 전환하기는 어렵다는 결과가 나왔습니다.
그 후 현재 사용하는 DB를 클라우드에 올릴 수 있는지 검증이 필요했습니다.
기존 Unix 장비에서 운영되던 DB가 x86 리눅스로 넘어가서도 동일한 성능이 나오는지도 확인이 필요했습니다.
타겟으로 하는 클라우드 환경(AWS, Azure, NCP 등)에 테스트 데이터를 올리고, 현재 DB수준의 부하를 기반으로,
클라우드에 올라간 DB의 성능과 비용을 검증하였습니다.
현재수준의 서비스 부하는
기존 DB 기준 Top 쿼리를 통해 평균 디비 cpu 사용량(tpmc 기준)만큼 부하를 발생시켜 기본 부하를 만들고,
정기적으로 도는 배치를 추가하고,
발생할 수 있는 세션을 추가로 붙이고,
모니터링과 백업은 기본 부하로 추가하여
현재 운영되는 DB와 비슷한 부하를 주는 테스트를 진행했습니다.
리눅스&DB의 성능이 생각보다 괜찮은 것으로 확인은 되었지만, 라이센스, 비용, 성능을 통합해서 고려한 결과
결국 DB의 클라우드 이관은 어려운 것으로 확인되어 IDC에 그대로 유지하고 전용선을 통해서 서비스를 하는 것으로 방향을 가닥을 잡게 되었습니다.
전용선
클라우드센터와 IDC간 단독으로 사용할 수 있는 네트워크 망을 확보하여 통신하는 구조로 센터간 네트워크 통신 시
일관적인 성능 확보와 보안요건으로 사용
DB가 IDC에 유지되는 것으로 결정됨에 따라 전용선을 통해 클라우드 센터와 IDC를 연계할 경우 거리에 따른
Latency 가 고민이 되기 시작했습니다.
일반적으로 Latency 는 클라우드와 IDC간 물리적인 거리와 거치는 N/W 장비들이 몇개가 있는지 (Network hop 이라고 합니다)에 영향을 받지만, 실제 고객의 체감 서비스는 업무 로직에 의해 DB를 몇번 호출하는지에 따라 네트워크 latency의 배수로 Latency가 발생할 수 있었습니다.
테스트와 실제 리퀘스트 검증이 진행되었습니다.
기존에 클라우드에 작게 연결되어있던 전용선을 사용해서 기존 소스를 기준으로 임시 서비스를 만들었습니다.
DB를 붙여서 UI도 띄우고 몇가지 업무도 띄워서 UI 기동시간을 확인하고, 디비에 별도 커넥션으로 쿼리 수행 및 응답속도를 확인한 결과 수 ms 이내로 큰 이슈가 없는것으로 결과가 나왔고, 큰 이슈가 없는 수준으로 확인이 되었습니다.
(나중에는 오히려 클라우드 내부 네트워크는 기존 IDC보다 더 우수한 것으로 확인되었습니다)
검증은 운영환경의 APM을 통해서 업무가 처리되는 리퀘스트를 기준으로 DB 요청에 의한 Round Trip이 평균 몇건이 발생하는지 데이터를 취합하였습니다.
결과적으로 대부분의 업무로직은 Round Trip은 수 회~수십 회 이내로 처리가 되는 것으로 확인되었고,
주문 등 일부 로직 상 우려되었던 수백 회 이상의 Round Trip은 발생 빈도가 매우 적었습니다.
STEP2. 어디로 이동할 것인가
클라우드로의 이관 방향이 가닥을 잡아가면서 CSP(Cloud Service Provider) 를 선정하는 절차가 진행이 되었습니다.
모든 클라우드 서비스가 각기 장단점이 있었기 때문에 기술적 완성도, 서비스 안정성, 테스트, 향후 서비스 확장을 위한 고민,
비용 등을 기준으로 평가를 진행했습니다.
STEP3. 어떻게 만들 것인가
계정그룹
가장 중요한 일은 당장 이관할 채널서비스 뿐 아니라 이후 업무 시스템을 클라우드로 이관할 수 있는 기반을 만드는 것이었습니다.
많은 고민이 있었지만, 클라우드의 계정을 그룹화하는 기능을 활용하여 비용관리, 네트워크 관리, 공유서비스 관리, 보안관리 등 공통계정과
실제 업무서비스를 위한 워크로드 계정을 분리하여 각 계정에 대한 권한과 보안을 강화하는 구조로 설계하는 것으로 결정되었습니다.
클라우드의 통합 보안관리를 위해 계정의 권한관리는 보안팀에서 담당하였습니다.
특히 네트워크는 네트워크 계정에서 VPC/Subnet 을 비롯한 모든 네트워크 리소스를 생성하여 개별 서비스 계정에 공유하는 방식으로 설계되었습니다.
이 방식은 장점과 단점이 명확한 아키텍처로 볼 수 있는데, 클라우드 인프라를 한곳에서 통합적으로 관리하는 구조라면 유리하지만,
모든 서비스의 계정을 각자 구축하고 운영하는 DevOps로 구성된 조직이거나, 네트워크 등 공유서비스를 컨트롤하는 요건이 많다고 하면, Cross Account Access 가 많이 필요한 복잡한 구성이 될 수 있습니다.
컨테이너
IDC에서 VM기반으로 운영하던 WEB / WAS를 클라우드 전환 이후에는 Autoscale / 컨테이너 기반으로 전환되었습니다.
개발파트의 부담을 줄이기 위해 기존 AP는 변경 없이 플랫폼만 변경하여, WEB은 AutoScale 로 WAS는 컨테이너로 전환하였습니다.
수시로 진행되는 다양한 이벤트를 수용하기 위해 서비스에 유연한 Kubernates 플랫폼 기반의 관리형 서비스를 사용하였습니다.
서비스 안정화를 위해 이관 후에도 약 1개월가량 동시 운영 기간이 존재할 것으로 예상되어 기존 IDC 와 클라우드의 컨테이너 배포를 동시에 이루어질 수 있도록 배포 프로세스가 변경되었습니다.
개발팀 입장에서는 기존과 동일하게 배포를 진행하면 순차적으로 클라우드의 컨테이너도 Rolling으로 동일한 소스가 배포되는 구조입니다.
(물론 이 프로세스는 클라우드 이관 안정화 이후 Mobile/Web 채널서비스 장비 폐기와 함께 삭제되었습니다.)
배포 프로세스 개발 시에 고려할 부분들이 몇 있었습니다.
요건
- 배포 시 IDC의 WEB/WAS Rolling 배포와 클라우드의 k8s 컨테이너 배포가 동시에 진행되어야 함.
- IDC 배포 이후 클라우드 환경에서 배포가 실패하면 전체 배포가 롤백이 되어야 함.
- 배포 시 kubernetes의 ingress 가 변경되는 경우 클라우드 DNS 서비스에 자동으로 반영이 되어야 함.
고민
- 배포 시 타겟 환경에 맞는 properties 를 물고 올라갈 때 어떤 방식이 적합한지 ?
- 배포 시 두개의 환경에 배포가 되어 2배의 시간이 소요됨 (1회 배포시 약 20분 가량)
- 안정적인 배포가 되려면 컨테이너 배포 시 Rolling과 Blue/Green 방식 중 가능한 방법은 무엇이고 더 안정적인지?
- Rolling 배포를 한다면 서비스에 영향이 최소화되는 안정적인 Rolling 비율은 ?
- 배포 후 WAS(Tomcat) 가 기동되고 필요 데이터를 메모리에 올리는 데 WAS당 약 5분정도 소요되는데 컨테이너 자체의 빠른 확장성을 위해서 개선이 가능한지 ?
- POD이 정상적으로 기동되어 서비스에 투입 가능한 상태의 기준은?
대부분 잘 반영이 되었고, 배포 방식은 현재 사용하는 CICD 솔루션의 한계로 Rolling 배포로 확정되었습니다.
Tomcat + 메모리 로딩까지 포함된 구조이다보니 배포 후 WAS 기동시간이 5분가량 소요되는 부분은, 향후 개선과제로 남아있습니다.
그로 인해 타임이벤트 같은 1분 이내의 순간적인 트래픽 폭증에는 반응이 느리다 보니, 이벤트는 사전 리소스 확보로 대응하고, 평시에는 업무 트래픽 패턴에 따라서 자동으로 스케줄링하여 대응하는 방식으로 운영하고 있습니다.
물론 kubernetes 의 hpa(horizontal pod autoscaler)를 통해 cpu 및 세션의 급증 등 사용량증가에 따른 스케일링은 기본적으로 적용되어있습니다.
JDK 변경 이슈
역사가 깊은 시스템이다보니 jdk1.6(free)을 사용하고 있었습니다.
초기에는 소스변경을 최소화 하기 위해 jdk 버전업 등은 이관 이후로 미뤄놨었지만,
보안 이슈와 더불어 TLS1.0, TLS1.1 을 더 이상 지원하지 않는다는 발표가 되었고, 그 다음버전인 TLS1.2를 지원하지 않는 jdk1.6 버전을 올려야 하는 상황이 발생했습니다.
TLS (Transport Layer Security)
https://namu.wiki/w/TLS
기존 계획과 다른 부분이었지만 뛰어난 개발자들과 미들웨어 담당자가 뛰어들어서 큰 이슈 없이 변경이 되었습니다.
Logging
시스템이 컨테이너로 전환됨에 따라 개발자의 서버 접근이 사실상 불가능해졌습니다.
물론 기존 IDC 내에서도 로그를 ES(ElasticSearch)를 통해 저장하고 Kibana로 확인하는 구조 자체는 있었습니다만 많이 사용되지는 않았습니다. 컨테이너 구조로 바뀌면서 이 부분이 강제화되어, 로그시스템 사용이 매우 활성화되는 계기가 되았습니다
로그 시스템도 관리 포인트를 최소화 하기 위해 클라우드의 관리형 서비스로 구성하여 사용하고 있습니다.
STEP4. 어떻게 오픈할 것인가
오픈 시 기존 IDC와 클라우드 환경을 동시에 운영하기 위해 GSLB 개념을 차용했습니다.
Global Server Load Balancing(GSLB)
단순히 IP기반으로 서비스를 넘기는 DNS 서비스의 확장형으로 사용자가 원하는 엔드포인트(서버 or 도메인) 및 정책을 이용해 최적의 장비로 트래픽을 로드밸런싱 해주는 서비스
클라우드의 DNS 서비스를 활용하여 IDC와 클라우드간 가중치를 기반으로 서비스 흐름을 조정하여
1차로 일부 트래픽을 넘겨서 서비스를 최종 검증하고
2차로 부하를 증가하여 실제 시스템의 사용량을 확인하여
3차로는 1,2차의 결과를 바탕으로 100% 클라우드로 트래픽을 넘기는 방식으로 오픈을 하였습니다.
전체가 100% 로 넘긴 이후에도 비상용으로 약 2주간 IDC를 유지했었는데, 예기치 못한 장애나 이슈로 다시 IDC로 긴급 전환을 한 적도 있었습니다.
동시운영이 되지 않았다면 큰 장애로 퍼질수도 있었던 사안들도 있어서 정상적인 서비스 오픈에 큰 도움이 되었습니다.
마치며 . . .
클라우드 이관 스토리를 간단하게 정리해보았습니다.
이관을 준비하고 진행하면서 타 업체의 많은 이관 사례들을 살펴보고 여러 클라우드 사업자의 다양한 이야기를 들었습니다.
그러나 기업의 IT환경이나 서비스는 모두 다르고 각자의 특성이 있기 때문에 결국은 우리 나름대로의 최선의 방안을 찾는 것이 가장 중요한 일이었습니다.
아마도 IDC에서 클라우드로 이관을 생각하는 분들은 대부분 비슷한 절차와 고민을 겪을 것으로 생각됩니다.
GSSHOP Mobile/Web 채널 서비스 지나온 경험의 스토리가 그러한 분들에게 조금이라도 도움이 되시길 바랍니다.
GS Retail 에는 전사 클라우드 서비스를 담당하는 클라우드팀이 있습니다.
전사 클라우드에 대한 방향성을 잡고 아키텍처를 설계하며 고객 서비스를 위한 기술발전을 도모하는 팀입니다.
참고 및 출처
[OpenSSL] OpenSSL Supports TLS 1.2 : https://www.openssl.org/news/changelog.html#x34
[Oracle] JDK 6u121 Supports TLS 1.2 : https://www.oracle.com/technetwork/java/javase/overview-156328.html#R160_121
[karakun Developer Hub] Do I need to pay for Java Now? : https://dev.karakun.com/java/2018/06/25/java-releases.html
[TLS] Namu wiki : https://namu.wiki/w/TLS
'Cloud&Security' 카테고리의 다른 글
| Nginx 기반의 API Gateway 구현(with Python) (0) | 2022.10.07 |
|---|---|
| [SSO] 2편: Aerobase (Keycloak) 클러스터링 & 커스텀 테마 (0) | 2022.05.26 |
| [SSO] 1편: 오픈소스 SSO를 왜 도입하였나요. (0) | 2022.02.07 |
| Flutter 기반의 모바일 앱 재개발 회고 (5) | 2021.11.22 |
| Micro/Mini/Macro Services (0) | 2021.10.06 |