블로그

애플리케이션 전달 비교: 2005 대 2015

로리 맥비티 썸네일
로리 맥비티
2015년 7월 20일 게시

코드를 작성하는 제임스 워드(자신의 설명)는 최근 10년 전과 오늘날의 애플리케이션 배포를 비교하는 훌륭한 글을 썼습니다 . IT 업계 전반에서 잘 알려지지 않은 비밀 중 하나는 애플리케이션 아키텍처와 배포 방식의 변경이 애플리케이션 전달(애플리케이션을 빠르고 안전하며 소비자에게 제공할 수 있도록 하는 실제 프로세스)에 직접적인 영향을 미친다는 것입니다. 예를 들어, 오늘날 마이크로서비스가 가져오는 변화는 네트워크 아키텍처와 배포 모델을 어떻게 바꿀 것인가에 있어서 매우 중요합니다.

알아요, 알아요. 마이크로서비스와 컨테이너화, 클라우드로의 전환이 네트워크를 추상화하여 애플리케이션의 네트워크 의존도를 낮출 것이라고 생각하고 계신가요? 개발자의 관점에서 보면, 그리고 아마도 운영진의 관점에서 보면 이는 사실입니다. 하지만 여전히 네트워크가 필요합니다. 교환되는 데이터는 여전히 이러한 파이프를 통해 흐르고, 네트워크에 있는 서비스는 앱의 속도를 높이고, 보안을 유지하고, 가용성을 보장하는 많은 기능을 담당합니다 . 따라서 애플리케이션이 작성되고 배포되는 위치와 방법이 변경되면 애플리케이션이 해당 애플리케이션의 존재를 인식하지 못하더라도(솔직히 말해서 애플리케이션은 그 존재조차 인식할 수 없어야 함) 해당 서비스에 영향을 미치게 됩니다. 그들은 그런 면에서 수호천사와 같습니다.)

따라서 신청서에 대한 짝사랑이 아니더라도 관계를 고려하면 James의 글은 지난 10년 동안 신청서를 전달하는 방식의 변화에 대한 평행한 시각을 제공했습니다.

배포 아키텍처

2005 2015
콩가라인 플랫폼

콩가라인 2005

플랫폼 2015

2005년에 네트워크 팀(NetOps)은 우리가 "콩가 라인"이라고 부르는 방식으로 애플리케이션을 제공하는 데 필요한 다양한 애플리케이션 서비스를 배포했습니다. 이는 개별적인 포인트 솔루션이었습니다. 앱을 더 빠르게 만들 방법이 필요하다면 개인용 상자에 웹 성능 최적화 제품을 배포하면 됩니다. 부하 분산을 위한 또 다른 상자, 앱 보안을 위한 또 다른 상자 등이 있습니다. 결국 많은 상자로 이루어진 긴 줄이 생겼고, 각 상자는 양쪽 방향으로 통과해야 했습니다. 

2004년에 애플리케이션 전송 컨트롤러가 등장했지만(2005년에는 매우 미숙했음) 오늘날의 플랫폼 으로 발전하기 시작했습니다. 이러한 플랫폼은 공통적인 기능과 처리 기능을 제공하며 모듈(또는 플러그인, 애드온 또는 원하는 대로 부를 수 있는 것)을 사용하여 확장할 수 있습니다. 플랫폼 방식은 컨테이너화와 가상화가 애플리케이션과 서비스 간 이동에 소요되는 시간을 줄이는 것과 같은 방식으로 "와이어에" 소요되는 시간을 크게 줄여줍니다. 또한 오늘날 애플리케이션을 제공하는 데 필요한 다양한 애플리케이션 서비스 전반의 관리를 정규화하는 공통 기반인 플랫폼을 공유함으로써 운영 비용을 절감할 수 있는 기능도 제공합니다.

제품에서 플랫폼으로의 진화는 애플리케이션 배포가 컨테이너 및 마이크로서비스와 같은 새로운 기술을 활용하고 클라우드 환경에 배포하는 더욱 일회용이고 분해 가능한 아키텍처로 이동함에 따라 유리합니다. 이는 다양한 애플리케이션 서비스를 배포하는 데 사용할 수 있거나, 동일한 표준화된 코어를 사용하여 하나만 배포할 수 있기 때문입니다. 이는 배포된 애플리케이션 서비스의 규모가 확장됨에 따라 관리 오버헤드가 줄어들고 애플리케이션이 성장함에 따라 필요에 따라 서비스를 추가할 수 있다는 것을 의미합니다.

배포 방법

2005 2015
수동 배포 프로그래밍 가능한 배포
키보드-png
네트워크 사이드 스크립트 아이콘

2005년에 웹 기반 GUI가 표준으로 사용되기 시작했고 애플리케이션 서비스를 프로비저닝하고 구성하는 주요 방법은 CLI를 통한 것이었습니다. 이 프로세스는 모든 수동 프로세스와 마찬가지로 시간이 걸렸고 애플리케이션 서비스가 더 복잡해짐에 따라 더 많은 시간이 걸렸습니다. 인간의 실수로 인한 문제가 발생하고 이로 인한 영향(네트워크에 있으면 구성 오류로 인한 폭발 반경이 기하급수적으로 커짐)이 커지면서 감독에 더 많은 시간이 필요하게 되었습니다. 복사하여 붙여넣는 방식이 널리 사용되었지만 완벽하지는 않았으며, 서비스를 관리하는 데 따른 관리 비용이 너무 많아서 더 중요한 애플리케이션에만 이러한 서비스의 이점이 제공되었습니다.

