[2023 AWS re:Invent] Amazon Neptune architectures for scale, availability, and insight

by
세션명

Amazon Neptune architectures for scale, availability, and insight (확장성, 가용성 및 통찰력을 위한 Amazon Neptune 아키텍처)

강연자

Ian Robinson

핵심 내용 요약

Amazon Neptune 아키텍처의 확장성, 가용성, 가시성의 기능 및 방법 소개

  1. 확장성
    • CPU 및 Memory 지표 확인을 통해 데이터베이스 확장을 검토 (Buffer cache churn 증상 등)
    • Serverless 사용 검토 –  워크로드 사용 패턴 검토가 필요
    • Multiple Workload의 확장 
      – Cache sharding, Dynamic Custom Endpoint
  2. 가용성
    • Engine Update간  Blue/Green Deployment 방식 지원
  3. 가시성
    • Neptune Notebook
    • Data API
    • Generative AI
세션 키워드
  1. Amazon Neptune – 완전관리형 Graph 데이터베이스
  2. 확장성 – Scale, Serverless
  3. 가용성 – availability, Blue/Green Deployment
  4. 가시성 – insight
세션 요약자

베스핀글로벌 PS본부 D&A실 김정환 님

1. 확장성 – Scale

  • 확장 요구 사항 확인 – CPU나 Memory 지표를 통해 확인
  • 워크로드에 맞는 올바른 Neptune resource를 사용  – 서버리스 사용 검토
  • 리소스의 효율적인 사용 보장 – 다수의 워크로드에 대한 확장

  • 데이터베이스 인스턴스의 모든 Worker Thread가 사용중인 상황일 때 CPU Utilization에 대한 지표 확인
    • High CPU  – Worker thread가 모두 사용 중으로 확장을 검토
    • Low CPU – Storage 대기 상태 –  Network IO 부하 발생

Buffer cache churn
  • 데이터베이스 인스턴스 버퍼캐시가 메인 메모리에 들어갈 수 없는 상황
  • 버퍼 캐시가 가득 차 있을 때 발생하며, 이때 많은 buffer cache churn이 경험된다.
  • 버퍼 캐시 적중률이 낮아지고 자주 발생하면 99.9% 미만으로 떨어지면 성능이 저하될 수 있다.
  • 버퍼 캐시 적중률이 낮아지면 볼륨 읽기 IOPS가 증가할 수 있으며, 모든 추가 데이터 페이지를 가져오기 위해 스토리지로 계속 내려가므로 애플리케이션에서는 작업 완료까지 더 오래 기다려야 한다.
  • Neptune의 과금 중 하나가 IO의 수이므로, 버퍼 캐시가 많이 소모되면 IO 비용이 증가할 수 있다.
  • 작업의 수가 많아지면 Cache가 스토리지 계층으로 계속 내려가므로 해당 차원에서 비용이 증가한다.

Database Resource 최적화
  • 보다 큰 인스턴스로 Scale up – Worker(CPU) 및 buffer cache(Memory) 확장
  •  Reader들을 추가하여 Scale out 한다.
  • 워크로드에 맞는 다른 다른 type의 instance 사용 
    • r5d 시리즈나 x2g/x2iedn 시리즈
    • Serverless 사용 검토

서버리스 사용에 좋은 대상 확인
  •  CPU 사용 메트릭 확인 – 곡선 아래 면적(Area Under curve)이 50% 미만 사용일 때
  •  서버리스와  프로비저닝 방식의 비용을 비교 검토하여 결정

 3가지 패턴에 대한 Serverless 사용 검토
  1. Office hour ( 하루에 6~8시간만 peak, 18시간정도는 유휴, 주말 유휴)
    • – 총 CPU 사용률 –  CPU 사용면적(Area Under Curve) 50% 미만
    • 프로비저닝 방식과 비용 비교
      • 서버리스 : 110$ vs 프로비저닝 : 200$
  2. International hour ( 하루에 18시동안 peak, 6시간 유휴, 주말 유휴)
    • 총 CPU 사용률 – CPU 사용면적(Area Under Curve) 50% 이상
    • Scheduled auto scaling에 좋은 대상
  3. On-off (Peak와 비사용이  7일동안 지속적으로 실행)
    • 프로비저닝 방식과 비용비교 
      • 서버리스 : $70 vs 프로비저닝 : 68$
    • 프로비저닝 과 서버리스가 유사 – 프로비저닝 방식 유지

  • Multiple access pattern
    • 동일한 데이터에 대한 많은 Access 패턴 – 질의, 리포팅,  ML 학습
  • Multiple tenants
    • 자기자신의 dataset을 가진 개별의 고객들
    • 개별적인 데이터 세트에 대해 여러 사용자가 접근하는 구성

