그래프 데이터베이스

• 그래프 데이터베이스는 노드 Nodes, 관계 Relationships, 프로퍼티 Properties 로 된 데이터를 저장하는 데이터베이스
• 개념
  • Node: 그래프에서의 개체 Entity
  • Relationship: 노드 간의 관계에 대한 이름
  • Property: Node 및 Relationship에 대한 속성들
• RDB와 비교 비유
  • Label은 RDB의 테이블
  • Node는 레코드(Row)
  • Property는 필드(Column)
  • Relationship은 관계. 딱히 대응시킬 개념은 없는듯

사용하는 이유

• 대량의 복잡한 데이터 핸들링에 용이함
• 기존 RDB에서 JOIN 연산은 비용이 비쌈
• 그래프 데이터베이스는 JOIN 연산이 없음
  • 관계를 더 유연한 포맷으로 네이티브하게 저장함으로써, 데이터 조회 비용도 낮추고 속도도 더 빠르게 최적화됨

많이 사용하는 GraphDB

• Neoj4
• ArangoDB
• 등
• 조금 더 자세한 내용은 아래 링크
  • [GraphDB] 그래프 데이터베이스 오픈소스 정리

• Neo4j Community Edition
  • 가장 많이 쓰이는 그래프 데이터베이스
  • Cypher라는 쿼리 언어 사용
  • 주로 관계 탐색, 소셜 네트워크 분석, 온톨로지 관리에 사용됨
• ArangoDB Community Edition
  • 다중 모델 데이터베이스
  • 그래프, 문서, 키-값 데이터 모두 관리 가능.
  • AQL (ArangoDB Query Language) 사용하여 그래프 쿼리 실행
  • 복잡한 관계 데이터 모델링, 온톨로지 관리, 문서형 데이터 통합
• JanusGraph
  • 유연한 그래프 쿼리 작성 가능.
  • 분산형 아케틱처 지원하여 대규모 데이터에서도 효율적
  • Apache TinkerPop의 Gremlin 쿼리 언어를 사용
  • Cassandra, HBase, ScyllaDB 같은 분산 데이터베이스 및 Elasticsearch, Solr 등의 검색 엔진 지원
  • 대규모 그래프 데이터 처리, 소셜 네트워크, 지식 그래프, 온톨로지 관리
• OrientDB Community Edition
  • 그래프와 문서형 데이터베이스가 결합된 멀티 데이터베이스
  • SQL과 유사한 쿼리 언어 제공
  • 관계형 데이터베이스와 그래프 데이터베이스의 혼합 사용
  • 데이터 분석 및 온톨로지 관리
• Apache TinkerPop과 Gremlin Server
  • 그래프 프로세싱을 위한 프레임워크로 다양한 DBMS와 함께 사용
  • Gremlin은 복잡한 그래프 탐색에 유용한 쿼리 언어
  • 다양한 그래프 데이터베이스와 연동 가능
  • 그래프 분석, 온톨로지와 지식 그래프 구축

PostgreSQL 로 온톨로지 DB 구축 시 주의점

• 다소 복잡할 수 있음

• 온톨로지 특성상 RDB보다 GraphDB 가 더 적합한 경우가 많음

• 데이터 스키마 설계

  • 개념 테이블: 온톨로지 개념 저장할 수 있는 테이블
  • 속성 테이블: 각 개념에 포함된 속성을 저장하는 테이블
  • 관계 테이블: 개념 간 관계 테이블

• JSON 데이터 타입 활용

  • PostgreSQL JSONB 타입 활용
    • JSONB 칼럼에 개념이나 관계에 대한 속성을 넣어 필요에 따라 필드 수정하지 않아도 됨

• 공통 테이블 표현식(CTE) 및 재귀 쿼리 활용

  • 공통 테이블 표현식(CTE)와 재귀 쿼리 사용하여 계층적 데이터 구조 쿼리
    • 하나의 개념 -> 하위 개념 탐색 쿼리 가능

• 인덱스 최적화

  • JSONB 필드 사용할 경우, GIN 인덱스 활용

• PostGIS

  • 지리적 정보 관리

