애플리케이션을 클라우드로 마이그레이션하시나요? 먼저 이것부터 읽어보세요.
소개
이제 클라우드 컴퓨팅 환경은 IT 환경의 주류로 자리 잡았으며, 조직들은 기존 온프레미스 애플리케이션을 점점 더 빈번하게 클라우드로 이전하고 있습니다. 하지만 애플리케이션을 클라우드로 마이그레이션하려면 단순히 클라우드 공급자의 가상 머신으로 옮기는 것 이상의 작업이 필요합니다. 조직마다 클라우드 마이그레이션을 추진하는 동기는 다르지만, 모든 조직이 고려해야 할 핵심 요소가 있으며 성공적인 클라우드 마이그레이션을 보장하는 데 도움이 되는 모범 사례도 분명히 존재합니다. 클라우드 마이그레이션의 이점을 최대한 활용하려면 애플리케이션 아키텍처와 온프레미스에서 클라우드로의 전환을 모두 사전에 계획해야 합니다.
개요
클라우드와 온프레미스: 주요 차이점
클라우드 환경은 온프레미스 환경과 다르게 작동합니다. 두 환경의 차이점 중 일부는 명확합니다. 예를 들어 컴퓨팅 리소스를 내부에서 소유하고 관리하는 대신 다른 기업이 소유하고 관리한다는 점입니다. 그러나 가장 중요한 차이점 중 몇 가지는 기술 자체에서 비롯되는 것이 아닙니다. 일반적으로 클라우드 제공업체에서 이용할 수 있는 모든 기술은 온프레미스에서도 이용할 수 있습니다. 클라우드가 제공하는 것은 대체 기술이 아니라 대안적인 소비 모델입니다. 다시 말해, 클라우드 제공업체로 이전할 때의 이점은 컴퓨팅 리소스 자체가 아니라 컴퓨팅 리소스를 사용하는 방식에 있습니다.
클라우드 공급자는 온프레미스 하드웨어용으로 설계된 데이터 감사 규정 준수 정책과 같은 모든 온프레미스 기능을 그대로 제공할 수는 없습니다. 클라우드 구성 요소는 지리적으로 분산되어 있으므로 일반적으로 클라우드 배포 환경에서는 지연 시간이 더 깁니다. 클라우드 공급자에게는 이 밖에도 여러 제약이 있습니다. 공급자는 모든 고객에게 공통된 표준을 적용하므로 컴퓨팅 환경을 사용자 지정하는 데 실질적인 한계가 있습니다. 예를 들어, 희귀하거나 특수한 컴퓨팅 장비를 제공하는 클라우드 공급자는 거의 없습니다.
하지만 기업이 이러한 제약 내에서 운영할 수 있다면, 클라우드 공급자는 대부분의 기업이 자체적으로는 구현하기 어려운 수준의 리소스 사용 역량을 제공할 수 있습니다. 클라우드 공급자는 전 세계에 데이터 센터를 운영하여 조직이 컴퓨팅 리소스를 배치할 데이터 센터를 선택할 수 있도록 할 수 있습니다. 또한 고정 비용을 부담함으로써 기업이 실제로 사용한 리소스에 대해서만 비용을 지불할 수 있게 합니다. 클라우드 공급자는 대부분의 기업이 따라올 수 없는 규모의 경제를 갖추고 있으므로 배포를 관리하고 자동화하는 시스템에 대규모로 투자할 수 있습니다. 이러한 이점은 기술적인 성격의 것이 아니라는 점에 유의해야 합니다. 클라우드 공급자의 장점은 소비자가 선택할 수 있는 옵션과 비용 구조에 있습니다.
클라우드 공급자의 한계를 완화하고 장점을 활용하려면 IT 부서는 애플리케이션 배포 방식을 바꾸어야 합니다. 즉, 클라우드 공급자의 상대적인 강점을 최대한 활용하는 동시에 지연 시간처럼 클라우드 환경에 불리한 특성에 대한 의존은 피하도록 워크플로를 변경해야 합니다.
클라우드 마이그레이션의 동기
비용 절감은 클라우드로 이전하는 주요 동기로 흔히 언급되지만, 실제 이유는 좀 더 복합적인 경우가 많습니다. 대부분의 동기는 확실성, 생산성, 민첩성이라는 세 가지 범주로 나뉩니다.
퍼블릭 클라우드 제공업체는 기술을 보다 쉽게 활용할 수 있도록 패키지화함으로써 예측 가능성을 높이고, 그 과정에서 IT 운영 위험의 일부를 부담합니다. 제공업체가 인프라를 유지 관리하고 책임지므로 조직은 이러한 문제를 신경 쓰지 않아도 됩니다. 또한 클라우드 제공업체는 일반적으로 IT 운영 현황을 파악할 수 있는 도구를 제공하여 가시성을 높입니다. 퍼블릭 클라우드 비용은 대체로 사용량에 따라 결정되므로, 조직은 애플리케이션이 제공하는 이점(예: 매출)을 해당 애플리케이션의 운영 비용과 더욱 긴밀하게 연계할 수 있습니다. 애플리케이션 사용량이 늘어나면 비용도 증가하지만 그에 따른 이점도 커집니다. 비용을 자본 지출에서 운영 지출로 전환하면 구매 결정 시 향후 성장에 대비해 여유 용량을 확보해야 할 필요성이 줄어듭니다. 이러한 불확실성을 클라우드 제공업체 차원에서 관리하면 측정 가능한 이점을 얻을 수 있습니다.
퍼블릭 클라우드를 도입하는 또 다른 이유는 생산성 향상입니다. 제공업체가 제공하는 협업 및 자동화 도구는 시중에서 가장 발전된 도구에 속합니다. 또한 인프라를 직접 관리하지 않아도 되므로 IT 직원은 비즈니스 전략적 업무에 집중할 수 있으며, 어디서나 관리할 수 있는 간소화된 운영 환경은 IT 직원의 생산성을 높여 줍니다.
퍼블릭 클라우드를 도입해야 하는 마지막 이유는 아마도 가장 설득력 있는 민첩성일 것입니다. 클라우드 제공업체는 언제든 무한한 리소스를 사용할 수 있는 것처럼 지원하므로, 비즈니스 활동의 속도와 방향이 더 이상 IT 프로비저닝의 제약을 받지 않습니다. 리소스는 몇 초 또는 몇 분 안에 배포할 수 있습니다. 프로젝트가 종료될 때 하드웨어를 폐기할 걱정 없이 복잡한 컴퓨팅 환경을 단기간 사용할 수 있습니다. 하드웨어 자산에 대한 걱정 없이 애플리케이션을 신속하게 배포하고 확장하거나 제거할 수 있습니다.
클라우드 마이그레이션의 장벽
클라우드 마이그레이션에는 많은 이점이 있지만, 마이그레이션을 추진하는 과정에서 여러 과제에 직면할 수 있습니다. 장애 요인과 위험은 마이그레이션 프로세스 중 어느 단계에서 발생하는지, 즉 마이그레이션 전, 마이그레이션 중, 마이그레이션 후인지에 따라 달라집니다. 이러한 장애 요인과 위험에 미리 대응하면 마이그레이션에 성공할 가능성이 높아집니다.
마이그레이션 전 계획은 마이그레이션 프로세스에서 가장 중요한 부분일 수 있습니다. 클라우드 기능을 활용할 수 있도록 애플리케이션 아키텍처를 재설계하지 않으면 마이그레이션이 실패할 수 있습니다. 또한 이 시기는 애플리케이션의 복잡성을 파악하고 관리하기 시작하기에 적절한 때입니다. IT 교육 역시 프로젝트 초기에 실시해야 합니다. 클라우드 배포는 사일로화된 실행과 도구의 난립으로 이어지는 경향이 있으므로, 초기 단계에서 계획을 수립하면 마이그레이션 프로세스를 원활하게 진행하는 데 도움이 됩니다.
애플리케이션을 클라우드로 마이그레이션하는 작업은 처음 계획했던 것보다 더 오래 걸리고 복잡해지는 경향이 있습니다. 문제를 최소화하려면 규모가 작고 비교적 독립적인 애플리케이션부터 시작하여 발생하는 문제의 영향을 최소한으로 줄이십시오. 소규모 애플리케이션의 첫 번째 마이그레이션에서 얻은 교훈은 향후 마이그레이션에 적용할 수 있습니다.
마이그레이션이 완료된 후에는 장기적인 문제가 드러나기 시작합니다. 클라우드 환경에서는 보안 경계를 정의하기가 더 어렵기 때문에 보안 및 규정 준수 문제가 발생할 수 있습니다. 기존 시스템과 신규 시스템이 서로 다른 환경에 있을 뿐만 아니라 서로 다른 문화 속에서 개발된 경우, 레거시 시스템을 지원하기가 더 어려울 수 있습니다. 일부 조직에서는 특히 컨테이너가 부상하면서 특정 클라우드에 대한 종속을 우려하고 있습니다. 마지막으로, 변동성이 큰 클라우드 비용은 분기별로 예측하기 어려울 수 있어 예산 문제가 발생할 수 있습니다.
마이그레이션할 앱을 선택하는 방법
애플리케이션을 평가하는 한 가지 방법은 성숙도와 위치를 기준으로 한 매트릭스를 활용하는 것입니다. 애플리케이션을 검토하여 어느 정도의 성숙도가 필요한지 판단하세요. 경쟁 우위를 제공하거나 틈새시장을 겨냥한 애플리케이션은 온프레미스 환경에서 운영하는 것이 가장 적합할 수 있습니다. 반면, 저비용 또는 비용 우위가 중요한 애플리케이션(특히 변경 비용이 중요한 경우)은 클라우드 환경에 적합한 경우가 많습니다. 확장성도 고려해야 할 요소입니다. 새 애플리케이션을 배포했으며 향후 현재 부하의 100배까지 확장될 수 있다고 가정해 보겠습니다. 온프레미스 배포 환경에서 증가하는 수요에 미리 대비하려면 인프라를 필요 이상으로 대폭 확충해야 하므로, 유휴 리소스에 대한 추가 자본 비용이 발생합니다. 그러나 동일한 애플리케이션을 클라우드 환경에 배포하면 성장에 따라 비용도 늘어나므로 리소스를 미리 과도하게 확충할 필요가 없습니다.
클라우드 환경으로 마이그레이션할 애플리케이션을 결정할 때 네트워크 문제도 고려해야 할 수 있습니다. 광범위한 대리점 네트워크처럼 분산된 사용자의 비율이 높거나 원격 이메일 사용자가 상당히 많은 애플리케이션의 경우, 온프레미스 배포에서는 이러한 트래픽이 모두 데이터 센터로 집중됩니다. 이 트래픽은 이미 인터넷을 통해 전송되고 있으므로 해당 애플리케이션은 지연 시간에 민감하지 않습니다. 이러한 애플리케이션을 클라우드 환경에 배치해도 네트워크 지연 시간은 달라지지 않지만, 분산된 사용자로 인해 소모되었을 온프레미스 데이터 센터의 대역폭을 확보할 수 있습니다.
동시에 일부 앱을 온프레미스에 유지해야 할 이유도 있습니다. 예상 수명이 짧은 애플리케이션은 마이그레이션에 따르는 위험과 비용을 감수할 가치가 없을 수 있습니다. 일부 앱은 짧은 네트워크 지연 시간과 빠른 스토리지 속도에 의존하므로 클라우드 환경에서는 성능이 크게 저하될 수 있습니다. 규정 준수 및 보안 문제도 앱을 온프레미스에 유지하는 주된 이유로 자주 거론됩니다. 일부 감사 절차에서는 데이터를 검증하기 위해 시스템과 데이터에 물리적으로 접근할 수 있어야 한다고 전제하며, 애플리케이션과 운영 체제가 베어 메탈에서 실행되어야 한다고 요구하는 절차도 있습니다. 즉, 가상 머신에서는 실행할 수 없습니다. 시간이 지나면 규정 준수 절차도 클라우드 환경을 수용하게 되겠지만, 아직은 그렇지 않은 경우가 많습니다. 애플리케이션을 클라우드로 이전해 규정 준수 감사에 실패할 위험을 감수하기보다는, 당분간 이러한 민감한 앱을 온프레미스에 유지하는 편이 더 합리적일 수 있습니다. 일부 앱은 레거시 시스템과 프로세스를 지원해야 하므로 클라우드에서 작동하도록 아키텍처를 재설계하기가 현실적으로 어렵습니다. 이러한 앱 역시 온프레미스에 남겨 둘 후보가 될 수 있습니다. 따라서 일부 앱은 클라우드 환경에 더 적합한 앱보다 마이그레이션 우선순위를 낮게 설정해야 합니다.
온프레미스에 유지하는 것이 더 적합한 애플리케이션
- 수명이 짧을 것으로 예상되는 애플리케이션
- 낮은 지연 시간이 필요한 앱
- 규정 준수 문제가 우려되는 앱
- 레거시 시스템을 지원하는 앱
전환 시 고려 사항
많은 조직이 마이그레이션 과정에서 여러 과제를 극복해야 합니다. 이때 해결해야 할 주요 문제 중 하나는 실제 전환을 어떻게 수행할 것인가입니다. 한 가지 방법은 클라우드 애플리케이션을 충분히 테스트할 때까지 DNS가 온프레미스 애플리케이션을 가리키도록 유지한 다음, 클라우드 애플리케이션을 가리키도록 DNS 레코드를 변경하는 것입니다. DNS에는 클라이언트가 일정 시간 동안 DNS 응답을 캐시할 수 있게 하는 TTL(Time to Live) 값이 있습니다. 전환 전에 TTL을 몇 초 정도로 짧게 설정하면 전환 후 클라이언트가 새 애플리케이션의 주소를 신속하게 확인할 수 있습니다. 그러나 이 방법에는 몇 가지 위험이 따릅니다. TTL을 낮추면 DNS 트래픽과 서버 부하가 크게 증가할 수 있습니다. 일부 조직에서는 TTL을 무시하고 지정된 시간보다 오래 캐시할 수 있으므로, 전환이 완료된 후에도 일부 사용자가 상당 기간 온프레미스 애플리케이션에 연결될 수 있습니다. 이 방법을 사용하기 전에 DNS 인프라의 안정성을 테스트하는 것이 좋습니다.
전환 과정에서는 테스트 중에 발견되지 않았던 새 애플리케이션의 문제점이 드러날 수도 있습니다. 애플리케이션에 문제가 발생할 가능성에 대비하는 한 가지 방법은 문제 발생 시 처리를 온프레미스 애플리케이션으로 되돌릴 수 있는 대체 계획을 마련하는 것입니다. 하지만 양방향 전환은 데이터 동기화를 복잡하게 만들기 때문에 훨씬 더 많은 사전 계획과 테스트가 필요합니다. 보다 정교한 접근 방식으로는 카나리 테스트라는 부분 전환을 사용할 수 있습니다. 이는 일부 사용자를 클라우드 애플리케이션으로 전환한 후 해당 애플리케이션을 모니터링하는 방식입니다. 애플리케이션에 대한 신뢰도가 높아지면 더 많은 사용자를 전환하고, 최종적으로는 모든 사용자를 전환할 수 있습니다. 반대로 문제가 발생하면 전환된 사용자를 다시 온프레미스 애플리케이션으로 되돌릴 수 있습니다. 카나리 테스트는 프로그래밍 가능한 ADC(Application Delivery Controller)에서 F5® iRules®를 통해 수행할 수 있으므로, 위험을 최소화하는 동시에 전환 기간에 운영 팀이 선택할 수 있는 옵션을 늘릴 수 있습니다.
권고 사항
클라우드에 맞게 앱을 다르게 구축하기
조직이 애플리케이션을 마이그레이션할 때 저지르는 가장 큰 실수 중 하나는 클라우드에 맞게 애플리케이션 아키텍처를 재설계하지 않는 것입니다. 클라우드 환경의 차이점을 활용할 수 있도록 애플리케이션 구조를 변경하는 데 시간을 투자하면 상당한 이점을 얻을 수 있습니다.
예를 들어 클라우드 환경에서의 확장은 온프레미스 환경에서의 확장에 비해 매우 간단합니다. 최악의 부하를 기준으로 애플리케이션을 설계하고 테스트하는 대신, 가볍지만 확장 가능하도록 설계해야 합니다. 애플리케이션 사용량이 매우 폭넓게 변동하는 경우에도 대규모 운영 환경에 따른 오버헤드를 계속 유지할 필요가 없습니다. 대신 작게 구축하고 필요할 때 확장할 수 있도록 준비하십시오. 마찬가지로 정전과 같은 일부 장애는 클라우드 환경에서 발생할 가능성이 더 낮으므로, 이러한 장애에 대비한 아키텍처를 설계할 필요성도 줄어듭니다.
반면, 클라우드 환경에는 온프레미스에서는 일반적으로 겪지 않는 새로운 제약이 있습니다. 클라우드 아키텍트들은 정상적인 처리 과정에서도 언제든지 VM 인스턴스에 장애가 발생할 수 있음을 고려해 설계해야 한다고 강조합니다. 클라우드 환경에서는 스토리지도 다릅니다. 온프레미스 설계에서는 일반적으로 로컬 블록 스토리지를 사용합니다. 클라우드 환경에서도 같은 옵션을 사용할 수 있지만 공유할 수는 없습니다. 공유되지 않는 로컬 상태와 인스턴스 장애가 결합되면 심각한 문제가 발생할 수 있습니다. 객체 기반 스토리지나 키-값 스토리지 서비스와 같은 다른 스토리지 패러다임도 있습니다. 애플리케이션을 재설계하면 클라우드 환경의 제약에 대비할 수 있습니다.
온프레미스에 유지할 항목 고려하기
일부 애플리케이션이나 제어 시스템은 온프레미스에 유지하는 것이 합리적입니다. 많은 조직이 Active Directory를 온프레미스에 유지하면서 페더레이션을 활용해 ID를 클라우드 환경으로 확장합니다. 마찬가지로 ADC는 애플리케이션 제공을 지원하기 위해 방화벽, 웹 애플리케이션 방화벽, DDoS 방어, SSL/TLS 인터셉트 및 서비스 체이닝과 같은 다양한 보안 서비스를 제공합니다. 또한 ADC는 고급 트래픽 관리와 프로그래밍 가능한 프록시뿐만 아니라 ID 및 액세스 관리 기능도 제공합니다.
조직은 일반적으로 이러한 애플리케이션 서비스가 비즈니스 로직의 일부가 아니라 운영상의 고려 사항이므로 애플리케이션 외부에 통합해 왔습니다. 많은 기업은 애플리케이션 릴리스 일정과 관계없이 운영 환경을 변경할 수 있도록 ADC를 전략적 제어 지점으로 활용하여 모든 애플리케이션에 적용할 수 있는 도메인 전문 지식을 집중시킵니다. 그러나 클라우드 환경에서는 이러한 모델이 달라집니다.
클라우드 환경에서 애플리케이션을 제공하기 위해 초기에 사용된 접근 방식은 각 클라우드 환경의 네이티브 도구를 사용하여 ADC 서비스를 복제하는 것이었습니다. 그러나 곧 클라우드 제공업체마다 제공하는 네이티브 기능의 수준이 동일하지 않다는 사실이 드러났고, 이에 따라 조직은 클라우드와 온프레미스 환경에서 서로 다른 애플리케이션 제공 표준을 유지하거나 모든 애플리케이션을 최소 공통 수준에 맞게 재설계해야 하는 선택에 직면했습니다.
기업이 여러 클라우드 환경으로 확장하면서 두 가지 선택지 모두 매력이 떨어졌습니다. 한 조직이 세 곳의 클라우드 공급자를 이용하면서 온프레미스 데이터 센터도 운영한다고 가정해 보겠습니다. 이 조직은 SSL/TLS 전문 역량과 DDoS 전문 역량 등을 각각 네 벌씩 유지하거나, 갈수록 더 파편화되고 제한적인 기본 서비스 집합을 표준으로 채택해야 했습니다. 클라우드 환경을 하나 더 추가해 신규 애플리케이션 단 하나를 배포하는 데도 해당 분야의 전문가를 추가로 확보하거나 기존의 모든 애플리케이션에 적용할 새로운 표준을 마련해야 하는 등 상당한 한계 비용이 발생했습니다.
하지만 모든 환경에서 일관된 서비스를 제공할 수 있는 세 번째 선택지가 있습니다. F5 Application Connector를 사용하면 애플리케이션이 어디에 있든 하나의 도메인 전문가 팀이 모든 애플리케이션을 관리할 수 있습니다. 조직은 기존 BIG-IP® 하드웨어 또는 소프트웨어 어플라이언스를 사용하여 위치와 관계없이 모든 애플리케이션의 프런트엔드에 완전한 고급 애플리케이션 서비스를 적용할 수 있으며, 이를 통해 하나의 도메인 전문가 팀이 관리하는 전략적 제어 지점을 모든 애플리케이션에 제공할 수 있습니다. 또한 Application Connector는 외부에 노출되는 모든 공용 IP 주소를 제거하여 공격 표면을 줄이고 보안을 강화합니다. 암호화 키를 클라우드 인스턴스가 아닌 중앙에 저장하므로 조직은 중요한 암호화 정보가 비공개로 유지된다는 확신을 가질 수 있습니다. 마지막으로 Application Connector는 프록시 인스턴스가 새로운 워크로드 노드를 자동으로 검색할 수 있도록 하여 클라우드 배포의 효율성을 높입니다.
스토리지를 신중하게 고려하세요
온프레미스 애플리케이션과 클라우드 애플리케이션의 가장 큰 차이점 중 하나는 애플리케이션 상태를 저장하는 방식입니다. 온프레미스 설계에서는 대부분 하드 디스크나 솔리드 스테이트 드라이브와 같은 로컬 블록 스토리지를 사용합니다. 클라우드 애플리케이션에서도 블록 스토리지를 사용할 수 있지만, 이 스토리지는 인스턴스에 종속되므로 인스턴스에 장애가 발생할 수 있음을 고려해 설계해야 합니다. 조직이 애플리케이션을 클라우드로 이전하면서 설계의 다른 부분을 전혀 변경하지 않더라도, 상태를 처리하는 방식만큼은 바꿔야 합니다.
일반적인 클라우드 스토리지 유형 중 하나는 객체 스토리지입니다. 각 객체는 본질적으로 파일이지만 이름을 사용해 접근합니다. 일반적으로 스토리지의 계층 구조는 최대 한 단계(예: 폴더 또는 디렉터리)뿐이므로 기존 파일 시스템을 객체에 매핑하기가 어려울 수 있습니다. 객체는 편집할 수 없고 생성, 읽기, 삭제만 가능하므로 객체 스토리지는 이미지와 같은 정적 콘텐츠에는 적합하지만 상태 저장에는 적합하지 않습니다. 많은 애플리케이션은 파일을 수정할 수 있다고 가정하므로 이러한 애플리케이션은 객체 스토리지에서 작동하지 않습니다.
그 밖의 스토리지 옵션으로는 키-값 저장소와 기존의 트랜잭션 데이터베이스가 있습니다. 이들은 파일 시스템과 같은 스토리지는 아니지만 데이터를 저장하며 부가 서비스로 제공됩니다. 효과적으로 설계하면 상태를 키-값 저장소나 데이터베이스 서비스에 저장할 수 있습니다.
핵심: 마이그레이션 전에 준비하세요
클라우드 컴퓨팅 환경은 여러 이점을 제공하지만, 핵심 애플리케이션을 재설계하여 클라우드의 제약으로 인한 영향을 완화하는 동시에 클라우드 기능을 활용할 수 있어야만 이러한 이점을 누릴 수 있습니다. 클라우드 환경은 장애 발생 양상이 다르고 네트워크 지연 시간이 늘어나는 경우가 많지만, 신속하게 확장할 수 있고 전 세계의 데이터 센터를 선택할 수 있습니다. 클라우드로 마이그레이션할 때는 어떤 애플리케이션을 이전하고 어떤 애플리케이션을 온프레미스에 유지할지 결정해야 합니다.
전환 프로세스 자체도 신중하게 검토하고 계획해야 하며, 클라우드 애플리케이션이 예상대로 작동하지 않을 경우에 대비한 원복 계획도 마련해야 합니다. 계획 수립 과정에서 일부 조직은 애플리케이션이 어디에 호스팅되어 있든 모든 애플리케이션을 제어할 수 있는 전략적 거점으로 온프레미스에 ADC를 유지합니다. 마지막으로, 클라우드 애플리케이션이 데이터와 상태를 저장하는 방식을 면밀히 계획해야 합니다. 애플리케이션과 비즈니스를 어떤 방식으로 클라우드로 이전하든, 경험이 풍부한 클라우드 파트너와 함께하는 것을 고려해 보십시오.
2017년 8월 16일 게시