BLOG
혁신(Innovation)은 항상 아마존 DNA의 일부였지만, 약 20년 전, 아마존은 반복적인 프로세스 (발명, 출시, 재개발, 재출시, 재시작, 보완, 반복, 끊임없는 시도)를 구축하는 것을 목표로 급진적인 변화를 겪었습니다. 이 변화는 애플리케이션 구축 방법과 회사의 조직적인 구성 방안에 영향을 미쳤습니다.
당시 아마존은 오늘날 아마존 고객 수의 극히 일부만을 가지고 있었습니다. 그러나 AWS가 제공하는 제품과 서비스를 확장하려면 애플리케이션 아키텍처에 접근하는 방식을 바꿔야 한다는 것을 알고 있었습니다.
Amazon.com 을 강화하는데 사용했던 거대한 모놀리식 “bookstore” 애플리케이션과 대규모 데이터베이스는 속도와 민첩성을 제한했습니다. 비디오 스트리밍과 같이 고객을 위해 새로운 기능이나 제품을 추가할 때마다 첫 번째 제품인 “bookstore”을 위해 특별히 설계된 애플리케이션에서 방대한 양의 코드를 편집하고 다시 작성해야 했습니다. 복잡한 조정을 필요로 하는 길고 다루기 힘든 프로세스였으며, 신속하고 대규모로 혁신할 수 있는 능력이 제한되었습니다.
아마존은 이때 “Distributed Computing Manifesto”를 사용하여 변화를 위한 청사진을 만들었습니다. 이것은 새로운 아키텍처를 설명하는 내부 문서입니다. 이 선언문을 통해 애플리케이션을 “서비스”라고 하는 더 작은 조각으로 재구성하기 시작하여 Amazon을 극적으로 확장할 수 있었습니다.
그러나 애플리케이션 아키텍처 변경은 절반에 불과했습니다. 1998년에 모든 Amazon 개발 팀은 동일한 애플리케이션에서 작업했으며 모든 애플리케이션에서 해당 애플리케이션의 모든 릴리스를 조정해야했습니다.
이 새로운 아키텍처 접근 방식을 지원하기 위해 기능 계층을 세분화하고 조직을 작은 자율 팀으로 재구성하였습니다. (각 팀에 피자 두 판이면 배불리 먹을 수 있을 정도로의 적은 인원). 우리는 이러한 “피자 2판 팀” 각각을 특정 제품, 서비스 또는 기능 세트에 중점을 두어 앱의 특정 부분에 대해 더 많은 권한을 부여했습니다. 이를 통해 개발자는 개별 제품에 영향을 미치는 의사 결정을 신속하게 내릴 수 있는 제품 소유자로 전환했습니다.
조직과 애플리케이션 구조를 분해하는 것은 대담한 아이디어였지만 효과가 있었습니다. 우리는 훨씬 더 빠른 속도로 고객을 위해 혁신을 할 수 있었고 아마존이 성장함에 따라 매년 수십 건의 기능 배포를 수백만 건으로 배포했습니다. 확장성이 뛰어난 인프라 구축에 성공한 결과 궁극적으로 새로운 핵심 역량이 개발되어 2006년 AWS가 설립되었습니다.
그리고 오늘도 저는(원문의 저자: Werner Vogels, Amazon.com의 CTO) 피자 2판 팀에서 계속 일하고 있습니다.
아마존은 빠른 혁신을 추구하는데 있어서 혼자가 아닙니다. 경쟁력을 유지하려면 기업은 민첩성을 높여서 새로운 기회를 지속적으로 발굴하고 더 나은 제품을 만들 수 있어야 합니다. 그렇기 때문에 점점 더 많은 고객이 아마존이 했던 것과 같은 여정을 시작하고 현대적 애플리케이션 개발로 이동하고 있습니다. 이 새로운 접근 방식에는 모놀리 식 아키텍처에서 구성 요소 또는 microservices로의 전환이 필요하지만 최신 애플리케이션의 모범 사례에는 기술 설계 및 구축 방식을 변경하는 것 이상의 것이 포함됩니다. 또한 관리 방법을 재고해야 합니다.
민첩성과 혁신 속도를 높이기 위해 애플리케이션 개발을 성공적으로 사용하려면 조직은 순서에 관계없이 마이크로 서비스, 특수화된 데이터베이스, 자동화된 소프트웨어 릴리스 파이프 라인, 서버리스 운영 모델, 자동화된 지속적인 보안과 같은 5가지 요소를 채택해야 합니다.
아키텍쳐 패턴: 마이크로 서비스
아마존과 같은 대부분의 회사는 가장 빠르고 개발하기 쉬운 시스템이기 때문에 단일 애플리케이션으로 비즈니스를 시작합니다. 그러나 프로세스를 밀접하게 결합하여 단일 서비스로 실행하는 데 문제가 있습니다. 애플리케이션의 한 프로세스에서 수요가 급증하는 경우 해당 한 프로세스의 로드를 처리 할 수 있도록 전체 아키텍처를 확장해야 합니다.
또한 코드 기반이 커짐에 따라 기능 추가 및 개선이 더욱 복잡해져 새로운 아이디어를 실험하고 구현하기가 어렵습니다. 모놀리식 아키텍처 역시 의존적이고 밀접하게 결합된 많은 프로세스가 단일 프로세스 장애의 영향을 증가시키기 때문에 애플리케이션 가용성의 위험을 증가시킵니다.
이것이 기업이 성장함에 따라 마이크로 서비스가 등장하는 이유입니다. 마이크로 서비스 아키텍처를 사용하면 애플리케이션은 각 앱의 프로세스를 서비스로 실행하는 독립 구성 요소로 구성됩니다. 서비스는 온라인 쇼핑 카트와 같은 비즈니스 기능을 위해 구축되었으며 각 서비스는 단일 기능을 수행합니다. 독립적으로 실행되며 단일 개발 팀에서 관리하므로 앱의 특정 기능에 대한 요구에 맞게 각 서비스를 업데이트, 배포 및 확장할 수 있습니다. 예를 들어 쇼핑 카트는 판매 시 훨씬 더 많은 사용자를 지원할 수 있습니다.
조직이 모놀리식에서 마이크로 서비스로 전환함에 따라 많은 개발자들은 파이프 라인을 통해 각 서비스 내의 종속성을 관리하고 싶어하며 앱을 패키징하고 코드를 실행하는 새로운 방법을 만들어야 했습니다. 이러한 혁신으로 인해 인스턴스는 더 이상 유일한 컴퓨팅 옵션이 아닙니다.
컨테이너 또는 AWS Lambda 함수를 사용할 수도 있습니다. 컨테이너는 코드를 패키징하는 데 가장 널리 사용되는 옵션이며 레거시 애플리케이션을 현대화하기 위한 훌륭한 도구입니다. 앱 설정에 비해 뛰어난 이식성과 유연성을 제공하기 때문입니다. Lambda를 사용하면 가장 단순해집니다. 작성하는 유일한 코드는 비즈니스 로직입니다.
마이크로 서비스의 또 다른 고려 사항은 서로 통신할 수 있는 방법이 필요하다는 것입니다. 많은 애플리케이션이 계속 API 연결을 사용하지만 서비스간에 데이터를 전송하기 위한 여러 가지 다른 옵션이 있습니다. 여기에는 실시간 데이터 처리를 위한 스트리밍, 데이터 변경에 대한 응답을 트리거하는 이벤트, 앱 수준의 통신 및 관찰을 위한 서비스 메시가 포함됩니다. 어플리케이션 요구에 가장 적합한 통합 방법을 선택할 수 있습니다.
데이터 관리: 목적에 따른 적합한 데이터베이스
최신 애플리케이션은 단일 데이터베이스가 아닌 데이터베이스와 마이크로 서비스의 일대일 매핑이 있는 분리된 데이터 저장소로 구축 됩니다. 모놀리식 애플리케이션이 커짐에 따라 확장 및 내결함성 문제가 발생하는 것처럼 데이터베이스도 마찬가지이기 때문에 이는 기존 애플리케이션 아키텍처에서 중요한 변화입니다. 또한 단일 데이터베이스는 단일 장애 지점이므로 단일 데이터베이스가 다양한 마이크로 서비스 세트의 특정 요구를 충족시키기가 어렵습니다. 마이크로 서비스와 함께 데이터를 분리하면 필요에 가장 적합한 데이터베이스를 자유롭게 선택할 수 있습니다.
많은 앱의 경우 가장 좋은 방법은 관계형 데이터베이스이지만 여전히 많은 앱의 데이터 요구 사항이 다릅니다. 예를 들어 추천 엔진과 같이 고도로 연결된 데이터 세트에서 작동하는 애플리케이션을 실행하는 경우 관계를 저장하고 탐색하는 Amazon Neptune 과 같은 그래프 데이터베이스를 선택할 수 있습니다.
또는 애플리케이션에서 실시간으로 데이터에 액세스해야하는 경우 게임 및 IoT 앱에 일반적으로 사용되는 Amazon ElastiCache 와 같은 인 메모리 데이터베이스를 선택할 수 있습니다. 일반적으로 최상의 데이터베이스는 마이크로 서비스에 필요한 것을 정확하게 수행하는 데이터베이스입니다.
소프트웨어 전송: 자동 릴리스 파이프 라인
Amazon.com의 모놀리식 아키텍처를 벗어나 피자 2판 팀으로 재구성할 때 단일 릴리스 파이프 라인 사용을 중단하고 각 팀이 독립적으로 릴리스 할 수 있게 되었습니다.
이로 인해 업데이트를 작성하고 제공해야 하는 조정 문제가 제거되었지만 개발 및 릴리스 프로세스를 분산하는 데 새로운 과제가 발생했습니다. 특히 릴리스 프로세스의 각 단계를 수동으로 수행하여 인적 오류 가능성이 있는 경우 모든 팀에서 릴리스 프로세스 및 품질 일관성을 유지하기가 어려워졌습니다.
우리의 솔루션은 표준화와 자동화라는 두 가지 방식으로 진행되었습니다. 먼저 소프트웨어 제공 프로세스를 모범 사례 템플릿으로 정의하여 클라우드 환경에서 모든 인프라 리소스를 모델링하고 프로비저닝하기위한 표준을 제공합니다. 이러한 “infrastructure as code”템플릿은 템플릿이 수동 프로세스를 사용하지 않고 코드를 통해 애플리케이션에 대한 전체 기술 스택을 프로비저닝하므로 팀이 올바른 출발을 시작할 수 있도록 도와줍니다. 아마존에서는 팀의 요구 사항에 따라 프로세스 및 배포를 구성할 수 있습니다.
둘째, 소프트웨어 전송 워크 플로우에서 수동 프로세스를 제거하기 위해 자동화를 사용하기 시작했습니다. CI / CD (Continuous Integration and Continuous Deployment)를 포함한 자동 릴리스 파이프 라인을 사용하여 오류를 최소화하면서 많은 코드를 신속하게 테스트 및 릴리스합니다. CI를 사용하여 팀은 정기적으로 코드 변경 사항을 중앙 저장소에 병합합니다. 그런 다음 자동화된 빌드 및 테스트를 실행하여 문제를 조기에 감지합니다. CD를 사용하여 우리 팀은 사람의 손길이 없이 프로덕션으로 흘러가는 변경 사항을 하루에 여러 번 커밋합니다.
처음에는 사람의 개입없이 배포하는 것이 무섭다는 것을 알았습니다. 그러나 올바른 테스트 및 페일 세이프를 작성하는 데 시간을 투자 한 후 속도와 민첩성이 크게 향상되었을 뿐만 아니라 코드의 품질도 향상되었습니다.
운영 모델: 가능하다면 최대한 서버리스로
최신 애플리케이션에는 움직이는 부분이 많이 있습니다. 최신 앱은 단일 앱과 데이터베이스가 아니라 각각 전용 데이터베이스와 팀이 새로운 기능을 지속적으로 제공하는 수천 개의 서비스로 구성될 수 있습니다.
이 움직이는 부분은 두 가지 범주로 나눌 수 있습니다.
- 회사의 “비밀 소스”의 일부이며 고유 한 사용자 경험 만들기 및 혁신적인 제품 개발과 같이 시장에서 성공하는 활동.
- 우리가 종종 “비확산된 무거운 물건 들기”라고 부르는 활동들은 반드시 해야 할 일이지만 경쟁 우위를 제공하지는 않습니다. 대부분의 비즈니스에서 이러한 작업에는 서버 관리,로드 밸런싱 및 보안 패치 적용과 같은 작업이 포함됩니다.
2014 년에 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있는 컴퓨팅 서비스 인 AWS Lambda 가 출시되면서 “서버리스”개념이 도입되었습니다 . 이는 미분화된 작업을 AWS로 오프로드하여 고객이 비밀 소스 주변의 리소스를 최적화 할 수 있도록 하는 전반적인 목표를 지원하며 현대적인 애플리케이션 개발에서 중요한 요소가 되었습니다. 서버리스로 전환하면 제품 혁신과 같이 회사를 차별화하는 활동에 집중할 수 있습니다.
“서버리스”라고 말하면 인프라 프로비저닝 및 확장이 필요하지 않고 기본 제공되는 가용성 및 보안이 있으며 PPU (Pay-for-Valuebilling) 모델을 사용하는 서비스를 말합니다. 서버리스는 Lambda만이 아니라 전체 애플리케이션 스택입니다.
응용 프로그램 스택은 일반적으로 세 가지 구성 요소로 구성됩니다.
- 애플리케이션 로직을 실행하기위한 AWS Fargate와 같은 컴퓨팅 서비스
- MySQL 및 PostgreSQL 관계형 데이터베이스 또는 데이터를 유지하기위한 Amazon Aurora와 같은 데이터 저장소
- 데이터를 이동시키는 이벤트 버스 Amazon EventBridge와 같은 통합 계층
이러한 서버리스 빌딩 블록을 통해 회사는 서버리스 모델의 이점을 극대화하는 애플리케이션을 구축할 수 있습니다.
아마존은 서버가 없는 것은 아니지만 그 방향으로 나아가고 있습니다. 그리고 많은 고객들도 마찬가지입니다. 실제로 서버에 손대지 않고 비즈니스 로직을 작성하지 않은 전체 세대의 개발자가 곧 있을 것으로 예상합니다. 이유는 간단합니다. 그 이유는 간단하다. 새로운 애플리케이션을 구축하든 기존 애플리케이션을 마이그레이션하든 컴퓨팅, 데이터 및 통합을 위해 서버리스의 기본 솔루션을 사용하든 클라우드가 제공하는 가장 민첩한 이점을 누릴 수 있기 때문입니다.
보안: 모두의 책임
과거에는 많은 회사가 보안을 마치 마법 가루같이 취급했습니다. 즉, 릴리스 준비가 완료된 후 애플리케이션에 뿌려지는 것처럼 말이죠. 지속적인 릴리스 주기에서는 제대로 작동하지 않으므로 조직은 전체 애플리케이션 주위에 방화벽을 구축하여 새로운 보안 접근 방식을 취해야 습니다. 그러나 이것은 또한 도전 과제를 야기한 앱의 모든 부분에 동일한 보안 설정이 적용되었으므로 앱이 다른 설정이 필요할 경우 예를 들어 독립적인 마이크로 서비스로 구축된 경우에 문제가 됩니다.
이러한 이유로 최신 애플리케이션에서는 보안 기능이 앱의 모든 구성 요소에 내장되어 있으며 각 릴리스마다 자동으로 테스트 및 배포됩니다. 이는 보안이 더 이상 보안 팀의 단독 책임이 아님을 의미합니다. 오히려 개발 수명주기의 모든 단계에 깊이 통합되어 있습니다. 엔지니어링, 운영 및 규정 준수 팀은 모두 역할을 수행해야 합니다.
보안은 코드 리포지토리, 빌드 관리 프로그램 및 배포 도구와 같은 툴링에 통합되어 있습니다. 릴리스 파이프 라인 자체와 해당 파이프 라인을 통해 릴리스되는 소프트웨어 모두에 적용됩니다. 서버리스 서비스를 사용하면 운영 체제 버전 업데이트, 소프트웨어 패치 및 모니터링과 같은 기본 인프라 보안이 각 서비스에 내장되어 있으므로 보안 상태를 훨씬 쉽게 유지할 수 있습니다.
여정
고객들은 실제로 애플리케이션을 현대화하기 위해 어떠한 변화를 만들고 있을까요? 단일 경로는 없지만 Amazon에서의 접근 방식을 포함하여 몇 가지 일반적인 패턴이 있습니다.
혁신에 중점을 두고 Amazon.com을 극적으로 확장하기로 결정했을 때, 모놀리식 애플리케이션을 리팩터링하고 조직을 재구성한 다음 자동화 및 추상화를 통해 클라우드에 최적화했습니다. Yelp 와 같은 일부 고객은 아마존과 비슷한 여정을 밟았습니다. .
온 프레미스에서 호스팅되는 애플리케이션으로 시작하는 고객의 경우 가장 일반적인 접근 방식은 애플리케이션을 클라우드로 “리프팅 앤 시프트”하는 것입니다. 그런 다음 많은 고객이 클라우드에서 관리 서비스를 활용하여 데이터베이스 및 API 관리와 같은 항목을 AWS로 오프로드하여 비즈니스 논리에 집중합니다.
오늘날 점점 더 많은 고객들이 새로운 애플리케이션을 서버리스 마이크로 서비스로 구축하여 조직이 클라우드를 최대한 활용할 수 있도록 하는 새로운 길을 가고 있습니다. AWS 플랫폼에서는 애플리케이션이 모든 상태에 공존하고 이러한 경로 중 하나에서 성공적으로 상호 작용할 수 있으므로 현대화하는 올바른 방법은 없습니다.
그러나 우리가 흔히 볼 수 있는 것은 현대적인 앱을 구축하는 고객은 전체 시간, 특히 시간과 리소스를 할당하는 방식에서 혜택을 볼 수 있다는 것입니다. 비즈니스를 정의하는 논리에 더 많은 시간을 소비하고, 최대 고객 요구를 쉽게 충족하고, 민첩성을 높이고, 새로운 기능을 시장에 더 빠르고 자주 제공하기 위해 시스템을 확장합니다.
예를 들어, 자동차 구매자에게 최신 차량 정보를 제공하는 Edmunds.com 은 새로운 웹 사이트 기능을 출시하는 데 걸리는 시간을 6 개월에서 1 주로 줄였습니다. 스타트 업 바이더 는 또한 제품을 출시하는 데 걸리는 시간을 1 년에서 1 개월로 단축했습니다. 기업은 기술에 접근하는 방식을 변경하여 비즈니스 수행 방식을 개선할 수 있습니다.
이것이 현대 애플리케이션의 힘입니다.
원문 URL: https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.