서버 만들기 charsyam@naver.com

대용량 고속 서버?

WARNING! • 해당 문서의 내용은 다음과 같은 사이트에서 얻은 내용입니다.

– http://pl.atyp.us/content/tech/servers.html

– http://www.powerbox.pe.kr/312

TIP VS Baseline

첫번째 경기는 39점

두번째 경기는 95점

욲빨!

TIP을 알면 점수가 오를 수 있지만, BaseLine 이 없으면 기복이 심해지고,

진짜 실력이 아니다!

여기는 BaseLine

서버 만들기의 BaseLine

• 모든 근본은 소프트웨어 개발의 근본! • 소프트웨어 개발의 5대 원칙

– SRP(단일 책임 법칙) • 클래스가 하나의 책임만 가진다. 변경되는 이유가 하나의 책임과 연관된다.

– OCP(개방 폐쇄 법칙) • 기능을 추가하기는 쉽게!, 기존 기능을 변경하게 만드는 것은 어렵게.

– LSP(리스코프 치홖 법칙) • 하위 타입은 그것의 Base Type 에 대해서 치홖 가능해야 한다.

– ISP(인터페이스 격리 법칙) • 자신이 필요한 인터페이스만 존재

– DIP(의존 관계 역젂 법칙) • 상위 모듈이 하위 모듈에 의존하지 않도록 Concrete Class 대신에 Interface를 써라!

서버 만들기의 BaseLine 2

• Pattern?

– 우리가 POSA2를 공부하려는 이유

– POSA2는 ACE의 구조다!

– 결국 변하는 부분과 그렇지 않은 부분의 분리

서버 모델

• 서버 모델이 뭐예요?

– 서버의 목적과, 성능, 안젂성 등의 요구사항에 따라 달라집니다.

threading Model?

• Single Process Model

• Multi Process Model

– Preforked Model

– Dynamic

• Multi Thread Model

– Preforked Model

– Dynamic

Server Model?

• 의사소통의 수단으로 사용합니다.

• Worker Crew Model

– 하나의 작업을 나눠서 여려명이서!!!, 계산 작업?

• Boss/Worker Model

– Channel(Queue)

– Producer-Consumer

• Consumer 가 하나면 Pipeline Model

• Consumer 가 여러 개면 Boss/Worker

Reactor/Proactor 모델은요?

• 가장 많이 듣는 이야기!

– 주로 앞단에서 Event Handling 을 위한 구조

– 목적에 따라서 여러가지 패턴이 조합될 수 있다.

• 특정 패턴이 모든 것을 얘기하지 않습니다.

다시 Server 모델

Reactor EH EH

Processor Processor

다시 Server 모델

Reactor

ITEM

ITEM

ITEM

ITEM

Worker Worker Worker Worker

Worker EH EH

Reactor EH EH

Processor Processor

Server Pattern With POSA2

• Event Handling Patterns – Reactor

– Proactor

– Asynchronous Completion Token

– Acceptor-Connector

• Concurrency Patterns – Active Object

– Monitor Object

– Half-Sync/Half-Async

– Reader-Followers

간략한 ACE 소개

• POSA2 저자가 만들었어요.

• OPEN SOURCE

여기부터는 TIP

서버 만들기의 TIP

• Data Copies

• Context Switches

• Memory Allocation

• Lock Contention

Data Copies

• Data Copy가 많을 수록 괜히 CPU를 낭비하게 된다.

• 그럼 어떻게?

– Socket Zero Buffer?(효과는 미비?)

– 최소한의 데이터 복사만 일어나도록 사용

Context Switches

• Thread는 Light Weight Process?

• 그러나 Thread의 Context Switch 가 자주 일어나면 점점 성능은 떨어진다.

• 2n+1 등의 공식이 있지만, 실제로는 해당 수치는 테스트로 검증해야 한다.

Memory Allocation

• 메모리 Pool을 이용하는 것이 좋다.

• 아니면 미리 할당, 한방에 필요한 만큼 모두 할당 한다.

• 자주 할당하는 것을 피하는 것이 좋다.

Lock Contention

• Lock이 빈번하면 속도가 느리다.

• 그러나 안정성을 위해서 필요

• 최대한 락이 필요없는 구조로 설계

• 하지만 필요하다면 써야한다.

• Lock-Free, Wait-Free 방식도 알아보자

서버 만들기의 TIP 2 - 1

• Just Network, Memory, CPU

– HDD is slow!( Not use Slow I/O )

– HDD -> SSD

• Thread and Process Count

– 적젃한 비율은 실험으로 발견

• Use Resource POOL

• Use Cache( Be Higher Cache Hit )

• Use Compression( Low CPU Using and High Memory Use)

놓치기 쉬운 것들! 그리고 개발자들이 잘 신경 쓰지 않는 것들!

코드가 전부는 아니다.

• 서버의 물리적 구조

• 얼마 만큼의 트래픽이 발생할 까?

– 스위치의 밴드위스?

• 당신의 서버에 사용자가 많다면 스위치가 못버틸 수도 있다.

– 안정성(스위치, 라우터 2중화)

– FailOver 는 어떻게?

물리적 Deploy: 장애에 대한 이중화

외부 인터넷

ROUTE ROUTE

Switch Switch

Server Server Server Server

적절한 로그가 필요하다.

• 버그를 확인하기 위해서!!!

• 더욱 더 중요한!!!

– 사용자의 요청 처리용!!!(많은 정보가 필요하다)

• Log4j 등과 같은 툴의 이용

– Log4plus, Log4cxx, Log4cpp

적절한 로그가 필요하다.

• [2010/11/20 08:30:12] 127.0.0.1 charsyam LOGIN

• [2010/11/20 08:30:13] 127.0.0.1 charsyam GET_ITEM SWORD 100

• [2010/11/20 08:30:15] 127.0.0.1 charsyam GET_ITEM GOLD 100

• [2010/11/20 08:32:12] 127.0.0.1 charsyam CHANGE_ITEM jinuki79 SWORD 100 GOLD 2000

• [2010/11/20 08:35:12] 127.0.0.1 charsyam LOGOUT

• 너무 많으면 중요한 작업이라도 꼭 남겨야 합니다.(이건 기획과 협의)