Video: 티켓 예매 시스템 | 고객 요구에서 설계로 가는 접근법
Channel: 코딩하는기술사
Duration: 23m 48s
Source: subtitle (auto, ko)
Transcript:
자, 여러분, 지난 시간에이 아키텍처 용어 여덟 개 같이 한번 봤었죠. 자, 이렇게 설계 언어 여덟 가지 아키텍처 용어를 봤습니다. 어, 그리고이 용어들을 기반으로 해서 아키텍처를 설계할 때 어떤 흐름으로 하는지 이렇게 확인을 했습니다. 그리고 나서이 콘서트 티켓 매매 시스템 요구 사항을 같이 한번 봤었죠.이 요구 사항을 기반으로 해서 아키텍처를 어떻게 설계할지 질문을 드렸습니다. 어, 이렇게 힌트도 드렸죠. 자, 그래서 오늘은이 콘서트 티켓 예매 시스템이라는 것을 고객 요구 사항으로부터 출발해서 아키텍처 설계를 어떻게 해 나가는지 그 설교의 과정을 한번 말씀드려 보겠습니다. 자, 다시 고객의 요구 사항입니다. 아키텍처 설계할 땐 고객 요구 사항이 아주 중요합니다. 그래서 하나씩 볼 텐데요. 자, 넘어가실 분들은 타임라인을 보시고 넘기시면 됩니다. 자, 공연과 자석을 조회하고 원하는 자석을 선택해서 결제할 수 있어야 된다. 그리고 평소에는 한산데 티켓 오픈 직후에는 엄청난 수십 수십만 명이 들어올 수 있다.

그리고 어 좌석이 동일한 좌석이 중복 예매되면 안 된다. 그리고 사람이 몰려도이 서비스가 다운되지 않아야 된다. 그리고 사용자가 너무 오래 기다리지 않았으면 좋겠다. 회원 시스템과 결제 시스템은 지금 사용하고 있는 것을 그대로 연동해야 된다. 그리고 DB는 기존에 포스트레 SQL 그리고 AWS 인프라로 가야 된다. 그리고이 시스템을 만들면 앞으로 다른 공연에서도이 시스템을 사용할 수 있게 해 주세요. 자, 이게 고객의 요구 사항입니다. 자, 여러분들이이 시스템을 설계를 해야 되는 아키텍트라면 무엇부터 하시겠습니까? 또는 AI를 이용해서 무엇부터 AI에게 시키겠습니까? 지난 시간에서도 말씀을 드렸죠. 특정 기술은 아키텍처 설계에 출발점이 아닙니다. 아키텍처를 설계를 시작할 때는 기술부터 떠올리지 마십시오. 자, 먼저 해야 될 것은 이것입니다. 앞서 봤던이 고객의 요구 사항을 잘 정재를 하고 분류를 해야 됩니다. 그리고 나서이 요구 사항으로부터 아키텍처 드라이버를 식별해야 되고요.이 이 드라이브를 만족시킬 수 있는 아텍처, 전략, 스타일, 패턴, 텍틱 이런 다양한 대안들을 비교하고 트레이드오프를 판단해서 우리 시스템에 가장 적합한 아키텍처 구조와 설계를 결정하는 과정으로이 아키텍처를 설계해야 됩니다.

어, 참고로 오늘 말씀드리는이 내용은이 티켓 예매 시스템의 아키텍처 설계의 정답을 말씀드리는 것은 아닙니다. 오늘 말씀드리고 싶은 것은 아키텍트가 고객 사항으로부터 어떻게 설계를 처음부터 끝까지 이끌어 가는지 그 과정을 보여 드리고자 하는 것입니다. 아키텍처는 정답이 없죠. 요구 사항과 제약 해당 시스템 이해 관계자들이 바뀌면 아키텍스도 바뀝니다. 그래서 오늘이 내용을 보고 아 이렇게 설계해야 되겠다는 설계의 정답으로 받아들이시면 안 되고요. 오늘 중점을 둘 것은 아키텍트의 사고 흐름 설계 과정입니다. 자 그럼 시작해 보겠습니다. 자 아키텍트가 고객과 회의를 통해서 요구 사항을 받았습니다. 그러면 제일 처음 할 일은 요구 사항을 정확하게 분석하고 분류하는 것입니다. 지난 시간에 배웠던 아키텍처 드라이브의 세 가지가 있었죠. 기능 요구 사항, 품질 요구 사항, 그리고 제약 사항이었습니다. 자, 앞서 그 고객의 요구 사항으로부터 기능 요구 사항을 식별합니다. 자, 공연 좌석 조회야 되고 선택해서 예매하고 결제할 수 있어야 된다.

