클라우드에서 워크로드를 실행하려면 일부 시나리오에서 클라이언트의 경우 신속하고 안정적인 인터넷 연결이 보장되어야 합니다. 현재의 네트워크를 고려하면, 이러한 요구사항은 클라우드 채택에 있어 거의 문제가 되지 않습니다. 그러나 다음과 같이 지속적인 연결을 사용할 수 없는 시나리오가 있습니다.
해상 선박과 기타 차량은 간헐적으로 연결되거나 지연 시간이 긴 위성 링크에만 액세스할 수 있습니다.
공장이나 발전소가 인터넷에 연결되어 있을 수 있습니다. 이러한 시설에는 인터넷 제공업체의 가용성 보장을 초과하는 안정성 요구사항이 있을 수 있습니다.
소매점과 슈퍼마켓은 가끔만 연결되거나 비즈니스에 중요한 거래를 처리하는 데 필요한 안정성이나 처리량을 제공하지 않는 링크를 사용할 수 있습니다.
에지 하이브리드 아키텍처 패턴은 시간적, 비즈니스적으로 중요한 워크로드는 네트워크의 에지에서 로컬로 실행하고, 그 외의 모든 워크로드는 클라우드를 사용하여 이러한 문제를 해결합니다. 에지 하이브리드 아키텍처에서 인터넷 링크는 관리 목적으로 사용되며, 주로 비동기식으로 데이터 동기화와 업로드에 활용되지만, 시간적, 비즈니스적으로 중요한 트랜잭션에는 관여하지 않는 비핵심 구성 요소입니다.
장점
특정 워크로드를 에지에서 실행하고 다른 워크로드를 클라우드에서 실행하면 다음과 같은 여러 가지 이점이 있습니다.
에지에서 Google Cloud로 데이터를 이동하는 인바운드 트래픽은 무료일 수 있습니다.
시간적, 비즈니스적으로 중요한 워크로드를 에지에서 실행하면 지연 시간이 단축되고 자가 효율성이 향상됩니다. 인터넷 연결이 실패하거나 인터넷 연결을 일시적으로 사용할 수 없는 경우에도 모든 중요 트랜잭션을 계속 실행할 수 있습니다.
동시에 전체 워크로드의 상당 부분에 클라우드를 사용함으로써 이점을 얻을 수 있습니다.
컴퓨팅 및 스토리지 장비에 대한 기존 투자를 재사용할 수 있습니다.
시간이 지남에 따라 특정 애플리케이션을 다시 작동하거나 일부 에지 위치에 더 안정적인 인터넷 링크를 장착하여 에지에서 실행되는 워크로드의 비율을 점차적으로 줄이고 클라우드로 이동할 수 있습니다.
사물 인터넷(IoT) 관련 프로젝트는 로컬에서 데이터 계산을 실행하여 비용 효율성을 높일 수 있습니다. 이를 통해 기업은 데이터 소스에 더 가까운 에지에서 일부 서비스를 로컬로 실행하고 처리할 수 있습니다. 또한 기업은 데이터를 클라우드로 선택적으로 전송할 수 있으므로 IoT 솔루션의 용량, 데이터 전송, 처리, 전반적인 비용을 줄일 수 있습니다.
에지 컴퓨팅은 기존 서비스와 현대화된 서비스 간에 중간 통신 레이어 역할을 할 수 있습니다. 예를 들어 Apigee Hybrid와 같이 컨테이너화된 API 게이트웨이를 실행할 수 있는 서비스입니다. 이를 통해 기존 애플리케이션과 시스템을 IoT 솔루션과 같은 현대화된 서비스와 통합할 수 있습니다.
솔루션이 공개 인터넷을 통해 Google Cloud에 연결되는 여러 에지 원격 사이트로 구성된 경우 소프트웨어 정의 WAN(SD-WAN) 솔루션을 사용할 수 있습니다. Google Cloud 파트너가 지원하는 서드 파티 SD-WAN 라우터와 함께 Network Connectivity Center를 사용하여 대규모로 보안 연결을 간편하게 프로비저닝하고 관리할 수도 있습니다.
에지에서 실행 중인 시스템과 클라우드 환경에서 실행 중인 시스템 간의 종속 항목을 최소화합니다. 각 종속 항목은 에지 하이브리드 설정의 안정성과 지연 시간 이점을 약화시킬 수 있습니다.
여러 에지 위치를 효율적으로 관리 및 운영하려면 클라우드에 중앙 집중식 관리 영역과 모니터링 솔루션이 있어야 합니다.
클라우드와 에지 환경에서 배포 및 모니터링용 도구와 CI/CD 파이프라인이 일관성을 갖는지 확인합니다.
해당하고 실행 가능한 경우 컨테이너와 Kubernetes를 사용하여 다양한 에지 위치 간의 차이와 에지 위치와 클라우드 간의 차이를 추상화하는 것이 좋습니다. Kubernetes는 공통 런타임 레이어를 제공하므로 컴퓨팅 환경 전반에서 워크로드를 지속적으로 개발, 실행, 운영할 수 있습니다. 에지와 클라우드 간에 워크로드를 이동할 수도 있습니다.
하이브리드 설정 및 운영을 간소화하려면 이 아키텍처에 GKE Enterprise를 사용하면 됩니다(여러 환경에서 컨테이너가 사용되는 경우).
온프레미스 또는 에지 환경에서 실행 중인 GKE Enterprise 클러스터를 Google Cloud에 연결해야 하는 가능한 연결 옵션을 고려하세요.
이 패턴의 일환으로 일부 GKE Enterprise 구성요소는 Google Cloud에 대한 일시적인 연결 중단 중에 유지될 수 있지만, Google Cloud에서 연결이 끊어진 상태를 GKE Enterprise의 일반적인 작동 모드로 사용해서는 안 됩니다. 자세한 내용은 일시적인 Google Cloud 연결 해제로 인한 영향을 참조하세요.
여러 백엔드 및 에지 서비스 간에 프로토콜, API, 인증 메커니즘의 불일치 문제를 해결하기 위해서는 가능한 경우 API 게이트웨이 또는 프록시를 통합 퍼사드로 배포하는 것이 좋습니다.
이러한 게이트웨이 또는 프록시는 중앙화된 컨트롤 포인트로 작동하며 다음과 같은 측정을 수행합니다.
추가 보안 측정을 구현합니다.
백엔드 코드 변경사항으로부터 클라이언트 앱과 기타 서비스를 보호합니다.
모든 교차 환경 애플리케이션과 분리된 구성요소 사이의 통신을 위한 감사 추적을 지원합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2023-12-14(UTC)"],[[["\u003cp\u003eEdge hybrid architecture allows for running time- and business-critical workloads locally at the edge while utilizing the cloud for other workloads, addressing challenges posed by intermittent or unreliable internet connectivity.\u003c/p\u003e\n"],["\u003cp\u003eThis architecture ensures low latency and self-sufficiency for essential transactions, even during internet outages, while still leveraging cloud benefits for a significant portion of overall workload.\u003c/p\u003e\n"],["\u003cp\u003eImplementing edge hybrid can improve cost efficiency, particularly for IoT projects, by enabling local data processing and selective cloud data transfer.\u003c/p\u003e\n"],["\u003cp\u003eIt's best to minimize dependencies between edge and cloud systems to maximize reliability and latency advantages, while also employing a centralized management and monitoring solution in the cloud for efficient operation.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing containers and Kubernetes, along with a unified API gateway, helps maintain consistency across diverse edge locations and between edge and cloud environments.\u003c/p\u003e\n"]]],[],null,["# Edge hybrid pattern\n\nRunning workloads in the cloud requires that clients in some scenarios have\nfast and reliable internet connectivity. Given today's networks, this\nrequirement rarely poses a challenge for cloud adoption. There are, however,\nscenarios when you can't rely on continuous connectivity, such as:\n\n- Sea-going vessels and other vehicles might be connected only intermittently or have access only to high-latency satellite links.\n- Factories or power plants might be connected to the internet. These facilities might have reliability requirements that exceed the availability claims of their internet provider.\n- Retail stores and supermarkets might be connected only occasionally or use links that don't provide the necessary reliability or throughput to handle business-critical transactions.\n\nThe *edge hybrid* architecture pattern addresses these challenges by running\ntime- and business-critical workloads locally, at the edge of the network, while\nusing the cloud for all other kinds of workloads. In an edge hybrid\narchitecture, the internet link is a noncritical component that is used for\nmanagement purposes and to synchronize or upload data, often asynchronously, but\nisn't involved in time or business-critical transactions.\n\nAdvantages\n----------\n\nRunning certain workloads at the edge and other workloads in the cloud offers\nseveral advantages:\n\n- Inbound traffic---moving data from the edge to Google Cloud---[might be free of charge](/vpc/network-pricing#general).\n- Running workloads that are business- and time-critical at the edge helps ensure low latency and self-sufficiency. If internet connectivity fails or is temporarily unavailable, you can still run all important transactions. At the same time, you can benefit from using the cloud for a significant portion of your overall workload.\n- You can reuse existing investments in computing and storage equipment.\n- Over time, you can incrementally reduce the fraction of workloads that are run at the edge and move them to the cloud, either by reworking certain applications or by equipping some edge locations with internet links that are more reliable.\n- Internet of Things (IoT)-related projects can become more cost-efficient by performing data computations locally. This allows enterprises to run and process some services locally at the edge, closer to the data sources. It also allows enterprises to selectively send data to the cloud, which can help to reduce the capacity, data transfer, processing, and overall costs of the IoT solution.\n- Edge computing can act as an [intermediate communication layer](/solutions/unlocking-legacy-applications#section-3) between legacy and modernized services. For example, services that might be running a containerized API gateway such as Apigee hybrid). This enables legacy applications and systems to integrate with modernized services, like IoT solutions.\n\nBest practices\n--------------\n\nConsider the following recommendations when implementing the edge hybrid\narchitecture pattern:\n\n- If communication is unidirectional, use the [gated ingress pattern](/architecture/hybrid-multicloud-secure-networking-patterns/gated-ingress).\n- If communication is bidirectional, consider the [gated egress and gated ingress pattern](/architecture/hybrid-multicloud-secure-networking-patterns/gated-egress-ingress).\n- If the solution consists of many edge remote sites connecting to Google Cloud over the public internet, you can use a software-defined WAN (SD-WAN) solution. You can also use [Network Connectivity Center](/network-connectivity/docs/network-connectivity-center/concepts/ra-overview) with a third-party SD-WAN router supported by a [Google Cloud partner](/network-connectivity/docs/network-connectivity-center/partners) to simplify the provisioning and management of secure connectivity at scale.\n- Minimize dependencies between systems that are running at the edge and systems that are running in the cloud environment. Each dependency can undermine the reliability and latency advantages of an edge hybrid setup.\n- To manage and operate multiple edge locations efficiently, you should have a centralized management plane and monitoring solution in the cloud.\n- Ensure that CI/CD pipelines along with tooling for deployment and monitoring are consistent across cloud and edge environments.\n- Consider using containers and Kubernetes when applicable and feasible, to abstract away differences among various edge locations and also among edge locations and the cloud. Because Kubernetes provides a common runtime layer, you can develop, run, and operate workloads consistently across computing environments. You can also move workloads between the edge and the cloud.\n - To simplify the hybrid setup and operation, you can use [GKE Enterprise](/anthos/docs/concepts/gke-editions) for this architecture (if containers are used across the environments). Consider [the possible connectivity options](/anthos/clusters/docs/bare-metal/latest/concepts/connect-on-prem-gcp) that you have to connect a GKE Enterprise cluster running in your on-premises or edge environment to Google Cloud.\n- As part of this pattern, although some GKE Enterprise components might sustain during a temporary connectivity interruption to Google Cloud, don't use GKE Enterprises when it's disconnected from Google Cloud as a nominal working mode. For more information, see [Impact of temporary disconnection from Google Cloud](/anthos/docs/concepts/anthos-connectivity).\n- To overcome inconsistencies in protocols, APIs, and authentication mechanisms across diverse backend and edge services, we recommend, where applicable, to deploy an API gateway or proxy as a unifying [facade](/apigee/resources/ebook/api-facade-pattern-register). This gateway or proxy acts as a centralized control point and performs the following measures:\n - Implements additional security measures.\n - Shields client apps and other services from backend code changes.\n - Facilitates audit trails for communication between all cross-environment applications and its decoupled components.\n - Acts as an [intermediate communication layer](/solutions/unlocking-legacy-applications#section-3) between legacy and modernized services.\n - Apigee and [Apigee Hybrid](/apigee/docs/hybrid/v1.10/what-is-hybrid) let you host and manage enterprise-grade and hybrid gateways across on-premises environments, edge, other clouds, and Google Cloud environments.\n- [Establish common identity](/architecture/authenticating-corporate-users-in-a-hybrid-environment) between environments so that systems can authenticate securely across environment boundaries.\n- Because the data that is exchanged between environments might be sensitive, ensure that all communication is encrypted in transit by using VPN tunnels, [TLS](/architecture/landing-zones/decide-security#option-2-require-layer7), or both."]]
