공유 캐시를 빠르게 사용하는 서버와 실패한 작업자를 격리해야 하는 서버에서 프로세스와 스레드는 어떤 기준으로 선택하나요?

프로세스와 스레드는 ‘무엇을 공유할지’와 ‘실패를 어디까지 가둘지’를 기준으로 선택합니다. 프로세스는 별도 가상 주소 공간과 자원 경계를 제공하므로 잘못된 포인터나 크래시를 다른 프로세스에서 격리하기 쉽습니다. 스레드는 같은 프로세스의 힙·전역 데이터·파일 디스크립터를 공유하며 각자 stack·register·실행 상태를 가집니다. 스레드마다 stack이 있다는 사실은 주소 공간 격리가 아니므로, 공유 캐시의 빠른 접근과 장애 격리는 서로 다른 축으로 판단해야 합니다. 이를 실행 단위 선택(process versus thread model)이라고 합니다.

공유 효율의 대가

메모리 캐시를 여러 요청 처리 흐름이 함께 읽고 짧은 상태 갱신을 한다면 스레드는 복사와 IPC를 줄일 수 있습니다. 대신 데이터 경합, lock 경합, 잘못된 수명 관리, false sharing이 프로세스 전체에 영향을 줍니다. 스레드 수를 늘려도 공유 카운터·메모리 대역폭·캐시 일관성에서 병목이 생길 수 있으므로 실행기 큐와 락 보유 시간을 측정하겠습니다. 프로세스는 격리를 얻지만 IPC, 직렬화, 중복 메모리와 상태 동기화 비용이 늘어납니다.

신뢰하기 어려운 플러그인, 네이티브 라이브러리, 작업별 CPU·메모리 제한이 필요한 경우에는 worker process와 감독자를 선택할 수 있습니다. 다만 worker를 죽이고 재시작하는 것만으로 진행 중 작업이 안전해지는 것은 아닙니다. 작업 ID와 멱등 처리, 진행 상태 저장, 결과 커밋 경계를 두어 재할당과 중복 반영을 제어해야 합니다. 반대로 모든 것을 프로세스로 나누어도 공통 DB·네트워크·호스트 메모리를 함께 고갈시키면 장애 격리는 완성되지 않습니다.

스레드와 프로세스는 생성 비용이 아니라 장애 전파 경계까지 비교해야 합니다. 요청 라우터와 신뢰하는 계산은 스레드로 두고, 신뢰할 수 없는 압축·스크립트 작업은 worker process로 보내는 혼합 구성이 가능합니다. 이때 process마다 CPU·메모리·파일 디스크립터·큐 한도를 두고 감독자가 deadline과 종료를 관리해야 주소 공간 분리만으로 끝나지 않습니다.

예를 들어 8개 스레드의 공유 캐시는 메모리 복제가 없지만 한 잘못된 포인터가 모든 요청을 중단시킬 수 있습니다. 4개 프로세스로 복제하면 crash 범위는 줄어도 4배 캐시 메모리와 IPC 직렬화가 생깁니다. 같은 부하에서 p99·IPC 대기·cache miss·메모리와, worker 강제 종료 뒤 다른 요청 성공률·복구 시간·중복 결과를 비교해 선택하겠습니다.

프로세스 경계는 crash를 막는 것이 아니라 crash가 미치는 주소 공간을 제한합니다. 공용 DB나 메시지 큐의 작업이 중복되면 프로세스를 나눠도 결과는 깨질 수 있습니다. 그러므로 감독자는 worker 종료뿐 아니라 작업 lease, 결과 검증, 재시도와 멱등성을 관리해야 합니다.

프로세스 경계는 충돌의 범위를 제한하지만 공용 DB·네트워크·호스트 메모리 고갈을 막지는 않습니다. worker를 재시작해도 작업 중간 결과가 자동으로 안전해지지 않으므로 작업 ID·deadline·결과 커밋·멱등 재시도를 감독자가 관리해야 합니다. 반대로 스레드 공유 캐시는 복제를 줄이지만 포인터 오류와 메모리 폭증이 전체 주소 공간에 영향을 줍니다. 장애 주입 시 다른 요청 성공률과 복구 시간을 비교하겠습니다.