• SPARQL 및 그래프 DBMS 와 연동

  • PostgreSQL은 SPARQL을 기본적으로 지원하지 않음
  • 외부 SPARQL 엔진과 PostgreSQL 연동
    • PostgreSQL의 데이터를 그래프 데이터베이스에 동기화

장점

• 기존 온톨로지 관리 소프트웨어보다 속도 및 안정성 활용 가능
• JSONB와 같은 유연한 데이터 타입을 통해 다양한 데이터 효율적 저장 가능

단점

• 관계형 DBMS로 그래프처럼 계층적 구조를 구현하고 관리하면 다소 복잡함
• SPARQL과 같은 온톨로지 전용 쿼리 언어를 직접적으로 사용할 수 없음
  • 따라서 그래프 DBMS와 연동하여 SPARQL 사용하는거네

온톨로지 데이터베이스

• 개념과 관계가 체계적으로 정의 및 구조화 된 것
• 주로 특정 도메인에서의 객체나 개체간의 관계를 나타내는 데이터 구조
• 자연어 처리, 검색 엔진, 지식 관리 시스템 등에서 많이 사용됨

온톨로지 구성요소

1. 개념(Entity): 특정 도메인의 주요 항목
   • 차량, 사람, 도로
2. 속성: 각 개념이 가지는 특성
   • 차량 - 제조사, 모델명
3. 관계: 개념들 간 연결 및 상호작용
   • '사람'은 '차량'을 '소유'한다
4. 규칙 및 제약: 개념과 관계에 대한 규칙 정의 -> 데이터의 일관성과 유효성 보장

온톨로지 구조 설계

• 데이터 모델링: 개념(Entity), 속성, 관계, 규칙 구조화
  • RDF (Resource Description Framework), WOL (Web Ontology Language) 같은 표준 포맷 사용
• 계층화: 개념을 계층적으로 구성 -> 데이터 구조 명확히 유지
  • 개념의 상하위 관계 정의
  • 특정 개념 그룹화

데이터베이스 및 자료 관리

• 그래프 데이터베이스: 온톨로지의 관계성 때문에 그래프 DBMS 사용이 효과적
  • 그래프DB: 노드와 엣지 구조를 이용해 개념과 관계를 시각화 및 관리
  • Neo4j, Blazegraph, Amaonze Neptune,...
• 문서형 데이터베이스: 개념과 관계가 매우 복잡하거나 변화가 잦은 경우 MongoDB 같은 문서형 DB
  • JSON-LD 같은 표준 사용해 문서 형태로 관리
• 트리플 스토어: RDF 트리플을 저장하는 DBMS
  • RDF, SPARQL 쿼리 지원하여 데이터 추출 및 분석 용이
  • Apache Jena, Virtuoso,...

온톨로지 편집 및 관리 기능 개발

• CRUD 기능: 개념, 속성, 관계를 생성, 조회, 수정, 삭제 할 수 있는 인터페이스 구현
• 시각화 도구: 개념 및 관계를 그래프로 시각화하여 사용자 경험 향상
  • 노드-엣지 그래프 동적 생성
  • D3.js, Cytoscape.js 같은 시각화 라이브러리 활용
• 버전 관리: 온톨로지 버전 관리 기능으로 변경 사항 추적. 필요시 이전 버전으로 롤백
• SPARQL 쿼리 인터페이스: 사용자나 개발자가 SPARQL 쿼리를 통해 온톨로지 탐색 및 분석
  • SPARQL API 제공하는 것이 유용

계기

개발 진행 중, 체인 데이터가 깨지는 이슈가 발생하였으나 컨테이너의 health 체크 및 재시동에 이슈가 발생하였음
현재는 본인이 3년전에 세팅한 Docker Swarm 으로 컨테이너 오케스트레이션 중이나, 서비스 고도화로 인한 오케스트레이션해야 할 컨테이너가 다양해지고 많아짐
컨테이너 health 상태 체크 및 정상화에 대한 기능이 필요해짐
서비스 운영시의 서버 문제 발생 및 리소스 문제 대처를 위한 Auto Scaling 기능 역시 필요
이외에 무중단 배포 전략 수행을 위한 옵션 역시 필요함
이를 해결하기 위한 방안에 대하여 고민중, 회사에 제안할 내용의 초안을 작성해본다.

