아마존 비지니스 민첩성의 비밀

아마존 비지니스 민첩성의 비밀

아마존(Amazon)과 넷플릭스(Netflix), 우버(UBER), 그리고 그 외 성공한 유니콘(Unicon) 기업들의 공통점이 있다면 이미 익숙한 비즈니스에 새로운 비즈니스 개념과 기술을 융합해 자신만의 특화 서비스로 제공한다는 점이다. 또한 기업들은 이러한 시도를 누구보다 빨리 실행하며 사용자 피드백을 반영해 끊임없이 서비스를 개선하고 있다. 우린 이런 기업들의 특출난 장점으로 비즈니스 민첩성(Agility)을 뽑고 이들 기업 성공의 가장 큰 요인이라고 말한다. 지금까지 인터넷의 발전과 모바일 환경의 대중화로 이런 비즈니스 민첩성에 대한 중요성은 항상 강조되어 왔고 이를 지원하는 데 시스템 측면의 많은 투자와 시도가 이루어져 왔으나 사실 잘되지 않았다. 그러나 이런 지지부진헀던 노력이 클라우드(Cloud)의 등장과 이를 가장 잘 활용한 아마존, 넷플릭스 같은 기업 사례에서 증명돼 실질적인 비즈니스 성과로 나타나고 있다. 그렇다면 구체적으로 비즈니스 민첩성이라는 것이 기업의 어떠한 활동으로 나타나는지와 클라우드 환경이 그것을 어떻게 촉진했는지 살펴보자.

https://www.youtube.com/watch?v=dxk8b9rSKOo 11.6초 2011년 Velocity라는 해외 콘퍼런스 에서 언급한 숫자이다. 100미터 달리기 속도 치고도 매우 빠른 속도이다. 이건 아마존의 서비스가 배포되는 주기라고 한다. 즉 11.6초마다 아마존 쇼핑몰이 변경되어 배포된다는 말이다. 또 아래 그림과 같이 작년에 국내에서 발표한 수치를 보면 2014년 기준으로 11.6초 당 1번에서 초당 1.5번으로 향상되었다고 한다. 가름이 안되는 속도이다. 그렇다면 이 수치가 의미하는 바는 무엇일까?

배포주기 = 서비스 변경속도 = 비즈 민첩성

비즈니스가 계속 변경되므로 시스템은 배포되어야 한다. 기업은 새로운 아이디어를 시스템에 반영해 적시에 오픈하고 그 반응을 살펴보길 원한다. 또한 제공한 서비스를 강화해줄 이벤트가 필요한 시점이나 새로운 서비스를 공개했지만 반응이 안 좋아 이를 개선해야 할 때도 시스템을 빠르게 변경 배포해야 한다. 따라서 빠른 배포 주기는 비즈니스의 민첩성을 간접적으로 보여 주는 지표라 볼 수 있다.

보통 서비스 개발은 기획, 분석, 설계, 구현 과정을 거쳐 빌드 되고 배포된다. 길게는 몇 개월 작은 수정이라 하더라도 짧게 몇 주가 걸린다. 그런데 아마존 쇼핑몰은 이러한 과정의 결과로 초당 1.5번 서비스가 개선되고 있다. 인간의 몸에 새로운 세포가 죽고 신선한 세포가 생겨나는 것처럼 시스템이 살아 숨 쉬는 것과 같다.

0.66 sec vs 3 days

그렇다면 국내의 한 쇼핑몰과 비교해 보자. 국내 한 쇼핑몰 시스템 배포 주기는 1주이다. 중간에 긴급 배포가 필요하면 주 중에 1번을 더 배포한다. 그럼 최대 빠른 배포 주기를 3일이라 볼 수 있다. 즉 비즈니스 개선 주기가 3일이다. 3일 대 초당 1.5번이니 0.66초. 아마존의 서비스는 0.66초마다 진화하고 국내 쇼핑몰은 3일마다 진화한다.

비유하자면 3일마다 새로운 상품 전시와 매장 환경을 개선하는 상점과 0.66초마다 변경하는 상점이다. 경쟁하면 누가 우위일지 답은 자명하다.

이것이 비즈니스 민첩성의 차이이다. 그럼 어떻게 아마존이 이런 비즈니스 속도를 갖게 됐는지 살펴보자. 더 많은 요인이 있겠지만 시스템 관점에서 시스템을 구성하는 인프라와 애플리케이션 측면으로 보도록 한다.

필요한 만큼 사용한 만큼 지불하는 클라우드 인프라

전형적인 시스템 인프라 구축 과정을 살펴보면 아래 그림과 같이 서버를 도입하고 네트워크를 구축한 뒤 각 서버마다 운영체제를 설치하고 서비스에 필요한 소프트웨어를 설치하는데 작게는 며칠에서 몇 주, 몇 달이 걸리기도 한다. 이렇게 애플리케이션을 개발하기 위한 인프라 환경 준비작업은 간단치 않았다. 아예 기업에선 이 작업만을 위한 전담조직이 있기도 하다. 그래서 이런 활동을 개발자가 직접 하지 않고 인프라 조직에 요청한다면 의사소통 시간이 추가되므로 더 오래 걸리기도 한다.