자, 이게 일반적인 예매 시스템의 기능이죠. 자, 여기서 품질 요구 사항도 있었죠. 오픈 순간에 수십만 명이 접속할 수 있다. 자, 성능과 확장성의 품질 요구 사항이죠. 그리고 사용자가 몰려도 서비스가 유지가 된다. 자, 가용성에 대한 요구 사항이죠. 그리고 오래 기다리지 않게 했으면 좋겠다. 역시 성능에 대한 품질 요구 사항이고요. 다른 공연에도 사용할 수 있었으면 좋겠다. 자, 변경 용의성 또는 재사용성이라는 품질 요구 사항이 될 수 있습니다. 그리고 제약 사항은 기존 결제 시스템을 이용해야 된다. 기존의 포스트 그 스Q를 사용해야 된다. 그리고 아마존 인프라를 사용해야 된다. 자, 이것은 미리 전제로 주어지는 제약 사항입니다. 자, 여기서 하나 동일 좌석이 중복 판매되면 안 된다. 자, 이것은 기능일까요? 품질일까요? 제약일까요? 어, 사실 이것은 어디에 포함되도 크게 이상하진 않습니다. 기능 관점에서 보면 기능의 정확성 관점에서 기능이라 할 수 있고요. 품질 관점에서 보면 무결성이나 뭐 일관성 같은 품질 요소로도 볼 수 있고 뭐 미리 전제로 주어지는 제약 사항으로 볼 수도 있죠.

그러나 여기서는 별도 항목으로 분리했습니다.이 도메인,이 비즈니스의 불변의 규칙이라고 해서 따로 분리를 했습니다. 어, 왜 그러냐면이 품질 요구상 같은 경우에는 트레이드오프를 판단하면서 일정 부분 고객과 협의가 가능합니다. 그런데이 규칙은 협의할 수가 없는 거죠. 중복 판매가 1분은 돼도 되고 1분은 안 돼야 된다. 이런 협의 자체가 불가능한 거죠. 그래서 품질로 두지 않고 그냥이 비즈니스의 불변의 규칙으로 따로 분리를 했고요. 어, 이것은 식별의 문제이지 이게 어디에 들어가냐 뭐 이런 것도 정답이 있는 건 아닙니다. 그냥 우리가 아키텍처 드라이브를 식별할 때 기본적으로는 기능과 품질 제약으로 나눌 수 있지만 여기서 핵심인 비즈니스 규칙이라고 해서 따로 카테고리 화학화 할 수도 있다는 것입니다. 자, 이거 역시 아키텍처 드라이브인 거죠. 자, 이렇게 드라이브를 찾는 과정에서이 고객의 모호환 표현은 협의를 통해서 구체화시키는 것이 필요합니다. 자, 수십만 명이 몰릴 것입니다라고 했습니다. 자, 수십만 명.

10만 명과 90만 명은 다르죠. 자, 그래서 혹시나 참조할 데이터가 있는지 작년에 어, 최대치는 얼마였는지 아니면 지난번 예매할 때는 최대 얼마나 몰렸는지 그리고 예약 가능한 좌석은 몇 개인지 자, 이런 수치들이 있어야 설계를 더 정확하게 할 수 있겠죠. 다음으로 고객이 사용자가 너무 오래 기다리지 않았으면 합니다. 자,이 너무 오래의 기준도 현재는 없죠. 이것도 아키텍터가 이렇게 물어볼 수 있는 거죠. 어, 이렇게 많은 사용자를 한꺼번에 다 받을 수는 없을 것 같고요. 순서대로 입장을 시키면 어, 누군가는 몇 분 이상 기다리게 될 건데 괜찮을까요라고 물어봅니다. 그러면 고객이 어, 몇 분 정도는 뭐 어쩔 수 없이 기다리는 거 괜찮은데 다만 그 기다릴 때 화면이 가만히 멈춰 있으면 고객은이 시스템이 뻗은 줄 알테니까 화면이 멈춰 있으면 곤란합니다. 이렇게 얘기를 하는 거죠. 자, 그러면 아키텍트가 그러면 고객한테 기다리는 동안 화면이 멈춰 있는 모습이 아니게 대기 순번을 계속 보여주고 본인의 순번이 계속 줄어드는 걸 보여주는 방식으로 구현하겠습니다.

