2008. 12. 23. 14:01

JOINC.co.kr

쓰레드 풀 작성

Date: 2002/12/23

Topic: 시스템 프로그램

윤상배: dreamyun@yahoo.co.kr

 

 

쓰레드 풀은 연결/종료가 자주 일어나는 웹 서버와 같은 바쁜 서버에게 있어서 효율적인 클라이언트 연결 처리를 위해서 사용하는 프로그래밍 기법이다. 이번에는 쓰레드 풀을 이용한 애플리케이션 제작 방법에 대해서 알아보도록 하겠다.

 

1절. Thread Pooling

 

1.1절. Thread Pooling 이란

 

pool의 사전적인 뜻을 찾아보면 연못, 저수지, 수영장 풀 등 "무엇을 담아놓는"의 뜻을 가진다. 이대로 해석하자면 Thread Pooling이란 쓰레드를 담아 놓는 용기(메모리가 될 것이다)를 뜻하며, 프로그래밍 측면에서 해석하자면, "미리 쓰레드를 할당시켜 놓는 기법"을 뜻한다.

 

그렇다면 쓰레드를 미리 할당시켜 놓는 이유에 대해서 생각해보자, 지금까지 이 사이트에서 다루었던 쓰레드 프로그래밍 기법은 기본적으로 fork 방식과 매우 비슷하며, 쓰레드를 생성시켜야 될 필요가 있을 때 pthread_create(3) 등의 함수를 이용하여 새로운 작업 쓰레드를 생성시키는 방식을 사용했다. 보통 쓰레드 프로그래밍은 네트웍 프로그래밍시 주로 사용됨으로 accept(2)로 연결을 기다리다가 연결이 만들어지면 accept에서 넘어온 소켓 지시자를 인자로 하는 쓰레드를 생성했다.

 

이러한 방식 - 요청이 있을 때 쓰레드를 생성시키는 - 의 쓰레드 프로그래밍 기법은 대부분의 작업을 처리하기에 충분히 효율적이며, 빠르긴하지만 클라이언트로부터의 연결과 종료가 매우 바쁘게 일어나는 서버의 경우, 계속적으로 쓰레드를 생성하고 종료해야 하는 비용을 무시할 수 없게 된다. 쓰레드가 비록 fork()에 비해서 생성과 소멸시에 훨씬 적은 비용을 소모한다고는 하지만, 이건 어디까지나 상대적인 것으로 실상은 꽤 많은 시간과 비용을 소비하는 작업이다. 특히 Linux에서의 Pthread의 경우 clone(2)을 이용한 구현임으로 더욱더 많은 비용을 소비하게 된다.

 

Thread Pooling은 이러한 반복적인 쓰레드의 생성/소멸에 의한 비효율적인 측면을 없애고자 하는 목적으로 만들어진 프로그래밍 기법이다.

 

1.1.1절. Thread Pool의 구현방식

 

개념적으로 보자면 Thread Pool을 구성하는 건 매우 간단하다. 생성하고자 하는 크기만큼 ptread_create 함수를 돌리면 되기 때문이다.

 

하지만 이건 어디까지나 개념적인 것으로 대부분의 경우 각각의 쓰레드를 스케쥴링 해주어야 함으로, 때에 따라서는 구현을 위해서 매우 복잡한 프로그래밍 기법을 동원해야 할 때도 있다. 간단히 웹 서버를 Thread Pool로 구현한다고 가정을 해보자. - 보통 웹 서버는 HTTP의 특성상 연결/종료가 빈번하게 일어 남으로 쓰레드 풀을 사용할 경우 많은 이익을 얻을 수 있다 - 만약 100개의 Thread를 미리 생성시켰고, 각각의 Thread는 하나의 클라이언트 연결을 처리한다고 가정했을 때, main 쓰레드는 accept(2)를 통해서 클라이언트를 받아들였을 때, accept()로 만들어진 소켓 지정 번호를 미리 만들어진 100개의 쓰레드 중 "놀고" 있는 쓰레드에게 넘겨주어야 할 것이다. 그러기 위해서는 main 쓰레드에서 각각의 쓰레드 상태를 유지해서 적당한 쓰레드에게 파일 지정자를 넘겨줘야 할 것이다.

 

