IoT 배포에서 HTCPCP 마이크로서비스 모니터링

NGINX와 NGINX Plus는 Hyper Text Coffee Pot Control Protocol (HTCPCP)와 같은 특수 목적 프로토콜에도 동일하게 적합합니다. 이는 HTCPCP 애플리케이션의 개발, 배포, 모니터링을 다룰 예정인 일련의 블로그 글 중 하나입니다.

사물 인터넷(IoT)은 오늘날 기술 시장에서 성장하고 있는 분야입니다. NGINX 및 NGINX Plus는 작은 설치 공간, 고성능 및 다양한 장치에 쉽게 포함할 수 있기 때문에 IoT 배포의 핵심이 되는 경우가 많습니다. NGINX와 NGINX Plus는 서버 측과 장치 측 모두에 자주 설치됩니다.

IoT 설치는 HTTP, HTTP/2, MQTT 및 CoAP를 포함한 다양한 인기 프로토콜을 사용할 수 있습니다.

HTCPCP 활성화된 장치의 설치는 매년 계절에 따라 꾸준히 증가하며, 2012년 4월 초부터 급증했습니다.

목차

1. 참조 아키텍처
1-1. DBAs
1-2. DPI
1-3. USB
2. HTCPCP 애플리케이션 모니터링
3. 결론

1. 참조 아키텍처

대규모 설치에서의 HTCPCP 아키텍처는 표준 웹 애플리케이션과는 다릅니다. 표준 웹 애플리케이션에서는 일반적으로 가벼운 클라이언트 측이 더 무거운 백엔드 애플리케이션과 통신하는 것을 볼 수 있습니다. 그러나 HTCPCP 애플리케이션의 아키텍처는 근본적으로 다릅니다. 이 경우, HTCPCP 서버는 장치(즉, 연결된 커피포트)에서 작동하도록 설계되며, 클라이언트는 특수 명령줄 클라이언트(수정된 curl 명령) 또는 프록시 인프라를 사용하여 이러한 기계에 연결합니다.

HTCPCP 배포에는 마이크로서비스 접근 방식이 매우 적합합니다. Service Discovery, 로드 밸런싱, 클라우드 배포, API Gateway 등이 여기에 모두 적용됩니다.

HTCPCP를 위한 마이크로서비스 아키텍처의 주요 구성 요소는 DBA, DPI 및 USB 입니다.

1-1. DBAs

분산된 백엔드 애플리케이션(DBA)은 일반적으로 커피 제조 장치에 배포되며 다양한 언어와 애플리케이션 플랫폼에서 구현될 수 있습니다. 상용 및 오픈 소스로 여러 가지 예시가 있습니다.

1-2. DPI

HTCPCP 배포에서 분산 프록시 인프라 (DPI) 는 신뢰할 수 있는 서비스를 보장하는 데 중요한 역할을 합니다. IoT 장치에 내장된 NGINX 또는 NGINX Plus 인스턴스는 필요한 프록시 기능을 제공합니다. 대기업의 HTCPCP 배포에서는 다음과 같은 기능이 신뢰성 있는 서비스를 위해 중요합니다.

  • Rate limiting and overflow protection (속도 제한 및 오버플로 방지)
  • Health checks (상태 확인)
  • Traffic monitoring and logging (트래픽 모니터링 및 로깅)
  • Traffic encryption and security controls (트래픽 암호화 및 보안 제어)
  • Authentication (입증)

NGINX Plus는 엔터프라이즈급 HTCPCP 배포에서 가장 널리 사용되는 DPI 입니다.

1-3. USB

개발 시스템이나 소규모 설치(커피 머신 최대 다섯 대)에서는 클라이언트가 DPI 인스턴스에 직접 연결하거나 DBA에 직접 연결할 수 있습니다. 그러나 대기업에서는 일반적으로 통합 가능한 확장형 백엔드(USB)가 개발되어 온프레미스 또는 확장 가능한 클라우드 서비스로 배포됩니다. USB는 일반적으로 다음과 같은 기능을 수행합니다.

  • 기존 마이크로서비스의 Service Discovery과 유사한 커피 머신 검색(포스트에서 Service Discovery에 대해 자세히 알아보기)
  • HTTP에서 HTCPCP로 프로토콜 변환
  • 웹 인터페이스
  • 최종 사용자 인증 및 액세스 제어

