거기 누구 있나요? 집에 아무도 없나요? 애플리케이션 모니터링을 생각하면 핑크 플로이드의 ‘Comfortably Numb’에 나오는 이 구절이 떠오릅니다. 다소 뜬금없게 들릴 수 있지만, 잠시만 들어보세요. 비즈니스 요구 사항을 충족하는 안전한 애플리케이션을 신속하게 제공하는 과정에는 여러 미묘한 요소가 얽혀 있어 네트워크와 애플리케이션 포트폴리오 곳곳에 잠재적인 문제 지점이 생깁니다. 여기에 SaaS, 클라우드, 온프레미스, 하이브리드 등 점점 다양해지는 배포 옵션까지 더해지면, 각 문제 지점에는 장애가 발생하거나 잘못 구성되거나 공격 경로로 악용될 수 있는 고유한 영역이 존재하며, 각각의 영향 범위와 근본 원인도 다릅니다. 애플리케이션과 네트워크를 책임지는 관리자로서 우리는 네트워크 인프라 전반에서 트래픽이 어떻게 이동하는지 한눈에 파악할 수 있어야 합니다. 그렇다면 애플리케이션이 비즈니스 운영에 필수적인 상황에서 이러한 위험을 어떻게 관리할 수 있을까요? 어떻게 애플리케이션 가용성을 파악하고 사용자가 애플리케이션에 액세스할 때 어떤 경험을 하는지 알 수 있을까요? 애플리케이션이 실제로 존재하는지는 어떻게 알 수 있을까요?
애플리케이션 모니터링은 성공적인 앱 보안 및 제공 전략에 매우 중요합니다. 트래픽이 어떻게 애플리케이션에 도달할 수 있는지 파악하면 사용자에게 문제가 발생하기 전에 이를 해결하는 데 필요한 더 많은 인사이트를 얻을 수 있기 때문입니다. 지난해 애플리케이션 전략 현황 보고서를 위해 설문 조사한 기업 중 약 3분의 1은 앱 성능에 대한 기준선이 없었습니다. 최종 사용자보다 먼저 앱 문제와 중단을 감지하는 기업의 비율은 이보다도 낮습니다. 또한 40%의 모바일 사용자가 단 한 번의 좋지 않은 애플리케이션 경험만으로 경쟁사로 이탈한다는 사실을 고려하면, 기업이 애플리케이션의 상태를 모니터링하는 것이 얼마나 중요한지 알 수 있습니다. 여기서 BIG-IP Local Traffic Manager의 (LTM) 상태 모니터는 애플리케이션의 가용성을 확인하는 반면, 성능 모니터는 성능과 부하를 확인한다는 점에 유의해야 합니다. 하지만 여러 측면에서 이러한 애플리케이션 모니터링 방식은 클라이언트의 관점에서 애플리케이션이 어떻게 작동하는지를 보다 현실적으로 보여 줍니다.
그럼 이제 BIG-IP LTM을 통해 애플리케이션을 모니터링할 수 있는 세 가지 방법을 살펴보겠습니다.
단순 모니터링 – 이름에서 알 수 있듯이 단순 모니터링은 간단합니다. 이 모니터링 방식은 기본적으로 “이봐요, 거기에 뭔가 있나요?”라고 묻고, LTM 노드, BIG-IP DNS 서버, 가상 서버, 풀, 풀 멤버 또는 링크의 “가동” 또는 “중단” 상태만 확인합니다. 단순 모니터에는 Gateway ICMP, ICMP, TCP_ECHO의 세 가지 모니터 유형이 있으며, 풀 멤버나 개별 프로토콜, 서비스 또는 노드의 애플리케이션이 아닌 노드 자체만 모니터링합니다.
다시 말해: 친구들과 수영장에서 ‘마르코 폴로’ 놀이를 하는 것과 같습니다. 한 명이 “마르코”라고 외치면 나머지 풀 멤버들이 “폴로”라고 응답합니다. 이들이 풀에 있다는 것은 알 수 있지만, 그 이상의 정보는 알 수 없습니다.
수동 모니터링 – 수동 모니터링은 클라이언트 요청을 처리하는 과정에서 일정 기간 내 데이터 또는 연결 요청 시도 횟수와 같이 관리자가 정의한 매개변수를 기준으로 풀 멤버의 상태를 확인합니다. 해당 기간 내에 정해진 횟수만큼 시도한 후에도 시스템이 서버에 연결하거나 응답을 받지 못하는 경우, 또는 잘못된 응답을 받는 경우 시스템은 해당 풀 멤버를 “다운” 상태로 표시합니다.
이 방식은 클라이언트 요청 및 서버 응답 외에 추가적인 네트워크 트래픽을 발생시키지 않으며, 네트워크 트래픽이 있는 경우 풀 멤버를 신속하게 “down” 상태로 표시할 수 있습니다. 패시브 모니터는 사실상 클라이언트 요청에 편승하는 방식이므로 특정 응답을 확인할 수 없으며, 풀 멤버를 “up” 상태로 표시하는 데 시간이 걸릴 수 있습니다.
다시 말해, 초등학교 시절의 복도 지도원과 같습니다. 다른 학생들이 복도를 지나다니는 모습을 지켜보면서 그 학생들이 교실에 잘 도착하는지 보고하지만, 통행량이 있을 때만 보고합니다.
능동 모니터링 – 애플리케이션으로 들어오거나 애플리케이션에서 나가는 트래픽의 상태를 단순히 “무언가 있는가?” 이상으로 파악해야 할 때, 이 유형의 모니터는 주기적으로 상태 확인 요청을 보냅니다. 지정된 시간 내에 응답이 없거나 노드 상태에서 성능 저하가 나타나면 BIG-IP는 트래픽을 다른 풀 멤버 또는 노드로 리디렉션할 수 있습니다. 또한 앱 서버에 대한 상태 확인으로 사용자 세션을 시뮬레이션하고, HTTP 상태 확인을 통해 애플리케이션을 모니터링하면서 서버의 특정 응답을 확인할 수도 있습니다.
활성 모니터는 클라이언트 요청 및 서버 응답 외에 추가 네트워크 트래픽을 생성하므로 풀 멤버를 “다운” 상태로 표시하는 데 시간이 걸릴 수 있습니다. 트래픽이 많아질수록 지연 시간이 늘어날 가능성도 커집니다.
다시 말해: 교통 상황을 파악하기 위해 직접 차를 몰고 도로를 달리는 것과 같습니다. 교통 흐름이나 정체 구간을 자세히 살펴볼 수 있지만, 그 과정에서 모니터링 중인 교통량이 늘어나게 됩니다.
속도, 엔진 온도 또는 연료 소비량을 확인할 수 없는 상태로 자동차를 운전하고 싶지는 않을 것입니다. 그렇다면 사용자의 만족스러운 경험에 많은 것이 달려 있는데도, 사용자가 비즈니스 핵심 애플리케이션에 어떻게 액세스하는지 모니터링하지 않은 채 이를 제공하려는 이유는 무엇일까요? 애플리케이션에 “거기 누구 있나요?”라고 물어보는 것을 잊지 마세요.
BIG-IP의 모니터링 기능에 대한 자세한 내용은 아래 리소스를 확인하거나 F5 고객 담당 팀에 문의하여 BIG-IP 애플리케이션 상태 모니터를 특정 사용 사례에 어떻게 적용할 수 있는지 알아보세요.
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.