스마트폰이 대중화되기 직전까지 KT이동통신(KTF)의 모든 단말기가 인터넷 콘텐트 접속시에 거쳐가는 Web Proxy (PAS라 불림)를 바닥부터 새로 개발한 개발 기록. multi thread 기반으로 동작. 한 thread에서 여러 단말(client)처리. Multi-connection per thread. ACE framework사용. Reactor패턴 사용. 부하(동시접속 단말 개수)에 따라 reactor thread 개수를 동적으로 자동 조절하는 pool 방식 구현. 설계를 다시하고 밑바닥부터 새로 만듦. 200TPS 의 기존 성능을 1,000 TPS 로 올림. 5~6번의 deploy 작업 끝에 memory leak 문제 등 모든 문제 해결하고, 30일 넘게 운영해도 죽지 않는 서버로 구현함. 2006년.

1. 1
표지
PAS 고도화 소개
(PAS2006)
2006.11.30

2. 2
I-1. 개요
I. 개요
• PAS 대용량 컨텐츠 전송을 위한 구조 고도화• PAS 대용량 컨텐츠 전송을 위한 구조 고도화프로젝트명프로젝트명
• 2006. 04. 14 ~ 2006. 11. 15 ( 총 7 개월 )• 2006. 04. 14 ~ 2006. 11. 15 ( 총 7 개월 )기간기간
• PAS 에서 대용량의 컨텐츠 전송을 위한 구조 및 품질 개선• PAS 에서 대용량의 컨텐츠 전송을 위한 구조 및 품질 개선목적목적
• 성능 및 구조 고도화
• Thread 구조 개선
• Memory 구조 개선
• 처리 성능 향상
• 차세대 브라우저 지원 (KUN 3.0)
• 바이너리 파일 업로드
• 대용량 컨텐츠 다운로드
• 파이프라이닝 지원
• 멀티 소켓 지원
• 품질 개선
• 공지 처리 기능 개선
• 오류 상황 감지 개선
• 오류 코드 분류 개선
• 성능 및 구조 고도화
• Thread 구조 개선
• Memory 구조 개선
• 처리 성능 향상
• 차세대 브라우저 지원 (KUN 3.0)
• 바이너리 파일 업로드
• 대용량 컨텐츠 다운로드
• 파이프라이닝 지원
• 멀티 소켓 지원
• 품질 개선
• 공지 처리 기능 개선
• 오류 상황 감지 개선
• 오류 코드 분류 개선
구축 범위구축 범위

3. 3
I-2. 고도화 결과 개요
I. 개요
신규 기존
C++ library Standard library 사용 RogueWave library 사용
Thread
Thread pool 방식
한 쓰레드가 여러 단말을 처리
쓰레드 수 : CPU 개수 x 2 정도
Thread-per-connection
한 쓰레드가 동시에 하나의 단말 처리
쓰레드 수 : 접속 단말 개수에 비례하여 가변
메모리
메모리 pool 사용
메모리 블락 크기 가변적 .
고정된 메모리 블락 크기 (500K)
성능
최대 1,000 TPS
오류 0% (180 TPS 부하에서 )
최대 200 TPS
오류 1% (180 TPS 부하에서 )
대용량 콘텐츠 대용량 콘텐츠 처리 가능 X
KUN 3.0 지원
멀티소켓 지원
파이프라이닝 지원
바이너리 파일 업로드
X
접속 / 통계 / 과금
로그 출력
실시간 출력
SSL 로그 출력 개선
한 transaction 씩 지연 .
마지막 transaction 의 로그는 20 분 후 출력
공지 처리
오류 감지 주기 단축 (10 초 )
공지 적용 주기 단축 (10 초 )
단말 번호별 공지 처리 가능
5 분 ~10 분
5 분 ~10 분
X
디버그 로깅
디버그 레벨 4 단계 지원
실행 중 디버그 레벨 조절 가능
컨피그 파일에 레벨 설정 가능
FILE/STDERR 출력 가능
소스 컴파일을 통해 디버깅 가능
STDERR 출력
디버그 레벨 없음
단말별 로깅 특정 번호에 대한 디버그 로깅만 별도 파일로 출력 . X
시스템정보 로깅
초당 접속 수 , 초당 transaction 개수 , 등의 정보를
파일에 출력 .
X

