Amazon.com CTO이신 Werner Vogels 박사님이 블로그에 1998년에 만들어진 Amazon.com 내부 문서 중 하나인 Distributed Computing Manifesto를 공유하셨습니다. 이 문서는 SOA 아키텍처로 변신하는 Amazon 초기에 작성된 것으로서 아마존 전자상거래 플랫폼과 90년대말의 도전과 지향점에 대한 힌트를 제공합니다. 이 글은 저자의 허가를 얻어 한국어로 번역하였으며, 구글 번역으로 초안을 얻었습니다. 꽤나 긴 문서지만, 1998년 당시에는 일반적이지 않던 이벤트 기반 비동기 처리, 도메인 주도 모델, Pub/Sub 구독 처리 등을 어떻게 아마존 주문 과정에 적용하는지 자세히 나와 있습니다. 더 중요한 점은 이러한 아키텍처 변화를 과감하게 결단을 하고 사내의 개발 문화를 엔지니어 의사 결정을 통해 탑다운으로 바꾸었다는 점입니다.
Amazon의 전자 상거래 측면에서 아키텍처 정보는 대중에게 거의 공유되지 않았습니다. 그래서 2004년에 아마존에서 저의 분산 시스템 연구에 대해 초청 강연을 요청 받았을때, 응하지 않았습니다. 저는 그때 웹 서버와 데이터베이스가 뭐가 그렇게 어렵겠냐? 그렇게 여겼죠. 그런데 그걸 알게돼서 지금은 매우 행복합니다. 서비스 운영의 규모와 다양성은 내가 생각했던 것과는 달랐습니다. 당시 Amazon의 아키텍처는 제가 다른 회사에서 본것 보다 적어도 10년은 앞서 있었습니다. 당시 고성능 웹사이트 뿐만 아니라 기계 학습, 보안, 로봇 공학을 이용한 수백만개 제품에 대한 대용량 트랜잭션 등 분산 시스템 교과서에서나 볼 만한 사례가 Amazon에서 일어나고 있었고, 그것은 지금도 마찬가지입니다. Amazon에서 취업 제안을 했을 때 안 올수가 없었습니다. Amazon CTO로 거의 18년을 지낸 지금, 많은 소프트웨어 엔지니어와 그들이 매일 만드는 시스템의 독창성에 항상 놀라고 잇습니다.
발명하고 단순화하라 (Invent and Simplify)
아마존은 앞서 말한 큰 규모로 서비스를 운영할 때 생기는 도전으로 다른 누구보다 수십 년 앞서 그 규모만큼 성장하고 있습니다. 이런 경우에는 딱히 따라할 교과서도 없고, 구매할만한 소프트웨어도 없습니다. 아마존의 엔지니어들은 미래를 위한 방법을 직접 발명해야 했습니다. 대부분 기하급수적으로 성장할 때마다 기존 아키텍처는 안정성과 성능에 균열을 보이기 시작하고 엔지니어는 새로운 혁신적인 제품을 구축하는 것보다 마구 땜질하는데 시간을 더 보내게 됩니다. 따라서, 특정 성장의 변곡점에서 엔지니어들은 다음 규모의 성장에 대비하기 위해 아직 아무도 해보지 않은 새로운 아키텍처 구조로 가는 길을 발명해야 합니다.
20년 동안 Amazon은 모놀리식(Monolithic)에서 서비스 지향 아키텍처(SOA), 마이크로서비스(Microservice)로, 그리고 공유 인프라 위의 마이크로서비스 아키텍처로 진화하고 있습니다. 이런 변화는 SOA라는 용어가 존재하기 전에 이미 진행되었습니다. 그 과정에서 우리는 인터넷 규모 운영에 대한 많은 교훈을 배웠습니다.
몇 주 후에 있을 AWS re:Invent의 기조 연설에서 저는 이 문서의 개념이 어떻게 마이크로서비스 및 이벤트 기반 아키텍처의 개념을 형성하기 시작했는지에 대해 이야기할 계획입니다. 또한 앞으로 몇 달 동안 분산 컴퓨팅 선언문의 특정 섹션에 대해 자세히 설명하는 일련의 게시물을 작성할 예정입니다.
Amazon 시스템 아키텍처 진화 역사
아마존 건축 역사의 잡초에 깊이 들어가기 전에 25년 전 우리가 어디에 있었는지 조금이나마 이해하는 데 도움이 됩니다. Amazon은 빠른 속도로 움직이며 매일 제품을 구축하고 출시했습니다. 몇 개월, 오늘날 우리가 당연하게 여기는 혁신: 원클릭 구매, 셀프 서비스 주문, 즉시 환불, 추천, 유사점, 도서 내 검색, 제휴 판매 및 타사 제품. 목록은 계속됩니다. 그리고 이것들은 단지 고객을 향한 혁신일 뿐이었습니다. 우리는 배후에서 일어난 일의 겉핥기조차 하지 않습니다. 장면.
아마존 아키텍처 역사를 자세히 알아보기 전에 25년 전 우리가 어디에 있었는지 잠깐 설명해 볼께요. 당시 아마존은 빠른 속도로 움직이며 몇 달에 한 번씩 제품 기능을 출시했으며, 오늘날 우리가 당연하게 여기는 원클릭 구매, 셀프 서비스 주문, 즉시 환불, 상품 추천, 도서 내 검색, 제휴 판매 같은 기능을 계속 만들었습니다. 고객을 향한 혁신을 위해 저희는 피상적으로만 접근하지 않았습니다.
초기 Amazon은 전통적인 2계층 모놀리식 아키텍처로 시작했습니다. Obidos라고 불리는 Stateless 애플리케이션으로 웹 서버와 데이터베이스입니다. 이 시스템에 신규 상품 카탈로그, 고객 및 국가 정보가 다 들어가 있었습니다. 이러한 공유 데이터베이스는 결국 속도 병목 현상을 만들게 되었죠.
1998년에 선임 Amazon 엔지니어 그룹은 차세대 고객 중심 혁신을 지원하기 위해 Amazon 아키텍처를 근본적으로 개편하기 위한 토대를 마련하기 시작했습니다. 핵심은 프레젠테이션 계층, 비즈니스 로직 및 데이터를 분리하는 동시에 안정성, 확장성, 성능 및 보안이 매우 높은 기준을 충족하면서도 비용을 통제하도록 하는 것이었습니다. 이러한 제안을 분산 컴퓨팅 선언문(Distributed Computing Manifesto)이라고 명명했습니다.
저는 90년대 후반 Amazon 엔지니어링 팀의 생각이 얼마나 발전했는지 엿볼 수 있도록 이 내용을 이 블로그에 공유합니다. 그들은 지속적으로 문제의 해법을 스스로 발명했고, 모놀리식 시스템을 우리가 지금 서비스 지향 아키텍처라고 부르는 것으로 확장했고, 아마존의 빠른 성장을 지원해 주었습니다. Amazon의 리더십 원칙 중 하나는 발명하고 단순화하라는 것입니다. 저희 엔지니어들은 실제로 그 모토에 따라 개발하고 있습니다.
모든것은 변한다…
이 문서를 읽으면서 한 가지 명심해야 할 것은 이게 거의 25년 전의 생각이라는 겁니다. 그 이후로 우리는 진짜 먼 길을 왔습니다. (인터넷 환경이나 사용자의 디바이스와 함께) 비즈니스 요구 사항도 발전했고 시스템도 크게 변화하였습니다. 너무 단순하거나 평범하게 들릴 수도 있고, 어쩌면 동의하지 않을 수도 있습니다만… 90년대 후반에는 이런 아이디어가 있었다는 것만 알아주시고 즐겁게 읽어봐 주시기 바랍니다.
분산 컴퓨팅 선언문의 전문은 아래에서 확인할 수 있으며, 영문 PDF로도 볼 수 있습니다.
분산 컴퓨팅 선언문 (Distributed Computing Manifesto)
생성일: 1998년 5월 24일
개정: 1998년 7월 10일
배경
Amazon 서비스 처리량을 현재 주문량의 10배를 지원할 수 있는 지점까지 확장되려면 새로운 아키텍처를 만들고 구현해야 합니다. 우리의 문제는 새로운 아키텍처가 어떤 형태를 취해야 하며 이를 실현하기 위해 어떻게 나아가야 하는가입니다.
현재 2계층 클라이언트-서버 아키텍처는 본질적으로 데이터 바인딩된 아키텍처입니다. 비즈니스를 실행하는 애플리케이션은 데이터베이스에 직접 액세스하고 데이터 모델에 대한 정보를 내장하고 있습니다. 즉, 애플리케이션과 데이터 모델 간에 매우 긴밀한 결합이 있으며 기능이 동일하게 유지되더라도 데이터 모델 변경에는 애플리케이션 변경이 계속 수반되어야 합니다. 이 접근 방식은 확장성이 좋지 않으며 애플리케이션이 데이터 요소 간의 상호 종속 관계에 민감하기 때문에 데이터가 있는 위치에 따라 처리를 분산 및 분리하기 어렵습니다.
주요 컨셉
현재 시스템의 단점을 해결하기 위해 제안하는 새로운 아키텍처에는 두 가지 핵심 개념이 있습니다. 첫 번째는 서비스 기반 모델로 이동하는 것이고 두 번째는 워크플로우 접근 방식에 가깝게 모델링하도록 프로세스를 전환하는 것입니다. 이 문서에서는 새로운 아키텍처를 구현하는 데 어떤 특정 기술을 사용해야 하는지는 다루지 않습니다. 이는 새로운 아키텍처가 우리의 요구 사항을 충족하고 구현에 착수할 것이라고 판단한 경우에만 결정되어야 합니다.
서비스 기반 모델 (SOA)
먼저 프레젠테이션(클라이언트), 비즈니스 로직 및 데이터가 분리되는 3계층 아키텍처로 이동할 것을 제안합니다. 이를 서비스 기반 아키텍처(SOA)라고도 합니다. 애플리케이션(클라이언트)은 더 이상 데이터베이스에 직접 액세스할 수 없으며 기능을 수행하는 데 필요한 비즈니스 로직을 포함하는 잘 정의된 인터페이스를 통해서만 액세스할 수 있습니다. 즉, 클라이언트는 더 이상 기본 데이터 구조나 데이터가 있는 위치에 의존하지 않습니다. 클라이언트가 자체 인터페이스를 통해 서비스와 상호 작용하므로 (서비스 내) 비즈니스 로직과 데이터베이스 간의 인터페이스는 클라이언트에 영향을 주지 않고 변경될 수 있습니다. 마찬가지로 클라이언트 인터페이스는 서비스와 기본 데이터베이스의 상호 작용에 영향을 주지 않고 발전할 수 있습니다.
각 서비스는 워크플로와 결합하여 동기식 및 비동기식 메서드를 모두 제공해야 합니다. 동기식 방법은 고객 추가 또는 공급업체 정보 조회와 같이 응답이 즉각적인 작업에 적용될 수는 있습니다. 그러나, 본질적으로 비동기적인 다른 작업은 즉각적인 응답을 제공하지 않아야 합니다. 예를 들어, 서비스를 호출하여 워크플로 요소를 체인의 다음 처리 노드로 전달하는 것입니다. 요청자는 결과가 즉시 반환되기를 기대하지 않고 워크플로 요소가 성공적으로 대기열에 추가되었다는 표시만 기대합니다. 그러나, 요청자는 결국 요청 결과를 다시 받는 데 관심이 있을 수 있습니다. 이를 용이하게 하기 위해 서비스는 요청자가 비동기 요청의 결과를 받을 수 있는 메커니즘을 제공해야 합니다. 이를 위해 폴링(Polling) 또는 콜백(Callback)과 같은 몇 가지 모델이 있습니다. 콜백 모델에서 요청자는 요청이 완료되었을 때 호출할 루틴의 주소를 전달합니다. 이 접근 방식은 요청과 응답 사이의 시간이 상대적으로 짧을 때 가장 일반적으로 사용됩니다. 콜백 방식의 중요한 단점은 요청이 완료되어 콜백 주소가 유효하지 않게 되면 요청자가 더 이상 활성화되지 않을 수 있다는 것입니다. 폴링 모델은 요청이 완료되었는지 주기적으로 확인하는 데 필요한 오버헤드가 있지만, 폴링 모델은 비동기 서비스와의 상호 작용에 가장 유용한 모델입니다.
서비스 기반 모델로 이동함에 따라 고려해야 할 몇 가지 중요한 의미가 있습니다.
첫 번째는 소프트웨어 엔지니어링에 대해 더 훈련된 접근 방식을 채택해야 한다는 것입니다. 현재 우리 데이터베이스 액세스의 대부분은 비즈니스를 운영하는 Perl 스크립트가 계속 늘어나는데 이것은 임시방편입니다. 서비스 기반 아키텍처로 이동하려면 일정 기간 동안 데이터베이스에 대한 클라이언트의 직접 액세스를 단계적으로 중단해야 합니다. 그렇지 않으면 클라이언트에 부정적인 영향을 미치지 않고 데이터 위치 투명성 및 데이터 모델을 발전시킬 수 있는 3계층 아키텍처의 이점을 얻을 수 없습니다. 이제 서비스와 해당 인터페이스의 사양, 설계 및 개발은 아무렇게나 일어나서는 안 됩니다. 현재와 같은 강하게 결합된 방식이 계속 개발 확산되지 않도록 신중하게 조정해야 합니다. 결론적으로 서비스 기반 모델로 성공적으로 이동하려면 더 나은 소프트웨어 엔지니어링 관행을 채택하고 “고객”에게 비즈니스 데이터에 대한 액세스를 계속 제공하면서 이 방향으로 이동할 수 있는 프로세스를 계획해야 한다는 것입니다.
두번째로 모든 소프트웨어 개발자에게 필요한 중요한 사고 방식의 변화입니다. 우리의 현재 사고방식은 데이터 중심이며 비즈니스 요구 사항을 모델링할 때 데이터 중심 접근 방식을 사용합니다. 우리 회사가 취하는 방법은 기능을 구현하기 위해 데이터베이스 테이블 또는 열을 변경하는 것과 관련이 있으며 액세스하는 애플리케이션 내에 데이터 모델을 포함하고 있습니다. 서비스 기반 접근 방식을 사용하려면 비즈니스 요구 사항에 대한 구현 방식을 최소한 두 부분으로 나누어야 합니다. 첫 번째 부분은 우리가 항상 그래왔듯이 데이터 요소 간의 관계를 모델링하는 것입니다. 여기에는 데이터와 상호 작용하는 서비스에서 시행될 데이터 모델 및 비즈니스 규칙이 포함됩니다. 그러나 두 번째 부분은 우리가 전에 한 번도 해본 적이 없는 것으로, 기본 데이터 모델이 클라이언트에 노출되거나 클라이언트에 의해 의존되지 않도록 클라이언트와 서비스 간의 인터페이스를 설계하는 것입니다. 이는 첫번째로 이야기한 소프트웨어 엔지니어링 문제와 상당히 관련되어 있습니다.
워크플로 기반 모델 및 데이터 도메인화
Amazon의 비즈니스는 워크플로 기반 처리 모델에 매우 적합합니다. 우리는 이미 고객 주문이 접수된 시점부터 출고될 때까지 다양한 비즈니스 프로세스에 의해 작동되는 “주문 파이프라인”을 보유하고 있습니다. 이러한 워크 플로의 각 “요소”는 정적이며 주로 단일 데이터베이스에 상주합니다. 대표적인 워크플로 모델은 customer_orders 프로세스입니다. 각 customer_order에 있는 조건 속성은 다음 워크플로 활동을 지정합니다. 그러나, 중앙에서 처리가 수행되기 때문에 현재 데이터베이스 워크플로 모델은 제대로 확장할 수 없습니다. 작업량이 증가함에 따라(단위 시간당 더 많은 수의 주문) 중앙 시스템이 처리할 수 없는 지점까지 증가할 수 있습니다. 해결 방법은 중앙 시스템에서 업무 부하를 줄일 수 있게 워크플로 처리를 분산하는 것입니다. 이를 구현하려면 customer_orders와 같은 워크플로 요소가 별도의 시스템에 있을 수 있는 비즈니스 처리(“노드”)로 이동해야 합니다. 즉, 프로세스가 데이터로 오는 대신 데이터가 프로세스로 이동합니다. 이를 위해서는 각 워크플로 요소에 워크플로의 다음 노드가 작동하는 데 필요한 모든 정보가 필요합니다. 이 개념은 작업 단위가 한 노드(비즈니스 프로세스)에서 다른 노드로 전환되는 메시지로 표현되는 메시지 지향 미들웨어에서 사용하는 방식과 유사합니다.
워크플로우 문제는 처리되는 방식과 관련이 있습니다. 각 처리 노드에는 포함된 비즈니스 규칙에 따라 워크플로 요소를 다음 노드로 리디렉션할 수 있는 자율성이 있나요? 아니면 노드 간 작업 전송을 처리하는 일종의 워크플로 조정자가 있어야 합니까? 이 두 가지 차이점을 설명하기 위해 신용 카드 청구를 수행하는 예를 들어보겠습니다. 주문 파이프라인의 다음 처리 노드에서 성공한 주문을 참조하고 예외 처리를 위해 다른 노드로 실패한 주문을 전환하는 내장된 “조정자”가 있습니까? 아니면 신용 카드 과금 노드는 어디에서나 호출할 수 있고 그 결과를 요청자에게 그냥 반환하는 서비스입니까? 후자의 경우 요청자 스스로 실패 조건을 처리하고 성공 및 실패한 요청에 대한 처리의 다음 노드를 결정해야 합니다. 워크플로 모델의 이점은 유연성입니다. 각 작업을 이동하는 워크플로 처리 노드는 다양한 조합과 다양한 용도로 사용할 수 있는 상호 교환 가능한 하나의 빌딩 블록입니다. 앞서 든 신용 카드 청구 처리는 다른 컨텍스트에서 호출될 수 있으므로 이러한 워크플로 모델에 적합합니다. 더 큰 규모에서 단일 논리 프로세스는 분산 컴퓨팅(DC) 처리에 잇점이 있습니다. DC 환경에서 처리 과정을 보면, 고객 주문을 수락하고 수행할 작업을 제공한 결과(선적, 예외 조건 등)를 반환합니다. 반면에 특정 프로세스는 인접한 프로세스와의 상호 작용이 고정되어 있고 변경될 가능성이 없는 경우에만 자율 모델의 이점을 얻을 수 있습니다. 예를 들어, 여러 권의 책을 배송하려면 항상 피킹 목록(pickinglist, 온라인 주문 목록을 물류 창고 저장소에서 찾아오는 위치 목록 문서)에서 물건 선반 위치를 지정해야 합니다.
분산 워크플로 접근 방식에는 몇 가지 장점이 있습니다. 그 중 하나는 주문과 같은 비즈니스 프로세스를 쉽게 모델링하여 확장성을 향상시킬 수 있다는 것입니다. 예를 들어, 신용 카드 청구가 병목이 되는 경우 워크플로우 모델에 영향을 주지 않고 추가 청구 노드를 추가할 수 있습니다. 또 다른 장점은 워크플로 경로에 있는 노드가 워크플로 요소에서 작동하기 위해 반드시 원격 데이터베이스 액세스에 의존할 필요가 없다는 것입니다. 즉, 워크플로우 시스템의 다른 부분(예: 데이터베이스)을 사용할 수 없을 때 특정 처리를 계속하여 시스템의 전반적인 가용성을 향상시킬 수 있습니다.
그러나, 메시지 기반 분산 워크플로 모델에는 몇 가지 단점이 있습니다. 기존의 데이터 중심 모델에서는 모든 프로세스가 동일한 중앙 데이터 저장소에 액세스하여 데이터 변경 사항을 시스템 전체에 빠르고 효율적으로 전파할 수 있습니다. 예를 들어 고객이 처음에 지정한 신용 카드 번호가 만료되었거나 거부되어 주문에 사용되는 신용 카드 번호를 변경하려는 경우 쉽게 수행할 수 있으며 변경 사항은 시스템의 모든 곳에 즉시 표시됩니다. 하지만, 메시지 기반 워크플로우 모델에서는 이것이 더 복잡해집니다. 워크플로 디자인은 워크플로 요소가 시스템의 한쪽 끝에서 다른 쪽 끝으로 이동하는 동안 일부 기본 데이터가 변경될 수도 있다는 사실을 수용해야 합니다. 또한, 기존의 대기열 기반 워크플로에서는 특정 워크플로 요소의 상태를 확인하기가 더 어렵습니다. 이를 극복하려면 워크플로 프로세스의 가용성과 자율성에 영향을 주지 않고 외부 프로세스의 이익을 위해 상태 전환을 기록할 수 있는 메커니즘을 만들어야 합니다. 이것은 기존 모놀리식 시스템보다 초기에 올바른 설계를 해야 한다는 것을 의미하고, 앞에서 말한 소프트웨어 엔지니어링 방식을 잘 정립해야 한다는 것을 다시 강조합니다.
워크플로 모델은 시스템에서 일시적인 데이터에 적용되며 잘 정의된 상태 변경을 거칩니다. 그러나 워크플로우 접근 방식에 적합하지 않은 또 다른 데이터 클래스가 있습니다. 대체로 영구적이며 워크플로 데이터와 동일한 빈도 또는 예측 가능성으로 변경되지 않는 것들입니다. 예를 들어, 고객, 공급업체 및 카탈로그 같은 것들입니다. 이들 데이터는 높은 가용성으로 서비스를 제공하면서도 데이터 간의 관계 (예를 들어: 고객의 배송 주소 파악)를 유지 관리하는 것이 중요합니다. 새로운 데이터 도메인 생성 아이디어를 통해 다른 데이터와의 관계에 따라 데이터 클래스를 분할할 수 있습니다. 예를 들어, 고객과 관련된 모든 데이터는 하나의 도메인을 구성하고 공급업체에 대한 모든 데이터는 또 다른 도메인을 구성하며 카탈로그에 대한 모든 데이터는 세 번째 도메인을 구성하는 것입니다. 이를 통해 클라이언트가 다양한 데이터 도메인과 상호 작용하는 서비스를 생성하고 도메인 데이터를 복제하여 소비자에게 더 가까이 다가갈 수 있는 가능성을 열어줍니다. 예를 들어, 고객 서비스 조직이 단일 데이터 서비스의 가용성에 의존하지 않고 로컬 데이터 저장소에서 운영할 수 있도록 고객 데이터 도메인을 영국과 독일에 따로 복제하는 것입니다. 데이터에 대한 서비스 인터페이스는 동일하지만 액세스하는 도메인의 사본은 다를 수 있습니다. 데이터 도메인과 이에 액세스하기 위한 서비스 인터페이스를 생성하는 것은 데이터의 내부 구조 및 위치에 대한 지식에서 클라이언트를 분리하는 중요한 요소입니다.
개념 적용해보기
DC 처리는 위에서 논의한 워크플로 및 데이터 영역 지정 개념의 적용 사례로 적합합니다. DC를 통한 데이터 흐름은 세 가지 범주로 나뉩니다. 첫 번째는 순차 대기열 처리에 적합한 것입니다. 예를 들어, vreceive에 의해 채워진 received_items 대기열 같은 것입니다. 두 번째는 지속성 또는 광범위하게 사용할 수 있어야 하는 요구 사항 때문에 데이터 도메인에 상주해야 하는 데이터입니다. 상품 인벤토리 정보(bin_items)는 상품 소싱 및 고객 지원과 같은 다른 비즈니스 기능에서 모두 필요하므로 이 범주에 속합니다. 마지막 세 번째 데이터 범주는 큐잉 모델이나 도메인 모델에 잘 맞지 않는 것들입니다. 이 데이터 클래스는 일시적이며 로컬에서만 필요합니다. 집합적으로 작동하기 때문에 순차 대기열 처리에는 적합하지 않습니다. 예를 들어, 피킹 목록을 생성하는 데 필요한 데이터입니다. 피킹 목록과 배송 방법에 따라 작업자 피킹 문서에 인쇄할 수 있는 충분한 정보를 누적해야 합니다. 피킹 목록 처리가 완료되면 배송은 워크플로의 다음 단계로 이동합니다. 이러한 세 번째 유형의 데이터를 보관하는 영역은 큐와 데이터베이스 테이블의 속성을 모두 나타내므로 집계 큐라고 합니다.
상태 변경 추적
외부 프로세스가 시스템을 통해 워크플로우 요소의 이동 및 상태 변경을 추적할 수 있는 기능은 필수적입니다. DC 기반 처리의 경우 고객 서비스 및 기타 기능에서 고객 주문 또는 배송이 진행 중인 위치를 확인할 수 있어야 합니다. 우리가 제안하는 메커니즘은 워크플로의 특정 노드가 일부 중앙 집중식 데이터베이스 인스턴스에 행을 삽입하여 처리 중인 워크플로 요소의 현재 상태를 나타내는 방식입니다. 이런 종류의 정보는 작업 흐름의 위치를 추적하는 데 유용할 뿐만 아니라 주문 파이프라인의 작동 및 비효율에 대한 중요한 통찰력을 제공합니다. 상태 정보는 고객 주문이 활성화된 동안에만 프로덕션 데이터베이스에 보관됩니다. 이행되면 상태 변경 정보는 기록 분석에 사용되는 데이터 웨어하우스로 이동됩니다.
진행 중 워크플로 요소 변경
워크플로 처리 방식은 데이터 흐름에 문제를 일으킵니다. 이는 다음 워크플로 노드로 이동하는 데 필요한 모든 정보가 포함되어야 하기 있기 때문인데요. 만약 주문이 처리되는 동안 고객이 주문에 대한 배송 주소를 변경하려는 경우 어떻게 해야 할까요? 기존에는 고객 문의 담당자는 주문 및 고객 데이터가 모두 중앙에 위치하므로 customer_order에서 배송 주소를 변경할 수 있습니다. 하지만, 새로운 워크플로 모델에서 고객 주문은 고객에게 배송되는 과정에서 다양한 단계를 통해 다른 곳에서 처리됩니다. 진행 중인 워크플로 요소에 대한 변경 사항에 영향을 미치려면 속성 변경 사항을 전파하는 메커니즘이 있어야 합니다. 이를 위해서 게시 및 구독(Pub/Sub) 모델을 사용할 수 있습니다. Pub/Sub 모델을 구현하기 위해 워크플로 처리 노드는 특정 이벤트 또는 예외에 대한 알림을 받도록 구독할 수 있습니다. 속성 변경은 하나의 이벤트 클래스를 구성합니다. 진행 중인 주문에 대한 주소를 변경하기 위해 주문 및 변경된 속성을 나타내는 메시지가 특정 이벤트를 구독한 모든 처리 노드로 전송합니다. 또한, 속성 변경이 요청되었음을 나타내는 상태 변경 행이 추적 테이블에 삽입됩니다. 노드 중 하나가 속성 변경에 영향을 미칠 수 있는 경우 상태 변경 테이블에 다른 행을 삽입하여 주문을 변경했음을 나타낼 수 있구요. 이 메커니즘에서는 속성 변경 이벤트 및 적용 여부에 대한 영구 기록이 있습니다.
Pub/Sub 모델의 또 다른 변형은 워크플로 처리 노드 대신 워크플로 조정자가 워크플로 처리 노드 대신 진행 중인 워크플로 요소에 대한 변경 사항에 영향을 주는 것입니다. 위에서 설명한 메커니즘과 마찬가지로 워크플로 조정자는 이벤트 또는 예외에 대한 알림을 수신하고 이를 처리할 때 적용 가능한 워크플로 요소에 적용하도록 구독합니다.
진행 중인 워크플로 요소에 변경 사항을 동기식으로 적용하는 것은 변경 요청의 비동기식 전파에 대한 대안으로 사용 가능합니다. 이는 변경 요청의 작성자에게 변경이 영향을 받았는지 여부에 대한 즉각적인 피드백을 제공하는 이점이 있습니다. 그러나 이 모델에서는 워크플로의 모든 노드가 변경 사항을 동기식으로 처리할 수 있어야 하며 일시적인 사용 불가능으로 인해 요청이 실패해도 되는 변경 사항에만 사용해야 합니다.
워크플로 및 DC 고객 주문 처리
아래 다이어그램은 고객 주문이 DC의 다양한 워크플로 단계를 통해 이동하는 방식을 간략하게 보여줍니다. DC 격리의 결과로 작동하는 방식을 나타내기 위해 현재 작동 방식을 일부 변경한 후, 모델링하였습니다. 이 그림에서는 고객 주문 또는 고객 배송 정보가 정적 데이터베이스 테이블에 남아 있는 게 아니라, 다이아몬드 모양의 상자로 표시되는 워크플로 처리 노드 간에 물리적으로 이동됩니다. 즉, DC 처리가 데이터 도메인(고객 및 재고 정보용), 실제 대기열(수령된 품목 및 유통업체 배송용) 및 집계 대기열(요금 처리, 선택 목록 등용)을 사용한다는 것을 알 수 있습니다. 각 큐는 요청자가 큐의 각 워크플로 처리 노드에서 처리할 워크플로 요소를 삽입할 수 있는 서비스 인터페이스를 제공합니다. 예를 들어, 청구 준비가 된 주문은 청구 서비스의 대기열에 삽입합니다. (물리적으로 여러 곳에서 요청한) 청구 처리는 대기열에서 주문을 제거한 후, 청구가 완료되면 다음 워크플로 노드로 전달거나, 또는 자율적인 워크플로 상 프로세스에 따라 청구 요청자에게 되돌아갈 수도 있습니다.
사족
여기서 부터는 관심 없는 분은 스킵하셔도 됩니다 하하~ 그런데, 1998년에 아마존이 저런 걸 하고 있을 때, 저는 무얼 했나 기억을 더듬어 보니 저도 온라인 전자 상거래 솔루션을 만들고 있었습니다. 당시 아마존 스케일은 아니지만, 아키텍처와 기능에 대해 굉장히 고민도 많이 했고 스크래치 부터 코딩에도 시간을 많이 쏟았던 기억이 나네요.
당시 저희 회사는 전자 상거래 스타트업으로 온라인 음악 서비스를 하고 있었기 때문에 CD 쇼핑몰을 개발하면서, 데이터베이스 마케팅을 위한 백-엔드 솔루션을 개발을 위해 공영 마케팅이랑 개발도 같이 하였구요. 다양한 고객/상품/주문 데이터 들을 효과적으로 구성하기 위해 당시에는 보기 드물게 객체지향 데이터베이스였던 UniSQL (지금의 큐브리드 전신)을 사용하기도 했었습니다.
저희 회사를 투자한 모회사의 사업 때문에 텔레마케팅에 대한 기능 구현이 매우 중요했던 기억이 나네요. 나중에 이 솔루션은 SK의 사이버 LMC 프로젝트, YBM 서울 음반 쇼핑몰인 아이뮤직랜드 수주를 하기도 했었어요.
아래는 1998년 KRNET에서 마켓25-DBM 개발 사례 발표 했던 장표입니다. (아주 오래된 아카이브에서 찾았네요!)
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)
* 이 글의 댓글 일부는 Webmention 도구를 이용하여, 소셜 미디어 공유 반응(Comments, Like, Tweet)을 수집한 것입니다.