안정적인 서비스 운영 2014.03

안정적인 서비스 운영
설계에서 모니터링까지
cybaek.com
2015.02-rev4

스케일링
“Replacing all components of a car
while driving it at 100mph”
- Instagram

서버 한 대에서 시작
웹과 디비를 한 대에서 운영
| 쉽게 시작할 수 있지만,
| 원만한 운영 어려움
웹, 디비

두 대의 서버
웹 서버 1대, 디비 서버 1대
| SPOF: 웹, 디비 뭐든 하나만 죽으면
웹
디비
W W W
R R R
R R R

세 대의 서버
웹 서버를 2대로 늘려서
웹
디비
웹
W W W
R R R
R R R

세 대의 서버
로드밸런싱
| 두 서버에 트래픽을 ‘분배’
웹 웹
분배기
웹 웹
분배기

세 대의 서버
고가용성
| 디비 구성의 예
장애 시에 대기 서버를 활용
트래픽을 분배하지는 않음
액티브 스탠바이
클라이언트
액티브 스탠바이
클라이언트

세 대의 서버
로드밸런싱과 고가용성
| 가장 흔한 것이 L4
L7 헬스체크
| HAProxy
http://
helloworld.naver.com/
helloworld/284659
웹
디비
웹
L4
W W W
R R R
R R R

세 대의 서버
| DNS RR을 이용
웹
디비
웹
DNS
W W W
R R R
R R R

세 대의 서버
| 세션 공유
로그인 정보 등을 공유해야함
쿠키를 이용할 수도
.데이터 양에 제한 웹
디비
웹
L4
세션
W W W
R R R
R R R

웹
디비
웹
L4
세션
W W W
R R R
R R R
| 웹 서버 로컬 디스크에 공유 정보를 저장할 수 없음
구글 앱엔진과 같은 자동 스케일링을 해주는 인프라의
중요 제한 사항
세 대의 서버

세 대의 서버
| 두 서버간 컨텐트를 공유하려면,
DB
NAS/NFS
memcached, Redis,
nBaseArc
웹
디비
웹
L4
세션
공유 데이터
W W W
R R R
R R R

L4에 대해 조금만 더
DSR(Direct Server Return) 모드
| L4가 양방향 프락시라면
모든 웹 서버가 받는 트래픽을  
L4가 다 받아야함
웹
디비
웹
L4
세션
공유 데이터
W W W
R R R
R R R

웹
디비
웹
L4
세션
공유 데이터
W W W
R R R
R R R
| 적당한 예
요청 패킷이 적은 케이스
.일반적인 웹 요청
.파일 다운로드

웹
디비
웹
L4
세션
공유 데이터
W W W
R R R
R R R
| 적합하지 않은 예
요청 패킷이 많은 케이스
.파일 업로드와 같은 웹 요청
업로드 할 때는 L4를 거치지 않도록 예외처리
.SMTP

대용량 파일 업로드
| 두 단계로 나눠 동작
웹 #1 웹 #2
L4
1.
GET http://L4-IP/who
2.
web-1 public IP
3.
POST http://web-1/upload
웹 #3

