윈도우와 리눅스의 멀티프로세싱 동작 방식 차이

 

 

들어가며

작년에 실무에서 파이썬을 사용해 멀티프로세싱 작업을 수행하면서 문제가 발생한 적이 있었습니다.

특정 작업에서 SQLAlchemy(파이썬 ORM 라이브러리)의 DB 커넥션 풀을 사용해 데이터를 INSERT하는 로직이 있었는데, 로컬 개발 환경(윈도우)에서는 아무런 문제가 없었습니다. 그러나 동일한 코드를 사내 개발 서버(리눅스)에 배포했을 때 다음과 같은 에러 로그가 발생했습니다.

 

2024-12-21 17:57:00,471 [ERROR   ] <root> [Process-21][Thread-140372676175552]: write_module:76:  Error during bulk insert: ORA-01001: invalid cursor

ORA-03106: fatal two-task communication protocol error

DPI-1080: connection was closed by ORA-3135

 

에러를 살펴보면, 커서가 잘못되거나 커넥션이 닫혔음을 알 수 있습니다. 특히 SQLAlchemy가 사용하는 DB 커넥션 풀이 리눅스 환경에서 충돌을 일으켰다는 점이 문제의 핵심으로 보였습니다.

 

그렇다면 왜 같은 코드가 OS에 따라 다르게 동작했던 걸까요?

 

 

 

 

 

SQLAlchemy 커넥션 풀과 멀티프로세싱

이에 대한 힌트를 SQLAlchemy 공식 문서에서 찾아볼 수 있었습니다.

 

https://docs.sqlalchemy.org/en/20/core/pooling.html#pooling-multiprocessing

Connection Pooling — SQLAlchemy 2.0 Documentation

 

It’s critical that when using a connection pool, and by extension when using an Engine created via create_engine(), that the pooled connections are not shared to a forked process.
(...중략)
The SQLAlchemy Engine object refers to a connection pool of existing database connections. So when this object is replicated to a child process, the goal is to ensure that no database connections are carried over.

 

 

공식 문서에서 SQLAlchemy의 엔진은 fork된 프로세스에 기존 데이터베이스의 커넥션 풀을 참조한다고 설명되어 있습니다. 즉, 자식 프로세스를 생성할 때 fork 방식으로 부모 프로세스를 복사하기 때문에 부모 프로세스가 가지고 있는 커넥션 풀을 공유하게 됩니다. 이로 인해 자식 프로세스에서 부모 프로세스의 리소스를 사용하려다 충돌이 발생합니다.

 

이러한 멀티프로세싱 환경에서 문제를 해결하기 위해 몇 가지 방법을 제시하고 있는데 그 중 engine.dispose(close=False)를 사용하는 것을 권장하고 있습니다.

 

아래 예시 코드와 같이 엔진 초기화 시 Engine.dispose.close의 매개변수 값에 False를 전달하게 되면, 자식 프로세스가 부모 프로세스의 커넥션 풀을 건드리지 않고 새로운 커넥션을 시작합니다.

from multiprocessing import Pool

engine = create_engine("mysql+mysqldb://user:pass@host/dbname")


def run_in_process(some_data_record):
    with engine.connect() as conn:
        conn.execute(text("..."))


def initializer():
    """ensure the parent proc's database connections are not touched
    in the new connection pool"""
    engine.dispose(close=False)


with Pool(10, initializer=initializer) as p:
    p.map(run_in_process, data)

 

코드 설명

1. engine.dispose(close=False)
   • 자식 프로세스에서 새로운 커넥션 풀을 생성하도록 강제합니다.
   • close=False는 기존 연결을 닫지 않고 새 커넥션만 생성합니다.
2. initializer 함수
   • initializer를 통해 각 자식 프로세스의 초기화 시 엔진 리소스를 정리합니다.
3. Pool 생성 시 초기화 함수 지정
   • multiprocessing.Pool에서 initializer를 지정하면 자식 프로세스 생성 시 자동으로 호출됩니다.

 

 

 

 

 

윈도우와 리눅스의 멀티프로세싱 차이

그렇다면 윈도우에서는 왜 이런 문제가 발생하지 않았던걸까요?

그 이유는 파이썬에서 멀티프로세싱을 수행하는 방식이 운영체제에 따라 다르게 동작하기 때문입니다.

 

• 윈도우: spawn() 방식을 사용해 새로운 프로세스를 독립적으로 생성합니다. 이 과정에서 부모 프로세스의 리소스를 새로 초기화합니다.
• 리눅스: fork() 방식을 사용해 부모 프로세스를 복사합니다. 이로 인해 부모 프로세스의 모든 리소스, 즉 SQLAlchemy의 커넥션 풀도 공유됩니다.

 

이 동작 차이를 간단한 코드로 확인해 보겠습니다.

import multiprocessing as mp
import random

val = random.random()

def simple_func():
    print(val)


if __name__ == '__main__':
    print('Before multiprocessing: ')
    simple_func()
    print('After multiprocessing:')
    p = mp.Process(target=simple_func)
    p.start()
    p.join()

 

 

윈도우 출력 결과

Before multiprocessing: 
0.7345451427940827
After multiprocessing:
0.23541224006190398

 

윈도우는 자식 프로세스가 완전히 독립적인 새로운 공간에서 시작하므로, random.random()으로 생성된 val 값을 복사하지 않고 자식 프로세스에서 새로 초기화됩니다.

결과적으로 부모 프로세스와 자식 프로세스의 val 값이 서로 다릅니다.

 

 

리눅스 출력 결과

Before multiprocessing:
0.19180520863603323
After multiprocessing:
0.19180520863603323

 

fork()로 인해 부모와 자식이 동일한 리소스를 공유합니다. 부모 프로세스의 모든 메모리 상태를 복사하기 때문에, 부모 프로세스에서 생성된 val 값이 자식 프로세스에도 동일하게 전달됩니다.

결과적으로 부모 프로세스와 자식 프로세스의 val 값이 동일합니다.

 

SQLAlchemy에서도 동일한 원리로 인해 부모 프로세스의 커넥션 풀이 자식 프로세스에 복사되며 OS 간에 차이가 발생했던 것입니다.

 

 

 

 

 

 

결과 요약

1. 윈도우와 리눅스의 멀티프로세싱 방식은 다르다.
   • 윈도우는 spawn() 방식을 사용해 부모 프로세스와 독립된 새로운 프로세스를 생성하지만, 리눅스는 fork()방식으로 부모 프로세스를 복사해 리소스를 공유합니다.
   • 이 차이로 인해 리눅스 환경에서는 부모 프로세스의 리소스가 자식 프로세스에서 충돌을 일으킬 수 있습니다.
2. SQLAlchemy는 멀티프로세싱 환경을 위해 dispose(close=False) 방식을 권장한다.
   • engine.dispose(close=False)를 사용해 자식 프로세스에서 새로운 커넥션 풀을 생성함으로써 문제를 해결할 수 있었습니다.

 

 

 

참고

https://pythonforthelab.com/blog/differences-between-multiprocessing-windows-and-linux/

https://docs.sqlalchemy.org/en/20/core/pooling.html#pooling-multiprocessing