Application Load Balancer for SAP Enterprise Portal

이 글은 AWS AWS for SAP Blog에 게시된 Application Load Balancer for SAP Enterprise Portal by Debasis Sahoo를 한국어 번역 및 편집하였습니다.

소개

SAP 엔터프라이즈 포털(EP)과 같은 SAP Java 애플리케이션의 경우, 고객은 SAP 웹 디스패처를 HTTP 요청의 진입점으로 사용합니다. SAP 웹 디스패처는 인터넷 또는 인트라넷에서 들어오는 요청을 수신하고 애플리케이션 서버에 요청을 배포합니다. 인터넷 기반 HTTP 요청의 경우, 인터넷에 접속할 수 있어야 하므로 공용 서브넷에 설치해야 합니다. 많은 SAP 고객은 가능한 공격 표면을 줄여 잠재적인 공격 반경을 줄이기 위해 공용 서브넷에 EC2 인스턴스를 설치하지 않습니다.

이 블로그에서는 고객이 SAP EP 애플리케이션을 위해 Elastic Load Balancing (ELB)을 사용하는 방법에 대해 설명합니다. SAP EP 애플리케이션은 애플리케이션 로드 밸런서(ALB)를 사용해 HTTP 요청을 로드 밸런싱합니다. SAP 웹 디스패처와 달리, ALB는 서버리스 서비스이며 AWS에서 완전히 관리합니다. ALB를 인터넷에 연결하여 SAP EP에 HTTP 트래픽을 제공하도록 구성할 수 있습니다. 고객은 ALB를 통해 알려진 취약점을 해결하기 위해 AWS 웹 애플리케이션 방화벽 (WAF), 콘텐츠 가속을 위한 Amazon CloudFront, TLS/SSL 인증서를 관리하기 위한 AWS Certificate Manager(ACM)와 통합할 수 있습니다.

애플리케이션 로드 밸런서와 그 기능

ALB는 클라이언트로부터 HTTP 요청을 받아 규칙에 따라 대상 그룹에 배포하는 고가용성 서비스입니다. 각 대상 그룹에는 SAP EP를 위한 단일 또는 여러 애플리케이션 서버의 IP 주소 또는 EC2 인스턴스 ID와 HTTP 포트 조합이 포함됩니다. HTTP 요청은 ALB에 의해 애플리케이션 서버로 전달됩니다.

ALB는 다음과 같은 SAP EP 요구 사항을 충족할 수 있습니다.

1. 가용성이 높고 여러 가용 영역(AZ)에 걸쳐 요청을 분산할 수 있는 레이어 7 HTTP 부하 분산 서비스를 제공합니다.
2. 수동 서버 유지 관리가 필요 없는(서버리스) 매우 안전하고 안정적이며 확장 가능한 관리형 AWS 서비스를 제공합니다.
3. 호스트 및/또는 포트 기반 매핑을 기반으로 여러 애플리케이션 서버로 HTTP 요청 전달할 수 있습니다.
4. TLS/SSL 암호화 오프로딩. ALB는 SSL 인증서와 함께 작동하여 로드 밸런서와 클라이언트 간의 트래픽을 암호화합니다. 들어오는 트래픽은 SAP 애플리케이션을 호스팅하는 EC2 인스턴스에 도달하기 전에 ACL(액세스 제어 목록)에 대한 엄격한 검사를 통과해야 합니다.
5. 간단하고 보호된 GSS-API 협상(SPNEGO)을 통한 싱글 사인온(SSO) 지원 및 Active Directory와 같은 ID 공급자를 통한 SAML(Security Assertion Markup Language) 인증을 지원합니다.
6. HTTP 요청 필터링. WAF는 ALB와 함께 이 블로그에서 언급한 SQL 인젝션과 같은 OWASP(오픈 웹 애플리케이션 보안 프로젝트) 공격에 대한 추가 보안 계층으로 사용할 수 있습니다. 또한 ACL 및 규칙의 형태로 트래픽 검사 및 필터 규칙 지원도 제공합니다. 설명서에 따라 WAF에서 사용자 지정 규칙을 정의할 수 있습니다.
7. SSL 인증서 관리. 이 문서에 설명된 대로 ACM을 사용하여 SSL/TLS 인증서를 관리할 수 있습니다.

아키텍처

1) SAP EP용 단일 ALB 아키텍처

