SAP 데이터 추출을 위한 성능 및 문제 해결

이 문서는 "SAP 데이터 확장 및 혁신: 모범 사례" 문서 시리즈의 일부입니다.

• SAP 데이터 원본 식별
• 최상의 SAP 커넥터 선택
• SAP 데이터 추출을 위한 성능 및 문제 해결
• Azure의 SAP에 대한 데이터 통합 보안
• SAP 데이터 통합 일반 아키텍처

데이터 통합을 위해 SAP 시스템에 연결하는 방법에는 여러 가지가 있습니다. 아래 섹션에서는 일반 및 커넥터 관련 고려 사항 및 권장 사항에 대해 설명합니다.

성능

데이터 추출 및 처리 중에 최상의 성능을 얻을 수 있도록 원본 및 대상에 대한 최적의 설정을 구성하는 것이 중요합니다.

일반적인 고려 사항

• 최대 동시 연결에 대해 올바른 SAP 매개 변수가 설정되어 있는지 확인합니다.
• 성능 및 부하 분산을 향상시키려면 SAP 그룹 로그온 유형을 사용하는 것이 좋습니다.
• SHIR(자체 호스팅 통합 런타임) 가상 머신의 크기가 적절하게 조정되고 고가용성인지 확인합니다.
• 대용량 데이터 세트로 작업할 때 사용 중인 커넥터가 분할 기능을 제공하는지 검사. 대부분의 SAP 커넥터는 데이터 로드 속도를 높이기 위해 분할 및 병렬화 기능을 지원합니다. 이 메서드를 사용하면 여러 병렬 프로세스를 사용하여 로드할 수 있는 작은 청크로 데이터가 패키지됩니다. 자세한 내용은 커넥터 관련 설명서를 참조하세요.

일반 권장 사항

• SAP 트랜잭션 RZ12를 사용하여 최대 동시 연결에 대한 값을 수정합니다.

  RFC에 대한 SAP 매개 변수 - RZ12: 다음 매개 변수는 한 사용자 또는 한 애플리케이션에 허용되는 RFC 호출 수를 제한할 수 있으므로 이 제한으로 인해 병목 현상이 발생하지 않도록 합니다.

  

  

• 로그온 그룹을 사용하여 SAP에 연결: SHIR(자체 호스팅 통합 런타임)은 사용 가능한 모든 애플리케이션 서버에서 워크로드 배포를 보장하기 위해 특정 애플리케이션 서버가 아닌 SAP 로그온 그룹을 사용하여 SAP에 연결해야 합니다.

  참고

  데이터 흐름 Spark 클러스터 및 SHIR은 강력합니다. 많은 내부 SAP 복사 작업(예: 16)을 트리거하고 실행할 수 있습니다. 그러나 SAP 서버의 동시 연결 번호가 작은 경우(예: 8) 성능은 SAP 쪽에서 데이터를 읽습니다.

• SHIR용 4vCPU 및 16GB VM으로 시작합니다. 다음 단계에서는 SHIR을 사용하여 SAP에서 대화 상자 작업 프로세스의 연결을 보여줍니다.

  1. 고객이 불량한 물리적 컴퓨터를 사용하여 SHIR을 설정하고 설치하여 내부 SAP 복사본을 실행하는지 확인합니다.
  2. Azure Data Factory 포털로 이동하여 데이터 흐름에 사용되는 관련 SAP CDC 연결된 서비스를 찾습니다. 참조된 SHIR 이름을 확인합니다.
  3. SHIR이 설치된 물리적 컴퓨터의 CPU, 메모리, 네트워크 및 디스크 설정을 확인합니다.
  4. SHIR 컴퓨터에서 실행 중인 개수를 diawp.exe 확인합니다. 하나의 diawp.exe 복사 작업을 실행할 수 있습니다. 의 수는 diawp.exe 컴퓨터의 CPU, 메모리, 네트워크 및 디스크 설정을 기반으로 합니다.

  

• SHIR에서 동시에 여러 파티션을 병렬로 실행하려면 강력한 가상 머신을 사용하여 SHIR을 설정합니다. 또는 SHIR 고가용성 및 확장성 기능을 사용하여 스케일 아웃을 사용하여 여러 노드를 갖습니다. 자세한 내용은 고가용성 및 확장성을 참조하세요.

파티션

다음 섹션에서는 SAP CDC 커넥터의 분할 프로세스에 대해 설명합니다. 이 프로세스는 SAP 테이블 및 SAP BW Open Hub 커넥터에 대해 동일합니다.

