2013년 7월 16일 일본에서 진행된 AWS 八木橋 徹平 솔루션스 아키텍트의 기술 웨비나 발표 자료를 한국의 정윤진 솔루션스 아키텍트가 한글로 번역한 자료입니다. 웨비나 당시와 현재의 내용이 상이한 부분이 있을 수 있으니 자료 열람에 이 점 참고하시기 바라며, 혹 내용에 대한 문의사항이 있으신 경우 info-kr@amazon.com으로 연락 부탁드리겠습니다.
2013년 7월 16일 일본에서 진행된 AWS 八木橋 徹平 솔루션스 아키텍트의 기술 웨비나 발표 자료를 한국의 정윤진 솔루션스 아키텍트가 한글로 번역한 자료입니다. 웨비나 당시와 현재의 내용이 상이한 부분이 있을 수 있으니 자료 열람에 이 점 참고하시기 바라며, 혹 내용에 대한 문의사항이 있으신 경우 info-kr@amazon.com으로 연락 부탁드리겠습니다.
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study (임현수 플랫폼인프라실 Technical Manager, 넥...Amazon Web Services Korea
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study
이 세션에서는 넥슨의 Case study를 통하여 글로벌플랫폼 구축을 위해 기존 플랫폼을 AWS로 Migration하는 과정 및 발생가능한 이슈를 공유합니다. 넥슨이 DB서버를 이전하는 과정 속에서 마주한 기술적 고민과 이슈를 통하여 AWS 활용 시 고려해야 할 부분들에 대해 소개하고 함께 이야기 나누고자 합니다.
[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | Aurora로 게임 데이터베이스 레벨 업! - 김병수 AWS ...Amazon Web Services Korea
Amazon Aurora Database는 오픈소스의 개방성과 상용 데이터베이스의 성능과 안정성을 모두 제공하는 관리형 데이터베이스 서비스입니다. Amazon Aurora Database는 처음 소개된 이후로 계속 기능을 추가하며 진화해 왔습니다. Amazon Aurora의 성능과 새롭게 업데이트된 기능들을 게임사에 적용할 수 있는 사용 사례와 함께 소개합니다.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
마이크로서비스 아키텍처로 만들어진 현대 애플리케이션에서는 관계형 데이터베이스 이외에도 각 마이크로서비스의 특징에 맞는 데이터베이스를 사용하는 것은 중요합니다. 오픈소스 데이터베이스들은 서로 닮아가며 진화하고 있기에 내 서비스에 적합한 데이터베이스를 선택하는 것은 여전히 어려운 과제입니다. 이 세션에서는 다양한 워크로드에 따른 적합한 오픈소스 데이터베이스를 알아보고, 이와 매핑되는 AWS 매니지드 데이터베이스 서비스를 함께 소개합니다.
컨테이너를 활용하여 마이크로서비스를 구성할 때는 효과적으로 컨테이너 및 서비스를 관리할 수 있는 방법이 필요합니다. 본 세션에서는 유연하게 컨테이너 환경을 관리/모니터링 할 수 있는 Amazon EC2 Container Service 및 EC2 Container Registry를 소개합니다. 아울러 Amazon ECS/ECR 환경에서 효과적인 자원 및 로그 관리, 마이크로서비스 관리에 대해서 자세히 살펴봅니다.
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )SANG WON PARK
몇년 전부터 Data Architecture의 변화가 빠르게 진행되고 있고,
그 중 Cloud DW는 기존 Data Lake(Hadoop 기반)의 한계(성능, 비용, 운영 등)에 대한 대안으로 주목받으며,
많은 기업들이 이미 도입했거나, 도입을 검토하고 있다.
본 자료는 이러한 Cloud DW에 대해서 개념적으로 이해하고,
시장에 존재하는 다양한 Cloud DW 중에서 기업의 환경에 맞는 제품이 어떤 것인지 성능/비용 관점으로 비교했다.
- 왜기업들은 CloudDW에주목하는가?
- 시장에는어떤 제품들이 있는가?
- 우리Biz환경에서는 어떤 제품을 도입해야 하는가?
- CloudDW솔루션의 성능은?
- 기존DataLake(EMR)대비 성능은?
- 유사CloudDW(snowflake vs redshift) 대비성능은?
앞으로도 Data를 둘러싼 시장은 Cloud DW를 기반으로 ELT, Mata Mesh, Reverse ETL등 새로운 생테계가 급속하게 발전할 것이고,
이를 위한 데이터 엔지니어/데이터 아키텍트 관점의 기술적 검토와 고민이 필요할 것 같다.
https://blog.naver.com/freepsw/222654809552
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study (임현수 플랫폼인프라실 Technical Manager, 넥...Amazon Web Services Korea
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study
이 세션에서는 넥슨의 Case study를 통하여 글로벌플랫폼 구축을 위해 기존 플랫폼을 AWS로 Migration하는 과정 및 발생가능한 이슈를 공유합니다. 넥슨이 DB서버를 이전하는 과정 속에서 마주한 기술적 고민과 이슈를 통하여 AWS 활용 시 고려해야 할 부분들에 대해 소개하고 함께 이야기 나누고자 합니다.
[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | Aurora로 게임 데이터베이스 레벨 업! - 김병수 AWS ...Amazon Web Services Korea
Amazon Aurora Database는 오픈소스의 개방성과 상용 데이터베이스의 성능과 안정성을 모두 제공하는 관리형 데이터베이스 서비스입니다. Amazon Aurora Database는 처음 소개된 이후로 계속 기능을 추가하며 진화해 왔습니다. Amazon Aurora의 성능과 새롭게 업데이트된 기능들을 게임사에 적용할 수 있는 사용 사례와 함께 소개합니다.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
마이크로서비스 아키텍처로 만들어진 현대 애플리케이션에서는 관계형 데이터베이스 이외에도 각 마이크로서비스의 특징에 맞는 데이터베이스를 사용하는 것은 중요합니다. 오픈소스 데이터베이스들은 서로 닮아가며 진화하고 있기에 내 서비스에 적합한 데이터베이스를 선택하는 것은 여전히 어려운 과제입니다. 이 세션에서는 다양한 워크로드에 따른 적합한 오픈소스 데이터베이스를 알아보고, 이와 매핑되는 AWS 매니지드 데이터베이스 서비스를 함께 소개합니다.
컨테이너를 활용하여 마이크로서비스를 구성할 때는 효과적으로 컨테이너 및 서비스를 관리할 수 있는 방법이 필요합니다. 본 세션에서는 유연하게 컨테이너 환경을 관리/모니터링 할 수 있는 Amazon EC2 Container Service 및 EC2 Container Registry를 소개합니다. 아울러 Amazon ECS/ECR 환경에서 효과적인 자원 및 로그 관리, 마이크로서비스 관리에 대해서 자세히 살펴봅니다.
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )SANG WON PARK
몇년 전부터 Data Architecture의 변화가 빠르게 진행되고 있고,
그 중 Cloud DW는 기존 Data Lake(Hadoop 기반)의 한계(성능, 비용, 운영 등)에 대한 대안으로 주목받으며,
많은 기업들이 이미 도입했거나, 도입을 검토하고 있다.
본 자료는 이러한 Cloud DW에 대해서 개념적으로 이해하고,
시장에 존재하는 다양한 Cloud DW 중에서 기업의 환경에 맞는 제품이 어떤 것인지 성능/비용 관점으로 비교했다.
- 왜기업들은 CloudDW에주목하는가?
- 시장에는어떤 제품들이 있는가?
- 우리Biz환경에서는 어떤 제품을 도입해야 하는가?
- CloudDW솔루션의 성능은?
- 기존DataLake(EMR)대비 성능은?
- 유사CloudDW(snowflake vs redshift) 대비성능은?
앞으로도 Data를 둘러싼 시장은 Cloud DW를 기반으로 ELT, Mata Mesh, Reverse ETL등 새로운 생테계가 급속하게 발전할 것이고,
이를 위한 데이터 엔지니어/데이터 아키텍트 관점의 기술적 검토와 고민이 필요할 것 같다.
https://blog.naver.com/freepsw/222654809552
클라우드에서 인프라 구축 시 고려해야 할 사항들을 살펴보고, 네이버 클라우드 플랫폼을 활용하여 고가용성을 유지하는 방안에 대해 소개합니다. | Explore the considerations of building infrastructure in the cloud and introduce ways to maintain high availability by leveraging the Naver cloud platform.
드랍박스, nDrive 등과 같은 클라우드 스토리지 서비스들은 데이터를 어떻게 저장하는지에 대한 이론적 내용과 실제 구현 내용을 살펴봅니다. 이 발표에서는 OpenStack 의 swift라는 Object Storage 를 이용하여 이론이 어떻게 구현되어있는지 알아봅니다.
Cloud DW technology trends and considerations for enterprises to apply snowflakeSANG WON PARK
올해 처음 오프라인으로 진행된 "한국 데이터 엔니지어 모임"에서 발표한 cloud dw와 snowflake라는 주제로 발표한 내용을 정리하여 공유함. (2022.07)
[ 발표 주제 ]
Cloud DW 기술 트렌드와 Snowflake 적용
- Modern Data Stack에서 Cloud DW의 역할
- 기존 Data Lake + DW와 무엇이 다른가?
- Data Engineer 관점에서 어떻게 사용하면 좋을까? (기능/성능/비용 측면의 장점/단점)
[ 주요 내용 ]
- 최근 많은 Data Engineer가 기존 기술 스택(Hadoop, Spark, DW 등)의 기술적/운영적 한계를 극복하기 위한 고민중.
- 특히 Cloud의 장점과 운영 및 성능을 고려한 Cloud DW(AWS Redshift, GCP BigQuery, DataBricks, Snowflake)를 고려
- 이 중 Snowflake를 실제 프로젝트에 적용한 경험과 기술적인 특징/장점/단점을 공유하고자 함.
작년부터 정부의 데이터 정책 변화와 Cloud 기반의 기술 변화 가속화로 기업의 데이터 환경에도 많은 변화가 발생하고 있고, 기업들은 이에 적응하기 위한 다양한 시도를 하고 있다.
그 중심에 cloud dw (또는 Lake house)가 위치하고 있으며, 이를 기반으로 통합 데이터 플랫폼으로의 아키텍처로 변화하고 있다. 하지만, 아직까지 기존 DW 제품과 주요 CSP(AWS, GCP, Azure)의 제품군을 다양하게 시도하고 있으나, 기대와 다르게 생각보나 낮은 성능 또는 비싼 사용료, 운영의 복잡성으로 인한 많은 시행착오를 거치고 있다.
이 상황에서 작년에 처음 검토한 snowflake의 다양한 기능들이 기업들의 고민과 문제를 상당부분 손쉽게 해결할 수 있다는 것을 확인할 수 있었고, 이를 이용하여 실제 많은 기업들에게 적용하기 위한 POC를 수행하거나, 실제 적용하는 프로젝트를 수행하게 되었다.
본 발표 내용은 이러한 경험을 기반으로 기업(그리고 실제 업무를 수행할 Data Engineer) 관점에서 snowflake가 어떻게 문제를 해결할 수 있는지 cloud dw를 도입/활용/확장 하는 단계별로 문제와 해결 방안을 중심으로 설명하였다.
https://blog.naver.com/freepsw?Redirect=Update&logNo=222815591918
넷플릭스에서는 높은 속도로 데이터를 제공하기 위해서 뿐만 아니라 멀티 리전의 데이터 가용성을 바탕으로한 전체 서비스 가용성 유지를 위해 캐시를 사용하고 있습니다. 이 앞의 세션에서 보았던 마이크로서비스 구조를 염두해 둘때 한가지 가장 간단한 변화는 외부 클라이언트로 부터 유입되는 단 하나의 요청에 대한 응답을 만들기 위해 다수의 내부 서비스들로 부터 데이터를 확보해야 하며, 이는 다수 서비스들에 대한 요청과 응답으로 이루어지게 됩니다. 내부 네트워크 성능, 데이터 저장소의 응답속도등의 복합적인 영향으로 인해 마이크로 서비스는 쉽게 느려질 수 있으며, 이는 보통 '팬아웃 효과'로 알려져 있습니다. 뿐만 아니라 다수 서비스간의 데이터 정합성 유지, 필요에 따라 각 서비스간 데이터의 다운타임 없는 이동, 증가하는 데이터량에 동시에 증가하는 데이터 소스의 부하, 그리고 이런 것들을 모두 감안한 데이터 복제 등을 처리해야 할 필요가 있습니다. 본 세션에서는 넷플릭스에서는 이런 문제를 어떤 방식으로 해결하는지, 그리고 스프링 부트, 스프링 클라우드를 비롯한 피보탈의 기술을 사용해서 어떻게 빠르고 쉽게 사용할 수 있는지에 대해 알아봅니다.
Oracle DB를 AWS로 이관하는 방법들 - 서호석 클라우드 사업부/컨설팅팀 이사, 영우디지탈 :: AWS Summit Seoul 2021Amazon Web Services Korea
Oracle DBMS 는 국내 대기업에서 압도적으로 가장 많이 사용하는 DB 로, 이 세션에서는 Oracle DB 를 AWS 로 이관하는 방법들에 대하여 살펴보겠습니다. 환경에 따라 Oracle DB 를 이관하는 어떤 방법들이 있는지 알아보며, AWS DMS(Database Migration Service) 를 사용하여 효과적으로 이관할수 있는 방법을 소개합니다. Oracle DB 를 클라우드 환경으로 이관할 때 유의해야할 포인트들에 대해 함께 공유합니다.
Similar to Scalable web architecture and distributed systems (20)
7. Image Hosting Application
Architecture
• 저장될 이미지의 개수에 제한이 없다. 따라서 저장공간
의 확장성에 대해서도 고려해야 한다
• 이미지 보기나 다운로드를 요청할 때 응답 시간이 빨라
야 한다.
• 사용자가 이미지를 업로드하고 난 후, 해당 이미지는
항상 시스템에 저장되어 있어야 한다. (데이터에 대한
신뢰성)
• 시스템을 운용하기 쉬워야 한다(관리성)
• 이미지 호스팅 서비스 자체의 이익율이 높지 않기 때문
에, 시스템은 비용 효율적으로 운용될 필요가 있다.
8. • 제공하는 기능을 두가지로 한정 한다
upload(write) 와 query(read)
9. • Problem 1
‘Write'가 'Read'에 영향을 미친다.
이 두 가지 기능은 공유 자원을 경쟁적으로 사용하고 있기 때문에
다운로드와 업로드의 속도가 똑같다고 가정해도 ‘Write'가 'Read'에 영향을 미친다.
(실제로는 다운로드 속도와 업로드 속도 비율은 3:1 정도다)
'읽기'는 캐시의 도움을 받을 수 있지만 '쓰기' 요청은 결과적으로 디스크까지 도달해야 하기 때문이
다.
10. • Problem 2
디자인 관점에서의 문제 임. 웹 서버는 동시 커넥션 수에 상한선이 있다는 것이다.(아파치의 경우 디
폴트 500개)
읽기는 비동기일 수 있기 때문에 gzip 압축이나 chunked transfer encoding을
이용하여 성능을 최적화할 수 있다. 쓰기의 경우에는 업로드 동안 연결을 열어 놓은 상태로 유지해야
한다.
만약 1MB를 업로드 하는 것이 1초 이상 걸린다면 서버는 고작 500개의 동시적인 쓰기만 처리할 수
있을 뿐이다.
11. Services
위 문제를 해결하기위하여 읽기 서비스와 쓰기 서비스를 분리한다.
읽기와 쓰기를 각각 독립적으로 확장할 수 있게 한다.
읽기와 쓰기를 각각의 서비스로 분리하는 것은 좋은 방법이다.
(보통 사용자들은 쓰기보다는 읽기를 더 많이 한다)
15. Redundancy
시스템을 이중화하는 것은 single point of failure 을 없애고,
장애 발생 시에도 백업하게 할 수 있거나 시스템이 계속 동작할 수 있게 한다.
서비스를 이중화할 때 중요한 것은 Shared Nothing 아키텍처를 만드는 것이다.
중요한 것은 시스템의 single point of failure 를 없애고 장애에 좀 더 잘 대처할 수 있
게 된다.
16. Problem !!!!!!!!
하나의 서버에서 감당할 수 없는 많은 데이터가 있을 수
있다.
또는 연산을 위해 많은 컴퓨팅 자원이 필요하게 되어 성
능이 떨어지게 되는 경우가 있을 수 있다.
18. Partitions
- To scale vertically
각각의 서버에 더 많은 자원을 추가하는 것을 말한다.
많은 데이터를 처리하기 위해 서버에 하드 디스크나 더 빠른 CPU나 큰 용량의 메모리를
추가 하는 게 이에 해당한다. 즉, 수직적 확장은 각 자원의 처리 능력을 향상시키는 것을
말한다.
- To scale horizontally
데이터가 많을 경우에는 부분 데이터를 저장할 수 있는 노드를 추가하는 것이다.
수평적 확장의 장점을 모두 취하기 위해서는 시스템 아키텍처의 고유한 설계
원칙들을 따라야 한다.
수평적 확장을 하는 가장 보편적인 방법은 서비스를 파티션이나 샤드 단위
로
분할하는 것이다
19. Problem !!!!!!!!
- data locality (데이터 로컬리티)
연산하려는 데이터가 가까이 위치해 있을 수록 시스템의 성능은 향상된다.
따라서 필요한 데이터를 여러 서버에 분산시키는 것은 로컬에 있지 않을 수
있는 데이터를 얻기 위해 비용이 높은 네트워크를 이용한 읽기가 발생할 수
있어 잠재적인 성능 문제가 발생할 수 있다.
- inconsistency (비정합성)
공유된 자원으로부터 읽기와 쓰기를 하는 서로 다른 서비스가 있다고 가정할때.
어떠한 데이터가 업데이트되려 할 때, 읽기 요청이 업데이트 요청보다 먼저 발생했다면 해
당 데이터는 비정합성 상태가 된다.
예를 들어 어떤 클라이언트가 어떤 이미지 이름을 Dog에서 Gizmo로 바꾸는 업데이트 요청
을 보냈고,
동시에 다른 클라이언트가 해당 이미지를 읽고 있다면 경합조건이 발생한다.
20. fault tolerance and
monitoring reference
• http://katemats.com/distributed-systems-basics-
handling-failure-fault-tolerance-and-monitoring/
22. LAMP stack
applications
간단한 형태의 웹 애플리케이션을 많은 사용자가 사용하게 되면 두 가지 기술적
인 문제에
직면하게 된다.
1. 애플리케이션 서버에 대한 데이터 액세스를 확장성 있게 하는 것이고,
2. 데이터베이스에 대한 데이터 액세스를 확장성 있게 하는 것이다.
23. 수 테라바이트 크기의 데이터가 있다고 가정해 보자.
그리고 우리는 사용자가 원하는(랜덤한) 데이터에 접근할 수 있도록 하고 싶다.
수 테라바이트 크기의 데이터를 메모리에 올리는 것은 매우 높은 비용이 필요하
기 때문에
모든 데이터를 메모리에 저장하지 않으면서도 빠른 액세스가 가능하도록 하는
것은 어렵다.
여기서 성능에 가장 영향을 미치는 것은 디스크 I/O다.
24. 그러나 쉽게 하기 위한 다양한 방법이 있다.
- Caches (Global Cache, Distributed Cache)
- Proxies
- Indexes
- Load Balancers
GOALS
25. Caches ?
최근에 요청받은 데이터는 다시 요청받을 확률이 높다는 지역성의 원리
(locality of reference)에 기반한 방법이다.
캐시란 매우 짧은 시간 동안 유지되는 메모리와 같은 것이다.
캐시는 아키텍처의 모든 단계에 위치할 수 있지만, 프런트엔드와 가까운 곳에
위치하는
경우가 많다. 왜냐하면 보통 캐시는 서비스의 백 엔드까지 가는 시간적인 비
용을 줄이기 위해서 사용하는 경우가 많기 때문이다.
26. Caches
Insert a cache on your request layer node
매번 요청은 서비스로 보내지고, 요청 노드에 데이터가 존재하면 그 노드는 빠
르게
로컬에서 캐싱된 데이터를 보낸다.
만약 캐시에 데이터가 없다면 요청 노드는 디스크에서 데이터를 질의할 것이
다.
27. Caches
Multiple caches
만약 로드 밸런서가 임의로 요청을 분산시키면, 같은 요청이 다른 노드로 가게 될
수도 있다. 즉, 캐시 미스가 증가하게 될 것이다.
캐시 미스를 줄이면서 여러 개의 캐시를 사용하기 위해 사용하는 방법이
글로벌 캐시 와 분산 캐시다.
28. Global Cache 1
All the nodes use the same single cache space.
요청 노드에서 각각의 요청은 로컬에 캐시를 가지고 있는 것과 같은 방법으로 글로벌 캐시에 데이터를
질의한다.
데이터 노드는 오직 캐시에만 데이터를 질의하고, 글로벌 캐시는 요청받은 데이터를 자기 자신에서 찾
을 수 없을 때,
캐시 스스로가 저장 공간에 데이터를 질의하여 요청 노드에 데이터를 전달하도록 하는 방식이다.
이런 아키텍처는 특정한 상황에서는 매우 유용하다
(특화된 하드웨어를 써서 글로벌 캐시를 빠르게 만들거나, 캐시가 필요한 데이터의 양이 고정된 일정량
일 때)
29. Global Cache 2
요청 노드가 글로벌 캐시에서 데이터를 질의하여 데이터가 없음을 확인하였을 때는
직접 스토리지에 질의하여 데이터를 가져오는 방식이다.
큰 크기의 파일 제공을 위하여 캐시를 사용하는 경우에, 낮은 캐시 히트가 발생하면 전반적인 캐시 미스가
증가하게 된다.
이 경우에는 자주 사용되는 데이터만 캐시에 위치하게 하는 것이 도움이 된다.
31. Distributed Cache
• 일반적으로 분산 캐시는 consistent hashing 함수를 사
용한다.
• 해시 함수를 이용해 데이터 위치 파악 할 수 있다.
• 각각의 노드는 각각의 조그마한 캐시를 가지고 있다
• 요청이 들어오면 원본 저장 공간으로 요청을 보내기 전
에 다른 노드에 요청을 보낸다.
분산 캐시의 이런 점 때문에 요청 풀에 노드를 추가하면
전체 캐시 크기를 증가시킬 수 있다.
32. Distributed Cache
• 분산 캐시의 단점
장애가 발생한 노드를 처리하는 방법이 필요하다.
다른 노드에 여러 개의 복제본을 가지는 방법으로 해결
하기도
한다.
• 캐시의 장점
올바르게만 구현되어 있다면 시스템을 더욱 빠르게 만들
수 있다
캐시를 이용해 더욱 더 많은 요청을 이전보다 더 빠르게
처리하게 할 수도 있다.
그러나 캐시 시스템에는 값 비싼 메모리와 같은 추가적
인 저장 공간을 유지하기 위한 비용 문제가 항상 따른다.
35. Proxies
Proxies
프락시는 요청을 필터링, 로깅, 변환(헤더에 속성 더하고/빼고, 암호화/복호화, 압
축)하는데 사용 하고 여러 서버에서 오는 요청을 받아 정리하여, 전체 시스템 관점
에서 요청 트래픽을 최적화시키는 데도 도움이 된다.
36. Proxies
Collapsed Forwarding
데이터 액세스를 빠르게 하기 위하여 프락시가 제공하는 방법 중의 하나로
같거나 비슷한 요청들을 모아 단 하나의 요청을 만들어 내는 것을 말한다.
요청을 그룹화하는 데 드는 시간 때문에 각각의 요청에는 더 많은 레이턴시가 발생할
수도 있다.
그러나 부하가 높은 상황에서는 성능이 향상될 것이다.
37. Proxies
프락시를 사용하는 다른 방법으로는 공간적으로 가까운 데이터에 대한 요청을 묶어주는 것이 있다.
이러한 전략은 요청의 데이터 로컬리티를 최대화하여, 요청 지연을 줄일 수 있다.
수많은 요청이 B의 일부분을 요청(B:partB1, B:partB2) -> 프락시는 bigB 를 요청 한다.
이러한 방식은 클라이언트가 수 테라바이트 크기 데이터의 일부분을 랜덤하게 요청할 때 요청 시간을 단
축시킬 수 있다.
프락시는 여러 번의 요청을 한 번에 처리하기 때문에 높은 로드 상황이나 캐시 사용이 제한적인 상황에서
특히 유용하다.
39. Indexes
빠른 데이터 액세스를 위해서 인덱싱 전략을 사용하는 것은 굉장히 잘 알려져 있는 방법이
다.
데이터 크기가 수 테라바이트지만 전달해야 할 데이터 크기가 작을 때는(예를 들어 1KB정
도), 데이터 액세스를 최적화하기 위해 인덱스는 필수적이다.
인덱스는 목차와 같이 데이터가 어디에 위치하는지 알려주는 역할을 한다.
40. Indexes
BerkeleyDB와 트리 형태의 데이터 구조는 이러한 정렬된 리스트를 저장하고
색인을 사용하는 이상적이고 보편적인 방법이라 할 수 있다.
때때로 맵의 형태를 가진 여러 개의 레이어로 이루어진 인덱스도 있다.
41. Load Balancers
로드 밸런서는 어떤 아키텍처에서든 중요하다.
로드 밸런서는 서비스 요청을 여러 노드에게 분배하는 일을 한다.
로드 밸런서의 주 목적은 동시에 오는 수많은 커넥션을 처리하고 해당 커
넥션이
요청 노드 중의 하나로 전달될 수 있게 하는 것이다.
또한 노드를 추가하는 것만으로 서비스가 확장성을 가질 수 있도록 한다.
42. Open Source Load
Balancers
로드 밸런서에서 서비스 요청을 처리하는 방법에는 다양한 알고리즘이 있다.
( 랜덤, 라운드 로빈, CPU나 메모리 사용률 등과 같은 특정 범주에 따라 노드를 선택하는 등의 방법이 있다)
로드 밸런서는 소프트웨어로 구현될 수도 있고 하드웨어 제품이 될 수도 있다.
43. Multiple Load Balancers
프락시처럼 어떤 로드 밸런서는 요청의 종류를 파악하고 해당 요청을 처리
할 수
있는 노드에 전달하는 기능을 가지고 있다
(기술적으로 이러한 형태를 리버스 프락시라고 부른다).
44. Queue
시스템이 확장성 있도록 설계하려면 쓰기에 대한 고려 또한 필요하다.
데이터가 여러 곳에 분산된 서버나 인덱스에 쓰여야 하고 당시의 시스템 부하 상태가
높다면 쓰기 연산은 매우 오랜 시간이 걸리게 된다.
이럴 때 시스템의 성능과 가용성을 얻기 위해서 사용하는 보편적인 방법은 큐를 사용하
는 것이다.
45. Queue
하나의 서버가 들어오는 클라이언트의 모든 요청을 처리하는 작은 시스템이라도 데이
터 양이
적다면 별 문제없이 작동할 수 있다.
하지만 하나의 서버가 자신이 해결할 수 있는 요청보다 더 많은 요청을 받게 되면, 각 클
라이언트는 다른 클라이언트의 요청이 끝나기 전까지 기다려야 한다.
이러한 종류의 동기적인 행동은 클라이언트의 성능을 심각하게 저하시킨다.
46. Queue
이러한 문제를 효과적으로 풀기 위해서는 클라이언트의 요청과 서비스를 처리하기 위해서 처리되는 일
사이에
추상화가 필요하다.
클라이언트가 큐로 작업 요청을 보내고 난 다음에는 그 결과를 기다릴 필요가 없다. 대신 큐에 요청이 잘
쌓였다는
응답(acknowledgement)만 받는다.
큐의 장점은 클라이언트가 비동기 방식으로 동작할 수 있게 한다는 데에 있다.
가용성(Availability): 웹 사이트의 가용성은 많은 회사의 명성과 기능에 절대적으로 중요한 것이다.
분산 시스템에서 높은 가용성을 얻기 위해, 중요한 컴포넌트의 이중화와 실패가 발생했을 경우에 대한 빠른 복구 방법,
문제가 발생할 때 일부만으로 동작할 수 있게 해 전면 장애가 발생하지 않게 하는 구성(graceful degradation)에 대한 고려가 필요하다.
성능(Performance): 대부분의 웹 사이트에서 성능은 매우 중요한 고려사항이다.
결과적으로 빠른 응답 시간과 낮은 레이턴시를 위해서 최적화된 시스템을 만드는 것은 중요하다.
신뢰성(Reliability): 항상 똑같은 요청에는 똑같은 결과를 제공해야 한다. (정합성)
시스템이 항상 정상적으로 동작해야 한다는 말이다.
데이터가 변하거나 업데이트되고 나면 업데이트된 새로운 데이터를 반환해야 한다.
확장성(Scalability): 대규모의 분산 시스템에서라면 규모 자체는 확장성에서 고려해야 할 하나의 측면에 불과하다.
중요한 것은 더 많은 부하를 처리할 수 있도록 처리량을 증가시키기 위해 필요한 노력이다.
관리성(Manageability): 쉽게 운용할 수 있는 시스템을 설계하는 것은 또 다른 중요한 고려 사항이다.
시스템의 관리성이란 운용(유지와 업데이트)의 확장성과 같은 말이다.
관리성이 좋아지려면 문제 발생 시 분석이 용이해야 하며 문제를 이해하기 쉬워야 한다.
그리고 업데이트와 수정, 시스템 운용 자체가 쉬워야 한다
비용(Cost): 비용은 중요한 요소다시스템을 배포하고 관리하는 비용 또한 중요하게 고려해야 한다.
이러한 비용에는 시스템이 빌드하는 데 걸리는 시간, 시스템을 실행시키는 데 드는 운용 노력의 양,
모든 고려해야 할 사항에 대해서 필요한 교육 비용까지 포함된다. 즉 비용은 시스템 소유에 필요한 모든 비용이다.
모든 대규모 웹 애플리케이션에 필요한 핵심 사항인 '서비스들', '이중화', '분할', '예외 처리'를 다룬다.
이러한 사항 각각에 대해서는 앞에서 고려한 사항에 기반한 선택과 합의가 필요하다.
이미지 호스팅 시스템에서는 고려해야 할 다른 측면이 있다.
확장성 있는 시스템을 설계할 때 각각의 명확한 인터페이스를 기반으로 기능별로 나누어 생각하는 것은 좋은 방법이다. 이러한 방식으로 설계하는 시스템을 SOA(Service-Oriented Architecture)라고 부른다. SOA에서는 명확하게 기능별로 서비스를 구성한다. 그리고 각각의 서비스는 다른 서비스와 상호 작용을 위해 다른 서비스에서 공개하는 API 형태인 추상화된 인터페이스를 사용한다.
시스템을 상호 보완적인 서비스로 분할한다는 것은 시스템을 기능 단위로 분리시키는 것을 말한다. 이러한 추상화는 서비스와 서비스가 처한 환경 그리고 서비스와 서비스 사용자 사이의 명확한 관계를 수립하는 데에 도움이 된다. 이러한 명확한 기술은 문제를 분리시키는 데도 도움이 되지만, 각각을 독립적으로 확장시키는 것에도 효과적이다.
빠르고 확장성 있는 데이터 액세스를 위한 빌딩 블록
그 중 가장 중요한 네 가지 방법에는 캐시, 프락시, 인덱스, 그리고 로드 밸런서, 큐 가 있다.
각각의 방법이 어떻게 데이터 액세스를 빠르게 하는지에 대해서 알아보려 한다.