앱을 클라우드로 마이그레이션하시나요? 먼저 이 글을 읽어보세요.

클라우드 컴퓨팅 환경은 이제 IT 환경에서 가장 중요한 특징이 되었으며, 기업들이 기존의 온프레미스 애플리케이션을 점점 더 규칙적으로 클라우드로 옮기고 있습니다. 하지만 애플리케이션을 클라우드로 마이그레이션하려면 클라우드 공급업체의 가상 머신으로 애플리케이션을 옮기는 것 이상이 필요합니다. 클라우드 마이그레이션에 대한 동기는 조직마다 다르지만 모든 조직이 고려해야 할 핵심 요소가 있으며, 성공적인 클라우드 마이그레이션을 보장하는 데 도움이 되는 모범 사례도 확실히 있습니다. 클라우드 마이그레이션에서 최대한의 이점을 얻으려면 애플리케이션 아키텍처와 온프레미스에서 클라우드로의 전환 모두에서 미리 계획을 세워야 합니다.

클라우드 환경은 온프레미스 환경과 다르게 동작합니다. 두 환경 사이의 몇 가지 차이점은 명확합니다. 예를 들어, 컴퓨팅 리소스를 회사 내부에서 소유하고 관리하는 것이 아니라 다른 회사가 소유하고 관리한다는 사실입니다. 그러나 가장 중요한 차이점 중 몇 가지는 기술의 결과가 아닙니다. 일반적으로 클라우드 공급업체가 제공하는 모든 기술은 온프레미스에서도 사용할 수 있습니다. 클라우드가 제공하는 것은 대체 기술이 아닌 대체 소비 모델입니다. 다시 말해, 클라우드 공급업체로 이전하는 이점은 컴퓨팅 리소스 자체가 아니라 컴퓨팅 리소스를 사용하는 방식에서 찾을 수 있습니다.

클라우드 제공자는 온프레미스 하드웨어용으로 설계된 데이터 감사 준수 정책 등 온프레미스 기능을 모두 복제할 수는 없습니다. 클라우드 구성 요소가 지리적으로 분산되어 있기 때문에 클라우드 배포 시 지연 시간이 일반적으로 더 심합니다. 클라우드 제공자는 다른 한계에도 직면한다. 공급업체가 클라이언트 전반에 걸쳐 표준을 준수하기 때문에 컴퓨팅 환경을 사용자 지정하는 데 실질적인 한계가 있습니다. 예를 들어, 희귀하고 이국적인 컴퓨팅 장비를 제공하는 클라우드 제공업체는 거의 없습니다.

하지만 기업이 그러한 한계 내에서 운영할 수 있다면 클라우드 공급업체는 대부분 기업이 도달할 수 없는 수준의 소비 역량을 제공할 수 있습니다. 클라우드 제공자는 전 세계에 데이터 센터를 운영하여 기업이 어느 데이터 센터에 컴퓨팅 리소스를 배치할지 선택할 수 있도록 할 수 있습니다. 클라우드 제공자는 고정 비용을 흡수하여 회사가 실제로 사용한 리소스에 대한 비용만 지불할 수 있도록 할 수도 있습니다. 클라우드 공급업체는 대부분 회사가 따라올 수 없는 규모의 경제성을 갖추고 있으므로 배포를 관리하고 자동화하는 시스템에 많은 투자를 할 수 있습니다. 이러한 혜택은 기술적인 성격을 띠고 있지 않습니다. 오히려 클라우드 공급업체의 장점은 소비자에게 제공되는 선택권과 비용 구조에 있습니다.

클라우드 제공자의 한계를 완화하고 그 이점을 활용하기 위해 IT 부서는 애플리케이션 배포 방식을 변경하고, 클라우드 제공자의 상대적인 장점을 최대한 활용할 수 있도록 워크플로를 변경해야 하며, 대기 시간과 같이 클라우드 환경이 불리한 속성에 대한 종속성을 피해야 합니다.