성능 요구 사항에 따라 자체 호스팅 IR 또는 Azure IR에서 크기 조정을 수행할 수 있습니다. 크기 조정 방법을 결정하는 데 도움이 되는 메트릭을 보려면 SHIR의 CPU 사용량을 검토합니다. SHIR은 필요에 따라 수직 또는 수평으로 스케일링할 수 있습니다. 더 낮은 SKU에서 Azure IR을 배포하는 것이 좋습니다. 더 높은 쪽에서 불필요하게 시작하는 대신 부하 테스트를 통해 결정된 성능 요구 사항을 충족하도록 스케일 업합니다.

분할은 초기 또는 대규모 전체 로드에 유용하며 일반적으로 델타 로드에는 필요하지 않습니다. 파티션을 지정하지 않으면 기본적으로 SAP 시스템의 1개 "생산자"(일반적으로 하나의 일괄 처리 프로세스)가 원본 데이터를 ODQ(운영 데이터 큐)로 가져오고 SHIR은 ODQ에서 데이터를 가져옵니다. 기본적으로 SHIR은 4개의 스레드를 사용하여 ODQ에서 데이터를 가져오므로 현재 SAP에서 잠재적으로 4개의 대화 프로세스가 사용됩니다.

분할의 개념은 큰 초기 데이터 세트를 크기가 같고 병렬로 처리할 수 있는 여러 개의 더 작은 연결되지 않은 하위 집합으로 분할하는 것입니다. 이 메서드는 선형 방식으로 원본 테이블에서 ODQ로 데이터를 생성하는 데 걸리는 시간을 줄입니다. 이 메서드는 SAP 쪽에 부하를 처리하기에 충분한 리소스가 있다고 가정합니다.

CDC를 사용하여 파이프라인을 실행할 때의 디자인 고려 사항

• SAP에서 스테이징 기간을 확인합니다.

• 싱크에서 런타임 성능을 확인합니다.

• 더 나은 처리량을 위해 분할 기능을 사용하여 성능을 향상시키는 것이 좋습니다.

• SAP-스테이지 기간이 느린 경우 SHIR 크기를 더 높은 사양으로 조정하는 것이 좋습니다.

  

• 싱크 처리 시간이 너무 느린지 확인합니다.

  

  작은 클러스터를 사용하여 매핑 데이터 흐름을 실행하는 경우 싱크의 성능에 영향을 줄 수 있습니다. 성능이 단계에서 데이터를 읽고 싱크에 쓰도록 큰 클러스터(예: 16+ 256코어)를 사용합니다.

• 대규모 데이터 볼륨의 경우 부하를 분할하여 병렬 작업을 실행하는 것이 좋지만 파티션 수를 Spark 클러스터 코어라고도 하는 Azure IR 코어보다 작거나 같게 유지하는 것이 좋습니다.

  최적화 탭을 사용하여 파티션을 정의합니다. CDC 커넥터에서 원본 분할을 사용할 수 있습니다.

  

  참고

  • SHIR 코어를 사용하는 파티션 수와 Azure IR 노드 간에는 직접적인 상관 관계가 있습니다.
  • SAP CDC 커넥터는 SAP 시스템의 ODQMON 아래에 Odata 구독자 유형 "운영 데이터 프로비저닝에 대한 Odata 액세스"로 나열됩니다.

테이블 커넥터를 사용할 때 디자인 고려 사항

• 더 나은 성능을 위해 분할을 최적화합니다.
• SAP 테이블의 병렬 처리 수준을 고려합니다.
• 대상 싱크에 대한 단일 파일 디자인을 고려합니다.
• 대용량 데이터 볼륨을 사용하는 경우 처리량을 벤치마킹합니다.

Table 커넥터를 사용할 때 권장 사항 디자인

• 파티션: SAP Table 커넥터에서 분할하는 경우 절이 적절한 필드에 있는 경우(예: 카디널리티가 높은 필드)를 사용하여 하나의 기본 select 문을 여러 문으로 분할합니다. SAP 테이블에 대량의 데이터가 있는 경우 분할을 사용하도록 설정하여 데이터를 더 작은 파티션으로 분할합니다. 파티션이 SAP의 메모리 덤프를 방지할 수 있을 만큼 작지만 추출 속도를 높일 수 있을 만큼 충분히 커지도록 파티션 수(매개 변수 maxPartitionsNumber)를 최적화해 보세요.

