Cloud Computing On Demand

브라우저 등에서 문제가 생겼을 때 tcpdump나 wireshark 등으로 
TCP 레벨 등에서의 분석을 하는 경우가 종종 있습니다. 
하지만, 이렇게까지 해야 하는가... 하는 자괴감이 들때가 많습니다. 
할 때 마다 새롭고...

그리하여 찾아보니, 
크롬 브라우저에 대한 내용만이긴 하지만 
네트워크 레벨의 동작 로그를 추출/분석하는 방법이 있어서
미래의 나는 분명 까먹을테니.. 여기에 정리해 봅니다. 

시작은 이상한 HTTP2 RST 동작을 분석하는 것이었는데
결국 늘 그렇듯... 또 이렇게 블로그에 글 하나를 적고 있습니다 ㅠㅠ

네트워크 로그를 채취하려면...

간단합니다. 
브라우저에서 chrome://net-export/ 를 입력합니다. 
노출되는 도구에서 개인정보 저장 등의 옵션을 고른다음 채취를 시작하면 됩니다. 

채취한 로그를 분석하려면...

여러가지 도구가 있는 것 같습니다만 
온라인에서 쉽게 사용할 수 있는 도구가 역시 편한 것 같습니다. 
https://netlog-viewer.appspot.com/#import

채취한 파일을 import 에 넣어주기만 하면 분석화면으로 바뀝니다. 
참 쉽죠?

그 다음 분석부터는 각자의 역량입니다!

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html

Route53 은 CloudWatch Logs 로 로그를 보내 분석하기 쉽습니다. 
다만, 이놈의 AWS 는 언제나 문서는 많지만, 원하는 문서를 찾기가 어렵긴합니다.

CWL에서 Log Insights로 Route53 로그를 쿼리할 때
도대체 어떤 컬럼명이 존재하는지 찾는 것도 마찬가지입니다.

일단은 위의 페이지에서 컬럼명을 추정할 수 있고
추정된 컬럼을 쿼리에서 사용할 수 있습니다. 
몇 가지 샘플 쿼리를 미래의 나를 위해 남겨둬 봅니다. 

filter (queryType="A" or queryType="AAAA")
| stats count(*) by queryName, queryType, responseCode, bin(1h)
| limit 50

stats count(*) as numRequests by resolverIp
| sort numRequests desc
| limit 10

filter responseCode="SERVFAIL"
| stats count(*) by queryName

그리고 CWL 쿼리 문서는 아래의 경로에 있습니다. 
정리가 잘 되어 있지 않지만... 대략...?

#cloudwatch #cloudwatchlogs #route53 #aws #awsroute53 #dns

일단 문서의 모든 내용을 이해한 것이 아니라 찾아보고 공부할 것들이 많이 있다.
실제 하드웨어의 스펙도 실무에서 쓰는 것과 다른 부분이 많기 때문에
어떤 항목들에 대한 튜닝과 개선을 통해
넷플릭스 만큼은 아니더라도 대역폭을 더 적은 자원을 소모하면서
뽑아낼 것인가에 대한 연구는 해볼만할 것 같다.

FreeBSD의 기술행사인 EuroBSDCon 2022에서 발표된
넷플릭스의 프레젠테이션 자료는 아래와 같다.

공부해보자!

글로벌 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