Apache Kafka vs AWS Kinesis

Apache Kafka

apache kafka에 대한 이미지 검색결과

Definition

2010년 LinkedIn에서 플랫폼 사용자들의 수 많은 구인구직 정보들을 한 곳에서 효율적으로 관리하기 위해 개발한 Open Source Message Queue System.

Context

개발 배경 스토리는 아래와 같다. (출처: InsideBIGDATA)

  1. LinkedIn 의 Architecture Migration (from Monolith to Microservice)
  2. Mid-tier Service의 Data Model/Back-end Service로 API 접근 횟수 증가
  3. 이를 Service 별로 처리하기 위한 Service 별 여러 Data Pipeline들을 구축
  4. Site Traffic에 따라 개별 Data Pipeline들이 Autoscaling 하지 못하는 문제 발생
  5. 이에 Autoscaling이 가능한 단일 Distributed Pub-Sub Platform 개발 필요 발생
  6. 아래 Design Principles에 입각하여 개발
    – 심플한 API (producers & consumers양측 모두)
    – 높은 정보처리량(throughput)
    – Scale-out 방식 아키텍쳐

Use-case

현재 Kafka를 사용하는 기업 (출처 : Apache Kafka)
LinkedIn, Twitter, NetFlix, Spotify, Uber, Goldman Sachs, PayPal, Airbnb …
*Globally하게 Tech-savvy한 기업들.. Open Source 운용에는 DevOps팀 또는 그에 준하는 인력이 필요하다고 여실히 보여진다.

작동 방식

Kafka 의 작동 방식에 관해서는 DevTimes Blog 에 깔끔하게 잘 설명되어 있으니 참고.
기존 Message Queue System 과의 차이점에 대해 간략히 요약하자면,

  • Producer ~ Broker : 개별 메시지 전송 뿐만 아니라 Batch 전달 가능
  • Broker :  Memory 가 아닌 File System에 메시지 저장
  • Broker ~ Consumer : Consumer 메시지 Push 받는 방식이 아닌 Pull 하는 방식

장점

쉽고 빠르고 강력하고 확장성 좋다.

약점

관리가 어렵다.

.

AWS Kinesis
관련 이미지

 

Definition

AWS의 Streaming Data를 위한 Platform

Context

Kinesis = re-brand(Apache Kafka) + service*

AWS Kinesis 는 Apache Kafka 를 reference하여 개발되었다.
위에서 service* 라고 함은 크게 두 부류로 파악된다.

  1. 관리 서비스  (Kafka 의 약점)
    – 서버 집합 모니터링·확장·관리
    – 소프트웨어 스택 유지·관리
    – 클러스터 보안 관리
  2. 타 AWS 서비스와 연계 편의성

.

결국 Kafka 나 Kinesis 의 역할은 둘다 마찬가지로 데이터 파이프라인이며  목적은 데이터 이동간 Seamless, Real-time 효익 달성에 초점이 맞추어져 있다.

Kinesis 는 비즈니스 용도에 따라 그에 특화된 서비스 상품을 출시했다.

  1. AWS Kinesis Video Stream : 영상 처리 및 분석 용도
  2. AWS Kinesis Data Stream : 범용
  3. AWS Kinesis Firehose : 저장(to AWS S3, Redshift, Elastic Search) 용도
  4. AWS Kinesis Data Analytics : 분석 용도

Use case

현재 Kinesis 를 사용하는 기업 (출처 : Stackshare)
Instacart, Lyft, Intuit, Zillow, Tilt, AgoraPulse, Custora, GoGuardian …

기타 참고

주요 개념 비교 (출처 : IT Cheer Up)

Concepts Apache Kafka AWS Kinesis Data Streams
Data Storage Partitions Shards
Data Ordering In partition level In shard level
Data Retention No maximum (configurable) 1 to 7 days (default is 24 hours)
Data Size Per Blob Default 1MB (but can be configured) Maximum 1 MB
Partition/Shard Modification Increase only and does not repartition existing data Re-shard by merging or splitting shards
Partition/Shard Limitation No limit. Optimal partitions depend on the use case 500 shards in US East (N. Virginia), US West (Oregon), and EU (Ireland) regions. 200 shards in all other regions.
Data Replication/DR Cluster mirroring Automatically across 3 Availability Zones
Message Delivery Semantics Kafka guarantees at-least-once delivery by default. Kafka supports exactly-once delivery in Kafka Streams Kinesis Data Streams has at least once semantics
Security Either SSL or SASL and authentication of connections to Kafka Brokers from clients; authentication of connections from brokers to ZooKeeper; data encryption with SSL/TLS Data can be secured at-rest by using server-side encryption and AWS KMS master keys on sensitive data within KDS. Access data privately via your Amazon Virtual Private Cloud (VPC)
Monitoring Yammer Metrics for metrics reporting in the server AWS CloudWatch and CloudTrail
Dependency ZooKeeper DynamoDB
Cost Requires a lot of human support on installation, set up, configuration and clusters management. Setup in weeks Pay and use. Setup in a couple Of hours

