관측 가능성 기반 기술

트래픽 관리

단일 장애점
- 클라우드 환경은 많은 사용자들이 공용의 리소스를 사용하는 멀티 테넌트(하나의 시스템을 여러 사용자가 독립적인 환경처럼 사용할 수 있도록 설계하는 방식 - 애플리케이션, 데이터베이스, 인프라) 환경
- 클라우드 환경에서는 많은 장애의 대부분은 사용자가 알지 못하는 사이에 발생할 가능성이 높다.
- 클라우드 환경에서는 장애 발생으로 인한 원인 분석이 미흡하고 고객에게 저오학한 사실이 전달되지 않는 경우가 많다.
- 분산 클라우드 네이티브 환경에서 대부분 치명적인 장애는 네트워크 장애이다.
- 네트워크 데이터 중에도 로드 밸런서, 웹 서버 엑세스 로그, 보안 접근 제어 데이터 등은 중요하게 관리되어야 한다.
- 쿠버네티스의 네트워크 구성은 복잡하다.
  - KubeDNS, KubeProxy, Ingress를 내부적으로 관리하는데 각 구성 요소에 문제가 발생하면 전체 클러스터의 장애로 전파가 이어진다.
- 네트워크는 SPOF(Single Point of Failure- 단일 장애점)의 특징을 갖고 있어 네트워크 장애가 발생하면 기업과 고객에게 치명적이다.
- 강력한 네트워크 관리 체계를 구축하고 장애 발생 시 정확한 원인 분석과 사전에 이상 현상을 탐지하고 예측하는 방안이 필요하다.
LoadBalancer
- 복원성이 뛰어나고 탄력적인 네트워크를 구축하기 위해서는 LoadBalancer가 필요하다.
- 클라우드와 쿠버네티스를 도입함으로써 네트워크 구조가 복잡해지면서 여러 개의 DNS 서버와 여러 유형의 로드밸런서를 구성
- AWS 기반의 네트워크 흐름
  - 외부에서 유입되는 트래픽은 AWS NAT Gateway를 통해서 VPC로 유입되고 VPC의 내부는 여러 개의 서브넷으로 구성되는데 트래픽은 서브넷에서 AWS Elastic Load Balancer를 경유하며 쿠버네티스 인그레스로 유입되며 인그레스의 경로에 맞게 특정 애플리케이션으로 라우팅되는 것이 일반적이다.
- 쿠버네티스는 자체적인 로드 밸런서(Kube Proxy)와 DNS Server를 가지고 있으며 이를 정확히 이해하지 않으면 네트워크 장애 발생 시 문제 해결이 쉽지 않다.
  - CoreDNS를 통해서 서비스를 찾아내고 Kube Proxy를 이용해서 특정 파드로 로드 밸런싱을 수행한다.
