계기

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

현 상태

* 개발 서버에서 모든 서비스의 배포와 테스트가 진행되고 있음
* 로컬 환경에서도 개발 서버의 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