[기고] 엔터프라이즈 공개SW 클라우드 전환

엔터프라이즈 기업의 데이터센터가 변화하고 있다. 유닉스 기반의 경직된 시스템 환경에서 스케일 아웃을 통한 확장성 있는 인프라로의 변화를 위하여 많은 기업들이 소프트웨어 정의 데이터센터(SDDC:Software Defined Data Center)를 외치고 있는 실정이다.

현재 데이터센터를 자체적으로 보유한 기업들 조차도 신규 서비스 기획 시 사업에 대한 불명확성, 시장 반응들을 살펴볼 수 있는 시스템을 만들기 위하여 하드웨어를 구매하고, 상용 소프트웨어로 도배된 데이터센터 기반 시스템의 사용에 대해 의문을 가지고 있으며, 일부 서비스를 클라우드 서비스 혹은 하이브리드 방식의 클라우드로의 전환을 검토하고 있으며 또한 진행중이다.

퍼블릭 클라우드 시장도 급속도로 팽창하고 있으며, IaaS, PaaS 시장은 AWS, Google, 마이크로소프트 등의 대형업체로 통합되고 있다. 이들 대형업체는 신규 서비스를 지속적으로 내놓고 있으며, 자신들의 강점 분야를 내세워 데이터센터 고객의 자사 클라우드 유도와 하이브리드 운영 방안에 대한 레퍼런스를 지속적으로 내놓고 있는 상황이다.

가트너에 따르면 클라우드 애플리케이션 서비스(SaaS)는 클라우드 시장에서 가장 큰 비중을 차지한다. 전세계 퍼블릭 클라우드 시장에서 해당 분야의 매출은 2019년 948억달러에서 2022년에는 1437억달러로 증가할 것이라는 전망이다. 한국의 경우 퍼블릭 클라우드 서비스 시장에서 SaaS가 가장 큰 비중을 차지한다. 국내 SaaS 최종 사용자 지출액은 2018년 약 7787억원에서 지속적으로 증가해 2022년에는 약 1조5745억원에 이를 것으로 예상된다. 

전환의 이유는 무엇인가?

국내 대기업의 데이터센터는 그룹사의 IT를 담당하는 회사에서 관리를 주로 하고 있으며, 오픈스택 또는 가상화 기반 하의 클라우드라는 명칭으로 각 그룹 고객사에 서비스를 제공하려 많은 노력들을 기울이고 있다. 내부의 IT 자원의 성능이 훨씬 더 압도적일 것이라 대부분 판단하지만 퍼블릭 클라우드 서비스 업체가 물리 자원에 대한 액세스를 너무나 잘 관리하기 때문에 그 차이가 많이 나지 않는 것이 일반적이다.

또한 서비스들은 내부 ITSM 시스템의 관제하에 들어가게 되므로 클라우드 컴퓨팅이 제공하는 가치의 많은 부분이 민첩성에서 나온다는 점에서 이를 포기하고 데이터 센터만을 고집하는 것도 좋은 방향은 아닐 것이다. 이로 인해 퍼블릭 클라우드에 대한 도입 검토와 개념검증(PoC), 실제 전환이 활발하게 이루어지고 있는 실정이다.

일반적으로 클라우드 전환 후 종속성(lock-in)에 대해서 우려를 하는 기업들도 있겠지만 그러한 종속성은 데이터 센터가 훨씬 더 심하며, 기업은 다양한 서버와 운영체제, 애플리케이션, 어플라이언스를 선택하고 원하는 특정 결과를 얻기 위한 과정일 뿐이다.

어떻게 전환할 것인가?

