Amazon EKS Container Network Observability 출시 – 클러스터 전반의 네트워크 성능과 트래픽 모니터링

기업들은 점진적으로 혁신하고 더 빠르게 비즈니스 가치를 제공하기 위해 마이크로서비스를 배포하여 Kubernetes 활용 범위를 점점 더 확장하고 있습니다. 이러한 성장으로 인해 네트워크 의존도가 높아짐에 따라 플랫폼 팀은 EKS에서 네트워크 성능과 트래픽 패턴을 모니터링하는 데 있어 기하급수적으로 복잡한 과제에 직면하게 됩니다. 결과적으로 조직은 컨테이너 환경 규모가 조정됨에 따라 운영 효율성을 유지하는 데 어려움을 겪으며, 이로 인해 애플리케이션 제공이 지연되고 운영 비용이 증가하는 경우가 많습니다.

이러한 문제 해결을 위한 Amazon Elastic Kubernetes Service(Amazon EKS)의 Container Network Observability를 소개합니다. Amazon EKS의 포괄적인 네트워크 관찰성 특성 세트인 이 특성을 사용하면 시스템의 네트워크 성능을 더 효과적으로 측정하고 EKS에서 네트워크 트래픽의 환경과 동작을 동적으로 시각화할 수 있습니다.

Amazon EKS의 Container Network Observability를 간략하게 살펴보겠습니다.

EKS의 Container Network Observability는 워크로드 트래픽에 대한 향상된 가시성을 제공하여 관찰성 문제를 해결합니다. 클러스터 내의 네트워크 흐름과 클러스터 외부 대상이 있는 네트워크 흐름에 대한 성능 인사이트를 제공합니다. 이를 통해 EKS 클러스터 네트워크 환경을 더 잘 관찰할 수 있고 보다 정확한 문제 해결 및 조사 작업을 위한 내장 기능을 사용할 수 있습니다.

EKS의 Container Network Observability 시작하기

신규 또는 기존 EKS 클러스터에 대해 이 새로운 특성을 활성화할 수 있습니다. 새 EKS 클러스터의 경우 관찰성 구성 설정 중 네트워크 관찰성 구성 섹션으로 이동합니다. 여기서 컨테이너 네트워크 관찰성 편집을 선택합니다. Amazon CloudWatch Network Flow Monitor에서 활성화되는 서비스 맵, 흐름 테이블, 성능 지표 엔드포인트의 세 가지 특성이 포함되어 있습니다.

다음 페이지에서 AWS Network Flow Monitor 에이전트를 설치해야 합니다.

활성화된 후에는 EKS 클러스터로 이동하여 클러스터 모니터링을 선택할 수 있습니다.

클러스터 관찰성 대시보드로 이동됩니다. 네트워크 탭을 선택합니다.

포괄적인 관찰성 기능
EKS의 Container Network Observability는 AWS 서비스 보기, 클러스터 보기, 외부 보기의 세 가지 보기가 있는 흐름 테이블, 성능 지표, 서비스 맵 등의 몇 가지 주요 특성을 제공합니다.

성능 지표를 통해 이제 Network Flow Monitor 에이전트에서 직접 포드와 워커 노드에 대한 네트워크 관련 시스템 지표를 스크래핑하여 원하는 모니터링 대상으로 전송할 수 있습니다. 사용 가능한 지표로 대역폭, 초당 패킷 수, 연결 추적 제한에 대한 다양한 허용 한도 초과 카운터, 수신/송신 흐름 수, 패킷 수, 전송된 바이트 수가 있습니다. 다음 스크린샷은 Amazon Managed Grafana를 사용하여 Prometheus로 스크래핑한 성능 지표를 시각화하는 방법을 보여주는 예시입니다.

서비스 맵 특성을 사용하면 클러스터 내 워크로드 간 상호 통신을 동적으로 시각화하여 애플리케이션 토폴로지를 쉽고 간단하게 파악할 수 있습니다. 서비스 맵은 통신 중인 포드 간 네트워크 흐름에 대한 재전송, 재전송 타임아웃, 전송된 데이터와 같은 주요 지표를 강조 표시하여 성능 문제를 신속하게 식별하는 데 도움이 됩니다.

샘플 전자상거래 애플리케이션을 통해 서비스 맵이 어떻게 작동하는지 보여드리겠습니다. 서비스 맵은 마이크로서비스 아키텍처에 대한 개요 보기와 세부 보기를 모두 제공합니다. 이 전자상거래 예시에서 세 가지 핵심 마이크로서비스가 함께 작동하는 것을 확인할 수 있습니다. GraphQL 서비스는 API 게이트웨이 역할을 하며 프론트엔드 서비스와 백엔드 서비스 간의 요청을 조율합니다.