현 상태

• Docker Swam을 통한 노드 컨테이너 오케스트레이션이 수행되고 있음
  • 오케스트레이션 대상이 블록체인 노드 8개 밖에 없었기에 kubernetes를 사용할 필요가 없어 보였음
• 그러나 관리 및 오케스트레이션 해야 할 대상이 많고 다양해짐
  • 노드
  • Explorer
  • 어플리케이션들
    • 거래소
    • 지갑
    • 등
  • DB
  • 게이트웨이
  • 모니터링 시스템
    • 자체 제작 Collector 및 대시보드
    • Prometheus
    • Grafana
• Auto-Scaling, 리소스 할당에 대한 필요성 대두
• 무중단 배포 전략 도입의 필요성 확인

제안

• 컨테이너 오케스트레이터(Orchestrator)를 Kubernetes로 변경
  • 더욱 안정적 시스템 운영
  • Auto Scaling

구상

• 노드 구성
  • Master
  • Worker Nodes
    • Explorer
    • Chain Nodes - 7 nodes
    • DataBase
    • Monitoring
    • Trade Application
    • Wallet Application
• Pods 단위
  • Explorer pod
  • Blockchain Nodes pod
  • Database pod
  • Services
    • Trade Application
    • Wallet Application
    • etc...
  • Monitoring pod
    • Prometheus
    • Grafana
    • 자체 제작 Collecter, Dashboard

계기

최근 새로운 솔루션 개발 및 데모를 위한 과정에서 많은 이슈들을 경험하였다.
이를 과정에서 현 개발 환경 및 서버 환경의 분리가 필요함을 느꼈다.
때문에 회사에 새로운 서버 구성을 제안하기 위한 초안을 정리해 본다.

현 상태

* 개발 서버에서 모든 서비스의 배포와 테스트가 진행되고 있음
* 로컬 환경에서도 개발 서버의 DB를 보며 개발을 진행하고 있으며, 데모 시에 사용하는 DB 역시 개발 서버에서 수행됨
    * 개발 진행 중 테이블 구조를 바꾸는 경우도 발생하여 데모에 이슈를 야기하기도 함
* 따라서 개발서버는 새로운 기능 배포 및 테스트 용도
* QA 서버를 따로 배포하여, 운영 서버와 동일한 환경에서 데모 및 QA 수행이 필요해 보임

제안

* 운영 서버
* 개발 서버
    * 개발 수행 및 기능 테스트를 위한 서버
* QA 서버 (스테이징 서버)
    * 운영서버와 동일한 환경으로 세팅하여, 운영서버 배포 전 QA 용도로 사용
    *  QA 수행 및 데모 시의 문제를 확인함
        * DB 변동에 의한 데모 및 테스트 문제가 여러번 발생함
        * 로컬 환경에서도 개발 서버를 바라보기 때문에 더 문제가 발생
            * 따라서 DB, 서버, 클라이언트, Explorer(blockscout) 등을 배포해 테스트하는 서버 필요

OpenTelemetry(OTel)

• https://opentelemetry.io/docs/what-is-opentelemetry/

OpenTelemetry란?

• Traces, Metrics, Logs 와 같은 데이터 instrumenting, generating, collecting, exporting 할 수 있는 Observability Framework.
• 데이터를 수집, 변환 및 벡엔드 전송을 위한 표준화된 SDK / API / OTel Collector 제공을 목표로 함.
• OTLP: OpenTelemetry Protocol
• Prometheus, OTLP, Jaeger, Zipkin 등 매우 다양하고 많이 있음
  • Loki: Log 데이터의 Receiver
  • Prometheus: Metrics 에 대한 Receiver
  • Grafana Tempo: Trace에 대한 Receiver

필요한 이유

• 표준화 된 데이터 수집 / 내보내기 / 관리가 가능해짐
  • 확장 및 이전이 용이해짐
