아마존은 클라우드 서비스 시장의 리더임은 말할 것도 없고 서버리스 컴퓨팅을 앞장서서 지지하는 대표적인 기업이다. 따라서 문제의 글을 본받을 만한 개방성을 보여주는 행동으로 평가하는 사람도 있고, 전형적으로 회사의 뒤통수를 때리는 행동이라고 평가하는 사람도 있다. 어느 쪽이든 이 블로그 글은 소셜 미디어 플랫폼에서 다음과 같은 주제로 열띤 논쟁을 촉발했다.
- 그동안의 서버리스/마이크로서비스/SOA(Service-Oriented Architecture)에 관한 온갖 호들갑은 결국 과대포장이었나?
- 소프트웨어 개발에 대한 전통적인 모놀리식 접근법이 과소평가되었는가?
- 일부 기업이 클라우드에서 데이터센터로 앱을 다시 옮기고 클라우드 우선 전략을 재고하는 등 현재 클라우드 전반에서 일어나고 있는 현상과 비슷한 시장 조정이 필요한 시점인가?
소동이 어느 정도 가라앉은 지금, 프라임 비디오 팀의 경험을 면밀히 살펴보면 기업에서 앞으로 적용할 수 있는 몇 가지 중요한 교훈을 얻을 수 있다. 그러나 이에 못지않게 중요한 점은 이들이 직면했던 문제는 조기에, 즉 애플리케이션 계획 프로세스를 시작할 때 네트워킹 전문가들의 의견을 반영해야 할 필요성도 잘 보여준다는 것이다.
무엇이 문제였는가?
가장 먼저 해야 할 질문부터 보자. 이 문제가 광범위하고 일반적인 의미를 갖는 사례일까? 아마존 팀은 실시간 비디오 스트림을 다루는 일을 하므로 엄밀히 말해 일반적인 엔터프라이즈 앱 사례는 아니다. 그러나 관련된 교훈은 데이터 집약적인 저지연 애플리케이션이 포함되는 모든 개발 프로세스에 보편적으로 적용된다.프라임 비디오는 비디오 스트림에서 비디오 멈춤 또는 오디오와 비디오의 동기화 어긋남과 같은 품질 문제를 분석하기 위한 툴을 만들고 있었다. 여러 단계로 구성된 복잡한 프로세스로, 미디어 컨버터가 스트림을 비디오 프레임과 오디오 버퍼로 분할하면 이렇게 분할된 데이터가 결함 탐지기로 전달되는 구조다. 결함 탐지기는 알고리즘을 사용해서 결함을 식별해 실시간 알림을 보내는 소프트웨어이며, 자체 마이크로서비스로 실행 중이었다.
팀이 해당 애플리케이션의 규모를 확장하기 시작하자 2가지 문제가 발생했다. 아마존 S3 스토리지를 대상으로 한 고부하 호출이 너무 많고 프로세스의 오케스트레이션이 어렵다는 점이다.
아마존 프라임 비디오 팀은 “초기 솔루션은 서버리스 구성요소(가령 AWS 스텝 펑션 또는 AWS 람다)를 사용하는 분산 시스템으로 설계했고, 신속하게 서비스를 구축하기 위한 좋은 선택이었다. 이론적으로는 각 서비스 구성요소를 독립적으로 확장할 수 있는 설계였다”라고 말했다.
그러나 “일부 구성요소를 사용한 방식으로 인해 예상된 부하의 5% 정도에서 확장의 한계에 이르렀다. 또한 대규모로 해당 솔루션을 채택하기에는 모든 빌딩 블록의 전체적인 비용이 너무 높았다. 문제를 해결하기 위해 모든 구성요소를 하나의 프로세스로 옮겨 데이터 전송을 프로세스 메모리 내에 유지했고, 이를 통해 오케스트레이션 로직도 간소화했다”라고 설명했다.
전반적인 아키텍처는 그대로 유지됐으며, 원래의 코드를 재사용해서 새 아키텍처로 신속하게 마이그레이션해서 워크플로우를 하나의 아마존 ECS(Elastic Container Service) 작업으로 통합했다.
팀은 블로그에서 “서비스를 모놀리스로 이전한 결과 인프라 비용이 90% 이상 줄었고 확장 역량도 증대됐다. 현재 우리는 수천 개의 스트림을 처리할 수 있고 서비스를 지금보다 더 확장할 용량까지 갖추고 있다”라고 썼다.
엇갈린 반응
이 글은 소셜 미디어에서 논쟁을 불러일으켰다. SaaS 솔루션 제공업체 37시그널스(37signals)의 CTO 데이비드 하이네마이어 핸슨도 즉시 논쟁에 뛰어들었다. 최근 핸슨은 회사의 애플리케이션과 데이터를 아마존 퍼블릭 클라우드에서 빼내기로 하면서 논쟁을 촉발한 바 있다.핸슨은 블로그에서 “마이크로서비스 우선 아키텍처가 합리적인 경우도 있다는 것을 부정하지는 않는다. 다만 극히 드물 뿐이다. 대다수 시스템은 ‘장엄한 모놀리스’로 시작해 유지하는 편이 훨씬 더 효과적”이라고 썼다.
핸슨은 마이크로서비스/SOA 접근 방법이 대규모 엔터프라이즈와 하이퍼스케일러에는 적합하지만, 그보다 작은 기업의 경우 효과를 장담할 수 없다면서 “아마존, 구글 또는 개발자가 수천 명이 있는 다른 소프트웨어 기업이라면 마이크로서비스/SOA는 개선의 기회를 병렬화하기 위한 좋은 방법이다. 각 서비스마다 자체 팀, 자체 타임라인, 담당자, 목표가 있다. 적어도 어느 정도는 전체 환경 내의 다른 부분에서 일어나는 일과는 독립적으로 발전할 수 있다. 특정 규모에 도달하면 그 외의 다른 합리적인 조율 방안이 없다. 이 방법이 아니라면 모두가 서로의 발등을 밟게 되고 끝없는 병합 충돌을 처리해야 할 것”이라고 말했다.
그러나 애플리케이션을 여러 조각으로 나누면 복잡성이 커질 수 있다. 핸슨은 “객체 간 협업에서 시스템 간의 협업으로 추출할 때마다 수많은 책임과 장애 상태가 있는 골칫덩어리를 받아들게 된다”라고 지적했다.
이어 오늘날의 기술 문화에서 전통적인 모놀리식 애플리케이션은 “조롱의 대상”이 됐지만 “자부심을 갖고 모놀리스를 포용하는” 문화가 필요하다며, “모놀리스는 불필요한 개념적 모델을 최대한 많이 축소하고 쓸데없는 추상화를 최대한 많이 제거한 통합 시스템이다. 정작 해야 할 일을 못하도록 하는 시스템 분산에 대한 강력한 ‘반대’의 상징”이라고 덧붙였다.
썬 마이크로시스템즈(Sun Microsystems)와 이베이, 넷플릭스, 배터리 벤처스(Battery Ventures), AWS를 거치며 일해온 베테랑인 아드리안 코크로프트의 생각은 달랐다. 코크로프트는 프라임 비디오 팀이 사실상 부정확한 용어를 사용했다고 주장했다. 모놀리스로 돌아간 것이 아니라 초기 구현을 리팩터링했을 뿐이며, 이는 베스트 프랙티스라는 것이다.
코크로프트는 “프라임 비디오 팀은 서버리스 우선(Serverless First) 방식을 따랐다. 이 방식에서는 뭔가를 구축하기 위한 첫 시도를 스텝 함수와 람다 호출로 조합한다. 뭔가를 구축할 방법을 알아볼 때 며칠이나 몇 주에 걸쳐 프로토타입을 만드는 것은 좋은 접근 방법이다. 이들은 그런 다음 높은 트래픽에 대응하기 위해 확장을 시도했는데, 스텝 함수의 상태 전환 일부가 너무 빈번하게 일어나고 AWS 람다 함수와 S3 사이의 호출이 과도하다는 사실을 발견했다. 이들은 코드 대부분을 재사용해서 ECS를 통해 수평 확장되고 람다 함수를 통해 호출되는 하나의 장기 실행 마이크로서비스로 결합할 수 있었다. 문제는 이 리팩터링을 두고 마이크로서비스에서 모놀리스로 전환했다고 표현했다는 점이다. 이것은 명확히 마이크로서비스 리팩터링 단계이며, 내가 권장하는 방식”이라고 말했다.
코크로프트는 마이크로서비스가 과대포장된 면이 어느 정도 있고, 많은 기업이 “쿠버네티스의 복잡성에는 비용이 따르며 애초에 대규모 팀에서 대규모로 실행하지 않는 한 불필요한 요소”라는 사실을 인식하면서 역풍도 발생했다는 점을 인정했다.
이어 “서버리스만 사용하는 방식은 지지하지 않는다. 지속적인 높은 트래픽과 낮은 지연, 높은 효율성이 필요한 경우에 권장하는 방식은 더 큰 서버리스 이벤트 기반 아키텍처의 일부로 지속적으로 실행되는 자동 확장 컨테이너로 신속한 프로토타입을 다시 구현하는 것이다. 프라임 비디오 팀이 한 작업은 바로 그것”이라고 덧붙였다.
IT 전문가가 기억해야 할 6가지 교훈
기업의 IT 리더가 아마존 프라임 비디오 사례에서 배울 수 있는 중요한 교훈은 다음과 같다.
1. 핵심은 기술이 아니다
아카마이의 선임 제품 마케팅 관리자인 파벨 디스팟은 “기술이 아니라 목표부터 시작하라”라면서 “달성하고자 하는 것부터 시작하고 거기서 제시되는 요구사항에 따라 시스템을 구축해 나가야 한다”라고 말했다.퍼널랩스(Funnel-Labs.io) CEO 비제이 나야르 역시 “문제가 무엇인지 듣기도 전에 마이크로서비스 또는 모놀리스 시스템을 정답 또는 오답으로 정하는 것은 총을 먼저 쏜 다음 질문하는 것과 같다. 무모하고 나쁜 의사 결정으로 이어진다”라고 지적했다.
2. 절충점을 분석하라
마이크로서비스는 유연성을 제공하고 개별 서비스의 독립적인 개발, 배포, 확장성을 실현한다. 하지만 서비스 검색 필요성, 서비스 간 통신, 분산된 시스템 관리 등의 복잡성도 따른다. 서버리스를 선택하는 경우 애플리케이션을 구축하는 기반 인프라를 서비스 제공업체가 수요에 따라 가동하므로 빠른 배포의 장점을 얻게 된다.
3. 첫 설계를 제대로 하라
애플리케이션이 실행되는 기반 인프라는 처음부터 제대로 돼야 한다. 그렇지 않은 경우 프로토타입에서 프로덕션으로 이동할 때 확장 문제에 직면하게 된다.AWS 전문가이자 여행 앱 개발 업체 인에이블스(Enables)의 CTO 데이비트 개티는 “아키텍처를 잘못 설계할 경우 작동하지 않고 많은 비용이 소비되고 복잡해진다. 람다에서 람다로 데이터를 전달해 가면서 작업을 한다는 것은 좋은 생각이 아니다. 모든 처리 작업을 하나의 람다에서 해야 한다”면서, 아마존 프라임 비디오 팀을 향해 “필요한 워크로드를 기반으로 잘못된 의사 결정을 내렸지만 이제는 제대로 하고 있다. 이 사례가 모든 서버리스가 나쁘다는 것을 의미하지는 않는다”라고 말했다.
4. 언어와 종속성을 간소화하라
핸슨은 “마이크로서비스 광기의 나쁜 부작용 중 하나는 수없이 많은 프로그래밍 언어와 프레임워크와 생태계를 포용하는 경향”이라며, 언어는 2가지를 넘지 말아야 한다고 권장했다. 두 언어 중 하나는 생산성에 초점을 둔 언어로 대부분 시간 동안 사용되며, 다른 하나는 문제 영역을 처리하는 데 사용되는 고성능 언어다.나야르는 “서비스를 100가지 작은 서비스로 분할했는데, 문제의 발생지가 어디인지 알 수 없고 서비스 간의 거미줄처럼 얽힌 종속성으로 인해 배포가 극단적으로 어려워진다면 각 서비스의 용도와 논리를 명확히 하기 위한 고민 없이 서비스를 분할했기 때문”이라고 지적했다.
5. 특정 사용례를 목표로 삼아라
코크로프트에 따르면, 간헐적이고 규모가 작은 기업의 워크로드는 아마존 스텝 펑션과 람다를 사용한 서버리스 접근 방법에 적합하다. 핸슨은 “효과적인 마이크로서비스를 보면 시스템에서 좁은 범위의 격리된, 일반적으로 성능이 중요한 특정 부분을 대상으로 하는 경우가 많다”라고 덧붙였다.
디스팟은 서버리스 접근 방법이 유연함을 제공하긴 하지만 마이크로서비스 간, 그리고 백엔드 데이터베이스와의 통신 요구사항으로 인해 지연이 발생할 수 있다고 지적했다.
6. 비용을 고려하라
서버리스 컴퓨팅 제공업체는 코드가 실행되는 시간만큼 비용을 청구하므로 서버리스 환경에서 장기간 실행되는 프로세스가 있는 애플리케이션이라면 비용 효율성이 떨어질 수 있다.주의하지 않으면 스토리지 비용에 얻어맞을 수 있다는 교훈은 아마존 프라임 팀의 사례에서도 얻을 수 있다. AWS 스토리지 비용은 티어 기반으로, 티어 1 고속 액세스가 다른 느린 티어에 비해 값도 더 비싸다. 또한 모든 데이터 요청과 데이터 전송에 대한 비용도 청구되므로 요청이 지나치게 많은 애플리케이션은 빠른 비용 증가를 유발할 수 있다.
editor@itworld.co.kr
함께 보면 좋은 콘텐츠
Sponsored
Surfshark
“유료 VPN, 분명한 가치 있다” VPN 선택 가이드
ⓒ Surfshark VPN(가상 사설 네트워크, Virtual Private Network)은 인터넷 사용자에게 개인 정보 보호와 보안을 제공하는 중요한 도구로 널리 인정받고 있다. VPN은 공공 와이파이 환경에서도 데이터를 안전하게 전송할 수 있고, 개인 정보를 보호하는 데 도움을 준다. VPN 서비스의 수요가 증가하는 것도 같은 이유에서다. 동시에 유료와 무료 중 어떤 VPN을 선택해야 할지 많은 관심을 가지고 살펴보는 사용자가 많다. 가장 먼저 사용자의 관심을 끄는 것은 별도의 예산 부담이 없는 무료 VPN이지만, 그만큼의 한계도 있다. 무료 VPN, 정말 괜찮을까? 무료 VPN 서비스는 편리하고 경제적 부담도 없지만 고려할 점이 아예 없는 것은 아니다. 보안 우려 대부분의 무료 VPN 서비스는 유료 서비스에 비해 보안 수준이 낮을 수 있다. 일부 무료 VPN은 사용자 데이터를 수집해 광고주나 서드파티 업체에 판매하는 경우도 있다. 이러한 상황에서 개인 정보가 유출될 우려가 있다. 속도와 대역폭 제한 무료 VPN 서비스는 종종 속도와 대역폭에 제한을 생긴다. 따라서 사용자는 느린 인터넷 속도를 경험할 수 있으며, 높은 대역폭이 필요한 작업을 수행하는 데 제약을 받을 수 있다. 서비스 제한 무료 VPN 서비스는 종종 서버 위치가 적거나 특정 서비스 또는 웹사이트에 액세스하지 못하는 경우가 생긴다. 또한 사용자 수가 늘어나 서버 부하가 증가하면 서비스의 안정성이 저하될 수 있다. 광고 및 추적 위험 일부 무료 VPN은 광고를 삽입하거나 사용자의 온라인 활동을 추적하여 광고주에게 판매할 수 있다. 이 경우 사용자가 광고를 보아야 하거나 개인 정보를 노출해야 할 수도 있다. 제한된 기능 무료 VPN은 유료 버전에 비해 기능이 제한될 수 있다. 예를 들어, 특정 프로토콜이나 고급 보안 기능을 지원하지 않는 경우가 그렇다. 유료 VPN의 필요성 최근 유행하는 로맨스 스캠은 인터넷 사기의 일종으로, 온라인 데이트나 소셜 미디어를 통해 가짜 프로필을 만들어 상대를 속이는 행위다. 이러한 상황에서 VPN은 사용자가 안전한 연결을 유지하고 사기 행위를 방지하는 데 도움이 된다. VPN을 통해 사용자는 상대방의 신원을 확인하고 의심스러운 활동을 감지할 수 있다. 서프샤크 VPN은 구독 요금제 가입 후 7일간의 무료 체험을 제공하고 있다. ⓒ Surfshark 그 외에도 유료 VPN만의 강점을 적극 이용해야 하는 이유는 다음 3가지로 요약할 수 있다. 보안 강화 해외 여행객이 증가함에 따라 공공 와이파이를 사용하는 경우가 늘어나고 있다. 그러나 공공 와이파이는 보안이 취약해 개인 정보를 노출할 위험이 있다. 따라서 VPN을 사용하여 데이터를 암호화하고 개인 정보를 보호하는 것이 중요하다. 서프샤크 VPN은 사용자의 개인 정보를 안전하게 유지하고 해킹을 방지하는 데 유용하다. 개인정보 보호 인터넷 사용자의 검색 기록과 콘텐츠 소비 패턴은 플랫폼에 의해 추적될 수 있다. VPN을 사용하면 사용자의 IP 주소와 로그를 숨길 수 있으며, 개인 정보를 보호할 수 있다. 또한 VPN은 사용자의 위치를 숨기고 인터넷 활동을 익명으로 유지하는 데 도움이 된다. 지역 제한 해제 해외 여행 중에도 한국에서 송금이 필요한 경우가 생길 수 있다. 그러나 IP가 해외 주소이므로 은행 앱에 접근하는 것이 제한될 수 있다. VPN을 사용하면 지역 제한을 해제해 해외에서도 한국 인터넷 서비스를 이용할 수 있다. 따라서 해외에서도 안전하고 편리하게 인터넷을 이용할 수 있다. 빠르고 안전한 유료 VPN, 서프샤크 VPN ⓒ Surfshark 뛰어난 보안 서프샤크 VPN은 강력한 암호화 기술을 사용하여 사용자의 인터넷 연결을 안전하게 보호한다. 이는 사용자의 개인 정보와 데이터를 보호하고 외부 공격으로부터 사용자를 보호하는 데 도움이 된다. 다양한 서버 위치 서프샤크 VPN은 전 세계 곳곳에 여러 서버가 위치하고 있어, 사용자가 지역 제한된 콘텐츠에 액세스할 수 있다. 해외에서도 로컬 콘텐츠에 손쉽게 접근할 수 있음은 물론이다. 속도와 대역폭 서프샤크 VPN은 빠른 속도와 무제한 대역폭을 제공하여 사용자가 원활한 인터넷 경험을 누릴 수 있도록 지원한다. 온라인 게임, 스트리밍, 다운로드 등 대역폭이 필요한 활동에 이상적이다. 다양한 플랫폼 지원 서프샤크 VPN은 다양한 플랫폼 및 디바이스에서 사용할 수 있다. 윈도우, 맥OS, iOS, 안드로이드 등 다양한 운영체제 및 디바이스에서 호환되어 사용자가 어디서나 안전한 인터넷을 즐길 수 있다. 디바이스 무제한 연결 서프샤크 VPN은 무제한 연결을 제공하여 사용자가 필요할 때 언제든지 디바이스의 갯수에 상관없이 VPN을 사용할 수 있다.