- 로드 밸런싱의 종류
  - 플랫폼 로드 밸런싱
    - AWS Elastic Load Balancer, Nginx 등이 플랫폼 로드 밸런서다.
    - 레이어 4계층은 네트워크 로드 밸런서, 레이어 7계층은 애플리케이션 로드 밸런서를 제공한다.
    - 온프레미스 환경에서는 IIS, Nginx, Apache 등을 이용한 정적인 로드밸런싱 기법이 널리 쓰이는데 이러한 트래픽 패턴은 게이트웨이, 클라이언트 로드 밸런싱과 구분할 필요가 있다.
    - 그라파나 관측 가능성은 nginx를 이용해서 플랫폼 로드 밸런서를 구현하며 public cloud 환경에서 사용하는 경우는 nginx 앞에 AWS 애플리케이션 로드 밸런서를 사용한다.
    - 그라파나 관측 가능성에서는 nginx 리버스 프록시를 사용한다.
    - ConfigMap을 사용해서 nginx 리버스 프록시 구성 파일을 생성해야 한다.
  - 게이트웨이 로드 밸런싱
    - 소프트웨어 기반의 게이트웨이는 오픈 소스로 쉽게 구현된다.
    - 스프링 클라우드 게이트웨이, 넷플릭스의 zuul이 대표적이다.
    - 일반적인 용어로는 API Gateway
    - 플랫폼 기반의 로드 밸런싱 능력은 가용성 최적화 측면에서 한계를 보인다.
    - 레이턴시(요청이 응답을 받기까지 걸리는 시간) 유형의 가용성 정보는 사용자나 클라이언트 즉, 호출하는 쪽에서 정확히 관찰이 가능하다.
    - 리소스 사용율 유형의 신호를 측정할 때는 서버가 가장 정확한 정보를 제공한다.
    - 이러한 두 가용성 신호를 조합해야 가장 효과적인 로드 밸런싱 전략을 구축할 수 있다.
    - 사이트 신뢰성 향상을 위한 로드 밸런싱의 과제는 에러 등의 문제 소지가 있을만한 서버로부터 트래픽을 분리하는 것이므로 응답 시간의 최적화 과정에서 정상 인스턴스나 그룹으로 트래픽이 몰려 과부하가 걸리므로 주의가 필요하다.
    - 게이트웨이 로드 밸런서인 API 게이트웨이는 기본적인 Routing 기능을 포함해서 비율 제한 A/B 테스트, 카나리아 배포(새 버전을 조금만 배포한 후 안정화가 되면 조금씩 늘려가는 방식의 업데이트)를 제공하며 쿠버네티스 연계를 위한 Ingress 기능도 제공한다.
    - 기본적인 쿠버네티스 인그레스에 비교해서 다양한 기능을 가지고 있으며 높은 안정성과 확장성을 제공하는 것이 일반적이다.
    - Proxy나 Sidecar 방식은 아니므로 클라이언트 측 부하 분산에 비교해서 복원성 기능은 부족하다.
    - Istio는 많은 장점을 제공하지만 사이드카로 인해서 추가적인 리소스가 필요하며 프록시가 네트워크 전방을 제어하므로 네트워크 트래픽이 발생한다.
    - Istio는 Service Mesh와 Multi Cluster 때문에 사용한다.
    - Cilium CNI를 이용해서 사이드카 없이 리눅스 커널 레벨에서 구현하는 것도 가능하다.
클라이언트 측 부하 분산
- 호출하는 주체가 로드 밸런싱 결정권을 갖는 구조
- 호출하는 서비스의 애플리케이션 코드 일부로 구현한다.
- 인스턴스 목록은 일반적으로 유레카나 콘술 등의 디스커버리 서비스에서 얻고 로드 밸런서는 호출당하는 인스턴스를 선정해서 트래픽을 전달한다.
- 원래는 유레카, 콘술 등에 구현된 서비스 디스커버리 매커니즘에서 서버 IP나 호스트명을 동적으로 가져오기 위해 사용한다.
- 넷플릭스의 유레카와 이스티오는 클라이언트 측 부하 분산을 구현한 최적의 소프트웨어로 평가된다.
복원성 패턴
- 마이크로서비스는 일반적으로 분산 시스템 복원력을 높이기 위해 여러 가용 영역에 수평 확장이 가능하도록 배포한다.
- 마이크로서비스는 정적으로 유지되는 것이 아니라 릴리스(배포 또는 카나리), 확장, 이동 등의 동적인 환경에서 각기 다른 상태를 가진다.
- 일부가 일시적으로 중단되거나 성능이 떨어지기도 하는 이런 시스템은 서비스의 최초 진입점을 파악하고 트래픽을 전달할 인스턴스를 선정하기까지의 전 과정을 모니터링하고 관리해야 한다.
- 서비스 메시를 사용하면 네트워크 구간의 모니터링이 가능하고 복원성 패턴을 구현할 수 있다.
- 관측 가능성 시스템에서는 서비스 메시를 필요로 하지는 않는다.
- 백엔드와 프론트엔드에서 구현하며 관측 가능성은 서비스 메시가 잘 동작하는지 관찰하고 잘 운영할 수 있도록 해줘야 한다.
- 신뢰성이 있고 안정적인 관측 가능성 시스템을 구현하려면 멀티 클러스터가 필요하다.
  - 장애를 극복하고 중단없이 서비스를 운영하고자 하면 고가용성의 기준을 만족하는 관측 가능성 시스템을 구축해야 한다.
- 이스티오 서비스 메시를 사용하면 관측 가능성과 연계할 수 있다.
- 이스티오에서 생성되는 로그, 메트릭, 추적은 관측 가능성과 연계 가능하다.
- 트래픽 제어는 주로 애플리케이션 코드 또는 자원 인프라(플랫폼/게이트웨이 로드 밸런서, 클라이언트 로드 밸런싱 등)를 이용해서 구현한다.
  - 애플리케이션 코드로 구현하는 쪽이 유연하게 동작하며 비즈니스 도메인 특성에 맞게 가공하기도 쉽다.
