[MicroService] 비지니스 민첩성 1장

◆ 성공한 인터넷 기업들과 비지니스 민첩성

▶ 아마존(Amazon)과 넷플릭스(Netflix), 우버(Uber)를 비롯해 성공한 유니콘 기업들의 공통점 특징은 이미 익숙한 비즈니스에 새로운 비즈니스 개념과 기술을 융합해 자신만의 특화된 서비스를 제공한다는 것

▶ 자신만의 특화된 서비스를 제공하려는 시도를 누구보다 빨리 실행했고 사용자 피드백을 반영해 끊임없이 서비스를 개선

▶ 이러한 기업들의 특출난 장점으로 비즈니스 민첩성(Agility)을 꼽고 이것이 기업 성공의 가장 큰 요인으로 판단

▶ 지금까지 인터넷의 발전과 모바일 환경의 대중화로 이 같은 비즈니스 민첩성에 대한 중요성은 항상 강조돼 왔고 비즈니스 민첩성을 지원하기 위한 시스템 측면의 많은 투자와 시도가 이뤄져 왔으나 성공 사례가 많지 않았지만 이처럼 지지부진했던 노력이 클라우드 환경의 등장과 이를 잘 활용한 아마존, 넷플릭스 같은 기업의 사례에서 증명돼 실질적인 비즈니스 성과로 나타나고 있음

 

▶ 아마존의 배포 속도

    ●  11.6초 - 2011년 Velocity라는 해외 콘퍼런스 에서 언급된 숫자로 11.6초는 100미터 달리기 기록으로 치기에도 매우 빠른 속도인데 이 수치는 아마존의 비즈니스 서비스가 배포되는 주기로 11.6초마다 아마존 쇼핑몰의 소스 코드가 변경되어 배포된다는 의미

    ●  2019년에 국내 AWS 컨퍼런스에서 발표된 내용 - 아마존 서비스의 배포 주기가 초당 1.5번으로 향상

    ●  비즈니스는 계속 변경되므로 이에 따라 개선된 시스템도 계속 배포돼야 하는데 기업은 새로운 아이디어를 시스템에 반영해 적시에 오픈하고 그 반응을 살펴보고자 하고 기존 서비스를 보완하는 부가 서비스가 필요한 시점이나 새로운 서비스를 공개했지만 반응이 좋지 않아 이를 개선해야 할 때도 시스템을 빠르게 변경해서 배포해야 하므로 빠른 배포 주기는 비즈니스의 민첩성을 간접적으로 보여주는 지표라 할 수 있음

    ●  보통 서비스는 기획, 분석, 설계, 구현 과정을 거쳐 빌드되고 배포되는데 그 과정이 길게는 몇 개 월 걸리고 규모가 작은 수정이라 하더라도 몇 주가 걸리기 마련인데 아마존 쇼핑몰은 이 같은 전체 과정이 독립적으로 완료되어 초당 1.5번씩 서비스가 변경, 개선되고 있는데 비유하면 인간의 몸에서 낡은 세포가 죽고 새로운 세포가 생겨나는 것처럼 시스템이 살아 숨 쉬는 것 과 같음

    ●  국내 한 쇼핑몰의 시스템 배포 주기는 1주다. 중간에 긴급 배포가 필요하면 주중에 1번 더 배포하는데 그럼 가장 빠른 배포 주기를 3일이라 볼 수 있는데 비즈니스 개선 주기가 3일인 것

    ●  초당 1.5번이면 0.66초에 1번인데 아마존의 서비스는 0.66초마다 진화하고 국내 쇼핑몰은 3일마다 진화하는 셈

    ●  3일마다 새로운 상품을 전시하고 매장 환경을 개선하는 상점과 0.66초마다 변화하는 상점 과 도 같은데 두 상점이 경쟁하면 어떤 회사가 우위에 있을지 답은 자명

▶ 클라우드 인프라의 등장

    ● 전형적인 시스템 인프라 구축 과정을 살펴보면 서버를 도입하고 네트워크를 구축한 뒤 각 서버마다 운영체제를 설치하고 서비스에 필요한 소프트웨어를 설치하는 과정으로 진행되고 전 과정을 완료하기까지 적게는 며칠에서 몇 주, 길게는 몇 달이 걸리기도 함

    ● 애플리케이션을 개발하기 위한 인프라 환경을 준비하는 작업은 간단하지 않음

    ● 어떤 기업에서는 아예 이 작업만 전담하는 인프라 조직을 두기도 하는데 이러한 활동을 개발 조직이 직접 담당하지 않고 인프라 조직에 요청한다면 의사소통 시간이 더해지므로 더 오랜 시간이 걸리기 마련

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

    ● 최근에는 위와 같은 문제가 클라우드 인프라의 등장으로 해결되었는데 서비스 개발에 필요한 시스템 인프라를 준비하는 데 오랜 시간이 들지 않음

    ● 적당한 클라우드 플랫폼 벤더를 선택해 필요한 시점에 몇 번의 클릭으로 손쉽게 개발 시스템 인프라를 마련할 수 있음

    ● 아마존은 자사의 풍부한 클라우드 서비스 경험을 아마존 웹서비스(AWS: Amazon Web Service)라는 사업으로 제공하고 마이크로소프트사의 애저(Azure), 구글의 구글 클라우드 플랫폼(Google Cloud Platform)0! 있고 최근에는 오라클까지 클라우드 플랫폼 사업을 벌이고 있음

    ● 수많은 스타트업이 생겨나고 참신한 서비스를 빠르게 선보이는 것을 보면 이러한 클라우드 인프라가 얼마나 강력하게 비즈니스 개발의 민첩성을 촉진하는지 알 수 있음