문제점
  • 단일 인스턴스로 처리할 수 없는 대규모 Working Set 발생
  • 모든 데이터가 메모리에 저장되지 않아 다양한 워크로드 간 리소스 경쟁
  • 버퍼 캐시에서의 이탈로 인한 추가 비용, 재작업 등 다양한 문제 발생
  • 쿼리 우선순위 미지정으로 모든 쿼리가 리소스 경쟁에 참여
  • 중요한 짧은 실행 시간의 쿼리가 실행 시간이 긴 쿼리에 뒤쳐질 가능성이 있음
  • 여러 워크로드 시나리오에서 효율적인 데이터베이스 리소스 활용을 위한 해결책 필요

  • 캐시 샤딩 기술을 사용하여 데이터베이스 리소스를 효율적으로 활용
  • 이 기술은 특정 워크로드 트래픽을 개별 리플리케이터 또는 서비스 전용 복제본으로 효과적으로 라우팅하는 방식으로 작동
  • 이를 통해 작은 작업 세트를 생성하고 인스턴스 크기 및 버퍼 캐시 크기를 조정할 수 있음
  • 트래픽을 워크로드에 따라 조절하여 특정 복제본 또는 인스턴스 세트를 선택적으로 확장 가능
  • 이러한 기능은 Neptune에 내장되어 있어 복잡한 애플리케이션 로직을 개발하지 않고도 클러스터 토폴로지의 변경을 효과적으로 수용할 수 있음

  • Neptune에는 이러한 문제를 해결할 수 있는 사용자 정의 엔드포인트라는 기능이 내장되어 있음
  • Custom endpoint는 reader endpoint와 유사하지만 사용자가 멤버십 세트를 직접 결정 가능
  • Custom endpoint는 해당 membership group에 속하는 모든 인스턴스 간의 연결을 균형 잡아줌
  • 사용자는 include list나 exclude list를 사용하여 간단한 제어 기능을 얻을 수 있으며, 특정 reader만을 포함하거나 Primary와 reader를 모두 포함하는 endpoint를 생성 가능

  • Custom Endpoint는 애플리케이션 구성이 간단하고 특정 엔드포인트 주소만 설정하면 모든 쿼리 언어와 데이터 모델에서 작동
  • Custom Endpoint는 reader endpoint와 동일한 Connection Swarm 문제를 겪으며 IP 주소가 5초마다 변경되나 연결은 일반적으로 단일 인스턴스에 고정됨
  • 연결이 오래 지속되기 때문에 해당 인스턴스는 잠시 동안 잠긴 상태로 남아있음
  • Custom Endpoint는 모든 트래픽이 단일 인스턴스에 집중될 수 있도록 하는 문제가 있음
  • 이를 해결하기 위해 연결을 재활용하고 10초마다 연결을 재활용하며 DNS 캐시를 최소화하는 것이 권장
  • 사용자 지정 엔드포인트의 구성은 간단하지만 유연성이 부족하며 특정 엔드포인트를 중심으로 의미 있는 시맨틱을 만드는 데 한계가 있음
  • 엔드포인트의 역할이 변경되면 의도치 않게 이전 역할의 멤버로 남을 수 있음

  • 이러한 문제를 해결하기 위한 Dynamic custum endpoint라는 package를 제공
  • 기존 custom endpoint를 사용하여 CloudFormation을 이용하며 lambda와 scheduler를 제공
  • membership group을 설명할수 있는 선언적 사양 기능을 제공
  • 매 1분마다 Lambda 함수를 호출하여 custom endpoint를 update