- 그라파나 관측 가능성은 마이크로 서비스로 배포되고 쿠버네티스에서 오토스케일링되며 다양한 로드 밸런서와 연계가 필요하다.
- 비즈니스 로직을 처리하는 마이크로 서비스만이 트래픽 관리의 대상은 아니며 관측 가능성과 가시성을 구현하기 위한 시스템 자체도 트래픽 관리의 대상이 된다. (그라파나 자체도 트래픽 관리의 대상이다.)
- 모든 예측은 과거 성능을 기반으로 수립한다.
  - 실패에 대비한 다른 복원 절차를 마련해야 한다.
  - 완벽한 로드 밸런서를 앞세운 클러스터도 처리량에 제한은 있다.
  - 가용 자원이 가장 많은 인스턴스를 골라 정확하게 트래픽을 할당해도 한계처리량 이상에 대응할 수는 없다.
  - 오토스케일링은 이러한 과부하에 대응하기 위한 좋은 대안이다.
  - 오토스케일링을 적용하면 파드와 노드를 자동적으로 증감할 수 있을 뿐 아니라 멀티 클러스터를 도입해서 필요 시 클러스터를 추가하는 것도 가능하다.
  - 파드와 노드의 증감은 자동화가 가능하며 멀티 클러스터 환경에서 클러스터 추가는 Ansible이나 Terraform으로 가능하다.
  - 관측 가능성 시스템은 백엔드 시스템 이상으로 많은 과부하를 받는 것이다.
- 복원성을 구현하는 방법은 다양하다.
  - 애플리케이션을 개발하는 개발자가 소스에서 구현하는 것이 가능하고 개발없이 운영자가 프록시, 사이드카와 안정적인 메시징을 이용해서 구성할 수 있다.
  - 애플리케이션에서 복원력을 높이는 방법은 소스 내 예외 처리와 재시도, 타임아웃을 정의하는 것으로 개발자는 비즈니스적인 에러와 시스템 에러를 구분하고 에러 유형에 따른 후속 처리를 수행하도록 하는데 일정한 간격으로 다수 재시도, 재처리를 진행한다.
  - 인프라 관점에서 복원력을 높이는 방법은 서비스 매시와 메시징을 이용하는 것인데 서비스 메시는 프록시를 포함하고 복원력을 향상시킬 수 있는 다양한 기능을 제공하고 메시징은 메시지 유실을 방지하고 대용량 트랜잭션을 처리할 수 있는 백본을 제공한다.
- 복원력을 높일 수 있는 패턴
  - 재시도
    - 비즈니스 에러는 재시도를 하지 않고 시스템 에러의 경우는 일정 시간이 지나면 정상적인 처리가 가능하므로 시스템 에러의 경우 재시도를 하는 경우가 많다.
  - 비율 제한
    - 비율 제한 기법을 도입하면 비정상적인 상황에도 비록 제한된 처리량이나마 요청에 대응하도록 서비스를 지속시킬 수 있다.
    - 이스티오를 사용할 수도 있지만 다양한 인그레스와 게이트웨이 로드 밸런싱으로도 구현 가능하다.
  - 벌크헤드
    - 마이크로서비스는 여러 다운스트림 서비스에 요청을 보내는데 한 서비스의 가용성만 저하되어도 여기 의존하는 다른 서비스까지 응답 불가 상태에 놓일 위험이 있다.
    - 하나의 스레드에서 여러 다운스트림 서비스에 요청을 보내는 경우 더욱 심하다. (전체가 마비될 수도 있다.)
    - 벌크헤드는 다운스트림 서비스를 서로 격리하고 각 서비스의 동시 처리 능력을 제한하다.
  - Circuit Breaker
    - 벌크 헤드를 확장한 개념
    - 넷플릭스의 추천 영화 목록은 서킷 브레이커 패턴을 적용한 대표적인 기능이다.
    - 추천 목록은 가입자의 과거 시청 기록 등을 기반으로 개개인의 독립적인 선호를 계산해 선정하는데 개인화 서비스 호출을 보호하는 서킷 브레이커가 열린 상태로 전환이 되면 추천 콘텐츠 목록 대신에 일반 콘텐츠 목록으로 응답한다.
    - 서비스1 → 서킷 브레이커 → 서비스2
    - 서비스2로의 호출은 서킷 브레이커를 통하고 서비스2가 정상적인 상황에서는 트래픽이 문제없이 통과하지만 서킷 브레이커에서 서비스2의 문제를 감지하면 서비스2로의 호출을 강제로 종료하고 서비스1의 스레드는 더 이상 요청에 대한 응답을 기다리지 않는다.
    - 서킷 브레이커는 이런 형태로 장애가 전파되는 것을 방지한다.
    - 서비스2가 정상적으로 응답할 수 없을 때 서비스2에서는 정해진 규칙에 따라 대안이 되는 로직을 반환할 수 있다. 이것을 fall back이라고 한다.
    - 서비스2가 장애 상황일 때 서킷 브레이커는 서비스2가 제공할 기본 로직을 반환해서 전체 서비스에 영향이 가지 않도록 유도한다.
    - 카프카와 같은 분산 메시지 시스템을 적용하기도 한다.
    - 관측 가능성은 비즈니스 애플리케이션에 비해 대용량의 트랜잭션을 처리하는 것이 일반적이다.
    - 관측 가능성을 운영하면 메시지 유실이 빈번히 발생하고 시스템의 증설의 필요성이 여러 차례 부각될 것이므로 확장성을 염두에 두고 구축해야 한다.
    - 오토스케일링 수평적 확장과 객체 스토리지 저장 공간은 관측 가능성에 확장성을 제공하는 기술이다.

