섹션 22: 데이터 & 분석

Athena

• S3 버킷에 저장된 데이터 분석에 사용하는 서버리스 쿼리 서비스
  • 데이터 분석 할려면 표준 SQL 언어로 쿼리 해야함
• 자신의 S3 버킷에 데이터 로드 하면 Athena 사용해서 바로 쿼리 후 분석 가능
• CSV, JSON, ORC, Avro Parquet 등 다양한 형식 지원
• 자주 사용하는 도구
  
  • Amazon QuickSight
    • 보고서와 대시보드를 생성 할 수 있음
  • 아키텍처 흐름
    • S3 -> Athena -> QuickSight
• 사용 사례
  • 임시 쿼리 수행
  • 비즈니스 인텔리전스 분석 및 보고
  • AWS 서비스 발생하는 모든 로그 쿼리 후 분석 가능
    • VPC 흐름 로그
    • 로드 밸런서 로그
    • CloudTrail 추적
    • 등
• 서버리스 SQL 엔진 사용한 S3 데이터 분석은 Athena을 생각하면 됨
• 성능 향상
  • 첫 번째 
    • 비용을 지불 할 때 스캔된 데이터의 TB당 가격 지불
      데이터를 적게 스캔할 유형의 데이터를 사용하면 가격을 덜 지불함
    • 열 기반 데이터 유형을 사용하면 필요한 열만 스캔 가능
  • 두 번째
    • 권장하는 형식을 사용하는 것
    • Apache Parquet, ORC 형식을 사용하면 성능이 크게 향상됨
  • 세 번째
    • 데이터 세트를 분할
    • S3 버킷에 있는 전체 경로를 슬래시로 분할하여 사용
• 오버헤드 최소화
  • 큰 파일을 사용해서 오버헤드를 최소화 시켜야함
  • S3에 작은 파일이 너무 많으면 성능이 떨어짐
  • 128MB 이상의 파일을 사용해야함
• 연합 쿼리
  • S3가 아닌 다른 곳의 데이터도 쿼리가 가능
  • AWS
    • 데이터 원본 커넥터를 사용해서 Lambda 함수로 다른 서비스에서 연합 쿼리 실행
  • 온프레미스 데이터베이스도 쿼리를 할 수 있음

Redshift

• 데이터베이스이면서 분석 엔진임
  • PostgreSQL 기술 기반
  • 온라인 트랜잭션 처리 (OLTP)에 사용은 안함
• 온라인 분석 처리 (OLAP) 유형의 데이터베이스
• 분석과 데이터 웨어하우징에 사용함
• 성능 향상
  • 열 기반 데이터 스토리지를 사용하기에 성능 향상이 가능
  • 행 기반이 아니라 병렬 쿼리 엔진에 있는 것
• 다른 AWS 통합
  • Tableau 같은 도구도 Redshift와 통합이 가능
• Redshift vs Athena
  • Redshift
    • S3에서 모든 데이터를 Redshift에 로드를 한다.
    • 그러면 Redshift의 쿼리가 더 빠르고 조인과 통합을 더 빠르게 함
    • 왜냐하면 Athena에는 없는 인덱스가 있기 때문
    • 데이터 웨어하우스가 높은 성능을 발휘하게 인덱스를 빌드한다.
    • 즉 쿼리가 많고 복잡하고 조인하거나 집계하는 집중적인 데이터 웨어하우스면 적합
  • Athena
    • 인덱스가 없기 때문에 임시 쿼리를 사용 시 적합
• Redshift 클러스터
  • 2개의 노드가 존재
    • 리더 노드
      • 쿼리를 계획하고 결과 집계
    • 컴퓨팅 노드
      • 실제로 쿼리 실행하고 결과를 리더 노드에게 전달
  • 클러스터는 노드 크기를 미리 프로비저닝을 해야한다.
  • 비용 절감을 할려면 예약 인스턴스를 사용하면 됨
• 일부 클러스터 타입은 다중 AZ 모드 가능
  • 재난 복구 전략이 적용됨
• 단일 AZ일 경우에 재난 복구 전략을 사용 할려면 ?
  • 스냅샷을 사용해서 S3 내부에 지정 시간 백업 가능
  • 스냅샷에는 두 가지 모드 존재
    • 수동
      • 직접 스냅샷을 삭제하기 전까지 스냅샷이 유지됨
    • 자동
      • 스냅샷이 8시간마다 또는 5GB마다 자동으로 생성되도록 일정 예약 가능
      • 자동화된 스냅샷의 보존 기간을 설정 할 수 있음
