프록시의 힘: Dev와 Prod 간의 격차 해소

애플리케이션 개발자와 네트워크 아키텍트의 세계는 서로의 도메인을 보는 방식을 제외하고는 그 어느 때보다 다릅니다.

애플리케이션 배포의 일반적인 네트워크 관점은 다음과 같습니다.

"벽"의 반대편에서 동일한 애플리케이션 배포에 대한 개발자의 관점은 종종 다음과 같습니다.

두 방법 모두 각 분야에서는 정확하지만, 다른 방법의 실제 아키텍처에는 전혀 무관심합니다. 이는 애플리케이션이 프로덕션 단계로 넘어갈 때 많은 문제가 발생하는 이유를 잘 보여줍니다. 그리고 그들은 일어납니다. 연구에 따르면 2013년에 "개발자의 90%가 주말, 휴일, 휴가를 프로덕션 단계 앱 비상 상황을 해결하는 데 사용했다고 답했습니다. [1]”. 이러한 문제 중 다수가 소프트웨어 결함 및 오류와 관련이 있는 것은 분명하지만, 다른 문제들은 의심할 여지 없이 환경의 다양한 차이로 인해 발생합니다. 생산은 개발이 아니며 그 반대도 마찬가지입니다.

오늘날의 애플리케이션은 확장성을 위한 로드 밸런서, 성능 개선을 위한 캐시, 보안을 위한 웹 앱 방화벽 등 운영 환경에는 존재하지만 개발이나 테스트 환경에는 거의 존재하지 않는 다양한 서비스를 활용합니다. 이러한 서비스는 사용자와 앱(또는 선호하는 경우 앱과 API) 간 네트워크를 통과하는 모든 요청과 응답에 영향을 미칠 뿐만 아니라 어떤 경우에는 요청 및/또는 응답을 수정합니다. 이에 대한 좋은 예가 사용자의 IP 주소입니다. 이 값은 모든 요청의 HTTP 헤더에서 발견되지만, 부하 분산 프록시를 통과하면 클라이언트의 IP 주소가 아닌 프록시 의 IP 주소가 됩니다.

의심치 않는 개발자의 경우, 이로 인해 애플리케이션이 "중단"되고 앱을 수정하는 데 필요한 시간 외에도 수 시간 동안 문제 해결이 필요할 수 있습니다. 환경의 차이로 인해 발생하는 이러한 유형의 문제는 의심할 여지 없이 설문 조사에 응답한 개발자의 28%가 [2] 2015년 중반에 "올바른 테스트 환경이 있었다면 생산 문제의 50% 이상을 찾아서 수정할 수 있었을 것"이라고 말했습니다. 그리고 절반 이상(52%)이 "생산 문제의 25%~50%가 해결되었을 것"이라고 답했습니다.

생산 과정에서 발생하는 많은 문제는 애플리케이션의 차이에서 직접적으로 기인하며, 특히 애자일 방법론을 사용하여 개발한 애플리케이션에서 그렇습니다. Agile 방법을 사용하면 코드가 자주 변경되기 때문에 프로덕션 환경에서 이러한 종류의 충돌이 발생할 가능성이 높아집니다.

점점 더 많은 과제가 프로그래밍 가능 프록시를 사용하여 해결되고 있지만, 전부는 아닙니다. 이를 통해 이미 프로덕션에 있는 코드를 변경할 필요성이 없고 애플리케이션 출시가 더욱 지연되지 않습니다. 앞서 언급한 "IP 주소" 문제는 일반적으로 프록시에 실제 IP 주소를 포함하는 새 HTTP 헤더를 삽입하도록 지시하여 해결되므로 개발자는 여전히 해당 정보에 액세스할 수 있으며 7계층 부하 분산 프록시는 버전 관리 및 API 서명을 포함한 다양한 데이터를 기반으로 애플리케이션 및 API 요청을 라우팅하는 데 능숙합니다.

소프트웨어와 네트워크 엔지니어링 다이어그램에서 자주 언급되는 구성 요소 중 하나가 로드 밸런서라는 점이 흥미롭습니다. 이 프록시는 전통적으로 네트워크 팀에서 배포 및 관리하지만 애플리케이션 아키텍처에 매우 중요하기 때문에 거의 항상 애플리케이션의 일부로 포함됩니다. 마찬가지로, 개발자들은 오늘날 애플리케이션 확장에 있어서 부하 분산의 중요성을 인식하고 있으며 일반적으로 다이어그램에 부하 분산을 포함시킵니다.

또한 이는 개발자와 운영자가 확장성에 대한 책임을 맡고 애플리케이션의 부하 분산을 제어하는 사례가 증가하고 있음을 반영합니다.  좋은 일입니다. 이를 통해 개발자와 운영자는 CI/CD 파이프라인에 로드 밸런싱(및 모든 레이어 7 장점)을 포함할 수 있고(바라건대 그럴 것입니다), 특히 테스트 중에 잠재적인 문제를 빠르게 찾아 프로덕션으로 옮기기 전에 해결할 수 있습니다. CI/CD 파이프라인으로 로드 밸런싱을 왼쪽으로 이동하면 전체 애플리케이션 패키지(아키텍처)를 코드로 관리하고 동시에 업데이트할 수 있어 지속적인 배포에 대한 보다 전체적인 접근 방식이 가능해집니다. 이를 통해 네트워크 인프라(로드 밸런싱이 전통적으로 설명되는 위치이기 때문)는 애플리케이션(또는 해당 경로를 사용하는 경우 마이크로서비스)이 단순히 업데이트되는 것이 아니라 새로운 구성으로 완전히 재배포되는 변경 불가능한 아키텍처를 지원하여 문제와 기술적 부채를 유발할 수 있는 자연스러운 소프트웨어 엔트로피를 피할 수 있습니다.

프록시는 여러 면에서 소프트웨어 및 네트워크 엔지니어와 아키텍트를 분리하는 비유적인 격차(솔직히 말해서 벽에 가깝습니다)를 통해 "네트워크"와 "애플리케이션"을 연결하는 다리입니다. 조직이 현대적 아키텍처의 과제를 충족하기 위해 확장하려면 DevOps에 포함해야 할 차이점 중 하나가 바로 이것입니다.

[1] http://solutions-review.com/mobile-application-development/5000-developer-survey-mobile-app-development-insights-revealed/

[2] https://www.ravellosystems.com/blog/software-is-not-quite-ready-to-eat-the-world-state-of-devtest-infrastructure-survey-results/