확장가능한 웹 아키텍쳐 구축 방안
13 likes1,316 views
AOSA 서적의 Scalable Web Architecture and Distributed System 의 내용을 이해하기 쉽게 보강및 각색한 버전입니다. 어니컴의 김현종 님이 작업해 주셨습니다.
확장가능한 웹 아키텍쳐 구축 방안
- 1. 김현종 책임연구원
- 2. 대표적인 대용량 웹 서비스들
- 4. 고려해야 할 것? Localization 가입자수 TIME ZONE 처리 ? TEXT 다국어 처리 ? 기준 FONT ? 방문자수 확장성 (Scalability) ? TPS (Transaction Per Second) HA (High Availability) ? 비용(Cost) 성능(Performance)
- 5. Key Principles • 대규모의 웹 시스템을 설계할 때 고려해야 할 주요 사항들. 가용성 (Availability) 성능 (Performance) 신뢰성 (Reliability) 확장성 (Scalability) 관리성 (Manageability) 비용(Cost)
- 6. Key Principles 가용성 (Availability) 성능 (Performance) 신뢰성 (Reliability) 장애가 발생했을 경우에 대한 빠른 복구 방법, 문제가 발생할 때 일부만으로 동작할 수 있게 해서 전면 장애가 발생하지 않게 하는 구성 해야 한다. 웹 사이트에서 성능은 매우 중요한 고려사항, 빠른 응답 시간과 낮은 레이턴시를 위해서 최적화된 시스템을 만드는 것은 중요하다. 항상 똑같은 요청에는 똑같은 결과를 제공해야 한다. 시스템이 항상 정상적으로 동작해야 한다. 데이터가 변하거나 업데이트되고 나면 업데이트된 새 로운 데이터를 반환 해야한다.
- 7. Key Principles 확장성 (Scalability) 관리성 (Manageability) 비용(Cost) 많은 부하를 처리할 수 있도록 처리량을 증가 시킬 수 있어야 한다. 시스템의 확장성이란 시스템의 여러 특징이나 기능 / 비 기능, 한계 상황 으로 설명될 수 있다. 쉽게 운용할 수 있는 시스템을 설계하는 것은 또 다른 중요한 고려 사항이다. 관리성이 좋아지려면 문제 발생 시 윈인 분석과 문제를 이해하기 쉬워야 한다. 그리고 업데이트와 수정, 시스템 운용 자체가 쉬워야 한다. 비용은 중요한다. 비용은 하드웨어와 소프트웨어 비용을 포함하지만, 시스템을 배포하고 관리하는 비용 또한 중요하게 고려해야 한다. 예를 들면 시스템이 빌드하는 데 걸리는 시간, 시스템을 실행시키는 데 드는 운용 노력의 양, 모든 고려해야 할 사항에 대해서 필요한 교육 비용까지 포함된다. 즉, 비용은 시스템 소유에 필요한 모든 비용이다.
- 8. 이 중 가장 고려해야할 사항은? 올바른 선택은 무엇인가? 이것들을 어떻게 잘 조합 할 것 인가?
- 9. 목차 • Motivation • Basics - Services - Redundancy - Partitions • Fast and Scalable Data Access - Cache - Proxies - Indexes • Load Balancers • Queue
- 10. • 서비스들 (Services) • 이중화 (Redundancy) • 분할 (Partitions)
- 13. 고려해야 할 또 다른 측면 • 저장될 이미지의 개수에 제한이 없다. 저장공간의 확장성에 대해서도 고려해야 한다. • 이미지 보기나 다운로드를 요청할 때 응답 시간이 빨라야 한다. • 사용자가 이미지를 업로드하고 난 후, 해당 이미지는 항상 시스 템에 저장되어 있어야 한다. (데이터 신뢰성) • 시스템을 운용하기 쉬워야 한다. (관리성) • 이미지 호스팅 서비스 자체의 이익율이 높지 않기 때문에, 시스템은 효율적으로 운용될 필요가 있다.(비용)
- 14. ISSUE
- 15. Services
- 17. MSA Gateway Product List
- 18. Services SPOF
- 19. SPOF
- 21. Redundancy
- 22. Shared Nothing Architecture 공유하는 자원 없이 고가용성(HA)을 구현하기 위한 아키텍처
- 23. Shared Nothing Architecture 특징 구분 Shared Nothing Architecture 공유 자원 공유 자원 없음 데이터동기화 방안 Network를 통한 공유 (복제) 성능 공유 자원이 없으므로 빠른 성능 시스템 구축비용 저비용(로컬 디스크, Network) 거리 적용 일반적인 TCP기반의 Network 를 사용해도 원거리 적용에 큰 무리가 없음 데이터 정합성 Network 공유(복제) 특성상 노드간 데이터 불일치 현상을 억제하기 위한 별도의 고려가 필요 치명적인 Failure 요소 Network Failure 시 관련 노드 데이터 동기화 불가 적합 시스템 완벽한 데이터 정합성보다는 빠른 성능 요구 관련 대표 DBMS기술 이중화(replication)
- 24. Shared Nothing Architecture • 각각의 노드는 상태나 작업을 관리하는 중앙부 없이 독립적으로 동작 가능 • 새로운 노드를 특별한 조건없이 추가 가능. • 시스템이 single point of failure을 갖지 않 음.즉, 장애에 좀 더 잘 대처할 수 있음.
- 25. Redundancy
- 26. Partitioning
- 27. Partitioning
- 29. What is Sharding • 퍼포먼스(performance), 가용성(availability) 또는 운영 용이성(maintainability)를 목적으로 논리적인 데이터 엘리먼트들을 다수의 엔티티 (table)로 쪼개는 행위를 뜻하는 일반적인 용어 이다.
- 31. Partitioning
- 34. How to sharding? partitioning?
- 37. Key or Hash Based Partitioning
- 38. ETC Partitioning • Directory Based Partitioning - 파티셔닝 메커니즘을 제공하는 추상화된 서비스 - 샤드키를 조회 할 수 있으면 되므로, 구현은 DB 와 cache 등 를 적절히 조합해서 만들수 있다. https://charsyam.wordpress.com/2011/12/04/instagram-%EC%97%90%EC%84%9C-id- %EC%83%A4%EB%94%A9%ED%95%98%EA%B8%B0/
- 39. 일반적인 방법
- 40. Partitions
- 41. ISSUE • 데이터 로컬리티 - 로컬에 데이터가 없다면 데이터를 얻기 위해 네트워크 비용 과 잠재적인 성능 문제가 발생할 수 있다. • 데이터 비 정합성 - 어떠한 데이터가 업데이트 되려 할 때, 읽기 요청이 업데이트 요청보다 먼저 발생했다면 해당 데이터는 비 정합성 상태가 된다.
- 42. 결론 • MSA 처럼 각 서비스를 독립적으로 만들어 확장성을 확보 해야 한다. • Shared Nothing Architecture 를 이용하여 HA(High Availability) 을 확보 해야 한다.
- 43. Fast and Scalable Data Access
- 45. Busy Disk I/O
- 46. Motivation • Cache • Proxies • Indexes
- 47. Cache • Request Layer Node Cache (ex: BrowserCache ) • Global Cache • Distributed Cache
- 48. Cpu Cache
- 49. Browser Cache
- 50. Caches • 요청 받은 데이터는 다시 요청 받을 확률이 높다는 지역성의 원리 (locality of reference)에 기반한 방법. • 매우 짧은 시간 동안 유지되는 메모리와 같은 것. (단기 기억) • 캐시 용량은 매우 제한적이지만, 통상적으로 원래의 데이터 저장소 보다는 매우 빠르고 자주 액세스되는 데이터를 보유. • 아키텍처의 모든 단계에 위치할 수 있지만, Front-end 와 가까운 곳 에 위치하는 경우가 많음. • 보통 캐시는 서비스의 Back-end까지 가는 시간적인 비용을 줄이기 위해서 사용하는 경우가 많기 때문.
- 51. Where Caches ??
- 52. Request Layer Node Cache
- 53. Request Layer Node Multiple Cache
- 54. Global Cache 두가지 방식
- 55. Global Cache A TypeGlobal Cache A Type
- 56. MySQL 5.7 Memcache Plugin https://dev.mysql.com/doc/refman/5.7/en/innodb-memcached- setup.html
- 57. Global Cache A Type • 원래의 데이터 저장소보다는 매우 빠르게 제공 해야 하고, 자주 사용 되는 데이터 • 짧은 시간 동안 유지되는 되어야 하는 데이터
- 58. Global Cache B Type
- 59. Global Cache B Type • 파일 사이즈가 크면서 자주 사용 하는 데이터 파일 (각종 이미지, 데모 영상, 사용자 메뉴얼 등) • 정적 파일을 캐시에 저장하는 경우. • 각 노드들이 공유 해야 하는 정보들
- 61. Consistent Hashing (Hash Ring) • https://www.popit.kr/consistent-hashing/
- 63. Distributed Cache 단점 • 장애가 발생한 노드를 처리하는 방법이 필요하다. 다른 노드에 여러 개의 복제본을 가지는 방법으로 해결 하기도 한다. 그러나 문제 노드를 처리하기 위한 로직이 복잡해진다. • 캐시 시스템에는 추가적인 저장 공간을 유지하기 위한 비용 문제가 항상 따른다
- 65. Cache에 데이터가 없을때
- 66. Proxies
- 67. Proxies 종류 • Forward Proxy • Reverse Proxy
- 68. Forward Proxy
- 69. Reverse Proxy
- 70. Forward vs Reverse Proxy 차이점 Forward Proxy 가고 싶은 목적지 사이트의 주소를 직접 프록시 서버에게 전달, 전달 받은 프록시 서버가 해당 목적지 사이트의 내용을 받아와서 전달해주는 대리인 역할 (즉, Client가 목적지를 알고 프록시에 전달) 예: (http://proxy.com/?url=target.com) Reverse Proxy Reverse Proxy 에 설정된 서버의 주소 로 데이터를 요청, Reverse Proxy는 이 요청을 받아서 자신의 뒤에 있는 "배후"의 서버에 데이터를 요청하여 받은 다음 클라이언트에 전달하게 됨. (즉, Client 가 목적지는 모르지만 프록시가 알고 요청을 처리 하여 전달) 예: ( 클라이언트는 http://proxy.com/로 요청 --> proxy는 target.com 에 서 데이터를 가져와 응답)
- 71. Proxies
- 73. Forward Proxy
- 74. Proxies With Caches • 프락시와 캐시를 함께 사용하는 것은 무의미하지만, 같이 사용하게 될 때에는 캐시를 프락시 앞에 두는 것이 최선. • 프락시가 캐시 앞에 있으면 캐시로 요청이 오기 전에 추가적인 지연 만 생기기 때문에 성능이 저하 된다. • 캐시와 비슷하지만, 캐시는 데이터나 문서를 저장하기 위함 이고, 프락시는 여러 클라이언트가 원하는 문서를 제공하기 위한 요청이 나 콜을 최적화시키는 방법이다.
- 75. Open Source Forward Proxy
- 76. Open Source Reverse Proxy
- 77. 수 십만 테라바이트에서 1KB정도 데이터를 액세스 하기 위해서는 어떻게 해야하나?
- 78. Indexes • Indexes • Multi Layer Indexes
- 79. Indexes
- 80. Indexes
- 81. Indexes • DBMS에서는 다양한 Indexing 방법을 제공 https://www.tutorialspoint.com/dbms/dbms_indexing.htm
- 82. Load Balancers
- 83. Load Balancers
- 84. Load Balancers
- 85. Open Source Load Balancers
- 86. 동기적 요청 처리 상황
- 87. 동기적 요청 처리 상황
- 88. Half-Sync / Half-Async 패턴
- 89. Queues
- 90. Queues • 클라이언트의 동기 적인 처리 방식을 비동기 처리 방식으로 동작. • 클라이언트 요청과 그 요청에 대한 응답 사이에 추상화를 제공. • 요청 부 와 응답 처리 부를 분리하여 관리 할 수 있다.
- 92. Architecture
- 93. Architecture
- 98. x