▶ 클라우드 인프라에 어울리는 애플리케이션의 조건

    ●  스케일 업 과 스케일 아웃

        → 사용량 증가에 따른 성능 및 가용성을 높이는 방법으로 스케일 업(Scale- up)과 스케일 아웃(Scale-out)이 있음

        →  쇼핑몰 시스템 운영자는 타임세일 기간에 밀려올 트래픽에 대비하려고 쇼핑몰 시스템의 용량을 증설하려 하는 경우

            ⊙ 첫 번째 단계는 스케일 업 작업으로 전체 시스템의 트래픽 최대치를 계산해서 대용량 처리가 가능하도록 시스템 용량을 증설하는 것인데 그럼에도 예상 트래픽을 초과해 시스템이 다운될 수 있음

            ⊙ 두 번째 단계는 확장 탄력성을 보장하는 스케일 아웃을 설정하는 것으로 이 경우 CPU 나 메모리의 트래픽 양이 한계 수치에 도달하면 시스템의 인스턴스를 설정된 개수로 복제해서 증가시키는데 CPU 사용량이 70% 이상으로 증가하면 1개였던 쇼핑몰 인스턴스가 2개로 늘어나도록 하면 사용량이 2대의 인스턴스로 적절히 분산됨

 

    ●  특정 서비스만 탄력성 있게 확장(스케일 아웃)

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

        →  세일 이벤트를 담당하는 조각만 용량이 증설되고 사용량에 따라 복제되어 트래픽에 대비하면 되는데 이를 위해서는 전체가 한 덩어리로 묶여 있는 애플리케이션을 레고 블록처럼 분리하면 됨

        →  레고 블록과 같다면 세일 기간에 타임세일 이벤트를 수행하는 레고 모듈만 열심히 일할 수 있도록 용량을 증설하고 트래픽에 반응해 복제되게 설정하면 됨

        →  시스템을 작은 단위의 독립적인 서비스 연계로 구성

        →  시스템 운영장의 시나리오

            ≡ 첫 번째 단계에서 운영자는 타임세일 서비스만 분리돼 있으므로 타임세일 서비스의 용량만 고려해서 증설(스케일 업)

            ≡ 두 번째 단계에서는 독립된 타임세일 서비스의 사용량을 고려해서 트래픽이 증가하면 타임세일 서비스 인스턴스만 복제되도록 설정(스케일 아웃)

            ≡ 전체 시스템이 사용할 메모리 크기가 16GB였다면 타임세일 서비스에 필요한 용량은 3~ 4GB 정도에 불과한데 이전 시나리오에서는 전체 시스템에 할당된 16GB의 메모리 크기를 32GB로 증설한 후 32GB가 여러 개로 복제된 비용을 지불했는데 이제는 타임세일 서비스에 필요한 3GB를 8GB로 증설하고 8GB가 여러 개로 복제된 비용만 지불

            ≡ 조각으로 세일 서비스만 분리돼 있기 때문에 나머지 서비스는 가동된 상태에서 변경하고 싶은 일부분 만 변경해 배포할 수도 있음

    ●  클라우드 프렌들리와 클라우드 네이티브

        →  작은 단위의 서비스 연계로 시스템을 구성하지 않고 전체 시스템을 하나의 덩어리로 만들어 클라우드 인프라에 올려도 비즈니스를 제공하는 데 전혀 문제가 없지만 특정 기능만 확장하거나 배포할 수 없는 비효율을 감수해야 함

        →  클라우드 플랫폼 중 하나인 클라우드 파운드리(Cloud Foundry)를 서비스하는 피보탈(Pivotal)에서는 이처럼 큰 덩어리로 클라우드 환경에 올라갈 수 있게만 한 애플리케이션을 클라우드 친화 애플리케이션(Cloud Friendly Application)이라 하고 독립적으로 분리되어 배포될 수 있는 조각으로 구성된 애플리케이션을 클라우드 인프라에 가장 어울리고 효과적이라는 의미로 클라우드 네이티브 애플리케이션(Cloud Native Application)이라 부르고 궁극적으로 클라우드 프렌들리에서 클라우드 네이티브로 전이해야 한다고 함

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

모노리스와 Micro Service에 대해서는 다음 2장에서 계속 이어져서 포스팅 하도록 하겠다. 아래 포스팅을 참고하자.

https://joylucky7.tistory.com/49

[MicroService] 비지니스 민첩성 2장