빌드 프로세스에 사용할 Azure 기술
이 단원에서는 애플리케이션에 새로운 기능을 빌드하는 데 도움이 되는 혁신 프로세스와 업계의 여러 기술 사이의 관계에 대해 알아봅니다.
DevOps
빌드 단계를 시작하여 혁신 가설을 검증한 후에는 개발과 통합, 배포 주기를 최대한 간소화해야 합니다. 여기서 DevOps가 사용됩니다. DevOps를 “빠르게 안정적으로 소프트웨어 기능을 제공하는 프로세스 및 도구”로 정의할 수 있습니다. 이 정의에 대한 자세한 내용은 다음과 같습니다.
프로세스 및 도구: DevOps 및 전체 혁신 프로세스는 변화를 독려하는 문화 패턴을 기반으로 합니다. Azure와 GitHub는 DevOps를 중심으로 훌륭한 도구를 제공하지만 라이선스 구매로는 충분하지 않습니다. 변화와 혁신을 수용하도록 프로세스와 조직 문화가 발전해야 합니다.
빠르게 소프트웨어 기능 제공: DevOps 프로세스 및 도구는 페일 패스트라는 개념을 수용합니다. MVP 또는 프로토타입을 빌드하여 기능이 올바른 방향으로 가고 있는지를 확인하는 것은 DevOps 개념에서 핵심적인 부분입니다.
안정적으로 소프트웨어 기능 제공: 변화를 꺼리는 조직에서는 가동 중지 시간을 이용하여 빠른 변화를 이루는 경우가 많습니다. 그러나 DevOps 방식에서는 높은 안정성과 빠른 변동률이라는 이와 반대되는 점을 추구합니다. 이는 “왼쪽으로 시프트” 프로세스를 통해 개발 주기의 초기 단계에 테스트를 통합하여 구현할 수 있습니다.
시간 경과에 따른 기능 개발이 왼쪽에서 오른쪽으로 늘어나는 선으로 나타납니다. 그런 다음, 레거시 개발 프로세스는 개발 주기가 끝날 때 사용자 유효성 검사 및 품질 관리를 수행합니다. 해당 줄의 “오른쪽” 끝에 있습니다. DevOps 방식에서는 최대한 이른 시점에, 즉 타임라인의 “왼쪽”에서 테스트와 유효성 검사를 진행합니다.
DevOps는 건전한 혁신 문화의 동일한 핵심 개념을 구현합니다. 방법론 채택은 민첩한 혁신 주기에 도달하기 위한 핵심입니다.
마이크로 서비스 아키텍처
모듈화는 복잡한 시스템을 설계하는 복잡성을 줄이기 위한 잘 알려진 기술입니다. 시스템이 분리될 수 없는 많은 요소의 복잡한 상호 작용(종종 “모놀리식”이라고 함)인 경우, 구성 요소의 긴밀한 상호 의존성으로 인해 시스템 개선이 어렵습니다. 모든 변화는 시스템의 나머지 부분에서도 검증되어야 하므로 테스트 프로세스는 복잡합니다.
시스템이 모듈식이라면 잘 정의된 인터페이스를 통해 서로 상호 작용하는 더 작은 하위 시스템으로 분리할 수 있습니다. 다른 모듈과의 인터페이스가 일관되게 유지된다면 전체 시스템은 계속 작동하기 때문에 이런 하위 시스템 중 하나에 변경 사항을 적용하기가 더욱 쉽습니다.
마이크로 서비스 아키텍처는 모듈화를 활용하는 애플리케이션 패턴입니다. 애플리케이션은 독립적으로 개발할 수 있는 별도의 작은 구성 요소로 세분되며, 다양한 프로그래밍 언어를 사용하기도 합니다. 각 구성 요소 또는 마이크로 서비스는 독자적으로 작동할 수 있습니다. 필요에 따라 스케일링할 수 있고, 하나의 단위로 취급하여 문제를 해결할 수 있으며, 다른 마이크로 서비스와 독립적으로 수정할 수 있습니다.
조직에서 자주 묻는 질문은 애플리케이션이 모놀리식일 경우 어떻게 해야 하느냐는 것입니다. 혁신을 도입하기 전에 조직이 애플리케이션을 마이크로 서비스 아키텍처로 재설계해야 할까요? 아니면 혁신 프로세스와 재설계 프로세스를 함께 진행할 수 있을까요? 이 질문에 정답은 없습니다. 고려 중인 애플리케이션의 복잡성 및 비즈니스 관련성에 따라 달라집니다.
Tailwind Traders는 전자상거래 플랫폼에 혁신을 도입하려 할 때 이러한 질문에 맞닥뜨렸습니다. 애플리케이션의 비즈니스 중요도가 높기 때문에 전자상거래 애플리케이션을 마이크로 서비스 아키텍처로 재설계하는 프로젝트를 시작하기로 했습니다. 모듈식 애플리케이션이 없다면 Tailwind Trader가 변화하는 온라인 시장의 동향에 대응하기가 무척 어려워질 것입니다.
하지만 Tailwind Traders는 플랫폼에 있는 몇 가지 중대한 격차를 동시에 해결하기로 했습니다. 애플리케이션 재설계 프로젝트가 완료될 때까지 기다린다면 바로 지금 전자상거래 시장을 혁신하고 있는 새로운 스타트업에게 시장 점유율을 크게 빼앗길 수도 있습니다.
프로젝트는 혁신의 비즈니스 가치에 따라 서로 상호 작용합니다. 재설계 작업은 고객 경험 개선을 위한 수정의 필요성이 가장 높은 중요한 애플리케이션 영역에 초점을 맞추게 됩니다.
컨테이너
컨테이너화 기술은 마이크로 서비스 아키텍처에만 사용되는 것은 아니지만 여러 관련 개념이 함께 작용합니다. 컨테이너는 어떤 플랫폼에도 쉽게 배포할 수 있도록 애플리케이션 코드와 종속성을 캡슐화하는 한 가지 방법입니다.
기존의 애플리케이션 배포에서는 조직이 애플리케이션 런타임, 프로그래밍 라이브러리 또는 외부 구성 요소와 같은 소프트웨어를 먼저 설치해야 합니다. 이러한 방식은 “일부 머신에서만 작동하는” 문제를 유발하는 경우가 많습니다. 개발, 테스트, 스테이징 및 프로덕션 단계에서 동일한 환경을 구현하기가 어렵기 때문입니다. 애플리케이션 종속성이 설치되는 방식에서의 작은 차이들로 인해 테스트 중에는 문제없이 작동하던 애플리케이션도 프로덕션 단계로 전개되면 작동하지 않는 문제가 발생할 수 있습니다.
컨테이너는 게임의 규칙을 변경합니다. 컨테이너 이미지라는 독자적인 배포 단위에 애플리케이션 종속성과 애플리케이션 코드가 함께 패키징되기 때문입니다. 애플리케이션 컨테이너를 개발자의 노트북에 배포하든 아니면 수백 개의 노드가 있는 프로덕션 클러스터에 배포하든 종속성은 동일한 방식으로 처리됩니다. 컨테이너는 정확히 동일한 방식으로 작동하므로 애플리케이션 테스트가 좀 더 안정적으로 진행되고 신뢰할 수 있게 됩니다.
컨테이너는 2013년에 Docker가 자사 코드를 오픈 소스로 공개한 후에 많은 변화를 거쳐 왔습니다. 컨테이너는 이제 Linux와 Windows, 다양한 CPU 아키텍처를 모두 지원합니다. Azure에는 컨테이너 기반 워크로드를 실행하는 데 사용할 수 있는 여러 제품이 있습니다. 이 단원에서는 그 중 몇 가지에 대해 알아봅니다.
Kubernetes와 Red Hat OpenShift
컨테이너 런타임은 컴퓨터에서 컨테이너를 시작하는 기술입니다. 그러나 프로덕션 환경에서는 더 많은 로직이 필요합니다. 더 높은 성능이 요구될 경우 누가 더 많은 컨테이너를 배포할까요? 문제가 있는 경우 컨테이너를 누가 다시 시작할까요? 컴퓨터를 여러 대 사용하는 경우, 특정 컨테이너를 어느 컴퓨터에서 시작할지 누가 결정해야 할까요? 컨테이너 오케스트레이션 플랫폼은 이러한 작업과 그 밖의 여러 작업을 담당합니다.
2015년에 첫 번째 버전이 출시된 Kubernetes는 컨테이너 오케스트레이션을 위한 사실상의 표준이 되었습니다. Kubernetes 클러스터는 여러 작업자 노드로 구성됩니다. 각 작업자 노드에는 컨테이너 런타임이 있어서 컨테이너를 실행할 수 있습니다. 해당 컨테이너에서는 Kubernetes 컨트롤 플레인이 컨테이너화된 애플리케이션의 배포를 예약합니다. 일반적으로 이 컨트롤 플레인은 코어 노드 집합에서 실행됩니다. 애플리케이션을 올바르게 실행하고, 애플리케이션을 스케일 업 또는 스케일 다운하고, 필요한 업데이트를 수행하는 일을 담당합니다.
Kubernetes가 인기 있는 주요 이유 중 하나는 컨테이너가 제공하는 하드웨어 독립성입니다. 컨테이너 기반 애플리케이션은 컨테이너 런타임에 안정적으로 배포할 수 있으므로 다양한 하이퍼바이저를 사용하는 클라우드에서 Kubernetes를 실행할 수 있습니다. 배포된 애플리케이션은 비슷한 방식으로 작동해야 합니다(기본 하드웨어 리소스도 비슷하다고 가정). 많은 조직이 온-프레미스와 퍼블릭 클라우드에서 일관된 애플리케이션 배포 프로세스를 지원하는 추상화 계층으로 Kubernetes를 채택했습니다.
Azure에서 Kubernetes를 실행하기는 쉽습니다. Azure Kubernetes Service는 배포가 간단하고, 작업자 노드의 비용만 고객에게 청구되므로 비용 효율적입니다. Microsoft가 핵심 구성 요소를 포함하는 컨트롤 플레인의 비용과 작업을 담당합니다. Microsoft는 작업자 노드의 운영 체제를 패치하고 업데이트하여 Linux 및 Windows 컨테이너 실행을 위한 Kubernetes 클러스터를 관리하는 운영 복잡성을 훨씬 더 낮춰 줍니다.
OpenShift는 Red Hat에서 개발 및 지원하는 Kubernetes를 기반 애플리케이션 배포 플랫폼입니다. 이 외에도 다양한 기능을 통합합니다. OpenShift에서 애플리케이션을 실행하는 몇몇 조직은 추가 기능과 Red Hat에서 제공하는 지원을 활용하기 위해 그렇게 합니다. Azure에서 OpenShift를 실행하기는 역시 간단합니다. Azure Red Hat OpenShift는 클러스터의 전체 수명 주기를 포함하여 여러 측면을 Microsoft에서 관리하는 OpenShift 클러스터로 구성됩니다.
Azure App Service
Azure App Service는 조직에서 오케스트레이터나 기본 운영 체제를 관리하지 않으면서 웹 기반 워크로드를 실행할 수 있는 플랫폼입니다. 유일한 요구 사항은 사용 가능한 여러 배포 방법 중 하나를 통해 애플리케이션 코드를 서비스에 업로드하는 것입니다. Azure는 Kubernetes의 학습 곡선을 요구하지 않고 애플리케이션을 스케일 인 및 스케일 아웃하고, 기본 가상 머신을 패치 및 유지 관리하는 등의 다양한 나머지 작업을 수행합니다.
Azure App Service는 컨테이너 기반 워크로드를 지원하므로 애플리케이션 코드 대신 컨테이너 이미지를 업로드할 수 있습니다. 또한 Linux 및 Windows 워크로드와 여러 애플리케이션 런타임을 지원합니다.
Azure App Service는 Azure Functions라는 서버리스 옵션을 포함하여 다양한 가격 책정 모델을 지원합니다. Azure Functions에서는 애플리케이션 사용량에 따른 요금만 부과되며, 고정 비용은 없습니다.
서버리스 모델은 시장에서 수용하지 않을 경우 높은 월간 요금을 부과하지 않으면서 새로운 마이크로 서비스를 배포할 수 있도록 지원하기 때문에 혁신을 이룩하는 데 매력적인 옵션입니다. 이는 혁신이 반드시 많은 비용을 의미하지 않는다는 빠르게 실패하기 전략의 또 다른 예입니다.
또한 Azure App Service는 웹앱 슬롯과 같이 DevOps 중심 배포를 지원하는 여러 가지 기능을 제공합니다. 슬롯은 프로덕션 환경에 영향을 주지 않으면서 새로운 기능을 배포할 수 있는 스테이징 영역입니다. 선택한 소수의 고객을 이 새로운 버전의 애플리케이션으로 리디렉션할 수 있으므로 혁신이라는 관점에서 유용합니다. 그런 다음 혁신 가설이 올바른지 확인할 수 있습니다. 새로운 코드를 프로덕션으로 승격하려면 스테이징 환경이 프로덕션 버전이 되도록 슬롯을 “교환”할 수 있습니다.
요약
이 단원에서는 기술이 혁신을 지원하는 방식에 대해 알아보았습니다.
- DevOps 프로세스와 도구는 개발 팀과 운영 팀이 새로운 기능을 빠르고 안정적으로 제공하는 데 도움이 되는 역량을 제공합니다.
- 애플리케이션을 마이크로 서비스로 재구성하면 나머지 부분에 영향을 주지 않으면서 구성 요소를 개별적으로 혁신할 수 있습니다.
- 컨테이너는 여러 플랫폼과 환경에서 안정적으로 애플리케이션을 배포하도록 지원합니다.
- Kubernetes는 컨테이너화된 애플리케이션을 실행하는 클라우드 중립적 오케스트레이션 플랫폼입니다.
- Azure App Service는 관리 오버헤드를 최소화하면서 웹 기반 워크로드를 실행할 수 있습니다. 이 제품은 서버리스 또는 애플리케이션 슬롯 등 혁신 주기의 속도를 높이는 여러 기능을 제공합니다.
Tailwind Traders는 전자상거래 애플리케이션을 마이크로 서비스 아키텍처로 재설계하기로 했습니다. “모놀리식”에서 분리할 첫 번째 애플리케이션 하위 시스템은 경쟁사가 고객에게 더 나은 가치를 제공하고 있는 핵심적인 영역으로 파악된 결제 서비스입니다.
결제 하위 시스템을 재구성한 후에는 더 많은 애플리케이션 구성 요소를 독립적인 마이크로 서비스로 변환할 예정입니다. 마이크로 서비스는 REST API를 통해 통신합니다. 각 마이크로 서비스의 애플리케이션 코드는 컨테이너화될 것이며, 개발 및 운영 조직은 DevOps 모범 사례를 채택할 것입니다.
Tailwind Traders는 특정 퍼블릭 클라우드에 종속되지 않기 위해 사내에 Kubernetes 전문 지식을 구축하여 Azure Kubernetes Service 클러스터에 애플리케이션을 배포하기로 했습니다. 또한 새로운 마이크로 서비스를 개발해야 하는 경우 개발 비용을 절약하기 위해 MVP 배포용 플랫폼으로 Azure Functions를 도입할 계획입니다.
다음으로 살펴볼 자료
이 단원에서 소개한 여러 개념은 클라우드 채택 프레임워크 문서인 디지털 혁신으로 채택 강화 및 클라우드 채택 프레임워크의 Kubernetes에서 자세히 설명합니다.