[%] 병렬로 API 요청 날릴 때, 하나 삑날경우 어케처리함?

[익명(114.203)]

5개정도ㄹㅡㄹ 한번에 요청하고싶은데 병렬로 날리고싶음.

근데 하나 삑나면 ㅊㅓㅁ부터 다시하기 부담스러울것같은데

보통 어떻게처리함?? 그냥 직렬로하는건 너무느릴것같은데

[익명(211.178)]

삑 난 것만 다시 보내게 못함?

[익명(114.203)]

그렇게 할 순 있는데, 보통은 어케하는지 궁금해서..

[익명(114.203)]

근데 보통 묶어서 보내면 한개 한개 요청처리를 컨트롤하는게 힘들긴하지..

[익명(114.203)]

보통 현업에서는 저렇게 5개의 api를 한번에 요청받아야하는경우 어케함? 1. 백앤드에서 그냥 알아서해주고 프론트는 결과를 받기만 한다. 2. 프론트에서 retry횟수 정해주고 5개를 받도록함. 3. 그냥 직렬로 쏨.

[익명(220.118)]

실패하면 알아서 재시도 하게 만들면 되지 않음?

[익명(114.203)]

근데 만약에 5개의 api중에서 한개의 서버가 종료되었다고 가정하면, 재시도 해도 의미없지않음?

[익명(114.203)]

실제로 백 서버에서는 서버가 일시적으로 죽는 경우가 있다해서..

[익명(114.203)]

보통 현업에서는 저렇게 5개의 api를 한번에 요청받아야하는경우 어케함? 1. 백앤드에서 그냥 알아서해주고 프론트는 결과를 받기만 한다. 2. 프론트에서 retry횟수 정해주고 5개를 받도록함. 3. 그냥 직렬로 쏨.

[익명(220.118)]

그런 경우면 의미없는게 맞긴하지 요청 보내는데 비용이 크다면 어따 저장하긴 할듯?

[익명(220.118)]

나 있는곳은 백 프론트 팀이 나뉘어 있으니 서로 의논해서 뭐가 나은지 선택할듯

[익명(114.203)]

흠.. 1. 서버쪽에서 잘 안죽거나 빠르게 회복되는것을 기준으로 병렬/직렬을 정한다. 2. 프론트쪽에서는 잘 변하지 않는 데이터들은 캐싱해둔다. 3. Retry횟수등을 적절하게 정한다. ... 뭐 여러가지방법이있는건가.. 어렵네

[익명(211.178)]

꼭 5개 요청을 병렬로 보내야 하는 거임? 괜히 하나 제대로 안 날아와서 또 요청 보내면 미리 받아 놓은 애들이 outdated되거나 그런 문제 생길 수도 있을텐데

[익명(114.203)]

오호 그런 문제가 있을 수 있겠네. 나는 퍼포먼스때문에 병렬을 생각한거임.

[익명(114.203)]

데이터가 outdated등에는 크게 문제가 없는 데이터들이라 상관안했던것같아.

[익명(114.203)]

그리고 내가 썼던 라이브러리는 한개 실패하면 전부다 새로받아오기 때문에 outdated문제는 없을것같아..

[익명(59.25)]

apache kafka

[익명(59.25)]

를 비롯한 메시징 시스템의 필요성

[익명(114.203)]

메시징 시스템이 저기서 해주는 역할이 뭔디?

[익명(59.13)]

Event driven programming

[야딩조무사(cir6174)]

웹 프론트 개발 말하는거면 allSettled로 실패한 요청만 골라서 처리하면댐 근데 실제론 비동기 태스트를 감싸서 아예 에러가 없게 한다음 Promise.all로 묶지 - dc App

[익명(114.203)]

allSettled라는 존재를 몰랐네. 오우 그런거 쓰면되겠다

[야딩조무사(cir6174)]

그리고 API 콜처럼 한 번의 요청에 하나의 응답이 오는 상황에 이벤트 드리븐 쓰는거 뇌절임 코드가 한 흐름으로 안나와서 번거로움 - dc App

[익명(114.203)]

근데 Promise같은것도 결국 이벤트드리븐 프로그래밍아닌가..?

[익명(114.203)]

그러니까 Promise.all 쓰지말고, 그냥 각각 비동기요청받아라 이말인가?

[야딩조무사(cir6174)]

핸들러 왔다갔다 하면 번거롭다는거임 프로미스는 await으로 연결할 수 있어서 쉽다는 얘기 - dc App

[익명(114.203)]

핸들러 왔다갔다라는 말이 이해가안되네.. 블락킹 해서라도 컨트롤 쉽게하라는 소리인가

[익명(114.203)]

블락킹 하지말고 속도를 빠르게 하고싶은게 내 목적인디

[익명(114.203)]

await으로 했더니 순차적으로 보내서 속도가 너무 느리다 => Promise.all이든 뭐든 병렬적으로 처리할 수 있는 솔루션=> 한번에 wrapping하다보니, 각각 처리하는게 너무 어렵다 => allSettled의 존재를 알게됨. 현재 여기까지가 내가 팔로우업한 단계

[익명(114.203)]