자, 이렇게 협의를 해 나가는 것이죠. 이렇게 설계하고 검증하고 측정할 수 있는 형태로 모한 표현 추상적인 기준을 구체적인 표현과 구체적인 기준으로 만듭니다. 수치로 만들 수 있는 것은 수치로 만드는게 좋고요. 자, 좌석 조회의 성능을 정상 운영시 95%의 사용자가 1초 이내에 응답을 받도록 해야 된다. 이것을 협의해서 구체화시키는 거죠. 그리고 피크 유입을 오픈 1분 내에 최대 30만 명 접속할 수 있다. 자, 트래픽 양을 산정을 하는 거죠. 그리고 가용성 예매 오픈 시간대 핵심 기능은 어 99.9% 뭐 최대한 살렸으면 좋겠다라는 구체적인 가용성 수치로 협의를 하고요. 그리고 중복 판매 안 된다. 자, 이거는 불변의 규칙이었죠. 자, 이렇게 고객과 합의를 통해서 구체화를 시켜야 됩니다. 여기 이렇게 제시한 숫자들을 제가 보라고 하는 것은 아닙니다.이 숫자들은 얼마든지 달라질 수 있는 거고요. 중요한 것은 합의를 통해서 구체화시켜야 된다는 것입니다. 모호한 말을 설계와 테스트가 가능한 기준으로 바꾸는게 중요한 것이죠.

자,이 과정을 통해서 아키텍처 드라이브 식별을 하는 것이죠. 자, 이렇게 식별을 했습니다. 첫 번째 순간적으로 폭증하는 트래픽. 평소에는 한산하지만 티켓을 오픈하는 순간 30만 명이 들어올 수 있다고 했죠. 자,이 특성을 파악하는 거죠. 평소에는 잠잠한데 오픈한이 초반 시점에 엄청난 트래픽이 물린다. 자, 이게 중요한 드라이버 중에 하나고요. 두 번째 동일 좌석이 중복 판매되면 안 된다. 자, 이건 역시 좌석 예약 처리 구조를 크게 바꿀 수 있는 아키텍처 드라이브일 수가 있는 거죠. 동시성 제어나 락 처리 같은게 필요할 겁니다. 세 번째 피크 시간에도 핵심 기능이 보호돼야 된다. 즉 사용자가 초반에 많이 물리는 그 시간에도이 시스템이 무너지면 안 된다. 특히이 핵심 기능은 작품질로 보면 가용성과 회복 탄력성 관점일 테고요. 어 전체이 기능에서 예매 처리라는이 핵심 기능에 우리가 물리적이고 논리적인 리소스를 투입을 해야 된다는 것입니다. 그리고네 번째 외부 결제 장애가 예매 전체로 전파되지 않을 것. 자, 이것은 고객 요구 사항에 직접적으로 있던 내용은 아니었죠.

아키텍트가 경험에서 이런 것을 드라이브로 도출할 수도 있는 겁니다. 우리 고객의 요구 사항 중에서 결제 기존 결제 시스템을 사용해야 된다 했었고요. 그리고 핵심 기능은 살아 있어야 된다 있었죠.이 이 두 가지를 보고 아키텍트가 아 그러면 우리 통제권 밖에 있는 외부 피지사의 어떤 응답 지연이나 장애가 우리 시스템에 전파될 때 어떻게 할 것인가? 핵심 기능은 죽으면 안 된다고 했으니까 이건 역시 외부의 장애가 우리 시스템으로 전파되지 않도록 해야 된다라는 아키텍처 드라이브로 식별를 한 것이죠. 아키텍터가 경험에 의해서. 자, 그리고 다섯 번째 향후 다른 공연에도 재사용할 수 있도록 만들어야 한다. 그리고 제약상도 있었죠. 기존 포스트 SQL과 아마존 인프라와 기존의 결제 시스템 사용해야 된다. 자, 이렇게 다섯 가지 아키텍처 드라이버를 식별로 했습니다. 그리고이 제약 사항 중에서는 일부라도 협의 가능한게 있는지 아니면 모두가 다 필수 전제로 받아들여야 되는 것인지 한번 더 체크하는 것이 좋고요. 자, 이렇게 아키텍처 드라이브를 식별했다면 그다음으로는이 드라이브들의 중요도 우선 순위를 정합니다.

