이 정도면 이것만 사용하겠는데요?

Question

ISR 을 보면서 SSR과 SSG의 각각의 단점을 모두 커버할 수 있는 기술이라 생각이 되었습니다.   진짜, 이 외에는 쓸 필요가 있나 싶을 정도인데요..   한가지 여쭤보고 싶은 것은, ISR 을 API 로 호출해서 한다고 했을 때 예를 들면, 어떤 게시물이 등록이 되면 그 시점에 이 API를 호출하고 그 후 해당 페이지가 재생성 될 것입니다.   그렇다면, 게시물을 동시에 여러개 작성하게 된다면 (서비스의 비즈니스 로직에 따라..) 어쩔 수 없이 이 API 엔드포인트에 트래픽이 몰리게 될 텐데 그로 인한 서버부하 는 생각 안해도 되는것이지 여쭤보고 싶습니다.

이정환 Winterlood · Answer

안녕하세요 이정환입니다. 먼저 " ISR 을 API 로 호출해서 한다" 라는 말씀을 "주문형(On-Demand) ISR을 사용한다 " 라고 이해하고 답변드리겠습니다. 혹시 정확하지 않았다면 추가 답글 부탁드립니다.   보통 서버의 부하를 고려할 때에 특정 엔드포인트의 부하는 잘 고려되지 않는걸로 알고 있습니다. 엔드포인트 별로 인스턴스를 분리해 사용하는게 아니라면 ... 딱히 고려하실 문제는 아닌것 같아요 😃 이유는 어떤 엔드포인트로 요청이 들어오든 결국 같은 서버에 요청이 발생하는 상황이라, 동일한 100개의 요청이 있을 때 A 엔드포인트에 100개의 요청이 오는 상황과 여러개의 엔드포인트에 요청이 나누어 발생하는 상황에 서버의 부하 수준이 크게 달라지지는 않을 것 같아요 😃

인프런 AI 인턴 · Answer

안녕하세요, YoungMan님. 인프런 AI 인턴입니다. ISR(Incremental Static Regeneration)은 SSG와 SSR의 장점을 결합하여 효율적으로 동작할 수 있는 렌더링 방식입니다. 특히 최신 데이터를 반영하면서도 성능을 유지할 수 있는 측면에서 많이 사용되죠. 이런 점에서 ISR이 매우 매력적이라는 의견에 공감합니다. 서버 부하와 트래픽 관리 ISR 사용 시 트래픽이 특정 API 엔드포인트에 몰리게 될 경우, 서버 부하가 발생할 수 있습니다. 특히, 동시에 많은 게시물이 등록되거나 변경되면서 revalidate API가 다수 호출되면 서버 성능에 영향을 미칠 수 있는 가능성도 배제할 수 없습니다. 이를 해결하기 위한 몇 가지 방법을 소개합니다: Rate Limiting : 요청을 일정 비율로 제한하여 서버에 과부하가 걸리지 않도록 할 수 있습니다. 이를 통해 트래픽을 효율적으로 관리할 수 있습니다. Queue System : 게시물 생성 요청을 큐 시스템에 넣어 처리 속도를 조절함으로써 서버에 가해지는 부하를 완화할 수 있습니다. 캐싱 전략 최적화 : 페이지의 캐싱 전략을 최적화하여 불필요한 서버 호출을 줄이고, 적절한 리데이터 전략을 채택할 수 있습니다. 이와 같은 방법을 통해 트래픽 관리가 가능하며, 확인된 유사한 질문과 답변을 아래의 URL에서 참조하실 수 있습니다. 관련 질문 URL On-Demand ISR 관련 질문 - rogguh님의 질문과 Winterlood님의 답변 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.