GCP Cloud monitoring으로 편리하게 Network monitoring을 해보자

 

 

Network 인프라를 운영하는데 있어서 가장 중요한 행위 중 하나는 Monitoring, 즉 지속적으로 Network의 performance나 failing 여부를 감시하는 것입니다.

 

하지만 현재의 Network 트렌드는 MSA(Micro Service Architecture), Multi-tire architecture처럼 단일 구조보다는 여러 개의 분산된 구조의 아키텍쳐를 구성하는 것입니다.

 

때문에 Network상에서 감시해야 할 요소와 경로들이 점점 더 많아지고 복잡해지는 양상을 띄고 있습니다.

 

이러한 상황에서 더 고도화되고 발전된 성능의 Monitoring tool을 사용하는 것이 피할 수 없는 흐름이 되었습니다.

 

특히 Network 구성요소의 배치가 유연하고 더 변화무쌍한 Cloud 환경에서 고성능의 Monitoring tool을 이용한 감시는 필수적이라고 볼 수 있습니다.

 

GCP에서는 Operation 제품군의(구 Stackdriver) Cloud Monitoring을 통해서 Monitoring 서비스를 제공하고 있습니다.

 

Cloud Monitoring이 제공하는 감시 서비스의 범위와 성능은 무궁무진하지만, 본 포스팅에서는 Load balancer와 backend server를 두고 있는 단순한 구조에서 Network inspection을 하는 방법을 소개하려고 합니다.

 

 

 

1. Cloud Monitoring이란?

 

Cloud Monitoring은 GCP의 Operations suite에 속한 Logging, Trace, Error report, Debugger, Profiler와 함께 모니터링을 맡고 있는 Monitoring 서비스입니다.

 

 

 

 

Cloud Monitoring은 GCP Project 내에 Metric을 감지할 수 있는 resource가 생성되면 자동으로 Monitoring을 시작합니다.

 

Cloud Monitoring이 편리한 점은 Workspace라는 그룹을 통해 각기 다른 GCP Project나 심지어 AWS의 resource까지도 한 페이지에서 통합적으로 감시할 수 있는 환경을 제공해준다는 겁니다.

 

이를 통해 각기 다른 GCP Project나 AWS Account에서 필요한 Resource만 골라 Dashboard를 구성할 수도 있습니다.

 

이번 포스팅에서는 단일 GCP Project에 배치된 Load Balancer와 VM instance를 중심으로 Cloud Monitoring Dashboard에서 어떤 유형의 Metric을 보는 것이 유용한지 살펴보겠습니다.

 

 

2. Load balancer와 VM instance Inspection 하기

 

2-1. HTTP load balancer request counts

 

 

하나의 HTTP Load balancer와 여러개의 Backend instance로 구성되어 있는 Network 구조에서 가장 먼저 볼 metric은 Load balancer request counts입니다.

 

이는 LB로 들어오는 Request의 수를 Monitoring할 수 있는 Metric입니다.

 

이를 통해 Backend로 들어오는 통로가 되는 Load balancer가 어느정도의 request를 받고 있는지 파악할 수 있습니다.

 

이 Metric을 보면서 외부에서 들어오는 총 request 수를 가늠할 수 있기 때문에 전체적인 부하의 정도를 파악하는데 유용합니다.

 

 

 

2-2. Load balancer backend request counts

 

 

다음은 Load balancer backend request counts입니다. 

 

위에 소개한 Load balancer request counts와는 달리 LB가 부하분산하는 Backend로 들어가는 request의 수를 각각 볼 수 있습니다.

 

LB에서 받은 request가 어떤 Instance에 얼마나 분산되고 있는지 파악할 때 유용합니다.

 

특정 backend가 fail되었을때 이 수치가 급격하게 떨어지므로 Service가 정상적으로 구동되고 있는지 감시할때도 이 Metric을 활용할 수 있습니다.

 

 

 

※ Cloud Monitoring TIP

 

화면에 표시되는 Chart의 수가 너무 많아 정보를 파악하기 힘들때,

View options -> Chart mode = Outlier mode, Number of lines = n 으로 설정하면 위와 같이 n개의 Chart만 표시할 수 있어 보고 싶은 Resource의 chart만 볼 수 있습니다.

 

위와 같이 기존의 Chart가 수십개 VM Instance를 모두 표시해 Insight를 얻기 어려웠지만, Top 3개의 Chart만 표시하도록 변경함으로써 중요한 정보만 얻을 수 있게 바꿀 수 있습니다.

 

 

2-3. Load balancer reuqest counts by continents

 

 

 

 

Global service를 운영하고 있는 환경이라면 HTTP LB가 전세계에서 들어오는 request를 받게 될 것입니다.

 

이러한 경우에 대륙별로 들어오는 request 수를 파악해 어떤 대륙에서 주로 request가 들어오는지 쉽게 파악할 수 있습니다.

 

비단 Continents 뿐만 아니라 Country별로도 Metric을 설정할 수 있기 때문에 더 자세한 request 유입 지역을 파악할 수도 있습니다. 

 

이렇게 지역별로 Traffic 흐름을 파악하고 있다면 추후 서버 증설 시 어떤 region에 증설해야 할 지 쉽게 결정할 수 있기 때문에 Global service를 운영하고 있다면 큰 도움이 되는 Metric입니다.

 

 

 

3. Network Topology

 

Cloud Monitoring 서비스는 아니지만 GCP의 Network inspection을 진행할 때 개인적으로 유용하게 사용한 서비스가 있어서 소개해드립니다.

 

Network Topology는 현재 Network Intelligence -> Network topology로 진입하면 사용할 수 있습니다.

 

문자 그대로 Network의 Topology를 visualization해주어 Traffic flow를 쉽게 파악할 수 있게 해주는 서비스입니다.

 

 

 

 

위에서 Instances, Load balancer, end user로 구성된 Network topology를 통해 대륙별 End user의 Traffic이 어떤 경로로 들어오는지, 얼마나 들어오는지 알 수 있습니다.

 

Cloud Monitoring은 그래프 형태로 Metric을 표현해주기 때문에 Monitoring이 Resource간의 상관관계나 Traffic 흐름을 파악하기 어려웠던 점을 보완해줍니다.

 

단, 사용할 수 있는 Data의 period는 최대 2 days이기 때문에 2일 전의 Topology는 볼 수 없음에 유의해야 합니다.

 

위와 같이 대륙별로 LB에 들어오는 Traffic을 시간대 별로 볼 수 있기 때문에 Load balancer request counts by continents Metric에서 볼 수 있었던 것과는 또 다른 관점을 얻을 수 있습니다.

 

 

4. 마무리하며

 

이번 포스팅에서 크게 3가지의 Cloud Monitoring Metric과 Network Toplogy 서비스를 소개해드렸습니다.

 

하지만 제가 소개해드린 것들은 Cloud Monitoring에서 제공하는 수많은 Metric들 중 일부입니다.

 

게다가 같은 Metric이더라도 그래프 설정, 데이터 구성에 따라 새로운 관점에서 Network inspection을 진행할 수 있으니 Cloud Monitoring을 활용하고 싶다면 직접 Dashboard를 구성해보시는 것을 권합니다.