자, 제일 먼저 양보 불과한 불변의 규칙이 있었죠. 자석 중복 판매 금지. 그다음에 어 피크 트래픽에 대응하는게 또 중요했죠. 그리고이 피크 트래픽 때 어 시스템 보호 외부 결제 장애 전파 방지를 포함해서 보호를 해야 된다라는게 있었고요. 그리고 응답이 좀 빨랐으면 좋겠다라는 것도 있었고요. 그리고 향후 다른 공연으로 재사용할 수 있었으면 좋겠다. 자, 우선 순위는 제일 낫지만 역시 아키텍처 드라이버죠. 자, 이렇게 여러 가지 드라이브들의 우선 순위를 정합니다. 어, 그런데 여기서 잠깐만 우리가 기존 시스템 그대로 사용한다면 어떤 문제가 생길까요? 자, 기존에 어플리케이션 서버가 여러 대가 있고 백단에 단일 데이터베이스가 이렇게 있어요. 앞에로드 밸런스가 있고요. 자, 웹서버 여러 포스트 QL 이렇게 직접 조회합니다. 자, 평소에는 아무 문제 없이 잘 동작하겠죠. 그런데 오픈 순간에 30만 명이 몰려든다 그랬죠. 자, 그러면 어떻게 될까요? 어플리케이션은 적당히 분배가 되지만 병목은 데이터베이스죠. 단일 데이터베이스.

자,이 DB가 뻗겠죠. 이렇게 되면 그러면이 시스템 전체가 뻗어 버리겠죠. 이때 어플리케이션 서버를 늘린다고 해도 데이터베이스 자체가 현재 한대기 때문에 병목인 거죠. 그리고 포스트 SQL을 사용해야 된다는 제약 조건이 있었죠. DB를 다른 뭐 노 SQL 같은 걸로 바꿀 수도 없죠. 자,이 상황에서 조회를 좀 버티기 위해서 앞단에 캐시를 둘 수도 있을 겁니다. 자, 그러나 캐시를 두면 조회 성능은 향상이 되겠죠. 그러나 데이터베이스로 쓰기 성능은 여전히 안 좋을 수 있고요. 또는 TV에 또 동시성 충돌이 생길 수도 있겠죠. 자, 조회하고 좌석 선점은 다른 문제죠. 아, 조회는 부하의 문제고 선점은 부하도 있지만 정합성 문제도 있죠. 그래서 캐시를 도입하면 조회 부안은 크게 완화시킬 수가 있습니다. 그래서 이번 사례에서는 일단 캐시는 적용한다는 가정을 하고 남은 문제를 보겠습니다. 자, 아키텍처 드라이버 식별했고 모성을 구체화시켰고 우선 순위도 지정을 했습니다. 자, 이제 본격적으로 설계에 들어가는데요. 어, 그런데 바로이 전체 아키텍처를 그리려고 하지 말고 앞서 식별했던이 드라이브를 만족시키기 위해서 필요한 핵심 설계 질문을 한번 뽑아 보겠습니다.

그리고 나서이 질문에 해당되는 전략과 트레이드 오퍼를 하나씩 식별하고 검토하는 거죠. 자, 질문 세 가지를 뽑아봤습니다. 첫 번째 수십만 명이 한꺼번에 들어오면 자, 설계 문제 첫 번째고요. 두 번째 같은 좌석이 동시에 선택되면 세 번째 결제 시스템이 느려지거나 죽으면 자, 이렇게이 문제가 발생했을 때 어떻게 해야 되는지 그 전략들을 하나씩 살펴보겠습니다. 자, 첫 번째 문제입니다. 수십만 명이 한꺼번에 들어오면 어떤 전략으로 우리가 대응할 수 있을까요? 자, 가장 먼저 떠오르는게 스케일업. 어플리케이션 서버를 여러대 늘려서로드 분배하는 거죠. 또 레이트 리미팅 같은 것도 대응 전략으로 삼을 수 있겠죠. 우리 시스템이 버틸 수 있는 수준을 넘어서는이 상한을 넘어서는 요청은 거부를 시켜 버리는 거죠. 그리고 웨이팅룸 대기열 수십만 명이 들어오면 대기열에 대기를 시키는 거죠. 그리고 우리 시스템이 감당할 수 있는 수준으로만 보내고 나머지는 대기열에서 대기시키는 웨이팅룸 전략입니다. 자,이 외에도 뭐 다른 전략들이 있을 수도 있겠죠.