여러 SAP 애플리케이션 서버 간에 부하를 분산하기 위해 단일 ALB를 사용할 수 있습니다. ALB는 인터넷용 또는 인트라넷용(내부 ALB라고도 함)이 될 수 있습니다. 직접 연결 또는 VPN(가상 사설망)을 통해 고객 네트워크에서 도착하는 HTTP 요청의 경우, “내부” ALB가 요청을 애플리케이션 서버로 전달하고 부하를 분산합니다. 그러나 고객이 사용자가 인터넷에서 SAP EP로 접속할 수 있도록 허용하려면 그림 1 오른쪽 다이어그램에 표시된 것처럼 인터넷 접속 ALB가 필요하며, 인터넷 접속 ALB는 공용 서브넷에 배포됩니다.

그림 1: 왼쪽 – SAP EP를 위한 단일 내부 ALB 아키텍처, 오른쪽 – SAP EP를 위한 단일 인터넷 ALB 아키텍처

2) SAP EP용 ALB 샌드위치 아키텍처

그림 2: SAP EP를 위한 ALB 샌드위치 아키텍처

그림 2와 같이 퍼블릭 서브넷에 인터넷을 향한 ALB와 프라이빗 서브넷에 두 번째 내부 ALB가 있는 두 개의 ALB를 조합할 수 있습니다. 이러한 배포는 SAP 애플리케이션 서브넷이 인터넷에 노출되지 않기 때문에 폭발 반경을 줄일 수 있으며, 아키텍처를 더욱 안전하게 만드는 동시에 복원력을 위해 AWS Well-Architected Framework와 연계할 수 있습니다.

아키텍처 설명

• 퍼블릭 서브넷은 네트워크 계정에, 프라이빗 서브넷은 AWS 프로덕션 계정에 두는 두 개의 계정 전략을 고려했습니다. 단일 계정에 동일한 아키텍처를 배포할 수도 있습니다.
• 네트워크 계정은 인터넷에 액세스할 수 있는 반면, AWS 프로덕션 계정은 인터넷에 직접 액세스할 수 없습니다. 이렇게 하면 AWS 프로덕션 계정이 더 안전해집니다.
• 두 가지 ALB를 고려했습니다. 네트워크 계정의 ALB는 SAP EP용 인터넷 연결 ALB입니다. 이는 인터넷(외부) 사용자에게 서비스를 제공하며, 인트라넷(내부) ALB에 연결되어 인트라넷(내부) 사용자에게 서비스를 제공합니다.
• 그림 2에서는 가용성과 복원력을 개선하기 위해 여러 AZ에 분산된 VM 시리즈 방화벽 세트와 Amazon EC2 오토 스케일링 그룹을 사용했습니다.
• 이러한 샌드위치 아키텍처는 인바운드 트래픽 방화벽 검사에 대한 요구 사항을 해결하는 데 사용됩니다. 트래픽은 먼저 VM 시리즈 방화벽의 자동 확장 그룹에 대한 프런트엔드로 사용되는 ALB를 통과합니다. 각 방화벽의 대상은 그 뒤에 있는 대상 그룹(이 경우 EC2 인스턴스)을 포함하는 ALB입니다. 이 접근 방식을 사용하면 보안 검사 티어와 웹 프론트엔드 티어가 비용 효율적인 방식으로 서로 독립적으로 확장 및 축소할 수 있습니다. 자세한 내용은 이 블로그에서 확인할 수 있습니다.

인터넷 연결 ALB 구성

• 인터넷 연결 ALB는 HTTP 또는 HTTPS 트래픽을 수신하도록 구성됩니다. 보안을 강화하려면 HTTP 포트 80을 HTTPS 포트 443으로 라우팅하도록 설정합니다.
• 기본 보안 정책 ELBSecurityPolicy-2016-08은2를 지원하므로 인터넷 접속 및 내부 로드밸런서 모두에 권장되는 정책입니다.
• HTTPS 리스너의 경우, ACM 인증서 또는 타사 인증서를 사용하여 ALB에 하나의 SSL/TLS 서버 인증서를 배포합니다.

흐름은 다음과 같습니다:

1. 트래픽이 인터넷에 연결된 ALB에서 수신됩니다.
2. 방화벽 인스턴스 기반 대상 그룹으로 트래픽을 전달합니다.
3. 방화벽 인스턴스에서는 정적 NAT(네트워크 주소 변환) 또는 포트-호스트 간 NAT 정책을 사용하여 트래픽을 내부 ALB로 라우팅합니다.
4. 내부 ALB는 방화벽에서 트래픽을 수신합니다.

내부 ALB 구성

