DataPower 국내 사례와 데모

1. DataPower 국내 사례와 데모 DataPower를 활용한 SOA 기반의 ESB 벤치마킹 사례를 중심으로 한국 IBM 지용득

2. Agenda • 사례 1: A 금융사 벤치마킹 • 사례 2: A 통신사 벤치마킹 • 구현 데모 및 Q&A

3. 사례1. A 금융사 벤치마킹 배경 • SOA/Web Services 기반의 채널통합 ESB 구축 필요 • 서비스 지향 ESB 구축을 위해 개방형 표준인 Web Services 인터페이스 채택 • Bank of America, Wachovia 등 선진 SOA 사례에서는 이미 Web Services 기반의 채널통합 솔루션을 운영하며 TCO 절감 • SOA의 기반인 개방형 표준을 통한 애플리케이션의 확장성과 빠른 시장 대응능력 확보 필요 • SOA/Web Services 기반의 ESB 성능 및 안정성에 대한 고려 • Web Services 인터페이스에서 기능적/비기능적 요구 사항을 충족하고자 할 때 기존방식(소켓 위주) 대비 발생하는 다음의 추가적인 오버헤드를 최소의 노력과 비용으로 대처하는 방안 필요 • SOAP 메시지에 대한 XML 처리 시 발생하는 추가 부하: SOAP Validation, XML 데이터 자체에 대한 보안,XML Transformation, XML 내용 기반의 Routing 등 • Web Services 인터페이스의 보안(WS-Security/SSL 등) 활성화 시 발생하는 추가 부하:PKI 기반의 클라이언트(서비스 요청자)/서버(서비스 제공자) 인증,SOAP 메시지의 기밀성을 위한 암/복호화,부인방지를 위한 SOAP 메시지 전자 서명(Digital Signature) 및 확인(Verification) 등

4. 벤치마크 테스트 환경 Gigabit Network

5. 사례 1 ESB 아키텍처의 성능 목표 • 아무런 중개 Activity 없이 Back End의 Legacy 서비스를 직접 호출하는 1의 성능을 기준으로 하여 • ESB 또는 Security Gateway의 기능을 수행하는 중재 역할을 각각 SW와 Appliance로 구현 • 주어진 요건을 수행함에 있어서 2와 3의 성능과 자원 사용을 비교하고 최적화하여 1에 근접하도록 하는 것 • Offloading SOA/XML Overhead: DataPower vs. SW ESB 서비스 요청자 서비스 요청자 MCI ESB Legacy 2 1 3

6. 테스트용 SOAP 메시지 구조 *SOAP 메시지의 복잡도에 따라 XML 처리 시에 발생하는 부하가 달라질 수 있으며, 이를 회피하기 위해, 또한 XML 변환 요건이 발생하도록 유도하는 시나리오 구성을 위해 아래와 같이 SOAP의 복잡도에 차별을 두어 전문을 분류 대략적인 구조 Fine Grain Large Grain Merged

7. 벤치마킹 시나리오 1: SOAP 변환(XSLT) 및 Validation 수행 구성도 SW ESB 처리 서비스 요청자 서비스 요청자 MCI ESB Legacy • SOAP Large Grain • SOAP Fine Grain • SOAP Validation • 요청을 Merged SOAP으로 변환 수행 DataPower 처리 서비스 요청자 서비스 요청자 MCI ESB Legacy • SOAP Large Grain • SOAP Fine Grain • Offloading WS/SOA Overhead • SOAP Validation • 요청을 Merged SOAP으로 변환 수행 • XML 데이터 레벨의 방화벽 역할 수행

8. 벤치마킹 시나리오 1: SOAP 변환(XSLT) 및 Validation 수행 성능 *부하 발생기와 DataPower의 Back End ServiceWeb Server와 인터페이스 방식 차이에 의해 DataPower/Large Grain 처리가 더 높은 성능을 기록한 것으로 보임

9. 벤치마킹 시나리오 2: 시나리오 1 + WS-Security 보안 구현 구성도 SW ESB 처리 서비스 요청자 서비스 요청자 MCI ESB Legacy • 암호화된 SOAP Large Grain • 암호화된 SOAP Fine Grain • SOAP Validation • 요청을 Merged SOAP으로 변환 수행 • WS-S에 의한 SOAP 요청 전문 복호화 및 서명 Verification DataPower 처리 서비스 요청자 서비스 요청자 MCI ESB Legacy • 암호화된 SOAP Large Grain • 암호화된 SOAP Fine Grain • Offloading WS/SOA Overhead • SOAP Validation • 요청을 Merged SOAP으로 변환 수행 • XML 데이터 레벨의 방화벽 수행 • WS-S에 의한 SOAP요청 전문 복호화 및 서명 Verification

10. 벤치마킹 시나리오 2: 시나리오 1 + WS-Security 보안 구현 수행 성능 *Speaker의 구두 설명 필요

11. 시나리오 별 성능 결과 요약 및 비교