네 대의 서버
디비 서버를 한 대 더
| 마스터/슬레이브
웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
W W W
R R
R
W W W
R
R R

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
W W W
R R
R
W W W
R
R R
쓰기는 마스터에, 읽기는 두 대 모두에서
| 읽기 처리는 두 배로 증가 ;-)
| 써야할 양도 두 배로 증가 :-(
슬레이브 복제 트래픽
네 대의 서버

디비를 계속 증설
마스터는 하나, 슬레이브는 +1...
웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
W W W
R
R
W W W
R
R
W W W
R
R

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
W W W
R
R
W W W
R
R
W W W
R
R
읽기 부하는 분산이 되나
복제 시간은 점점 늘어남
| 복제본이 늘어나 안정적이지만 낭비가 큼
| 복제 지연은 생각보다 심각
데이터 싱크 문제로 인해
정말 읽은 것이 맞는지 재차 확인하는 로직으로, 필요
이상의 조회 부하 발생
디비를 계속 증설

클러스터링
| 데이터를 자동으로 분산 저장
| 노드간 재균형 작업
샤딩
| 데이터를 수동으로 분산 저장
| 분할된 데이터는 서로 연관관계가 없음
클러스터링과 샤딩

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
W W W
R
R
W W W
R
R
W W W
R
R
데이터를 특정 속성 중심으로 물리적 분할
| 분할된 데이터는 서로 조인을 하거나 참조가 발생해
서는 안 됨
| 보통 userId, blogId, boardId 등을 사용
디비 파티셔닝/샤딩

| 예, 메일
디비
To
cybaek
milk012
cybaek
From
steve
bill
jonny
Subject
아이패드 어때?
주말에 시간 있나요?
[요청] 디자인 좀 봐줘요.
cybaek milk012
웹웹

| 사용자(군)별로 데이터를 분리
디비
To
cybaek
milk012
cybaek
From
steve
bill
jonny
Subject
cybaek milk012
웹웹
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
To
milk012
From
bill
Subject
웹웹

| 테이블 분리를 디비 분리까지
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
디비
To
milk012
From
bill
Subject
웹 웹

| 어떤 디비를 봐야할지 판단해야함
사용자별
디비 위치
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
디비
To
milk012
From
bill
Subject
세
웹

사용자별
디비 위치
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
디비
To
milk012
From
bill
Subject
세
웹
| 어떤 디비를 봐야할지 판단해야함
매핑 디비 서버
.데이터 이동이 유연하지만, 별도 서버 운영 필요
해쉬 함수 이용
.별도 서버 없이 찾을 수 있으나, 데이터 분할 시 많은 데
이터를 이동해야할 수 있음

셀 아키텍처
| 웹과 디비 서버를 함께 사용자(군)별로 분리할 수도
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
디비
To
milk012
From
bill
Subject
웹 웹

셀 아키텍처
| 웹, 디비 서버 이중화
cybaek milk012
세
웹
웹
웹
웹
디비
cybaek 웹
디비
milk012

셀 아키텍처
| 사용자(군)별 어느 디비에 있는지 정보 보관
cybaek milk012
세
웹
웹
웹
웹
디비
cybaek 웹
디비
milk012
cybaek milk012
웹
웹
웹
웹
웹
디비
cybaek 웹
디비
milk012
웹
사용자별
디비 위치

셀 아키텍처
| 셀(Cell)!
cybaek milk012
웹
웹
웹
웹
웹
디비
cybaek 웹
디비
milk012
웹
셀 디비
셀 셀

셀 아키텍처
웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
셀 디비
| 분할된 데이터가 어디에 속하는지 참조
전체 사용자가 공통으로 참조
셀 디비, 로케이션 디비, 유저 디스커버리 서비스 등등
의 용어 사용
셀 아키텍처

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
장점
| 셀 단위 스케일링
| 장애를 특정 셀로 고립 가능
| 프론트+백엔드 점진적 배포
일부 웹 서버만 선적용하는 것은 흔하고 쉽지만
디비가 변경되었을 때, 일부 웹 서버만 적용하는 것은
쉽지 않지만, 셀 아키텍처에서는 가능
셀 아키텍처

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
단점
| SPOF: 셀!
가장 심각한 문제
하지만 거의 정적인 데이터
| 많은 장비 필요
| 제공하는 기능에 따라 셀간 데이터를 조합해야할 수
도
예, 페이스북의 현 계정 친구 정보를 스트림에 추가
셀 아키텍처

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
워드프레스
| 2^n개의 버켓(샤드)을 마련
가상의 버켓을 미리 많이 만들어 두고, 물리 버켓을 매
핑
| 하나의 서버에서 운영하다가 용량이 차면 2대로 분
할
또 차면 또 분할
셀 아키텍처

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
메일
| 웹 인터페이스
HTTP 리다이렉트를 이용하여 속한 셀로 전환 가능
| IMAP, POP3
프로토콜상 어느 셀에서나 모든 사용자 서비스 가능해
야함
셀 아키텍처

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
몇 개의 셀이 적당
| 최소 2개
50:50? 10:90?!
.50:50 등분하면 점진적 배포를 적극 활용하기 어려움
위험이 있는 배포를 조금 선 배포하지 못하고 절반에 적용하
게 됨
.10:90과 같이 특정 셀을 작게 가져가면 점진적 배포에
유리
| 5개? 10개?
정책!
셀 아키텍처

웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
IDC 분할
| 그렇게까지?
| 4개라면 IDC별 2개씩? 혹은 1개, 3개?
역시 정책!
셀 아키텍처

디비 샤딩
Service
DB #1 DB #2
1. 기존과 동일하게 서비스에 접속
http://mail.com/2. 해당 데이터가 어느 디비에
속해 있는지 질의
3. 속한 디비에 질의
Location Service
DB #1 DB #2
1. 기존과 동일하게 서비스에 접속
http://mail.com/2. 해당 데이터가 어느 디비에
속해 있는지 계산
3. 속한 디비에 질의

셀 아키텍처
Cell #1
Service
(샤딩한) 디비
Location
Cell #2
Service
(샤딩한) 디비
IntroService
1. 비로그인 상태에서 접속
http://mail.com/
2. 로그인 후 접속을 받음
3. 어떤 셀에 속한지 물어봄
5. 해당 셀로 접속
http://cell1.mail.com/
4. 어디로 redirect 할지 돌려줌

스토리지 스케일링
분산파일시스템
| 복제본 수를 일률적으로 적용할 필요가 없음
요청이 많은 파일은 복제수 늘리고
보존 시한이 얼마 남지 않은 파일은 복제수 줄이고
| 중복 파일 처리
그냥 둘 것인가
줄일 것인가

스토리지 스케일링
사용성에 따라
| 단위 디스크 크기와 서버의 디스크 베이 갯수
파일을 쌓아두기만 하는 아카이빙 용도인지
.용량이 큰 디스크를
거의 전 파일에 거쳐 IO가 발생하는지
.빠른 디스크(혹은 SSD)를 많이 꽂아서
최근 파일만 주로 사용하는지
.최근 파일은 작은 디스크(혹은 SSD)로 구성한 서버를
사용하고
.시간이 지난 파일은 용량이 큰 서버로 이전

장비가 늘면서 생각할 고민들
빠른 배포
| 배포가 번거로운 일이 되면 안됨
페이스북
.BitTorrent 이용
.사이트 업데이트에 15~30분 소요
.마이너 업데이트는 매일
.메이저 업데이트는 매주 한 번

빠른 롤백
| 빠른 배포보다 중요!
| 롤백 기준 사전 정의 필수
배포 장애시 우왕좌왕하면 안됨
즉각 해결을 못한다면 미련없이 롤백
.“10분이면 고칠 것 같아요”이런 말 믿지 말 것!
| 배포 전에, 롤백 때 필요한 작업 미리 준비
롤백 결정 후, 이런 저런 스크립트 만들면 때는 늦음
엔터 한 번으로 롤백이 되도록

설정 관리
| 모든 장비의 설정 내용이 같은가
설정 값을 바꿔가며 테스트 한 다음 그대로 방치하는
경우가 있음
| 배포
바이너리 배포 시 함께?
설정은 따로 리포지토리 관리?

속도
두 배 빨라진다면
| 50% 하드웨어로 커버

속도 개선
제일 첫 번째 작업은 프로파일링
| 절대로 감에 의존하지 말 것
| 어디가 느린지 파악하는 것이 우선

속도 개선
해결책
| 캐쉬: memcached, Redis, nBaseArc …
각 레이어별 적용 가능
.디비에서, WAS에서, 웹 서버에서 각각 캐쉬 가능
저장 방식
.사용할 결과를 그대로 저장하거나
빠르나 많은 메모리
.구조화하여 저장하거나
조금 느리지만 보다 효율적인 메모리 사용

속도 개선
해결책
| 캐쉬: 지역성!을 고려해서 설계
시간적 지역성
.한번 읽은 데이터를 곧 다시 읽을 수 있다.
.LRU
공간적 지역성
.읽은 곳 근처의 데이터를 접근하는 경우가 있다.
.프리페치(prefetch)

속도 개선
해결책
| 증설
사용자가 늘었거나, 기능이 추가되어서 정말 증설이 필
요할 수도 있음
증설은 죄가 아님

속도 개선
해결책
| 정책변경
예, 조회 수가 꼭 정확해야하나?
.공유 저장소(memcached)에 기록하되, 일정 시간마다
디비에 기록
.디비에 기록하기 전에 저장소가 비정상 종료된다면 일
부 조회수는 유실
이런 것을 정책으로 허용하느냐 마냐에 따라 구조가 달라짐
.디비 기록 주기가 1분이고, 분당 1,000번 조회를 할 경
우, 정책과 약간의 코드만으로 디비 UPDATE를 분당
1,000회에서 단 1회로 줄일 수 있음

속도 개선
해결책
| 정책변경
조회 수 캐쉬(Write back)
번호
1023
글쓴이
cybaek
제목
steve가 보고 싶어요…
조회수
56
Key
1023
디비에 기록한 시각
2014/04/30 09:05:34
조회수
56
Value
1023번 글을 읽음
1023 cybaek steve가 보고 싶어요… 561023 2014/04/30 09:05:34 571분 뒤에 다시 읽음
지금 - 09:05:34 > 5분 초과?
캐쉬 디비
지금 - 09:05:34 > 5분 초과?
지금 - 09:05:34 > 5분 초과!

속도 개선
해결책
| 정책변경
WWDC, GoogleIO 티켓 구매
.최근 몇 년 초단시간에 매진을 기록
.하지만 사이트는 먹통
.결국, 추첨해서 티켓 구매 기회를 주는 것으로 변경

스토리지 속도
메모리
디스크 개수
| 1T x 1 vs 100G x 10
RAID 컨트롤러
| 정책
배터리 충전 중에는 디스크에 바로 쓰기(Battery
Backup Write Cache)
.전원 공급이 갑자기 끊길 때 쓰기 유실을 최소화 하기
위한 드라이버 정책(조정 가능)
.하지만 이로 인해 디비 같은 경우 서비스 품질이 급락

품질 관리
웹, WAS
| 각 URI별 응답속도 관리
평균과 표준편차 같이 관리
| 구간별 처리 속도 관리
주요 기능의 경우, URI 하나의 응답 속도를 더 쪼개서
내부 로직별 처리 속도를 기록

품질 관리
read list write
search delete

운영
서비스 오픈은 끝이 아니라 시작.
- ?

메일 발송
생각보다 관리할 것이 많음
| 한 통 발송은 쉽지만,
책 예제 따라하면 됨
| 다량 발송은 손이 많이 감
코드의 문제가 아니라 운영 문제
.KISA 화이트IP 등록
.(업계가 21세기답게 돌아가지는 않음…)

자동화
신규 서버 설치
| 장비를 받아, 10분 내에 설치할 수 있도록
| 방화벽 오픈 등이 빠른 대응에 걸림돌
애당초 C클래스 단위로 관리
일상적인 응용 배포
자동 복구
| 장애 시 루틴하게 하는 작업
예, 프로세스 재구동 등을 특정 조건일 때 자동으로 수
행하도록

배치 작업
필요한 기본 인프라
| 실패시 알림
| 과거 작업 이력 조회
| 여러 서버 묶어서 실행

로그 처리
수집
| 주기는?
실시간
.Scribe: https://github.com/facebook/scribe
시간 단위

백업
어떤 전략으로
| 주기는?
| 전체? 증분?
어떻게 복구
| 복구에 얼마나 걸리나
| 복구하는 동안 서비스는 유지? 정지? 읽기만?

로그 처리
보관
| 얼마나 오랫동안 보관해야하나
정책의 문제
조회
| 얼마나 많은 범위의 데이터를, 얼마나 빠르게
잘 구축하면 고객문의 처리를 비개발자에게 이관 가능
보안
| 개인 정보 저장하지 않도록

품질 관리
백엔드 서버간 처리
| 각 서버 구간별 처리 속도 관리
한 요청이 여러 서버를 활용할 때, 각 서버별 응답 속도
관리
.PINPOINT: https://github.com/naver/pinpoint

품질 관리
디비
| DBA의 검수 필수
| 동적 쿼리를 없애도록
1개의 동적 쿼리는 생각보다 적은 N개의 정적 쿼리로
변경 가능
.쿼리 관리가 용이해지고
.각 정적 쿼리마다 힌트를 정확하게 줄 수 있음
| 슬로우 쿼리 자동 검출

모니터링
경고와 장애 수준 분리
| 대부분 장애 수준이 되고 나서야 알람을 받음
디스크 사용률 90%일 때 알람
.“이제 장애 납니다”라는 문자 받는 것
.평상 시 사용률 20%를 유지하고 있다면, 90%가 아니라
50% 수준에서 경고 알람을 받아야함

모니터링
최저 값 모니터링
| 보통 데몬 개수가 N개를 넘을 때만 알람을 받음
데몬이 죽었다면 알람 안 옴
주기적으로 수치 점검
| 시스템의 기능과 사용자 수는 계속 변함
경고, 장애, 최저 값 세 수치는 주기적으로 리뷰해야함

모니터링
테스트 활용하여 기능 체크
| 사용자 인터페이스 레벨의 테스트 모듈을 주기적으
로 돌려, 서비스 상태 체크 
 
무의미한 알람 받지 않도록
| 무시해도 되는 알람이라면 받지 않도록 설정
그런 알람 속에 진짜 경고 메시지가 묻힐 수 있음

모니터링
연동 서비스/서버 모니터링
| 외부 API를 이용할 경우, 해당 API를 직접 체크
연동 서비스쪽 원인으로 발생한 장애를 빠르게 검출할
수 있음
.연동 서비스의 응답 속도는 담당 서비스의 품질에도 영
향을 줌
내가 직접 관리하는 서비스가 아니라고 방치해서는 안 됨

시스템 유틸리티
필수
| vmstat, mpstat, iostat, netstat, free, top, sar,
ping

HTTP 에러 페이지 설정
50x
| 사용자들은 무의식적으로 새로 고침을 반복
별도 (정적) 서버로 리다이렉트 하도록 설정

흔한 장애
로그
| DEBUG 레벨의 로깅
예, 로그를 껐더니 속도가 10배 향상
| 에러 로그를 안 봐서 키우는 장애
에러 로그 크기는 0이 정상
‘괜찮은 에러’는 에러가 아니니 에러 로그에 남기지
말 것

흔한 장애
타임아웃
| 디폴트 값 사용 주의
보통 디폴트가 얼마인지도 모르고 사용
보통 10ms로 응답할 때, 응답이 1초 지연되면 동시 접
속수는 100배가 됨
| 평균 응답 속도에 상응하는 타임아웃 설정
보통 5ms 이하로 응답할 때, 타임아웃이 2초가 적당?
| 단위 확인 필요
예, ms인 줄 알고 1000이라고 넘겼는데... sec

흔한 장애
트래픽
| 한 달 전부터 늘고 있었는데
에러 핸들링
| 소스코드에서 return 값 제대로 확인하지 않고

흔한 장애
파일/디스크 관련
| 디스크 가용량이 부족하거나
지우지 않고 쌓인 로그
| inode가 부족하거나
작은 파일을 많이 저장하고 있을 때
| FD_MAX가 작거나
ulimit -n

흔한 장애
L4
| L4를 적용했는데도, 정상 동작하지 않는 서버로 계
속 요청이 가는 경우
HTTP라면 L7 헬스 체크 적용

흔한 장애
디비
| 갑자기 쿼리의 실행 계획이 바뀌어 슬로우 쿼리 발
생
쿼리에 힌트를 주어 실행 계획을 고정
.동적으로 문자열을 만들어 쿼리를 생성할 경우 힌트 주
기가 어려움
동적 쿼리를 다수의 정적 쿼리로!
| 통계 쿼리
캐쉬 메모리가 지역성이 떨어지는 데이터로 채워져 성
능 저하 초래

대규모 장애 대응
중요 기능 우선
| 서비스 기능을 중요도로 정렬
.게시판: 읽기 > 쓰기 > 검색
.메일: 수신/읽기 > 목록 > ... > 쓰기 > ... > 검색 > 색인
.검색: 통합검색 > ... > ... > 색인
| 장애 시 중요 기능을 보호하는 대응
우선 순위 떨어지는 기능을 포기하여 상위 기능을 개선
.미들웨어에서 호출 컴포넌트 정보를 받아, 비중요 컴포
넌트로 부터의 호출을 실패 처리

대규모 장애 대응
기타
| 캐쉬 만료 기간 연장
캐쉬를 2분간 보관한다면 임시로 10분 등으로 연장
.백엔드 호출이 그만큼 줄어들게 됨
| 색인 갱신 중단
색인 작업은 전반적인 데이터 패치를 수반
이를 잠시 멈춰, 내부 트래픽과 미들웨어 호출량을 줄
일 수 있음
| 서비스 마다 특성이 있음
고민! 고민! 고민!

장애 대응
전파
| 메일링 리스트를 이용하여 유관자에게 전파
처리
| Case By Case
에러 로그
롤백이 가능하면 롤백 우선
에러의 원인이 내 서비스가 아닌 연관 API 서버에 있을
수도

장애 후 대응
회고
| 해당 장애를 사용자가 인지하기 전에 미리 알 수는
없었는지
미리 알 수 있는 방법을 찾아내면 모니터링 항목으로
등록
| 장애 원인을 아는데 왜 오래 걸렸는지, 자동으로 알
수는 없었는지
자동으로 알 수 있게 됐다면 스크립트화
.해당 스크립트 묶음을 장애 시 활용하면 원인 진단을 빠
르게 할 수 있음

http://www.slideshare.net/cybaek/201403

안정적인 서비스 운영 2014.03

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 안정적인 서비스 운영 2014.03

Similaire à 안정적인 서비스 운영 2014.03 (20)

안정적인 서비스 운영 2014.03