4. 4
II-2. 프로젝트의 필요성
기존의 무선인터넷 Proxy 서버는 대용량 KUN 컨텐츠의 전송이 어려운 구조이며 , CP 서비스의 증가에 대처하
기 힘든 비효율적인 감시도구로 인해 , 모니터링에 한계가 있고 오류의 신속한 파악 및 대처가 어려운 상황이다 .
• 대용량 KUN 컨텐츠 다운로드가 어려운 구조
(500KB 가 한계 ) 및 업로드 불가
• 단말과 Thread 의 1:1 매치 및 고정 Memory
할당으로 인해 비효율적인 서버 자원 사용 문제
• 파이프라이닝 미지원 및 단일 소켓 구조로 비효
율적인 네트웍 자원 사용 문제
• 오류 감지 주기가 길어 신속한 문제 대응 어려움
• 응답 지연 및 오류 코드의 단순한 처리로 인해
오류 유형의 신속한 판단이 어려움
• 오류 발생 시 URL/DOMAIN 만 차단 가능
• 관리자 페이지 및 모니터링 Tool 에 대한 유지
보수 부재로 신규 기능 추가 어려움
• 대용량 KUN 컨텐츠 다운로드가 가능하며 , 바이
너리 파일 업로드 기능 제공
• 한 Thread 에서 여러 요청 처리 및 Memory Pool
사용으로 효율적인 서버 자원 관리 가능
• 파이프라이닝 및 멀티 소켓 지원으로 효율적인 네
트웍 자원 운용 가능
• 실시간 오류 감지 기능 및 개인별 Noti 기능 제
공
• 응답 지연 및 오류 코드 분류 개선으로 신속한
오류 진단 가능
• 오류 발생 시 단말 번호로도 차단 가능하도록 구
현
• 관리자 페이지의 지속적인 유지 보수 및 향후 모
니터링 Tool 신규 기능 추가 용이
II. 프로젝트 배경 및 전략
AS-IS TO-BE

5. 5
II-3. 프로젝트 목적
차세대 브라우저 지
원 - KUN 3.0
성능 및 구조
고도화
품질 개선
PAS 시스템의 대용량의 컨텐츠 전송을 위한 구조 및 품질 개선
• Thread 구조 개선
• Memory 구조 개선
무선인터넷 서비스 경쟁력 강화
• 바이너리 파일 업로드
• 대용량 컨텐츠 다운로드
• 파이프라이닝 지원
• 멀티 소켓 지원
본 프로젝트는 PAS 시스템의 대용량 컨텐츠 전송을 위한 구조 및 품질 개선을 통해 , 새로운 서비스 및 무선인터넷
기술 발전에 따른 시스템 진화 전략을 수립함으로써 무선인터넷 서비스 경쟁력을 강화하는 것을 목적으로 합니다 .
II. 프로젝트 배경 및 전략
• 공지 처리 기능 개선
• 오류 상황 감지 개선
• 오류 코드 분류 개선

6. 6
III-1. 시스템 구조
용어
PAS : Portal Access Server
PAS AUTH : PAS인증 G/W
IPLS : IP Location Server
KUNLOG
L4 Switch
UDP
DB
STATBBS
(WEB)
ACL Agent
PAS G/W#1
PAS G/W#6
PASAUTH01
LOGSVR
mIDC 내부mIDC외부
MENU 서버
EMC(NFS)
STATBBS WEB를통한
통계 Operating 및 Traffic monitor
SANTA
MECA
FTP
L4 Switch
PASAUTH02
IPLS
IPLS
IWF/PSDN
Contents
Provider 1
Contents
Provider 2
Contents
Provider n
PASPAS
mIDC외부
PAS(Portal Access Server) 는 무선인터넷 프락시 서버로 인증처리 , 단말 -CP 중계 , 과금 처리 , 통계처리를 담당하
며 , 게이트웨이 (G/W) 서버 , 인증 서버 , 로그 서버 (LOGSVR/KUNLOG) 및 통계 모니터링 서버 (STATBBS) 로 구성
되어 있다 .
III. 프로젝트 수행 내역

