컨테이너 확장의 예술: 모니터링

컨테이너를 확장한다는 것은 단순히 서비스 앞에 프록시를 두고 그냥 방치하는 것보다 더 많은 것입니다. 확장에는 배포 외에도 더 많은 요소가 필요하며, 빠르게 변화하는 컨테이너 세계에서는 확장을 보장하는 데 필요한 다섯 가지 기능, 즉 재시도 , 회로 차단기 , 검색 , 배포 , 모니터링이 있습니다.

컨테이너 확장 기술에 대한 이 게시물에서는 모니터링에 대해 자세히 알아보겠습니다.

모니터링

모니터링. 운전 속도부터 냉장고에 무엇이 들어 있는지까지 모든 것이 듣고 있거나 지켜보는 듯한 시대에, 이 단어는 많은 사람에게 나쁜 맛을 남깁니다. 우리는 대신 '가시성'이라는 단어를 사용할 수 있고 종종 그렇게 하지만, 그 의미론적 변증법은 우리가 하는 일을 바꾸지 않습니다. 우리는 면밀히 지켜보고 있습니다.

규모에 대한 모든 것은 모니터링에 달려 있습니다. 즉, 요청을 분산시키는 리소스의 상태를 아는 것입니다. 리소스가 충돌하거나 최근에 종료되었기 때문에 '데드 존'에 요청을 보내는 것은 콘센트가 없는 막다른 길로 들어가는 것과 같습니다. 시간 낭비예요.

모니터링에는 여러 가지 형태가 있습니다. 네트워크 계층에서 ping을 모니터링하여 "연락 가능 여부"를 묻습니다. TCP 연결에 대한 "집에 계십니까?" 모니터링이 있습니다. 그리고 HTTP 요청의 "문에 대답하시겠습니까?"라는 질문이 있습니다. 그리고 서비스가 올바르게 답변하는지 여부를 판별하는 "커피를 드셨나요?" 모니터링도 있습니다.

서비스의 상태와 실행을 확인하는 것에 더해 성능 모니터링도 제공됩니다. 응답 시간에 따라 요청을 분배하는 경우 서비스가 얼마나 빨리 응답했는지가 중요합니다. 성과의 갑작스러운 변화는 문제를 나타낼 수 있으므로 역사적으로 중요한 데이터도 모니터링해야 합니다.

능동적 모니터링(실제 요청을 보내볼게요!), 합성적 모니터링(가짜 요청을 보내볼게요), 수동적 모니터링(실제 요청에 무슨 일이 일어나는지 여기 앉아서 지켜보겠어요)이 있습니다. 각 방법에는 장단점이 있으며 모두 유효한 모니터링 방법입니다. 핵심은 프록시가 상태를 판단할 수 있다는 것입니다. 작동 중인지, 작동하지 않는지, 엘비스와 함께 건물을 떠났는지?

도달 가능성, 가용성, 성능은 모두 모니터링의 측면이며 확장성을 보장하는 데 필요합니다. 즉, 모니터링에 관한 것이 아니라 로드 밸런싱 프록시가 요청을 보낼 수 있는 각 리소스의 상태에 대한 최신 정보를 가지고 있는지 확인하는 것입니다.

컨테이너의 특성과 이를 마이크로서비스 기반 아키텍처와 결합하는 경향을 생각해 보면 모니터링이 금세 악몽 같은 일이 되어버린다는 것을 알 수 있습니다. 컨테이너 환경 내에서 가장 널리 사용되는 로드 밸런싱 모델은 포워드(및 사이드카) 프록시이기 때문입니다. 두 방법 모두 각 노드가 요청을 보내야 할 모든 리소스의 상태와 안녕 상태를 알고 있어야 합니다. 즉, 거의 모든 리소스를 모니터링한다는 의미입니다.

주어진 리소스가 자신의 상태에 관해 15개 또는 20개의 전방 프록시에 응답하는 데 제한된 리소스를 사용하는 것은 실제로 효율적이지 않다고 상상할 수 있습니다. 이러한 모델을 모니터링하면 성능과 용량에 상당히 부정적인 영향을 미쳐 확장을 더욱 어렵게 만듭니다.

모니터링이 컨테이너에서 보는 것만큼 규모에 큰 영향을 미친 적은 없었습니다.

하지만 위에서 언급했듯이 그것은 중요합니다. 가능하다면 '막다른 길' 리소스에 시간을 낭비하고 싶지 않기 때문입니다.

필요한 모니터링의 과제는 서비스 메시가 컨테이너 환경 내에서 확장의 미래 모델로서 계속해서 선호(및 주목)를 받는 이유 중 하나입니다.

모니터링은 선택 사항은 아니지만 부담이 되어서는 안 됩니다.