API Gateway에서 느린 요청이 다른 요청에 영향을 미칠까요?

API 게이트웨이 분야에서 자주 논의되는 문제 중 하나는 많은 수의 동시 요청을 효율적으로 처리할 수 있는 능력입니다. 특히, **느린 요청이 API 게이트웨이에서 다른 정상 요청의 응답 시간을 크게 증가시킬까요?**라는 질문이 제기됩니다.

이에 대한 답변은 APISIX가 이 부분에서 뛰어나다는 것입니다. 느린 요청이 다른 정상 요청에 부정적인 영향을 미치지 않음을 보여줍니다. 그러나 다른 언어와 소프트웨어 아키텍처를 기반으로 한 API 게이트웨이 제품의 경우 성능이 그렇게 좋지 않을 수 있습니다.

다양한 프로그래밍 언어는 동시성 소프트웨어 아키텍처에 대해 다양한 정도의 친화도를 보입니다. 단일 프로세서 시스템을 위해 설계된 C와 Fortran과 같은 초기 프로그래밍 언어는 동시성에 대한 지원이 제한적입니다. 그러나 멀티프로세서 및 멀티스레딩 환경의 등장으로, Java와 Python과 같은 새로운 언어들은 더 강력한 동시성 및 병렬 처리 기능을 포함하게 되었습니다. Go와 같은 언어는 동시성을 염두에 두고 설계되었으며, 동시성 모델을 언어 기능과 긴밀하게 통합했습니다. 프로그래밍 언어의 동시성 지원은 그 언어가 탄생한 기술 환경을 반영할 뿐만 아니라, 그 언어가 목표로 하는 응용 시나리오를 예측할 수 있게 합니다.

수천 개의 동시 요청이 있다고 가정할 때, 멀티스레딩 또는 멀티프로세싱 아키텍처(Java 또는 Python에서 볼 수 있는)를 사용하면 요청 컨텍스트를 관리하기 위해 수천 개의 스레드 또는 프로세스를 할당해야 합니다. 컴퓨터 프로그래밍에 익숙한 사람들은 대부분의 스레드가 유휴 상태일지라도, 운영 체제가 수천 개의 스레드 또는 프로세스를 유지하는 데 하드웨어 리소스 소비가 발생한다는 것을 이해합니다. 그러나 코루틴(APISIX와 Golang에서 사용하는)을 사용하면 동시 요청이 급증하더라도 추가 스레드나 프로세스가 필요하지 않습니다.

코루틴, 스레드, 프로세스는 모두 멀티태스킹을 위한 접근 방식이지만 주요 차이점이 있습니다:

1. 스케줄링 메커니즘: 스레드/프로세스 스케줄링은 선점형이며 운영 체제(OS)에 의해 관리됩니다. 즉, OS가 언제 중단하고 다른 스레드나 프로세스로 전환할지 결정합니다. 반면, 코루틴 스케줄링은 협력적이며 프로그래머나 언어 라이브러리에 의해 명시적으로 구동됩니다. 코루틴은 다른 코루틴으로 전환하기 위해 명시적으로 제어를 양보해야 합니다.

2. 오버헤드: 스레드/프로세스는 운영 체제 수준에서 작동하므로 생성, 전환, 종료에 더 많은 리소스가 필요합니다. 반면, 코루틴은 사용자 공간에서 작동하므로 생성, 전환, 종료에 상대적으로 낮은 오버헤드가 발생합니다.

3. 데이터 공유 및 동기화: 스레드/프로세스 간 데이터 공유는 데이터 경쟁 조건을 방지하기 위해 뮤텍스 잠금, 읽기-쓰기 잠금, 세마포어 등과 같은 복잡한 동기화 작업이 필요합니다. 코루틴은 동일한 스레드 내에 있으므로 복잡한 동기화 없이도 전역 변수를 직접 공유할 수 있습니다.

APISIX의 세계에서 느린 요청은 단순히 업스트림 응답을 기다리는 과정이며, 이는 네트워크 이벤트를 수신하는 데 제한되며 추가 시스템 리소스 오버헤드가 발생하지 않습니다. 결론적으로, APISIX는 특정 요청의 응답 시간이 길어져도 다른 정상 요청의 응답 시간을 저하시키지 않습니다.