Service Mesh

마이크로서비스 아키텍쳐에서 서비스 간 통신을 관리하고 제어하는 인프라 레이어를 의미한다.
넷플릭스 OSS나 Istio 등이 대표적인 서비스 메시 소프트웨어이다.
견고한 내부 아키텍쳐 외에 사용자 화면이 필요한 경우에는 kiali는 동적인 네트워크 모니터링을 위한 풍부한 기능을 제공하고 그라파나 관측 가능성과 쉽게 통합 가능하다.
데이터 관점에서 이스티오와 엔보이 프록시는 높은 품질의 엑세스 로그를 제공한다.
이스티오의 한계점
- 애플리케이션 코드와 별개로 운영되는 트래픽 관리 기법
- 사이드카는 비싼 리소스이며 내부 네트워크 처리 과정은 다소 비효율적이다.

쿠버네티스 오토스케일링

쿠버네티스는 CPU 사용률이나 기타 메트릭을 체크해서 파드의 개수를 스케일링하는 기능을 소유하고 있다.

HPA(Horizontal Pod AutoScaler)로 지정한 메트릭을 컨트롤러가 체크하여 부하에 따라 필요한 레플리카 수가 되도록 자동으로 파드를 늘리거나 줄이는 것이다.
HPA는 파드를 오토스케일링한다.
사용 가능 리소스
- Deployment
- ReplicaSet
- ReplicationController
- StatefulSet
관측 가능성은 대용량 트래픽을 안정적으로 처리하고 비용을 절감해야 한다.
- 관측 가능성 시스템에도 쿠버네티스 오토스케일링을 적용해야 한다.

HPA 설정

HPA는 별도의 객체로 정의된다.
HPA 버전 1: cpu 사용량이 75퍼센트가 넘으면 파드를 추가하는 HPA를 생성(파드의 최대 개수는 5)
- pi-web-lab 이라는 Deployment가 배포된 상태라고 가정

apiVersion: autoscaling/v1
kind: horizontalpodautoscaler
metadata:
  name: pi-cpu
spec:
  scaletargetref:
    apiVersion: apps/v1
    kind: deployment
    name: pi-web-lab
  minreplicas: 1
  maxreplicas: 5
  targetcpuutilizationpercentage: 75

HPA는 15초마다 하나씩 파드를 추가한다.
5분이 지날 동안 CPU 사용량이 설정값보다 작으면 파드를 감소시킨다.
HPA 버전 2 사용

metrics:
- type: Resource
  resource:
    name: cpu
    target:
      type: Utilization
      averageUtilization: 75
behavior:
  scaleDown:
    stabilizationWindowSeconds: 30 # 측정값이 기준 아래로 내려온 후 30초 대기
    policies:
    - type: Percent
      value: 50
      periodSeconds: 15