비용 절감은 클라우드로 전환하는 주된 이유로 언급되는 경우가 많지만, 진짜 이유는 보다 미묘합니다. 대부분의 동기는 확실성, 생산성, 민첩성이라는 세 가지 범주에 속합니다.

퍼블릭 클라우드 제공업체는 기술을 패키징하여 사용하기 쉽게 만들어 확실성을 높이고, 그렇게 함으로써 일부 IT 운영 위험을 흡수합니다. 공급업체가 인프라를 유지 관리하고 책임을 지므로 조직은 이러한 우려를 무시할 수 있습니다. 마찬가지로, 클라우드 제공업체는 일반적으로 IT 운영에 대한 통찰력을 얻을 수 있는 도구를 제공하여 가시성을 높입니다. 퍼블릭 클라우드 비용은 일반적으로 소비에 따른 함수이므로 조직은 애플리케이션의 이점(예: 수익)을 해당 애플리케이션의 운영 비용과 더욱 밀접하게 연관시킬 수 있습니다. 응용프로그램을 더 많이 사용할수록 비용은 늘어나지만, 이점도 그만큼 커집니다. 자본 비용에서 운영 비용으로 비용을 옮기면 구매 결정 시 미래 성장에 대한 여지를 마련할 필요성이 줄어듭니다. 클라우드 공급자 수준에서 이러한 불확실성을 관리하면 측정 가능한 이점이 제공됩니다.

퍼블릭 클라우드를 도입하는 또 다른 이유는 생산성 향상입니다. 공급업체가 제공하는 협업 및 자동화 도구는 시중에서 판매되는 도구 중 가장 발전된 도구에 속합니다. 게다가 인프라를 관리하지 않기 때문에 IT 직원은 비즈니스 전략적 노력에 집중할 수 있으며, 어디서나 관리할 수 있는 간소화된 운영 덕분에 IT 직원의 생산성이 높아집니다.

퍼블릭 클라우드를 도입하는 마지막 이유는 아마도 가장 설득력이 있을 것입니다. 바로 민첩성입니다. 클라우드 공급업체가 언제나 무한한 리소스를 사용할 수 있다는 환상을 만들어내기 때문에 비즈니스 활동의 속도와 방향은 더 이상 IT 프로비저닝 제약에 얽매이지 않습니다. 리소스는 몇 초 또는 몇 분 내에 배포될 수 있습니다. 프로젝트는 종료 시 하드웨어를 폐기할 필요 없이 단기간 복잡한 컴퓨팅 환경을 사용할 수 있습니다. 하드웨어 자산에 대한 걱정 없이 애플리케이션을 신속하게 배포, 확장, 제거할 수 있습니다.

클라우드 마이그레이션에는 많은 이점이 있지만, 마이그레이션 작업과 관련된 몇 가지 과제도 있습니다. 장벽과 위험은 이주 과정의 어느 부분에서 발생하는지에 따라 다릅니다. 즉, 이주 전, 이주 중, 이주 후입니다. 이런 장벽과 위험을 미리 해결하면 이주 작업이 성공할 가능성이 커집니다.

이주 전 계획을 세우는 것은 아마도 이주 과정에서 가장 중요한 부분일 것입니다. 클라우드 기능을 활용하도록 애플리케이션을 재구성하지 못하면 마이그레이션 작업이 실패할 수 있습니다. 이는 또한 애플리케이션의 복잡성을 파악하고 관리하기 시작하기에 좋은 시점입니다. IT 교육은 노력의 시작부터 이루어져야 합니다. 클라우드 배포는 분산된 실행과 도구 확산으로 이어지는 경향이 있으며, 초기 단계에서 계획을 세우면 마이그레이션 프로세스를 원활하게 진행하는 데 도움이 될 수 있습니다.

애플리케이션을 클라우드로 마이그레이션하는 작업은 처음 계획했던 것보다 시간이 더 오래 걸리고 복잡해질 수 있습니다. 문제를 최소화하려면 문제가 발생하더라도 그 영향이 최소화되도록 작고 상대적으로 독립적인 애플리케이션부터 시작하세요. 소규모 애플리케이션을 처음 마이그레이션할 때 얻은 교훈은 향후 마이그레이션에 적용할 수 있습니다.