새로운 서비스 개발을 위한 프로젝트를 시작한다고 보자. 당연히 장비, 네트워크, 운영체제 등을 위한 초기 투자 비용을 고려해야 하고 그걸 지속적으로 관리하는 비용 또한 적지 않다. 이런 환경에서는 좋은 아이디어를 가졌고 직접 애플리케이션을 개발할 능력이 있다 하더라도 빨리 서비스를 해 볼 수 없다. 또한 운 좋게 아이디어에 대한 투자를 받고 어렵게 개발 환경을 구축한 뒤 서비스를 개발해 런칭했지만 서비스가 실패로 끝났다면 초기 투입된 인프라 비용을 건질 수 없다.

그런데 최근엔 이런 문제가 클라우드 인프라의 등장으로 인해 말끔히 해결되었다. 우선 이제 서비스 개발에 필요한 시스템 인프라 준비에 오랜 시간이 들지 않는다. 적당한 클라우드 플랫폼 벤더를 선택하여 필요한 시점에 몇 번의 클릭으로 손쉽게 준비할 수 있다.

아마존은 자사의 풍부한 클라우드 경험을 아마존 웹서비스(AWS)란 사업으로 제공한다. 그뿐만 아니라 마이크로소프트사의 애저(Azure), 구글의 구글 클라우드 플랫폼(Google Cloud Platform)이 존재하고 최근에는 오라클까지 클라우드 플랫폼 사업을 벌이고 있다. 수많은 스타트 업 기업들이 생겨나고 참신한 서비스를 빠르게 선보이는 것을 보면 이런 클라우드 인프라가 얼마나 강력히 비즈니스 개발의 민첩성을 촉진하고 있는지 알 수 있다.

클라우드 인프라에 걸맞은 애플리케이션의 조건

클라우드 인프라를 사용하면 사용량에 따라 비용을 유연하게 조정할 수가 있다. 즉 사용한 만큼만 지불한다. 쇼핑몰을 예를 들어 보면 쇼핑몰 운영자는 타임 세일이 진행되는 1주일간의 사용자 트래픽을 예상해 시스템의 용량을 증설하고 세일 기간이 지나면 다시 원래의 용량으로 줄이려 한다. 따라서 당연히 1주일간의 용량 증가 비용만 추가로 지불하고 싶다. 클라우드에서는 이런 유연한 용량 증감 설정이 쉽게 가능하다. 이런 조절이 안 된다면 운영자는 처음부터 타임 세일을 고려해 용량을 크게 계획하여 증설한 뒤 이를 다시 반환할 수 없다. 그러나 클라우드 인프라는 그럴 필요가 없다. 클라우드 인프라의 등장으로 필요할 시점에 필요한 만큼만 쉽고 빠르게 시스템 인프라 환경을 준비할 수 있다.

그럼 실제로 서비스를 제공하는 애플리케이션 측면을 살펴보자. 비즈니스 민첩성을 지원키 위해 인프라와 마찬가지로 필요한 시점에 필요한 만큼만 애플리케이션을 변경해 배포하고 싶다. 그러려면 어떠한 애플리케이션 구조를 가져야 할까? 클라우드 인프라를 닮으면 되지 않을까? 클라우드는 여러 개의 서버 장비가 모여 논리적으로 하나처럼 관리된다. 즉 레고처럼 조각 조각이 모여 하나가 큰 덩어리가 되고 쉽게 분리되기도 한다. 애플리케이션도 이런 모양이라면 효율성을 극대화할 수 있다.

특히 이런 애플리케이션이 탑재되는 클라우드 인프라는 사용한 단위로만 지불하므로 이런 애플리케이션 블록이 작으면 작을수록 효율적이다. 특히 사용량이 증가할 운영 시점이라면 서비스 비용을 유연하게 관리할 수 있다. 왜 그러한지 우선 서비스 사용량 증가에 따른 인프라 용량의 성능과 가용성을 높이는 일반적 방법에 대해 알아보자.

Scale up과 Scale out

사용량 증가에 따른 성능 및 가용성을 증가시키는 방법은 스케일 업(Scale-up)과 스케일 아웃(Scale-out)이 있다.

• 스케일 업은 기존 시스템 자체 물리적 용량을 증가시켜 성능을 향상시키는 방법이다. 사용량이 많아진다는 것은 데이터처리가 증가한다는 것이고 시스템을 담을 그릇도 켜져야 한다.
• 스케일 아웃은 기존 시스템 용량과 같은 다수의 장비를 병행 추가하여 그 가용성을 증가시키는 방법이다. 즉 사용량을 분산시켜 전체 장애 없이 운영되도록 한다.

