Daily Record

한국금융연수원 클라우드 데이터 플랫폼 2일차

13 min read

시작하며

연수 2일차에는 NoSQL 개념부터 HDFS, Spark, Data LakeHouse, Kafka, Kinesis까지 데이터 플랫폼의 핵심 기술 스택을 폭넓게 다뤘다. AWS 관리형 서비스(RDS, DynamoDB, Lambda, RedShift)와 Kafka, Kinesis를 이용한 스트리밍 실습도 진행했다.

본 강의 내용

Schema on Write vs Schema on Read

  • Schema on Write : 데이터를 저장할 때 미리 스키마를 정의하고 그에 맞게 적재한다.
  • Schema on Read : 데이터를 읽을 때 스키마를 적용한다. 적재 시점의 유연성이 높다.

NoSQL 이란?

Schemaless, Schema-Free O(1) 조회 성능 Unlimited Scale-out : 제약 없는 확장이 가능하도록 설계

  • key-value : String-JSON 구조
  • document : 한 장의 데이터를 전부 JSON으로 구조화한 경우
  • Column-Family : 컬럼 기준으로 데이터를 보유 — HBase, Cassandra
  • Graph : 그래프DB

DHT : Distributed Hash Table

어떤 데이터가 어떤 서버에 있는지를 파악해서 가져오는 것이 핵심이므로 데이터가 어디에 분산되어 있는지 아는 것이 중요하다. CAP 이론 : 모든 데이터베이스는 CAP에서 최대 2가지를 만족시킬 수 있다. DB가 새로 들어왔을 때 DHT가 어떤 방식으로 동작하는지를 파악한다면 그 DB가 어떤 특성을 가지는지 대략적으로 알 수 있다.

HADOOP

HADOOP : 더그 커팅이 시작(루신과 너치의 창시자). 검색엔진에 특화된 상태로 제작하기 시작했다.

크롤링한 데이터가 워낙 컸기 때문에 unlimited size, parallel이 필수가 되었다.

Search Engine : 역인덱싱을 통해 문서의 위치를 파악한다. 추가로, 정배열 여부, 단어들이 떨어진 정도(GAP) 등을 검색 키워드와 비교해 우선순위로 나열한다.

→ Object Storage + Processing Engine(Data Locality) : 네트워크 I/O를 발생시키지 않고 데이터가 있는 곳에 로직이 가서 부하를 최소화한다.

Object 특징 : Immutable(Update에 약함), No Directory, Metadata, Grouping

HDFS

하나의 블럭이 2GB라고 하면, 2GB = 256MB × 8 Data Node에 분산하여 저장한다. Name Node에서 원 데이터에 대한 순서 정보 등의 메타 정보를 저장한다.

각 DataNode에서 Mapper를 통해 파일 조각마다 로직을 돌린다.(이 예제에서는 8개) 이후 Reducer를 통해 로직의 결과를 취합한다.

현재의 관점에서는 오히려 속도가 느리다(과거에는 빨랐으나!) → 그래서 Hive → Impala 등을 계속 학습해야 한다.

HDFS 디자인 오류

메타 정보를 관리하는 NameNode에서는 데이터를 메모리에서 관리하는데, 데이터의 용량이 커져버리면 데이터를 넣기가 힘들다.

SPARK

HADOOP에 비해 심플한 스택으로 구성하여 내부적으로 Java 기반 Scala를 통해 Java, Python, Scala를 쉽게 구현할 수 있다.

RDD(Resilient Distributed DataSet) : 내부적으로 분산되어 있는 데이터셋 → Lazy 실행 (실제 작업이 바로 수행되는 것이 아니라, 일단 계획만 세워두고 명령이 들어오면 실행한다)

→ DataFrame 코드를 통해 작성할 수도 있다. → Spark SQL을 통해 SQL문으로 사용할 수 있다.

결국 다양한 레벨, 다양한 성능으로 활용할 수 있다. 쿠버네티스에 대한 지원이 많아지고 있다. Resource Manager는 YARN에서 Kubernetes로 점차 넘어가고 있다.

Data LakeHouse

Data Catalog + DataLake + Data Warehouse + Data Lineage

  • Data Fabric : 모든 데이터를 하나의 공간(분산 시스템)에 모아야 제대로 분석할 수 있다(= Data Lake). 이를 좀 더 구조화한 것이 Data Warehouse이다.
  • Data Mesh : 원하는 시간에 원하는 공간에 데이터를 보내는 집합(data pipeline의 집합)