근데 근본적으로 서버가 죽는경우는 retry()같은 솔루션이 안먹힐 수 있어서, 이런경우 백앤드쪽에서 메세징 기술을 활용한다? 라고 이해한것같은데.. 잘몰겠다..

[야딩조무사(cir6174)]

js 말하는거면 await 걸어도 블록되지 않음 코드가 순차적으로 보일 뿐임 - dc App

[익명(114.203)]

헉..지금까지잘못알았누..

[야딩조무사(cir6174)]

동시에 보내는건 await을 안걸면 되는거고 allSettled은 그냥 동기화를 위한거임 될때까지 몇번 살행하거나 이런건 그냥 원래 요청을 래핑해서 처리하면됨 allSettled는 모든게 실패하거나 성공할때까지 기다리는게 전부임 - dc App

[익명(114.203)]

근데 코드가 순차적으로 실행되는거나 블락해서 다음넘어갈때까지 대기한다는거나 같은말아님?

[야딩조무사(cir6174)]

그리고 클라에서 서버의 구현을 알아야하는 설계면 대부분 좋지않은 설계고 이벤트 드리븐으로 돌아야하는거랑 요청은 있는데 응답은 필요없는 경우(204)를 구분해야함 - dc App

[야딩조무사(cir6174)]

js 이벤트 루프로 알아보셈 await 건다고 메인스레드가 블락되고 그러지 않음 - dc App

[야딩조무사(cir6174)]

코드만 보면 블로킹처럼 생기긴 함 님리 말한게 코드의 모양세만 뜻한거면 틀린말은 아님 - dc App

[익명(114.203)]

말을 정리하자면 await으로 여러줄 날린거는 Promise + then을 여러개로 날린거랑 다르지 않다는 소리네?

[익명(114.203)]

(요청부분에 있어서는)

[야딩조무사(cir6174)]

ㅇㅇ 완전히 동등한 동작임 - dc App

[익명(114.203)]

다만 response가 올때까지 대기타고있는건 맞는거고

[야딩조무사(cir6174)]

await을 여러번 하는건 순차적으로 가고 Promise+then을 여러개 한다는게 then 체인이 여러개면 같은말인데 진짜 말 그대로 Promise.then() Promise.then() 이렇게 여러개 있는거면 다름 후자인 경우에는 동시에 돌음

[야딩조무사(cir6174)]

all이나 allSettled는 빠르게 돌리는거랑은 상관없고 결과가 전부 끝난걸 동기화 하는거인거고

[익명(114.203)]

Promise+then / Promise + then = Promise.all Promise.then.then.then = await

[야딩조무사(cir6174)]

Promise.all은 있건없건 상관없음 동시성에서 말하는 배리어의 역할임

[익명(114.203)]

만약 이거라면 현재 내가 하고싶은거는 전자임. Promise.all같이 병렬적으로 처리하고 싶은거고, 그러면 Response 받는 비교적 속도를 빠르게할 수 있으니까..

[익명(114.203)]

근데 "핸들러 왔다갔다 하면 번거롭다는거임 프로미스는 await으로 연결할 수 있어서 쉽다는 얘기" 라고말해서 await으로 내가말한 경우를 해결하는것으로 생각했음.

[익명(114.203)]

근본적인 질문은 만약 저런 상황이 있다면, 보통 현업에서는 어떻게 처리하는게 best pratice인지 궁금함. 그냥 프론트는 백앤드가 추상화해준 한개의 api를 통해 받는것이 좋은지?

[야딩조무사(cir6174)]

프론트에서 서버 안이 어떻게 생겼는지 알고 동작하면 별로 좋은 설계가 아님

[야딩조무사(cir6174)]

추상화된 하나의 api로 받는거고 클라이언트에서는 이게 성공했는지 실패했는지만 처리하셈 안에서 실패를 메시징 했다가 처리하고 이런건 서버의 역할

[익명(114.203)]

그렇구만.. 실제 플젝하다가 그런 경우가 있는경우 보통 Promise.all을 날려서 처리했었는데, 백앤드가 알아서 잘 처리해서 요청/응답 받도록 해줘야 했던거네..

[익명(114.203)]

그럼 백앤드에서 그런 역할을 해주는게 메세징서버 라는게 맞음? 그 키워드로 찾아보려고하는데 빅데이터랑 연관되어있어서 확신이안드네

[야딩조무사(cir6174)]

신경써야 하는거면 서버에 뭐 생성하는 동작인데 이게 응답은 안왔는데 실패했는지 성공했는지 애매할때 이런게 있는데 이것도 REST 잘 지키면 멱등성으로 커버돼서 다시 요청만 보내면 되는 경우가 많음 대부분의 경우에 생성동작만 좀 조심하면됨

[야딩조무사(cir6174)]

메시징은 용도가 너무 다양해서 머라 하나 짚기가 그런데

[야딩조무사(cir6174)]

클라에서 실패한거면 실패한것만 알면 됨

[야딩조무사(cir6174)]

저거 딸랑 검색하면 카프카 이런거 나오면서 빅데이터 자료만 나올텐데 검색어에 아키텍처 키워드 넣으면 님이 원하는거 나올거임

