C10K 문제는 2000년대 초 서버 아키텍처가 10,000개의 동시 연결을 효율적으로 처리하는데 도전했습니다. 전통적인 연결당 스레드 모델은 컨텍스트 스위치로 인해 메모리와 CPU를 소진했습니다. Go의 제작자는 수백만 개의 고루틴을 지원하면서 차단되는 I/O 코드의 명확성을 유지하도록 목표로 했으며, 이는 고루틴 대기 상태를 OS 스레드 소비로부터 분리하는 메커니즘이 필요하다는 것을 의미했습니다.
고루틴이 네트워크 소켓에서 read()와 같은 차단 시스템 호출을 실행할 때, 기본 OS 스레드 (M)을 고정할 위험이 있습니다. 개입이 없으면 수천 개의 동시 연결이 수천 개의 스레드를 생성하게 되어 M:N 스케줄링의 장점을 무너뜨리고 시스템 자원을 소진시킵니다.
Go 런타임은 스케줄러에 직접 통합된 네트워크 폴러(Linux의 epoll, BSD의 kqueue, Windows의 IOCP 이용)를 사용합니다. 고루틴이 폴링할 수 있는 설명자에서 I/O를 시작하면, 런타임은 이를 _Gwaiting 상태로 주차하고 파일 설명자를 OS 전용 폴러에 등록합니다. 모니터링 스레드는 준비 상태를 기다립니다; 알림이 오면, 폴러는 고루틴을 _Grunnable 상태로 전환하고 사용 가능한 P(논리 프로세서)에 스케줄합니다. 이는 차단되는 작업을 효율적인 주차 이벤트로 변형시켜, 작은 GOMAXPROCS 스레드 풀로 엄청난 동시성을 처리할 수 있게 합니다.
// 실제로 차단되지 않고 주차하는 관용적인 Go 코드 func handleConn(conn net.Conn) { buf := make([]byte, 1024) n, err := conn.Read(buf) // 고루틴을 주차시킴, 스레드를 해방시킴 if err != nil { log.Println(err) return } process(buf[:n]) }
당신은 시장 데이터 피드를 위해 20,000개의 지속적인 TCP 연결을 유지하는 고주파 거래 게이트웨이를 구축하고 있습니다. 변동성 급등 시, 대기 시간을 100 마이크로초 이하로 유지해야 합니다. Java NIO 접근 방식을 사용한 초기 테스트는 처리량을 달성했지만 복잡한 콜백 유지 관리에 어려움을 겪었습니다. Go로 마이그레이션 할 때, 팀은 net.TCPConn을 사용하여 간단한 차단 코드를 작성했습니다. 그러나 50,000개의 동시 연결로 부하 테스트를 수행할 때, 프로세스는 10,000개 이상의 OS 스레드를 생성하여 OOM 킬을 유발하고 대기 시간 보장을 파괴했습니다.
해결책 A: 리액터 패턴을 수동으로 재구현하기. 표준 라이브러리를 우회하고 syscall 래퍼를 사용하여 수동 epoll 이벤트 루프를 작성합니다. 장점: 메모리 레이아웃과 깨우기 지연에 대한 최대 제어. 단점: Go의 순차 코딩 모델을 희생하고, 플랫폼별 복잡성을 도입하며, 검증된 런타임 코드를 중복하여 버그 발생 가능성을 높입니다.
해결책 B: runtime.LockOSThread로 스레드 오버헤드를 수용하기. 각 연결을 전용 스레드에 강제로 할당하여 스케줄링 격리를 보장합니다. 장점: 예측 가능한 스레드 친화성. 단점: 고루틴의 기본 경제적 이익을 위반하며; 메모리 사용량이 ~8MB per connection으로 증가하여 목표 규모에 맞지 않게 됩니다.
해결책 C: 비폴링 I/O를 감사하고 netpoller를 신뢰하기. 관용적인 차단 코드를 유지하되, 스레드 생성을 강제하는 우연한 차단 시스템 호출(예: 로깅 파일 작성 또는 해상도 인식 없이 DNS 조회)을 제거합니다. 장점: 읽기 쉬운 선형 흐름을 유지하며; Linux/macOS/Windows 전반에 걸쳐 런타임 최적화를 활용하고; 메모리를 ~2KB per connection으로 줄입니다. 단점: net.Conn 작업이 주차되고 os.File 작업이 스레드를 차단한다는 깊은 이해가 필요합니다.
팀은 해결책 C를 선택했으며, 스레드 폭발이 정상적으로 이루어진 로그 마켓 데이터를 로컬 ext4 파일에 동기적으로 기록하는 경로에서 발생했음을 인식했습니다. 정규 파일 I/O는 netpoller를 사용할 수 없기 때문에(파일은 항상 Unix epoll에서 “준비됨”으로 취급됨), 각 로그 작성이 OS 스레드를 차단했습니다. 그들은 네트워크 I/O(폴링 가능)를 주요 고루틴에 유지하면서 채널 버퍼를 사용하는 비동기 파일 작성 고루틴으로 리팩토링했습니다.
이제 게이트웨이는 16개의 OS 스레드( GOMAXPROCS와 일치)로 50,000개의 연결을 유지하며 ~85µs P99 대기 시간을 달성하고 있습니다. 메모리 소비는 40GB(예상 스레드 스택)에서 ~180MB 총 RSS로 줄었습니다.
왜 os.Stdin 또는 일반 파일에서 읽는 것이 TCP 소켓과 같은 Read 메서드를 사용하더라도 OS 스레드를 차단하며, 이는 CLI 도구의 동시성에 어떤 영향을 미칩니까?
TCP 소켓은 epoll을 통한 비동기 준비 알림을 지원하는 반면, Unix 시스템의 일반 파일과 파이프는 항상 I/O를 위해 “준비됨”으로 보고합니다; 커널은 파일 데이터 유효성에 대한 비차단 인터페이스를 제공하지 않습니다. 따라서, 고루틴이 os.File.Read를 호출할 때, Go 런타임은 이를 주차할 수 없고 차단 시스템 호출에 실제 OS 스레드를 할당해야 합니다. 입력 파일 당 고루틴을 생성하는 CLI 도구(예: 로그 프로세서)에서는 이로 인해 전통적인 스레딩 모델과 동일한 스레드 누수가 발생합니다. 해결책은 세마포어를 사용하여 동시 파일 작업을 제한하거나 전용 작업자 풀을 사용하는 것입니다.
네트폴러가 네트워크 파티션이 치유된 후 한꺼번에 수천 개의 고루틴을 깨울 때 "우르르 떼지어 몰려오는 무리"를 방지하는 방법은 무엇입니까?
네트폴러가 ( epoll_wait를 통해) 수천 개의 준비된 설명자를 반환할 때, netpoll 함수는 모든 P(논리 프로세서) 간에 고루틴을 분배합니다. 전체 실행 대기열과 작업 도둑 알고리즘을 사용하여, 모든 고루틴을 단일 P에 추가하는 대신 분산합니다. 또한, 스케줄러는 공정성 타이머를 구현합니다: 매 10ms마다 실행 후, 실행 가능한 I/O 고루틴을 확인하여 CPU 집약형 작업이 이를 배고프게 하지 않도록 합니다. 후보자들은 종종 연결당 FIFO 큐잉을 가정하지만, 스케줄러는 깨우는 이벤트를 분산시키고 선점 포인트를 강제하여 처리량의 균형을 유지함을 간과합니다.
SetReadDeadline과 활성 Read 호출 간에 어떤 경합 조건이 존재하며, 타이머 휠 구현이 netpoller와 원자적 동기화를 요구하는 이유는 무엇입니까?
네트폴러는 I/O 기한을 관리하기 위해 각 P 타이머 휠 또는 최소 힙을 사용합니다. 고루틴 A가 고루틴 B가 Read에서 차단되는 동안 SetReadDeadline을 호출하면, A는 B의 주차 상태에 의존하는 타이머를 수정합니다. 원자적 업데이트가 없을 경우(내부 뮤텍스에 의해 보호됨) 경합이 발생할 수 있습니다; 이로 인해 폴러가 새 기한이 설정된 후 이전 기한을 관찰하게 되어 누락된 깨우기(무기한 정지) 또는 불필요한 시간 초과가 발생할 수 있습니다. 원자성은 전에 발생한 일관성을 보장합니다: 업데이트된 기한이 epoll 대기 주기에 의해 관찰되거나 이전 타이머가 작동하게 되며, 그러나 기한 계약을 위반하는 정의되지 않은 중간 상태는 절대 발생하지 않습니다.