결국 목표는 잘 만들어진 RDW(Real Time DW)를 구성하는 것이다.

Elastic LoadBalancing 제품

  • ALB (Application Load Balancer) : L7 레벨에서 HTTP/HTTPS 요청을 라우팅
  • NLB (Network Load Balancer) : L4 레벨에서 TCP/UDP 요청을 처리
  • CLB (Classic Load Balancer) : 이전 세대

Auto Scaling

Auto Scaling용 CloudWatch 메트릭을 기반으로 인스턴스 수를 자동 조절한다.

EBS 볼륨

EC2 인스턴스를 위한, 사용자 지정 가능한 영구 블록 스토리지

RDS

AWS 관리형으로 지원되는 데이터베이스 서비스. 이런 서비스는 Private Subnet에 올려두고, Public Subnet에 bastion 서버를 띄워서 이를 통해 접속한다.

다중 AZ를 통한 고가용성

다중 AZ 배포를 통해 장애 발생 시 자동으로 대기 인스턴스로 페일오버된다.

Amazon DynamoDB

NoSQL 데이터베이스 테이블로, 캐시 서버처럼 많이 사용한다. 내부적으로 파티셔닝을 사용한다. 한 서버에는 여러 파티션 키가 있을 수 있지만, 파티션 키가 같다면 반드시 같은 서버에 저장된다.

AWS Lambda

서버를 프로비저닝하거나 관리하지 않고 코드를 실행할 수 있는 컴퓨팅 서비스

Exadata 특징

MPP InfraStructure : 분산 키를 통해 여러 Node에 균등 분산 저장된다. 데이터베이스를 디자인할 때 MPP에 대한 고민이 필요하다.

RedShift (Red: Oracle은 비켜!)

컬럼 기반 데이터 웨어하우스. Glue에서 migration하여 RedShift로 데이터를 이동한다. Leader Node에 쿼리가 인입되면 Compute-Node에서 연산이 진행된다.

분산

  • EVEN 분산
  • KEY 분산
  • ALL 분산

정렬

  • Zone Map : 각 Block에 대한 최대값 및 최소값

MySQL HeatWave

HeatWave : MySQL 네이티브 고성능 인메모리 분석 기능. 기존 OLTP 트랜젝션을 처리하는 공간은 그대로 유지한 상태에서, 대용량 트랜젝션이 들어왔을 때 옵티마이저가 비용을 계산하여 OLTP 옵티마이저에서 돌릴지, 분석 쿼리 옵티마이저에서 돌릴지 판단한다. 인메모리 서버(VM)를 최대 250대까지 추가할 수 있어 OLTP와 OLAP 기능을 동시에 수행할 수 있다.

Kafka

  • schema registry : 정형 데이터 등을 강제한다. schema registry에 데이터 형태를 저장해서 확인한다.

  • kafka connect : 외부 시스템과의 연동을 담당

  • kafka streaming : 스트림 처리 기능

  • 특징 1. Page Cache : OS의 페이지 캐시를 적극 활용한다.

  • 특징 2. Heap Memory : 굉장히 작은 메모리로도 띄울 수 있다.

  • 특징 3. 파티션-컨슈머 관계 : 파티션 별로 하나의 컨슈머만 바라볼 수 있다. 반대로 컨슈머는 여러 파티션에서 데이터를 가져올 수 있다.

    • key가 같으면 같은 파티션에 저장되며, 같은 파티션에 저장되면 순서가 보장된다.
    • 일반적으로 파티션의 개수와 컨슈머의 개수를 1:1로 맞춘다.

  • replica & partition

    • replica : 데이터 안정성을 의미. replica의 개수는 broker의 개수를 넘을 수 없다.
    • partition : 병렬성을 의미. partition의 개수는 broker 개수와 관련없다.

실습 1. Kafka broker 간단하게 생성 후 컨슘

1. 서버 생성
 
2. java & kafka 설치
    - sudo yum install -y java-1.8.0-openjdk-devel.x86_64
    - wget https://downloads.apache.org/kafka/3.4.0/kafka_2.13-3.4.0.tgz
    - tar xvf ./kafka_2.13-3.4.0.tgz
    - ln -s kafka_2.13-3.4.0 kafka
 
