Cloud Computing On Demand

관찰 가능성을 다루다 보면 늘 나오는 용어들.
그 중에서도 SLI, SLO, SLA는 늘, 반드시 나옵니다.

SLI - Service Level Indicator

SLI는 단일하면서도 측정 가능한 서비스의 동작을 나타내는 지표입니다.
중요한 것은 SLI의 대상은 명확하게 의미를 갖고 있는 것이어야 합니다.

• 예시
  
  • Availability (%)
  • Response time (ms)

SLA - Service Level Agreement

SLA는 여러 SLI를 조합한 형태로 보통 표현되는 지표입니다. 
특히 계약 관계가 얽혀 있을때는 패널티 Penalty 나 크레딧 Credit 을 부여하는 기준이 되기도 합니다. 
때문에 벤더 제품이나 플랫폼을 사용할 때 늘 첨예한 충돌이 일어나는 지점이기도 합니다. 
사내에 제공되는 내부 개발 플랫폼이라 하더라도 
SLA를 명확하게 정의해 두는 것이 정신건강을 위해 좋습니다.

SLA의 내용은 보통 (1) 보장하고자 하는 것과, 이를 위해 제시되는 (2) 제약 조건으로 구성됩니다.

• 예시
  • 매일 99% 이상의 요청이 200ms 이내의 응답시간으로 응답되어야 하며, 이 때 응답 Body 크기는 1MB 이하여야 합니다. 이보다 큰 Body를 응답하는 경우 응답시간을 보장할 수 없습니다

가만히 보면 SLA를 구성하는 요소들이 바로 SLI입니다. 

• 예시 SLA에 포함된 SLI들
  • Availability (% of requests)
  • Latency (ms)
  • Content Length (MB)

SLA는 서비스에 대한 SLA가 일반적으로 이야기되지만 
컴포넌트 단위의 SLA도 정의할 수 있습니다. 

SLO - Service Level Objective

SLO는 내용상으로보면 SLA와 거의 동일합니다. 
따라서 구성 요소도 SLA와 마찬가지로 여러 SLI가 됩니다. 
다만 SLA가 "꼭 지켜야만 하는 수준"을 나타낸다면 
SLO는 "우리가 달성하고자 하는 수준"을 나타냅니다.

글로벌 Edge Location을 이용한 가속 상품 Global Accelerator
속칭 GA는 모니터링 할 수 있는 메트릭을 많이 제공하지는 않습니다. 
Flowlog를 제공하긴 하지만 뭔가 서비스 레벨에서 모니터링하긴 애매하고...
가능한 지표들을 가지고 CloudWatch 대시보드로 구성해 보았습니다.

Global Accelerator 지표는 Oregon 리전에...

AWS의 제품들 중 일부는 특정 리전에서만 사용할 수 있거나 
특정 리전에서만 모니터링 할 수 있는 제품들이 있습니다. 
Global Accelerator 역시 그런 제품중 하나로 
GA의 지표들은 US West 혹은 us-west-2로 표기되는 Oregon 리전에서 제공됩니다. 

GlobalAccelerator 메트릭을 선택하면 
하위에 여러가지 메트릭이 다시 나옵니다. 

참 애매한 것이 중복되서 제공되는 메트릭들이 있어서
GlobalAccelerator, Listener, EndpointGroup 등이 
뭉쳐서 나오는 것들이 있어서... 처음 보면 당황하기 딱 좋습니다. 

Accelerator 메트릭

개인적으로 추천드리는 첫번째 지표는 Accelerator 입니다. 
실제 GA 인스턴스?가 처리하는 지표 다섯가지가 이곳에 있습니다. 

GA의 ProcessedBytesIn은 외부 혹은 업스트림으로부터 수신한 바이트
반대로 ProcessedBytesOut은 외부 혹은 업스트림으로 송신한 바이트입니다. 
보통은 GA를 업스트림 가속으로 쓰기 때문에 In을 사용자가 업로드한 바이트
Out을 업스트림으로 내보낸 바이트로 생각하면 편리합니다.

다만 상황에 따라 이 메트릭이 별로일 수도 있습니다. 
GA는 IPv4 only 일때 두개의 공인 IP, v4+v6 일때 4개의 IP를 제공하는데
이 메트릭으로는 합계 트래픽만 볼 수 있기 때문입니다. 
이때 활용하는 것이 AcceleratorIPAddress 지표입니다. 

AcceleratorIPAddress 메트릭

이 메트릭은 기본적으로 Accelerator의 메트릭중 ProcessedBytesIn/Out과 같습니다. 
다만 차이점은 GA에 할당된 IP 단위로 보여준다는 점입니다. 
즉, 특정한 IP에 문제가 생기는 경우에 대해 확인이 가능하다는 것을 의미합니다. 

네, 요렇게 지표를 추가하면 GA VIP 별로 트래픽 흐름을 볼 수 있습니다. 

