인프런 커뮤니티 질문&답변
작성한 질문수
Response Time (강의 외 질문)
해결된 질문
작성
·
600
2
안녕하세요 선생님!
이전 시리즈의 강의에서도 언급해주셨듯 운영환경에서 바람직한 Response Time이 있고 이에 관해 찾아보던 중
100ms 이하의 Response Time 성능을 가져야한다는 글을 보았습니다!
하지만 제가 현재 개발하고 있는 api의 Response Time은 대략 250ms ~ 350ms 정도 나옵니다(local 환경에서)
정말 단순히 로그인 유무를 체크하는 api 조차도 대략 250ms의 Response Time이 발생합니다.
인증 관련 api부분이라 조금이라도 response time을 줄이기 위해 promise.all을 사용하여 코드를 구현해보았는데 만족스럽지 않은 Response Time이 발생합니다.
전체적인 설계의 문제인지 다른 고려사항이 있는지 조언을 부탁드려도 될까요?
혹시나 봐주실 수 있으시다면 https://github.com/FITTOSS/fittoss_backend 전체 코드도 올리겠습니다!
감사합니다!
답변 2
0
선생님 질문 하나만 더 남기겠습니다.
response time을 줄이기 위해 선생님의 조언도 고려해보고 이전 강의, 이번 강의의 api를 비교해보면서 알게된 점이 있습니다.
유독 현재 제가 개발하고 있는 api만 아래의 사진에서도 알 수 있듯, Download시 많은 시간이 소비됩니다.
코드적인 차이로는 session 사용 유무고 제 생각에는 비효율적으로 코드를 구현하지는 않은 것 같다고 생각하는데 그렇다면 session 사용이 극명하게 download time에 영향을 주는 건가요?
또한 Download시 소비되는 시간을 줄이기 위해서는 어떤 것을 고려해야되는 지 알고 싶고 정확히Download time이 어떤 시간들을 의미하는지도 알고 싶습니다.
더 나아가 압축과 관련이 있는 것 같아 express-static-gzip middleware를 도입하려고 생각중인데, 다른 곳에서 터졌던 문제를 이상한 곳에서 해결해보려고 하는게 아닌지라는 의문도 드네요..
감사합니다!!
0
Dev님 안녕하세요 :)
일단 100ms 이하이면 정말 좋은거고요 ㅎㅎ 200ms 때도 충분히 좋습니다.
350ms는 좀 과한거 같긴 하네요.
일단 코드상으로 속도를 줄일 수 있는 방법은 세션 대신 JWT 토큰을 사용하는거에요. 세션 기반으로 하게 되면 요청마다 미들웨어가 session(몽고디비)를 조회하고 결과를 req에 담아서 전달하죠.
따라서 API 자체만 보면 API 호출을 한번만 한것처럼 보이지만 실제로는 한번씩 더 하게 되는거죠. 특히나 이건 Promise.all루 묶인게 아니기도 하고요. JWT를 사용하게 되면 따로 session 조회없이 secret key를 이용해서 JWT토큰이 유요한지만 확인하면 되서 추가로 드는 시간이 거의 없다고 볼 수 있어요.
그리고 다른 면에서 확인할점은 백엔드와 데이터베이스가 같은 데이터 센터(AWS region)에 있는냐에요. 같은 데이터센터이면 백엔드와 디비 사이에 통신하는 물리적 거리가 매우 짧아지기 때문에 훨씬 처리가 빠르겠죠.
같은 데이터센터일 경우 VPN을 이용하면 더 빠르게 통신이 가능할거에요. 인터넷 네트워크망을 타고 통신하는게 아니라 localhost로 접속하는것과 같이 처리가 되요.
마지막으로 백엔드, 디비 데이터센터 위치가 클라이언트에서 얼마나 가깝냐도 중요합니다. 싱가폴에 서버가 있는데 클라이언트가 한국에 있으면 아무래도 좀 더 시간이 걸리겠죠. 서버가 미국이나 유럽에 있으면 더 걸리고요.
만약 글로벌 서비스로 가고 싶다. 그래서 전세계 어디서든 빨리 처리가 됬으면 좋겠다! 그러면 좀 복잡해지는데요. 백엔드를 일단 여러 지역에 두어야 하고요. Gateway가 가까운 백엔드로 전달. 근데 디비가 서울에 다 모여 있으면 여전히 느리겠죠? 그래서 각 지역별로 디비도 두어야 하는데요. 백엔드는 stateless라서 문제 없지만 디비는 statefull하기 때문에 무작정 여러 데이터센터에 두면 안되요. 쉽게 말하면 디비는 상태를 갖고 있기 때문에 한곳에 데이터가 관리되어야 일관성이 보장되겠죠?
그러면 어떻게 하느냐 Global Replica Set을 만들 수 있어요. 쓰기는 Primary 한곳에서 처리하고 replica set을 여러개 만들어서 여러 데이터 센터에 퍼트리는거에요. 몽고디비 강의에서 배운 replica set, primary 이 용어들이 맞습니다! ㅎㅎ 강의에서 잠깐 언급을 했던거 같은데 replca set에 쓰기는 안되지만 읽기는 가능하다고 했었어요. 그래서 가까운 replica set에서 읽게 하면 됩니다! Primary는 여전히 먼 곳에 있을 가능성이 있어서 딜레이가 조금 생겨요. 근데 속도에서 민감하게 반응하는 부분은 다행이 읽기 부분이에요! 예를 들어 결제 하는건 시간이 조금 더 걸려도 괜찮은데 화면 바뀔 때마다 버벅거리면 엄청 불편하겠죠 ㅎㅎ
엇 해당 미들웨어는 없어도 되요!
지금은 아마 제일 오래 걸리는 이유가 데이터베이스(AWS)랑 백엔드(local) 사이의 통신거리일거에요.
backend(local) -> db(aws) -> backend(local) 이게 200ms 소요한다면 지금은 세션 확인 포함해서 두번 왔다갔다 하는거기 때문에 400ms가 나오게 되죠.
백엔드를 같은 AWS region으로 배포하고 테스트 해보면 backend(aws) -> db(aws) -> backend(aws) 이 부분이 매우 짧아질거에요.
같은 리전으로 디비와 백엔드를 배포하고 배포한 위치를 클라이언트와 가깝게 하면 해결될겁니다.