대규모 트래픽을 위한 백엔드 설계 꿀팁

1. 개발자들이 말하는 대규모 트래픽 경험은 뭔가요?

안녕하세요. 이번에 백엔드 개발자로 취준을 하고 있는 학생입니다. 문득 면접 정리를 하다보니 "대규모 트래픽을 경험해보고 싶습니다"라고 말한 것이 사람마다 느끼는 점이 다를 수 있겠다 라고 생각이 되더라구요. 저는 저 표현을 썼을때 1000만명이 써도 서비스가 안 죽고 요청을 잘 처리하는 서버 운영 방법을 알고 싶다라는 의미에서 썼는데요. 생각해보니 대규모 트래픽이 몰려서 서버가 죽는 경우는 일상에서 그렇게 흔하지 않을 수도 있다고 생각이 되었습니다. 혹시 선배님들은 위와 같은 말은 하면 어떤 것을 경험해보고 싶다인지 구체적인 사례를 알려주실 수 있나요? 예를 들면 대규모 트래픽이란 어느정도고 서버가 트래픽 때문에 죽는 경우가 실제로 흔한 사례인지도 궁금합니다. 감사합니다.

답변

안녕하세요! 이미 좋은 답변이 많아서 저는 공부하시면서 참고하면 좋을 것 같은 사이트만 링크 걸겠습니다 :) - http://highscalability.com/start-here/ - https://alexpareto.com/scalability/systems/2020/02/03/scaling-100k.html - https://leonkim.dev/systems/scaling-100k/ (위 링크 번역본) - https://shdkej.com/100k_concurrent_server/

2. 아키텍처 설계 시 트래픽 규모는 어떻게 예측하나요?

안녕하세요. 토이 프로젝트를 진행 중인 학생입니다! 궁금한게 있어서 말씀을 듣고자합니다! 아키텍처 설계에서 결정요인 도출시, 비기능요구사항에 해당하는 "서비스 제공 기간에 원활한 진행"이 무엇을 의미하는 것인지 모호해 다음과 같은 질문을 남깁니다. 현재 소프트웨어 아키텍처를 설계하면서 트래픽에 관련해서 요구사항을 설정해보려고 합니다. 혹시 트래픽 처리능력을 초기에 어느정도로 잡아야할까요? 알아보니 초당, 분당, 시간당, 그리고 인원 설정도 다 다른 것 같은데 이런 초기사항을 어떻게 잡아야할지 감이 오지 않습니다 답변 부탁드리겠습니다 감사합니다! 행복한 하루 되세요~☺️

답변

비즈니스적인 관점에서 우리의 서비스를 이용할 잠재 고객의 수 그리고 거기에 현실적으로 그중에 몇명이나 우리의 서비스를 이용할지를 생각해보시면 되겠습니다. 예를들어 잠재 고객이 대한민국의 모든 국민이라면 대략 5천만의 이용자가 있는것이고 그중에 현실적으로 우리 서비스를 이용할 고객은 인구의 5% 정도 일 것으로 예상한다면 이용인원은 250만명일것이고 평균적으로 서비스를 이용하는 시간이 어느정도인지 대상고객 한명당 저장해야할 데이터는 얼만큼인지. 그리고 주로 이용하는 기능은 어떤것이고 서비스의 피크타임에 최대 몇명까지 동시접속이 예상되는지 등등을 생각하여 트래픽 요구사항을 대략적으로 계산하시면 될 것 같습니다. 최대트래픽은 개발자 스스로 혼자 판단하기 어려운 부분이기때문에 유연하게 결정하시되 개발자로서 하셔야 될 일은 사용자수가 늘거나 줄었을때 혹은 주로 이용하는 기능이 바뀌거나 이용시간이 바뀌었을경우 손쉽게 시스템 성능의 요구치를 다시 계산할 수 있도록 만들어 놓는것이 중요할 것 같습니다.

3. 트래픽 성능 지표를 이해하는 방법