다음 포스팅에서는 GA의 전송량대신 대역폭으로 보는 법을 살펴보겠습니다. 
익숙한게 대역폭인데 AWS는 DataTransfer를 Bytes로 측정하다보니 
CloudWatch 등의 메트릭도 동일한 기조로 되어 있어 다소 불편함이 있습니다 ㅎㅎ
요걸 CloudWatch Math로 풀어보겠습니다. 

#aws #globalaccelerator #awsga #accelerator #가속 #아마존 #아마존웹서비스 #글로벌엑셀러레이터 #IT #cloud #publiccloud #cloudwatch

Grafana 8.x 이상 버전에서는 웹 소켓을 이용하여 업데이트 되는 데이터를 패치해 옵니다.
이전에는 별도의 HTTP Request를 이용했지만, 이제는 웹 소켓을 이용해 
매번 연결을 보내는 오버헤드를 줄이려는 의도라고 생각합니다. 
Grafana 에서는 이 기능을 Grafana Live라 부릅니다. 

Grafana 인스턴스가 직접 엔드포인트를 제공하면 웹 소켓 이용에 특별한 문제가 없으나
여러가지 이유로 앞단에 NGINX 등을 통한 리버스 프락시를 구현해 두었다면
웹 소켓 연결이 제대로 맺어지지 않는 문제가 있습니다.

물론 Grafana 의 동작 자체는 문제가 없고 브라우저 개발자 도구/콘솔상에 
보기 싫은 빨간색 에러가 잔뜩 찍히는 불편함이 있습니다.

방법#1. Grafana Live 기능을 꺼버리자!

가장 쉬운 방법은 Grafana Live 기능을 꺼버리는 방법입니다. 
다만 이 방법은 Grafana Live 문서에서 이야기 하고 있는 기술의 장점을 버리는 선택이 됩니다. 
그렇지만 굳이 필요 없다면 기능을 꺼버리는 것이 여러모로 더 나은 선택일 수도 있습니다.

Grafana 설정 파일인 grafana.ini 혹은 custom.ini 에 
[live] 섹션을 찾아 max_connections 값을 0으로 설정하면 기능을 끌 수 있습니다. 

방법#2. 리버스 프락시에 웹 소켓 설정을 추가하자!

조금 더 적극적인 사용자이고 새로운 기술들을 활용해 보고 싶다면?
구성해 둔 리버스 프락시의 설정을 업데이트하여 웹 소켓을 잘 소화하도록 수정할 수 있습니다. 
여기에서는 가장 널리 사용되는 nginx를 리버스 프락시로 사용한 경우입니다. 

웹 소켓은 hop-by-hop, 즉 클라이언트와 nginx, 그리고 nginx와 Grafana 사이의 연결을 별도로 취급합니다. 
클라이언트가 Grafana와 웹 소켓을 통한 데이터 교환을 하기 위해서는 
nginx가 웹 소켓과 관련하여 일종의 터널링을 해주어야 합니다. 
마치 nginx가 없는 것처럼 클라이언트와 Grafana 사이를 연결해 주어야 하는 것입니다. 

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    upstream grafana {
        server 127.0.0.1:3000;
    }

    server {
        listen 8000;

        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $http_host;
            proxy_pass http://grafana;
        }
    }
}

사용자 환경에 따라 nginx 설정 파일을 쪼개서 쓸 수도 있기 때문에 
공식 문서에서 가이드 하고 있는 예제 설정을 가져왔습니다. 

웹 소켓은 Upgrade 헤더를 이용하여 웹 소켓 사용이 가능한지를 체크하고 
문제가 없는 경우에만 커넥션을 맺고 데이터를 흘리는 구조입니다.

설정의 내용은 클라이언트와 nginx 간에 Upgrade 헤더 값에 따라 
변수($connection_upgrade) 값을 지정하고 
이 값을 Grafana로 요청을 보낼때 사용하는 방식입니다. 

마지막의 location 블록을 보면 클라이언트가 보낸
Upgrade 헤더 값($http_upgrade)을 Upgrade 요청 헤더에 지정하고 
map 블록으로 지정한 $connection_upgrade 변수 값을 
Connection 헤더에 담아 Grafana로 보내는 것을 확인할 수 있습니다. 

이렇게 설정하고 nginx config을 리로드 하면 에러가 깔끔하게 사라집니다!

nginx 기준으로 위와 같은 형태로 구성하는 것은 1.13.x 이후 버전부터 가능합니다. 
혹시나 예상대로 잘 동작하지 않으면 nginx의 버전을 살펴보기 바랍니다!

꾸준히 판매되고 있는 저의 번역서 NGINX 쿡북!
아직 구매하지 않았다면 아래 링크로 고고씽~ 구매 달려주시기 바랍니다!

본 포스팅은 제휴 마케팅을 통해 
소정의 수수료를 지급 받을 수 있습니다.