• Redshift 데이터 주입 방법 세 가지
  • Amazon Kinesis Data Firehose
  • S3 데이터 로드 후 Redshift에서 복사 명령 실행
  • JDBC 드라이버를 사용해서 데이터 삽입
• Redshift Spectrum
  • 분석은 하지만 Redshift에 로드는 하지 않음
  • 로드를 하지 않기에 더 많은 처리 능력이 생김
  • 쿼리를 시작할 수 있는 Redshift 클러스터가 필요
  • 예시
    • S3에 쿼리 요청
    • Redshift Spectrum이 자동으로 시작하여 S3 데이터 읽어서
      Redshift Spectrum 노드에 제출
    • 결과 Redshift Spectrum 클러스터를 통해 쿼리를 시작한 곳으로 전송

오픈서치(예: ElasticSearch)

• Amazon ElasticSearch의 후속작
  
  • 이름 변경은 라이선싱 문제때문
• 예시
  • DynamoDB에서 기본 키나 인덱스만으로 쿼리를 할 수 있지만?
  • OpenSearch를 사용하면 모든 필드를 검색 할 수 있다.
• 분석적 쿼리에도 사용이 가능
• OpenSearch 클러스터 프로비저닝 2가지 모드가 있음
  • 관리형 클러스터
    • 실제 물리적인 인스턴스가 프로비저닝이 됨
    • 확인이 가능함
  • 서버리스 클러스터
    • 스케일링부터 운영까지 모두 AWS에서 관리
• OpenSearch에는 자체 쿼리 언어가 있음
  • 플러그인을 통해서 SQL 호환성 활성화가 가능함
• Kinesis Data Firehose, AWS IoT, CloudWatch Logs 등 다양한 곳 에서 받는게 가능
• 보안은 Cognito, IAM 등을 통해 제공
• OpenSearch 대시보드로 시각화 가능
• 흔한 사용 패턴
  • 첫 번째 
    • DynamoDB -> DynamoDB Stream -> Lambda -> OpenSearch
    • 항목 이름으로 부분 검색을 하여 항목 ID를 찾아서 DynamoDB에 호출해서 결과 받기 가능
  • 두 번째
    • CloudWatch Logs -> Subscription Filter -> Lambda -> OpenSearch
      • 실시간으로 전달
    • CloudWatch Logs -> Subscription Filter -> Kinesis Data Firehose -> OpenSearch
      • 근 실시간 전달
  • 세 번째
    • kinesis Data Streams -> Kinesis Data Firehose -> Lambda(사용 할 경우 데이터 변환 가능) -> OpenSearch
      • 근 실시간 전달
    • Kinesis Data Streams -> Lambda -> OpenSearch
      • 실시간으로 전달

EMR

• Elastic MapReduce
• 빅 데이터 작업을 위한 하둡 클러스터 생성에 사용이 됨
• 방대한 양의 데이터를 분석하고 처리 할 수 있음
• 하둡 클러스터가 있는 빅데이터에 사용을 하는 것
• 하둡 클러스터는 프로비저닝을 해야함
  • 수백 개의 EC2 인스턴스로 구성이 될 수 있음
• 왜 EMR을 사용하는가 ?
  • 빅 데이터 전문가가 사용하는 여러 도구와 함께 제공이 됨
  • Apache Spark, HBase, Presto, Apache Flink
  • 설정이 어려운데 EMR이 위에 서비스들을 프로비저닝과 구성을 대신 해줌
  • 전체 클러스터를 자동으로 확장 할 수 있음
• 사용 사례
  • 기계 학습
  • 웹 인덱싱 빅 데이터 작업
• 모든 작업은 하둡, Spark, HBase, Presto, Flink 같은 빅 데이터 기술을 사용
• EMR은 EC2 인스턴스의 클러스터로 구성이 된다
  • 노드 유형
    • 마스터 노드
      • 클러스터를 관리, 다른 모드 노드 상태 조정를 하며 장기 실행 (온디맨드, 예약)
    • 코어 노드
      • 태스크를 실행하고 데이터를 저장 장기 실행 (온디맨드, 예약)
    • 태스크 노드
      • 테스트만 실행하는 태스크 노드 단기 실행 (스팟)
  • 1년 이상 사용할경우 예약 인스턴스를 사용하는게 좋음
  • 가능한 경우 EMR이 자동으로 예약 인스턴스 사용함