• 시스템 운영에 필요한 정보들을 직접 수집 및 모니터링이 가능함
• 데이터 관리자 중앙집중화 되어 관리가 용이함
  • 특히 MSA 와 같은 분산 시스템에서 효과적임

용어 정리

• Traces
  • 어플리케이션 / 클러스터 등에서 수행된 동작들 간의 지연(Latency)와 관계에 대한 데이터
• Metrics
  • 시계열 데이터. 즉 시간의 순서에 따라 기록되는 숫자 및 통계적 데이터
  • 일정 시간마다 수집됨
  • 수치 값을 통해 이상 징후 감지 가능
• Logs
  • 요청이 수행되는 동안 시스템의 임의의 시점에서 발생한 이벤트에 대한 데이터
  • 일반적으로 timestamp와 context payload를 포함함
  • json, binary 등의 형태로 기록됨
• Observability
  • 아웃풋을 설명함으로써 시스템 내부 상태를 이해할 수 있게 하는 것을 의미
    • Traces, Metrics, Logs와 같은 telemetry data를 통해 시스템 내부 상태를 이해하게 됨을 의미
  • 즉, 코드는 반드시 traces, metrics, logs 와 같은 데이터를 산출해야 하고 observability 백엔드로 전송해야만 함

아키텍처

• 개별 언어별 SDK
• 데이터 수집
• 변환 및 데이터 내보내기
• 등

OpenTelemetry Collector

• 원격 측정 데이터(Metrics / Traces / Logs) 수신 및 처리
• 이후 OpenTelemetry 백엔드로 데이터 내보내기
• 구성
  • Receivers
    • gRPC / HTTP 통해 데이터 수신
    • 하나 이상의 Receivers 구성 가능
  • Processors
    • 수신한 데이터를 OpenTelemetry 보내기 전 데이터 처리
  • Exporters
    • 데이터를 하나 이상의 OpenTelemetry 백엔드로 내보내기
    • 하나 이상의 Exporter 사용 가능

단점

• 기능 및 옵션의 다양화로 인한 러닝 커브 존재
• 직접 데이터 수집 및 관리하기 때문에 운영 및 관리에 대한 부담이 증가

OpenTelemetry Collector 데모

• https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/examples/demo
• MSA 구조에서 Observability 구성 예시

Deployment

• 파드들을 관리함을 의미
• rolling update, rollback, scaling 과 같은 기능을 제공
• web server, APIs, microservices에 적합하게 만듬

apiVersion: apps/v1  
kind: Deployment                        // Deployment 정의 
metadata:  
    name: webapp-deployment  
spec:  
    replicas: 3                         // 3개의 레플리카(인스턴스) - 아래 파드들
    selector:  
        matchLabels:  
            app: my-webapp  
    template:  
        metadata:  
            labels:  
                app: my-webapp  
        spec:  
            containers:  
            - name: webapp  
              image: nginx:latest  
              ports:  
                - containerPort: 80  
              envFrom:  
                - configMapRef:  
                    name: webapp-config  
            - name: database  
              image: mongo:latest  
              env:  
                - name: MONGO_INITDB_ROOT_USERNAME  
                  valueFrom:   
                    secretKeyRef:  
                        name: db-credentials  
                        key: username  
                - name: MONGO_INITDB_ROOT_PASSWORD  
                  valueFrom:  
                    secretKeyRef:  
                        name: db-credentials  
                        key: password  
              volumeMounts:  
                - name: db-data  
                  mountPath: /data/db  
    volumes:  
        - name: db-data  
          persistentVolumeClaim:  
          claimName: database-pvc  

---  

apiVersion: v1  
kind: Service  
metadata:  
    name: webapp-service  
spec:  
    selector:  
        app: my-webapp  
    ports:  
        - protocol: TCP  
          port: 80  
          targetPort: 80  

---  

apiVersion: v1  
kind: ConfigMap  
metadata:  
    name: webapp-config  
data:  
    WEBAPP_ENV: "production"  
    DATABASE_URL: "mongodb://database-service:27017/mydb"  

---  

apiVersion: v1  
kind: Secret  
metadata:  
    name: db-credentials  
type: Opaque  
data:  
    username: <base64-encoded-username>  
    password: <base64-encoded-password>  