고객이 제품을 탐색하거나 주문할 때 GraphQL 서비스는 제품 서비스(카탈로그 데이터, 요금, 재고 관리)와 주문 서비스(주문 처리 및 관리) 간의 통신을 조정합니다. 이 아키텍처를 통해 각 서비스는 명확한 관심사 분리를 유지하면서 독립적으로 규모를 조정할 수 있습니다.

더 심층적인 문제 해결을 위해 보기를 확장하여 개별 포드 인스턴스와 해당 통신 패턴을 확인할 수 있습니다. 세부 정보 보기는 마이크로서비스 통신의 복잡성을 보여줍니다. 여기에서 각 서비스에 대한 여러 포드 인스턴스와 이들 간의 연결 네트워크를 확인할 수 있습니다.

이러한 세분화된 가시성은 로드 분산 불균형, 포드 간 통신 병목 현상, 특정 포드 인스턴스의 지연 시간 증가 등의 문제를 식별하는 데 매우 중요합니다. 예를 들어 하나의 GraphQL 포드가 특정 제품 포드에 대해 과도하게 많은 직접 호출을 하는 경우 이러한 패턴을 신속하게 파악하고 잠재적 원인을 조사할 수 있습니다.

흐름 테이블을 사용하여 클러스터 내 Kubernetes 워크로드 전반의 상위 토커를 세 가지 관점에서 모니터링할 수 있습니다. 각 관점은 네트워크 트래픽 패턴에 대한 고유한 인사이트를 제공합니다.

흐름 테이블 – 클러스터 내 Kubernetes 워크로드 전반의 상위 토커를 세 가지 관점에서 모니터링할 수 있습니다. 각 관점은 네트워크 트래픽 패턴에 대한 고유한 인사이트를 제공합니다.

• AWS 서비스 보기는 Amazon DynamoDB, Amazon Simple Storage Service(Amazon S3) 등의 Amazon Web Services(AWS) 서비스에 대한 가장 많은 트래픽을 생성하는 워크로드를 보여줍니다. 이를 통해 데이터 액세스 패턴을 최적화하고 잠재적인 비용 최적화 기회를 식별할 수 있습니다.
• 클러스터 보기는 클러스터 내에서 가장 많은 통신을 하는 마이크로서비스(동서 방향 트래픽)를 보여줍니다. 즉, 최적화 또는 콜로케이션 전략으로 개선이 필요한 과도한 통신을 하는 마이크로서비스를 식별할 수 있습니다.
• 외부 보기는 AWS 외부(인터넷 또는 온프레미스) 대상에 대한 트래픽이 가장 많은 워크로드를 식별하며, 이는 보안 모니터링과 대역폭 관리에 유용합니다.

흐름 테이블은 네트워크 트래픽 패턴을 분석하기 위한 세부 지표와 필터링 기능을 제공합니다. 이 예에서는 전자상거래 서비스 간 클러스터 보기 트래픽을 보여주는 흐름 테이블을 확인할 수 있습니다. 표는 주문 포드가 여러 제품 포드와 통신하며 대량의 데이터를 전송하고 있음을 보여줍니다. 이 패턴은 주문 처리 중 주문 서비스가 자주 제품을 조회하고 있음을 시사합니다.

필터링 기능은 문제 해결에 유용합니다. 예를 들어, 특정 주문 포드에서 발생하는 트래픽에 초점을 맞출 수 있습니다. 이 세분화된 필터링 기능은 성능 문제를 조사할 때 통신 패턴을 신속하게 분리하는 데 도움이 됩니다. 예를 들어, 고객이 결제 시간이 느리다고 느끼는 경우 필터링을 통해 주문 서비스가 제품 서비스에 너무 많은 직접 호출을 하고 있는지 또는 특정 포드 인스턴스 간에 네트워크 병목 현상이 있는지 확인할 수 있습니다.

추가 정보
다음은 EKS의 Container Network Observability에 대해 알아두어야 할 주요 사항입니다.

• 요금 – 네트워크 모니터링의 경우 표준 Amazon CloudWatch Network Flow Monitor 요금이 적용됩니다.
• 가용성 – EKS의 Container Network Observability는 Amazon CloudWatch Network Flow Monitor가 제공되는 모든 상용 AWS 리전에서 이용 가능합니다.
• 선호하는 모니터링 솔루션으로 지표 내보내기 – Prometheus 및 Grafana와 호환되는 OpenMetrics 형식으로 지표가 제공됩니다. 구성 세부 정보는 Network Flow Monitor 설명서를 참조하세요.

지금 Amazon EKS의 Container Network Observability를 시작하여 클러스터의 네트워크 관찰성을 개선하세요.

즐겁게 빌드해 보세요!
– Donnie