그나마 위의 경우는 하나의 쓰레드가 하나의 연결을 처리함으로 어렵지 않게 구현하겠지만, 만약 100개의 쓰레드가 있고, 거기에 각각의 쓰레드가 10개씩의 클라이언트 연결을 처리하도록 구성한다면, 거기에다가 적당한 로드 밸런싱 기능까지 포함시키고자 한다면, 구현이 꽤 복잡해 질 수도 있다.

 

위는 Thread Pool의 대략적인 구현 상태를 그림으로 나타낸 것이다. Thread Pool에 들어있는 각각의 쓰레드를 관리하기 위해서는 필수적으로 각각의 쓰레드의 상태를 가지고 있는 Schedul 자료 구조를 가지고 있어야 한다. 그래야만 MAIN THREAD에서 쓰레드 상태를 확인해서 적당한 쓰레드로 작업 분배가 가능할 것이기 때문이다. - 실제 Linux 커널도 각각의 task의 스케쥴링을 위해서 task 구조체를 유지한다. -

 

1.1.2절. 구현 프로세스

 

이제 구현 방식에 대한 밑그림이 나왔으니, 실제로 구현을 위한 프로세스를 만들어 보도록 하자.
프로세스는 슈도 코드로 구성을 하도록 하겠다. 네트웍 서버 작성을 기준으로 하겠다.

구현은 구현하는 프로그래머가 상황에 따라서 선택하기 나름이긴 하지만 보통은 위의 방법을 기본으로 해서, 약간의 변경을 가하는 정도가 될 것이다. 위의 슈도 코드를 보면 main 쓰레드에서 accept를 받으면 휴식 상태에 있는 쓰레드를 깨운다고 되어 있는데, 이때 깨우기 위해서는 쓰레드 조건 변수를 사용하면 될 것이다.

 

그렇다면 스케쥴 관련 자료 구조는 어떻게 구현하는게 쉬운 방법인지 생각해보도록 하자. 구현하는 방법은 프로그래머 맘이겠지만, 필자가 구현하고자 한다면 multimap을 이용해서 구현할 것이다. 이 자료 구조는 아마 다음과 같을 것이다.

멀티맵의 key는 쓰레드의 활성화 여부로 1 혹은 0이 된다. 그리고 value는 해당 쓰레드 정보가 될 것이다. 이렇게 멀티맵으로 만든 이유는 간단하다. 멀티맵은 정렬 연관 컨테이너임으로 key를 기준으로 자동적으로 정렬이 될 것이다. 만약 첫 번째 쓰레드가 처리 중(1)으로 변경되었다면 이 원소는 multimap의 가장 뒤로 정렬이 될 것이다. 그럼으로 우리는 클라이언트의 수가 총 연결 가능한 클라이언트 수(Thread Pool에 생성된 쓰레드 수)를 초과하지 않는 한 phinfo.begin()로 가져온 쓰레드는 휴식 상태(0)이라는 걸 믿을 수 있게 된다. 다시 말해서 복잡해서 쓰레드 상태가 0인지 1인지 처음부터 검사할 필요가 없다는 뜻이다.

 

사실 multimap을 쓴다면 굳이 "현재 연결된 클라이언트 수"를 유지하기 위해서 별도의 변수를 둘 필요가 없을 것이다. multimap에서 제공하는 count()를 이용해서 key가 "1" 인 요소의 수를 구하면 되기 때문이다. 만약 multimp의 begin() 값이 1이라면 MAX 클라이언트가 가득 찼다는 걸 의미할 것이다.

 