2. 가용성 – Availability

 Engine Update
  • Major, Minor, Patch 업데이트 지원
  • Patch 업데이트의 경우 자동으로 업데이트되며  14일간 Maintenance window를 부여하여 수동으로 Patch가 가능하게 할 수 있도록함
  • 1.3.0 이후 버전은 자동으로 패치되는 대상이 좀더 엄격해지고  중요한 버그 패치를 자동으로 적용됨

Engine 업데이트 진행시 가용성
  • 업데이트는  database restart가 됨
  • 20-30초에서 몇 분 소요, Major version 업데이트는 30분이상
  • Neptune Blue/Green 배포 지원

Neptune Blue/Green Deployment
  • Neptune Stream 기능 활성화
  • Cloudformation Template을 배포하여 복제 구 성
  • DynamoDB같은 보조 리소스를 사용함
  • 상대적으로 writing 트래픽이 적은 시간에 진행되어야 함
  • Application에서  새 endpoint로 변경해 주어야 함

  • Blue측 Neptune 스트림이 활성화되었는지 확인하고 Dynamo DB vpc endpoint가 있는지 확인
  • Cloudformation Template 배포를 통해 Green Neptune 자동 복제 시작

  • Neptune의 신속한 데이터베이스 복제로 Green 클러스터에 데이터베이스 복사본 생성
  • Green 클러스터에는 이미 대부분의 데이터가 있고, 최근 트랜잭션 ID가 기록됨
  • 복제 프로세스는 해당 트랜잭션 ID를 활용하여 클러스터를 따라 잡음
  • Cloudwatch 로그를 통해 마이그레이션 모니터링이 가능하며  실시간으로 상태 및 트랜잭션 적용 상황 확인 가능

  • 복제가 완료되면  Green Cluster의  업그레이드 시작
  • 여러 번 업그레이드가 진행되며  수십 분이 걸릴 수 있지만 실제로는 애플리케이션에 문제가 되지 않음

  • Target 버전 번호로 업그레이드하면 프로세스는 필요한 읽기 복제본을 추가

  • Neptune 스트림의 변경 데이터 캡처 기록을 통해 모든 기간이 기록되며, 프로세스는 미리 기록한 마지막 트랜잭션 ID를 찾아서 해당 트랜잭션 이후에 스트림의 지점을 설정하고 모든 변경 사항을 적용하여 Blue 클러스터에 적용
  • Replication 로그를 통해 Green측으로 write를 잠시 멈출수 있는 시점을 찾고 어플리케이션의 Endpoint를 전환

  • 어플리케이션의 Endpoint를 전환하고 기존 Cloudfomatin Stack 및 Blue Cluster삭제

3. 가시성 – Insight

  • Neptune 팀은 오픈 소스 소프트웨어로 그래프 노트북과 그래프 탐색기를 개발하여 Graph 커뮤니티에 기여하고 있음
  •  그래프 노트북과 그래프 탐색기는 Apache의 오픈 소스 소프트웨어로 여러 그래프 데이터베이스와 호환됩니다.
  •   Graph Notebook
    • Python 패키지로  주피터 노트북을 통해 데이터베이스와 쿼리 작성 및 시각화가 가능
    • 쿼리 작성에 익숙한 실무자에게 적합
  • Graph Explorer
    • 브라우저 기반의 코드 없는 시각화 환경을 제공하여 속성 그래프와 RDF 데이터를 검색하고 시각화
    • 쿼리를 작성하지 않고 시각적으로 데이터를 탐색하려는 사용자에게 적합
  •  두 도구는 각각 쿼리 작성 및 결과 시각화, 브라우저 기반의 시각화를 중점으로 한 사용자 경험을 제공