2015년으로 넘어가면 DevOps 혁명이 일어납니다. API와 템플릿 기반 구성 모두에서의 프로그래밍 가능성은 네트워크에서도 모든 것을 바꾸고 있습니다. 이제 Puppet 및 Chef와 같은 인기 있는 프레임워크를 사용한 API를 통해 애플리케이션 서비스를 자동화할 수 있으며, Cisco APIC 및 VMware NSX와 같은 오케스트레이션 솔루션과 사전 통합되고 Python, Perl, bash 및 curl로 사용자 정의할 수 있습니다. 애플리케이션 서비스 템플릿은 표준화와 재사용을 가능하게 하며 인프라를 "코드"로 처리하여 지속적인 전달 관행을 네트워크로 확장할 수 있도록 장려합니다.

애플리케이션 개발 내에서 지속적인 전달만큼 보편화되지는 않았지만, 애플리케이션 전달은 더 빠른 서비스 제공을 통해 출시 시간을 단축하고 자동화 및 재사용을 통해 운영 비용을 낮추는 프로그래밍 가능한 배포 옵션을 지원하도록 발전해 왔으며(계속해서 발전하고 있습니다).

배포 폼 팩터

2005 2015
빅 아이언 가상화됨

큰 철

가상화-adc

2005년에는 더 크고, 더 좋고, 더 빠르고, 더 성능이 좋은 네트워크 하드웨어를 구축하기 위한 노력이 시작되었습니다. 이더넷 속도가 증가하고 웹 기반 애플리케이션이 폭발적으로 증가함에 따라 애플리케이션 서비스 요구 사항을 지원하기 위해 네트워크에 구축된 대규모 인프라의 보완적 확장이 필요하게 되었습니다.

오늘날에는 밀도와 자원의 최적 활용에 초점이 맞춰져 있습니다. 즉, 가상화와 클라우드 컴퓨팅이 등장하게 되었고, 둘 다 애플리케이션 제공 플랫폼의 가상화를 통해 지원되었습니다. 이제 애플리케이션 제공 플랫폼은 AWS, Microsoft Azure, Rackspace와 같은 클라우드 환경뿐 아니라 특수 목적 하드웨어나 기성형 하드웨어에 배포 가능한 가상 어플라이언스에도 배포할 수 있습니다. 이러한 기능은 클라우드 환경을 지원하기 위한 필수 사항일 뿐만 아니라 마이크로서비스와 같은 새로운 아키텍처에 적응하기 위해서도 필요합니다. 오늘날 마이크로서비스와 서버 자체는 James Ward가 지적했듯이 "일회용이고, 변경 불가능하며, 덧없습니다..."

이는 DevOps 영역으로 이동하는 많은 애플리케이션 서비스(로드 밸런싱, 애플리케이션 보안 및 최적화) 가 소프트웨어 정의 데이터 센터의 기준을 충족해야 함을 의미합니다. 최소한 규모에 따라 변경 불가능하고 일회용 모델에 적합해야 합니다. 오늘날, 많은 애플리케이션 제공 플랫폼이 존재하며, 프로그래밍 가능한 배포 옵션과 결합되어 이러한 과제를 해결할 준비가 되어 있습니다.

배포 책임

2005 2015
네트워크 팀 네트워크 팀 / DevOps

2005년에도, 그리고 오늘날에도 많은 조직에서 네트워크 팀은 애플리케이션 전달의 배포와 관리를 전적으로 담당하고 있습니다. 조달부터 프로비저닝, 구성까지 전달의 모든 측면은 과거에도, 그리고 지금도 여전히 네트워크 운영에 의해 처리됩니다. 이러한 분리된 모델은 요구 사항이 해결되고, 티켓이 생성되고, 엔지니어가 앱을 제공하는 데 필요한 애플리케이션 서비스를 수동으로 프로비저닝하고 구성함에 따라 지연이 발생함을 의미했습니다.

오늘날에도 여전히 많은 조직에서 이러한 관행이 유지되고 있지만, 클라우드와 마이크로서비스의 영향과 DevOps 도입이 결합되면서 이러한 관행이 바뀌고 있습니다. 서비스로서의 IT에 대한 요구가 강하며, 애플리케이션 서비스 구성에 대한 책임이 운영팀이나 개발팀으로 이전되고 있습니다. 애플리케이션 아핀 서비스가 물리적으로나 토폴로지적으로 앱에 더 가깝게 위치해야 할 필요가 있습니다. 이를 통해 DevOps가 확고하게 주도권을 잡고 해당 서비스를 프로비저닝하고 구성할 책임이 있습니다.

하지만 그렇다고 해서 네트워크 팀이 애플리케이션 제공에서 손을 뗀다는 것은 아닙니다. 민첩성보다는 안정성을 달성하는 데 중점을 둔 보다 전통적인 방식으로 제공되는 애플리케이션 서비스를 요구하는 상당수의 애플리케이션 및 기업 관심사가 있습니다. 해당 서비스는 여전히 네트워크 팀의 영역이며, 앞으로도 그럴 가능성이 높습니다. 하지만 DevOps의 책임을 맡는 사람들도 있고 앞으로도 계속 그럴 것입니다.

지난 10년 동안 애플리케이션 제공은 큰 발전을 이루었습니다. 제품 세트에서 통합 플랫폼으로 진화하고 프로그래밍 기능을 얻었으며 대규모에서 하이퍼바이저와 클라우드 배포를 지원하는 형태로 변형되었습니다. 모바일 애플리케이션과 마이크로서비스, DevOps가 애플리케이션의 빌드, 배포, 제공 방식을 근본적으로 변화시키고 있기 때문에 궁극적으로 이러한 애플리케이션을 제공하고 빠르고 안전하며 가용성을 유지하는 서비스도 지속적으로 발전할 것으로 예상됩니다.