Apache Kafa 와  AWS Kinesis Architecture (출처: Cloudurable, AWS)

kafka vs kinesis

참고 링크
Amazon Kinesis 홈페이지
Apache Kafka 홈페이지
Epic Developer 블로그
Medium 블로그

광고

가상머신(Virtual Machine) vs 컨테이너(Container)

*본 내용은 소프트웨어정책연구소 이슈리포트 2018-008 / 안성원 저 요약본입니다.

가상화 개념

가상화(Virtualization)는 물리적인 컴포넌트(Components, HW장치)를 논리적인 객체로 추상화 하는 것을 의미하는데, 마치 하나의 장치를 여러 개처럼 동작시키거나 반대로 여러 개의 장치를 묶어 마치 하나의 장치인 것처럼 사용자에게 공유자원으로 제공할 수 있어 클라우드 컴퓨팅 구현을 위한 핵심기술이다.
가상화의 대상이 되는 컴퓨팅 자원은 프로세서(CPU), 메모리(Memory), 스토리지(Storage), 네트워크(Network)를 포함하며, 이들로 구성된 서버나 장치들을 가상화함으로써 높은 수준의 자원 사용율(물리서버 10~15% vs 가상화 70% 이상) vs 과 분산 처리 능력을 제공할 수 있다.
가상화 개념

가상머신

가상화를 통하여 구현되는 복제된 컴퓨팅 환경.
운용목적1. 하나의 하드웨어위에 동시에 여러 종류의 운영체제나 프로토콜을 실행
운용목적2. 하나의 하드웨어 자원을 여러 사용자에게 분할
운용목적3. 가상화를 통해 분할된 시스템 간 상호 간섭이 없는 독립성(Isolation)을 보장

하이퍼바이저

공유 컴퓨팅 자원을 관리하고 가상머신들을 컨트롤(I/O  명령  처리) 하는 중간관리자.

컨테이너

모듈화되고 격리된 컴퓨팅 공간 또는 컴퓨팅 환경을 의미하며, 시스템 환경 의존성을 탈피하고 안정적으로 구동.

컨테이너 기술의 등장 배경 : 개발한 프로그램이 구동환경의 달라짐에 따라 예상하지 못한 각종
오류를 발생시키는 것을 해결하기 위함 (= 컴퓨팅 환경 간 이식성 ↑)

가상머신과 컨테이너의 차이점

  1. 컨테이너는 가상화에서 하이퍼바이저와 게스트OS 불필요
  2. 대신, 컨테이너는 OS 레벨에서 프로세스를 격리하여‘모듈화된 프로그램 패키지’로써 수행함
  3. 따라서 컨테이너는 가상머신보다 가볍고(수십 MB) 빠름
  4. 이는 더 많은 응용프로그램을 더 쉽게 하나의 물리적 서버에서 구동시키는 것을 가능케 함containers-101.png

초간단 요약

1 컨테이너 = ( 1 하이퍼바이저 + Σ 게스트OS )

표 요약
VM vs Container.JPG

컨테이너 기술 Leading Vendors : 쿠버네틱스(Kubernetes), 도커(Docker)

출처
2018. 12. 10. 제2018-008호 클라우드 가상화 기술의 변화 – 컨테이너 기반의 클라우드 가상화와 DevOps / 안성원 소프트웨어정책연구소
https://cloud.google.com/containers/?hl=ko

아키텍처 유형 별 비교, 장단점 요약

1. 집약형

Keyword : #기간시스템 #Host #MainFrame #범용장비

장점👍 간단한 구성
👍 높은 안정성
👍 고성능
단점👎 높은 도입 및 유지 비용
👎 낮은 확장성

2. 분할형

Keyword : #Server

장점👍 낮은 도입 비용
👍 높은 확장성
단점👎 서버 수 증가에 따른 유지 관리 어려움

2.1. 수직 분할형

Keyword : #역할별분할

2.1.1. 클라이언트-서버

Keyword : #단말기

