한빛출판네트워크

제공 : 한빛 네트워크
저자 : Rachel Roumeliotis
역자 : 김상현
원문 : 3 easy reasons why you’ll move your business to the cloud

클라우드 네이티브 애플리케이션 아키택쳐로의 변화는 혁신으로 이어집니다.

클라우드 네이티브 애플리케이션 아키택쳐를 적용할 때 어떻게 클라우드가 혁신과 변화를 가능하게 하는지 회사가 고려해야 할 부분과 클라우드 네이티브 애플리케이션 아키택쳐로의 변화가 가지고 있는 기본적인 동기들을 살펴봅시다.

 

속도(Speed)

속도가 시장에서 중요한 성공 요인이라는 것은 분명합니다. 소프트웨어 기반의 솔루션들을 개발하고 제공하는 사업들은 경쟁자들보다 빠르게 기존의 딜리버리 모델들을 습득해야 합니다.

엔터프라이즈 환경에서 새로운 애플리케이션 환경을 제공하고 새로운 버전의 소프트웨어를 반영하는데 걸리는 시간은 기본적으로 일, 주, 또는 월 단위로 측정됩니다. 신속성의 부족은 특정 릴리즈에 의해 발생할 수 있는 위험을 엄격하게 제한합니다. 왜냐하면 오류를 만들어내고 수정하는 비용 또한 동일한 시간 단위로 측정되기 때문입니다.

인터넷 기업들은 종종 하루에 수 백 번씩 배포를 하는 작업에 대해 표창을 하기도 합니다. 왜 빈번한 배포가 중요한 걸까요? 만약 당신이 하루에도 수 백 번 배포가 가능하다면 거의 즉시 오류들을 처리할 수 있을 것입니다. 그리고 당신이 즉시 오류를 처리할 수 있다면 더 많은 위험을 떠맡게 될 것입니다. 그리고 더 많은 위험을 떠맡게 된다면 결과적으로 당신은 다른 경쟁자들 보다 우위에 설수 있게 됩니다.

탄력성과 셀프서비스를 갖춘 클라우드 기반의 인프라는 자연스럽게 이런 작업에 적합합니다. 클라우드 서비스 API를 호출해서 새로운 애플리케이션 환경을 제공하는 것이 수많은 절차를 거쳐서 진행되는 양식 기반의 방식보다 빠릅니다. 다른 API를 호출해서 새로운 환경에 코드를 반영할 때에는 속도가 더 빠릅니다. 팀에 있는 통합 빌드 서버 환경에 셀프서비스와 후크를 추가하게 되면 속도는 더 향상될 것입니다. 결과적으로 우리는 Lean 그루인 Mary Poppendick이 말한 “당신의 조직은 단 한 줄의 변경된 코드를 반영하는데 얼마나 시간이 걸립니까?” 라는 질문의 답을 몇 분 또는 몇 초 안에 측정할 수 있습니다.

당신이 그렇게 빠르게 처리 할 수 있다면 당신의 팀이, 당신의 비즈니스가 무엇을 할 수 있을지 상상해 보십시오.

보안(Safety)

단지 빠른 것만으로는 충분하지 않습니다. 만약 당신이 차를 타고 건물을 향해 패달을 밟는다면 치명적인 사고를 당하게 될 것입니다. 항공기나 특급 고속열차 같은 운송수단은 빠르고 안전하게 만들어졌습니다. 클라우드 네이티브 애플리케이션 아키택쳐는 내구성, 유효성, 안전성에 대한 요구에 빠르게 대응할 수 있도록 균형을 유지해 줍니다. 따라서 속도와 보안은 갖추는 것은 기본이고 필수입니다.

우리가 앞에서 언급했듯이 클라우드 네이티브 애플리케이션 아키택쳐는 오류를 빠르게 복구하는 것을 가능하게 해줍니다.

우리는 지금 엔터프라이즈 환경에서 프로세스 엔지니어링에 많은 시간을 투자해서 오류를 예방해야 한다는 이야기를 하고 있는 것이 아닙니다. 화려한 디자인, 철저한 문서, 아키텍처 리뷰보드, 긴 회귀 테스트 사이클은 우리가 추구하는 속도에 역행을 하고 있습니다. 물론 이런 관행들은 좋은 의도에서 만들어졌던 것들입니다. 하지만 안타깝게도 그 중 어느 하나도 수많은 결함을 제품으로 만드는 데에 꾸준하게 주목할만한 향상을 보여주지 못했습니다.

