※ 해당 포스팅은 개인적인 클라우드 전환(IaaS)에 관한 생각을 다루고 있습니다.
클라우드 전환에 대한 정확한 분석 및 가이드는 어렵습니다.
업무를 하다보면 내 의지와는 다르게 여러 일을 겪는 것 같다.
클라우드 전환도 이에 포함이었다.
기존 VM 서버를 잘 이용하고 있었지만 Azure 클라우드로 전환해야 한다는 지침이 내려왔고,
직접 클라우드 서버를 구축하는 건 아니었지만
Application 담당자인 나는 전환에 필요한 시스템 정보 등을 지원하는 역할이었다.
그 전환 과정을 대략 아래처럼 정리해보았다.
직접 작업을 했다면 정확히 알았을텐데...
업무 영역이 분리되었기에 참여도가 높진 않았기에 지금 생각해보면 조금 아쉬운 부분이다.
기존 VM 서버 -> 클라우드 전환
1. 기존 VM 서버 분석
- 트래픽량 (Transaction 수)
- OS 종류 (Windows NT, Linux)
- WEB/WAS 확인 (WebToB/Jeus, Apache/Tomcat, ...)
- DB 용량
- 연관 제휴 서비스와 인터페이스 현황
- JDK version 확인
예로 WAS와 JDK version이 변경되거나 업데이트 되면 Source 단에서 영향이 미칠 수 있고,
기존 Library 지원하던 Function을 지원 안 하거나 그래서 필요한 부분은 따로 개발을 해야 한다던지 말이다.
전환 전에는 서비스는 꼼꼼히 분석해야 한다.
2. 적정량 클라우드 서버 구축
- 서비스 비즈니스 모델과, 트래픽량 등 전체적인 설계를 통해 적정량의 클라우드 서버 모델을 선택해야 한다.
3. ER(Express Route) 전용망 설치
- ER은 온-프레미스 or (공동 장소 환경의 인프라)와 Azure 데이터 센터 사이에 개인 연결을 만들 수 있게 해주는 서비스라고 한다. (아래 출처)
- 이를 통해 이용요금을 책정을 하기도 한다고 한다.
azure.microsoft.com/ko-kr/pricing/details/expressroute/
가격 - ExpressRoute | Microsoft Azure
개인 데이터 센터 연결 생성을 위한 클라우드 통합 솔루션인 Azure ExpressRoute에 대한 자세한 가격을 확인하세요. 사용한 만큼 지불하세요. 무료 평가판입니다.
azure.microsoft.com
4. 전환 방법 결정
4.1. VM 이미지 복사
- 기존 VM 서버의 이미지를 떠서 복사하는 방법인데, 시간이 너무 오래 걸리는 것 같다.
- 실제 운영서버의 이미지를 뜬다면 Risk 산정이 필요하다.
4.2. 직접 설치
- 서버 안에서 직접 설치하는 방식
- 이미지를 복사하는 건 시간 상 비효율로 판단되어 실제로 직접 설치하는 방법을 택했다.
5. 네트워크 망 정리(실제 작업은 네트워크 팀에서 진행하여 자세히 알지는 못한다)
- ER 구축을 통해 네트워크 망을 구축한 뒤 사설망을 통해 서버 접근이 가능하다.
- 서비스와 관련 서비스의 방화벽을 허용 시키는게 만만치 않았었다.
내 쪽에서의 Outbound와 상대편의 Inbound 허용이 필요하고,
Azure의 경우 NSG(Network Security Group) 으로 방화벽을 제어하는 부분이 있었다.
한편으론 OS 방화벽 확인도 NSG외 필수로 확인해야 하는 부분이라고 생각한다.
- 외부망에선 AG(Application Gateway) 를 통한 Domain(예, ryan-king.tistory.com 등)만 접근이 가능하다.
-> 내부망에서 내부 DNS 서버를 통해 내부 통신을 할 수 있다.
6. 클라우드 서버 배포하기(war파일)
- 맡았던 업무에선 Jenkins 처럼 특별한 배포 툴은 없고, war 파일을 생성하여 직접 서버 접근하여 톰캣을 재기동을 했었다.
- 이후 다른 업무에서는 Jenkins를 사용하긴 했는데, 역시 많이 알아서 개선 할 것도 보이고 하는 것 같다.
짧은 전환 기간으로 힘은 들었지만 새로운 지식을 알게되어서 좋았던 경험이다.
하지만 매번 생각하는게 정말 공부할 게 많다고 느낀다.