7. 7
III-3. 성능 및 구조 고도화
PAS Gateway 의 기능들에 대한 Class 를 먼저 정의하고 , 시스템의 효율화를 위해서 아래와 같이 구현하였다 .
III. 프로젝트 수행 내역
Thread Model : Working Thread, Reactor 등으로 구성
Stat Filter : Statfilter 에 대한 처리 담당
Acl : ACL 처리 담당
SANTA : SANTA 연동
AUTH : PAS_AUTH 연동
Session : 세션 연결 정보 관리
Response : PAS -> Mobile 로 처리
Request : Mobile -> PAS, PAS -> CP 처리
MemAlloc : 메모리 관리
HTTPParser : Request 의 헤더 정보 처리
Etc.
System 구조 개선

8. 8
III-3. 성능 및 구조 고도화
Reactor 내부
Event 발생을 감시하고 .
Event 처리를 담당하는 오브
젝트에 event 를 dispatch
한다 .
Thread 구조 개선
 기존 thread-per-connection 모델에서 thread pool 모델로 변경 .
 Master Thread - Acceptor. 단말의 요청을 받아 Worker 들에게 분배한다 .
 Worker Pool - Reactor. 한 Thread 당 여러 개의 단말을 처리한다 .
 Thread 개수 = CPU 개수 x 2 정도가 적당하다 .
III. 프로젝트 수행 내역

9. 9
III-3. 성능 및 구조 고도화
메모리 구조 개선
 대용량 처리와 시스템의 안정성을 고려하여 자체 메모리 관리 툴을 구현하였다 .
 고정사이즈의 메모리 block 들을 관리하는 메모리 풀을 복수 개 사용하여 구현한다 .
 메모리 할당 크기 (block 크기 ) 는 2 의 N 승으로 증가한다 . ( 예 : 64K -> 128K -> 256K -> 512K
-> ...)
 각 메모리 풀의 block 크기와 최대 block 개수는 config 파일에 설정한다 .
 최대 block 개수를 초과하거나 , 최대 block 크기를 초과하는 경우에는 OS 의 메모리 관리
(new/delete) 를 직접 이용한다 .
III. 프로젝트 수행 내역

10. 10
III-4. 차세대 브라우저 지원
2100 SERVER
단말기
KUN PAS magicn
Myphoto.jpg
단말기에서 전송되면
UpLoad 라는 디렉토리에
생성된다 .
CP 서버로 전송 후 삭제
한다 .
포토앨범 혹은 자료실로
PAS 에서 바이너리 파일
이 전송된다 .
CP Server
바이너리 파일 업로드
 단말기에서 업로드할 파일을 선택한다 .
 <form enctype=multipart/form-data”….> 와 같은 규격으로 데이터를 전송한다 .
(HTML 의 multipart 규격에 의거 전송 , KUN 의 HTML 에서는 규약이 정해져 있지 않음 )
 업로드할 contents 의 크기 만큼 메모리를 할당한다
 전송된 데이터를 마이매직엔의 자료함 혹은 포토앨범 , CP Server 로 자료를 재전송한다 .
III. 프로젝트 수행 내역

11. 11
III-4. 차세대 브라우저 지원
HTTP Pipelining
[ 단말기 ]
R1
R2
[CP1]
[CP2]
R1
A1
R2
A2
[PAS]
A1
A2
TR1
TR2
5 초 소요
1 초 소요
Transaction
Queue
Pipelining 구현
III. 프로젝트 수행 내역
 브라우저에서 연속적으로 request 를 보내고 연속된 response 를 순차적으로 받는 방식을 말한
다 .
 동일 소켓 상에서 수신한 여러 개의 요청들을 순차적으로 처리한다 .
 CP 의 응답 순서에 관계없이 , 단말에서 요청한 순서에 따라 응답을 단말로 송신한다 .
 Transaction Queue 를 이용하여 응답 순서를 보장한다 .

12. 12
III-4. 차세대 브라우저 지원
멀티 소켓
[ 단말기 ]
Connect 1
A1
[PAS]
User & Session
Info
R1
Connect 2
A2
R2
III. 프로젝트 수행 내역
 하나의 단말에서 동시에 여러 개의 소켓을 열어서 PAS 에 연결하고 요청한다 .
 멀티 소켓은 여러 개의 세션이 동시에 한 단말에서 진행되는 것을 의미한다 .

13. 13
III-5. 품질 개선
III. 프로젝트 수행 내역
공지 처리 기능 개선
 공지처리 (stat.cfg) 시에 PAS GW 에 반영되던 주기를 5 분에서 10 초로 단축
 기존에는 도메인 , URL 별로만 공지처리 가능하였으나 , 단말번호별로 공지 처리 가능하도록 개
선

