. 마이크로서비스 아키텍처가 제공하는 수많은 이점을 통해 IT 부문의 모든 사람들이 이 새로운 아키텍처로 전환하는 것은 당연한 일입니다! 마이크로서비스 아키텍처에는 복잡한 애플리케이션을 작은 독립형 애플리케이션으로 분할하여 각 애플리케이션을 독립적으로 확장하고 유지 관리할 수 있습니다 마이크로서비스 아키텍처의 핵심에는 역방향 프록시 개념이 있습니다. 역방향 프록시는 다양한 마이크로서비스 간에 트래픽을 전달하고 마이크로서비스의 여러 인스턴스에 워크로드를 분산시키는 데 중추적인 역할을 합니다. 역방향 프록시가 없으면 오늘날 우리가 알고 있는 마이크로서비스 아키텍처 내의 복잡한 상호 작용 웹과 부하 분산은 불가능할 것입니다! 마이크로서비스 설정에서 역방향 프록시의 역할에 대해 자세히 살펴보겠습니다! 프록시란 무엇입니까? 프록시는 클라이언트의 컴퓨터와 인터넷 사이에 위치하는 서버입니다. 클라이언트 시스템에서 나오는 모든 트래픽은 프록시 서버를 통과합니다. 나머지 인터넷에서는 프록시 서버가 요청을 시작하는 것처럼 보입니다. 프록시 서버를 사용하는 데에는 몇 가지 이유가 있습니다. 그 중 일부는 다음과 같습니다 - 프록시를 사용하면 클라이언트의 실제 신원이 인터넷에 공개되지 않습니다. 클라이언트에 대해 차단/제한된 콘텐츠에 액세스하는 데 사용할 수 있습니다. 신원 마스킹: 특정 구성을 사용하면 프록시 서버를 사용하여 클라이언트의 특정 콘텐츠에 대한 액세스를 제한할 수 있습니다. 제한 설정: 보안도 강화됩니다 역방향 프록시란 무엇입니까? 역방향 프록시는 인터넷과 백엔드 서버 사이에 위치하는 서버입니다. 서버로 향하는 모든 트래픽은 역방향 프록시를 통과해야 합니다. 나머지 인터넷에서는 역방향 프록시가 요청을 처리하는 것처럼 보입니다. 일반적으로 역방향 프록시를 사용하면 여러 가지 이점이 있습니다. 나열된 일부 항목을 찾을 수 있습니다. 여기에 역방향 프록시의 개념은 마이크로서비스 아키텍처에 생명을 불어넣어 클라이언트가 액세스할 서버를 결정하여 마이크로서비스의 동적 환경을 탐색할 수 있도록 합니다. 이 중요한 구성 요소가 없으면 클라이언트는 마이크로서비스 아키텍처의 복잡한 환경을 효과적으로 탐색할 수 있는 수단이 없게 됩니다. 서비스 발견 🌍 마이크로서비스 아키텍처의 서비스는 로드에 따라 확장 및 축소됩니다. 이는 서비스의 복제본이 애플리케이션 수명 동안 언제든지 왔다가 사라질 수 있음을 의미합니다. 역방향 프록시는 서비스 서버를 감지하고 클라이언트 트래픽을 해당 서버로 효과적으로 전달합니다. 로드 밸런싱 ⚖️ 서비스에는 여러 개의 복제본이 실행될 수 있으므로 클라이언트의 요청이 사용 가능한 서버에 적절하게 분산되는 것이 중요합니다. 로드 밸런싱은 여기에서 사용되는 Revere Proxy의 또 다른 기능입니다. 역방향 프록시는 서비스의 사용 가능한 복제본에 로드를 스마트하게 분산합니다. 모니터링 🖥️ 애플리케이션에 입력되는 모든 요청은 역방향 프록시를 통과하므로 요청을 모니터링하고 로깅을 수행하기에 좋은 장소입니다. 이는 시스템에 존재하는 서비스 수에 대한 중요한 통찰력을 얻는 데 도움이 됩니다. 내부 트래픽 🚦 마이크로서비스 설정에서는 클러스터의 내부 트래픽을 라우팅하는 데에도 역방향 프록시가 사용됩니다. 이는 서비스 간 통신의 경우 특히 유용합니다. 캐싱 💰 캐싱은 역방향 프록시를 사용할 때 얻을 수 있는 일반적인 이점입니다. 프록시 서버는 유사한 쿼리에 대해 캐시된 결과를 반환할 수 있으므로 클라이언트에 대한 응답 시간이 향상됩니다. 집계 ⛙ 단일 클라이언트의 요청에는 백엔드에 있는 둘 이상의 서비스로부터의 응답 집계가 필요할 수 있습니다. 이러한 집계는 클라이언트가 사용할 깨끗한 끝점을 남기는 역방향 프록시에 의해 수행될 수 있습니다! 레이어 간 프록싱 역방향 프록시는 다른 구성으로 사용될 수 있습니다. 이러한 구성은 일반적으로 라우팅 결정이 내려지는 OSI 계층을 나타냅니다. 널리 알려진 두 가지 프록싱이 있습니다. (1) 레이어 4의 프록싱과 (2) 레이어 7의 프록싱입니다. 레이어가 올라갈수록 라우팅 결정에 사용할 수 있는 인터넷 패킷에서 더 많은 정보를 디코딩합니다. 레이어 4 프록시 OSI 모델의 계층 4는 전송 계층입니다. 애플리케이션 개발자의 관점에서 라우팅 결정을 위해 계층 4에서 사용할 수 있는 사항은 다음과 같습니다. 요청을 보내는 클라이언트의 IP 및 포트 요청을 받는 서버의 IP와 포트 따라서 레이어 4 프록시는 서버와 클라이언트의 IP와 포트를 기반으로만 라우팅 결정을 내릴 수 있습니다. 요청 내용을 조사할 수 없으므로 제한된 라우팅 결정을 내릴 수 있습니다. 레이어 4 프록시를 사용하는 이유에는 여러 가지가 있습니다. 패킷 수준 로드 밸런싱만 필요한 경우. 안전 문제로 인해 역방향 프록시가 요청을 해독하는 것을 원하지 않습니다. 레이어 4에서의 프록싱은 빠르기 때문에 효율성이 필요합니다. 레이어 4 프록시에도 몇 가지 단점이 있습니다. 레벨 4이므로 스마트 로드 밸런싱이 불가능합니다. 진정한 마이크로서비스 로드 밸런싱을 수행할 수 없습니다. 레이어 7 프록시 OSI 모델의 계층 7은 애플리케이션 계층입니다. 애플리케이션 개발자의 관점에서 라우팅 결정을 위해 계층 7에서 사용할 수 있는 사항은 다음과 같습니다. 레이어 4에서 사용 가능한 모든 것 헤더를 포함한 요청의 전체 내용 레이어 7에서는 의사결정을 위한 훨씬 더 많은 콘텐츠를 사용할 수 있으므로 보다 스마트한 라우팅을 수행할 수 있습니다. 레이어 7 프록시를 사용하는 몇 가지 이유는 다음과 같습니다. 역방향 프록시에서 현명한 라우팅 결정을 내려야 합니다. 캐싱을 사용하고 싶습니다. 레이어 7 프록시를 사용할 때의 몇 가지 단점은 다음과 같습니다. 레이어 7 프록싱은 요청을 해독하고 라우팅 결정을 위해 해당 콘텐츠를 검사하므로 일반적으로 레이어 4보다 느립니다. 역방향 프록시는 요청 내용을 검사하므로 계층 7 프록시 사용 시 안전 문제도 있습니다. 역방향 프록시는 의심할 여지 없이 마이크로서비스 아키텍처에서 중요한 부분 중 하나입니다. 이것이 없으면 마이크로서비스 아키텍처의 진정한 이점을 완전히 실현할 수 없습니다. 이것으로 이 블로그를 마치겠습니다! 오늘 새로운 것을 배웠기를 바랍니다.