• 병렬 처리: 복사 병렬 처리 수준(매개 변수 parallelCopies)은 분할과 함께 작동하며 SHIR에 SAP 시스템에 대한 병렬 RFC 호출을 수행하도록 지시합니다. 예를 들어 이 매개 변수를 4로 설정하면 서비스는 지정된 파티션 옵션 및 설정에 따라 4개의 쿼리를 동시에 생성하고 실행합니다. 각 쿼리는 SAP 테이블에서 데이터의 일부를 검색합니다.

  최적의 결과를 위해 파티션 수는 복사 병렬 처리 정도의 배수여야 합니다.

  SAP 테이블에서 이진 싱크로 데이터를 복사하면 SHIR에서 사용할 수 있는 메모리 양에 따라 실제 병렬 수가 자동으로 조정됩니다. 각 테스트 주기의 SHIR VM 크기, 복사 병렬 처리 수준 및 파티션 수를 기록합니다. SHIR VM의 성능, 원본 SAP 시스템의 성능 및 원하는 수준과 실제 병렬 처리 수준을 관찰합니다. 반복 프로세스를 사용하여 SHIR VM에 대한 최적의 설정과 이상적인 크기를 식별합니다. 하나 또는 여러 SAP 시스템에서 동시에 데이터를 로드하는 모든 수집 파이프라인을 고려합니다.

  구성된 병렬 처리 정도에 대해 SAP에 대해 관찰된 RFC 호출 수를 확인합니다. SAP에 대한 RFC 호출 수가 병렬 처리 수준보다 작은 경우 SHIR VM에 사용 가능한 메모리 및 CPU 리소스가 충분한지 확인합니다. 필요한 경우 더 큰 가상 머신을 선택합니다. 원본 SAP 시스템은 병렬 연결 수를 제한하도록 구성됩니다. 자세한 내용은 이 문서의 일반 권장 사항 섹션을 참조하세요.

• 파일 수: 데이터를 파일 기반 데이터 저장소에 복사하고 대상 싱크가 폴더로 구성된 경우 기본적으로 여러 파일이 생성됩니다. 싱크에서 fileName 속성을 설정하면 데이터가 단일 파일에 기록됩니다. 단일 파일에 쓰는 데 비해 쓰기 처리량이 더 높기 때문에 폴더에 여러 파일로 쓰는 것이 좋습니다.

• 성능 벤치마크: 성능 벤치마킹 연습을 사용하여 많은 양의 데이터를 수집하는 것이 좋습니다. 이 메서드는 분할, 병렬 처리 수준 및 지정된 아키텍처, 볼륨 및 데이터 형식에 대한 최적의 설정을 결정하는 파일 수와 같은 매개 변수에 따라 다릅니다. 테스트의 데이터를 다음 형식으로 수집합니다.

  

문제 해결

• SAP 시스템에서 느리거나 실패한 추출의 경우 SM37의 SAP 로그를 사용하여 Data Factory의 판독값과 일치합니다.

• 하나의 일괄 처리 작업만 트리거되는 경우 DATA Factory의 매핑 데이터 흐름에서 성능이 향상되도록 SAP 원본 파티션을 설정합니다. 자세한 내용은 맵 데이터 흐름 속성의 6단계를 참조하세요.

• SAP 시스템에서 여러 일괄 처리 작업이 트리거되고 각 일괄 처리 작업의 시작 시간 사이에 상당한 차이가 있는 경우 Azure IR의 크기를 변경합니다. Azure IR에서 드라이버 노드 수를 늘리면 SAP 쪽에서 일괄 처리 작업의 병렬 처리가 증가합니다.

  참고

  Azure IR의 최대 드라이버 노드 수는 16개입니다. 각 드라이버 노드는 하나의 일괄 처리 프로세스만 트리거할 수 있습니다.

• SHIR에서 로그를 확인합니다. 로그를 보려면 SHIR VM으로 이동합니다. 이벤트 뷰어 > 애플리케이션 및 서비스 로그 > 커넥터 통합 런타임을 > 엽니다.

• 지원 로그를 보내려면 SHIR VM으로 이동합니다. Integration Runtime 구성 관리자 > 진단 > 보내기 로그를 엽니다. 이 작업은 지난 7일 동안의 로그를 보내고 보고서 ID를 제공합니다. 이 보고서 ID와 실행의 RunId가 필요합니다. 이후 참조를 위해 보고서 ID를 문서화합니다.