마이그레이션이 완료된 후에 마이그레이션과 관련된 장기적인 문제가 분명해집니다. 클라우드 환경에서는 보안 경계를 정의하기가 더 어려워서 보안 및 규정 준수 문제가 발생할 수 있습니다. 오래된 시스템과 새로운 시스템이 서로 다른 환경에 있을 뿐만 아니라 서로 다른 문화권에서 개발된 경우, 레거시 시스템을 지원하는 것이 더 어려울 수 있습니다. 일부 조직에서는 특히 컨테이너의 증가로 인해 클라우드 종속성에 대한 우려를 겪고 있습니다. 마지막으로, 가변적인 클라우드 비용을 분기별로 예측하기 어렵기 때문에 예산 문제가 문제가 될 수 있습니다.

애플리케이션을 평가하는 한 가지 기술은 성숙도 대 위치 행렬입니다. 신청서를 검토하여 필요한 성숙도가 얼마인지 확인하세요. 경쟁적 차별화를 제공하거나 틈새 시장을 겨냥한 애플리케이션은 사내에서 제공하는 것이 가장 좋을 수 있습니다. 반면에 저비용 또는 비용 리더십 애플리케이션(특히 변화 비용 측면에서)은 종종 클라우드 환경에 적합합니다. 고려해야 할 다른 요소로는 확장성이 있습니다. 새로운 애플리케이션이 배포되어 결국 현재 부하의 100배까지 확장될 수 있다고 가정해 보겠습니다. 온프레미스 배포의 성장에 앞서가려면 인프라를 상당히 과도하게 프로비저닝해야 하며, 그러면 유휴 리소스에 대한 추가 자본 비용이 발생합니다. 하지만 동일한 애플리케이션을 클라우드 환경에 배포하면 비용은 성장에 따라 늘어나고 과도한 프로비저닝이 필요 없게 됩니다.

네트워크 문제도 클라우드 환경으로 마이그레이션할 애플리케이션을 결정하는 데 영향을 줄 수 있습니다. 애플리케이션에 광범위한 딜러 네트워크나 상당수의 원격 이메일 사용자와 같이 분산된 사용자의 비중이 큰 경우, 온프레미스 배포를 통해 해당 트래픽이 모두 데이터 센터로 전송됩니다. 트래픽이 이미 인터넷을 통과하고 있으므로 애플리케이션은 지연 시간에 민감하지 않습니다. 이러한 애플리케이션을 클라우드 환경에 배치하면 네트워크 지연 시간은 변하지 않지만, 분산 사용자가 사용했을 수 있는 온프레미스 데이터 센터의 대역폭이 확보됩니다.

동시에 일부 앱을 온프레미스에 보관해야 하는 이유도 있습니다. 수명이 짧은 애플리케이션은 마이그레이션 작업에 드는 위험과 비용을 감당할 만한 가치가 없을 수 있습니다. 일부 앱은 낮은 네트워크 지연 시간과 저장 속도에 의존하며, 클라우드 환경에서는 성능이 훨씬 떨어질 수 있습니다. 규정 준수 및 보안 문제는 종종 앱을 온프레미스에 보관하는 이유로 발생합니다. 일부 감사 절차는 데이터를 검증하기 위해 시스템 및 데이터에 물리적으로 접근하는 것을 가정하는 반면, 다른 감사 절차는 애플리케이션과 운영 체제가 베어 메탈에서 수행되어야 함을 요구합니다(즉, 가상 머신에서 실행할 수 없음). 시간이 지남에 따라 규정 준수 절차가 클라우드 환경에 맞게 조정되겠지만 많은 경우 아직은 그렇지 않습니다. 클라우드에서 애플리케이션을 사용하여 규정 준수 감사에 실패할 위험을 감수하는 대신, 당장은 민감한 앱을 사내에 보관하는 것이 더 합리적일 수 있습니다. 일부 앱은 레거시 시스템과 프로세스를 지원해야 하므로 클라우드에서 작동하도록 재구성하는 것이 사실상 불가능합니다. 이러한 앱은 온프레미스에서 남겨둘 수 있는 후보가 될 수도 있습니다. 이러한 이유로 일부 앱은 클라우드 환경에 더 적합한 앱보다 마이그레이션 우선순위가 낮아야 합니다.