[익명(114.203)]

답변 고마워~! 공부해볼게요

[익명(114.203)]

방금 공부하다가 N+1문제에 대해서 알게되었는데 클라이언트가 백앤드의 호출을 최소화 한다는 입장에서 N+1문제랑 내가 제시한 문제랑 비슷한 맥락인건가요?

[야딩조무사(cir6174)]

그건 조인을 잘못해서 생기는 문제고 별개임 - dc App

[익명(114.203)]

"In the case of web APIs, the N+1 problem is a situation where client applications are required to call the server N+1 times to fetch one collection resource + N client resources, mostly because of collection resources not had enough information about child resources to build its user interface altogether."

[익명(114.203)]

https://restfulapi.net/rest-api-n-1-problem/
orm
쪽 뿐만 아니라 rest api쪽에서도 쓰는것같은데 헷갈린다 @.@

[익명(114.203)]

rest api의 n+1의 경우, 클라이언트에서 서버쪽 리소스를 다 따로따로 요청해야되는 경우를 의미하는것같은데

[익명(114.203)]

일반적인 orm에서의 n+1의 의미랑은 다른의미일 수 있겠군요.. orm도 공부해야겠네..

[야딩조무사(cir6174)]

요청을 하고 관계된 데이터를 sql을 날리건 프론트에서 요청하건 조인을 미리 안해서 N번 더 가져오는거임 sql http 구분하는 의미가 없음 - dc App

[야딩조무사(cir6174)]

같은의미 맞음 - dc App

[익명(114.203)]

아하!

[익명(114.203)]

그럼 백앤드에서 리소스들을 따로따로 분리해서 인터페이스를 제공해서 클라이언트가 따로따로 요청을 해야되는 경우라면 N+1 문제에 해당되는 경우 아닌가요? 이게 맞다면, 제가 위에 작성한 문제와 동일한 선상에 있다고 생각합니다.

[익명(114.203)]

저의 경우에도 백앤드가 리소스마다 통신할 수 있는 api를 만들어둬서 그것들을 프론트쪽에서 다 합치해줘야했었거든요

[익명(114.203)]

현재 보고있는 N+1자료에는 클라이언트 부분에서 블로그의 id를 가져와서 (1) comment등의 리소스를 조회하는데 (N) 번의 요청을 해야한다고 해서 N+1이라고 명명하는것같네요.

[야딩조무사(cir6174)]

a 한개에 b 여러개 달린 구조에서 a에 있는 정보로 b를 여러번 요청하는게 n + 1이고 조인걸기 싫으면 여러개의 b를 주는 api를 뚫고 파라미터로 a의 id 넘기고 이런식으로 하면 됨 /b?a=id 이런식으로 - dc App

[익명(114.203)]

제 상황도 클라이언트 유저 id 한개에 여러개의 api등을 요청해야하는 상황인데, 그럼 N+1문제라고 할 수 없는건가요?? "그건 조인을 잘못해서 생기는 문제고 별개임 " 이라고 해서 제가 제시한 상황이랑 어떤게 다른지 궁금합니다.

[야딩조무사(cir6174)]

여러 종류의 api를 호출하는걸 말하는거면 아니고 한 자원에 관계된 자원 한 종류를 가져오기 위해 여러번 호출해야하는거면 맞음 - dc App

[익명(114.203)]

아 그런 컨텍스트의 차이가 있군요.. 위키처럼 계속 질문하고 답변내놔라고 한것같아서 죄송합뉘당.. 이쪽분야는 쌩초짜라 돌다리를 두드려보고있는데 잘 감이안잡히네요 ㅎ;;

[야딩조무사(cir6174)]

글에 댓글이 10개 있는데 글 api 한번 댓글 api 열번 이런게 n+1인거고 다양한 정보를 가져오는건 다른거임 - dc App

[익명(114.203)]

그럼 그런경우를 명명하는 문제는 없나요?

[야딩조무사(cir6174)]

다양하게 호출하는건 별문제 없음 graphql같은 접근법도 있는데 이건 요청 한번으로 다가져올수있음 - dc App

[익명(114.203)]

제가 보기엔 유저 id한개에 덧글 가져오는행위나, 유저 id한개에 여러 관련 리소스를 합치해서 가져오는거랑 똑같은데 왜 N+1이라 명명하지 않는지 궁금.... 키워드라도 던져주시면 함찾아보겠습니다..

[익명(114.203)]

그래서 graphql같은걸 쓸수도있겠군요.. 호오

[야딩조무사(cir6174)]

자원에 대한 타입이 다양한건 많아봐야 그 타입 갯수만큼 요청가면 끝인데 N+1은 중첩이 될수도 있어서 위험한거임 유저가 쓴 모든 글에 대한 댓글 이런거면 요청만 N*M번 해야함 - dc App

[익명(114.203)]

답변을 들을수록 점점 이해가 가는 동시에 제가 N+1에 대해서 제대로 공부안하고 질문한 느낌이 드네요. 일단 N+1 관련 문서부터 강독해보고오겠습니다. 답변감사합니다!!!