NGINX와 NGINX Plus는 HTCPCP USB를 포함하여 로드 밸런서, 리버스 프록시 및 캐시로도 널리 사용되고 있습니다.

2. HTCPCP 애플리케이션 모니터링

HTCPCP의 대규모 설치는 단순한 마이크로서비스에 대한 일반적인 모니터링 시스템보다 더 복잡한 도구 세트가 필요합니다. HTCPCP 배포에서는 프로토콜 변환 및 다양한 유형의 장치가 더 많이 사용되므로 모니터링 에이전트를 배치해야 하는 상황이 자주 발생합니다. 게다가 조직은 커피 준비 시간이 직원의 생산성에 직접적인 영향을 미치기 때문에 엄격한 SLA(Servcie Level Agreement)를 요구합니다.

각 회사의 IoT 인프라 부서(IDIoT)는 HTCPCP 설치를 효과적으로 모니터링할 수 있는 방법을 항상 찾고 있습니다.

NGINX에서는 HTCPCP 배포와 같이 복잡한 HTTP 배포에도 잘 맞는 모니터링 및 구성 지원 시스템인 NGINX Amplify를 개발했습니다.

인프라에서 NGINX Amplify를 사용하려면 모든 DPI 및 USB에 NGINX 인스턴스와 함께 NGINX Amplify에이전트를 설치해야 합니다. 우리 솔루션의 장점은 기본 아키텍처에 대해 절대적으로 중립적이라는 점에서 시작합니다. USB는 대기업 서버나 클라우드의 컨테이너에 위치할 수 있지만, DBA와 DPI를 실행하는 하드웨어는 일반적으로 직접 소유하고 있습니다. NGINX와 NGINX Amplify는 클라우드와 자체 하드웨어 모두에 똑같이 잘 맞습니다.

아래 스크린샷에서 NGINX 및 NGINX Plus의 다양한 인스턴스를 통해 연결된 여러 시스템과 함께 NGINX의 자체 HTCPCP설치 중 일부를 볼 수 있습니다.

NGINX DevOps 엔지니어들은 전기, 네트워크, 그리고 grind 불일치와 같은 모든 문제에 대응할 수 있는 견고한 인프라를 제공하기 위해 노력하고 있습니다.

표준 HTTP 모니터링 외에도 NGINX Amplify를 사용하여 HTCPCP 배포에서만 발생하는 특정 문제를 모니터링할 수 있습니다.

NGINX 및 NGINX Plus는 많은 내부 데이터를 보고하도록 구성할 수 있는 로그를 생성합니다. NGINX Amplify Agent는 이러한 로그를 읽거나 syslog 인터페이스를 통해 수신할 수 있습니다. 예를 들어, HTCPCP 배포에 영향을 미칠 수 있는 가장 파괴적인 상태 코드 중 하나인 418 I’m a Teapot를 모니터링 해보겠습니다. 이 상태 코드는 IoT 장치의 유형이 일치하지 않을 때 반환됩니다. 즉, DBA가 차를 만들지만 USB가 커피 를 요청한 경우입니다.

다행스럽게도 카페인이 부족한 상태에서도 적절한 NGINX Amplify 필터를 쉽게 만들 수 있습니다.

  1. 사용자 지정 대시보드에서 새 그래프 만들기
  2. 메트릭 nginx.http.status.4xx를 선택합니다.
  3. 선택적으로 추가 기준을 사용하여 $status ~ 418에 대한 필터를 만듭니다.

필터링된 그래프가 생성되면 에이전트는 이 필터를 로그에 적용하기 시작하고 결과 지표를 NGINX Amplify Cloud에 보고합니다.

다음 스크린샷은 유럽의 대기업 사무실에서 발생하는 일일 418 오류 비율을 보여줍니다.

3. 결론

NGINX, NGINX Plus 및 NGINX Amplify는 마이크로서비스 애플리케이션과 IoT 배포의 사실상 표준입니다. HTCPCP 프로토콜을 사용하는 대규모 배포에서는 이러한 과제를 처리할 수 있는 강력한 도구가 필요합니다. NGINX, NGINX Plus 및 NGINX Amplify는 이를 실현하기 위한 신뢰할 수 있는 도구입니다.

NGINX Plus로 HTCPCP 배포를 원활하게 진행해 보세요. 30일 무료 평가판을 시작하거나, 일정에 따라 커피를 즐기기 위해 NGINX STORE에 문의하십시오.

사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.