애플리케이션의 아키텍처 구성요소는 프런트엔드 또는 백엔드로 분류할 수 있습니다. 일부 시나리오에서는 여러 컴퓨팅 환경에서 작동하도록 이러한 구성요소를 호스팅할 수 있습니다. 컴퓨팅 환경은 계층형 하이브리드 아키텍처 패턴의 일부로서 온프레미스 비공개 컴퓨팅 환경과 Google Cloud에 배치됩니다.
프런트엔드 애플리케이션 구성요소는 최종 사용자 또는 기기에 직접 노출됩니다. 따라서 이러한 애플리케이션은 성능에 민감한 경우가 많습니다. 새로운 기능과 개선사항을 개발하기 위해 소프트웨어 업데이트를 자주 수행할 수 있습니다. 프런트엔드 애플리케이션은 일반적으로 백엔드 애플리케이션에 의존해서 데이터(및 비즈니스 로직과 사용자 입력 처리)를 저장하고 관리하기 때문에 종종 스테이트리스(Stateless) 상태이거나 데이터 볼륨을 제한적으로만 관리합니다.
접근성과 사용성을 높이기 위해서는 다양한 프레임워크 및 기술을 사용해서 프런트엔드 애플리케이션을 빌드할 수 있습니다. 성공적인 프런트엔드 애플리케이션에 대한 몇 가지 핵심 요소에는 애플리케이션 성능, 응답 속도, 브라우저 호환성이 있습니다.
백엔드 애플리케이션 구성요소는 일반적으로 데이터 저장 및 관리에 중점을 둡니다. 일부 아키텍처에서는 비즈니스 로직이 백엔드 구성요소 내에 포함될 수 있습니다. 새로운 백엔드 애플리케이션 출시는 프런트엔드 애플리케이션 출시보다 빈도가 낮은 경향이 있습니다. 백엔드 애플리케이션의 관리 과제는 다음과 같습니다.
- 대량의 요청 처리
- 대량의 데이터 처리
- 데이터 보안
- 모든 시스템 복제본 간의 현재 및 업데이트된 데이터 유지보수
3계층 애플리케이션 아키텍처는 여러 다른 애플리케이션 구성요소를 포함하는 전자상거래 웹사이트와 같이 비즈니스 웹 애플리케이션을 빌드하기 위한 가장 인기 있는 구현 중 하나입니다. 이 아키텍처에는 다음과 같은 계층이 포함됩니다. 각 계층은 독립적으로 작동하지만 밀접하게 연결되어 있으며 모두 하나로 기능합니다.
- 웹 프런트엔드 및 프레젠테이션 계층
- 애플리케이션 계층
- 데이터 액세스 또는 백엔드 계층
이러한 레이어를 컨테이너에 배치하면 확장 요구사항과 같은 기술적 요구가 분리되고 단계적인 접근 방법으로 마이그레이션하는 데 도움이 됩니다. 또한 이를 사용해서 여러 환경 간에 이동이 가능한 플랫폼에 무관한 클라우드 서비스에 배포하고, 자동화된 관리를 사용하고, Cloud Run 또는 Google Kubernetes Engine(GKE) 엔터프라이즈 에디션과 같은 클라우드 관리 플랫폼으로 확장할 수 있습니다. 또한 Cloud SQL과 같은 Google Cloud 관리 데이터베이스는 데이터베이스 레이어로 백엔드를 제공할 수 있게 도와줍니다.
계층형 하이브리드 아키텍처 패턴은 기존 프런트엔드 애플리케이션 구성요소를 퍼블릭 클라우드에 배포하는 데 중점을 둡니다. 이 패턴에서는 기존 백엔드 애플리케이션 구성요소를 비공개 컴퓨팅 환경에 배치합니다. 애플리케이션의 규모 및 특정 설계에 따라 사례별 기준으로 프런트엔드 애플리케이션 구성요소를 마이그레이션할 수 있습니다. 자세한 내용은 Google Cloud로 마이그레이션을 참조하세요.
백엔드 및 프런트엔드 구성요소가 온프레미스 환경에 호스팅된 기존 애플리케이션이 있으면 현재 아키텍처의 제한사항을 고려하세요. 예를 들어 애플리케이션이 확장되고 성능 및 신뢰성에 대한 수요가 증가함에 따라 애플리케이션 일부를 리팩터링하거나 다른 더 최적화된 아키텍처로 이동할지 여부에 대한 평가를 시작해야 합니다. 계층형 하이브리드 아키텍처 패턴을 사용하면 전체 전환을 수행하기 전에 일부 애플리케이션 워크로드와 구성요소를 클라우드로 이동할 수 있습니다. 또한 이러한 마이그레이션에서 발생하는 비용, 시간, 위험을 고려해야 합니다.
다음 다이어그램은 일반적인 계층형 하이브리드 아키텍처 패턴을 보여줍니다.
이전 다이어그램에서 클라이언트 요청은 Google Cloud에서 호스팅되는 애플리케이션 프런트엔드로 전송됩니다. 그런 다음 애플리케이션 프런트엔드는 애플리케이션 백엔드가 호스팅되는(이상적으로 API 게이트웨이 사용) 온프레미스 환경으로 다시 데이터를 전송합니다.
계층형 하이브리드 아키텍처 패턴에서는 다음 다이어그램의 아키텍처 예시에 표시된 것처럼 Google Cloud 인프라 및 전역 서비스의 이점을 활용할 수 있습니다. 애플리케이션 프런트엔드는 Google Cloud를 통해 도달할 수 있습니다. 또한 인프라에 대한 초과 프로비저닝 없이도 자동 확장을 통해 확장 요구에 동적으로 효율적으로 대응함으로써 프런트엔드에 탄력성을 더할 수 있습니다. Google Cloud에서 확장 가능한 웹앱을 빌드하고 실행하는 데에는 여러 가지 아키텍처를 사용할 수 있습니다. 각 아키텍처에는 여러 다른 요구사항에 따라 장점과 단점이 있습니다.
자세한 내용은 YouTube 동영상 Google Cloud에서 확장 가능한 웹앱을 실행하는 3가지 방법을 참조하세요. Google Cloud에서 전자상거래 플랫폼을 현대화하는 여러 방법들을 자세히 알아보려면 Google Cloud에서 디지털 상거래 플랫폼을 빌드하는 방법을 참조하세요.
이전 다이어그램에서 애플리케이션 프런트엔드는 Google Cloud에 호스팅되어 전역 부하 분산, 자동 확장, Google Cloud Armor를 통한 DDoS 보호를 사용하는 멀티 리전을 지원하고 전역적으로 최적화된 사용자 경험을 제공합니다
시간이 지남에 따라 퍼블릭 클라우드에 배포하는 애플리케이션 수가 증가하여 백엔드 애플리케이션 구성요소를 퍼블릭 클라우드로 이동을 고려해야 하는 지점에 도달할 수 있습니다. 높은 트래픽 요구가 예상될 경우 자체 인프라를 관리할 때 클라우드 기반 서비스를 선택하면 엔지니어링 노력을 줄이는 데 도움이 될 수 있습니다. 제약조건 또는 요구사항에 따라 온프레미스에서 백엔드 애플리케이션 구성요소 호스팅이 강제되지 않는 한 이 옵션을 고려하세요. 예를 들어 백엔드 데이터에 규제 제한사항이 적용될 경우 해당 데이터를 온프레미스에 보관해야 할 수 있습니다. 하지만 적용 가능하고 규정에도 맞으면 익명화 기법과 같은 Sensitive Data Protection 기능을 사용해서 필요에 따라 데이터 이동을 도울 수 있습니다.
계층형 하이브리드 아키텍처 패턴에서는 또한 일부 시나리오에서 Google Distributed Cloud를 사용할 수 있습니다. Distributed Cloud를 사용하면 Google에서 제공 및 유지보수되고 Google Cloud 데이터 센터와 별개인 전용 하드웨어에서 Google Kubernetes Engine 클러스터를 실행할 수 있습니다. Distributed Cloud가 현재 및 미래의 요구사항을 충족하도록 보장하기 위해서는 기존의 클라우드 기반 GKE 영역과 비교되는 Distributed Cloud의 제한사항을 파악해야 합니다.
장점
프런트엔드 애플리케이션에 먼저 중점을 두면 다음과 같은 여러 이점이 있습니다.
- 프런트엔드 구성요소는 백엔드 리소스에 의존하며 일부 경우에는 다른 프런트엔드 구성요소에 의존합니다.
- 백엔드 구성요소는 프런트엔드 구성요소에 의존하지 않습니다. 따라서 프런트엔드 애플리케이션을 격리하고 마이그레이션하는 것이 백엔드 애플리케이션을 마이그레이션하는 것보다 덜 복잡할 수 있습니다.
- 프런트엔드 애플리케이션은 종종 스테이트리스(Stateless) 방식이거나 그 자체로 데이터를 관리하지 않기 때문에 백엔드보다 마이그레이션하기에 덜 까다로울 수 있습니다.
- 프런트엔드 구성요소는 마이그레이션 중에 스테이트리스(Stateless) 아키텍처를 사용하도록 최적화할 수 있습니다. 자세한 내용은 YouTube 동영상 Cloud Run에 스테이트풀(Stateful) 웹앱을 이식하는 방법을 참조하세요.
기존 또는 새롭게 개발된 프런트엔드 애플리케이션을 퍼블릭 클라우드에 배포하면 다음과 같은 몇 가지 이점이 있습니다.
- 많은 프런트엔드 애플리케이션은 자주 변경될 수 있습니다. 퍼블릭 클라우드에서 이러한 애플리케이션을 실행하면 지속적 통합/지속적 배포(CI/CD) 프로세스 설정이 간소화됩니다. CI/CD를 사용해서 효율적이고 자동화된 방법으로 업데이트를 전송할 수 있습니다. 자세한 내용은 Google Cloud의 CI/CD를 참조하세요.
- 트래픽 부하가 다양하고 성능에 민감한 프런트엔드는 클라우드 기반 배포로 지원되는(이상적으로 스테이트리스(Stateless) 아키텍처 사용) 부하 분산, 멀티 리전 배포, Cloud CDN 캐싱, 서버리스 및 자동 확장 기능에서 상당한 이점을 얻을 수 있습니다.
GKE와 같은 클라우드 관리 플랫폼을 사용하여 컨테이너가 있는 마이크로서비스를 채택하면 마이크로서비스를 프런트엔드 구성요소로 확장하는 마이크로프런트엔드와 같은 현대적인 아키텍처를 사용할 수 있습니다.
마이크로서비스 확장은 일반적으로 동일 애플리케이션에서 여러 팀이 협업하는 프런트엔드에 사용됩니다. 이러한 종류의 팀 구조에는 반복적인 접근 방법과 지속적인 유지보수가 필요합니다. 마이크로프런트엔드를 사용할 때의 장점은 다음과 같습니다.
- 개발, 테스트, 배포를 위한 독립적인 마이크로서비스 모듈로 만들 수 있습니다.
- 각 개발팀에 따라 선호하는 기술과 코드를 선���할 수 있는 분리 기능을 제공합니다.
- 다른 팀에서 관리할 수 있는 나머지 프런트엔드 구성요소에 영향을 주지 않고 개발 및 배포 주기를 빠르게 지원할 수 있습니다.
사용자 인터페이스 또는 API를 구현하거나 사물 인터넷(IoT) 데이터 수집을 처리하든지 간에 프런트엔드 애플리케이션이 Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine, Cloud Run과 같은 클라우드 서비스의 기능을 활용할 수 있습니다.
클라우드 관리 API 프록시는 다음을 도와줍니다.
- 마이크로서비스와 같은 백엔드 서비스에서 앱용 API를 분리합니다.
- 백엔드 코드 변경사항으로부터 앱을 보호합니다.
- 프런트엔드용 백엔드(BFF), 마이크로프런트엔드 등과 같은 기존 API 기반의 프런트엔드 아키텍처를 지원합니다.
- Apigee에서 API 프록시를 구현하여 Google Cloud 또는 기타 환경에서 API를 노출합니다.
또한 프런트엔드를 비공개 컴퓨팅 환경에 유지하면서 클라우드에 백엔드를 배포함으로써 계층형 하이브리드 패턴을 역방향으로 적용할 수 있습니다. 덜 일반적이지만 이 접근 방법은 규모가 크고 복잡한 모놀리식 프런트엔드를 다루는 데 가장 적합합니다. 이러한 경우 백엔드 기능을 반복적으로 추출하고 클라우드에 이러한 새로운 백엔드를 배포하는 것이 더 쉬울 수 있습니다.
이 시리즈의 3번째 부분에서는 이러한 아키텍처를 사용 설정하기 위해 가능한 네트워킹 패턴에 대해 논의합니다. Apigee Hybrid는 하이브리드 배포 모델에서 API 프록시를 빌드 및 관리하는 플랫폼으로서 도움이 됩니다. 자세한 내용은 계층형 모놀리식 및 마이크로서비스 아키텍처를 포함하여 느슨하게 결합된 아키텍처를 참조하세요.
권장사항
계층형 하이브리드 아키텍처를 계획할 때는 이 섹션의 정보를 참조하세요.
복잡성을 줄이기 위한 권장사항
계층형 하이브리드 아키텍처 패턴을 적용할 때는 전반적인 배포 및 운영 복잡성을 줄이는 데 도움이 될 수 있는 다음과 같은 권장사항을 고려하세요.
- 식별된 애플리케이션의 통신 모델에 대한 평가를 기준으로 이러한 애플리케이션에 대해 가장 효율적이고 효과적인 통신 솔루션을 선택합니다.
대부분의 사용자 상호작용은 여러 컴퓨팅 환경에 연결된 시스템에서 이루어���기 때문에 이러한 시스템 간에 지연 시간이 짧고 빠른 연결성이 중요합니다. 가용성 및 성능 기대치를 충족시키기 위해서는 고가용성, 낮은 지연 시간, 적합한 처리량 수준을 지원하도록 설계해야 합니다. 보안 관점에서는 통신을 미세 조정 및 제어해야 합니다. 이상적으로는 보안 API를 사용하여 애플리케이션 구성요소를 노출해야 합니다. 자세한 내용은 게이트 이그레스를 참조하세요.
- 여러 환경 간에 통신 지연 시간을 최소화하려면 애플리케이션 백엔드 구성요소가 호스팅된 비공개 컴퓨팅 환경에 지리적으로 가까운 Google Cloud 리전을 선택합니다. 자세한 내용은 Compute Engine 리전 선택 권장사항을 참조하세요.
- 특히 통신이 동시에 처리되는 경우, 서로 다른 환경에서 실행되는 시스템 간의 높은 종속 항목을 최소화합니다. 이러한 종속 항목은 성능을 느리게 하고, 전반적인 가용성을 줄이고, 잠재적으로 추가적인 아웃바운드 데이터 전송 요금을 발생시킬 수 있습니다.
- 계층형 하이브리드 아키텍처 패턴에서는 Google Cloud를 나가는 아웃바운드 트래픽에 비해 Google Cloud로 들어오는 온프레미스 환경의 인바운드 트래픽 볼륨이 더 클 수 있습니다. 그렇더라도 Google Cloud를 나가는 예상 아웃바운드 데이터 전송 볼륨을 알아야 합니다. 높은 아웃바운드 데이터 전송 볼륨이 이 아키텍처를 장기간 사용하려면 Cloud Interconnect 사용을 고려하세요. Cloud Interconnect는 연결 성능을 최적화하는 데 도움이 되며 특정 조건을 충족하는 트래픽에 대한 아웃바운드 데이터 전송 요금을 줄일 수 있습니다. 자세한 내용은 Cloud Interconnect 가격 책정을 참조하세요.
- 민감한 정보를 보호하기 위해서는 전송 중 상태의 모든 통신을 암호화하는 것이 좋습니다. 연결 레이어에 암호화가 필요하면 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cloud Interconnect용 MACsec를 사용할 수 있습니다.
여러 백엔드 간에 프로토콜, API, 인증 메커니즘의 불일치 문제를 해결하기 위해서는 가능한 경우 API 게이트웨이 또는 프록시를 통합 퍼사드로 배포하는 것이 좋습니다. 이러한 게이트웨이 또는 프록시는 중앙화된 제어 지점으로 작동하며 다음과 같은 측정을 수행합니다.
- 추가 보안 측정을 구현합니다.
- 백엔드 코드 변경사항으로부터 클라이언트 앱과 기타 서비스를 보호합니다.
- 모든 교차 환경 애플리케이션과 분리된 구성요소 사이의 통신을 위한 감사 추적을 지원합니다.
- 기존 서비스와 및 현대화된 서비스 사이에 중간 통신 레이어 역할을 수행합니다.
- Apigee 및 Apigee Hybrid를 사용하면 온프레미스 환경, 에지, 기타 클라우드, Google Cloud 환경 간에 엔터프라이즈급 및 하이브리드 게이트웨이를 호스팅하고 관리할 수 있습니다.
하이브리드 설정을 지원하기 위해서는 하이브리드 연결이 지원되는 Cloud Load Balancing을 사용합니다. 즉, 클라우드 부하 분산의 이점을 온프레미스 컴퓨팅 환경에 호스팅되는 서비스로 확장할 수 있습니다. 이 접근 방법을 사용하면 서비스 중단을 없애거나 최소화하는 방식으로 Google Cloud로 단계별 워크로드 마이그레이션을 수행하고 분산 서비스로의 원활한 전환을 보장할 수 있습니다. 자세한 내용은 하이브리드 연결 네트워크 엔드포인트 그룹 개요를 참조하세요.
일부 경우에는 API 게이트웨이 또는 프록시와 애플리케이션 부하 분산기를 함께 사용해서 대규모 API 트래픽 관리, 보안, 분산을 위한 보다 강력한 솔루션을 제공할 수 있습니다. API 게이트웨이와 함께 Cloud Load Balancing을 사용하면 다음을 달성할 수 있습니다.
- Apigee 및 Cloud CDN과 함께 고성능 API를 제공하여 지연 시간을 줄이고, API를 전역적으로 호스팅하고, 피크 트래픽 기간에 가용성을 늘릴 수 있습니다. 자세한 내용은 YouTube 동영상 Apigee 및 Cloud CDN과 함께 고성능 API 제공을 참조하세요.
- 고급 트래픽 관리를 구현합니다.
- Google Cloud Armor를 DDoS 보호 및 네트워크 보안 서비스로 사용해서 API를 보호합니다.
- 여러 리전의 게이트웨이에서 효율적인 부하 분산을 관리합니다. 자세한 내용은 YouTube 동영상 Private Service Connect와 Apigee로 API 보호 및 멀티 리전 장애 조치 구현을 참조하세요.
API 관리 및 서비스 메시를 사용하여 마이크로서비스 아키텍처에서 서비스가 통신을 수행하고 노출되는 방식을 보호하고 제어할 수 있습니다.
- Cloud Service Mesh를 사용하여 서비스 간 인증, 승인, 암호화를 관리할 수 있는 분산 서비스로 구성된 시스템에서 서비스 품질을 유지보수하는 서비스 간 통신을 허용할 수 있습니다.
- 서비스를 API로 노출하여 조직 및 외부 사용자가 이러한 서비스를 소비할 수 있게 해주는 Apigee와 같은 API 관리 플랫폼을 사용합니다.
환경 경계에서 시스템을 안전하게 인증할 수 있도록 환경 간에 일반 ID를 설정합니다.
퍼블릭 클라우드에 CI/CD 및 구성 관리 시스템을 배포합니다. 자세한 내용은 미러링된 네트워크 아키텍처 패턴을 참조하세요.
운영 효율을 높이기 위해서는 여러 환경에서 일관적인 도구 구성과 CI/CD 파이프라인을 사용합니다.
개별 워크로드 및 애플리케이션 아키텍처를 위한 권장사항
- 비록 이 패턴의 프런트엔드 애플리케이션에 초점이 맞춰져 있지만, 백엔드 애플리케이션을 최신화해야 함을 인식해야 합니다. 백엔드 애플리케이션의 개발 속도가 프런트엔드 애플리케이션보다 상당히 느릴 경우에는 이러한 차이로 인해 추가적인 복잡성이 발생할 수 있습니다.
- API를 백엔드 인터페이스로 취급하면 통합, 프런트엔드, 개발, 서비스 상호작용을 원활하게 지원하고 백엔드 시스템 복잡성을 숨길 수 있습니다. 이러한 과제를 해결하기 위해 Apigee는 하이브리드 및 멀티 클라우드 배포에 대한 API 게이트웨이/프록시 개발과 관리를 지원합니다.
- 콘텐츠(정적과 동적), 검색 엔진 최적화 성능, 페이지 로드 속도 기대치를 기준으로 프런트엔드 웹 애플리케이션의 렌더링 접근 방법을 선택합니다.
- 콘텐츠 기반의 웹 애플리케이션을 위한 아키텍처를 선택할 때는 모놀리식, 서버리스, 이벤트 기반, 마이크로서비스 아키텍처 등 다양한 옵션을 이용할 수 있습니다. 가장 적합한 아키텍처를 선택하려면 현재 및 미래의 애플리케이션 요구사항에 따라 이러한 옵션을 철저하게 평가해야 합니다. 비즈니스 및 기술적 목표에 맞게 조정된 아키텍처 의사결정을 내리기 위해서는 콘텐츠 기반 웹 애플리케이션 백엔드를 위한 여러 아키텍처 비교 및 웹 백엔드의 주요 고려사항을 참조하세요.
마이크로서비스 아키텍처에서는 Kubernetes를 공통 런타임 레이어로 사용하여 컨테이너화된 애플리케이션을 사용할 수 있습니다. 계층형 하이브리드 아키텍처 패턴에서는 다음 시나리오 중 하나로 실행할 수 있습니다.
두 환경 전체(Google Cloud 및 온프레미스 환경)에서 실행
- 환경 전체에서 컨테이너 및 Kubernetes를 사용하면 워크로드를 현대화하고 서로 다른 시간에 Google Cloud로 마이그레이션하는 유연성이 있습니다. 따라서 워크로드가 서로 크게 의존하고 개별적으로 마이그레이션할 수 없는 경우에 도움이 됩니다. 또는 하이브리드 워크로드 이동성을 이용해서 각 환경에서 최상의 리소스를 사용할 수 있습니다. 모든 경우에 GKE Enterprise는 핵심적인 지원 기술이 될 수 있습니다. 자세한 내용은 GKE Enterprise 하이브리드 환경을 참조하세요.
마이그레이션 및 현대화된 애플리케이션 구성요소의 Google Cloud 환경에서 실행
- 컨테이너화 지원이 부족하거나 단기적으로 현대화를 위해 상당한 시간과 리소스가 필요한 기존 백엔드가 온프레미스로 있으면 이 접근 방법을 사용합니다.
웹 애플리케이션 아키텍처를 현대화하기 위해 마이크로서비스 아키텍처에 대한 모놀리식 앱 설계 및 리팩터링에 대한 자세한 내용은 마이크로서비스 소개를 참조하세요.
웹 애플리케이션의 요구에 따라 데이터 스토리지 기술을 조합할 수 있습니다. 다양한 데이터 스토리지 요구를 충족하기 위해서는 정형 데이터에 Cloud SQL을 사용하고 미디어 파일에 Cloud Storage를 사용하는 것이 일반적입니다. 하지만 선택은 사용 사례에 가장 크게 의존합니다. 콘텐츠 기반의 애플리케이션 백엔드 및 효율적인 ���달성을 위한 데이터 스토리지 옵션에 대한 자세한 내용은 콘텐츠 기반 웹앱을 위한 데이터 스토리지 옵션을 참조하세요. 또한 Google Cloud 데이터베이스 옵션 설명을 참조하세요.