기본 콘텐츠로 건너뛰기

[AWS] Kinesis 개념 정리


What is STREAM

DATA가 모이는 흐르는 곳
Stream에 모이는 데이터는 유니크한 Partition Key로 각 Shard에 분산됨.
(Shard수에 의해 분산되는 Shard가 달라짐)

What is Shard

샤드는 스트림에서 고유하게 식별되는 데이터 레코드 시퀀스입니다. 스트림은 하나 이상의 샤드로 구성되며 각 샤드는 고정된 용량 단위를 제공합니다. 각 샤드는 최대 읽기: 5개의 초당 트랜잭션, 최대 총 데이터 읽기 속도: 초당 2MB 및 최대 쓰기: 1,000개의 초당 레코드, 최대 총 데이터 쓰기 속도: 초당 1MB(파티션 키 포함)를 지원할 수 있습니다. 스트림의 데이터 용량은 스트림에 지정하는 샤드 수의 함수입니다. 스트림의 총 용량은 해당 샤드의 용량의 합계입니다.

데이터 속도가 증가하면 스트림에 할당된 샤드 수를 늘리거나 줄일 수 있습니다. 자세한 내용은 스트림 리샤딩 단원을 참조하십시오.

Stream에 모여있는 데이터를 컨슈머(데이터를 사용하는 서버) 전달하는 입구
Stream을 작성할 때 샤드 수를 설정가능(샤드 수가 많을 수록 비용이 비싸짐)
Stream내부에 데이터를 취득하기 위한 샤드가 미리 정해져있음
(Stream에 데이터를 등록한 시점에 그 데이터를 어느 샤드에 취득 가능하는지 구별됨)
















What is Partition Key

  • 파티션 키는 스트림 내에서 샤드별로 데이터를 그룹화하는 데 사용
  • Kinesis Data Streams는 스트림에 속한 데이터 레코드를 여러 샤드로 분리
  • 각 데이터 레코드와 연결된 파티션 키를 사용하여 해당 데이터 레코드가 속한 샤드를 확인
  • 최대 길이 제한이 256자인 유니코드 문자열,파티션 키를 128비트 정수 값에 매핑하고 샤드의 해시 키 범위를 사용하여 연결된 데이터 레코드를 샤드에 매핑하기 위해 MD5 해시 함수가 사용

데이터 분활 룰

파티션 키: 최대 256바이트 unicode문자열
->Hashing 128 정수로 매핑(해시 키) -> Hashed Integer를 받은 샤드에 데이터가 보내짐

MD5 최대치 16진수: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
이것을 10진수로 변환한 최대치 :340282366920938463463374607431768211455

Kinesis 1 shard의 범위는 0~340282366920938463463374607431768211455 해시 키가 분배됨

샤드를 4분활 할 경우

shard1: 0 ~ 85070591730234615865843651857942052863
shard2: 85070591730234615865843651857942052864 ~ 170141183460469231731687303715884105727
shard3: 170141183460469231731687303715884105728 ~ 255211775190703847597530955573826158591
shard4: 255211775190703847597530955573826158592 ~ 340282366920938463463374607431768211455

구체적 예)

1. partition-key-0001 문자열을 해시키로 함
2. Hashing하면 b7681e2243f62f440887b6d38c002537 16진수를 얻음
3. 10진수로 변환하면 243789333289005976465737331408549979447
4. shard1-shar4의 범위를 참고하면 shard3에 해당하기때문에 파티션 키를 partition-key-0001를 지정한 데이터는 shard3에 흘러감

참고

Kinesis Client Library

Kinesis Client Library는 결함이 있어도 정상적으로 스트림의 데이터를 소비할 수 있도록 애플리케이션에 컴파일됩니다. Kinesis Client Library는 각 샤드에 대해 해당 샤드를 실행하고 처리하는 레코드 프로세서가 있도록 보장합니다. 또한 라이브러리는 스트림에서 데이터를 읽는 과정을 간소화합니다. Kinesis Client Library는 Amazon DynamoDB 테이블을 사용하여 제어 데이터를 저장하며, 데이터를 처리하는 애플리케이션마다 테이블 하나를 만듭니다.


REFFERENCE



댓글

이 블로그의 인기 게시물

기본적인 MongoDB 사용/자바연동

mongoDB 명령어 db: 현재 사용 중인 데이터베이스 확인 -test :Default로 들어가 있는 test 테이블 show dbs : DB의 리스트 확인 show collections : collection 리스트 확인, collection = table in mongoDB show tables : 위 명령어와 같음 db.stats() : 데이터베이스 상태 확인 db.(db명).drop(): 안에 있는 데이터 삭제 mongod --version => mongodb 확인 mongo -version => shell 확인 use 테이블 명: 테이블 생성 db.dropDatabase() : 접속된 테이블 삭제 -테이블 확인 필요!! db.createCollection(“테이블 명”): 테이블 생성 db.테이블 명.drop(): 테이블 지움 db.blog[테이블 명].insert({“name ” : “ nodejs”}) : 내용(Document)을 추가 db.테이블 명.insert([ {“ ” : “ ”},{“ ” : “ ”}]); -여러 Documents를 하나의 테이블에 넣는 방법 db.blog[테이블 명].find() : 내용 확인 db.테이블 명.find().pretty() : 보기 좋게 검색 id : primary key를 자동으로 부여해줌 db.테이블 명.remove({“name” : “book01”}) : 특정한 Documents를 지우는 법 insert 문 count 문 연산자 몽고디비 비교 연산자 $eq 2. $gt 3. $gte 4. $lt 5. $lte ne : 주어진 값과 일치 하지 않는 값 in: 주어진 배열 안에 속하는 값 nin: 주어진 배열 안에 속하지 않는 값 몽고디비 논리연산자 1.$or: 주어진 조건 중 하나라도 true일