• SLT 시나리오에서 SAP CDC 커넥터를 사용하는 경우:

  • 필수 구성 요소가 충족되는지 확인합니다. SAP SLT(가로 변환) 사용자(예: OLTP 시스템의 ADFSLTUSER 또는 SLT 복제가 작동하려면 ECC)에 역할이 필요합니다. 자세한 내용은 필요한 권한 부여 및 역할을 참조하세요.

  • SLT 시나리오에서 오류가 발생하는 경우 분석 권장 사항을 참조하세요. 먼저 SAP 솔루션 내에서 시나리오를 격리하고 테스트합니다. 예를 들어 SE38에서 SAP RODPS_REPL_TEST 에서 제공하는 테스트 프로그램을 실행하여 Data Factory 외부에서 테스트합니다. SAP 쪽에 문제가 있는 경우 보고서를 사용할 때 동일한 오류가 발생합니다. 트랜잭션 코드를 ODQMON사용하여 SAP에서 데이터 추출을 분석할 수 있습니다.

    이 테스트 보고서를 사용할 때 복제가 작동하지만 Data Factory에서는 작동하지 않는 경우 Azure 또는 Data Factory 지원에 문의하세요.

    다음 예제에서는 SE38의 에 대한 RODPS_REPL_TEST 보고서를 보여줍니다.

    

    

    

    다음 예제에서는 트랜잭션 코드를 ODQMON보여줍니다.

    

  • Data Factory 연결된 서비스가 SLT 시스템에 연결되면 컨텍스트 필드를 새로 고칠 때 SLT 대량 전송 ID가 표시되지 않습니다.

    

  • SAP LT 복제 서버에 대한 ODP/ODQ 복제 시나리오를 실행하려면 다음 BAdI(비즈니스 추가 기능) 구현을 활성화합니다.

    Badi: BADI_ODQ_QUEUE_MODEL

    향상된 구현: ODQ_ENH_SLT_REPLICATION

    1. 트랜잭션 LTRC에서 전문가 함수 탭으로 이동하여 BAdI 구현 활성화/비활성화 를 선택하여 구현을 활성화합니다.

       

    2. 예를 선택합니다.

       

    3. ODQ/ODP 특정 함수 폴더에서 BAdI 구현이 활성인지 여부를 선택합니다.

       

       대화 상자에 프로그램 활동이 표시됩니다.

       

