Video: 내가 대규모 트래픽을 만나면 제일 먼저 하는 일
Channel: 코딩하는기술사
Duration: 10m 15s
Source: subtitle (auto, ko)
Transcript:
자, 개발자 여러분,이 대규모 트래픽을 처리해야 된다고 하면 여러분들은 당장 뭐부터 시작할 건가요? 어, 서버부터 늘리려고 하지 않으신가요? 자, 오늘은 우리가이 아키텍처를 설계할 때 뭐 설계 기법도 좋고 기술도 좋지만 그전에이 요구 사항부터 최적화시키는 것을 시도해 봐야 된다. 이런 말씀을 드리고자 영상을 만들었습니다. 자, 얼마 전에이 추석 명절 기차매가 있었죠. 자, 그때이 코레일이 왜이 노선마다 메일을 다르게 했을까요? 자, 여기 코레일 홈페이지를 보시면 9월 10일부터 9월 11일까지 일주일 동안 노선별로 이렇게 요일을 구분해서 예매를 받았죠. 왜 이렇게 했을까요? 교통 약자부터 해서 이렇게 노선별로 나눴습니다. 어, 먼저이 결론부터 말씀을 드리면 능력 있는 아키텍트는이 설계 기법이나 기술로만 문제를 해결하려고 하지 않습니다. 뭐 서버 정설하고 대기를 만들고 선착순, 순서 보장 같은 이런 기법, 기술도 중요한데요. 이런 기술적인 기법을 설계적인 기법을 적용하기 이전에이 대규모 트래픽을 처리하는 더 잘 처리하는 방법이 있습니다.

그게 뭐냐면 바로 요구 사항을 조절하는 것. 저는 이것을 요구사항 설계라고 하겠습니다. 자, 그래서 명질 성착권 예매와 같이 이런 대규모 처리 상황에서 요구 사항을 설계를 해서 어떻게 잘 설계하는지 그 접거법을 말씀드리겠습니다. 자, 첫 번째는 트래픽을 나누는 것입니다. 방금 코레일 보셨죠? 일주일 동안 트래픽을 분산시켜 버린 거죠. 만일에 하루에 다 만든다고 하면이 전체 트래픽을 그 날 그 시간에 다 받아야 되겠죠. 그런데 이것을 일주일로 분산을 시키면 1/ 1로 트래픽이 분산되겠죠. 작아지겠죠. 자, 이렇게 기술이 아니라 요구상 정책 변경을 통해서 우리 시스템을 보다 안정적이고 좋은 성능을 낼 수 있도록 설계할 수 있습니다. 그래서이 트래픽의 총량을 줄일 수 없다면 피크의 트래픽을 줄여라. 이렇게 접근할 수 있고요. 두 번째는 2를 나누는 것입니다. 앞에서는 전체 트래픽 양에서 그 트래픽을 일별로 분산해서 트래픽을 나눴다면 다음으로는 기능의 복잡성을 제거하는 거죠. 우리 KTX 예매도 보면 자석 번호를 지정하거나 결제를 하는 것은 선착순 예매에 포함되 있지 않습니다.이 선착수 예매에서는 열차 노선을 선택하고 좌속수 몇 개만 할 건지 좌속수만 확보하고 끝이 나죠.

그리고 실제 결제는이 선착순 예매가 끝난 이후에이 예약된 사람을 대상으로 해서 실제 자석 번호 그리고 결제 발권까지 하게 되는 구조죠. 이렇게 대규모트래픽이 몰리는이 예매 단계에서는 최대한이 복잡성을 제거를 시킨 거죠. 만일에 결제까지 다 하도록 했다면 외부에 PG 호출해야 되죠. 응답 지연 생길 수 있죠. 타임업 발생할 수 있죠. 그러면 또 제시도를 해야 되겠죠. 또 결제 정합성 부분도 보장이 돼야 되겠죠. 자, 대규모 선착순 예매에 이런 좌석 지정과 결제까지 다 하게 된다면 개발 기간 그리고 테스트 케이스도 늘어나고 기간도 늘어나겠죠. 또한 장애 케이스도 다양해지겠죠. 그렇기 때문에 고객 응대도 보다 복잡해질 수 있겠죠. 이렇게 피크가 치는 그때에 이런 다양한 기능들을 다 같이 하려고 하면 개발부터 운영까지 복잡성이 한없이 늘어납니다. 자, 그런데 명절 성자권의 핵심은 무엇일까요? 결제를 완료하는게 핵심일까요? 아니죠. 핵심은 전 국민이 동시에 들어와서 선착으로 좌석을 선점하는게 핵심인 거죠. 좌석 번호를 지정하고 결제까지 하고 발권까지 하는 것은 어떻게 보면 부과 기능일 수 있다는 것입니다.