클라우드 전환에 있어 중요한 한 가지는 클라우드라는 트렌드에 대한 기업의 ‘적응력’과 ‘변화에 대한 의지’가 가장 클 것이다. 예를 들어 대한항공의 경우 모든 기간계 시스템을 아마존 퍼블릭 클라우드로 이동하는것을 목표로 하고 있으며 소프트웨어 중심에는 공개SW가 위치하고 있다.
                                                         (- 대한항공이 AWS에 올인하는 이유: https://www.zdnet.co.kr/view/?no=20181128110108 )

퍼블릭 클라우드로 전환할 수 있는 단계는 여러 가지가 있을 수 있지만 우선 크게 3단계에 대한 전환 절차를 고려할 수 있다.

첫번째 단계로 대상 시스템 선정 및 기술이다. 기존의 내부 시스템에 대한 조사를 통해 퍼블릭 클라우드의 유연성(오토스케일링 같은)을 통해 그 효과를 즉시 확인할 수 있는 시스템들이 그 대상이 될 수 있다. 이러한 시스템에 대한 AS-IS 현황 분석을 통해 클라우드 전환 시 TO-BE 아키텍처를 그릴 수 있다. 이 때 중요한 것은 전체 업무 대상 시스템이 아니며, 현재 가장 손쉽게 올릴 수 있는 WEB-WAS-DB 아키텍처를 가진 트래픽의 양 변화가 큰 업무들이 대상이 될 수 있다.

그 업무 시스템에서 사용하는 기술들이 클라우드로 전환됐을 때, 그대로 옮겨갈 것인지 AWS와 같은 클라우드의 네이티브 서비스(예: ELB, RDS, DynamoDB)를 활용할 것인지도 중요한 결정 사항이 될 것이다.

두번째 단계로는 시스템 전환이다. 대부분의 큰 기업에서는 내부의 데이터센터와 클라우드를 연결하는 것을 기본 전제로 하고 있다. 이 때 서비스를 어떻게 구성할 지 검토를 하게 되는데, 보통 퍼블릭 클라우드에서는 아래의 방식으로 서비스들을 제공하고 있다.

그림1. 기업의 퍼블릭 클라우드 연결 방식

기업 내의 데이터 센터와의 연결 시 전용선(비용 상승) 방식과 VPN을 통한 퍼블릭 클라우드 네트워크 연결을 고려할 수 있으며, 비용과 안정성 측면에서 장단점이 존재하므로 전환 시 의사결정이 필요한 부분 중 하나이다.

이후 클라우드 시스템 내의 목표 시스템 설계, 기술 아키텍처를 정의하고 기존의 베어메탈 방식에서 활용되던 개념을 스케일-아웃형 시스템으로 전환 설계 후 전환 작업을 진행한다. 전환 단계 상에서 성능, 안정성, 확장성 테스트를 통해 해당 시스템이 처리할 수 있는 능력을 정확하게 파악하고 이를 기준으로 향후 신규 온디맨드 시스템들이 필요한 경우 지표로 삼을 수 있어야 한다.

전환의 방식은 크게 아래와 같이 들 수 있다.

전환에 대한 목표와 시스템 소프트웨어의 변경에 대한 예시는 다음의 그림과 같다. 

그림2. 클라우드 목표모델 레이어 및 시스템 소프트웨어 변화

마지막 단계로 운영 서비스로의 이행이다. 전환 이후 전체 시스템에 대한 기능, 성능에 대한 상세 모니터링을 진행하고 필요 시 인스턴스 개수 조절, 사이즈 조정 등을 통해 비용 최적화 작업을 진행한다.

이 때 DevOps를 기반으로 한 운영 서비스를 전제로 하고 DevOps로의 전환 (클라우드와 DevOps 툴을 통해 개발자 중심의 자동화 환경 구축 -> 지속적인 배포(CD, Continuous Delivery) 가 가능하게 함으로써 효율성을 확보하고 개발자의 생산성과 비즈니스 민첩성 향상을 위한 기초를 만들 수 있도록 해야 한다.

기업이 가진 시스템에 대한 클라우드 전환은 빅뱅이 되어서는 안된다. 현재는 차세대 개념의 빅뱅형이 아닌 점진형 방식의 전환을 통해 리스크를 최소화할 수 있는 전략을 구상해야 한다. 전환 이후에도 트렌드로 자리 잡아가고 있는 마이크로서비스 아키텍처, 컨테이너로의 확장과 자동화를 염두에 둔 전환이 필요한 시점이며, 이를 위한 조직/운영의 관점도 달라져야 할 것이다.