14. 14
III-5. 품질 개선
구 현 Action Item 상 세
Stat Filter
개선
1. 오류 급증 Domain/URL 에 대한 공지 처
리
공지 처리 . 반영 주기 단축
2. 트랙픽 과다 CP 호제어 공지 처리
3. 단말번호별 긴급 공지 처리 단말 번호에 대해 공지 처리 가능하도록
개선
Over10
개선
4. Over10 통계 수집 주기 개선 1 분 단위 over10 통계 수집
6. Over10 오류통계 페이지 개선 URL, 도메인 , 단말 번호별 통계 제공
오류 코드 별 통계 제공
오류 코드
개선
5. 408 오류 코드 세분화 코드 값 정의
8. SSL 통신 호 코드 변경 코드 값 정의
7. 비정상 ( 한글 ) URL 에 대한 공지 처리 비정상 한글 URL 감지 함수 추가
오류 코드 정의
9. CP 연결 실패시 공지 처리 CP 연결 실패에 대한 오류 코드 정의
III. 프로젝트 수행 내역
오류 상황 감지 및 오류 코드 분류 개선

15. 15
III-6. 디버그 로그 강화
로깅 기능의 On/Off 를 컴파일 없이 프로그램 실행 시 결정
로깅 레벨의 분류
여러 쓰레드의 동시 로깅시 순차 처리 보장
로깅 storage 의 유연성
III. 프로젝트 수행 내역
 파일
 SysLog
 Custom Callback
 INFO
 DEBUG
 WARNING
 ERROR

16. 16
III-7. Trace 기능
특정 단말에 대한 로깅
III. 프로젝트 수행 내역
 상용 서비스 중 모든 단말에 대한 로깅은 시스템 부하 가중
 PhoneTrace: 시스템 부하 없이 실시간 로깅 , 디버깅 가능
 로깅 대상 단말 번호를 등록 / 삭제 가능
 단말 번호별로 로그 파일 설정함
 시스템 문제 해결에 도움
 불만 고객의 문제 해결에 도움

17. 17
III-8. 자체 검증 계획
III. 프로젝트 수행 내역
자체 검증 방법
 상용 서비스 되고 있는 기존 PAS 의 단말 /CP Log 의 dump data 를 기반으로 신규 PAS 에서
단말 /CP emulator 를 통해 과금 로그 및 통계 로그를 작성한다 .
 기존 PAS 와 신규 PAS 의 Log 를 Compare Tool 을 활용하여 비교 분석한다 .

18. 18
하드웨어 사양
IV-1. 개발 확인 시험 개요
IV. 개발 확인 시험
개발 확인 시험 개요
 테스트 기간 : 2006. 09. 25 ~ 2006. 10. 20
 테스트 항목 수 : 중분류 36 개 , 총 83 개 항목
 시험 결과 : 기능 테스트 – 전 항목 통과
성능 테스트 – 200tps -> 1000tps
성능 시험 환경
 성능 시험 장소 : SUN BMT 실
 Client : Sun SF6900 (Ultra Sparc IV, 1.5GHz 2CPU, Memory 4G)
 PASGW 서버 : Sun SF6900 (Ultra Sparc IV, 1.5GHz 2CPU-Dual Core, Memory 4G)
 웹 서버 : Sun SF6900 (Ultra Sparc IV, 1.5GHz 4CPU, Memory 32G)
 LAN : 1Gbps ( 실제 테스트 결과 40Mbytes/Second 전송 )

19. 19
IV. 개발 확인 시험
테스트 분류 테스트 항목 테스트 결과 테스트 항목 테스트 결과
HTTP 처리
메뉴 서버 연결 (4) OK 멀티 소켓 (1) OK
다운로드 (3) OK Chunked 데이터 (1) OK
SSL 연결 (3) OK BILL_INFO (1) OK
바이너리 업로드 (2) OK HASHKEY (1) OK
파이프라이닝 (1) OK 기타 항목 (19) OK
라우팅
KUN Multi Proxy (1) OK Hotnumber 라우팅 (4) OK
ACL 라우팅 (6) OK 긴급 공지 (7) OK
인증 PAS_AUTH 연동 (6) OK SANTA 연동 - 가상 번호 (7) OK
과금 및 통
계
과금 로그 (2) OK Over10( 오류 ) 로그 (2) OK
통계 로그 (2) OK SANTA 연동 로그 (2) OK
접속 로그 (2) OK PAS_AUTH 연동 로그 (2) OK
통합 통계 로그 (2) OK Phone Trace 로그 (2) OK
IV-2. 기능 테스트
* 괄호 안은 소분류 항목 개수

