현대 앱 프록시의 세 가지 주요 특징

뜨거운 면은 따뜻하게, 차가운 면은 차갑게 유지하세요.

기억하실지도 모르지만 (나이가 많으시다면, 걱정하지 마세요. 손을 들라고 하지는 않겠습니다) 수년 전 맥도날드가 자사 제품의 일부 포장을 "뜨거운 면은 뜨겁게, 차가운 면은 차갑게" 유지하도록 홍보하는 캠페인을 펼쳤습니다.

실제로 개념은 매우 단순했습니다. 따뜻한 물과 차가운 물을 분리하지만, 쉽게 운반할 수 있도록 하나의 용기에 담는 것입니다.

동일한 "컨테이너" 내에서 분리한다는 개념은 실제로 앱 프록시를 프록시로 만드는 기반입니다. 클라이언트 측은 클라이언트로, 앱 측은 앱으로 유지합니다.

글쎄요, 제가 원하는 만큼 깔끔하게 번역되지는 않을 수도 있겠네요.

그래도 이 개념은 타당하며 앱 프록시를 이해하는 데 중요합니다.

기본적으로 프록시는 통신 과정에서 두 참여자 사이에 논리적으로 위치하는 소프트웨어입니다. 앱 프록시는 앱과 클라이언트 사이에 위치합니다. 하지만 모든 프록시가 완전한 프록시는 아닙니다. 전체 프록시는 두 측면을 내부적으로 분리해야 합니다. 본질적으로 전체 프록시는 단일 장치 내에 포함된 두 개의 독립적인 네트워킹 스택을 갖습니다. 클라이언트 측(핫 측)과 앱 측(콜드 측). 

그렇죠. 비유가 잘 먹히지 않는 것 같아요. 나하고 함께 일해. 지금은 그게 내가 할 수 있는 전부야.

이것이 앱 프록시에 필요한 이유는(또는 그래야 하는) 프록시가 클라이언트와 서버 간의 교환에 참여할 수 있는 기능을 제공하기 때문입니다. 이는 최소화(앱 성능을 개선) 및 보안 기능(데이터 스크러빙 등), TCP 멀티플렉싱(최적화)과 같은 기능과 기타 다양한 서비스를 제공하는 데 필요합니다.

마법은 클라이언트 측과 앱 측 사이의 내부 "간격"에서 일어납니다. 여기서 기본적인 로드 밸런싱부터 고급 애플리케이션 방화벽, 애플리케이션 액세스 제어까지 다양한 서비스가 작동합니다. 요청은 앱 프록시의 클라이언트 측에서 효과적으로 종료됩니다. 그 후에는 서비스 체이닝과 매우 유사한 프로세스가 발생하지만, 이 모든 것은 내부 버스 및 프로세서 속도(거의 항상 네트워크 속도보다 빠름)에서 내부적으로 수행됩니다. 검사가 이어진다. 정책이 적용됩니다. 변형이 발생합니다. 결정이 내려집니다. 프록시와 앱 사이에 별도의 연결이 만들어지고, 요청이 해당 경로로 전송됩니다.

해당 요청이 프록시로 반환되면 그 반대의 일이 일어납니다. 검사가 이어진다. 데이터가 삭제되었습니다. 정책이 적용됩니다. 그런 다음 클라이언트 측으로 돌아가서 클라이언트로 다시 전송할 수 있습니다.

그리고 이 모든 일은 프록시 내부에서 이루어지기 때문에 1초 미만의 시간 내에 일어납니다.

앱 프록시의 목적은 가용성, 보안, 이동성, ID 및 액세스, 성능 등 광범위한 앱 서비스를 제공하는 것이므로 실제로는 전체 프록시여야 합니다. 각각의 요청과 응답에 참여하도록 설계된 것은 전체 프록시뿐입니다. 간단한 프록시(자세히 설명하면 상태 비저장 프록시)는 클라이언트와 앱 간의 연결이 생성될 때인 초기 대화에만 참여합니다. 그 목적은 앱 인스턴스를 선택한 다음 두 인스턴스 간의 연결을 "연결"하는 것입니다. 그 이후에는 대리인이 참여하지 않습니다. "흐름"(SDN을 논의하는 동안 들어봤을 수 있는 계층 4 TCP 구조, 이는 또 다른 시간에 논의할 또 다른 주제)을 보고 단순히 패킷을 앞뒤로 전달하면서 핫 패킷과 콜드 패킷을 무차별적으로 섞습니다. (보다? (저는 그 비유가 결국에는 통할 거라는 걸 알았습니다.)

지금까지 설명한 내용을 종합해 보면, 현대적이고 확장 가능한 앱 프록시는 완전한 프록시여야 하며 프로그래밍 가능성, 성능, 프로토콜이라는 세 가지 핵심 특징을 갖춰야 합니다.

프로그래밍 기능은 자동화, 오케스트레이션, 표준화를 지원하기 위해 현대 데이터 센터와 클라우드에 매우 중요합니다. 또한, 비즈니스와 운영에 고유한 가치를 제공하는 보안 및 서비스를 활성화하고, 사용자 정의 프로토콜을 지원하고 기존 프로토콜을 증강하는 데이터 경로에서도 중요합니다. 성능은 간단할 것 같지만 그렇지 않습니다. 앱 프록시는 모든 요청과 상호작용하므로 단순히 빠른 것이 아니라 엄청나게 빨라야 합니다. 거래소의 지연 시간을 없애는 앱 경험을 추가하지 않으면서도 신속하게 작업을 수행해야 합니다. 특히 배포의 기반으로 범용 컴퓨팅을 사용하려는 움직임이 있을 때, 이는 생각만큼 쉽지 않습니다.

마지막으로, 프로토콜이 중요합니다. "앱"이라는 말을 들으면 가장 먼저 떠오르는 것은 아마도 HTTP일 겁니다. 놀랄 일이 아닙니다. HTTP는 새로운 TCP이며 인터넷의 공통어입니다. 하지만 이것이 현재 사용되는 유일한 프로토콜은 아니며, 특히 인터넷이 통신의 기반이 된 시대에는 더욱 그렇습니다. SIP와 UDP도 있습니다. SMTP(여전히 이메일을 보내시나요?)와 LDAP는 말할 것도 없습니다. SSL과 TLS는 어떤가요? SSL을 모든 곳에 적용하려는 집중(과 긴급성)이 커지면서 앱 프록시가 SSL/TLS에 대해, 그것도 아주 유창하게 말하는 것이 더욱 중요해졌습니다. 그렇지 않으면 해당 성능 요구 사항을 충족하지 못할 수 있습니다.

앱 프록시는 최신 데이터 센터가 보안 및 성능 과제를 해결하고, 자동화 및 조율하여 운영 비용을 낮추고, 소비자 및 기업 고객 모두에게 최적의 앱 경험을 보장하는 데 필요한 플랫폼을 제공할 수 있습니다. 하지만 어떤 앱도 소외되지 않도록 하려면 프로그래밍 기능, 성능 및 프로토콜 지원이 포함된 전체 앱 프록시여야 합니다.