SAP on Google Cloud

Google Cloud 기반 SAP: 원활한 배포를 위한 네트워크 설정

2021년 12월 13일

https://storage.googleapis.com/gweb-cloudblog-publish/images/SAP-hero-2.max-1400x1400.png

Tinu Anand Chandrasekar

Customer Engineer, Google Cloud

GCP 사용해 보기

$300의 무료 크레딧과 20개 이상의 항상 무료인 제품으로 Google Cloud 사용을 시작해보세요.

무료 체험

* 본 아티클의 원문은 2021년 9월 3일 Google Cloud 블로그(영문)에 게재되었습니다.

SAP는 수많은 기업의 중요한 근간을 이루며 금융, 공급망, 창고 관리 등 여러 중요한 비즈니스 기능을 지원하고 있습니다. Google Cloud는 이러한 워크로드를 실행할 확장성이 뛰어나고 복원력이 우수한 인프라를 제공하고, 조직의 디지털 혁신을 가속화할 수 있는 스마트 분석과 머신러닝 같은 도구를 제공합니다.

실제로 Forrester의 최근 연구에 따르면 Google Cloud에서 SAP를 실행하면 기존 인프라 비용 절감, 다운타임 방지, 생산성 개선을 통해 투자수익을 160% 달성하고 6개월 이내에 자본을 회수할 수 있습니다.

네트워크에 SAP 시스템을 배포하는 방식에 따라 가용성, 복원력, 성능이 큰 영향을 받습니다. 일반적으로 SAP 배포에는 별도의 프로덕션 및 고가용성(HA) 환경 이외에도 샌드박스, 개발, 품질 보증(QA), 재해 복구 환경이 포함됩니다.

Google 네트워크의 대부분은 가상이기 때문에 SAP 관리자는 조직의 SAP 배포 및 조직 구조에 적합한 복잡한 환경을 간편하게 설계하면서 동시에 보안 및 운영 요건을 충족할 수 있습니다.

Google Cloud 기반 SAP를 시작할 때 다양한 SAP 시스템의 가용성과 성능을 보장하기 위해 네트워킹을 구성하는 방법을 결정해야 합니다. 다음과 같은 옵션이 있습니다.

VPC 및 공유 VPC

Virtual Private Cloud(VPC)는 Google Cloud 내에서 호스팅되는 안전하고 격리된 비공개 네트워크입니다. VPC는 Google Cloud에서 전역적이므로 공개 인터넷으로 통신하지 않아도 단일 VPC를 여러 리전으로 확장할 수 있습니다. 마찬가지로 서브넷은 한 리전 내 여러 영역에 걸쳐 있을 수 있습니다. 하나의 영역은 단일 장애 도메인을 나타내므로 일반적인 SAP 배포에서는 복원력을 보장하기 위해 프로덕션 및 HA 시스템을 서로 다른 영역에 배치합니다. 프로덕션 시스템과 HA 시스템을 모두 포함하는 서브넷이 여러 영역에 걸쳐 있을 수 있기 때문에 Google Cloud에서는 SAP 배포가 간단합니다.

이 기능은 또한 SAP의 클러스터링을 간소화하는데 클러스터의 가상 IP(VIP) 주소가 프로덕션 및 HA 머신의 주소와 동일한 범위에 있을 수 있기 때문입니다. 이러한 구성은 Google 내부 부하 분산기를 사용하여 유동 IP를 보호하고, 애플리케이션 레이어(ASCS 및 ERS) 및 HANA 데이터베이스 레이어(HANA 기본 및 보조)의 HA 클러스터링에 적용할 수 있습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/SAP_Networking_GCP_1.max-1900x1900.jpg

공유 VPC는 Google Cloud 고유의 기능으로서 조직은 이를 통해 여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결할 수 있습니다. 따라서 리소스는 내부 IP를 사용하여 서로 안전하고 효율적으로 통신할 수 있습니다. 또한 방화벽을 사용하여 동일한 서브넷 및 서로 다른 서브넷의 Compute Engine 간 통신을 검사하는 동안 호스트 프로젝트의 모든 SAP 프로젝트(서비스)에 대한 네트워크를 중앙에서 제어할 수 있습니다. (이러한 시스템 간 통신은 일반적으로 레이어 4에서 SAP 원격 함수 호출(RFC) 통신을 통해 필수 포트로만 제한하는 것이 좋습니다.)

네트워크를 설계할 때 먼저 공유 VPC 네트워크가 포함된 호스트 프로젝트부터 시작합니다. 추가 서비스 프로젝트를 호스트 프로젝트에 연결하면 서비스 프로젝트가 공유 VPC에 참여할 수 있습니다. 여러 서비스 프로젝트를 조직의 여러 부서 또는 팀에서 운영하고 관리하는 것이 일반적입니다.

필요에 따라 SAP를 단일 또는 여러 공유 VPC에 배포할 수 있습니다. 두 시나리오는 네트워크 제어, SAP 환경 격리, 네트워크 검사 측면에서 다릅니다. 이러한 차이점을 자세히 알아보겠습니다.

시나리오 1: 단일 공유 VPC에 SAP 배포하기

하나의 네트워크 검사만 필요한 경우 SAP를 단일 공유 VPC에 배포하면 간편하다는 장점이 있고 관리 오버헤드를 줄일 수 있습니다.

네트워크 제어: 공유 VPC가 네트워크 허브 역할을 하므로 프로덕션과 비프로덕션 환경 모두에서 네트워크 팀의 ID 및 액세스 관리(IAM) 역할을 기반으로 중앙에서 네트워크를 관리할 수 있습니다.
SAP 환경 격리: 각 SAP 환경에 대한 프로젝트 및 서브넷을 만들 수 있습니다. 프로젝트는 리소스를 그룹화하여 세밀하게 IAM을 제어하고 청구 정보를 파악하는 데 도움을 주며 서브넷은 개별 SAP 환경의 네트워크 격리를 제공합니다. 서비스 프로젝트에서 Compute Engine은 기본적으로 통신할 수 있지만 간단한 방화벽 규칙을 채택하여 하나의 서브넷이나 별도의 서브넷에 있는 Compute Engine 간의 통신을 차단할 수 있습니다.
네트워크 검사: Google Cloud 방화벽을 사용하여 SAP 시스템 간 통신에 필수 포트만 허용하도록 할 수 있습니다. 네트워크 태그 및 서비스 계정을 활용하여 North-South 트래픽과 East-West 트래픽에 대한 세밀한 제어를 정의할 수 있습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/SAP_Networking_GCP_2.max-2000x2000.jpg

시나리오 2: 여러 공유 VPC에 SAP 배포하기

추가 네트워크 검사가 필요한 시나리오에서는 일반적으로 환경마다 하나씩 여러 공유 VPC를 만들 수 있습니다. 이러한 공유 VPC 사이의 피어링을 사용하여 SAP 개발, QA, 프로덕션 시스템 간 RFC 통신을 지원합니다.

네트워크 격리: 여러 공유 VPC는 Google Cloud 방화벽에서 개방된 특정 포트를 통하는 경우를 제외하고 서로 완전히 격리됩니다. 따라서 Google Cloud 네트워크에서 네트워크 가상 어플라이언스(NVA)로 추가 East-West 트래픽 검사가 가능합니다.
네트워크 제어: 공유 VPC 수가 증가하면 피어링 같은 활동과 방화벽 정책도 증가합니다. 이는 공유 VPC가 제공하는 중앙 네트워크 제어를 약화하므로 네트워크팀은 각 VPC에서 개별적으로 정책을 관리하는 계획을 수립해야 합니다.