엔터프라이즈 앱을 클라우드로 리프트 앤 시프트하기: 따라야 할 5가지 원칙(그리고 깨야 할 1가지 원칙)
엔터프라이즈 애플리케이션을 퍼블릭 클라우드로 이전하려는 조직은 해당 애플리케이션이 데이터 센터에서 의존해 온 애플리케이션 딜리버리 서비스도 함께 이전해야 합니다. 또한 클라우드 마이그레이션은 보안 및 액세스 체계를 정비하고 합리화하며, 클라우드 기반 애플리케이션 트래픽에 대한 가시성을 확보하고, 강력한 재해 복구 계획을 설계할 기회를 제공합니다.
소개
많은 조직에서 엔터프라이즈 애플리케이션을 퍼블릭 클라우드로 이전하는 것은 매우 매력적인 선택이 될 수 있습니다. 이를 통해 세대와 지원 가능 수준이 서로 다른 장비로 가득 찬 고가의 데이터 센터를 비롯해 대규모 IT 인프라 운영에 수반되는 고정 비용과 자산을 처분할 수 있습니다. 이러한 서버는 기업의 업무를 지원하는 동시에 전력을 소비하고 열을 발생시키며, 비용이 많이 드는 지원 계약을 필요로 합니다. IT 인프라의 수명 주기와 유지보수, 물리적 설치 환경을 관리하려면 전문 역량과 시간, 예산이 필요하며, 이는 비즈니스 운영에 필요한 애플리케이션을 제공한다는 IT 조직의 본래 사명에 집중하는 데 방해가 될 수 있습니다.
이러한 운영상의 골칫거리와 재정적 부담에서 벗어나, 간단한 API 호출만으로 오래된 서버나 애플리케이션을 폐기할 수 있는 새로운 환경으로 전환하는 것은 재정적·운영적 측면에서 합리적인 선택인 경우가 많습니다. IT를 구동하는 기본 인프라를 더 이상 직접 관리할 필요가 없다면, IT가 기업에 제공하는 실질적인 가치를 구현하는 애플리케이션의 보안, 성능 및 가용성에 더욱 집중할 수 있습니다.
하지만 가상화된 유지보수 불필요 인프라라는 이상적인 환경에 도달하려면 먼저 애플리케이션을 새로운 환경으로 이전할 최적의 방법을 찾아야 합니다. 애플리케이션을 퍼블릭 클라우드로 마이그레이션할 때는 몇 가지 선택지가 있습니다. 클라우드 환경에 맞게 애플리케이션 아키텍처를 완전히 재설계하면 세련되고 간소화된 사용자 경험을 제공할 수 있지만, 많은 시간과 인력이 필요할 수 있습니다. 또는 대규모 설계나 플랫폼 변경 없이 데이터 센터에서 실행 중인 애플리케이션을 그대로 퍼블릭 클라우드로 옮길 수도 있습니다.
이러한 "리프트 앤 시프트" 모델을 고려할 만한 이유는 여러 가지입니다. 비용이 약 10분의 1로 줄어드는 것으로 추정되며,1 거의 언제나 훨씬 빠릅니다. 또한 수명이 얼마 남지 않은 애플리케이션은 굳이 다시 작성할 가치가 없는 경우도 있습니다. 하지만 "리프트 앤 시프트" 마이그레이션을 성공적으로 수행하려면 몇 가지 규칙을 따라야 하며, 그중 하나는 깨야 합니다.
규칙 #1: 서버를 애완동물이 아닌 가축처럼 다루기
먼저 깨야 할 원칙부터 살펴보겠습니다. 서버를 가축처럼 취급한다는 개념은 흔히 클라우드 아키텍처의 본질적인 특성으로 여겨집니다. 서버 인스턴스가 제대로 작동하지 않는다면 수정하느라 시간을 낭비하지 말고, 그냥 종료한 뒤 다시 배포하세요. 운영 체제나 소프트웨어를 업그레이드하지 말고, 새 인스턴스를 배포한 다음 기존 인스턴스를 종료하세요. 이는 타당한 조언입니다. 하지만 데이터 센터라는 안락하고 호화로운 환경에서 나고 자란 애플리케이션을 냉혹한 퍼블릭 클라우드 환경으로 이전하려는 경우에는 오히려 역효과를 낼 수 있습니다.
대부분의 엔터프라이즈 애플리케이션은 클라우드 아키텍처와 방법론을 염두에 두고 설계되지 않았습니다. 이러한 애플리케이션은 상태를 로컬에 저장하고, 기반 서버가 부팅된 후 가동되기까지 시간이 걸리며, 갑작스럽게 종료되면 데이터 불일치가 발생할 가능성이 큽니다. 따라서 가축처럼 다루지 말고, 애지중지 키운 반려동물처럼 세심하게 다뤄야 합니다.
클라우드 환경으로 이전된 엔터프라이즈 애플리케이션에는 데이터 센터에서 제공받던 것과 거의 동일한 수준의 관리와 운영, 그리고 애플리케이션 전송 서비스(보안, 가용성 및 성능)가 필요합니다. 이러한 애플리케이션에 필요한 기본적인 부하 분산 서비스조차 클라우드에서 처음부터 설계되고 개발된 애플리케이션에 필요한 서비스보다 더 복잡합니다. 애플리케이션이 클라우드에서 원활하게 운영되도록 하려면 이를 지원하는 인프라도 함께 이전해야 합니다. 다행히 이제 대부분의 인프라 구성 요소를 원하는 퍼블릭 클라우드에서 사용할 수 있으며, 조직이 보유한 지식과 기술은 물론 정책까지 클라우드에서 재사용할 수 있습니다.
규칙 #2: 애플리케이션만 이전하고, 골칫거리까지 옮기지는 마십시오
대부분의 엔터프라이즈 IT가 발전하는 과정은 패치 패널 배선 랙과 비슷합니다. 어떤 모습인지 아실 겁니다. 처음에는 아름답고, 설계도 훌륭하며, 완벽하게 구축되어 있습니다. (정말 감탄이 절로 나오는 구성 사례는 reddit.com/r/cableporn에서 확인해 보세요.) 하지만 1년도 지나지 않아 시간에 쫓기고 급한 상황이 이어지면서 여기저기 편법을 쓰고, 엉뚱한 색상의 케이블을 사용하게 됩니다("빨간색은 DMZ용이라고, 젠장!"). 불과 3년 만에 캐비닛은 라벨도 없는 형형색색의 이더넷 케이블이 고르디우스의 매듭처럼 뒤엉킨 상태로 전락해, 모두 뜯어내고 다시 구성해야 할 지경에 이릅니다.
클라우드로 이전하는 것은 복잡하게 얽힌 패치 패널을 정리하고 보안 및 액세스 관리에 대한 통제권을 되찾을 기회입니다. 애플리케이션과 함께 일부 인프라 서비스도 이전해야 하지만, 이 기회를 활용해 애플리케이션 및 네트워크 액세스 전략을 합리화하고 시각화하며 체계적으로 정비해야 합니다.
규칙 #3: 정체성을 지키세요
아마도 가장 중요한 통제 조치는 클라우드 환경에서 사용자 ID를 관리하는 것입니다. 일부 애플리케이션을 클라우드로 이전하거나, 서비스형 소프트웨어(SaaS)로 대체하여 기존 애플리케이션을 폐기하거나, 일부 애플리케이션을 완전히 새로 작성하는 과정에서 사용자 ID 관리에 관한 몇 가지 중요한 결정을 내려야 합니다.
여러 ID 서비스를 운영하면 부담이 크고 위험하며 비효율적일 수 있을 뿐 아니라, 제거해야 할 복잡성이 다시 늘어날 수 있습니다. ID 관리는 중앙 집중화해야 하지만, 필요한 모든 위치에서 액세스할 수 있도록 페더레이션해야 합니다. ID 서비스(일반적으로 Microsoft Active Directory)와 통합하고 SAML 및 OAuth 같은 프로토콜을 사용해 이를 클라우드 및 SaaS 서비스로 확장하는 기술을 활용하면, 애플리케이션이 로컬 ID에 의존하는 대신 단일 소스를 통해 사용자를 인증할 수 있습니다.
하지만 애플리케이션이 점점 더 분산된 것처럼 사용자도 여러 곳에 분산되어 있습니다. 사용자의 위치와 기기를 식별하는 제어 기능에 2단계 인증 및 일회용 비밀번호 옵션을 결합하면, 사회 공학적 공격을 비롯해 조직의 정보 보안을 침해하려는 유사한 시도를 방어할 수 있습니다.
규칙 #4: "클라우드 불안"을 해소하기 위한 모니터링
클라우드 환경은 여러 인프라 계층을 추상화하여 사용자가 직접 신경 쓰지 않아도 되게 합니다. 이제 물리적 인프라를 유지·보수하고 지원할 필요가 없으므로 이는 좋은 일입니다. 하지만 책임을 외부에 맡기면 직접적인 통제권도 일부 포기해야 합니다.
이에 대응하기 위해 해야 할 일 중 하나는 애플리케이션 성능을 더욱 면밀히 모니터링하는 것입니다. 관련성 있고 실행 가능한 정보를 제공하는 향상된 모니터링 기능을 추가하면 문제 해결과 용량 계획이 더 쉬워질 수 있습니다.
또 다른 이점은 기업 내부의 일부 우려를 해소할 수 있다는 것입니다. 클라우드의 보안과 성능에 대한 의문은 퍼블릭 클라우드의 멀티테넌트 및 공용 네트워크 연결 특성에서 일부 비롯되지만, 통제력을 잃었다는 인식에서도 발생합니다. 엔터프라이즈 애플리케이션과 동작에 대한 모니터링을 강화하면 이러한 마이그레이션을 촉진하고 클라우드 도입에 대한 심리적 장벽을 없애는 데 크게 도움이 될 수 있습니다.
규칙 #5: 재해 복구(DR)/비즈니스 연속성(BC) 전략에 집중하세요
재해 복구 및 비즈니스 연속성(DR/BC)은 우수한 데이터 센터 인프라와 애플리케이션 설계의 핵심 요소입니다. 퍼블릭 클라우드를 사용하더라도 애플리케이션을 안정적으로 운영하고 안전하게 보호해야 할 책임이 없어지는 것은 아닙니다. 하지만 DR/BC 서비스를 도입하기 위한 진입 장벽은 낮아집니다.
퍼블릭 클라우드 서비스가 등장하기 전에는 물리적 재해 복구 사이트를 구축하는 데 상당한 비용과 시간이 필요했을 수 있습니다. 이제는 서로 다른 기반 기술을 사용하는 별도의 공급업체를 통해 다른 대륙의 인프라에 단 몇 분 만에 액세스할 수 있습니다. 하지만 인프라를 훨씬 더 쉽게 이용할 수 있게 되었더라도 고가용성 애플리케이션을 구축하려면 여전히 상당한 계획과 구성이 필요합니다.
재해 복구 및 클라우드 인프라에 관한 방대한 문서가 있지만, DR/BC를 계획하고 설계하기 위한 효과적인 프레임워크는 몇 가지 핵심 결정 사항과 고려 사항으로 요약할 수 있습니다.
먼저 위험과 투자 수익률(ROI)을 고려해야 합니다. 궁극적인 다중 리전, 다중 공급업체 솔루션을 구축하는 것이 시간과 비용을 들일 만한 가치가 있을까요? 클라우드 서비스는 도입 비용을 낮출 수 있지만, 강력한 재해 복구 및 비즈니스 연속성(DR/BC) 서비스를 유지하는 데 드는 운영 비용은 여전히 발생합니다.
둘째, 트랜잭션 데이터를 어떻게 저장하고 분산하며 일관성을 유지할지 고려해야 합니다. 이는 잘 알려진 문제이지만, 지리적으로 분산된 고가용성 애플리케이션을 구축할 때 가장 어려운 부분일 수 있습니다. 많은 솔루션에는 위치 간 고대역폭·저지연 연결이 필요하며, 기업용 애플리케이션에서는 거의 채택하지 않는 최종 일관성 모델과 같은 보다 특수한 설계가 요구되기도 합니다. 서로 다른 클라우드 제공업체 간에 저지연 연결을 구축하는 것은 대부분의 기업이 자체적으로 구현하기 어렵지만, 몇 가지 선택지가 새롭게 등장하고 있습니다.
세 번째 핵심 과제는 애플리케이션에 대한 액세스를 관리하는 것입니다. 대부분의 액티브-액티브 또는 액티브-DR 설계에서는 DNS를 사용하여 가용성, 근접성 또는 성능을 기준으로 최적의 데이터 센터로 트래픽을 전달하는 방식이 단순성과 기능성 사이에서 가장 적절한 균형을 제공합니다. 애플리케이션에 서로 다른 클라우드 공급업체를 사용하는 멀티클라우드 모델을 고려할 때 특히 그렇습니다. BGP와 같은 네트워크 프로토콜을 사용하는 것도 한 가지 방법일 수 있지만, 일반적으로 복잡성과 위험이 다소 증가합니다. 또 다른 방법은 클라우드 외부이지만 인접한 위치에 배치된 장비나 서비스를 사용하여 클라우드 간 네트워크 트래픽의 부하를 분산하거나 전환하는 것입니다. 이제 마지막 원칙으로 넘어가겠습니다.
규칙 #6: 클라우드에 더 가까이 다가가라
엔터프라이즈 애플리케이션을 클라우드로 마이그레이션하는 대부분의 중견·대기업은 클라우드 인프라에 안전한 비공개 액세스를 구축하고자 할 것입니다. 일부 조직에는 공용 인터넷을 통한 VPN 솔루션이 적합할 수 있지만, 많은 조직은 클라우드 제공업체에 보다 직접적으로 연결되는 전용 회선을 사용할 것입니다. 서비스 제공업체가 제공하는 이러한 전용 회선은 공용 인터넷 연결보다 뛰어난 보안성과 보장된 대역폭, 짧은 지연 시간을 제공하지만 그만큼 비용이 듭니다.
또한 둘 이상의 클라우드에 안정적인 연결이 필요하다면 여러 회선을 구축해야 합니다. 또는 클라우드를 일부 인프라 구성 요소에 연결해야 하는데 기존 데이터 센터가 지리적으로나 논리적으로 클라우드 네트워크 피어링 지점에서 너무 멀리 떨어져 있다면 어떻게 해야 할까요?
점점 더 많은 조직이 여러 클라우드 공급자에 대한 고속 연결을 제공하는 클라우드 연결 환경(일반적으로 클라우드 익스체인지라고 함)에 장비를 코로케이션하는 방안을 고려하고 있습니다. 이를 통해 일부 IT 자산을 클라우드 가상 인프라와 매우 가까운 곳에 배치할 수 있으므로, 클라우드에서 실행되는 애플리케이션과 코로케이션 센터에 설치된 스토리지 또는 보안 어플라이언스 같은 인프라 구성 요소 간에 지연 시간이 짧은 전용 연결을 구축할 수 있습니다. 또한 이러한 구성은 기존 IT 장비를 활용하고 네트워크 및 보안 제어를 클라우드 인프라로 확장할 수 있게 해 줍니다.
마지막으로, 클라우드 익스체인지에 장비를 코로케이션하면 기업 데이터 센터, 클라우드 인프라 및 공용 인터넷이 연결되는 지점에 제어 기능을 배치할 수 있습니다. 비즈니스에 필요한 보안 정책을 확장하거나 새로 수립하고, 애플리케이션 데이터 흐름에 대한 제어력과 가시성을 높일 수 있습니다. 이를 통해 전반적인 보안 태세를 강화하고 액세스 및 보안 서비스를 합리화하고 표준화할 수 있습니다.
결론
엔터프라이즈 애플리케이션을 퍼블릭 클라우드로 리프트 앤 시프트하면 조직은 비용을 절감하고 유연성을 높이며 클라우드 환경으로 신속하게 전환할 수 있습니다. 하지만 성공적인 마이그레이션을 위해서는 엔터프라이즈 애플리케이션에 여전히 이를 뒷받침하는 인프라가 필요하다는 점을 인식하는 것이 중요합니다.
애플리케이션이 보안, 성능 및 가용성을 위해 의존하는 서비스가 클라우드에 갖춰져 있도록 하면 기존 엔터프라이즈 애플리케이션을 계속 원활하게 운영하고 사용자 만족도를 유지할 수 있습니다. 모니터링 기능을 기본적으로 구축하면 문제 영역을 신속하게 파악할 수 있으며, 서비스가 클라우드로 이전될 때 애플리케이션 소유자가 느낄 수 있는 불안감을 줄이는 데 도움이 됩니다.
리프트 앤 시프트는 강력한 통제 체계를 재정립하고, 액세스를 합리화하며, 비즈니스 연속성을 개선하는 촉매제 역할도 할 수 있습니다. 이를 통해 마이그레이션의 전반적인 투자 수익률(ROI)을 높일 수 있습니다. 마지막으로 여러 퍼블릭 클라우드를 활용하고 있다면 클라우드 익스체인지에 코로케이션하는 방안을 고려해 보세요. 성능을 개선하고 단일 제어 지점에서 보안 및 액세스 정책을 표준화할 수 있습니다.
1 Knapp, Kristin, 「목적을 달성하기 위한 수단」, Modern Infrastructure, 2015년 7/8월호, http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf
2016년 11월 29일 게시