애플리케이션은 사내에 두는 것이 더 좋습니다.

• 수명이 짧은 앱
• 낮은 대기 시간이 필요한 앱
• 규정 준수에 문제가 있는 앱
• 레거시 시스템을 지원하는 앱

많은 조직이 마이그레이션 과정에서 어려움을 극복해야 합니다. 가장 중요한 질문은 실제 전환을 어떻게 수행할 것인가입니다. 한 가지 방법은 클라우드 애플리케이션이 철저히 테스트될 때까지 DNS를 사용하여 온프레미스 애플리케이션을 확인한 다음, DNS 레코드를 변경하여 클라우드 애플리케이션을 확인하는 것입니다. DNS에는 클라이언트가 DNS 응답을 일정 시간 동안 캐시할 수 있도록 하는 TTL(수명) 값이 포함되어 있습니다. 전환 전에는 TTL을 몇 초 정도로 낮추는 것이 좋습니다. 그러면 전환 후 클라이언트가 새 애플리케이션에 빠르게 적응할 수 있습니다. 하지만 이런 접근 방식에는 어느 정도 위험이 있습니다. TTL을 낮추면 DNS 트래픽이 크게 증가하고 서버의 부담도 커질 수 있습니다. 조직에서는 지정된 기간보다 더 오랫동안 TTL과 캐시를 무시할 수 있으며, 이로 인해 일부 사용자는 전환이 이루어진 후에도 오랫동안 온프레미스 애플리케이션을 사용하게 될 수 있습니다. 이 방법을 사용하기 전에 DNS 인프라의 견고성을 테스트해 보세요.

전환 과정을 통해 테스트에서는 발견되지 않았던 새로운 애플리케이션의 문제점이 드러날 수도 있습니다. 문제가 있는 애플리케이션에 대한 대책 중 하나는 문제 발생 시 온프레미스 애플리케이션으로 처리를 되돌릴 수 있는 대체 계획을 세우는 것입니다. 안타깝게도 양방향 전환은 데이터 동기화를 복잡하게 만들기 때문에 훨씬 더 많은 사전 계획과 테스트가 필요합니다. 더 정교한 접근 방식은 카나리아 테스트라는 부분적 전환을 사용하는데, 이는 모니터링하는 동안 일부 사용자를 클라우드 애플리케이션으로 전환하는 것입니다. 애플리케이션에 대한 신뢰가 커질수록 더 많은 사용자, 결국 모든 사용자가 전환될 수 있습니다. 반대로, 문제가 발생하면 전환된 사용자는 온프레미스 애플리케이션을 다시 사용할 수 있습니다. 프로그래밍 가능한 ADC(애플리케이션 제공 컨트롤러)를 통해 F5® iRules®를 통해 카나리아 테스트를 수행할 수 있으므로 전환 기간 동안 운영 팀에 열려 있는 옵션의 수를 늘리는 동시에 위험을 최소화할 수 있습니다.

조직이 애플리케이션을 마이그레이션할 때 저지르는 가장 큰 실수 중 하나는 클라우드에 맞게 재구성하지 못하는 것입니다. 클라우드 환경의 차이점을 활용하여 애플리케이션 구조를 변경하는 데 시간을 할당하면 상당한 이점을 얻을 수 있습니다.

예를 들어, 클라우드 환경에서의 확장은 온프레미스에서의 확장에 비하면 사소한 일입니다. 최악의 부하에 맞춰 애플리케이션을 설계하고 테스트하는 대신, 애플리케이션을 간소하면서도 확장 가능하게 설계하세요. 애플리케이션 사용이 광범위한 분야에 걸쳐 이루어지는 경우, 대규모 풋프린트에 대한 오버헤드를 유지할 필요가 없습니다. 대신, 작은 규모로 구축하고 확장에 대비하세요. 마찬가지로 정전 등의 특정 장애는 클라우드 환경에서는 발생할 가능성이 낮기 때문에 이에 대한 설계 필요성이 적습니다.