제목 그대로 입니다. 사수님이 서버에 부하 테스트, 스트레스 테스트 하면서 서버가 언제 죽는지? 기록하라는 숙제를 내주셨는데요. 어떤 것들을 성능 지표로 놓고 봐야할지 모르겠습니다. 사수님은 추상적으로 "대충 사용자가 느낄만한 응답속도가 어느정도 되는지랑 동시 요청 몇개 쯤에서 뻗는지 알아봐주세요~" 라고 하셨는데 이게 단순히 초당 요청수 처리와 지연율만 보면 되는건가요? 처음해보는거라서 질문 남깁니다. 감사합니다. 사용하는 프로그램은 Jmeter 입니다.

답변

안녕하세요! 음, 애매모호한 작업이네요. 서버가 어떻게 구성되어있고, 어떤 기능들이 있으며, 어떻게 통신하는지 모르는 상황에서 알맞는 답변을 드리기 어려운것 같습니다. 사수님에게 직접 어떤 지표를 원하시는지 여쭤보는것도 좋은 방법인것 같아요. 통상적으로 TPS (초당 트랜잭션 수), RPS (초당 요청수) 와 같은 지표와 latency (지연 시간)을 보는 것 같아요. 보는 구간도 상황에 따라 다르고 보통 백분위수로 개선하고 싶은 영역을 파악하는 것 같아요. Jmeter로 트래픽 처리 후 결과를 확인하는 방법은 공식문서와 여러 블로그들에 잘 정리되어 있습니다. - https://octoperf.com/blog/2017/10/19/how-to-analyze-jmeter-results/#installation - https://creampuffy.tistory.com/209 - https://jmeter.apache.org/usermanual/get-started.html - https://effortguy.tistory.com/164 그치만, 전체적인 시스템에 따라 지표가 다 다르게 나올 수 있어서 어느정도 규모로 테스트를 집행해야하는지 알지 못하면 힘든 작업이 되실수도 있을것 같아요 :) 참고하시면 좋을법한 링크들 첨부할게요 - https://hyuntaeknote.tistory.com/10 - https://choibulldog.tistory.com/61 - https://blog.bramp.net/post/2018/01/16/measuring-percentile-latency/ - https://bcho.tistory.com/787

4. 서버 설계 어떻게 해야 하나요? 너무너무 궁금하고 급합니다.

부끄럽지만 서버 설계를 바꿔야 할 시기가 와서 선배님들께 여쭈어봅니다. 지금 aws에서 ec2 1대를 이용해서 서비스를 이용하고 있습니다. 당연 오픈한지 얼마 안 돼서 고객 유입도 적어 문제가 안됐는데 마케팅 이후 300명이 되면서 서버를 다시 작업해야 할 시기가 된 거 같아 아무리 찾아도 무얼 봐야 하는지 몰라서 여쭈어봅니다. 추가 마케팅 이후 예상 고객이 천명이 이상의 접속자가 생길 예정입니다. 프론트 : react 백엔드 : node.js DB : RDS (db.t3.micro) PC : aws EC2 1대 (t2.medium) 배포 : 젠킨스 git - 회원가입 - 상품1,상품2,고객 리스트 페이지 - 회원 정보 페이지 - 채팅(+결제) - 관리자 - 이미지 저장 이렇게 크게 나누어져 있습니다. 이런 작업이 회바회고 케바케이다 보니 어떻게 해야 할지 맞는것이 뭔지 못 찾고 있습니다. 프론트는 8080포트에서 서버를 3000 포트에서 돌리고 있습니다. 1. 컴퓨터 댓수를 늘린다. 가 서버를 분산해서 개발하는걸 말하는 걸까요? 2. 아니면 큰 PC 라지 이상의 PC를 구매하면 문제가 없는 걸까요? 부끄럽지만 이미지도 한번 추가해서 올려봅니다. ㅠㅠ

답변