장점👍 클라이언트 측에서 처리 부담 적음
(=소수 서버로 다수 클라이언트 처리 가능)
단점👎 클라이언트 측 SW 정기 업데이트 필요
👎 서버 부하 집중 시 확장성 한계

2.1.2. 3계층형

Keyword : #Presentation #Application #Data

장점👍 서버 부하 집중 개선
👍 클라이언트 SW 정기 업데이트 불필요
👍 처리 반환에 의한 서버 부하 저감
단점👎 C/S 구성보다 복잡한 구조

2.2. 수평 분할형

Keyword : #Scalability

2.2.1. 단순 수평 분할형

Keyword : #Sharding #Partitioning

장점👍 확장성 향상
👍독립적인 운영
단점👎 데이터 Single View 불가
👎 애플리케이션 업데이트를 양쪽에서 동시에 실시하거나,
처리량 불균등할 경우 서버별 처리량이 불균형해짐

2.2.2. 공유형

Keyword : #RealApplicationClusters

장점👍 확장성 향상
👍 분할된 시스템이 다른 시스템 데이터 참조 가능
단점👎 분할된 시스템 간 독립성 낮음
👎 공유한 계층의 확장성 낮음

2.3. 지리 분할형

2.3.1 스탠바이형

Keyword : #Active-Standby #HighAvailablity #2대이상의물리서버 #Failover

장점👍 물리 서버 고장에 대처 가능
단점👎 리소스 낭비 발생

2.3.2. 재해 대책형

Keyword : #DisasterRecovery

장점👍 재해 대처 가능
단점👎 별도 사이트 서버 구축 비용
👎 애플리케이션 및 데이터 동기화 비용

2.3.3. 클라우드형

Keyword : #SaaS #IaaS #PaaS #DBaaS

장점👍 전개 속도
👍 낮은 초기 구축 비용
단점👎 보안 이슈
👎 네트워크 연장 문제

*위 아키텍처 유형들은 배타적인 관계가 아니며, 대부분의 시스템에서 혼용됨

출처 : 그림으로 공부하는 IR 인프라 구조 / 야마자키 야스시·미나와 요시코·아제카츠 요헤이·사토 타카히코 지음

콘웨이의 법칙 (Conway’s Law)

콘웨이의 법칙이란..

“시스템의 구조는 그것을 설계하는 조직의 커뮤니케이션 구조를 닮는다. (organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations)”

— Melvin Conway, 1967
  • 1967년 프로그래머 멜빈 콘웨이가 제안한 법칙
  • 시스템 구조는 설계하는 조직의 커뮤니케이션 구조를 닮게 된다.
  • 조직의 구조가 시스템 아키텍처 설계에 영향을 준다.

MIT나 하버드처럼 잘 알려진 일부 조직이 이 법칙을 신중하게 생각했다. 그들은 콘웨이의 법칙에 관한 연구를 수행하면서, 개발 조직의 구조와 그 조직이 개발 중인 코드를 비교했다. 그리고 콘웨이의 법칙이 믿을만하다는 사실을 발견했다! 연구를 위해 다양한 영역에서 선택한 90%의 코드는 콘웨이의 법칙을 완벽하게 따른다.
– 마이크로서비스 아키텍처, 우메쉬 램 샤르마 p.42

출처:
https://en.wikipedia.org/wiki/Conway%27s_law
https://zetawiki.com/wiki/%EC%BD%98%EC%9B%A8%EC%9D%B4%EC%9D%98_%EB%B2%95%EC%B9%99
http://tomtunguz.com/conways-law
http://www.hbs.edu/faculty/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf

마이크로서비스 아키텍처, 우메쉬 램 샤르마

SOA 서비스 개념

SOA

Oracle® Reference Architecture and Service Orientation Release 3.0, 2010.09

 

계약 (Contract)

SOA 서비스를 사람이 읽을 수 있는 용어로 표현한 것.
비즈니스 영역에서 가용한 SOA 서비스의 역량에 대해 기술함.
역량은 기능적, 비기능적 측면을 모두 포괄함.

*비기능적 측면:  semantics, invocation style, security/transaction requirements, quality of service 등

구현 (Implementation)

계약의 기술적 실제화(realization).
기존 시스템이나 새롭게 개발된 코드를 통해 구현함.

*인프라스트럭쳐 구성요소는 SOA 서비스의 일부로 취급됨

인터페이스 (Interface)

소비자에게 서비스 계약 상 기능들에 접근하는 수단을 제공함.
인터페이스는 소비자를 구현으로부터 분리시며,
소비자는 인터페이스에 의해 기능 및 데이터 접근이 제한됨.