삽입 지점으로서의 앱 서버

이전 게시물에서 우리는 "삽입 지점"이라는 개념을 사용하여 변화하는 앱 아키텍처에 앱 서비스를 추가하는 개념을 살펴보았습니다. 아직 따라오지 않은 사람들을 위해 설명하자면, 삽입 지점이란 코드에서 고객 데이터 경로로 가는 경로에서 구조적으로 구별되는 위치이며, 이곳에서 개발 범위를 벗어나거나 운영상 더 효율적인 기능을 추가하는 것이 합리적입니다. 

강력한 기능 세트는 오늘날 비즈니스 활동을 나타내는 애플리케이션을 추가하거나 향상시킵니다.

삽입 지점에는 클라이언트, 인프라, 앱 자체가 포함됩니다. 운영 및 비용 효율성의 균형을 맞추는 데 있어서 각 측면에는 장단점이 있습니다. 예를 들어, 네트워크 중심 DDoS 앱 서비스를 클라이언트나 앱에 삽입하는 것은 운영상 또는 비용 효율적이지 않을 가능성이 높습니다. 이는 어느 삽입 지점도 인프라 옵션에서 사용 가능한 하드웨어 가속 기능에 액세스할 수 없고 정확한 결정을 내리는 데 필요한 가시성이 없기 때문입니다. 

따라서 우리가 찾는 것은 삽입 시점에 운영과 비용 효율성이 모두 뛰어난 앱 서비스입니다. 이 경우, 우리는 앱 서버(플랫폼) 자체에 초점을 맞춥니다.

삽입 지점으로서의 앱 플랫폼

처음에는 이 삽입 지점이 이상한 선택처럼 보일 수 있습니다. 앱 서버는 앱 서비스가 아닌 앱을 호스팅하고 제공합니다. 하지만 오늘날 NGINX 와 다른 앱 서버가 수행하는 역할을 생각해 보면, 종종 인프라와 서버 역할을 동시에 수행하는 것을 알 수 있습니다. 예를 들어, 일부 앱 서버는 SSL 종료 지점 역할을 할 수 있으며 실제로 그렇게 합니다. SSL 종료는 종종 SSL 오프로드(하드웨어 가속)와 결합되는 앱 서비스입니다. 웹 앱 방화벽 서비스도 플러그인을 통해 앱 서버에 결합되는 경우가 많습니다.

앱 서버를 삽입 지점으로 사용하는 것은 새로운 일이 아니며 낯선 일도 아닙니다. 2020년 애플리케이션 서비스 현황 조사에서 앱 서비스를 배포하는 이 옵션에 대해 질문했습니다. 우리는 이 삽입 지점에 대한 관심이 있다는 것을 발견했습니다. 응답자의 약 6%는 앱 서비스에 '플러그인'을 사용하고 싶어합니다. 나머지 9%는 "서비스로서"를 선호하는데, 이는 호출하기 위해 동반 코드(주입 또는 포함)가 필요합니다. 소수(4%)는 앱 서비스를 포함시키기 위해 라이브러리를 사용하고 싶어합니다. 마지막 옵션은 서버리스(서비스로서의 기능) 애플리케이션에 기능을 삽입하는 데 자주 사용되는 방법입니다.

많은 경우, 앱 서버에 앱 서비스를 배포하는 것이 운영상 합리적입니다. 이러한 서비스는 종종 단일 앱을 제공하도록 구성되므로 동일한 팀에서 패키징하여 배포할 수 있습니다. 앱 서버에 대한 전문 지식은 생태계와 배포 파이프라인에 대한 통합을 더욱 쉽게 만들고 신뢰성을 높여줍니다.

어떤 경우에는 단일 앱 서버의 동일한 인스턴스에 앱과 앱 서비스를 함께 배포하는 것이 합리적입니다. 예를 들어, 앱별 정책을 통한 앱 보호는 요청 및 응답 처리의 한 단계로 플러그인되어 실행될 수 있습니다. 해당 기능이 서버 내부에서 호출되는 것은 타당하며, 로컬에서 검사를 실행하면 환경 외부에서 호스팅되는 서비스에 의한 추가 홉과 처리를 제거하여 성능을 향상시킬 수 있습니다. 특히 서비스에 대해 시간당 또는 호출당 요금을 지불하는 경우 운영 및 재정적 측면에서 효율성을 높일 수 있습니다.  

앱 서버가 독립형 앱 서비스를 호스팅하는 데 사용되든 앱과 앱 서비스를 모두 호스팅하는 데 사용되든, 앱 서버는 적합한 앱 서비스를 삽입하기에 좋은 지점입니다.