대용량 아키텍처와 성능튜닝 ch6. 대용량 서비스 레퍼런스 아키텍처

1. Part3. 대용량 아키텍처
아키텍처를 꿈꾸는 사람들
최문규

2. 목차
4. Persistent Layer
5. Analysis Layer
6. OAM Layer
7. Cloud infra
8. Global service architecture

3. 4.Persistent Layer
• 처리할 데이터를 저장하는 공간
• RDMBS
• File system
• NoSQL

4. RDMBS
• 2차원 테이블 구조의 데이터
• 여러개의 칼럼으로 저장, 각각의 행은 다른 테이블과 관계가
가능
• OLTP(On-Line Transaction Processing)
요청을 바로 처리하는 트렌젝션 처리용
• OLAP(On-Line Analytical Processing)
성격과 데이터를 모아서 분석하고 리포팅

5. Query off Loading
• DB성능 향상을 위한 기법(처리량)
• 트랜잭션의 70~90%는 대부분 읽기 요청
나머지 10~30%는 CUD(create,update,delete)요청
• 트랜젝션이 많은 읽기 요청 분리해서 처리

6. Query off Loading
• Master DB에만 쓰기, Slave DB는 읽기만
• 요청이 많은 Slave DB는 Load Balancing / HA
• Staging DB는 Master DB의 backlog를 읽어 Slave DB에 replay

7. Sharding
• DB의 물리적 용량의 한계
• 데이터를 여러 개의 DB에 나눠담기
• 수직적 / 수평적 sharding

8. Sharding
• 샤딩을 할 때, 데이터 쏠림현상은?
• 샤드 서버 성능을 비대칭적으로 설계
• 등록 키를 시퀸셜하게(1,2... 6,7...9)

9. 4.2 File system
• 일반 파일 시스템
• Object storage
• 디스크 형태 마운트X
• HTTTP/REST형태(중앙집중X, 누구나 사용가능)
• http://aws.amazon.com/ko/s3/

10. 4.3 NoSQL
• 복잡한 업무의 구조와 관계를 표현한 RDBMS
• SNS서비스가 발전함에 따라, 간단한 테이블 구조
테이블 간의 관계 X
• 빠른 응답시간 보장
• 많은 용량을 저장
• 과연 NoSQL이 필요한가?
• case by case

11. 5. Analysis Layer
• 트랜젝션 처리에 의한 결과와 로그를 분석

12. 5.1 OLAP방식의 분석 시스템
ETL(Extract Transform Loading)
E - 다양한 데티러 소스로부터 데이터를 추출
T - 추출된 데이터를 수신 변환
L - 변환된 데이터를 수시신 쪽 데이터 베이스에 제공

13. 5.1 OLAP방식의 분석 시스템
Dataware house
데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스
Data Mart
부서내에서 단순하게 응용분야별로 구축되는 소규모 형태의 데이터웨어하우스

14. 5.2 Map & Reduce
나눠서 합친다

15. 5.4 실시간 분석 시스템
• OLAP, Map & Reduce방식은 분석 후, 리포팅 시점이 늦다
• 빠른 의사결정 및 전략을 세우기 어려움,
• 스트리밍 데이터 분석이 필요함
• Storm, Spark

16. 6. OAM Layer
• Operation, Administration ,Monitor
• Configuration Management
• Deploy system
• Monitoring system

17. 6.1 CMDB
• 다수의 인스턴스로 구성되는 분산시스템에 필요한 설정정보
• 어떻게 관리?!
• ZooKeeper
• 적은양의 구조화된 데이터로, 실시간 변경 알림, 적용

18. 6.2 모니터링
• Application
• Middleware
• DBMS
• Infrastructure

19. 6.3 로그 관리
• 시스템에 발생하는 행위에 대한 기록
• 로그의 분류
• 시스템 로그
• 애플리케이션 로그
• 비즈니스 로그

20. 6.3 로그 관리
• 수집과 저장
• Kafka + HDFS + Elastic search
• LogStash
• 분석과 시각화
• 시스템 로그에 대한 레퍼런스 아키텍처

21. 6.4 Configuration 관리
• 짧은 출시 기반의 개발론 유행
• auto scale out시 마다 설정 배포 작업
• 배포 설정 자동화 도구
• Puppet
• Chef

22. 7. 클라우드 인프라
클라우드란?
서버, 네트워크, 스토리지와 같은 컴퓨팅 지원을
언제 어디서든 원격의 공유된 풀에서 사용할 수 있는 형태

23. 7.1 클라우드 모델
• Private Cloud
• 클라우드 플랫폼이 회사 내부 데이터 센터에 독립적으로 구축
• VMware, CloudStack
• Public Cloud
• 서비스 제공자가 클라우드 서비스를 제공하기 위한 플랫폼
• Amazon Web Service, Window Azure, Google App Engine
• Hosted Private Cloud

24. 7.2 클라우드 컴퓨팅 서비스 분류
• Iaas(Infrastructure as a Service)
• 인프라 자원(cpu,mem,disk)을 관리 제공. 입맛대로
• AWS
• Paas(Platform as a Service)
• Iaas + 개발환경 + API지원
• Heroku, Bluemix, Azure
• Saas(Software as a Service)
• MS Office365

25. 7.3 클라우드 컴퓨팅의 장단점
장점
- 쉽고 빠르다
- 초기 투자 비용이 저렴
- 무제한의 확장성
단점
- 싸지 않다
- 성능이 생각보다 떨어진다
- 다른 아키텍처를 가져야 한다
- 불안정하다

26. 8.1 법적인 이슈에 대한 검토
• 중국의 ‘Great Fire Wall’
• 중국 대상 서비스는 중국에 시스템을 내놓고 서비스

27. 8.2 시스템 위치 선정
• 유럽, 미국 중 한 곳에 구축

28. 8.3 운영에 관련된 고려사항
• 24/7
• FTS(Follow The Sun)모델을 통한 운영

29. 8.4 기술적인 고려사항
센터의 레벨과 분류
- HQ : 전체 센터의 중시의 되는곳
- RC : 각 권역을 서비스학 위한 센터. 법적 이슈 회피
- Edge : 법적인 이슈를 피하기 위해, CDN

30. Request Routing

31. 센터간의 데이터 복제
솔루션 레벨
솔루션 자체 기능으로 데이터 센터 간 복제 (CDC)
어플리케이션 레벨
업데이트 된 내용을 SELECT 후, 복제 대상에 INSERT,UPDATE
인프라 레벨
디스크 자체를 블록 레벨에서 복사

32. 데이터 복제 토폴로지
Multi Master
모든 데이터 노드 간에 양방향으로 데이터 복제
각 노드에서 데이터에 대한 읽기쓰기 가능

33. 데이터 복제 토폴로지
Master Slave
데이터 복제를 Master에서 Slave로만 한다.
Master에서만 쓰기가능 Slave는 읽기만 가능

34. 데이터 복제 토폴로지
Multi Write
DB간의 복제를 사용하지 않고, 복제가 필요한 DB에 같이 쓰
는 방법

35. 데이터 복제 토폴로지
Multi Master
모든 데이터 노드 간에 양방향으로 데이터 복제
각 노드에서 데이터에 대한 읽기쓰기 가능