Software-defined storage is a marketing buzzword for promoting computer data storage technologies. Many storage H/W vendors are focusing on Storage Cloud in Software Defined Data Center. This document is that what is SDS and latest trend in Cloud Computing.
Apache kafka performance(latency)_benchmark_v0.3SANG WON PARK
Apache Kafka를 이용하여 이미지 데이터를 얼마나 빠르게(with low latency) 전달 가능한지 성능 테스트.
최종 목적은 AI(ML/DL) 모델의 입력으로 대량의 실시간 영상/이미지 데이터를 전달하는 메세지 큐로 사용하기 위하여, Drone/제조공정 등의 장비에서 전송된 이미지를 얼마나 빨리 AI Model로 전달 할 수 있는지 확인하기 위함.
그래서 Kafka에서 이미지를 전송하는 간단한 테스트를 진행하였고,
이 과정에서 latency를 얼마나 줄여주는지를 확인해 보았다.(HTTP 프로토콜/Socket과 비교하여)
[현재 까지 결론]
- Apache Kafka는 대량의 요청 처리를 위한 throughtput에 최적화 된 솔루션임.
- 현재는 producer의 몇가지 옵션만 조정하여 테스트한 결과이므로,
- 잠정적인 결과이지만, kafka의 latency를 향상을 위해서는 많은 시도가 필요할 것 같음.
- 즉, 단일 요청의 latency는 확실히 느리지만,
- 대량의 처리를 기준으로 평균 latency를 비교하면 평균적인 latency는 많이 낮아짐.
Test Code : https://github.com/freepsw/kafka-latency-test
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
Understanding of Apache kafka metrics for monitoring SANG WON PARK
2019 kafka conference seould에서 발표한 "Apache Kafka 모니터링을 위한 Metrics 이해" 슬라이드 자료
기존 2018년 자료에서 모니터링 관점에서 중요한 metrcis를 중심으로 정리하였고, 2019년 기준으로 추가/변경된 metrics를 반영하였다.
주용 내용은
- 업무에 최적화된 apache kafka 모니터링을 하려면?
- 어떤 정보를 모니터링 해야 할까?
- 적시성 관점의 모니터링 지표 (TotalTimeMs에 대한 세부 구조 이해)
- 안정성 관점의 모니터링 지표 (데이터 유실이 없이 중단없는 서비스)
- 언제 apache kafka 클러스터를 확장해야 할까? (어떤 지표를 봐야 할까?)
위 모든 지표는 producer/broker/consumer 3가지 측면에서 검토하였다.
컨퍼런스 영상 링크 : https://www.youtube.com/watch?v=p2RGsTOCHAg
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다.
기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다.
우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다.
이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다.
RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다.
지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다.
NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다.
아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다.
NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다.
NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다.
Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다.
Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다.
DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다.
NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다.
감사합니다.
The document discusses minimizing downtime in systems by allowing them to self-recover without human intervention. It notes that around 50% of failures are due to human error and lists strategies like including fault observers for detection, recovery blocks for handling errors, and maintenance interfaces to minimize human intervention while still allowing management. The goal is for systems to handle routine tasks automatically while reducing procedural errors.
Software-defined storage is a marketing buzzword for promoting computer data storage technologies. Many storage H/W vendors are focusing on Storage Cloud in Software Defined Data Center. This document is that what is SDS and latest trend in Cloud Computing.
Apache kafka performance(latency)_benchmark_v0.3SANG WON PARK
Apache Kafka를 이용하여 이미지 데이터를 얼마나 빠르게(with low latency) 전달 가능한지 성능 테스트.
최종 목적은 AI(ML/DL) 모델의 입력으로 대량의 실시간 영상/이미지 데이터를 전달하는 메세지 큐로 사용하기 위하여, Drone/제조공정 등의 장비에서 전송된 이미지를 얼마나 빨리 AI Model로 전달 할 수 있는지 확인하기 위함.
그래서 Kafka에서 이미지를 전송하는 간단한 테스트를 진행하였고,
이 과정에서 latency를 얼마나 줄여주는지를 확인해 보았다.(HTTP 프로토콜/Socket과 비교하여)
[현재 까지 결론]
- Apache Kafka는 대량의 요청 처리를 위한 throughtput에 최적화 된 솔루션임.
- 현재는 producer의 몇가지 옵션만 조정하여 테스트한 결과이므로,
- 잠정적인 결과이지만, kafka의 latency를 향상을 위해서는 많은 시도가 필요할 것 같음.
- 즉, 단일 요청의 latency는 확실히 느리지만,
- 대량의 처리를 기준으로 평균 latency를 비교하면 평균적인 latency는 많이 낮아짐.
Test Code : https://github.com/freepsw/kafka-latency-test
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
Understanding of Apache kafka metrics for monitoring SANG WON PARK
2019 kafka conference seould에서 발표한 "Apache Kafka 모니터링을 위한 Metrics 이해" 슬라이드 자료
기존 2018년 자료에서 모니터링 관점에서 중요한 metrcis를 중심으로 정리하였고, 2019년 기준으로 추가/변경된 metrics를 반영하였다.
주용 내용은
- 업무에 최적화된 apache kafka 모니터링을 하려면?
- 어떤 정보를 모니터링 해야 할까?
- 적시성 관점의 모니터링 지표 (TotalTimeMs에 대한 세부 구조 이해)
- 안정성 관점의 모니터링 지표 (데이터 유실이 없이 중단없는 서비스)
- 언제 apache kafka 클러스터를 확장해야 할까? (어떤 지표를 봐야 할까?)
위 모든 지표는 producer/broker/consumer 3가지 측면에서 검토하였다.
컨퍼런스 영상 링크 : https://www.youtube.com/watch?v=p2RGsTOCHAg
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다.
기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다.
우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다.
이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다.
RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다.
지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다.
NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다.
아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다.
NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다.
NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다.
Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다.
Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다.
DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다.
NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다.
감사합니다.
The document discusses minimizing downtime in systems by allowing them to self-recover without human intervention. It notes that around 50% of failures are due to human error and lists strategies like including fault observers for detection, recovery blocks for handling errors, and maintenance interfaces to minimize human intervention while still allowing management. The goal is for systems to handle routine tasks automatically while reducing procedural errors.
This document provides information about Facebook, including:
1. Facebook is an online social networking service founded in 2004 by Mark Zuckerberg that allows users to create profiles, share photos and messages, and connect with friends.
2. The document discusses Facebook's history and growth, privacy settings, applications platform, and advertising features.
3. It also covers benefits of using Facebook for businesses and individuals, as well as some problems Facebook has faced such as bans in some countries and overcrowding at public events.
The document summarizes an intellectual property case between Bajaj Auto Ltd. and TVS Motor Company Ltd. regarding Bajaj's patent on an internal combustion engine technology. Bajaj alleged TVS' new 125cc motorcycle infringed its patent. TVS argued the patent was invalid and its engine did not infringe. The court initially granted Bajaj an injunction but it was overturned on appeal. The Supreme Court allowed TVS to sell its product while maintaining sales records, appointing a receiver to oversee this.
This document defines and describes different camera shots and angles used in filmmaking, including establishing shots, extreme long shots, long shots, medium shots, close ups, over the shoulder shots, point of view shots, bird's eye views, and low angle shots. It explains what each shot shows or emphasizes and common purposes they serve in setting scenes and portraying characters.
The document discusses the concepts of truth and the lie according to Christianity. It explores how Jesus is the truth and the way to the Father. It describes how the devil is the father of lies and deceives humanity. It argues that the Holy Spirit reveals the truth about sin, righteousness, and judgment. It emphasizes developing an intimate relationship with the truth, which is Jesus, and that God reveals the deceit in people's hearts. The goal is for people to acknowledge their sin and need for God's righteousness in Christ.
The document describes various characters that could be part of a story, including the main girl, a vampire lover boy, a wizard best friend, Irish and funny wizard guys, a caring and mature wizard, a little brother, an evil sister, two other vampire sisters including one who is lost, vampire brothers of Justin including Ryan Kingsley and an eldest vampire brother, a mother vampire, Count Dracula, Niall's girlfriend, a baby girl, and Darcy's best friend. It concludes by questioning if Justin will get revenge and asking if the author should make a sequel.
The logo design process involves several steps: 1) Reviewing the client brief and asking questions to understand their needs, 2) Thoroughly researching the client's industry and target audience, 3) Brainstorming ideas through group sessions and analyzing competitors, 4) Sketching and drafting multiple concepts with attention to detail, 5) Digitalizing the drafts using design software, 6) Presenting concepts and getting feedback to finalize the design, and 7) Delivering the finalized logo on time.
The Bourne-Again Shell by Chet Ramey
from The Architecture of Open Source Applications I (http://aosabook.org/en/bash.html)
@ Eva
Focus on Bash as interpreter, rather than System shell.
인터프리터 동작에 초점을 맞춰 진행했습니다.
This document discusses various theories of entrepreneurship motivation. It describes McClelland's theory of need for achievement, which proposes that entrepreneurs are driven by a need to accomplish difficult tasks and get feedback on their performance. It also discusses Schumpeter's view of entrepreneurs as drivers of innovation and economic change. Various characteristics of highly motivated achievers are outlined, as are different needs for achievement, power, affiliation, security, and status. Theories by Maslow, McGregor, and Herzberg on work motivation are also compared. Emerging behavioral patterns of successful entrepreneurs are identified, such as setting their own standards, enjoying learning and experimenting, and never becoming fully satisfied with their achievements.
Creative accounting refers to accounting practices that follow legal requirements but deviate from the intent of accounting standards to portray a misleadingly positive image of a company's financial position. While legal, the loopholes exploited by creative accounting are often later reformed. Common creative accounting techniques include overstating assets by keeping obsolete items on the balance sheet, understating expenses such as depreciation, misclassifying items to manipulate revenue and expense reporting, and misrepresenting accounts receivable, payable, and inventory values. The lack of a "true and fair view" in creative accounting can mislead auditors and regulators and was a factor in scandals like Enron.
클라우드에서 인프라 구축 시 고려해야 할 사항들을 살펴보고, 네이버 클라우드 플랫폼을 활용하여 고가용성을 유지하는 방안에 대해 소개합니다. | 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 를 클라우드 환경으로 이관할 때 유의해야할 포인트들에 대해 함께 공유합니다.
[EVA] 5. Detection Patterns - Patterns for Fault Tolerant Softwareeva
This document discusses patterns for fault detection in software systems. It describes a priori detection using constraints on system states, results and side effects. It also covers comparing redundant results to identify faulty components, and using techniques like Bayesian learning to determine correct system behavior. Finally, it distinguishes between detecting errors, failures, and faults, noting that errors should be detected and corrected before resulting in failures through techniques like fail-silent crash detection and try/catch blocks.
This document discusses software updates and the importance of minimizing downtime when applying them. It notes that software will need changes over time to fix faults or add features. While the system is unavailable during updates, high availability is important. The document suggests designing systems that can apply updates with little or no downtime by allowing new software versions to run alongside old ones or replacing only specific parts of an application. It also stresses testing compatibility and fault tolerance when planning for updatable systems.
The document discusses various techniques for designing fault-tolerant systems, including having a fault-tolerant mindset, performing design tradeoffs that balance reliability and availability, keeping designs simple, and incrementally adding reliability over time. It also covers defensive programming techniques, data structure design, coding standards, redundancy approaches, static analysis tools, and fault insertion testing. The document proposes a six-step fault-tolerant design methodology involving assessing failures, defining risk mitigation strategies, creating system models, making architectural decisions, designing error handling capabilities, and considering human interfaces.
The document discusses patterns for implementing plug-ins in Android applications. It introduces plug-in patterns, how they can make applications more flexible and configurable, and how to design software components as independent and interchangeable plug-ins. It then covers organizing Android apps using the application framework and activity lifecycle. The rest of the document details specific plug-in patterns like plug-in contracts, lifecycles, registration, and packaging plug-ins for different tasks, languages, and resources. The goal is to explain techniques for designing Android apps that can incorporate external plug-ins to extend functionality.
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 형태인 추상화된 인터페이스를 사용한다.
시스템을 상호 보완적인 서비스로 분할한다는 것은 시스템을 기능 단위로 분리시키는 것을 말한다. 이러한 추상화는 서비스와 서비스가 처한 환경 그리고 서비스와 서비스 사용자 사이의 명확한 관계를 수립하는 데에 도움이 된다. 이러한 명확한 기술은 문제를 분리시키는 데도 도움이 되지만, 각각을 독립적으로 확장시키는 것에도 효과적이다.
빠르고 확장성 있는 데이터 액세스를 위한 빌딩 블록
그 중 가장 중요한 네 가지 방법에는 캐시, 프락시, 인덱스, 그리고 로드 밸런서, 큐 가 있다.
각각의 방법이 어떻게 데이터 액세스를 빠르게 하는지에 대해서 알아보려 한다.