대용량 아키텍처와 성능 튜닝 Chapter 6. 대용량서비스레퍼런스아키텍처 part.1 아꿈사 스터디 발표자료

1. [조대협의 서버사이드: 대용량 아키텍처와 성능 튜닝]
Ch6.대용량 서비스 레퍼런스 아키텍쳐
아꿈사
정민철(ccc612@gmail.com)

2. 대용량 서비스 레퍼런스 아키텍쳐

3. 대용량 서비스 레퍼런스 아키텍쳐
• 기반사상 => SOA
• Access Layer
– 외부로 부터 들어오는 사용자 요청에 대해서 관문 역할
– 외부 시스템과의 연동 역할
• Business Layer
– 들어온 사용자 요청에 대해서 비지니스 로직을 처리
– Client에 응답
• Persistent Layer
– Business Logic에 의해 처리되는 또는 처리된 데이타를 저장
• OAM(Operation Administration Monitoring)
– 시스템의 관리 및 운용
• Analysis Layer
– 로그분석

4. Access Layer
• 사용자 API에 대한 End Point
• 웹 캐시
– 정적인 자원(자바스크립트, 이미지, 정적 페이지 등) 캐싱
– 전체 시스템 부하 감소
• Reverse Proxy
– 정적 contents 서비스 제공
– 인증
– 라우팅

5. Access Layer
• API Gateway [선택사항] (1)
– API 인증 처리와 API 키 Lifecycle 관리
– 로드 밸런싱
– 공통기능 처리: Logging, 인증(Authentication)
– 다수의 end-point 제공
– API 변환 로직
• Protocol 변환
• 메시지 변환
• MEP(Message Exchange Pattern) 변환
– 서비스 버스 == ESB
– 매시업
– QoS 컨트롤

6. Access Layer
API Gateway (2)
• 개발자 포털
• API Spec
• API Key 인증
• API Manual
• API Sand Box

7. Access Layer
API Gateway (3)
• API Platform
• API Platform (APIgee)
• API Service (3Scale – API Market)
※ MaaS, BaaS

8. Access Layer
• API Mediation (APIgee)

9. Access Layer
계정관리 == IDM (Identity Management System)
– 사용자 관리: 계정 생명주기 관리, 로그인 정보 관리, 부가정보 관리
– Provisioning: 정보 변경 시 연계된 시스템에 배포
– 접근 제어: 인증(Authentication), 권한인가(Authorization), 사용자
역할 관리
– Federation: Idp(Indentity Provider)와 Sp(Service Provider) 연계
– SSO(Single Sign On): 한번의 로그인으로 독립된 시스템 모두 접근
– 타서비스 연동
– 감사(Audit)와 리포팅
ProvisioningAuthentication & Authorization

10. Access Layer
• 계정 관리
• 계정 관리 모델
• 개별 분산 모델
=> 각각 다른 계정 체계 사용
=> N개 서비스 N개 계정
• 중앙 집중형 모델 (가장 바람직한 모델)
=> 중앙 집중 계정관리 시스템
=> 구축 초반부터 잘 기획
10

11. Access Layer
• 계정 관리
• 계정 관리 모델
• 페더레이션 모델
=> 별도의 계정들을 페더레이션을 통해 하나의 통합된 계
정으로 관리
11

12. Access Layer
시스템 연동
• 인터페이스
• Inbound / Outbound: 어댑터, 메시지 변환
• Mediation: 라우팅, 맵핑, MEP 처리
• 모니터링 및 장애 관리
• Audit Log
• 에러 처리 로직
• 장애 처리 정책
– Ignore
– Notification
– Retry
– Manual Handling

13. Business Layer
1. Transaction Processing (Sync)
– Simple request and response pattern. (REST API)
– Stateless, Shared Nothing (공유 정보는 DataGrid로)
– Heavy Transaction & small # of concurrent user
• Multi threaded server
• Web Application Server
– Light Transaction & Huge # of concurrent user (C10K)
• Single thread server
• Vertex, node.js
– 트렌젝션 처리
• Transaction manager (JTS, XA)
• 보상 (Compensation) 트렌젝션
• 결론 : 하이브리드 플랫폼 활용

14. Business Layer
1. Transaction Processing (Sync)
Multi thread server Single Thread Server
(Async)

15. Business Layer
1. Transaction Processing (Sync)
Multi thread server Single Thread Server
(Async)
http://strongloop.com/strongblog/node-js-is-faster-than-java/

16. Business Layer
2. Transaction Processing (Async)
• 메세지 큐 기반 (MQ, RabbitMQ,ActiveMQ, JMS,ZeroMQ)
• 응답을 기다리지 않고 바로 리턴
• 큐 뒤에, 다수의 Worker를 둬서, 대용량 처리에 유리

17. Business Layer
2. Transaction Processing (Async)
* Message Exchange Patterns
1) Fire & forget
2) Publish & Subscribe
3) Routing
4) Call Back
※ collation id

18. Business Layer
2. Transaction Processing (Async)
• 에러처리 (Error Hospital)
① Ignore
② Notify
③ Human interaction
④ Retry (Aging required)

19. Business Layer
2. Transaction Processing (Async)
• 메세지 큐 구성 시 고려사항
• 성능 및 페일 오버를 고려한 persistence 선택
• 펜딩 메세지로 말미암은 Out of Memory
• 트랜잭션 지원 기능
• 클러스터링 기능

20. Business Layer
3. Data Grid
• IMDG (In memory data grid)- HazelCast,Infinispan,Coherence
※ cf. redis (IMDB, 클러스터 안됨)
• 거대한 메모리 클러스터
• 공유 정보 (Sessiom,키 등)와 캐쉬 영역으로 사용됨
• 클러스터링 기반의 자가 HA 기능 필수

21. Business Layer
4. Working Space
• 작업용 파일을 올리는 일종이 temp directory
• 이미지 변환, 동영상 변환
• 자체 HA를 위한 Clustering 필수
• NFS, Gluster FS
Working Space + Async Transaction Processing 기반 구조

22. Business Layer
• 메시징 프로토콜
• HTTP: 오버로드가 상대적으로 크다
• 대안: 내부적으로 필요한 부분에 바이너리 프로토콜 사용
• PB(Google Protocol Buffer)
• 객체에 대한 Serialization / Deserialization 기술
• 여러가지 전송채널 지원
• Thrift (Facebook)
• 직렬화 + RPC 지원
• 전송단의 보안 매커니즘 지원
• 콜렉션 형태의 데이터 지원
• 단점
• IDL 구조 정의가 복잡
• 데이터 포멧 변경이 유연하지 않음
( IDL변경 => 코드 재 생성 => 반영)
22

23. 소프트웨어 개발 트랜드의 변화
• 소규모/단기간 (스타트업)
• 오픈소스로 치덕치덕 & Don`t invent wheel again
• 빠르고 잦은 릴리즈 (애자일)
• 개발과 운영을 통합 (DEVOPS)
• Cloud: 비용 절감
• 하나씩 차근차근 => 결국 대용량 글로벌 스케일