• 구독을 다시 설정합니다. 새 추출로 시작하거나 복제 데이터를 중지하려면 ODQMON에서 구독을 제거합니다. 또한 이 작업은 LTRC에서 항목을 제거합니다. 구독을 다시 설정하면 LTRC에서 효과가 표시되기까지 몇 분 정도 걸릴 수 있습니다. ODP(운영 데이터 프로비저닝) 하우스키핑 작업을 예약하여 델타 큐를 클린 유지합니다( 예:ODQ_CLEANUP_CLIENT_004

• CDS_VIEW(DHCDCMON 트랜잭션). S/4HANA 1909부터 SAP는 날짜 열 대신 데이터 기반 트리거를 사용하는 CDS 뷰에서 데이터를 복제합니다. 개념은 SLT와 비슷하지만 LTRC 트랜잭션을 사용하여 모니터링하는 대신 DHCDCMON 트랜잭션을 사용합니다.

SLT 문제 해결

SLT 복제 서버는 SAP 원본 및/또는 비 SAP 원본에서 SAP 대상 및/또는 비 SAP 대상으로 실시간 데이터 복제를 제공합니다. SLT에서 Azure로의 추출을 모니터링하는 세 가지 유형의 도구 집합이 있습니다.

• ODQMON 은 데이터 추출을 위한 전체 모니터링 도구입니다. ODQMON을 사용하여 분석을 시작하여 데이터 불일치, 초기 성능 분석 및 열린 구독 및 추출 요청을 추적합니다.
• LTRC는 성능 분석을 검사 데 사용할 트랜잭션입니다. 데이터 흐름을 모니터링하고 불일치를 찾을 수 있으므로 원본 시스템에서 ODP로의 데이터 복제 문제가 있는 경우 유용합니다.
• SM37 은 각 SLT 추출 단계에 대한 자세한 모니터링을 제공합니다.

일반 하우스키핑은 구독을 직접 관리할 수 있는 ODQMON을 사용하여 수행해야 하며 LTRC를 동일하게 사용하면 안 됩니다.

SLT에서 데이터를 추출할 때 다음과 같은 문제가 발생할 수 있습니다.

• 추출이 실행되지 않습니다. SAP CDC 연결이 ODQMON에서 연결을 만들었는지 확인하고 구독이 있는지 검사.

• 데이터 불일치. ODQMON을 확인하여 데이터의 개별 요청을 확인하고 해당 데이터에서 데이터를 볼 수 있는지 확인합니다. ODQMON에서 데이터를 볼 수 있지만 Azure Synapse 또는 Data Factory에서는 볼 수 없는 경우 Azure 쪽에서 조사가 수행되어야 합니다. ODQMON에서 데이터를 볼 수 없는 경우 LTRC를 사용하여 SLT 프레임워크 분석을 수행합니다.

• 성능 문제. 데이터 추출은 2단계 방법입니다. 먼저 SLT는 원본 시스템에서 데이터를 읽고 ODP로 전송합니다. 둘째, SAP CDC 커넥터는 ODP에서 데이터를 선택하고 선택한 데이터 저장소로 전송합니다. LTRC 트랜잭션을 사용하면 추출 프로세스의 첫 번째 부분을 분석할 수 있습니다. ODP에서 Azure로의 데이터 추출을 분석하려면 ODQMON 및 Data Factory 또는 Synapse 모니터링 도구를 사용합니다.

  참고

  이러한 응용 프로그램은 Azure AD Graph API를 사용할 수 있습니다. 자세한 내용은 다음 리소스를 참조하세요.

  • SAP CDC 커넥터 및 SLT - 1부 - 개요 및 아키텍처
  • SAP CDC 커넥터 및 SLT - 2부 - 초기 구성

SLT 성능

초기 로드 모드(ODPSLT)에는 SLT에서 ODP로 데이터를 추출하는 세 가지 단계가 있습니다.

1. 마이그레이션 개체를 만듭니다. 이 프로세스는 몇 초밖에 걸리지 않습니다.
2. 원본 테이블을 더 작은 청크로 분할하는 계획 계산에 액세스합니다. 이 단계는 SLT 구성 중에 선택한 초기 부하 모드와 테이블 크기에 따라 달라집니다. 리소스 최적화 옵션을 사용하는 것이 좋습니다.
3. 데이터 로드는 원본 시스템에서 ODP로 데이터를 전송합니다.

• 각 단계는 백그라운드 작업에 의해 제어됩니다. SM37 및 LTRC 트랜잭션을 사용하여 기간을 모니터링할 수 있습니다. 시스템이 과도하게 사용되면 무료 일괄 처리 작업 프로세스가 충분하지 않기 때문에 백그라운드 작업이 나중에 시작될 수 있습니다. 작업이 유휴 상태이면 성능이 저하됩니다.

• 액세스 계획 계산에 시간이 오래 걸리고 초기 부하 모드가 "성능 최적화됨"으로 설정된 경우 이를 "리소스 최적화"로 변경하고 추출을 다시 실행합니다. 데이터 로드에 시간이 오래 걸리는 경우 구성에서 병렬 스레드 수를 늘립니다.

• SLT 복제(전용 SLT 복제 서버)에 독립 실행형 아키텍처를 사용하는 경우 원본 시스템과 복제 서버 간의 네트워크 처리량이 추출 성능에 영향을 줄 수 있습니다.

• 복제의 경우:

  • 초기 로드를 위해 예약되지 않은 충분한 데이터 전송 작업이 있는지 확인합니다.
  • 부하 통계에 처리되지 않은 로깅 테이블 레코드가 없는지 확인합니다.
  • 복제 옵션이 실시간으로 설정되어 있는지 확인합니다.

• 고급 복제 설정은 LTRS에서 사용할 수 있습니다. 자세한 내용은 SLT 문제 해결 가이드를 참조하세요.

• SAP 릴리스에 따라 LTRC 사용자 인터페이스가 다릅니다. 다음 스크린샷은 두 개의 서로 다른 릴리스에 대해 동일한 페이지를 보여 줍니다.

  SAP S/4HANA:

  

  SAP ECC:

  

Monitor

SAP 데이터 추출 모니터링에 대한 자세한 내용은 다음 리소스를 참조하세요.

• Data Factory 시각적 모니터링
• 델타 큐 모니터링

다음 단계

• SAP 데이터 통합 보안