• 포트 80은 방화벽을 통해 라우팅되는 인터넷 연결 ALB에서 들어오는 요청을 수신 대기하기 위한 HTTP 포트로 정의됩니다.
• 포트 443은 회사 네트워크 내에서 SAP EP에 직접 액세스하는 사용자를 수신 대기하는 HTTPS 포트로 정의됩니다.
• 기본 보안 정책인 ELBSecurityPolicy-2016-08은2를 지원하므로 인터넷 연결 및 내부 로드밸런서 모두에 권장되는 정책입니다.
• HTTPS 리스너의 경우, ACM 인증서 또는 타사 인증서를 사용하여 ALB에 하나의 SSL/TLS 서버 인증서를 배포합니다.

그림 3: 내부 ALB 리스너

내부 ALB의 대상 그룹

SAP EP 애플리케이션 서버의 모든 IP 주소가 대상 그룹에 추가됩니다. EC2 인스턴스를 추가할 수 있지만, 장애로 인해 종료되는 경우 EC2 인스턴스 ID가 변경되고 새 인스턴스가 그 자리를 대신할 수 있으므로 “IP 주소”를 대상으로 추가하는 것이 좋습니다.

그림 4: 내부 ALB의 SAP EP 대상 그룹

SAP EP 타겟 그룹 속성

그림 5: SAP EP의 세션 유지 설정

SAP EP를 사용하려면 애플리케이션 기반 세션 유지 설정을 활성화해야 합니다. 사용자 세션을 지원하기 위해 이미 세션을 맺고 있는 애플리케이션 서버에 후속 요청을 전달해야 합니다. 백엔드 SAP EP가 saplb_* 쿠키를 추가하고 있는지 확인해야 하며, ALB는 해당 값을 복사하여 AWSALBAPP-* 쿠키라는 또 다른 쿠키를 생성합니다. 세션 지속 시간은 사용자 세션이 ALB에 의해 항상 특정 애플리케이션 서버로 라우팅될 수 있도록 충분히 적절해야 합니다. 요구 사항에 따라 조정할 수 있습니다. 근무 시간 또는 하루 동안 사용하는 것이 좋습니다.

리스너 규칙

리스너는 사용자가 구성한 프로토콜과 포트를 사용하여 연결 요청을 확인하는 프로세스입니다. ALB를 생성할 때 리스너를 정의하고 언제든지 로드밸런서에 리스너를 추가할 수 있습니다. 예를 들어, 그림 3과 같이 내부 ALB에 두 개의 리스너를 정의했습니다:

1. 인터넷에서 ALB를 향하는 트래픽을 위한 HTTP 80
2. 기업 네트워크에서 도착하는 트래픽을 위한 HTTPS 443

리스너에 대한 리스너 규칙은 ALB가 등록된 대상으로 요청을 라우팅하는 방법을 결정합니다. 각 규칙은 우선순위, 하나 이상의 작업, 하나 이상의 조건으로 구성됩니다. 자세한 내용은 이 설명서를 참조하세요.

내부 ALB 리스너 규칙

아래 표는 ALB의 규칙 및 구성 예시를 설명합니다.

위의 두 개의 리스너 규칙 5와 6은 시스템 관리자만 내부적으로 UME(사용자 관리 엔진) 관리자에 액세스할 수 있도록 합니다.

규칙 5는 내부 회사 서브넷 범위 10.0.0.0/8 또는 192.168.138.0/24 또는 192.168.139.0/24 내의 IP 주소에서 UME 관리자 액세스가 허용됨을 나타냅니다.

규칙 6은 다른 IP 주소에서 UME 관리자에 액세스할 수 없음을 나타냅니다.

그림 6: 내부 ALB HTTP 리스너 포트 443 구성

인터넷 연결 ALB 리스너 규칙

HTTP 요청이 포트 443이 열려있는 인터넷 연결 ALB에 도달하면, 인터넷 연결 ALB의 대상 그룹으로 정의된 내부 ALB로 트래픽을 전달합니다.

리스너 규칙에 따라 인터넷에서 UME 관리자에게 요청이 오면 그림 7과 그림 8에 따라 차단됩니다.

그림 7: 내부 ALB HTTP 리스너 포트 80 구성

그림 8: 인터넷에서 사용자 관리자 URL에 액세스하려고 할 때의 결과

ALB 속성 및 보안 고려 사항

• 유효하지 않은 패킷을 삭제하고 유효하지 않은 헤더 필드가 있는 HTTP 헤더가 로드밸런서에 의해 제거되도록 ALB를 구성하는 것이 권장됩니다.
• TLS 1.1에 비해 보안이 강화된 TLS 1.2가 ALB 수준에서 적용되고 있습니다.
• EC2 오토 스케일링이 설정된 경우 삭제 방지 설정을 비활성화해야 합니다.
• 유휴 시간 제한은 SAP 애플리케이션의 처리 시간 제한과 같거나 그 이상이어야 합니다. 기본적으로 SAP EP의 타임아웃은 600초이며, 이는 인터넷과 인트라넷 모두에서 ALB를 향하도록 통합되어야 합니다.