자바FX 설치하기(펌)

필요한것 최신 Java JDK 8 (JavaFX 8 포함) Eclipse 4.6 또는 e(fx)clipse 플러그인을 포함한 그 이상 버전. 가장 쉬운 방법은 e(fx)clipse website 에서 미리 포함되어 있는 버전을 받습니다. 다른 대안으로는 Eclipse에서 update site 를 이용할 수 있습니다. Gluon이 제공하는 Scene Builder 8.0 (왜냐하면 Oracle은 오직 소스 코드 형태로만 제공 하기 때문입니다.) Eclipse 설정 Eclipse가 JDK 8과 Scene Builder를 사용할 수 있게 해야 합니다: Eclipse Preferences를 열어 *Java | Installed JREs*를 찾습니다. *Add..*를 클릭한 후 *Standard VM*를 선택, JDK 8이 설치되어 있는 *디렉토리*를 고릅니다. 다른 JRE나 JDK를 삭제합니다. 그러면 JDK 8 하나만 남습니다. *Java | Compiler*를 찾아 Compiler compliance level을 1.8로 설정합니다. JavaFX  부분을 찾아 Scene Builder 실행 파일이 있는 경로를 지정합니다. JavaFX 프로젝트 만들기 e(fx)clipse를 설치하고 나서 Eclipse에서  File | New | Other… , *JavaFX Project*를 고릅니다. 프로젝트 이름(예:  AddressApp )을 작성한 다음, *Finish*를 클릭합니다. 자동으로 생성되는  application  패키지가 있다면 삭제하세요. 패키지 만들기 시작부터 우리는 좋은 소프트웨어 디자인 원칙을 따를 겁니다. 가장 중요한 원칙이  모델-뷰-컨트롤러 입니다. 이에 따라 우리의 코드를 세 단위로 나누고 각 패키지를 만듭니다 (src 디렉토리에서 마우스 오른쪽 클릭 후  New… | Package  선택): ch.makery.address  - 컨트롤러 클래스의  대부분  (

Twelve-Factor 마이크로서비스 서비스 애플리케이션 구축

Practice DevOps! • 코드베이스(codebase): 모든 애플리케이션 코드와 서버 프로비저닝(provisioning) 정보는 버전 관 리(version control)되어야 한다. 각 마이크로서비스는 소스 제어 시스템 안에 독립적인 코드 저장소 를 가져야 한다. • 의존성(dependencies): 애플리케이션이 사용하는 의존성을 메이븐(자바) 같은 빌드 도구를 이용해 명시적으로 선언해야 한다. 제3자(3 rd party)의 JAR 의존성은 특정 버전 번호를 붙여 명시해 선언해 야 한다. 따라서 동일 버전의 라이브러리를 사용해 항상 마이크로서비스를 빌드할 수 있다. • 구성(config): 애플리케이션 구성(특히 환경별 구성)을 코드와 독립적으로 저장하자. 애플리케이션 구성은 절대로 소스 코드와 동일한 저장소에 있으면 안 된다. • 백엔드 서비스(backing services): 마이크로서비스는 대개 네트워크를 거쳐 데이터베이스나 메시징 서비스와 통신한다. 그렇다면 언제든 데이터베이스 구현을 자체 관리형 서비스에서 외부업체 서비스 로 교체할 수 있어야 한다. 10장에서 로컬에서 관리되는 Postgres 데이터베이스를 AWS 데이터베 이스로 옮기면서 이를 보여 준다.  • 빌드, 릴리스, 실행(build, release, run): 배포할 애플리케이션의 빌드, 릴리스, 실행 부분을 철저히 분리하라. 코드가 빌드되면 개발자는 실행 중에 코드를 변경할 수 없다. 모든 변경 사항을 빌드 프로 세스로 되돌려 재배포해야 한다. 빌드된 서비스는 불변적이므로(immutable) 변경할 수 없다. • 프로세스(processes): 마이크로서비스는 항상 무상태(stateless) 방식을 사용해야 한다. 서비스 인 스턴스 손실에 의해 데이터가 손실될 것이라는 우려 없이 언제든 서비스를 강제 종료하거나 교체할 수 있다. • 포트 바인딩(port binding): 마이크로서비스는 서비스용 런타임 엔진을 포함한(실행 파일에 패키징 된 서비스를 포