5. 챌린지 프로젝트(1)
아는 게 없는 말하는 감자누구인지 알 것 같지만가 있다. 그 감자는 싹을 틔우기 위해 열심히 흙바닥에서 구르며 자바 문법을 2회독 중(...)이고, 스프링을 처음 다뤄보며, 시큐리티를 적용하지 못해서 밤을 새가며 레퍼런스를 직접 참고하면서 기능 흐름을 이해하려고 했고 JPA를 기반으로 트랜잭션 개념과 N + 1 문제를 해결하는 방법에 대해 공부하며 끙끙대고 있다.
아직 한참 부족한 감자는 걷는 감자가 되기 위해 챌린지에 도전 중이다. 그것도 처음 접하는 대용량 트래픽 처리를 주제로...
1) 서비스 배제, 프로젝트 단계 단위화
대용량 트래픽 처리에 있어 매니저님이 조언해주신 키워드 중 가장 깊게 남은 것은 서버의 관점이었다. 작년의 프론트 공부의 여파인지, 여전히 클라이언트의 입장에서 어떻게 보일 지를 생각하며 계획을 짰는데 시작부터 잘못된 것을 깨닫고 험난한 미래가 될 거라는 눈물이 앞을 가리는 예상이...
(1) 우선 개발, MVP
MVP(Minimum Viable Product)는 한글로 해석하면 실행 가능한 최소 기능 제품이 된다. 대용량 트래픽 처리에 있어 실행 가능한 최소 기능은 어떤 의미를 가질지를 곰곰이 생각해봤다. 대용량 트래픽이 발생하는 상황이라면 단순히 수백만 명의 사용자가 동시에 API를 호출하는 상황 역시 예시에 포함될 수 있다. 이런 상황을 가정했을 때, 서버가 부하를 견디며 최적화를 이뤄낼 수 있는 기능이 현재 내 지식 수준에서는 필수 달성 목적이 될 것인데...
뜬금없지만 수학에서의 명제는 표현이 추상적일수록 스코프가 매우매우 넓어진다. 그리고 그 추상적인 전제에 주관성이 붙게 되면 스코프가 무한해진다.
- 나는 키가 크다.
- 나의 키는 1m보다 크다.
- 나의 키는 180cm와 185cm 사이에 있다.
위의 세 문장은 비슷한 표현을 담고 있지만 기준의 수치화(객관화)를 통해 스코프의 범위를 점점 좁혀나가고 있다. 1번 문장은 크다라는 표현 자체가 주관적이기 때문에 스코프가 무한하다고 볼 수 있고, 2번 문장은 기준 수치인 1m를 제시함으로써 스코프를 1번보다는 줄였지만 여전히 무한하다고 볼 수 있다. 3번 문장 역시 스코프가 엄청 좁다고는 할 수 없지만, 그래도 1번과 2번과 달리 기준의 수치를 조금 더 명세화시키며 범위를 제시해서 스코프 범위를 좁히려고 한 문장이 된다.
MVP의 원칙에 대해서는 상품 가치적인 측면으로 다음과 같다.
- 완벽함보다 속도 중시 : 완벽한 제품 개발보다는 빠르게 아이디어를 구현하는 데 더 초점을 둔다.
- 폭넓은 관심보다는 한 곳에 집중 : 특히 테스트 단계의 경우 적절한 특징(예를 들어 특정 기능)에 집중하고 그 특징의 성공을 측정하는 것이 중요하다.
- 폭포수 대신 민첩성 : 물론 제품 아이디어를 갖는 것은 언제나 권장할 만한 일이다. 그러나 그 다음 단계만 구체적으로 계획한다.
- 기능 추가 집착이 아닌 실용성 : 핵심은 최대한 많은 기능을 자랑하는 것이 아니라 사용자에게 구체적인 부가가치를 제공하는 것이다.
- 비용 절감과 판매 : 제품의 성공을 측정하는 기준에는 판매량 외에 비용 절감도 있다.
https://www.itworld.co.kr/news/212179#csidxaed20748fe2d077b599fe78a87f1608
위의 기준 원칙들을 보면 단순 추상적이지 않으면서도 집중적이고 신속하며 효율성을 동시에 추구하려고 한다. 이 점에 비춰봤을 때, 챌린지 프로젝트에서 명시한 우리의 첫 MVP 스펙은 수강 신청 티켓팅 기능이며, MVP 목표는 초당 2만 명의 수강신청 트래픽 처리를 지속적으로 정상 수행하기이다.
전술한 내 생각인 추상화 피하기와 MVP 원칙인 집중적이고 신속하되 효율적인 것을 준수하지 못하고 있다. 저것을 조금 더 구체화해서 수치적인 표현으로 나타내며, 또한 분기별 목표 설정이 필요하다는 생각이 든다.
(2) 테스트 및 모니터링
단순히 일회성 동작에 그치는 프로그램 개발은 빠르게 이뤄진다. 그렇지만 대용량 트래픽 처리라는 키워드는 일회성에 그치는 것이 아닌, 지속적이면서도 안정적인 시스템 구축을 목표로 삼아야 할 것이다. 그렇기에 개발 선후 과정에서의 테스트는 필수적이다. 개인적으로 가장 관심있는 부분이다. 테스트와 모니터링을 통해 약점을 추적하고 보완하는 것은 중요하게 생각하기 떄문.
그런데 여러 레퍼런스를 참조하면서 의문이 들었다. 테스트와 모니터링이 별개의 단계일까? ... 라는 질문은 구글링 몇 번 하면 바로 답이 나오는 것이었다. 약간 닭과 달걀 같은 밀접한 관계의 키워드라고 볼 수 있겠다. 저 둘과 관련된 툴들에 대한 공부는 차후에 진행하고 우선은 SA 작성을 위한 개념 숙지부터 수행할 예정.
테스트와 모니터링은 기준의 객관화 및 수치화가 가장 중시되는 단계일 것이다. MVP 설정을 위해서 최소 성능을 설정할 필요가 있다. 그 최소 성능의 기준에 대해 키워드를 찾아보았다.
TPS(Transaction Per Second)
서비스 처리 건수 / 측정 시간
요청 사용자 수 / 평균 응답 시간
동시 사용자 수 / 서비스 요청 간격
일정 시간동안 얼마나 많은 요청을 처리할 수 있는지를 나타내는 기준이 된다. 정확히는 일정 기간동안 처리되는 트랜잭션의 개수를 1초 단위의 평균값으로 계산한다. 즉, TPS가 높을수록 서비스 사용자의 관점에서는 쾌적한 환경을 제공받을 수 있게 된다. 위의 예시처럼 5초 단위로 트랜잭션 처리를 끊어서 평균값을 계산하면 1 TPS가 계산된다.
다만 서비스 동시 접속자가 증가할수록 TPS의 순간변화율(미분값)은 줄어들게 된다. 왜냐하면 성능의 개선 폭이 서비스 사용자 증가수를 완벽하게 커버하는 것이 불가능하기 때문이다. 다만 위의 그래프는 상당히 이상적인 그래프에 해당한다. TPS가 증가하지 않는 지점(Saturation Point)을 넘어서면 오히려 TPS가 떨어질 가능성도 있기 때문이다.
즉, TPS와 동시 접속자를 기준으로 MVP를 설정하는 것이 중요하다는 것이 내 나름의 결론.
시간
사용자에게 있어서 시간은 응답 시간 뿐이지만, 시스템 입장에서는 사용자 요청에 대하여 응답을 수락 후, 웹 페이지에 랜더링을 수행하는 등의 여러 작업을 처리하는 Think Time이 존재한다. 이를 기반으로 성능 테스트를 수행함에 있어, 실제 지연시간이 발생하는 구간을 파악해야 한다.
- 브라우저와 웹 서버간 구간에서는 정적 리소스, 커넥션, 네트워크 환경 등의 영향을 받을 수 있다.
- 서버 구간은 DB와 애플리케이션 간의 문제, 프로그램 로직 상의 문제, 서버의 리소스 부족 등을 의심해 볼 수 있다.
- 네트워크의 이슈의 경우 테스트하는 환경에 따라 달라질 수 있다. 따라서 상위 5프로의 페이지가 사용자의 트래픽을 받는다는 점을 감안하고 튜닝의 대상을 선정한 뒤 출시 전에 최대 응답시간을 파악하고 있어야 한다.
나름의 MVP 설정
참조 블로그(https://if-blog.tistory.com/14434)에서 발췌한 성능 테스트 예시 설정이다.
EX:
latency : 500ms
throughput
DAU : 7,300,000(명) (2020년 하루 평균 대중교통 이용자 수)
관련 기사 https://www.ajunews.com/view/20200423094948121
평균 접속 수 : 3회 (출근, 퇴근, 환승 등)
1일 총 접속 수 : 21,900,000회
1일 평균 rps : 353회 (1일 총 접속 수 / 86,400)
1일 최대 rps : 3530회 (출, 퇴근 시간 - 10배 예상)
이걸 기준으로 수강신청 서비스에 있어 MVP 설정에 참조하면 좋을 듯하다. 예를 들면, 2023년 기준 전국 대학생(대학원생 포함) 수가 3,100,000명 정도 되기 때문에 이들을 가상의 서비스 사용자로 설정하고 평균 접속 수를 1회(수강신청할 때에만 접속할 것이므로)로 둔 다음, 평균 TPS(위의 예시는 rps로 뒀는데, Request Per Second의 약자로 TPS와 거의 동일한 단위이다.)를 설정하면 될 것 같다.
PROJECT:
latency : 500ms
throughput
DAU : 3,100,000(명) (2020년 하루 평균 대중교통 이용자 수)
관련 기사 : https://if-blog.tistory.com/14434
평균 접속 수 : 1회 (수강신청 당일)
당일 총 접속 수 : 3,100,000회
예상 사용 시간 : 오전 9시 ~ 오전 11시(2시간)
지피티 아저씨에게 물어본 결과, 1초에 5만 건을 처리하는 것은 고도의 금융 시스템 내에서나 가능한 고수준 아키텍처 요구 프로젝트라고 하기 때문에(어...) 시작점을 1초에 500건 처리로 잡고 시작하는 것이 옳을 수도...?
어쩌면 전국 대학생이 아닌, 특정 학교의 대학생들만을 대상으로 한 서비스로 축소 기획한 다음, 이것을 전국 대학생이 공용으로 활용할 수 있는 기능 범위로써의 확장성을 고려할 수도 있을 듯하다.
그렇게 팀 회의를 거듭해서 결정된 우리의 첫 MVP 목표(3주차 기준)는...
TPS 50(특정 학과 학생 수 500명 / 평균 응답 시간 10s)의 수강신청 트래픽 처리를 수행하면서 서버가 부하를 버텨내도록 설계하기
...가 되었다.
(3) 성능 개선
MVP를 설정하는 데에 있어 성능 개선은 MVP 이후의 단계일 것으로 생각된다. 최소 달성 기능을 먼저 작성하고, 개발과 테스트를 반복하면서 수행할 부분이기 때문에 해당 단계의 관련 툴 및 개념은 차후의 포스팅에서 정리할 예정.
관련 키워드만 간략히 정리
- 서버 확장, 로드 밸런싱
- 캐싱 기능
- CDN(Content Delivery Network) 사용
- 데이터베이스 최적화(인덱스 기반, 쿼리 DSL 등등)
- 캐싱 DNS 서버
- 코드 최적화