그래서이 기능에서는 선착순으로 좌석을 선점하는이 핵심 기능을 빼고는 다 뒤로 나눠 버린 거죠. 자기 판단의 기준이 있죠. 명제 예매 핵심은 좌석을 선점하는 것이지 결제까지 완벽하게 마무리하는 것이 아니다. 자, 물론 결제까지 완벽하게 마무리하면 좋겠죠. 그렇지만 선택과 집중을 해야 되죠. 이런 대규모 드래픽에서는 안정성이 아주 중요하기 때문에 될 수 있으면 부과적인 기능은 분리하는 것이 좋습니다. 자, 이렇게 크고 복잡한 문제를 작고 단순한 문제로 나누고 분산시키는 접근법. 아키텍터가이 요구 사항을 조절해서 시스템을 안정적으로 설계하고 운영할 수 있는 그런 접근법을 가져가셔야 됩니다. 자, 이런 접근법과 사례는 뭐 기차표뿐만 아니죠. 도메인을 가리지 않고 이런 시도는 늘 있어 왔습니다. 자, 대규모 상황에서 트래픽을 나누는 사례입니다. 이전에 우리 백신 예약 10부제에 있었죠. 자, 생년놀이 끝자리를 해서 전 국민이 백신 예약을 해야 되는데 그러면 또 너무 많이 몰리죠. 이것을 부제로 해서 나눠서 반증성을 가져갔었고요.

대학에서도이 수강 신청할 때 학년별로 나누거나 뭐 또 다른 분리 기준이 있었죠. 이건 역시 트래픽이 한꺼번에 몰려서 부담이 되는 걸 나눈 거죠. 그리고 뭐 팬클럽 선매, 일반 예매 분리는 이거 뭐 트래픽을 나눈다는 개념 이전에 뭔가 혜택을 준다는 뭐 그런 개념도 포함되 있을 테고요. 두 번째이 복잡한 기능 2를 나누는 측면에서 보면 우리 게임에 보면 게임을 처음 출시할 때 사전 다운로드라는 제도가 있습니다. 자, 며칠에 걸쳐서 게임을 다운로드 할 수 있게 해 주는 거죠. 그리고 어, 사전 캐릭터 생성도 있죠. 자, 사전 다운로드와 사전 캐릭터 생성이 트래픽을 나누는 관점으로 볼 수도 있고요. 또 하나는 어 오픈 당일 날에 게임도 다운로드 받고 패치도 받고 캐릭터도 생성하고 중복 체크하고 이런 걸 한 번에 다 또 하면 기능이 아주 복잡해지겠죠. 그래서이 복잡성을 나누는 측면도 있습니다. 뭐 그리고이 커머스에서는 장바구리에는 일단 먼저 담아두게 하고 결제는 나중에 한다. 이렇게도 접근할 수 있을 테고요.

자, 들어오는 사람 즉 트래픽을 나누거나 복잡한 기능을 나누거나 자, 이것은 어떤 비즈니스 도메인에서도 특성은 다를 수 있지만 목적은 같다고 볼 수 있습니다. 피크에서 피크 전으로 나누든 피크 후로 나누든 피크 전으로 나누는 사례는 게임 다운로드 사전 패치 사전 캐릭터 생성 피크 후로 나누는 건 기차표 외매에서 자석번호 지정 결제 자 이렇게 안정성이 확보돼야 되는 피크에서이를 나눠서 앞뒤로 배치를 하는 거죠. 자 다시 말씀드리지만 도메인과 문제는 달라도 핵심은 한 가지입니다. 나눠서 크기와 복잡성을 줄여서 시스템의 안정성 운영의 단순성을 취하는 거죠. 물론 이렇게 나누면 대가도 따르죠. 뭐 제일 먼저 사용자가 조금 불편해질 수 있습니다. 뭐 노선마다 예매일이 달라서 그것을 숙지를 해야 될 테고 어 숙지 못하고 놓치면 못 사게 되겠죠. 그리고 또 마케팅 부서나 뭐 홍보 부서에서는 한 번에 오픈하고 싶어 할 수도 있겠죠. 왜냐면이 노선마다 달라지는 걸 또 사전에 숙지를 시키는 작업을 해야 되니깐요. 또 뭐 운영 부담이 생길 수도 있습니다.