QuickSight

• 서버리스 머신 러닝 기반
• 비즈니스 인텔리전스 서비스
  • 대화형 대시보드를 생성
• 대시보드를 생성하고 소유한 데이터 소스와 연결 함
• 사용 사례
  • 비즈니스 분석
  • 시각화 구현
  • 시각화된 정보로 임시 분석 수행
  • 데이터를 활용한 비즈니스 인사이트 획득
• 다양한 데이터 소스에 연결이 가능
  • RDS, Aurora, Athena, Redshift, S3 등..
  • 타사 데이터 소스 Salesforce, Jira 등..
  • 온프레미스 데이터베이스 JDBC 프로토콜 가능
  • Excel, CSV, JSON, TSV (SPICE로 가져옴)
  • 로그 형식 ELF, CLF (SPICE로 가져옴)
• SPICE 엔진
  • QuickSight에 데이터를 직접 가져올 때 사용
  • 인 메모리 연산 엔진임
  • 다른 DB에 연결돼 있을 때는 작동하지 않음
• 스탠다드 버전에서는 사용자 정의
  엔터프라이즈 버전에서는 그룹 정의
  • QuickSight의 사용자와 그룹은 IAM 사용자와는 다름
    • IAM 사용자는 관리용임
• 대시보드는 읽기 전용 스냅샷이며 분석 결과 공유 가능
  • 분석 구성 저장
• 액세스 권한이 있는 사용자는 기본 데이터 열람 가능
• 특정 사용자나 그룹과 공유 가능

Glue

• 추출과 변환 로드 서비스를 관리 ETL 서비스라고도 함
• 분석을 위해 데이터 준비, 변환 할 때 매우 유용
• 서버리스 서비스
• 사용 예시
  • 첫 번째 
    • S3, RDS 데이터 -> ETL로 추출 후 필터링하거나 변형 -> Redshift에 로드
    • Glue ETL 서비스에서 모든 작업이 이뤄진다.
  • 두 번째
    • Input S3 -> Glue ETL (Parquet 변환) ->  Output S3 -> Athena (성능 향상)
    • Input S3에서 Lambda를 사용해서 Glue ETL 작업 트리거 하면 자동화가 됨
• Glue Data Catalog
  • 1. Glue 데이터 크롤러를 실행해서 S3, RDS, DynamoDB, 온프레미스 JDBC에 연결
  • 2. 데이터베이스의 테이블 열, 데이터 형식등의 모든 메타 데이터를 Catelog에 저장
  • 3. ETL을 수행하기 위한 모든 DB, 메타데이터를 갖게 됨
• Glue 작업 북마크
  • 새 ETL 작업을 실행 할 때 이전 데이터 재처리를 방지 한다.
• Glue Elastic Views
  • SQL를 사용해 여러 데이터 스토어의 데이터 결합, 복제를 함
  • 예시
    • RDS, Aurora 데이터베이스를 S3에 걸친 뷰를 생성 할 수 있다.
• Glue DataBrew
  • 데이터 정리하고 정규화
• Glue Studio
  • ETL 작업을 모니터링하는 GUI
• Glue 스트링 ETL
  • Apache Spark Structured Streaming 위에 빌드 됨
  • 배치 작업이 아닌 스트리밍 작업으로 실행
  • Kinesis Data Streaming Kafka, MSK에서 해당 스트링 ETL을 사용해 데이터를 읽을 수 있다. 

Lake Formation

• 데이터 레이크 생성을 돕는 서비스
• 데이터 레이크란?
  • 데이터 분석을 위해 모든 데이터를 한곳으로 모아 주는 중앙 집중식 저장소
• 수개월씩 걸리는 작업을 며칠 만에 완료 할 수 있음
• 데이터 레이크에서의 검색, 정제, 변환 주입을 돕는다.
• 블루프린트 제공
  • 데이터를 데이터 레이크로 이전하는것을 도움
  • S3, RDS, 온프레미스에서 실행되는 RDBMS, NoSQL 지원
• Lake Formation을 설정 하는 이유
  • 모든 데이터를 한곳에서 처리
  • 애플리케이션에서 행, 열 수준의 세분화된 액세스 제어 가능
• Lake Formation은 왜 사용하나요?
  • 중앙화된 권한
    • 보안을 관리할 곳이 많아지면은 Lake Formation을 사용
      • S3, RDS, Aurora -> Athena -> Quicksight 흐름이면 4개 다 보안관리를 하기에 힘들어짐