자, 그러나 여기서는 세 가지 전략을 두고 한번 보겠습니다. 자,이 전략들을 식별했다면이 전략들의 트레이드오프를 판단하는 것입니다. 자, 스케일 아웃은 장점이 어플리케이션 단의 처리 용량을 확대시킬 수가 있죠. 하지만 그에 따른 자원이 들고 또 핵심적인 건 데이터베이스는 단일 병목이 될 수 있는 문제는 그대로 남아 있는 거죠. 다음으로 레이트 리미팅 전략은 오버되는 요청 자체를 거부해 버리면 되기 때문에 좀 단순할 수 있죠. 그렇지만 요청 자체가 거부가 되는 거고 거부가 되면 사용자가 제시도를 해야 되고 제시도를 하는 과정에서 공정성에 문제가 있을 수도 있겠죠. 그리고 대기열 전략은 장점은 우리 시스템으로 들어오는 유입을 동적으로 제어를 할 수가 있죠. 그리고 사용자 입장에서는 UX 사항 좋겠죠. 대기 상태를 계속 보고 순번을 보면서 기다릴 수 있으니까. 그렇지만 대기열 운영 부담이라는 우리가 치료야 될 것도 있는 거죠. 자, 여기서 우리가 아키텍처를 선택을 할 때 고객과 합의한 판단 기준을 한번 보겠습니다.

고객이 이렇게 협의를 했죠. 어, 몇 분 기다리는 것은 괜찮습니다. 다만 화면이 멈춰 있으면 곤란합니다. 자,이 고객 요구 사항에 가장 적합한 것은 웨이팅 룸이겠죠. 그래서 아키텍처 결정을 웨이팅 룸을 주된 우리이 트래픽 제어 전략으로 사용을 합니다. 물론 여기서 스케일 아웃이나 레이트 리미팅 역시 부가적으로 적용을 할 수도 있겠죠. 자, 여기서 말씀드리는 핵심은 수십만 명이 한꺼번에 들어오는이 문제를 해결하는이 대안들의 트레이드오프를 판단해서 우리 요구 사항과 시스템에 적합한 것을 선택하는 과정을 중요하게 봐야 됩니다. 자, 다음으로 두 번째 문제죠. 같은 좌석을 동시에 선택하면 자, 사용자 A와 사용자 B가 같은 좌석 101번을 동시에 예매하려고 하면 우리가 어떻게 해야 될까요? 이걸 안 되게 하는 전략이 필요하겠죠. 그리고 인기 좌석은 엄청나게 요청이 집중되겠죠. 여러 사용자가 좌석 선점을 하기 위해서 밀리초 단위로 동시에 요청을 하겠죠. 그렇지만이 좌석을 선점한 사용자가 결제까지 완료할 때는 몇 분 이상 걸리겠죠.

자, 이런 도매 특성을 파악을 하고요. 그리고 난 다음에이 문제를 대응할 수 있는 전략들을, 대안들을 보는 거죠. 자, 가장 기본적으로 락을 거는 거죠. 비관적 잠금입니다. 자, 데이터베이스의 행을 먼저 잠그고 다른 요청은 기다리게 하는 거죠. 또 다른 전략은 낙관적 락도 있겠죠. 처음부터 락을 걸지 않고 최종 적용할 때 중복됐으면 실패 처리하고 제시도 하는 거죠. 아니면 조건부 갱신도 전략으로 볼 수 있겠죠. 조건을 업데이트 문에 넣어서 별도의 읽기와 버전 비교 없이 한 문장으로 선점 여부를 판정하는 거죠. 또는 락을 외부에 둬서 분산 락을 구현할 수도 있겠죠. 자, 레디스 같은 외부에 둘 수 있겠죠. 자, 이렇게 같은 좌석을 동시에 선택할 때 우리가 그것에 대응하기 위한 전략으로 이런네 가지 전략을 생각해 볼 수가 있고요. 여기서도 트레이드오프를 판단하는 거죠. 비관적 잔금은 흐름이 직관적이지만 락을 유지해야 될 구간이 기회를 줄 수 있죠. 그러면 처리이 떨어지겠죠. 반면에 낙관적 락은 장점은 일단 경합이 적죠.

