[마소 394호] 되돌아 보는 1만 개의 클라이언트 문제

입력 2018.10.31 10:02

소프트웨어 전문지 마이크로소프트웨어 394호는 클라우드(Cloud)와 백엔드(Back-End)를 주제로 담았습니다. C10k, 데브옵스, PaaS, 마이크로서비스 아키텍처 등 마소 394호의 주요 기사들을 IT조선 독자에게도 소개합니다. [편집자주]

1만 개의 클라이언트 문제(The C10k Problem)는 1999년 단 케겔(Dan Kegel)이 처음 제시한 이야기로, ‘1만 개의 클라이언트를 동시에 처리할 수 있는 네트워크 I/O 모델 설계 방법(www.kegel.com/c10k.html)’을 묻는 말이다. 여기서 동시 처리의 기준이 되는 시간은 정확히 명시하지 않았지만, 보통은 1초를 뜻한다.

당시 하드웨어 기술은 그리 뛰어나지 않았다. 1GHz 성능의 CPU 1코어, 2GB 메모리의 컴퓨터를 사려면 100만 원이 훌쩍 넘는 돈이 필요했다. 이런 상황에 인터넷 사용자까지 급격히 늘어났으니 인기 있는 웹 사이트를 운영하는 사람들에게 1만 개의 클라이언트 문제는 반드시 해결해야 할 문제였다. 이는 미국만의 문제가 아니었다. 국내의 경우도 1998년과 1999년 사이에만 인터넷 사용자가 두 배 이상 증가했다.

20년이 지난 지금, 컴퓨터 성능은 10배 가까이 좋아졌다. 100만 원이 조금 넘는 돈이면 3GHz가 넘는 클럭 수와 4코어를 가진 CPU를 살 수 있고, 메모리도 8GB까지 살 수 있다. 여기다 꽤 좋은 그래픽 카드도 하나 끼워 넣을 수 있을 것이다. 이 정도면 클라이언트 1만 개 정도는 충분히 처리하지 않을까? 이 문제는 아직도 유효한 걸까?

고민하는 개발자. / 마이크로소프트웨어 394호 발췌
이 문제는 아직도 유효하다. 그리고 생각보다 많은 곳에서 1만 개의 클라이언트를 1초 안에 처리하지 못한다. 더 정확히 말하면, 사람들은 자신이 만든 서버가 1초에 얼마나 많은 요청을 처리할 수 있는지 모른다.

그 이유는 우리가 사용하는 기술과 관련 있다. 1990년대 후반에만 해도 서버 프로그램을 만들려면 소켓 동작 방식을 이해하고 프로토콜 헤더 정보, 연결을 맺고 끊는 일련의 과정을 알아야만 했다. 하드웨어 성능도 좋지 않았기 때문에 가능한 모든 수를 써서 자원을 낭비하지 않도록 개발해야 했다. 실제로 오래전에 생긴 ‘select()’와 ‘poll()’ 함수들은 CPU의 컨텍스트 스위칭 비용을 줄이기 위해 커널 영역에 접근하지 않게 설계돼 있다.

하지만 지금은 어떨까? 자바스크립트 언어 하나만 알아도 프론트엔드와 백엔드에서 동작하는 프로그램을 만들 수 있다. HTTP가 동작하는 방식을 자세히 알지 못해도 라이브러리나 프레임워크가 제공하는 함수, 핸들러 등록만으로 메시지를 주고받는 시대가 온 것이다.

더는 메시지를 어떻게 주고받는지 자세히 알 필요가 없다. 성능이 조금 낮아도 괜찮다. 이제 성능보다는 올바르게 동작하는 기능을 먼저 만드는 게 더 중요하다. 처음부터 수백만 명의 사용자를 대상으로 하는 서비스처럼 서비스 성능이 명시적으로 정의된 게 아니라면, 성능을 개선하는 일은 서비스 출시 후에 해도 늦지 않다는 이야기다.