그렇다면 우리는 어떻게 빠르고 안전하게 할 수 있을까요?

가시성(Visibility)

우리의 아키텍처는 장애가 발생했을 때 확인하기 위해 필요한 툴을 제공해야만 합니다. 우리는 모든 것을 측정할 수 있어야 하고 “정상적인 것이 무엇인지”에 대해 설명을 할 수 있어야 합니다. (절대값과 변화율을 포함한) 일반적인 상태와의 편차를 찾아내고 원인에 대해 알아낼 수 있어야 합니다. 다양한 통계, 모니터링, 경고, 데이터 시각화 프레임워크와 툴들은 모든 클라우드 네이티브 애플리케이션 아키택쳐의 핵심입니다.

장애 고립(Fault isolation)

장애와 연관된 위험을 줄이기 위해 위해 장애로 인해서 영향을 받을 수 있는 컴포넌트, 또는 기능들의 범위를 제한하는 것이 필요합니다. 만약 실시간 추천 엔진에 문제가 발생해서 Amazon.com에서 물건을 구매할 수 없다면 큰 재앙일 것입니다. 모놀리틱 애플리케이션 아키텍처는 이런 장애 모드에 대한 유형을 가지고 있습니다. 클라우드 네이티브 애플리케이션 아키택쳐는 종종 마이크로 서비스를 사용합니다. 마이크로 서비스로 구성된 시스템들 중에서도 오직 장애 허용 능력을 가지고 있는 마이크로 서비스만이 장애에 대한 범위를 제한할 수 있습니다.

장애 허용능력(Fault tolerance)

시스템을 독립적으로 반영할 수 있는 컴포넌트로 분해하는 것은 적합하지 않습니다. 그리고 우리는 컴포넌트들 중 한곳에서 발생한 장애가 의존관계를 통해 장애를 야기시키는 것을 막아야만 합니다. Mike Nygard는 그의 저서인 “Release It”(Progmatic Programmers) 에서 몇 가지의 장애 허용 패턴들에 대해서 언급하면서 가장 많이 사용되는 것은 서킷 브레이커라고 했습니다. 소프트웨어에서 서킷 브레이커는 전자기기에서 사용되는 서킷브레이커와 매우 유사하게 동작을 합니다. 서킷브레이커가 보호하고 있는 컴포넌트와 그 이외에 오류가 발생한 시스템 사이에 서킷을 오픈 함으로써 오류가 전이되는 것을 방지합니다. 또 서킷이 오픈되어 있는 동안 제품에서 기본적으로 제공되는 기본 셋 같은 폴백도 제공합니다.

자동 복구(Automated recovery)

가시성, 장애고립, 장애 허용능력과 같이 우리는 식별 및 복구 과정에 참여하는 동안 오류를 식별, 복구하고 우리의 고객들에게 적절한 레벨의 서비스를 제공하는데 필요한 툴을 가지고 있습니다. 발생할 때마다 쉽게 발견할 수 있는 패턴을 보여주는 오류들은 식별하기 쉽습니다. 예를 들어 헬스 체크 서비스는 건강한지 아닌지, 상태가 좋은지 나쁜지에 대해 2진법으로 응답을 합니다.

이런 종류의 오류가 매번 발생할 때마다 우리는 같은 행동을 반복할 것입니다. 헬스 체크에 오류가 생겼을 경우, 우리는 단순히 서비스를 다시 시작하거나 다시 배포할 것입니다. 클라우드 네이티브 애플리케이션 아키택쳐는 이런 상황에서 수동으로 개입하는 것을 기다리지 않습니다. 대신 감지 및 복구를 자동화해서 사용합니다. 다시 말해 사람대신 컴퓨터가 호출기를 착용한 것과 마찬가지입니다.

크기(Scale)