관련 작업을 많이 해보지는 않아서 많은 도움을 드릴수는 없지만, 비슷한 작업을 해본 경험을 바탕으로 방향성 정도만 남겨 드릴게요. 먼저 성능 문제에대한 측정 & 분석을 먼저 해보는걸 추천드려요. 어떤 API 혹은 Query 가 오래걸리는지 그리고 각각의 문제를 어느정도의 리소스로 어디까지 개선 가능한지를 먼저 분석해 보는게 좋아요. 아키텍쳐를 변경하는 작업은 큰 작업이기 때문에 무턱대고 적용하기 보다는 현재 상황에서 들어가는 리소스 대비 가장 큰 효과를 얻을 수 있는 작업을 먼저하는게 더 좋아요. (80 대 20 규칙을 찾아봐 주세요.) 문제를 분석하기 위해서 보통 실행시간 (API, Query) 를 분석하고, 분석을 위한 툴은 다양하게 있으니 현재 상황에 맞는 툴을 찾아서 사용해주세요. 많이 사용해본게 아니라서 ‘이런 툴이 좋다’ 라는 추천을 해주기가 어렵네요. 개인적으로 경험한 부하가 많이 발생하는 상황을 공유드리면 - DB 의 Write 혹은 Transaction 로직이 오래걸리는 상황 - DB 의 Read Query 에서 Index 가 없거나 잘못 적용된 상황 - DB 의 Read Query 에서 Join 이 효율적으로 되지 못하는 상황 - (ORM 을 사용한다면) 특정 로직의 Query 가 효율적으로 동작하는 상황 - 호용된 DB Connection Pool 을 초과하는 접속이 발생하는 상황 이렇게 DB 와 관련된 문제가 자주 발생합니다. API, Query 최적화 이후에 간단하게 적용 가능한 아키텍쳐는 Event Driven 아키텍쳐 인듯 합니다. 실시간으로 처리할 필요가 없는 작업들을 Queue 에 저장해서 Worker 에서 따로 돌리는 방식으로 서버의 부하를 크게 줄일 수 있어요. 이 방법도 마찬가지로 성능 문제를 파악해보고 어느정되의 효과를 얻을 수 있는지 파악하고 도입해보는걸 추천드려요.

5. 서버 트래픽 테스트 방법이 궁금합니다

안녕하세요~~ 서버 개발에 대해 공부하다가 궁금한 것이 생겨서 질문 남깁니다. 현업에서 서버가 트래픽을 감당할 수 있는지 테스트를 하시나요? 하신다면 언제 어느 시점에 어디에 하는게 좋은건지 궁금합니다. Jmeter나 artillery 등에 대해서 알고있고 써본적도 있지만, 특정 상황이 닥쳤을때만 써봐서 실제로 현업에서는 이걸 어느 서버에 어느 시점에 트래픽 부하 테스트를 하는지 문득 궁금하더라구요. 예를 들면, - 배포 파이프라인 스크립트에서 테스트를 해보고 배포를 하는건지 (자동화를 하는건지) - 프로덕션에서도 돌려보는건지, 아니면 개발 서버나 스테이징 서버에서만 돌려보는건지 - 모든 서비스에 대해서 하는건지, 아니면 게이트웨이 성격의 서버에만 하는건지 등이 궁금합니다 ㅎㅎ 최근에 서버 개발에 대해서 공부하다보니 다른 곳들은 트래픽 테스트를 하는지, 한다면 어떻게 하고 있는지 궁금하네요. 긴 글 읽어주셔서 감사합니다.

답변

안녕하세요! 정답은 없지만 회사 바이 회사, 팀 바이 팀인것 같습니다. 개인적으로 배포 파이프라인에 넣지는 않았고 필요할때 구동해서 테스트했었어요. 프로덕션은 유저가 안몰리는 시간대에 테스트 해본 기억이 있네요. 서버는 문제가 될 것 같은 서버에 우선적으로 돌려보고, 이후 중앙 집중형 컨트롤러 (게이트웨이) 성격의 서버에서 돌려본 것 같아요. 케바케지만, 서버가 감당할 수 있는 트래픽 성능을 주기적으로 테스트해야한다면 충분히 자동화 해볼 수 있다고 생각됩니다. 별개로 배포되는 서버의 성능이 어느정도인지, 서버가 트래픽을 어느정도 받으면 힘들어하는지 잘 알고 있는거는 좋은 것 같아요. 물론 예상하기 힘든 경우도 있어서 어렵지만요. 그리고 단순히 서버만 테스트하는건 아니고 메세지 큐나, 캐시 서버등 시스템 전체적으로 테스트 하는 경우도 많은 것 같아요. 결론은 케바케인 것 같습니다 ㅎㅎ 참고하시면 좋을것 같은 글 첨부할게요! - https://techblog.woowahan.com/2627/ - https://bcho.tistory.com/787