지금은 프로그램을 만들고, 성능을 평가한 후 결과를 기반으로 개선 작업을 진행한다. 이런 점진적 개발 방식은 개발 라이브러리와 프레임워크 덕분에 가능하게 됐지만, 메시지를 어떻게 처리하는지 알 방법이 없다는 점이 새로운 문제를 만들었다. 이제는 많은 사람이 네트워크 통신을 블랙박스처럼 다루기 시작한다. 한 마디로 ‘라이브러리가 알아서 해주겠지’ 정도로 생각하는 것이다.

네트워크에서 병목이나 과부하가 발생해도, 문제를 전혀 다른 관점에서 보기 시작한다. ‘데이터베이스가 느려서 그럴 거야’, ‘캐시를 추가하면 되지 않을까?’, ‘HTTP 헤더에 무언가를 추가해야 하나?’와 같은 것들 말이다. 실제로는 연결 풀이 부족하거나 비효율적이어서 그런 건데 말이다.

그럼 이제 본론으로 돌아와서, 문제를 다시 한번 생각해보자. 이 문제가 아직 유효한가? 20년 전 1만 개의 클라이언트를 처리하기 위해 사용했던 기술이라면 지금도 1만 개, 10만 개의 클라이언트를 처리하는 데 도움이 되지 않을까? 이 문제를 풀기 위해서는 어떤 지식이 필요할까?

이기곤 필자의 ‘되돌아 보는 1만 개의 클라이언트 문제’에 대한 자세한 내용은 ‘마이크로소프트웨어 394호(https://www.imaso.co.kr/archives/3939)’에서 확인할 수 있다.


키워드

관련기사를 더 보시려면,

[마소 394호] RxJava로 생각하기 오세용 기자
[마소 394호] 플라스크 효과적으로 사용하기 오세용 기자
[마소 394호] 스토리체인이 사이드체인을 선택하기까지 오세용 기자
[마소 394호] 모바일 앱 테스트 자동화용 디바이스팜 구축 오세용 기자
[마소 394호] 클릭만으로 도커 개발 환경을 완성시켜주는 애저 PaaS 오세용 기자
[마소 394호] DDD와 MSA로 쇼핑몰 구축하기 오세용 기자
[마소 394호] 이스티오 서비스 메시를 이용한 MSA 구축 오세용 기자
[마소 394호] 제대로 구성하는 마이크로서비스 아키텍처 오세용 기자
[마소 394호] 아마존 API 게이트웨이와 AWS 람다로 구성하는 다운로드 서버 오세용 기자
[마소 394호] AWS EC2와 트래비스CI를 활용한 무중단 배포 서비스 오세용 기자
[마소 394호] 스타트업의 좌충우돌 CI/CD 구성 오세용 기자
[마소 394호] AWS 이메일 서비스 써보니 오세용 기자
[마소 394호] 클라우드의 성능 품질 이야기 오세용 기자
[마소 394호] 클라우드 시대 토종 호스팅 업체의 변신 오세용 기자
[마소 394호] 데이터베이스의 게임 체인저, 오라클 클라우드 오세용 기자
[마소 394호] 알아두면 쓸데없는 신비한 TLS 1.3 오세용 기자
[마소 394호] 다시 보는 PaaS, 어디서 와서 어디로 가는가 오세용 기자
[마소 394호] 코드로 관리하는 인프라스트럭처, 테라폼 오세용 기자
[마소 394호] 더 웨더 컴퍼니의 데브옵스 오세용 기자
[마소 394호] 사설 클라우드의 끝판왕 오픈스택 오세용 기자
[마소 394호] 개발운영 퀀텀 점프를 위한 도커 오세용 기자
[마소 394호] IT 서비스와 모니터링 역사 오세용 기자
[마소 394호] 오픈스택 커뮤니티 동고동락 오세용 기자
[마소 394호] 데브옵스를 꿈꾸는 개발자를 위한 안내서 오세용 기자