12. 사례2. A 통신사 벤치마킹 배경 • SOA/Web Services 기반의 Service Delivery Platform을 위한 환경 필요 • 다양한 파트너와의 잦은 연계를 위해개방형 표준인 Web Services 인터페이스 채택 • SOA의 근간인 개방형 표준을 통한 유연한 연결성과 Governance 환경 확보 필요 • 서비스 소스의 다변화와 동적인 추가/변경에 따른 빠른 시장 대응능력 확보 필요 • SOA/Web Services 기반의 ESB 성능, 안정성, 보안성 및 Governance에 대한 고려 • Web Services 인터페이스를 활용한 단순 Connectivity뿐 아니라 Quality of Service와 Service Level Agreement 등의 SOA Governance 정책을 부과하기 위한 ESB 또는 보안 Gateway • ESB로서의 기능과 Web Services 환경에 대한 폭넓은 지원: Web Service Gateway/Proxy 역할의 Router 기능, WSRR/UDDI와의 연계,SOAP Validation, XML Transformation 등 • SOA Governance 기반:제반 WS-Security/WS-Policy 구현과 비표준 기반의 웹 보안 기술과의 접점 제공,개발 및 운영 포탈과의 개발 인터페이스 통합 요구,Service Level Agreement 정책을 성능 저하 없이 부과,WS-Security뿐 아니라 프로토콜 레벨의 SSL 가속,

13. 벤치마크 테스트 환경

14. 사례 2 ESB 아키텍처의 성능 목표 • 아무런 중개 Activity 없이 Back End의서비스를 직접 호출하는 1의 성능을 기준으로 하여 • ESB와 Governance 하부구조 기능을 수행하는 중재 역할을 각각 SW와 Appliance로 구현 • 주어진 요건을 수행함에 있어서 2와 3의 성능과 자원 사용을 비교하고 최적화하여 1에 근접하도록 하는 것 • Offloading SOA/XML/GovernanceOverhead: DataPower vs. SW ESB 서비스 요청자 서비스 요청자 SDP ESB 백엔드 서비스 제공자 2 백엔드 서비스 제공자 1 3

15. 벤치마킹 시나리오 1: 단순 Routing & 내용 기반 Routing 수행 구성도 SW ESB 처리 서비스 요청자 서비스제공자 서비스 요청자 SW ESB 서비스제공자 • Simple SOAP 요청 • Backend Service를 단순 호출하는 정적 Routing • SOAP 전문의 내용에 따라 Path를 변경하는 동적 Routing DataPower 처리 서비스 요청자 서비스제공자 서비스 요청자 서비스제공자 • Simple SOAP 요청 • Backend Service를 단순 호출하는 정적 Routing • SOAP 전문의 내용에 따라 Path를 변경하는 동적 Routing

16. 벤치마킹 시나리오 1: 단순 Routing & 내용 기반 Routing 수행 성능 *부하 발생기와 DataPower의 Back End ServiceWeb Server와 인터페이스 방식 차이에 의해 DataPower/Large Grain 처리가 더 높은 성능을 기록한 것으로 보임

17. 벤치마킹 시나리오 2: SOAP/XML 변환벤치마킹 시나리오 3: 사용자 인증, Security Token 변환수행 구성도 SW ESB 처리 서비스 요청자 서비스제공자 서비스 요청자 SW ESB 서비스제공자 • Simple SOAP 요청 • 서비스 제공자로부터 돌아온 응답 SOAP 전문을 XSLT를 통해 정해진 형태로 변환 DataPower 처리 서비스 요청자 서비스제공자 서비스 요청자 서비스제공자 • Simple SOAP 요청 • 서비스 제공자로부터 돌아온 응답 SOAP 전문을 XSLT를 통해 정해진 형태로 변환 • Web Service 보안을 위해 HTTP Basic 인증 방식으로 사용자 인증 후 이를 통해 Web Service의 특정 Operation에 권한을 부여, WS-Security의 Security Token으로 맵핑

18. 벤치마킹 시나리오 2 & 3: 수행 성능 *Speaker의 구두 설명 필요

19. 벤치마킹 시나리오 4: Service Level Agreement 아래 예처럼 60초에 특정 Operation이 10번 넘게 호출되면 이후의 요청은 DataPower가 차단하고 Client는 이에 관한 SOAP Fault를 받음. 이러한 이벤트를 관리자는 로그 정보나 시각적 모니터링을 통해 확인할 수 있으며 궁극적으로 서비스 제공자는 SLA에서 규정한 수준을 넘어서는 요청으로부터 안전하게 보호받게 되며 DataPower는 이 작업을 성능 감소 없이 수행함. Client는 SOAP Fault 수신 보호받음 DataPower SOA Appliance XI50 서비스 요청자 서비스제공자 Service Level Agreement 정책 부과: 60초에 test1 Operation이 10번 넘게 호출되는 경우 이를 차단하는 등의 주어진 조치를 자동으로 취함 모니터링

20. Q&A 구현 데모