20. 20
IV-3. 성능 테스트 – 신구 비교 (500K)
IV. 개발 확인 시험
최대 성능치 : 200TPS -> 1000TPS (TPS: Transaction per Second)
성능 개선 상황

21. 21
IV-3. 성능 테스트 – Working Thread(1,2,4,8)
0
200
400
600
800
1000
1200
1400
1 6 11 16 21 26 31 36 41 46 51 56 61
Thread 1
Thread 2
Thread 4
Thread 8
IV. 개발 확인 시험
테스트 환경 : Sun SF6900(Ultra Sparc IV, 1.5GHz 2CPU Memory 4G)
Thread 개수별 성능 비교

22. 22
V-1. 보안 검증
V. 보안 검증
mIDC TestBed 상용
Solaris 8 Solaris 10 Solaris 8
장비 Sun Fire 480R Sun Ultra 80 Sun Fire 280R
CPU 1.2G * 2 450M * 1 1.2G * 2
Memory 4G 1G 4G (512 * 8)
성능 테스트 환경
성능 테스트 결과 요약
개발 확인 시험 개요
 테스트 기간 : 2006. 10. 23 ~ 2006. 10. 31
 기능 테스트 : 전 항목 통과 (69 개 항목 )
 성능 테스트 : 오류비율 현저히 감소 . TB 실의 HW 및 네트웍 용량 한계로 최대 성능 비교는
어려움 .
 기존에 비해 Error 율 감소 확인
 기존에 비해 성능 향상 확인
 대용량 처리 기능 및 성능 확인
 부하 테스트 및 장기간 운용 테스트 확인

23. 23
V-2. 보안 검증 - 성능 테스트 결과
Old PAS 기본 성능 테스트 : 250 vUser 15 Minutes
구분 결과 비고
전체 운용시간 20 min 02 sec
응답시간 0.237 ~ 0.268 sec ( 개별 transaction )
전체 에러율 1.46 % ( 9,204 / 628,322 )
TPS 173 tps AVE.
203 tps MAX.
Connections 223 conn. AVE.
250 conn. MAX.
V. 보안 검증

24. 24
V-2. 보안 검증 - 성능 테스트 결과
New PAS 기본 성능 테스트 : 250 vUser 15 Minutes
구분 결과 비고
전체 운용시간 19 min 59 sec
응답시간 0.092 ~ 0.268 sec ( 개별 transaction )
전체 에러율 0.00 % ( 0 / 671,273 )
TPS 186 tps AVE.
217 tps MAX.
Connections 226 conn. AVE.
250 conn. MAX.
V. 보안 검증

25. 25
V-2. 보안 검증 - 성능 테스트 결과
New PAS 한계 성능 (1000 tps) 테스트 : 100 ~ 500 vUser 1 Hour 초과
구분 결과 비고
전체 운용시간 1 hour 32 min 36 sec
응답시간 0.581 ~ 0.873 sec AVE.
10.745 ~ 11.333 sec MAX.
전체 에러율 0.01 % ( 633 / 3,647,545 )
TPS 218 tps AVE.
257 tps MAX.
Connections 384 conn. AVE.
500 conn. MAX.
V. 보안 검증

26. 26
VI-1. 기대 효과
VI. 기대 효과
효율적인
진화전략 수립
• 운영 품질 개선을 통한 안정
적 운영
• 디버그 로그 및 Trace 로 문
제 추적 용이
• 통계 및 분석을 이용한 예상
문제 도출 및 해결 가능
기능 및
성능 고도화
안정적
시스템 운영
• 성능 (TPS) 의 향상으로
안정성 확보
• 대용량 컨텐츠 전송 서비
스로 인해 양질의 서비스
이용 가능
• 파이프라이닝 , 멀티 소켓
지원
• 바이너리 업로드 지원
서비스 경쟁력 강화
서비스
만족도 증가
서비스
만족도 증가
• 시스템 구조 및 성능 고도화를
통해 안정성 및 확장성 확보 .
• HTTP 기능 고도화를 통해 서비
스 진화 지원 가능 .
• 새로운 서비스 도입 및 기능 추
가 기간의 단축