Kinesis 데이터 분석

• 두 가지 종류가 있음
  • SQL 애플리케이션용
  • Apache Flink용
• SQL 애플리케이션용
  • Kinesis Data Strams, Kinesis Data Firehose 데이터 읽기 가능
  • 거기에 추가로 SQL문에 적용하여 실시간 분석 처리로 데이터 읽기 가능
  • 거기에 추가로 S3 버킷 데이터를 참조 데이터 조인하여 데이터 읽기 가능
  • 즉 Kinesis Data Strams, Kinesis Data Firehose, SQL, S3를 읽는 것
  • Kinesis Data Streams에 전송 할 경우
    • Lambda
    • EC2
  • Kinesis Data Firehose에 전송 할 경우
    • S3
    • Redshift
    • OpenSearch
    • 등
• Apache Flink용
  • 애플리케이션을 작성하고
  • 스트리밍 데이터를 처리, 분석 할 수 있음
  • 첫번째 유형과 다른점은 Flink는 코드로 작성해야 하는 특별한 애플리케이션임
  • Kinesis Data Streams, MSK 데이터를 읽을 수 있음
  • Flink는 표준 SQL 보다 훨씬 강력하기 때문에
    • 고급 쿼리 능력이 필요하거나
    • Kinesis Data Streams
    • AWS 관리형 Kafka인 MSK
  • 스트리밍 데이터를 읽는 능력이 필요 할 때 사용한다.
  • Kinesis Data Firehose의 데이터는 읽지 못함

MSK - Managed Streaming for Apache Kafka

• Apache Kafka용 Amazon 관리형 스트리밍 서비스 (MSK)
• Kafka는 Amazon Kinesis의 대안
  • 두 서비스 모두 데이터를 스트리밍 함
• MSK는 AWS의 완전 관리형 Kafka 클러스터 서비스
  • 그때그때 클러스터를 생성, 업데이트, 삭제함
• VPC 클러스터를 최대 세 개 다중 AZ 전역에 배포 (멀티 AZ)
• EBS 볼륨에 데이터 저장 가능
• Apache Kafka 설정이 어려운데 클릭 한번으로 배포 할 수 있어서 편리성 제공
• Apache Kafka란?
  • 데이터를 스트리밍 하는 방식 (실시간으로 데이터를 스트리밍)
  • Kafka 클러스터는 여러 브로커로 구성이 된다.
  • 클러스터에 주입을 하면은? 해당 데이터는 다른 브로커로 완전 복제 됨
  • 소비자는 데이터를 소비하기 위해 주제를 폴링(가져옴)함
  • 폴링 후 EMR, S3 SageMaker, Kinesis RDS 등 대상으로 보냄
• Kinesis Data Stremas vs Amazon MSK 차이점
  • Kinesis Data Streams
    • 1MB 메시지 크기 제한
    • 샤드로 데이터를 스트리밍 (파티션이랑 비슷)
    • 용량 확장시 샤드 분할을, 용량 축소시 샤드 병합을 한다.
  • MSK
    • 1MB가 기본이고 최대 10MB 까지 가능
    • 파티션을 이용한 Kafka 주제를 사용 (샤드랑 비슷)
    • 용량 확장시 파티션 추가만 가능, 제거가 불가능함
    • EBS 스토리지 비용 지불하면 1년 이상 데이터 보관 가능

빅 데이터 수집 파이프 라인

• 쿼리 및 분석 과정에서 흔히 발생하는 빅데이터 문제를 해결 할 수 있음
• 예시
  • 데이터 생산자가 IoT 장치
  • AWS 클라우드 서비스 중 IoT Core가 있음
  • IoT 장치 관리를 돕는 서비스임
  • IoT 기기(IoT Core 사용) -> Kinesis Data Streams -> Kinesis Data Firehose(거의 1분마다 스트림 받음) -> S3(수집 버킷)
    • Kinesis Data Firehose에서 Lambda를 통해 빠른 속도로 데이터를 정리하거나 변형이 가능
    • S3(수집 버킷)에서 SQS 대기열 작동 가능(선택 사항)
      • SQS 대기열 -> Lambda -> Athena(SQL 생성) -> S3(수집버킷)
      • SQL 생성한거를 S3(리포팅 버킷) 다른 버킷으로 전달해서 정리, 분석 가능
        • S3(리포팅 버킷) -> QuickSight, Redshift로 가능
        • 여기에서 Redshift -> QuickSight의 엔드포인트로 작용한다.