Neptune 노트북
  • Neptune 노트북은 쿼리 작성, 애플리케이션 개발 코드 없이 시각화까지 포함한 완전관리형 IDE를 제공
  • 이 환경에는 Graph Notebook, Graph Explorer, 그리고 AWS SDK를 포함한 다양한 라이브러리와 SDK가 함께 제공, boto3와 같은 Python용 AWS SDK뿐만 아니라 pandas용 SDK를 포함하여 다양한 AWS 서비스와 상호 작용할 수 있는 API를 제공, 이를 통해 복잡한 ETL 및 기계 학습 작업을 수행할 수 있음
  • Neptune 노트북은 CloudFormation Template이나 콘솔을 통해 프로비저닝할 수 있으며 Amazon Sage Maker에서 호스팅되므로 클러스터에 연결 및 상호 작용이 용이.  또한 Sage Maker의 다양한 기계 학습 기능을 활용 가능
  •  Neptune 노트북은 사용자가 데이터를 빠르고 쉽게 시각화하고 쿼리를 작성하고 결과를 조정하는 데 중점을 둠. Gremlin, 공개 Cipher, Spark를 활용하여 다양한 쿼리 작업을 수행할 수 있음

  • Neptune Data API는 40여 가지의 다양한 데이터 연산을 제공하며, openCypher,Gremlin, SPARQL을 지원하는 새롭게 출시된 AWS Data SDK
  • Neptune 데이터 API를 사용하면 연결 관리, 서명, 데이터베이스와의 상호 작용 등을 표준 AWS SDK를 통해 간소화할 수 있음
  • Neptune과 상호 작용하기 위한 설정 튜닝이나 드라이버 조정이 Neptune Data API에서 처리
  • 생산성 도구의 한 부분으로, 쿼리와 애플리케이션 코드 개발을 효율적으로 수행할 수 있음

  • Generative AI를 활용하여 애플리케이션 개발과 데이터에서 더 나은 인사이트 도출에 사용되는 세 가지 사용 사례 소개
    1. 언어 모델을 활용하여 그래프 쿼리 작성 사용자의 자연어 질문에 대해  Gremlin, openCypher, SPARQL의 쿼리를 생성함
    2. 그래프 애플리케이션 데이터 모델 설계를 위한 LLM 활용, 도메인에 대한 자연어 설명을 통해 그래프 데이터 모델을 생성
    3. RAG – 외부 소스 호출을 통해 대규모 언어 모델의 결과를 강화

 Generative AI를 사용한 Graph Query
  • Amazon Bedrock, Amazon Neptune, LangChain으로 구성된 아키텍처.
  • Amazon Bedrock은 대규모 언어 모델을 제공하는 관리형 서비스  Anthropic의 Claude V2 모델을 사용
  • LangChain은 오픈 소스 프레임 워크로 Bedrock의 대규모 언어 모델과 Neptune의 외부 데이터 소스 간 상호작용을 중개함

  1. 사용자가 자연어 질문 입력
  2. LangChain이 질문을 받고, Neptune에  쿼리하여  Graph 스키마의 표현을 얻음
  3. 가져온 질문과 스키마로 추가 프롬프트 생성 및 언어 모델에 제출
    • 대규모 언어 모델이 프롬프트를 기반으로 OpenCyper 쿼리 생성
  4. LangChain이  OpenCyper 쿼리를 Neptune에 실행하고 결과를 얻음
  5. 결과를 다시 언어 모델에 제출하고, 자연어로 표현하여 사용자에게 응답 반환
  6.  LangChain이 대규모 언어 모델과 Neptune 간의 모든 상호작용을 중개함
  7.  LangChain은 Neptune에 대해 쿼리 실행하여 결과를 얻고, 이를 언어 모델에 반환함
  8.  사용자는 자연어 응답을 받음

Bespin’s Comment

1. AWS Neptune 시리즈를 Detail하게 확인할수 있는 계기가 되었으며 Graph Database에 대해 알아볼수 있는 기회가 되었습니다.

2. Generative AI와 연동 방법을 통해 Neptune을 활용하는 방법이 인상적이었습니다.