성자권 예매처럼이 선정을 했는데 결제하지 않은 물량을 또 재배정하는 그런 또 처리를 해야 되니깐요. 그래서 우리가 이렇게 나누는 것은 부활을 나눠서 그래픽과 기능을 단순화시켜서 언널 혜택도 있지만이 비용이 이런 식으로 사용자 불편이나 비즈니스 충돌 이런 쪽으로 증가가 되는 부분도 있습니다. 자 그래서 협상을 해야 되죠. 자, 설계나 기술 아니라 요구 사항도이 트레이드오프가 있습니다. 아키텍트는이 트레이드오프를 관련 우리 부서들에게 오픈하고 설득을 해야 되죠. 자, 방금처럼 이렇게 트래픽을 나누고 그리고 기능을 나누는 것에 트레이드오프는 자, 먼저 감소하는 것도 말씀을 드려야 되겠죠. 오픈해야 되겠죠. 앞서 말씀드렸죠. 다만 얻는 것이 중요하죠. 이렇게 규모와 복잡성을 낮추면 인프라 비용이 많이 줄어들겠죠. 100만면 접속할 것을 10으로 나눠서 10만면 접속하도록 하면 비용도 그만큼 줄어드는 거죠. 비용만큼 잘 먹히는 트레이드 오픈 없습니다. 그리고 개발과 테스트 기간 범위가 줄어들겠죠. 자, 이건 역시 비용이죠.

기관이 들고 개발자 많이 드는 것은 비용이죠. 그리고 실제로 오픈했을 때 안정성도 확보되겠죠. 시스템이 장애가 빠질 가능성이 줄어들고 그리고 장애가 발생하더라도 그 장애의 복잡성이 줄어들죠. 그러면 빨리 복구를 할 수 있겠죠. 자, 이건 역시 비용이죠. 그리고 고객 응대 시나리오도 보다 심플해지겠죠. 기능이 복잡하면 결제까지 하고 좌석 선점도 하고 뭐 그런 거 다 하게 되면 고객 응대 시나리오도 복잡해지겠죠. 자, 이건 역시 비용이죠. 자, 이렇게 나누는 것에 따르는 감수해야 될 것과 얻는 것을 드러내고 무엇을 취할 것인지 설득을 하는 거죠. 저기 보시면 조금 불편한 시스템이 자주 멈추는 시스템보다 낫겠죠. 고객이 조금 불편하더라도 시스템이 안정적이면 고객 만족도는 더 높을 수 있습니다. 장애가 복잡하고 자주 발생하면 결국 신뢰를 잃어버리는 거죠. 그것보다는 약간의 불편이 훨씬 낫다는 점입니다. 자, 이렇게 비즈니스 요건 요구 사항을 조절하고 난 뒤에 실제이 기술 설계 기법들을 적용을 하는 것이죠. 요청 자체를 줄이는 지터를 적용한다든지 폴링도 적응 경우로 하든지 그리고 대기열을 둔다든지 뭐 CDN 캐시 둔다든지 스케업 데이터베이스 분산 그래서 우리 아키텍터들은이 순서를 요구 사항부터 최적화시키고 그다음에 기술적인 설계와 기법들을 적용하자는 것입니다.

자 개발자 여러분 요구 사항은 절대적인 것이 아닙니다. 어 위험과 비용을 줄이고이 시스템의 안정성과 운영 효율성을 올릴 방안을 우리 관련 부서와 의사 결정자들에게 제안을 하고 협상하는 것도 아키텍트의 일입니다. 여러분들의 시스템에서 피크 밖으로 옮길 수 있는 일이 무엇인지 늘 생각하시기 바랍니다. 제 채널에서는 아키텍트를 위한 멤버십을 운영하고 있습니다. 소프트웨 아키텍처의 정통 이론부터 실무 설계, 프로젝트 관리와 리더십 등 아키텍트로 성장하는데 도움이 될 만한 다양한 콘텐츠를 제공하고 있습니다. [음악] AI 시대에는 단순 구현을 넘어서 시스템 전체를 조망하고 판단하는 역향이 더욱 중요해지고 있습니다. 개발에 머무르지 않고 아키텍트로 한 단계 더 성장하고 싶다면 멤버십에서 저와 함께 공부하고 성장해 보시기 바랍니다. 그리고 지금까지 함께 해 주시는 우리 멤버 여러분 늘 감사드립니다. [음악] 함께 성장하는 멤버십이 될 수 있도록 계속 고민하겠습니다. 감사합니다.