K은행의 개발 언어와 플랫폼을 선정하기 위한 벤치마크 테스트 과정 소개
COBOL은 객체지향 세계에서 존재하는 하나의 절차적(Procedural) 언어이다. 배치 애플리케이션에 적합하고 핵심 비즈니스 요건을 손쉽게 구현하기에는 적합하나 사용자와 상호작용이 필요한 웹 애플리케이션에는 그 지위를 잃어 왔다. 현 시대의 많은 Java, C# 프로그래머들에게 COBOL은 곧 사라질 하위의 언어라는 인식이 광범위하게 존재한다.
그렇다면 Java는 어떠한가? Java는 객체지향 언어로 웹 시스템의 중심으로 자리를 잡았으며, 시스템 독립성과 이식성 면에서 시스템 전환 시 컴파일이 필요한 타 언어와 비교해 보았을 때 개방성에서 그 우위를 지니고 있으며 대학에서 배출되는 개발자들도 풍부하다. 미래 전망에 있어서도 Java가 COBOL 보다는 우위에 있는 것은 사실이다. 하지만 문제는 여전히 Java가 대규모 시스템의 핵심 요건들을 모두 충족하기에는 어렵다는 데 있다.
우선 가장 큰 문제는 Java의 상당한 CPU 사용량으로 인한 복잡한 비즈니스 로직 및 배치 애플리케이션의 처리 성능 저하에 있다. 현재 운용되는 은행이나 보험사, 또는 기타 금융권 시스템을 분석해 보면 DBMS 데이터를 처리하기 위한 SQL 횟수가 100회를 초과할 정도로 복잡한 트랜잭션을 손쉽게 볼 수 있다. 이런 트랜잭션을 COBOL이나 C로 구현하다가 Java로 구현해 보면 그 성능 차이는 쉽게 드러난다. 그리고 배치 애플리케이션의 처리 속도는 그 차이가 더욱 분명해 진다. 복잡한 업무의 빠른 응답시간이 비즈니스 요건이라면 Java는 손쉽게 선택할 수 있는 대안이 아니다. 특히 웹 애플리케이션 서버, 멀티채널 서버 등 아키텍처가 복잡해지는 최근의 아키텍처를 보았을 때 핵심 업무의 응답시간은 시스템의 품질을 좌우하는 중요한 요소일 수밖에 없다.
Java는 생각보다 관리하기 용이한 언어가 아니라는 것도 문제이다. JDK의 버전의 상이함, J2EE 서버의 상이함, Information Hiding이라는 객체지향 자체의 특징 때문에 엄격한 애플리케이션 아키텍처 표준이 존재하지 않는다면 일반 구조적인 언어보다 Java의 관리 복잡성이 대폭 증가한다.
또한 Java가 자랑하는 플랫폼 독립성 또한 일반적으로 생각되는 것보다 현실에서는 그리 높지 않다. JDK 수준에서는 상호 호환성을 보장하지만 그보다 상위 수준인 J2EE 서버들에는 개별 제조사들이 심어 놓은 독특한 속성과 메소드들이 존재하며 시장의 솔루션들 또한 JNI 구현이나 J2EE 서버 의존성 때문에 상호 이식성이 떨어지는 것이 현실이다.
위와 같은 Java의 한계 때문에 차세대 프로젝트에서 개발 표준을 Java와 J2EE로 정의하면서도 핵심 비즈니스 애플리케이션과 배치 애플리케이션은 TP Monitor 기반의 COBOL이나 C로 구현하는 것이 아직까지 일반적인 구현 방식이며 몇몇 회사들이 Java로 구현하기 위해 노력하지만 현재의 하드웨어 성능과 Java 아키텍처로는 비즈니스 요건을 하향 조정해야 하는 중대한 문제가 발생하고 있다.
Java가 이러한 문제를 안고 있다면 차세대를 구현함에 있어서 복잡한 핵심 업무나 배치는 어떤 언어로 구현해야 하는가? 이러한 고민으로 인해 한국에서는 COBOL과 C, 두 언어가 대표적으로 사용되고 있으며 이 두 언어를 차세대를 추진하는 회사의 기술 보유 현황에 맞게 선택해야 하는 상황에 직면하게 된다.
COBOL과 C에 대한 가트너 그룹의 평가를 살펴보면 COBOL이 시장에서의 안정적인 지원을 받고 있다는 'Mature' 상태로 평가 받은 반면 C는 'Aging'으로 평가를 받아서 틈새시장에서 존재 의의를 찾을 것이라는 냉정한 평가를 받았다.
위의 평가를 볼 때 플랫폼에 관계없이 COBOL이나 C를 핵심 애플리케이션으로 모두 사용할 수 있다. C나 COBOL이 단기간 내에 사라질 언어는 아니기 때문이다. 유닉스 시스템에서 COBOL로 핵심 시스템을 구현한 사례는 국내에서도 다수 존재하며 메인프레임에서 C도 국내에서 많이 활용되고 있고 중국의 대규모 은행 중 한 곳은 메인프레임에서 C가 주 비즈니스 언어로 사용하고 있는 것이 현실이다.
국내 차세대 프로젝트의 가장 큰 문제는 현재의 핵심 비즈니스에서 사용되고 있는 COBOL이나 C를 냉정한 평가 없이 다른 언어로 전환하는 것이다. 차세대 프로젝트에서 화면 처리나 외부 연계 로직, 멀티채널 아키텍처 등은 Java와 J2EE 기반을 활용하되 핵심 비즈니스 로직은 COBOL이나 C로 되어 있는 복잡한 로직을 정제하고 재사용하는 것이 비즈니스 요건을 시스템이 수용하는데 가장 적합한 아키텍처가 될 것이다.
물론 Java와 J2EE도 핵심 업무 아키텍처로 선택할 수 있다. 하지만 시스템 규모가 크면 클수록 그에 따른 추가적인 비용과 시스템 관리 인력 그리고 비즈니스 리스크를 감수해야만 한다.
K은행의 차세대 계정계 시스템 재구축 IT 인프라 요건
K은행의 5대 핵심 역량 강화 목표 중 하나인 '유연하고 안정적인 시스템'은 글로벌 시장 환경에서 K-은행의 경쟁 우위를 위한 IT의 목표라고 할 수 있는데 다음과 같이 세분화하여 볼 수 있다.
⁍ 글로벌 영업 환경 지원
⁍ 금융 환경 변화에 대비한 기반 구축
⁍ 무중단 시스템 구축을 위한 비즈니스 연속성 보장
⁍ 배치 작업의 최소화 및 통합 모니터링 기능 강화
⁍ 비용 효과적인 유연한 IT 인프라 구축
위와 같은 목표를 달성하기 위한 최적의 컴퓨터 플랫폼을 선정한다는 것은 매우 어려운 작업일 뿐만 아니라 기존의 표준화 된 절차를 가지고 서로 다른 컴퓨터를 비교한다는 것 자체가 많은 오류를 내포할 수밖에 없는 위험성을 지니고 있는 것이다.
컴퓨터 공급자뿐만 아니라 고객의 관점에서도 많은 시간과 비용을 투자할 수밖에 없는 것이지만, 향후에 사용될 적용 업무를 이용한 벤치마크 테스트는 이러한 경우에 정확한 판단을 위하여 사용되고 있는 방법중의 하나이다.
K은행은 최적의 플랫폼 선정을 위하여 수신, 여신, 인터넷 뱅킹, CD, 투신, 전자 은행 업무 프로그램을 신규 개발하여 실환경과 유사하게 운영하면서 처리성능, 가용성, 안정성, 유연성, 효율성, 확장성 및 보안성 등 약 50여개 세부 항목에 대한 벤치마크 테스트 기준을 제시 하였다. 이는 통상적인 벤치마크 테스트에서 이루어지는 10여개 미만의 세부 항목에 비교하여 볼 때 매우 예외적인 대규모 벤치마크 테스트가 이루어진 계기이기도 하였다.
벤치마크 테스트 평가 항목
벤치마크에 대한 일반적인 정의는 어떤 것을 측정할 때 참조하는 점(点)을 말한다. 측량술에서의 벤치마크는 이미 알려진 높이 위에 세워진 푯말이나 영구적인 표시를 말하는데, 이것은 다른 지형의 고도를 측정하는 기준으로 사용되기도 하며 수준점이라고도 한다. 그러나 컴퓨터나 인터넷 기술과 관련하여 어떤 제품이나 시스템에 대해 측정되고 비교되는 모든 종합 상황을 벤치마크라고 할 수 있다.
K은행 계정계 시스템 재구축 프로젝트의 IT 플랫폼을 선정하기 위하여 진행 되었던 벤치마크 테스트에서 제시된 평가 항목은 어떠한 것이었는가?
처리성능
목표 성능 테스트
최대 성능 테스트
온라인 / 센터컷 병행 테스트
동시 배치 테스트
대량 배치 테스트
시스템 구간별 응답 시간
가용성
Node (DB서버) Fail-Over
Node (DB서버) Fail-Back
DBMS Failover
DBMS Failback
시스템 내부 네트웍 Fail-Over
Disk Failover
메모리 보호 기술
문제 해결
Query 제어능력
안정성
장시간 부하 시 안정성 (25시간)
시스템 과부 상황하에서의 안정성(100%이상)- (8시간)
특정 테이블 Lock발생 시 타 업무 지속성 확인
데이터 정합성
데이터 정합성을 고려한 DB Recovery 기능
유연성
CPU 동적 확장 테스트
업무 운영 중 Disk추가
노드/시스템 동적 확장성
파티션 구성 추가
파티션간 독립성
자원의 자동 재분배
업무 운영 중 OS Upgrade
업무 운영 중 TP Monitor Upgrade
업무 운영 중 DBMS Upgrade
업무 운영 중 프로그램 모듈 동적 변경
온라인 Reorganization 및 소요시간
온라인 데이터베이스 변경
무정지 시스템 작업
효율성
업무 개발의 용이성과 신속성
실시간 성능 모니터링
시스템 및 어플리케이션 헬스 모니터링
시스템 사용 내역 로깅
운용의 편리성
통합콘솔 운영, 워크로드 관리기능 (AP)
성능 정보 제공 여부
확장성
CPU 동적 확장 (수직적 확장)
노드/시스템 동적 확장 (수평적 확장)
노드/시스템 증설 시 동적 Workload 분산
벤치마크 테스트의 의의
일반적으로 벤치마크 테스트의 의미는 요청하는 고객의 입장에 따라서 큰 차이를 보여준다.
태스크포스 팀을 구성하여 벤치마크 테스트 평가 항목의 개발, 적용 업무의 개발 및 테스트 데이터의 생성 등 몇 달에 걸쳐서 준비를 하고 벤더와 함께 테스트를 수행 한 뒤에 그 결과를 평가하는 것이다. 반면에 벤치마크 테스트를 요청하면서도 준비를 소홀히 하고 테스트 도중에 수시로 요건이 변경되는 경우도 있다. 이런 테스트들 중에는 결과를 냉정하게 평가하고 반영하기 보다는 하나의 요식 행위로 치러지는 경우가 종종 있다.
벤치마크테스트는 사용자 및 벤더 모두 많은 시간과 비용을 투자해야 하는 고통스러운 작업이라고 할 수 있으므로 철저한 사전 준비를 통한 최적의 결과가 도출될 수 있도록 할 때 그 의미를 찾을 수 있을 것이다. 이러한 의미에서 볼 때 K은행에서 이루어진 벤치마크 테스트는 '원칙에 가장 충실하였던 벤치마크 테스트'라고 할 수 있을 것이다.
IBM System z10 이란?
1964년 4월 7일 발표한 S/360 메인프레임은 계속적인 진화와 기술 혁신을 거쳐 2000년 10월에 최초로 발표한 IBM System zSeries(z900 모델)의 근간이 되었다. 'z'는 'Zero Defect'의 첫 자로 시장에서 요구되고 있는 24x365 운영을 위한 무결점 시스템이라는 의미를 내포하고 있다.
이후 2003년 System z990 모델, 2005년 System z9 EC(Enterprise Class) 및 2008년 2월 System z10 EC(Enterprise Class) 모델이 기술 혁신을 통해 다양한 가치를 부가하여 시장에 출시되었으며, 엔터프라이즈급 모델과 별도로 미드레인지 모델이 2002년 System z800, 2004년 System z890, 2006년 System z9 BC(Business Class) 및 2008년 10월 System z10 BC(Business Class)가 출시되었다.
이러한 내력은 IBM System z가 중소형 처리 업무에서부터 대용량 처리 업무를 아우를 수 있는 제품 라인을 구축하고 있다는 것을 의미하며, 결코 대용량 처리 환경에서만 System z가 사용되지 않고 있다는 것을 반증하여 주는 것이기도 하다.
K은행 차세대 계정계 시스템 플랫폼으로 선정된 IBM System z10 EC는 업계 최고 수준의 가용성, 확장성, 유연성, 보안성 및 서비스의 용이성을 제공할 뿐만 아니라 자바 및 리눅스 등 개방형 워크로드를 위한 성능을 획기적으로 향상시켰다.
System z10 EC는 단순한 진화를 뛰어 넘는 혁신적인 개념을 도입하여 I/O 집중적인 업무 처리만이 아니라 CPU 집중적인 업무 처리를 위하여 엔터프라이즈급에서 최초로 쿼드 코어 4.4GHz IBM System z10 프로세서 칩을 사용하였다. 성능 면에서 System z10은 기존 System z9와 비교할 때 단위 CPU 기준으로 최고 50%, CPU 의존적인 업무의 경우 100%까지 빠르며 총 용량 측면에서 최대 70%까지 확장될 수 있다.
System z10은 운영체제인 z/OS와 연동하여 추가 용량이 언제, 얼마나 필요한지를 예측하여 자동적으로 공급하는 '용량 자원의 적시 배포(Just In Time Deployment of Capacity Resources)' 기능을 제공하여 인터넷 등을 통한 '불특정 다수의 사용자 환경' 즉, 예측하지 못한 '최고의 부하(Peak Workload)'에도 안정적인 서비스를 제공할 수 있는 유일한 플랫폼이다.
한마디로 "The Future Running On System z" 즉 미래를 좌우하는 System z10이라고 할 수 있다.
Same Terminology, Different Meaning
흔히 가용성을 논할 때 누구나 'Five Nine' 즉 연간 99.999%라는 수치를 말한다. 99.999%의 가용성이란 1년 365일중 99.999%의 시간 동안 운용이 계속될 수 있다는 것을 의미하며 실제 시간으로 계산하면 1년간 허락되는 다운타임이 5분 15초 정도가 된다.
다운타임을 연간 5분정도로 억제하기 위해서는 대단한 운용 관리 체제가 필수적이며 하드웨어 및 소프트웨어 관한 통합적인 품질 관리 체제가 갖춰져야 한다. 이 때문에 IBM도 메인프레임 단독으로 99.999%의 가용성을 실현할 수 있다고는 공언하지 않고, 'Five Nine'의 가용성을 실현하기 위해서는 '병렬 시스플렉스 (Parallel Sysplex)', 즉 클러스터 구성을 전제로 이야기하는 것이다.
그렇다고 어느 시스템이든 클러스터 구성만 한다면 충분한 신뢰성을 확보할 수 있는 것은 아니다. 클러스터 구성이라면, UNIX서버에서도, IA/Windows서버에서도 구축이 가능하다. 그렇지만, 신뢰성의 확보는 단순히 테크놀러지만으로 대응할 수 있는 문제가 아니며 다양한 요소에 통합적인 체계, 최종적으로는 장애나 불안정 요소를 하나씩 찾아서 제거해 가는 인적 지원을 포함한 지대한 작업이 전제로 되는 것이다.
IBM에서는 System z10을 최상위급의 서버로 위치시키고 있으며 가상화를 시작으로 서버의 기반 기술이 되는 최신 기능을 우선 System z10부터 실현하고 나서, UNIX 서버와 하위 서버로 전개해 나가는 전략을 취하고 있다. 결국, IBM System z10은 최첨단 기술의 집합체이며 기술 개발의 성과를 압축하고 있는 것이다.
윤병훈 상무/한국IBM 책임전문위원
bhyoon@kr.ibm.com