2022년 5월 18일 수요일

클라우드가 보편화 되고 다양한 성공사례들이 등장함에 따라, 자사의 인프라를 클라우드로 옮기려는 시도는 더 이상 낯설지 않다. 클라우드가 갖고 있는 확장성, 유연성, 빠른 Time-to-Market 등의 이점을 취하기 위한 기업들의 이러한 노력은 충분히 이해할 수 있고, 실제로 어플리케이션에서는 큰 고민을 하지 않더라도 이러한 효과를 어느 정도는 누릴 수 있다. 하지만, 데이터가 존재하는 DBMS의 경우에는 이야기가 약간 달라진다.

전통적인 온프레미스 환경에서 DBMS은 철저하게 안정성 높은 고성능의 하드웨어로 구성되어 운영되어 왔다. 클라우드 환경의 안정성과 성능이 증가하고 있다고는 하지만, 그 수준이 대규모 인프라로 가면 갈수록 여전히 대체할 정도는 아닌 경우가 많다. 물론, 온프레미스 환경에서 쓰던 수TB급의 DB는 쉽게 이관할 수 있지만, 어플라이언스 형태로 수백TB를 운영하던 DB는 섵부르게 이관을 시도했다가 상당한 고전을 겪은 경우도 심심치 않게 들을 수 있다. 이러한 원인으로는 아주 많은 이유들을 댈 수 있지만, DBMS가 일반 어플리케이션과 다르다는 데에 근본적인 원인이 있다. 어플리케이션은 비동기적으로 Stateless 하게 운영되어도 큰 문제가 없는 반면, DBMS는 태생이 원칙적으로 데이터에 대한 정합성을 지속적으로 맞추는 Statefull한 아키텍처이기 때문이다. 

따라서, DBMS의 클라우드 이관에 대해서는 적절한 전략이 필요하다. 자사의 시스템에 대한 이해도, 엔지니어들의 역량, 이관 작업의 수행 시간, 이관 후 로드맵에 따라 다양하게 나누어지게 된다. 1 그 전략에 따라 수행하게 되는 이관 방법이 크게 Lift & Shift, Re-Platform to Cloud Service, Re-Architect to Cloud Native 세 가지로 구분할 수 있다. 2

Lift&Shift는 하드웨어에서 돌고 있던 DBMS를 클라우드의 IaaS 위에 옮기는 것이다. DBMS를 단순히 소프트웨어 관점에서 봤을 때, DBMS가 설치된 환경이 일반 하드웨어 환경에서 클라우드 환경으로 바뀌게 되는 것이라고 볼 수 있다. 상대적으로 가장 수월하며, 가장 많은 사용자들이 원하는 이관 방법이기도 하다. 다만, Lift&Shift는 클라우드에서 동일한 환경이 제공이 되어야 한다는 점에서 제한이 있고, 클라우드의 장점을 장기적으로 활용하기에는 추가적인 작업들이 필요하다는 점에서 단점이 있다. 초창기 클라우드로 이관 당시 경험치가 많지 않은 경우 많이 선택했던 방법이다.

Re-Platform to Cloud Service는 PaaS(Managed Service)로 플랫폼을 변경하면서 어느정도의 변환 작업을 수행하는 것이다. 가령, 전체 클라우드를 이관하면서 기존 어플라이언스를 활용하던 부분을 클라우드 서비스로 변경하는 것이 이에 해당한다. 특히, 근래에는 DW 부문에서 이러한 현상이 두드러지는데, Oracle Exadata나 Teradata와 같은 어플라이언스들이 메이저 클라우드 환경에서는 AWS Redshift, Google BigQuery, Azure Synapse 와 같은 서비스로만 제공이 되기에 이관 작업이 필수불가결하다. 근래 가장 많이 선택되고 있는 방법이지만, 실제적으로는 기존의 데이터베이스 교체와 거의 유사하다는 점에서 상당히 복잡한 이관 프로젝트를 수반하기도 한다. 

Re-Architect to Cloud Native는 클라우드의 장점을 최대한 활용할 수 있는 형태로 플랫폼 전체를 재설계하는 것을 의미한다. 이것은 이미 DBMS 변경의 작업이 아니며, 어플리케이션 영역과 궁극적으로 수행하고자 하는 시스템의 미래 방향성의 모습까지 모두 고려하여 아예 새로운 작업을 하는 것과 유사하다. 이 경우에는, DBMS를 사용하던 부분을 아예 재설계 하여 DBMS 대신 다른 솔루션을 사용하는 경우도 간혹 있으며, 최소한 기존에 상당 부분 DBMS에 의존했던 부분의 의존성을 낮추고 클라우드의 확장성을 최대한 활용할 수 있는 형태로 변경하게 된다. 이는 업무와 기술에 대해 모두 깊게 아는 팀이 모여서 함께 작업을 수행해야만 그 성공을 가늠할 수 있다는 점에서, 이 방법을 선택하는 경우는 글로벌하게도 흔하지는 않다.

세 가지 방법을 언뜻 잘못 이해하면, 조직이나 프로젝트 팀의 기술 수준 차이에 따라 선택하게 되는 분류로 느껴지는 경우가 있다. 하지만, 그것은 대단한 오해이며, IT가 비즈니스 환경에 미치는 중요도, 변경 작업에 주어진 시간, 조직의 예산 등에 맞춰서 선택하게 되는 문자 그대로 “전략”이다. 

다음 글에서는 근래에 많이 일어나고 있는, Re-Platform to Cloud Service의 구체적인 예를 하나 들어 실질적으로 DB의 Cloud Migration 시에 고려해야 하는 사항들을 소개하고자 한다.

(* Re-Architect to Cloud Native에 대한 내용은 Data Lake 를 다룬 글을 참조하면 된다.)

  1. 9 Steps for Migrating Databases to the Cloud
  2. Cloud-Native or Lift-and-Shift?

    Related Posts

    Stored Procedure에 대한 단상
    클라우드 환경에서의 데이터베이스 가용성
    Cloud 환경에서의 효율적인 보안 및 인증 관리

    1 Response

    Leave a Reply