인터넷을 통해 SAP EP를 통해 SAP ECC 백엔드 콘텐츠에 액세스하기 위한 ALB 지원

우리는 ALB가 인터넷을 통해 SAP EP에 대한 연결뿐만 아니라 SAP EP에서 SAP ECC 백엔드로의 리디렉션도 지원하기를 바랍니다. 퍼블릭 인터넷을 통해 SAP EP에서 SAP ECC 백엔드로 트래픽이 이동하는 방식에 대한 자세한 내용은 이 SAP 블로그를 참조하세요.

일부 고객은 인터넷 트래픽에 대해 하나의 FQDN(정규화된 도메인 이름)과 포트 조합만 허용하는 엄격한 정책을 가지고 있습니다. 이러한 경우 컨텍스트 또는 경로 기반 매핑을 통해서만 여러 SAP 시스템 간에 부하를 분산할 수 있습니다. 예를 들어, 고객이 포트 443을 사용하는 단일 외부 ALB만 허용하고 SAP EP 및 SAP Fiori에 대한 연결을 허용해야 하는 경우, 리스너 규칙 조건에 SAP EP의 경우 “/irj/portal” 또는 “/nwa”, SAP Fiori의 경우 “/fiori” 경로별 매핑이 포함되어야 합니다. 이렇게 하면 ALB가 하나만 있는 경우, 특히 “/icon”, “/sap” 등과 같은 일반적인 콘텐츠가 있는 경우 경로 충돌이 발생할 수 있습니다. 따라서 인터넷 접속 및 인트라넷 사용자를 위해 여러 SAP 솔루션에 대해 두 개 이상의 ALB를 조합하여 아키텍처를 구축하는 것이 좋습니다.

다음 아키텍처는 컨텍스트 기반 매핑에 사용되는 두 쌍의 ALB를 보여줍니다. 하나는 SAP EP용이고 다른 하나는 각 애플리케이션에 도달하기 위한 SAP ECC용입니다.

그림 9: 인터넷을 통해 SAP EP에서 SAP ECC 콘텐츠에 액세스하기 위한 멀티 ALB 아키텍처

인터넷을 통해 SAP EP를 통해 SAP ECC 기능을 제공한다는 목표를 달성하기 위해 두 쌍의 ALB를 고려했습니다. 첫번째 ALB들은 (그림 9에서 1번으로 표시된 초록색 박스) 앞서 SAP EP에 대해 설명한 아키텍처를 갖춘 인터넷용과 내부용 ALB입니다. 두번째 ALB들은 (그림 9에서 2번으로 표시된 초록색 박스) SAP ECC를 바라보는 인터넷용과 내부용 ALB입니다.

SAP ECC webdynpro URL은 인터넷을 통해 직접 접속할 수 없고 SAP EP 또는 동일한 도메인의 시스템을 통해서만 접속할 수 있도록 해야 합니다.

이는 그림 10에 표시된 것처럼 SAP ECC용 인터넷 대면 ALB에 리스너 규칙을 구현하여 달성할 수 있으며, 이 규칙은 “HTTP 헤더 Referer” 필드에서 ess-ep.example.com ALB FQDN에서만 ECC 서비스에 액세스할 수 있고 인터넷을 통한 모든 ECC 서비스에 대한 직접 액세스는 HTTP 응답 402로 차단되도록 합니다.

그림 10: ECC ALB 리스너 규칙의 HTTP 헤더 리퍼러

SAP ERP용 내부 ALB는 리스너 포트 443을 통해 직접 액세스할 수 있으므로 내부 기업 네트워크에서 직접 액세스하거나 SAP EP에서 참조할 수 있습니다.

그림 11: SAP EP 내에서 ESS iView

그림 12: 시스템 Alias 구성

예를 들어, 인터넷 사용자는 그림 11에 설명된 대로 https://ess-ecc.example.com/sap/bc/webdynpro/ZHRESS 에서 SAP ECC ALB로 설정된 SAP ECC에서 실행되는 직원 셀프 서비스(ESS) webdynpro 애플리케이션에 액세스하기 위해 SAP EP ALB 기반 포털 URL https://ess-ep.example.com/irj/portal 에 로그인할 수 있습니다.