그라파나 관측 가능성 도구 내 다양한 컴포넌트에 오토스케일링 적용 가능
- Ingester, Distributer, Querrie, Query-Frontend, Gateway 에는 오토스케일링 적용
오토스케일링 방법
- AWS는 EC2 가상 머신을 기반으로 오토스케일링을 제공한다.
- 가상 머신은 OS를 중심으로 네트워크, 스토리지가 모두 결합하므로 의존성이 높고 용량이 커서 오토스케일링에 필요한 복제 과정에서 시간이 오래 걸린다.
  - 애플리케이션의 수평적인 확장 시 불필요한 부분까지 확장이 되므로 비용과 자원의 최적화 측면에서 효과적이지 못하고 수평적인 확장을 달성하는 것이 어렵다.
  - 이러한 단점을 극복하고자 등장한 것이 컨테이너이다.
측정된 메트릭을 기반으로 파드를 증가시키는 방법
- 메트릭 측정을 위한 메트릭 서버를 사용하지만 이는 CPU와 메모리 메트릭만을 지원한다는 한계가 있다.
- 일반적으로 애플리케이션 메트릭의 수집/관리를 위한 프로메테우스 어댑터, KEDA(Kubernetes Event-driven Autoscaling)등을 사용한다.
유저의 트래픽을 각 파드로 분산하는 흐름
- 사용자 트래픽은 프론트엔드를 거쳐 쿠버네티스 서비스를 통해 유입된다.
- 오토스케일링으로 증가된 파드가 쉽게 발견되어야 하고 부하가 파드로 균등하게 분산되어야 한다.
- 쿠버네티스 서비스 앞에 로드 밸런서가 구축된 운영환경을 구성해야 한다.
오톳케일링을 적용할 때 고려할 내용
- 파드 레벨의 오토스케일링과 노드 레벨의 오토스케일링을 같이 적용한다.
- 스케일 아웃(파드 또는 노드 증가)보다는 인(파드나 노드 감소) 과정에서 장애가 발생할 가능성이 높다.
  - 스케일 인을 위한 상세 매개변수를 설정하는 것이 중요하다.
  - 사이트 별로 트래픽의 유형이 다르므로 스케일 인에 적용되는 매개변수도 다른 경우가 일반적이다.
  - 다양한 테스트를 통해 트래픽과 자원 증감에 따른 오토스케일링 매개변수를 선정한다.
- 커스텀 메트릭을 개발하고 프로메테우스를 통한 고도화된 오토스케일링을 권장하지만 복잡하게 연계된 마이크로서비스 기반의 애플리케이션을 사용 중이라면 주요한 리소스에 기반한 오토스케일링부터 권장한다.
  - 마이크로서비스 간의 복잡한 상호작용과 의존성으로 인해 커스텀 메트릭을 사용해 오토스케일링을 적용하는 것은 쉽지 않은 작업이다.
- 노드 오토스케일러는 대부분 자동화 기능을 제공하므로 운영자 입장에서는 수작업이 필요 없는 경우가 대부분이다.
  - drain, cordon, taint 명령어와 PDB, affinity 등 리소스 설정은 쿠버네티스 운영에 유용하다.
  - 그라파나 관측 가능성 Helm 차트는 기본적으로 메트릭 서버를 사용해서 CPU, 메모리 기반의 오토스케일링과 PDB(Pod Distruption budget - 동시에 중단할 수 있는 파드의 개수)을 사용한다.
  - KEDA를 사용해서 요구사항에 적합하게 고도화 가능하다.
오토스케일링 오픈 소스
- 메트릭 서버
  - 오토스케일링 구성 시 가장 먼저 언급되는 것
  - 메트릭 파이프라인 아키텍쳐
    - HPA ← API Server ← (Metric API) ← Metric Server ← (Summary API) ← Kubelet ← Pod
    - Kubelet은 컨테이너 리소스 관리를 위한 노드 에이전트이다.
    - Summary API는 사용 가능한 노드 별 요약 정보를 탐색하고 수집할 수 있도록 Kubelet이 /stats 엔드포인트를 통해 제공하는 API이다.
    - Metric Server는 Kubelet으로부터 수집한 리소스 메트릭을 집계한다.
    - API Server는 HPA, VPA, kubectl top 명령어를 사용할 수 있도록 Metric API를 제공한다.
    - Metric API는 워크로드 오토스케일링에 사용되는 CPU, 메모리 정보로의 접근을 허용하는 쿠버네티스 API
    - 사용하기 위해서는 deployment에 리소스 사용량을 명시해야 한다.