반면, 클라우드 환경에서는 온프레미스에서 일반적으로 경험하지 못하는 새로운 한계가 발생합니다. 클라우드 아키텍트는 정기적인 처리의 일부로 언제든지 VM 인스턴스의 장애가 발생할 수 있다는 것을 설계 시 고려해야 한다고 말합니다. 클라우드 환경에서는 저장 방식도 다릅니다. 온프레미스 디자인은 일반적으로 로컬 블록 스토리지를 사용합니다. 동일한 옵션은 클라우드 환경에서도 사용할 수 있지만 공유할 수는 없습니다. 로컬 비공유 상태와 인스턴스 장애가 결합되면 재앙이 초래될 수 있습니다. 객체 기반 스토리지나 키-값 스토리지 서비스 등의 다른 스토리지 패러다임도 존재합니다. 클라우드 환경의 한계를 극복하려면 애플리케이션을 재구성해야 합니다.

일부 애플리케이션이나 제어 시스템은 사내에 두는 것이 합리적입니다. 많은 조직에서는 클라우드 환경으로 ID를 확장하기 위해 페더레이션을 채택하는 동시에 사내 Active Directory를 유지합니다. 마찬가지로 ADC는 방화벽, 웹 애플리케이션 방화벽, DDoS 보호, SSL/TLS 가로채기, 서비스 체이닝 등 애플리케이션 전송을 지원하는 다양한 보안 서비스를 제공합니다. ADC는 고급 트래픽 관리 및 프로그래밍 가능한 프록시는 물론 ID 및 액세스 관리도 제공합니다.

기업들은 일반적으로 이러한 애플리케이션 서비스를 애플리케이션 외부에서 통합합니다. 그 이유는 해당 서비스가 비즈니스 로직의 일부가 아니라 운영상의 문제이기 때문입니다. 많은 기업에서는 애플리케이션 출시 일정과 관계없이 운영상의 변경이 가능하도록 ADC를 전략적 제어 지점으로 활용하여 모든 애플리케이션에 적용할 수 있는 도메인 전문 지식에 집중합니다. 하지만 클라우드 환경은 이 모델을 변화시킵니다.

클라우드 환경에서 애플리케이션을 제공하는 초기 접근 방식은 각 클라우드 환경에서 기본 도구를 사용하여 ADC 서비스를 복제하는 것이었습니다. 곧 클라우드 공급업체가 동일한 수준의 기본 기능을 제공하지 않는다는 점이 분명해졌고, 조직에는 선택권이 남게 되었습니다. 즉, 클라우드와 온프레미스 환경 간에 이기종 애플리케이션 제공 표준을 유지하거나 모든 애플리케이션을 최소공배수에 맞춰 재설계하는 것입니다.

기업이 여러 클라우드 환경으로 확장함에 따라 두 옵션 모두 수용하기 어려워졌습니다. 어떤 조직이 세 개의 클라우드 공급업체를 활용하고 온프레미스 데이터 센터도 유지 관리한다고 가정해 보겠습니다. 해당 조직은 4개의 SSL/TLS 전문 지식, 4개의 DDoS 전문 지식 등을 유지해야 했거나, 점점 더 분산되고 제한적인 기본 서비스 세트를 표준화해야 했습니다. 추가 클라우드 환경에 단 하나의 새로운 애플리케이션을 배포하는 데는 또 다른 도메인 전문가 집단이나 모든 기존 애플리케이션에 적용할 새로운 표준 집합이라는 상당한 한계 비용이 수반되었습니다.

