Multi-core의 Concurrency를 위해선 멀티스레딩 뿐인가?

답은 아니다라고 생각한다 — 실제 현실도 그런 것 같고. 명확히 정리된 생각은 아니지만, 어제~오늘 생각했던 얘기를 풀어보겠다. 응용에 따라선 다른 방식으로 하드웨어(특히 CPU)의 concurrency를 끌어다 쓸 수 있을 것 같으니.¹

멀티코어 / 멀티 CPU 머신이 시대의 흐름인 것은 거의 확실하다. 적어도 앞으로 수 년 정도 범위에서 CPU 기술의 방향은,

• 메모리와의 통신 효율성 재고 — 현재 최대의 병목은 CPU – 메모리 통신이다
• 캐쉬 용량 증대 — 앞에서 말한 효율성의 개선
• CPU 코어 수 증가 — CPU 클럭을 올리는게 힘들어지지만 당분간은 트랜지스터 수는 늘릴 수 있으니 이 쪽일 것이다

일 거라고 생각한다. 이 중에 마지막 예측 때문에 허브 서터 같은 “대가” 들이 concurrency를 활용하기 위한 방안들을 설명하거나, 강조하고 있다. 그러나 한 프로세스 ² 의 성능 향상 범위에서 보면 이건 정확하다. 적어도 CPU 발전 방향이 코어 수 증가로 쏠려있는 상황에서는³ 단일 프로그램의 1개 실행 속도가 올라가는데는 concurrency를 이용하지 않고는 한계에 직면한다. 뭐 “단일 프로그램"의 얘기다.

범위를 좀 더 확대해서 생각해보자.

1명의 사용자가 아니라 여러 명에게 서비스를 제공하는 “사업자” 측면을 생각해보자. 성능을 끌어올리기 위해 — 혹은 많은 사용자에게 서비스를 제공하기 위해 — 선택할 프로그래밍 모델은 세 가지 정도라고 생각된다.

1. 멀티스레딩 or concurrent 응용을 만들어낸다. 게임 쪽에서 MMORPG 서버를 만들 때 이런 방식을 취한다.
2. 같은 서비스를 제공하는 프로세스를 여럿 사용한다. 필요에 따라선 여러 개의 서버에 나눠 띄운다.
3. 같은 서비스를 제공하는 여러 개의 프로세스 - 여러 프로세스가 한 묶음이 되게 - 를 만들고, 이들간의 통신 시스템을 만든다. 역시 필요에 따라선 여러 개의 서버에 나눠 띄운다.

아마 많은 경우에 프로그래밍 복잡도는 1 > 3 > 2가 아닐까. 반대로 scalability는 3 > 2 > 1 순서.

물론, 하나의 프로세스 실행을 가속할 방법은 1 밖에 없지만, 사업자 측면에서 보면 1~3 모두가 scalable한(확대 제공 가능한) 서비스를 만들어낼 수 있는 방법이다.

게임 서버 처럼 프로세스보다 작은 단위 — 예를 들어 게임 내의 NPC와 게이머의 상호작용, 게이머간의 상호작용 — 에서 데이터 공유가 매우 많다면, 프로세스를 1개로 제한하는 수 밖에 없지만⁴, 그렇지 않은 상황에선 2/3 중에 적당한 것을 골라야 하지 않을까.

현존하는 초대형 웹 서비스들 — 웹 포탈이나 WordPress.com 같은 대형 호스팅 서비스들 — 은 3과 비슷한 구조를 가지고 있다. Load–balancer, 응용 서버 그리고 분산 DB로 이어지는 _잘 정의된 분할_을 가지고 있다. 물론 이런 대형 서비스들은 그것만으로 부족해서 구글의 분산 파일 시스템⁵ 같은 도메인에 정말 잘 어울리는 응용을 개발해버리기도 하지만 :)

게임 서버의 경우에도 2, 3 과 같은 구현체들이 적지 않다. Sun의 Dark Star도 3과 유사한 구조를 가지고 있다 — 알려진 성능 평가는 “안습” 한 마디 빼고는 해줄 말이 없지만.⁶ 카트라이더나 많은 수의 MMOG — 사용자 간의 상호작용이 일정 수(30인 이하 수준)으로 유지되는 게임들 — 의 경우에는 3과 같은 구조를 만들어내기 쉽다. Front-end의 load-balancer와 뒷 단의 DB, 그리고 중간이 분산된 게임 서버들 구성을 하는 경우들이 있다.

이런 분산된 개별 게임 서버는 간단하게 싱글 스레드/프로세스를 채용할 수 있게 된다. N모사 (내가 다니는 곳이 아닌 :p )에서 퇴사한 모군의 경우엔 싱글 스레드로 서버를 바꿨더니,

누구나 수정할 수 있게 되었어요!

라고 좋아하더라. 비슷하게 또 다른 개발자 한 분도, “굳이 멀티스레딩 쓸 이유있나요” 라는 뉘앙스의 얘기를.

사실 맞는 얘기다. 이런 구조에서 얻을 수 있는 병렬성이 있다 = 코어 수가 늘어갈 때도 분명히 이익이 있다. CPU 코어 수 만큼 게임 프로세스를 띄워버리면 되니까. 그럼 CPU를 낭비할 일도 없이(혹은 적게) 서버를 운영할 수 있게 된다.

그리고 위에서 후배 모군이 얘기한 것처럼 단일 스레드 프로그래밍은 쉽다. 굉장히 예측가능하고 인간의 뇌가 이해하기 쉽다. 다만 프로세스 간 통신이 힘들다는 근본적인 문제 때문에 만들어야하는 응용에 쓸 수 있냐없냐하는 문제가 있다. 오류가 발생해도 단순히 일부 게임들만 죽고(?) 끝나고, 개별 메시지를 처리할 때마다 오류처리를 아주 힘들게 할 이유가 없다 — 정 안되면 일부 게임을 포기하고 죽여버리면 되니까. 심지어 서버를 죽인다는 메모리 릭⁷이 좀 있어도 일부 게임만 죽이면서 프로세스를 다시 띄우는 방식으로 해결할 수 있다.

그래서 MMORPG 서버처럼 무시무시하게 coupling된 시스템이 아닌 이상 잘 쪼갤 궁리부터 열심히 해야하지 않을까. 잘 쪼개고, 쉽게 (단일 스레드로) 가는게 개발자 건강에 유익하지 않을까 하고 잡 생각하는 밤이다.

ps. 완전히 여담이지만. 1의 구조로 가기엔 지금 우리가 가진게 너무 없다. STM이나 묵시적인 locking algorithm, 메시지 전송 같은 좀 더 편안하고, 안전하게 쓸 수 있는 primitive 혹은 개념들이 제공되기 시작했지만 멀티스레딩-concurrent programming이란 것은 저수준 시스템 프로그래밍에 가깝다;

OS에서 제공하지 않는 기능만으로 하기엔 한계가 있고, OS에서 제공하는걸 쓰자니 굉장히 저수준이 되어가고.⁸