msa에서 특정 지점에서 장애가 발생했을 때,
해당 지점과 연결된 블로킹 서버들은 타임아웃 전에 스레드가 전부 점유돼서 장애 발생하고 그 앞에 서버도 블로킹이면 장애 전파되고 (무한반복)
논블로킹 서버들은 작업이 쌓이긴 해도 스레드가 점유되는건 아니라서 해당 지점과 연결되는 요청들만 타임아웃 발생하고 다른 요청들은 정상 서빙 가능
이희승님 말고 저런 이야기 하는 사람 한명도 못봤네
다들 성능만 이야기하는데, 사실 성능은 그정도로 요구되는 경우가 매우 드물고 서버를 늘려서 해결할 수 있음
그리고 기본적인 성능 차이가 의외로 많이 안남
많이 나려면 io 지연이 길어야하는데, io 지연 길면 애초에 정상적인 서비스가 불가능한 상황임
io 지연 없어도 요청이 몰리면 성능 차이가 나기 시작하는데, 이런 경우는 위에서 말했듯이 서버 늘리면 됨
그런 의미에서 msa에서는 spring mvc보다 spring webflux가 더 좋은데
webflux 이놈이 쓰기가 매우 잣같다 이거지
서비스들이 거미줄처럼 연결되는 진정한 msa에서 왜 node 쓰는지 더더욱 이해가 간다
물론 한국 좃밥들의 msa호소인들에겐 해당사항 없음
오 근데 맞말같음
글 수정함
근데 webflux써도 rds 엑세스 필요한 경우 결국엔 jdbc가 블로킹해서 좀 의미가 퇴색된다고 하던데 노드는 rds 엑세스 할 때 그런 문제 없음?
위의 내용이랑은 무관하지만 ㅇㅅㅇ;;
webflux 쓸거면 jdbc 쓰면 안되지 mongodb 쓰든가 해야지 노드는 mariadb, postgresql 드라이버가 논블로킹임
알겠지만 r2dbc는 아직 정식 출시가 안돼서 못쓰고
오 ㄱㅅㄱㅅ... 그나저나 노드 좋네...
물론 노드도 단점은 있지 생태계가 병신임ㅋㅋㅋ
msa가 필요할정도의 회사면 생태계 부족해도 자력갱생 가능할테니 문제 없으려나? 한국에는 그런 회사 없다고 생각함
이게 맞다. 논블로킹으로 성능체감 하려면 네카라쿠배 API 게이트웨이 트래픽 수준은 되어야 함. 일반적인 상황에선 오히려 코드 복잡도만 존나 높아지는 참사가 벌어짐. 어떻게 아냐고? mvc에서 webflux로 전환해봄 ㅅㅂ
api 게이트웨이야말로 여러가지 서비스와 엮이기 때문에 무조건 논블로킹으로 처리해야지 성능보다도 장애 전파가 더 큰 이유라고 생각함
그런면에선 일정 수준의 트래픽이 유입되는 환경일 경우 장애전파를 막기 위해서라도 논블로킹이 유리하다고 볼 수 있겠구만! 확실히 요청단의 리소스 과다 점유 문제는 생각해볼만한 문제인것 같음
특정 백단 서비스의 응답속도가 느려서 api 게이트웨이 전체 처리량이 급감하는 경우도 장애 전파와 같은 맥락이라서 그렇게 표현해봤음 ㅇ,ㅇ 백단 서비스가 항상 모두 빠른게 보장되면 api 게이트웨이가 블로킹으로 동작해도 문제 없지 서버만 늘리면 되니까
그래도 하나 배웠다. 연동 흐름 사이에서 나도 모르게 장애를 낳을 수 있다는 점은 생각 못했거든. 어쨌든 논블로킹도 능사는 아니기에 여러 조건들을 비교해서 적절한 기술 스택을 선택하는게 가장 중요한 개발자의 덕목이라고 생각함 스케일아웃으로 단순히 해결 가능하다면 (DB 자원이 널널하다면야..) 베스트지만 요즘 추세가 큰 회사들도 운영비용 절감하는지라..
db는 샤딩하면 됨 비즈니스 로직 수행하는 서버들을 서버 비용 줄인다고 전부 다 webflux로 전환하면 운영 자체가 안될걸 개발 난이도랑 트러블슈팅 난이도가 너무 차이나서
와 이거 개맞말이네
기본 성능 차이는 레이턴시 수준에서 웹 프레임워크 수준에선 차이가 작고, 사실상 node의 장점은 프론트랑 같은 언어라는 점인데 논블로킹으로 인해 장애가 전파 안되는건 무릎을 탁치네
이걸 노드 개발자라는 놈들이 주장 안하고 내가 말하는게 어이가 없음
이희승이 꽤 좋은 포인트를 지적한 것으로 보이지만, api 서버가 논블로킹이라도 디비든 다른 서비스든 커넥션 리밋이 있고, 연결지연 촤소화를 위해 커넥션 풀링을 사용함. 따라서 서비스 지연 발생시, 플갯수에 의해 블로캉효과가 나타나기 시작함, 풀링 없이 사용하는 경우 커넥션리밋에러가 뜨면서 모조리 에러발생함. 따라서 이 장점은
매우 특수한 경우를 외에는 생각보다 크지 않을 것, 기다가 블로킹서버들의 경우도 쓰리드 설정 자체를 이미 연계 비디나 서비스의 커넥셔느리밋을 고련해서 최적화 하기 때문에 동일 장애ㅡ상황에서 블로킹 서버들이 크게 단점을 가질까 싶다.
어쨌든 전체적으로 비동기 서버가 나을 가능성이 높다는 인사이트는 인정, 파이.선 asgi 진영도 이 점을 밀면 pep 으로 승격될지도.
글을 잘 이해하지 못한 것 같은데, 커넥션풀로 인한 대기가 길어질수록 블로킹 서버는 더 불리하다 왜냐면 블로킹 서버는 대기가 곧 스레드 점유거든
보통 쓰레드가 점유된 원인은 1.외부 디비같은 시스템의 장애 2.롱런이 필요한 요청 이겠지. 1번이 원인이라면 비동기라고 해도 딱히 나은 것이 없음. 2번이 원인인데, IO 바운드는 확실히 비동기가 우월함, 그러나 CPU 바운드라면 쓰레드가 우월함. 따라서 논블로킹이 언제나 우월하냐고 하면 딱히 말하기 쉽지 않다는 거지.
여전히 글을 잘 이해하지 못한 것 같은데, 디비 같은 단일 백단에만 접근하는 서버면 논블로킹에 특장점이 없다고 본문 글에 써져있다