3. Kafka Broker & Zookeeper 서버 시작
    - cd ~/kafka
    - nohup ./bin/zookeeper-server-start.sh config/zookeeper.properties > zookeeper.log &
    - nohup ./bin/kafka-server-start.sh config/server.properties > kafka.log &
 
4. 서버 상태 확인
    - sudo netstat -anp | egrep "9092|2181"
 
5. Kafka Topic 생성
    - ./bin/kafka-topics.sh --create --bootstrap-server 127.0.0.1:9092 --replication-factor 1 --partitions 1 --topic demotopic
    - ./bin/kafka-topics.sh --list --bootstrap-server 127.0.0.1:9092
 
6. (새 터미널) Kafka Producer에서 Topic으로 메세지 전송
    - kafka/bin/kafka-console-producer.sh --broker-list 127.0.0.1:9092 --topic demotopic
    - (데모 메세지 입력)
 
7. (새 터미널) Kafka Consumer에서 Topic 메세지 컨슘
    - kafka/bin/kafka-console-consumer.sh --bootstrap-server 127.0.0.1:9092 --topic demotopic --from-beginning

Kinesis

  • 자유롭게, 방향성을 가지고 움직이는 유기물에 대한 메타포어
  • app log, metric, clickstreams 등 real-time big data에 적합
  • automatically replicated synchronously to 3 AZ
서비스설명
Kinesis Streams스트림 데이터 수집
Kinesis Analytics스트림 데이터 실시간 분석
Kinesis FirehoseFluentd, Logstash 등과 같이 데이터를 이동시켜 적재하는 수단
  • Kafka의 partition(Kinesis에서는 shard)과 같이, shard 내에서는 순서를 보장한다.

AWS Kinesis vs AWS SQS

  • AWS SQS : Push 기반이므로, 타겟이 명확한 경우에 주로 사용한다.
  • AWS Kinesis : Pulling 기반, 타겟이 명확하지 않은 경우에 주로 사용한다.
    • Kinesis가 Kafka와 유사하다고 볼 수 있다.

실습 2. AWS Kinesis

1. CLI를 통해 stream 생성하기
    - aws kinesis create-stream --stream-name kbi-0127-stream-03 --shard-count 3
    - (생성확인) aws kinesis describe-stream-summary --stream-name kbi-0127-stream-03
 
2. kinesis stream 정보 확인
    - aws kinesis describe-stream --stream-name kbi-0127-stream-03
    - stream list만 조회 시 : aws kinesis list-streams
 
3. 각 파티션 별로 데이터 주입하기
    - aws kinesis put-record --stream-name kbi-0127-stream-03 --partition-key 1 --data test-data-1
    - aws kinesis put-record --stream-name kbi-0127-stream-03 --partition-key 2 --data test-data-2
    - aws kinesis put-record --stream-name kbi-0127-stream-03 --partition-key 3 --data test-data-3
 
4. 데이터 iterator 가져오기
    - aws kinesis get-shard-iterator --shard-iterator-type TRIM_HORIZON --stream-name kbi-0127-stream-03 --shard-id shardId-000000000002
    # TRIM_HORIZON: 가장 오래된 레코드부터 읽기 시작
    # LATEST: 가장 최근부터 읽기 시작
 
5. 데이터 가져오기
    - aws kinesis get-records --shard-iterator {ITERATOR_VALUE}
 
6. kinesis 모니터링 활성화
    - aws kinesis enable-enhanced-monitoring --shard-level-metrics ALL --stream-name {STREAM_NAME}
 
7. kinesis 데이터 스트림 삭제
    - aws kinesis delete-stream --stream-name {STREAM_NAME}

정리하며

NoSQL의 특징인 Schemaless와 O(1) 조회 성능, HDFS/Spark의 분산 처리 원리, Kafka와 Kinesis의 스트리밍 차이(Push vs Pull)까지 데이터 플랫폼의 핵심 기술들을 살펴봤다. RedShift의 MPP 구조와 MySQL HeatWave의 OLTP/OLAP 통합 방식은 실무에서 데이터 웨어하우스 선택 시 중요한 기준이 된다. Kinesis 실습을 통해 CLI로 스트림 생성부터 데이터 produce/consume까지의 전체 흐름을 직접 확인했다.

최근 게시글

68건 더보기 →

그래프 뷰

최근 게시글

68건 더보기 →