```
requests:
  limits:
    cpu: 550m
  requests:
    cpu: 200m
```
    → 1CPU는 클라우드 제공자의 경우 1vCPU/Core에 해당하고 베어메탈 인텔 프로세서의 경우 1하이퍼스레드
    - Memory는 메트릭을 수집하는 순간에 바이트 단위로 측정된 워킹셋 형태로 보고 이상적인 환경에서는 워킹셋은 해제할 수 없는 사용 중인 메모리의 양이다.
- 프로메테우스 어댑터
```
apiVersion: autoscaling/v2beta1
kind: horizontalpodautoscaler
metadata:
  name: autoscaling-app-hpa
  namespace: custom-metric
spec:
  scaletargetref:
    apiVersion: apps/v1
    kind: deployment
    name: pi-web-lab
  minreplicas: 1
  maxreplicas: 5
  metric:
  - type: Object
    object:
      target:
        kind: Service
        name: autoscaling-service
      metricName: http_requests
      targetValue: 5
```
- KEDA: 이벤트 소스를 모니터링하고 해당 데이터를 HPA에 공급하여 리소스를 빠르게 확장하는 역할을 수행한다.
```
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sample-app
spec:
  scaletargetref:
    apiVersion: apps/v1
    kind: deployment
    name: pi-web-lab
  pollingInterval: 15
  cooldownPeriod: 30
  minreplicas: 1
  maxreplicas: 5
  triggers:
  - type: prometheus
  metadata:
    serverAddress: <http://prometheus-server.default.svc.cluster.local>
    metricName: nginx_Ingreress_controller_requests
    threshlod:15
    query: http_requests_total
```
- 메트릭 측정
  - 요청 수
  - 요청 기간
  - 동시 요청
메트릭 선정
- HPA를 설정할 때 고려해야 할 영역
  - 메트릭 선택
    - 선택한 메트릭이 초당 요청 타입인 경우 파드 수를 늘리면 쿼리가 더 많은 파드로 전송되므로 평균 쿼리 수는 줄어듬
    - 평균 쿼리 수가 줄어들게 되면 CPU 사용량도 줄어들게 됨
    - 메모리는 그렇지 않음
    - 서비스가 특정 양의 메모리를 소비할 때 애플리케이션이 클러스터링 되어 있지 않고 메모리를 분산시키고 해제하는 메커니즘을 가지고 있지 않으면 더 많은 파드 인스턴스를 시작한다고 해도 메모리가 줄어들지 않음
    - 메모리와 관련있는 애플리케이션은 스테이트풀 애플리케이션이나 메모리 기반의 빅데이터 처리 애플리케이션이 메모리 와 관련된 메트릭을 사용
    - 그라파나 관측 가능성의 경우에는 디스트리뷰터는 스테이트리스하며 CPU 처리가 중요하고 Ingester는 레플리케이션 팩터 와 WAL 등 스테이트풀한 상태로 관리되므로 메모리 위주의 작업을 처리
  - thrashing 방지
    - 부하가 안정적이지 않을 때 레플리카 수의 잦은 변동을 야기할 수 있는 섣부른 실행을 막기 위해 HPA는 다양한 기술을 적용
    - thrashing: 너무 많은 스레드를 한꺼번에 수행하면 스레드를 교체할 때 발생하는 문맥 교환(context switching)으로 인해 실제 작업하는 시간보다 문맥 교환에 더 많은 시간을 소비하는 현상
- Kubernetes Hook Handler
  - 갑작스런 프로모션 이벤트가 벌어져 주문이 단시간에 급증했다가 일순간 부하가 감소하면서 스케일인이 발생하고 파드가 줄어드는 경우에 문제가 발생할 수 있음
  - 그라파나 관측 가능성에서는 갑작스러운 스케일 인 과정에서 데이터가 유실될 수 있습니다.
  - 스케일 인 과정에서 파드가 삭제되기 전에 flush 하고 블록을 생성해야 합니다.
  - 모든 작업을 완료한 후 파드를 삭제해야 합니다.
  - 이런 로직을 구현하기 위해서는 커스터마이징이 필요
  - 스케일 인을 부하가 높은 시간대에 하는 것은 위험

관측 가능성 프로세스

관측 가능성 운영 프로세스
- 장애가 없는 운영 프로세스
  - 메트릭 분석 -> 추적 분석 -> 로그 분석(추적 분석으로 이동하기도 합니다.)