그림 12에 표시된 바와 같이 SAP ECC의 ‘시스템 Alias’은 https:// URL >/irj/portal → 시스템 관리 → 시스템 환경을 통해 SAP EP에서 직접 SSO를 사용할 수 있도록 SAP ECC ALB FQDN으로 정의되어 있습니다. SAP ECC의 인터넷 트랜잭션 서버(ITS) 호스트 이름과 애플리케이션 서버 호스트 이름은 SAP ECC ALB FQDN으로 정의되었습니다.

예상되는 HTTP 요청 흐름:

• 사용자는 먼저 SAP EP 포털의 URL에 액세스하여 /irj/portal을 엽니다.
• 요청은 VM 시리즈 방화벽을 통과하기 전에 인터넷에 연결된 SAP EP ALB에 도달합니다.
• 그런 다음 요청은 SAP EP용 내부 ALB로 전달되고 마지막으로 SAP EP 애플리케이션 서버로 전달됩니다.
• SAP EP 내부에서 사용자가 ESS 탭을 클릭하면 요청이 인터넷 연결 SAP ECC용 ALB로 리디렉션됩니다.
• 그런 다음 요청은 VM 시리즈 방화벽으로 전송되어 리스너 규칙을 확인하는 SAP ECC 내부 ALB에 도달합니다.
• 일치하는 조건에 따라 트래픽을 SAP ECC 대상 그룹으로 전송하여 SAP ECC 애플리케이션 서버에 도달합니다.

사용자가 인터넷을 통해 SAP ECC webdynpro URL을 직접 방문하려고 시도하는 경우, 그림 10에 설명된 대로 규칙에 명시된 대로 “Referer”인 SAP EP ALB가 ECC ALB에 액세스할 수 있는 유일한 방법이기 때문에 액세스가 거부됩니다.

HTTP Referer는 외부 ALB 측에서만 구현되었기 때문에 내부 ALB에 직접 연결하는 인트라넷 사용자는 직간접적으로 URL에 액세스하는 데 아무런 문제가 발생하지 않습니다.

ALB 성능 분석 및 문제 해결

ALB 성능을 모니터링하려면 Amazon CloudWatch 콘솔의 메트릭으로 이동하여 원하는 ALB를 선택하거나, EC2 콘솔→ 로드 밸런싱→ 대상 그룹으로 이동하여 모니터링 탭에서 원하는 대상 그룹과 클럭을 선택할 수 있습니다. 자세한 내용은 다음 AWS 문서에서 확인할 수 있습니다. 아래는 인도의 피크 업무 시간 30분 동안 1500~2000건의 요청에 대해 약 150~200ms의 평균 “목표 응답 시간”을 보여주는 ALB에 대한 CloudWatch 지표의 예시입니다.

그림 13: Amazon CloudWatch ALB 성능 메트릭

이 기술 자료를 참조하여 높은 지연 시간 또는 시간 초과 문제에 대한 ALB 성능 문제를 해결할 수 있습니다. SAP EP와 관련된 문제의 범위를 좁힌 후에는 icm 로그 또는 기본 추적을 확인하여 단서를 찾으세요. 이러한 문제를 해결하려면 SAP 노트 2579836을 확인하세요.

결론

이 블로그 게시물에서는 사용 사례와 아키텍처 패턴, SAP EP 애플리케이션용 ALB의 설정 절차에 대해 자세히 살펴보았습니다. 고객들은 많은 기능과 장점을 활용하기 위해 SAP 애플리케이션에 ALB를 사용하고 있습니다. ALB는 AWS 관리형 서비스로, 기본 운영 계층이나 EC2 인스턴스를 유지 관리할 필요가 없습니다. 고가용성과 확장성이 뛰어난 서비스로 제공되어 SAP 환경을 간소화합니다.

SAP on AWS에 대한 자세한 내용은 AWS 제품 설명서에서 확인할 수 있습니다.

추가적인 전문가 안내가 필요한 경우, AWS 계정 팀에 문의하여 현지 SAP 전문 솔루션 아키텍트 또는 AWS Professional Services의 SAP 스페셜리스트를 요청해주세요.

SAP on AWS 토론에 참여하세요

고객 계정 팀과 AWS 지원 채널 외에도 re:Post – AWS에서 제공하는 Q&A 커뮤니티에서 참여할 수 있습니다. SAP 솔루션 아키텍처 팀은 고객과 파트너를 지원하기 위해 SAP on AWS 주제에 대한 토론과 질문에 대한 답변을 정기적으로 모니터링합니다. 지원과 관련된 질문이 아닌 경우, re:Post에서 토론에 참여하고 커뮤니티 지식창고에 추가하는 것을 고려해 보세요.

이 블로그는 Sumit Dey가 공동 작성했습니다.