요구사항이 많아짐에 따라 요구사항에 대한 서비스를 제공하기 위한 우리의 능력도 조정을 해야만 합니다. 과거에 우리는 더 큰 용량의 서버를 구매하는 방법으로 수직적으로 크기를 확장해서 요구사항을 만족시켰습니다. 결국 목표는 이루긴 했지만 점점 많은 비용을 지불해야만 했습니다. 이것은 용량에 대한 사용이 최대 사용 시점을 기준으로 계획이 되었기 때문에 발생한 문제입니다. 우리는 “이 서비스가 필요한 가장 적절한 용량은 어느 정도인가?” 라는 의문을 갖고 그에 맞는 충분한 하드웨어를 구매합니다. 하지만 대부분의 경우 우리는 이 예측이 잘못되었다는 것을 깨닫게 되고 블랙프라이데이 같은 이벤트 기간 동안에 여전히 허용량을 초과하게 됩니다. 또한 더 빈번하게 유휴상태의 CPU를 가지고 수십, 수백대의 서버를 보게 되고 비효율적인 결과를 초래하게 될 것입니다.

혁신을 선도하는 기업들은 두 가지 방법으로 이 문제를 해결하고 있습니다.

• 대용량 서버를 구매하여 숫자를 늘리는 것보다 다수의 장비를 이용해서 수평적으로 애플리케이션 인스턴스의 크기를 조정한다. 이 장비들은 취득(또는 조립), 그리고 빠르게 배포하는 것이 보다 쉽다.
  
  
• 대용량 서버들이 가지고 있는 비효율성은 같은 공간에 여러 개의 작은 서버들을 가상화하고 여러 개의 고립된 워크로드를 배포하여 개선한다.

Amazon Web Service 같은 일반적인 클라우드 환경이 가능해지면서 이런 두 가지 움직임은 수렴되었습니다. 가상화에 대한 노력은 클라우드 제공자에게로 위임되었고, 소비자들은 수많은 클라우드 서버 인스턴스에 걸쳐있는 그들의 애플리케이션들을 수평적으로 확장하는데 초점을 맞추고 있습니다. 최근 또 다른 변화는 응용 프로그램 배포 단위가 가상서버에서 컨테이너 단위로 변하고 있습니다.

더 많은 혁신을 위해 클라우드 환경이 보여준 변화는 더 이상 기업들은 그들의 소프트웨어를 배포하기 위해 수많은 초기자본이 필요하지 않게 되었습니다. 또한 더 적은 투자로도 지속적으로 유지를 할 수 있게 되었고, API를 통한 공급은 최초 배포 속도를 향상시켜줄 뿐만 아니라 수요의 변화에 대한 대답을 최대한 빨리 할 수 있게 되었습니다.

안타깝게도 이런 모든 혜택들은 비용이 필요합니다. 애플리케이션들은 수직적 크기 보다는 수평적으로 다르게 설계되어야만 합니다. 클라우드의 탄력성은 짧은 수명을 요구합니다. 뿐만 아니라 새로운 애플리케이션 인스턴스를 빠르게 생성할 수 있어야 하며 빠르고 안전하게 그것들을 폐기할 수 있어야 합니다.

이런 필요는 어떻게 지속적으로 처분할 수 있게 상호작용을 해야 하는지라는 상태관리에 의문을 가지게 됩니다. 매우 수직적인 아키텍쳐에 해당하는 세션을 클러스터링 하거나 파일 시스템을 공유하는 고전적인 방법은 스케일링을 제대로 수행할 수 없습니다.

클라우드 네이티브 애플리케이션 아키택쳐의 또 다른 특징은 애플리케이션 인스턴스를 기본적으로 상태없이 유지하는 동안 인-메모리데이터 그리드, 캐쉬, 영구적인 객체 저장에 대한 외부화 입니다. 상태 없는 애플리케이션은 빨리 생성할 수 있고 없앨 수 있습니다. 마찬가지로 요구사항 변화에 대한 응답에 대한 능력을 향상시킬 수 있도록 외부의 상태 매니저에 붙이거나 떼어낼 수 있습니다.

물론 이건 스스로 확장할 수 있는 외부 상태 관리자가 필요합니다. 대부분의 클라우드 인프라를 제공자들은 이 부분의 필요성을 알고 있으며 이런 서비스들을 제공하고 있습니다.