---  

apiVersion: v1  
kind: PersistentVolumeClaim  
metadata:  
    name: database-pvc  
spec:  
    accessModes:  
        - ReadWriteOnce  
    resources:  
        requests:  
            storage: 1Gi

VOLUME

• 파드 내의 모든 컨테이너가 접근 가능한 디렉토리
• 컨테이너에서 스토리지(storage)를 분리시켜 컨테이너 재시작/재스케쥴과 별개로 데이터를 영속 관리 가능하게 함

apiVersion: v1  
kind: Pod  
metadata:  
    name: webapp-with-db  
    labels:  
    app: my-webapp  
spec:  
    containers:  
    - name: webapp  
      image: nginx:latest 
      ports:  
        - containerPort: 80  
      envFrom:  
        - configMapRef:  
            name: webapp-config  
    - name: database  
      image: mongo:latest  
      env:  
        - name: MONGO_INITDB_ROOT_USERNAME  
          valueFrom:  
            secretKeyRef:  
                name: db-credentials  
                key: username  
        - name: MONGO_INITDB_ROOT_PASSWORD  
          valueFrom:  
            secretKeyRef:  
                name: db-credentials  
                key: password  
          volumeMounts:  
            - name: db-data                  
              mountPath: /data/db              // 데이터 볼륨을 /data/db 마운트한다
    volumes:  
    - name: db-data                            // db-data 볼륨에 영구히 저장된다
      persistentVolumeClaim:  
      claimName: database-pvc                 

---  

apiVersion: v1  
kind: Service  
metadata:  
    name: webapp-service  
spec:  
    selector:  
        app: my-webapp  
    ports:  
      - protocol: TCP  
        port: 80  
        targetPort: 80  

---  

apiVersion: v1  
kind: ConfigMap  
metadata:  
    name: webapp-config  
data:  
    WEBAPP_ENV: "production"  
    DATABASE_URL: "mongodb://database-service:27017/mydb"  

---  

apiVersion: v1  
kind: Secret  
metadata:  
    name: db-credentials                   
type: Opaque  
data:  
    username: <base64-encoded-username>    
    password: <base64-encoded-password>

---

apiVersion: v1  
kind: PersistentVolumeClaim                // PVC - 스토리지 요구사항 정의
metadata:  
    name: database-pvc  
spec:  
    accessModes:  
        - ReadWriteOnce  
resources:  
    requests:  
        storage: 1Gi                       // 스토리지 요구사항 상세. 1Gi 짜리 스토리지

Secrets

• 민감 정보 저장에 사용
• 기본 base64 인코딩이 default
• 파드에서 파일로 마운팅되거나 환경 변수로 사용할 수 있음

apiVersion: v1  
kind: Pod  
metadata:  
    name: webapp-with-db  
    labels:  
    app: my-webapp  
spec:  
    containers:  
    - name: webapp  
      image: nginx:latest 
      ports:  
        - containerPort: 80  
      envFrom:  
        - configMapRef:  
            name: webapp-config  
    - name: database  
      image: mongo:latest  
      env:  
        - name: MONGO_INITDB_ROOT_USERNAME  
          valueFrom:  
            secretKeyRef:  
                name: db-credentials  
                key: username  
        - name: MONGO_INITDB_ROOT_PASSWORD  
          valueFrom:  
            secretKeyRef:  
                name: db-credentials  
                key: password  

---  

apiVersion: v1  
kind: Service  
metadata:  
    name: webapp-service  
spec:  
    selector:  
        app: my-webapp  
    ports:  
      - protocol: TCP  
        port: 80  
        targetPort: 80  

---  

apiVersion: v1  
kind: ConfigMap  
metadata:  
    name: webapp-config  
data:  
    WEBAPP_ENV: "production"  
    DATABASE_URL: "mongodb://database-service:27017/mydb"  

---  

apiVersion: v1  
kind: Secret  
metadata:  
    name: db-credentials                   // Secret 명칭
type: Opaque  
data:  
    username: <base64-encoded-username>    // 실제 base64 로 인코딩 된 값
    password: <base64-encoded-password>