다시 쇼핑몰 시나리오로 돌아가자. 시스템 운영자는 타임세일 시간에 밀려올 트래픽을 대비하려고 쇼핑몰 시스템의 용량을 증설하려 한다.

• 첫 번째 단계는 전체 시스템의 트래픽의 최대치를 계산하여 대용량 처리가 가능하도록 시스템 용량을 증설하는 거다. (스케일 업) 그렇지만 그럼에도 예상 트래픽을 초과해 시스템이 다운될 수 있다.
• 따라서 두 번째 단계는 확장 탄력성을 보장하는 스케일 아웃 설정을 하는 것이다.
• 이 기능은 CPU, 메모리의 트래픽 양이 한계 수치에 도달하면 시스템의 인스턴스를 설정된 개수로 복제하여 증가시킨다. 즉 70% 이상으로 CPU 사용량이 증가하면 1개였던 쇼핑몰 인스턴스가 2개로 증가한다. 그럼 사용량이 2대의 인스턴스로 적절히 분산된다. 훌륭한 선택이 아닐 수 없다.

특정 서비스만 탄력성있게 확장(Scale out)

그런데 시스템 운영자 입장에서 생각해 보면 더 좋은 방법이 있다. 1주일간의 세일 기간 중 정작 바쁜 업무는 세일 이벤트를 수행하는 부분이다. 나머지 부분은 사용자가 몰리지 않아 더 한가해 질 수 있다. 그런데 이 모든 서비스의 시스템 용량을 증설하고 사용량이 몰리면 이 모든 것을 복제할 필요가 있을까? 낭비이다. 사실 원하는 것은 세일 이벤트 담당하는 조각만 용량이 증설되고 사용량에 따라 복제되면 된다.

그러면 어떻게 하면 될까? 앞서 말했듯이 전체 한 덩어리로 묶여 있는 애플리케이션을 레고 블록처럼 분리하면 된다. 레고 블록과 같다면 세일 기간에 타일 세일 레고 모듈만 열심히 일할 수 있도록 용량을 증설하고 트래픽에 반응해 증가하게 설정하면 된다.

즉 시스템을 작은 단위의 독립적인 서비스 연계로 구성해야 한다. 이런 케이스를 가정하여 다시 쇼핑몰 세일을 준비하는 운영자의 운영 시나리오를 상상해 보자.

• 첫 번째 단계에서 운영자는 타임서비스만 분리되어 있으므로 타임 세일 서비스의 용량만 고려해서 증설한다. (스케일 업)
• 두 번째 단계에서는 독립된 세일 서비스의 사용량을 고려해서 트래픽이 증가하면 세일 서비스 인스턴스만 복제되도록 설정한다. (스케일 아웃)
• 전체 시스템의 크기가 30기가였다면 타임 세일의 용량은 1~2기가 정도에 불과하다. 이전 시나리오에서는 30기가를 50기가로 증설 후 50기가가 여러 개로 복제된 비용을 지불했는데 이제는 2기가를 10기가로 증설하고 10기가가 여러 개로 복제된 비용만 지불한다.
• 또한 조각으로 세일 서비스만 분리되어 있기 때문에 나머지 서비스는 가동된 상태에서 변경하고 싶은 일부분만 변경해 배포할 수도 있다. 이것이 아마존 0.66초의 비밀이다. 어떤 모습이 더 효율적이고 빠른 비지니스 제공을 위한 모습인가?

클라우드 프렌드리(Friendly)와 클라우드 네이티브(Native)

물론 그렇게 하지 않고 그림 왼쪽처럼 전체 시스템을 큰 덩어리로 만들어 클라우드 인프라에 올릴 수도 있다. 그렇지만 특정 기능만 확장하거나 배포할 수 없는 비효율을 감안해야 한다. 클라우드 플랫폼 중 하나인 클라우드 파운드리(Cloud Foundry)를 서비스하는 피보탈(Pivotal) 사에서는 이렇게 큰 덩어리로 클라우드 환경에 올라갈 수 있게만 한 애플리케이션을 클라우드 친화 애플리케이션(Cloud friendly Application)라 하고 독립적으로 분리되어 배포될 수 있는 조각으로 구성된 애플리케이션을 클라우드 인프라에 가장 어울리고 효과적이라는 의미로 클라우드 네이티브 애플리케이션(Cloud Native Application)이라 부른다. 그리고 궁극적으로 클라우드 친화에서 클라우드 네이티브로 전이해야 한다고 말한다.

비즈니스 민첩성을 시스템이 잘 지원하기 위해서는 클라우드 인프라를 효율적으로 적용하도록 애플리케이션 조각으로 구성한 클라우드 네이티브 애플리케이션이 가장 효과적이다. 아마존 사례가 그것을 증명하고 비즈니스 개선 속도 0.66초를 만들어 냈다.