ch6 대용량서비스레퍼런스아키텍처...
TRANSCRIPT
대용량 서비스 레퍼런스 아키텍쳐
대용량 서비스 레퍼런스 아키텍쳐
• 기반사상 => SOA
• Access Layer
– 외부로 부터 들어오는 사용자 요청에 대해서 관문 역할
– 외부 시스템과의 연동 역할
• Business Layer
– 들어온 사용자 요청에 대해서 비지니스 로직을 처리
– Client에 응답
• Persistent Layer
– Business Logic에 의해 처리되는 또는 처리된 데이타를 저장
• OAM(Operation Administration Monitoring)
– 시스템의 관리 및 운용
• Analysis Layer
– 로그분석
Access Layer
• 사용자 API에 대한 End Point
• 웹 캐시– 정적인 자원(자바스크립트, 이미지, 정적 페이지 등) 캐싱– 전체 시스템 부하 감소
• Reverse Proxy– 정적 contents 서비스 제공– 인증– 라우팅
Access Layer
• API Gateway [선택사항] (1)
– API 인증 처리와 API 키 Lifecycle 관리
– 로드 밸런싱
– 공통기능 처리: Logging, 인증(Authentication)
– 다수의 end-point 제공
– API 변환 로직
• Protocol 변환
• 메시지 변환
• MEP(Message Exchange Pattern) 변환
– 서비스 버스 == ESB
– 매시업
– QoS 컨트롤
Access Layer
API Gateway (2)
• 개발자 포털
• API Spec
• API Key 인증
• API Manual
• API Sand Box
Access Layer
API Gateway (3)
• API Platform
• API Platform (APIgee)• API Service (3Scale – API Market)※ MaaS, BaaS
Access Layer
• API Mediation (APIgee)
Access Layer
계정관리 == IDM (Identity Management System)
– 사용자 관리: 계정 생명주기 관리, 로그인 정보 관리, 부가정보 관리
– Provisioning: 정보 변경 시 연계된 시스템에 배포
– 접근 제어: 인증(Authentication), 권한인가(Authorization), 사용자역할 관리
– Federation: Idp(Indentity Provider)와 Sp(Service Provider) 연계
– SSO(Single Sign On): 한번의 로그인으로 독립된 시스템 모두 접근
– 타서비스 연동
– 감사(Audit)와 리포팅
ProvisioningAuthentication & Authorization
Access Layer
• 계정 관리
• 계정 관리 모델
• 개별 분산 모델=> 각각 다른 계정 체계 사용=> N개 서비스 N개 계정
• 중앙 집중형 모델 (가장 바람직한 모델)=> 중앙 집중 계정관리 시스템=> 구축 초반부터 잘 기획
10
Access Layer
• 계정 관리
• 계정 관리 모델
• 페더레이션 모델=> 별도의 계정들을 페더레이션을 통해 하나의 통합된 계정으로 관리
11
Access Layer
시스템 연동
• 인터페이스
• Inbound / Outbound: 어댑터, 메시지 변환
• Mediation: 라우팅, 맵핑, MEP 처리
• 모니터링 및 장애 관리
• Audit Log
• 에러 처리 로직
• 장애 처리 정책
– Ignore
– Notification
– Retry
– Manual Handling
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) 트렌젝션
• 결론 : 하이브리드 플랫폼 활용
Business Layer
1. Transaction Processing (Sync)
Multi thread server Single Thread Server(Async)
Business Layer
1. Transaction Processing (Sync)
Multi thread server Single Thread Server(Async)
http://strongloop.com/strongblog/node-js-is-faster-than-java/
Business Layer
2. Transaction Processing (Async)
• 메세지 큐 기반 (MQ, RabbitMQ,ActiveMQ, JMS,ZeroMQ)
• 응답을 기다리지 않고 바로 리턴
• 큐 뒤에, 다수의 Worker를 둬서, 대용량 처리에 유리
Business Layer
2. Transaction Processing (Async)
* Message Exchange Patterns
1) Fire & forget
2) Publish & Subscribe
3) Routing
4) Call Back
※ collation id
Business Layer
2. Transaction Processing (Async)
• 에러처리 (Error Hospital)
① Ignore
② Notify
③ Human interaction
④ Retry (Aging required)
Business Layer
2. Transaction Processing (Async)
• 메세지 큐 구성 시 고려사항
• 성능 및 페일 오버를 고려한 persistence 선택
• 펜딩 메세지로 말미암은 Out of Memory
• 트랜잭션 지원 기능
• 클러스터링 기능
Business Layer
3. Data Grid
• IMDG (In memory data grid)- HazelCast,Infinispan,Coherence※ cf. redis (IMDB, 클러스터 안됨)
• 거대한 메모리 클러스터
• 공유 정보 (Sessiom,키 등)와 캐쉬 영역으로 사용됨
• 클러스터링 기반의 자가 HA 기능 필수
Business Layer
4. Working Space
• 작업용 파일을 올리는 일종이 temp directory
• 이미지 변환, 동영상 변환
• 자체 HA를 위한 Clustering 필수
• NFS, Gluster FS
Working Space + Async Transaction Processing 기반 구조
Business Layer
• 메시징 프로토콜
• HTTP: 오버로드가 상대적으로 크다
• 대안: 내부적으로 필요한 부분에 바이너리 프로토콜 사용
• PB(Google Protocol Buffer)
• 객체에 대한 Serialization / Deserialization 기술
• 여러가지 전송채널 지원
• Thrift (Facebook)
• 직렬화 + RPC 지원
• 전송단의 보안 매커니즘 지원
• 콜렉션 형태의 데이터 지원
• 단점
• IDL 구조 정의가 복잡
• 데이터 포멧 변경이 유연하지 않음( IDL변경 => 코드 재 생성 => 반영)
22
소프트웨어 개발 트랜드의 변화
• 소규모/단기간 (스타트업)
• 오픈소스로 치덕치덕 & Don`t invent wheel again
• 빠르고 잦은 릴리즈 (애자일)
• 개발과 운영을 통합 (DEVOPS)
• Cloud: 비용 절감
• 하나씩 차근차근 => 결국 대용량 글로벌 스케일