물론 multimap의 경우 기본적으로 key 값의 수정은 허용하지 않기 때문에 0을 1로 변경할 경우 실제로는 0을 가지는 요소를 삭제하고, 1을 가지는 새로운 요소를 삽입하는 방식을 취해야 할 것이다. 마찬가지로 클라이언트가 종료해서 1을 0으로 변경할 때에도 삭제/인서트를 해야할 것이다. Value(값)는 그대로 복사해서 삭제/인서트를 해야 한다.

 

이 방법이 번거롭다면, 그냥 배열을 쓰거나 혹은 다른 어떤 자료 구조를 쓰더라도 전혀 관계없기는 하다. 그건 자기의 기호에 맞게 선택해서 사용하면 될 문제이다.

 

1.2절. 예제

 

지금까지 Thread POOL의 구현 방법에 대해서 알아봤으니, 간단하게 구현해 보도록 하겠다. 이 코드는 지극히 기능 구현에만 신경쓴 코드이다. 에러 처리와 몇 군데 뮤텍스 잠금 처리는 각자의 재량에 맡기겠다.

 

예제 : pool_echo.cc

이 프로그램은 두 개의 인자를 받아들이며, 클라이언트의 입력을 되돌려 주는 일을 한다(echo 서버). 첫 번째 인자는 서비스 할 PORT 번호이고, 두 번째 인자는 쓰레드 생성 개수이다. 프로그램은 인자의 정보를 이용해서 PORT를 열고 클라이언트를 받아들인다. 클라이언트가 연결하면, Thread Pool에 남는 공간이 있는 지를 확인하고, 남는 공간이 있다면 클라이언트와 통신하게 된다.

 

단지 쓰레드를 미리 생성시키고 나서, 이것을 스케쥴링하기 위한 코드가 몇 줄 추가되었을 뿐 특별히 복잡한 코드는 아닐거라고 생각된다.

 

2절. 결론

 

이상 간단한 쓰레드 풀의 작성 요령에 대해서 알아보았다. 위에서 설명했듯이 쓰레드 풀이란 개념적인 요소에 가까움으로 어떻게 구현할 지는 상황에 따라서 매우 달라지게 되며, 위의 예제는 그러한 여러 가지 상황 중 가장 기본적인 상황을 예로 해서 만들어진 것이다. 어쨋든 위의 예제를 충분히 이해한다면 다른 상황으로의 응용 역시 별 어려움 없을 것이라고 생각된다.

 

쓰레드 풀은 보통 매우 효율적인 성능을 보장해주는 애플리케이션의 작성을 위해서 사용되어짐으로, 가능한 한 빠른 쓰레드 간 전환이 가능하도록 고민해서 코딩을 해야 한다. 위의 경우 쓰레드 간 전환을 위해서 multimap을 사용하고 있는데, accept가 들어왔을 경우 해당 클라이언트에 대한 쓰레드 할당은 매우 빠르다고 볼 수 있을 것이다. 그러나 종료할 경우에는 multimap의 첫 번째 원소부터 마지막 번 원소까지 search 해야 한다. 이것은 매우 비효율적임으로 개선할 여지가 있다. 가장 간단하게 생각할 수 있는 것은 multimap의 key 값이 1인 원소 내에서만 검색하는 것이다. 우리는 쓰레드 풀의 크기와 현재 연결된 클라이언트의 수를 알고 있음으로, multimap의 몇 번째 요소부터 key 값이 1인지를 계산해 낼수 있기 때문이다. 이렇게 할 경우 약간의 시간 단축 효과를 기대할 수 있을 것이다.

이 시간 단축 효과는 연결된 클라이언트의 수가 전체 POOL 사이즈에 비례해서 작을 수록 커질 것이다.

 

나머지 방법은 각자 고민을 해보기 바란다. 아마 전혀 다른 자료 구조를 사용할 수도 있을 것이다.

 

This article comes from Joinc

http://www.joinc.co.kr

Posted by 두장