- 업무 절차
  - SLI(서비스 수준 지표), SLO(서비스 수준 목표) 등 사이트 신뢰성 지표를 응용해서 알람 업무 규칙을 개발
  - 로그 와 분산 추적은 비용을 제어하기 위해 샘플링됩니다.
  - 메트릭과 추적은 상호 연관성을 높일 수 있도록 최대한 태그를 중첩시켜야 합니다.
  - 분산 추적은 특정 사용자나 상호 작용을 관찰할 수 있도록 카디널리티가 높은 태그를 추가
  - 증가한 트래픽으로 인해서 지연이 발생하고 처리 시간이 증가한다면 문제가 발생한 트랜잭션을 상세히 분석
  - 추적은 로깅보다 우선되어야 합니다.
  - 정보는 같지만 콘텍스트가 더 풍부하기 때문입니다.
관측 가능성 장애 프로세스
- 장애 발생 -> 알람 전송 -> 추적 분석 -> 로그 분석

수평 샤딩

데이터베이스의 수평적 확장을 샤딩이라고 합니다.
- 시스템의 확장, 성능 향상, 높은 안정성을 갖춘 클러스터를 구성하게 됨
- 그라파나 관측 가능성 뿐 아니라 카프카, 레디스, 카산드라 등에서도 유사한 개념으로 샤딩을 구현
샤딩은 대규모 데이터베이스를 샤드라고 부르는 작은 단위로 분할하는 기술
- 모든 샤드는 동일한 스키마를 사용하고 샤드에 보관되는 데이터는 중복이 없음
- replication factor 와 duplicate를 이용하면 중복될 수 있습니다.
고려할 내용
- 데이터의 재분배
  - 데이터가 너무 많아지는 경우 하나의 샤드로는 감당이 어려워지는데 샤드간 데이터 분포가 불균등해져서 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빨리 진행될 때 샤드 소진이라는 현상이 발생
  - 이런 경우에는 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치 해야 하는데 안정 해시 기법을 이용해서 해결
- 유명 인사 문제
  - hotspot key 문제라고도 부르는데 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제
- 조인과 비정규화
  - 일단 하나의 데이터베이스를 여러 샤드 서버로 쪼개고 나면 여러 샤드에 걸친 데이터를 조인하기가 힘들어집니다.
  - 이를 해결하는 방법 중 하나가 데이터베이스를 비정규화해서 하나의 테이블에서 모든 질의가 수행될 수 있도록 하는 것 입니다.

마이크로 서비스

개발 흐름
- 바이너리 -> 도커 이미지 -> 쿠버네티스 파드
스프링부트 나 go로 개발된 소스를 Makefile로 빌드해서 바이너리를 생성(jar 생성)
Dockerfile을 이용해서 이미지를 빌드(이미지가 여러 개라면 docker-composer를 사용)
생성된 이미지를 참조해서 차트를 만들고 Helm Chart를 배포
특정 관측 가능성 플랫폼과 런타임 플랫폼에 상관없이 개발과 운영이 이루어짐

시스템을 배포하고 운영하는데 종속성이 거의 없으며 개발 시점에 언어적인 종속성만 존재

애플리케이션 과 그라파나 관측 가능성을 바이너리로 배포

동일한 소스를 쿠버네티스에도 배포

이스티오 사이드카, 텔레메트리 API 등 과 같은 소프트웨어와 통합

이 과정에서 비지니스 로직이 변경되면 안됨

읽기 와 쓰기를 분리 - CQRS

독립적인 크기 조정
최적화된 데이터 스키마
관심사의 분리
보안 강화
단순한 쿼리

일관된 해시

샤딩이나 로드 밸런싱을 할 때 해시를 이용하는 경우가 있음
일관된 해시 함수를 선택해야만 부하를 균등하게 분배할 수 있고 데이터도 균등하게 샤딩 가능

관측 가능성 시각화

히트맵이나 시계열 차트 등의 용도를 정확히 파악해서 결과를 알아보기 쉽게 시각화를 해야 함

Key Value Store

해시 함수의 결과를 주소로 이용해서 바로 접근하기 위해서 사용하는 저장소
속도가 빠름
많이 사용하는 Key Value Store는 Dynamo DB, Redis
그라파나에서는 Redis 대신 MemCached를 권장

Object Storage

많은 양의 데이터를 저장하는 목적으로 사용
적은 양의 데이터를 저장하게 되면 통신 오버헤드가 크기 때문에 권장하지 않음

안정적 데이터 관리

데이터 파티셔닝
데이터 다중화
데이터 일관성
장애 감지
일시적 장애 처리

728x90