서버를 위한 동시성 모델과 Staged eventdrivenarchitecture

1. 서버를 위한 동시성 모델과Staged
Event Driven Architecture
2011.12.17
chois79

2. Contents
• 인터넷 서비스 사용 동향
• 서버 이슈
• 동시성을 위한 서버 모델
– 스레드 기반 모델
– 이벤드 기반 모델
• Staged Event Driven Architecture
• 적용 사례
• 결론

3. 인터넷 서비스 사용 동향 (1/2)
• 인터넷 서비스를 이용하는 사용자 수의 급증
페이지 뷰: 1조
유니크 방문자: 8억
페이지 뷰: 240억
유니크 방문자: 3,700만
자료 출처: DoubleClick Ad Planner

4. 인터넷 서비스 사용 동향 (2/2)
• 순간 트래픽 폭증 현상

5. 서버 이슈
• 동시에 많은 사용자에게 서비스를 제공해야 한다
– 스레드 기반 모델
– 이벤트 기반 모델
• 순간적으로 사용량이 급증하는 상황에서도 정상적인 서비스가
가능해야 함
– 순간 최대 사용량에 맞추어 장비를 마련하는 것은 현실적으로 불가능
– 로드 관리를 위한 특별한 프레임웍은 없음

6. 동시성을 위한 서버 모델

7. 스레드 기반 모델
• 스레드란?
– 경량 프로세스
– 운영체제에서 스케쥴링하는 최소 단위
– 프로세스에 비해 컨텍스트 스위칭 비용이 적음
– 스택을 제외한 Heap 및 코드 영역 공유
– 실행하는 작업이 서로 독립적일수록 더 나은 성능을 가짐

8. 스레드 기반 서버 모델
• 서비스 요청당 하나의 스레드를 생성하여 처리
– 코드가 직관적이고, 개발하기 편리하다
– Ex) 스레드 기반 HTTP 서버: apache, tomcat

9. 스레드 기반 서버 모델의 이슈
• 스레드를 많이 생성할 경우 성능 저하가 발생
– 리소스 낭비: Jdk 1.6 기준 1M 스택 사이즈
– 컨텍스트 스위칭, 스레드 생성 및 소멸에 따른 오버헤드

10. 스레드 기반 모델에서의 부하 관리
• 스레드의 개수를 제한하는 방법
– 스레드 풀을 사용하여 최대 개수를 제한하고, 생성에 따른 오
버헤드를 감소
• 스레드의 개수를 어떻게 결정할 것인가?
– 부하 테스트 이외에는 방법이 없음

11. 이벤트 기반 모델
• Event-Driven Architecture?
– 이벤트란 어플리케이션 내에서 중요한 상태의 변화
• EX) Network or Disk I/O 읽기 준비 상태, 완료 상태, 타이머 등
– 생성 및 핸들링 모듈로 구성, 서로 다른 프로세싱 유닛에서 동작
– 일반적으로 넌블럭킹 IO와 같이 사용되며, 콜백을 이용하여 상태 변
화에 따른 동작을 등록
– 스레드 모델에 비해 컨텍스트 스위칭 부하가 작음

12. 이벤트 기반 서버 모델
• 서비스는 FSM(finite state machine)로 구성되고, 최소한의 스레드를 생성하
여 각 이벤트를 연속해서 처리
– 모든 이벤트가 블럭킹 없이 수행될 경우 이상적인 스레드의 수는 코어 + 1
– 스레드 모델 보다 프로그래밍의 복잡도가 증가
– EX) 이벤트 기반 웹 서버: Nginx

13. 이벤트 기반 서버 모델의 이슈
• 코드의 모듈화가 어려움
• 이벤트의 순서 제어가 어려움
• 블럭킹 작업을 최소화 해야 함
– 스레드를 사용하여 이벤트 처리 간의 블럭킹을 최소화
• 스케쥴러의 이벤트 큐가 풀이 될 경우 오류 발생

14. 이벤트 기반 모델의 부하 관리
• 트래픽이 급증하는 상황에서도 안정적인 서비스가 가능
– 적은 수의 스레드가 순차적으로 이벤트 처리
– 이벤트 큐의 크기에 의해 동시에 받아 들일 수 있는 요청 수가 결정

15. STAGED EVENT DRIVEN
ARCHITECTURE

16. Overview
• 스레드 + 이벤트 기반 모델
– http://www.eecs.harvard.edu/~mdw/proj/seda/
• 이벤트 기반 Stage의 네트워크로 구성
– 각각의 Stage는 서로 독립적으로 구성

17. Goals
• 효과적인 이벤트 기반 동시성 제공
• 동적인 스레드 풀 관리
• 코드 모듈화를 위한 구조화된 큐 관리
• 자동화된 부하 관리
• 자동화된 리소스 관리

18. Stage 란?
• Stage는 이벤트 핸들러, 큐, 스레드 풀, 컨트롤러로 구성
• 이벤트는 스레드에 의해 처리됨
– 큐에 있는 이벤트를 처리하고 결과를 다음 Stage의 큐로 전달
• Stage의 동작은 컨트롤러에 의해 제어됨

19. 부하 관리
• 시스템 전체 부화 관리  Stage 별 부하 관리
• Stage 상태 모니터링을 통한 부하 관리
– 스레드 수의 조절
– 상태에 따른 처리 동작을 변경
• Ex) 진입 제어…

20. 특징
• Stage 별 부하 관리가 가능
• 배치 작업이 쉽다
• 모듈화가 용이
– 이벤트 기반 모델에 비해 개발이 용이
– Stage별 분산 처리가 가능

21. 이 슈
• 의존성이 있는 작업
• Stage별 효율적인 스레드 수 할당
• 효율적인 Stage 분할
• 2007년 성능 문제가 제기되어 더 이상 연구가 중지된 상태
– But, 성능 보다 부하 관리와 개발의 용이성에 초점을 맞춘 구조

22. 적용 사례
• Dynamo
– Amazon’s Key-value 기반 NoSQL 서버
– 리퀘스트를 SEDA의 Stage와 유사한 이벤트 파이프라인으로 구성
• Cassandra
– 컬럼 기반 NoSQL 서버
– 페이스 북에 의해 개발, 2008년 오프 소스로 공개
– Read, Mutation, Gossip, Response, Load Balancer …

23. 결론
• 스레드 기반 모델
– 개발이 용이하지만, 오버헤드가 큼
• 이벤트 기반 모델
– 성능이 뛰어나지만, 프로그램의 복잡성이 높음
• Staged Event Driven Architecture
– 스레드 + 이벤트 기반 모델
– 효율적인 부하 관리가 가능: Stage 단위 관리

24. Q&A