그러면 처리 높아지겠죠. 그렇지만 충돌이 집중되는 인기 좌석은 무조건 경합이 발생할 거기 때문에 제시도 비용이 엄청 커지겠죠. 원자적 조건부 갱신은 어 별도의 읽기와 버전 비교 없이이 한 문장으로 해당 자석의 선점 여부를 판단할 수가 있죠. 그리고 외부에 레디스 같은 곳에 락을 둬서 분수산 락을 구현하는 것은 데이터베이스의 경합을 안 시키는 거기 때문에 데이터베이스 경합은 완화시킬 수 있지만 정합성에 대한 책임이 외부 분산락과 데이터베이스 두 군데로 나눠지죠. 그리고 레디스 장애 시나리오도 또 감안을 해야 되죠. 자, 여기서 판단 기준 중에 하나는 뭐 중복 판매 연권은 당연한 거고요. 제약 사항이 있었죠. 기존 포스트레스퀘을 유지해야 된다. 그래서 어 이렇게 결정을 한다고 가정합니다. 조건부 업데이트로 결정. 좌석 선점은 포스트 SQL 조건부 업데이트로 하고 해결 수단이 제약 안에 있는데 밖에서 찾을 이유가 없다.이 말은 포스트레 SQL에 이렇게 동시성 제어를 할 수 있기 때문에 레디스 같은 외부 어떤 구성 요소를 추가할 이유가 없다는 말이고요.

이것은 정답이 아니라고 했죠.이 이 설계에서는 이렇게 판단했다는 겁니다. 그리고 좌석 선점과 결제는 아까 말씀드렸듯이 시간이 다르죠. 좌석 선점은 밀리초 단위로 일어나고 결제는 몇 분 동안 진행을 할 수 있는 거죠. 그래서 어떤 좌석에 선점 여부를 두고 중간에 선점 과정이라는 중간 단계를 두고 결제까지 완료를 했으면 솔더로 최종 상태를 업데이트하고 중간에 실패를 하거나이 사용자가 아무것도 하지 않았다면 만료를 시켜서 다시 선점 가능한 형태로 바꾸는 이런 구조로 구현을 해야 되는 거죠. 자, 마지막 문제죠. 세 번째 외부의 결제 시스템이 느리거나 죽으면 자 여기서는이 결제 요청을 동기로 할지 비동기로 할지 이게 대안인 거죠. 자 기존 결제 시스템은 외부에 있는 거기 때문에 우리의 통제권이 아니죠. 그렇지만이 외부 장애가 우리 예매 시스템에 퍼져서 안 되죠. 그래서이 전략 중에 동기와 비동기 어떻게 할지 판단을 하는 거죠. 동기로 할 경우에는 결과를 바로 확인할 수 있지만 외부의 지연이 우리 시스템, 우리 사용자에게 그대로 전달될 수 있고 비동기로 할 경우에는 우리 시스템과 외부 결제 시스템을 격리시킬 수는 있지만 동기적인 결과를 주기는 힘들죠.

그리고 구현이 좀 복잡해지죠. 그래서 아키텍처 결정을 이렇게 합니다. 결제에 대한 성인 요청은 동기로 처지하고 결제 알림과 결제에 따른 후속 처리는 비동기로 분리한다. 그리고이 결제 모듈을 어댑터로 분리해서 타임아웃과 섞기 브레이크를 두고 기존 결제 시스템에 자연스럽게 통합시킨다. 자, 이렇게 해서 기존 결제 시스템과 자연스럽게 통합을 시킵니다. 자, 앞서 봤던 그 세 가지 문제에 대한 아키텍처 대안들을 살펴보고 트레이드오프를 분석해서 우리 시스템의 최적의 아키텍처 결정을 내렸습니다. 자,이 결정들이 모여서 최종적인 구조가 이렇게 나왔습니다. 자, 대규모 트래픽 처리하는 문제. 그리고 중복 좌석 예매가 안 돼야 되는 문제. 그리고 외부 시스템의 장애가 우리 시스템에 전파되지 않아야 된다는 문제. 앞서 말씀드린 레디스는 이미 있다고 가정을 하고요. 자,이 전체 아키텍처 그림이 처음부터 그려진게 아니죠. 우리가 식별한 드라이버를 보고 우선 수리를 정해서 그거에 대한 설계 문제를 하나하나 풀어 나가면서 아키텍처 결정을 하고 난 뒤에 최종적인 아키텍처 구조가 나온 것이죠.