하지만 모든 환경에서 일관된 서비스를 제공하기 위한 세 번째 선택지도 있습니다. F5 애플리케이션 커넥터를 사용하면 하나의 도메인 전문가가 애플리케이션이 어디에 있든 모든 애플리케이션을 관리할 수 있습니다. 기존 BIG-IP® 하드웨어나 소프트웨어 어플라이언스를 사용하면 조직은 위치에 관계없이 모든 애플리케이션에 완벽한 고급 애플리케이션 서비스를 주입하여 모든 애플리케이션에 단일 도메인 전문가가 관리하는 전략적 제어 지점을 제공할 수 있습니다. 또한, Application Connector는 눈에 보이는 모든 공용 IP 주소를 제거하여 보안을 강화하고, 공격 표면을 줄입니다. 암호화 키를 클라우드 인스턴스가 아닌 중앙에 저장함으로써 조직은 중요한 암호화 정보가 비공개로 유지된다는 확신을 가질 수 있습니다. 마지막으로, Application Connector는 프록시 인스턴스가 새로운 워크로드 노드를 자동으로 검색할 수 있도록 하여 클라우드 배포의 효율성을 높여줍니다.

온프레미스 애플리케이션과 클라우드 애플리케이션의 가장 큰 차이점 중 하나는 애플리케이션 상태를 저장하는 방식입니다. 대부분의 온프레미스 설계에서는 하드 디스크나 SSD와 같은 로컬 블록 저장소를 사용합니다. 클라우드 애플리케이션도 블록 스토리지를 사용할 수 있지만, 스토리지는 인스턴스에 로컬로 저장되며 설계 시 인스턴스가 실패할 것으로 예상해야 합니다. 조직이 앱을 클라우드로 옮길 때 애플리케이션 설계에서 아무것도 바꾸지 않더라도 상태 처리 방식은 변경해야 합니다.

일반적인 클라우드 스토리지 유형은 각 객체가 본질적으로 파일이지만 이름을 사용하여 주소가 지정되는 객체 스토리지입니다. 일반적으로 저장소는 최대 1단계의 계층(즉, 폴더나 디렉토리)을 가지므로 기존 파일 시스템을 객체에 매핑하는 것은 문제가 될 수 있습니다. 객체는 편집할 수 없고 생성, 읽기, 삭제만 가능하기 때문에 객체 저장소는 이미지와 같은 정적 콘텐츠에는 적합하지만 상태에는 적합하지 않습니다. 많은 애플리케이션은 파일이 수정될 수 있다고 가정하기 때문에 이러한 애플리케이션은 객체와 작동하지 않습니다.

다른 저장 옵션으로는 키-값 저장소와 기존의 트랜잭션 데이터베이스가 있습니다. 이것들은 파일 시스템과 같은 저장소는 아니지만 데이터를 저장하며 추가 서비스로 제공됩니다. 효과적인 설계를 통해 상태를 키-값이나 데이터베이스 서비스에 저장할 수 있습니다.

클라우드 컴퓨팅 환경은 여러 가지 이점을 제공하지만, 클라우드 기능을 활용하고 클라우드 제한의 영향을 완화하도록 주요 애플리케이션을 재구성하는 경우에만 가능합니다. 클라우드 환경은 장애 시나리오가 다양하고 네트워크 지연 시간이 길어지는 경우가 많지만, 빠른 확장이 가능하고 전 세계적으로 데이터 센터를 선택할 수 있습니다. 클라우드 마이그레이션을 고려할 때는 어떤 애플리케이션을 마이그레이션할지, 어떤 애플리케이션을 온프레미스에 유지할지 결정하는 것이 포함됩니다.

전환 과정 자체에도 신중한 고려와 계획이 필요하며, 클라우드 애플리케이션이 예상대로 작동하지 않는 경우를 대비한 백아웃 계획도 수립해야 합니다. 일부 조직에서는 계획 과정의 일환으로 모든 애플리케이션을 호스팅하는 위치에 관계없이 모든 애플리케이션을 제어하는 전략적 지점으로 ADC를 사내에 유지합니다. 마지막으로, 클라우드 애플리케이션이 데이터와 상태를 저장하는 방법을 신중하게 계획합니다. 애플리케이션과 비즈니스를 클라우드로 옮기는 방법에 관계없이, 경험이 풍부한 클라우드 파트너와 함께하는 것을 고려하세요.