자,이 세 가지 문제를 풀면서 우리가 트레이드오프상 감수해야 할 것들이 있었죠. 대기열을으로 인해서 시스템 보호를 할 수 있었지만 사용자는 대기를 감소해야 되고요. 조건부 업데이트를 통해서 어 단순하게 선점 제어를 할 수 있지만 DV 경과 처리량 한계를 또 감수를 해야 되죠. 데이터베이스에 동시성 제어를 하기 때문에 데이터베이스의 처리량 그대로 따라가는 거죠. 그리고 동기 결제와 석기 브레이크를 둠으로써 결제 결과는 동기적으로 즉시없고 장시 결제 불과와 안내는 비동기로 하기 때문에 부담이 조금 경감됐죠. 자, 이렇게 좋은 아키텍처는 완벽하게 단점이 없는 구조가 아닙니다. 트레이드오프를 판단해서 우리 시스템이 어떤 것을 얻고 어떤 것을 감수할지를 알고 선택한 구조가 좋은 아키텍처인 거죠. 자, 이렇게 아키텍처를 결정했다면 그것을 기록으로 남기는 거죠. 그게 ADR이라고 그랬죠. 자, ADR의 대기열을 결정한 것을 이런 식으로 남길 수 있습니다. 자, 컨텍스트에 예매 오픈 직후에 30만 명이 동시에 접근해서 과부화가 될 수 있다.

자, 대안으로는 검토한 대안으로는 스케일 아웃 레리미팅 대기열 이렇게 대안을 검토했었고 그리고 결정은 웨이팅 룸을 주된 전략으로 삼고 어플리케이션은 필요 용량에 따라서 스케일 아웃한다라는 전략으로 결정을 했고요. 자, 결과는 핵심 예매 시스템을 보호하고 하위 시스템 용량에 맞춘 확장성을 제어한다. 그렇지만 사용자 대기가 발생할 수 있고 대기열 인프라를 추가해야 되고 어 순서와 이탈 정책이 필요하고 그리고 피크 대비해서 비용이 증가할 수 있다. 자,이 결과는이 아키텍처 결정을 내린 뒤에 우리가 어떤 상황에 놓이는지를 다 적는 겁니다. 좋아진 것도 있고 감수해야 될 것도 있고 또 앞으로 추가적으로 설계해야 할 숙제도 생길 수 있죠. 나중에이 문서를 읽는 사람이 알아야 될 걸 모두 적는 겁니다. 자, 이렇게 해서 고객의 요구 사항으로부터 우리 아키텍처 용어를 사용해서 설계 흐름을 한번 따라가 봤습니다. 자, 그런데 여기까지는 아직 가설이죠. 실제 실무에서는 부하 테스트 반드시 해 봐야 됩니다. 정말이 피크 트래픽을 견딜 수 있는지 역시 동시성 테스트도 해 봐야 되겠죠.

정말로 좌석 중복 판매가 일어나지 않는지. 그리고 장애 테스트도 해 봐야 되겠죠. 외부 시스템이 죽은 상황을 시현을 해 봐야 되겠죠. 자, 이런 식으로 아키텍처 드라이브를 직별하고 대안을 보고 트레이드오프 판단하고 결정하고 검증 자, 이런 것들을 검증해야 되겠죠. 검증하고 잘 안 되면 다시 또 설계로 돌아가야 되겠죠. 자, 정리하겠습니다. 티켓 예배 시스템을 설계해 보세요라고 하면 무엇부터 하겠습니까? 자, 이젠이 아니라 설계 흐름을 잘 따라갈 수 있겠죠? 제 채널에서는 아키텍트를 위한 멤버십을 [음악] 운영하고 있습니다. 소프트웨어 아키텍처의 정통 이론부터 실무 설계, 프로젝트 관리와 리더십 등 아키텍트로 성장하는데 도움이 될 만한 다양한 콘텐츠를 제공하고 있습니다. [음악] AI 시대에는 단순 구현을 넘어서 시스템 전체를 조망하고 판단하는 [음악] 역향이 더욱 중요해지고 있습니다. 개발에 머무르지 않고 아키텍트로 한 단계 더 성장하고 싶다면 멤버십에서 저와 함께 공부하고 성장해 보시기 바랍니다. 그리고 지금까지 함께 해 주시는 우리 멤버 여러분 늘 감사드립니다.

함께 성장하는 멤버십이 될 수 있도록 계속 고민하겠습니다. 감사합니다.