tyle-Y4p-1

2년동안 못 찾은 모바일 뱅킹의 장애원인을 진단하다!

 

이번 포스팅에서 소개드릴 케이스는 장기간 동안 원인을 알 수 없는 장애와 싸워온 모바일뱅킹 사례입니다.  저희를 부르기 이전까지 해결 할 때까지 어떤 일들이 있었을까요?

casestudy_mobilebanking_2

서버의 댓수를 늘려, 응급 처방을 한 사례 

먼저, 해당 솔루션은 도입에 2년 6개월정도 걸린 모바일 뱅킹 솔루션이었습니다. 사실 오래 전에 끝났어야 하는 프로젝트인데 원인을 알 수 없는 장애가 발생하여 프로젝트가 마무리되지 못했고, 이 장애를 해결하기 위해 6개월정도를 국내 J사와 P사의 APM 솔루션을 통해서 성능 진단을 하고 장애 원인에 대해 추적을 하고 있었죠. 이 과정에서 완전한 해결은 하지 못했지만 물리적 서버 용량을 늘리는 형태로 응급 처방이 진행됐습니다. 기존 시스템이 IBM AIX 코어로 8코어정도를 쓰고 있었는데, 무려 40코어나 사용하는 굉장히 큰 문제가 발생한거죠.

엄청난 비용

IBM 2코어 당 6천달러 정도로 계산을 해보면, 단순히 코어 수로만 비용 계산을 했는데도 다섯 배나 차이가 납니다. 여기에 보통 비용 계산을 할 때 더하는 유지보수비용 10%와 5년 TCO까지 고려를 하면 이 은행이 지출한 비용은 120,000 달러라는 천문학적인 숫자라고 할 수 있죠.

2년동안 솔루션을 개발했고, 6개월동안 컨설팅을 진행했음에도 불구하고 문제가 해결되지 않자 은행은 심각한 상황에 놓였습니다. 하지만 솔루션 공급사도 별 대책이 없었습니다. 그렇다면 도대체 8코어로 동작되는 시스템과 40코어로 동작하는 시스템은 어떤 차이가 있었을까요?

casestudy_mobilebanking_6

사실 신규 시스템에 많은 기능이 추가된 것은 아니었습니다. 통합 테스트 중 문제가 발생해 시스템의 기능은 MVP 수준으로 축소되었습니다. 그럼에도 불구하고 이렇게 비대해진 리소스는 정말 심각한 문제였죠. 이러한 문제를 장애로 봐야 할까요, 성능으로 봐야 할까요? 기존 동작하던 시스템에 몇 가지 기능만 추가되었음에도 불구하고 어마어마한 리소스를 요구하는 케이스는 성능 문제입니다.

다른 APM들은?

그렇다면, 다른 APM들은 이 성능 문제에 어떻게 대처했을까요? 일단 해당 은행은 기존 사용중인 J사의 APM을 통해 컨설팅을 받았습니다. 분명히 많은 slow query를 해결하고 응답시간을 개선했지만, 코어 수는 줄어들지 않았습니다. 게다가 종종 CPU 사용량이 80%까지 올라가는 극단적인 상황이 발생했죠. 이렇게 J사의 APM으로 해결이 되지 않으니, P사의 제품까지 구매를 하여 해결을 시도했지만 CPU 사용량의 문제는 해결이 되지 않았습니다.

다른 APM이 문제를 해결하지 못한 이유

다른 APM들은 왜 문제를 찾아내지 못했을까요? 잠시 문제를 일반화시켜, 웹서비스에서 발생하는 문제 유형들을 몇가지 나열해보도록 하겠습니다.

casestudy_mobilebanking_16
웹서비스에서 발생하는 문제의 대부분은 SQL 문장을 잘못 만들어서 생기는, 소위 말하는 slow query로 인해 발생한 문제가 80%입니다. 그 다음으로는 WAS connection pool, WAS 인스턴스의 설정 부분의 문제를 찾아내는 것이 2~30%의 문제에 해당 됩니다. 이런 경우는 웬만한 APM을 통해 손쉽게 찾아내고 해결할 수 있죠. 결국 slow query나 WAS 내부의 성능 문제 등 쉽게 해결할 수 있는 문제들이 웹 서비스 문제 유형 중 약 95%에 해당합니다.

그런데 진짜 문제는, 나머지 5%입니다. 이 5%의 문제때문에 시스템은 특정 상황에서 매우 많은 자원을 필요로 하게 되고, 이러한 상황을 대비해 CPU, 메모리 등의 자원을 실제 필요한 것보다 많이 준비해놓아야 하는거죠. 이 5%의 문제는 특정 메소드, 즉 개발자가 만들어놓은 소스코드의 특정 모듈 하나, 혹은 특정 메소드에 숨겨져있는 요소로 인해 발생하는 부분입니다. 아쉽게도, 이 부분은 프로파일 예외구간이기 때문에 메소드 호출에 대한 상세 정보를 찾기가 굉장히 어렵습니다.  

따라서 다른 APM들은 이 5%에서 발생하는 문제를 원인불명이라 이야기하며, 그나마 다른 95%의 문제를 찾은 것을 축하해야 한다고 이야기를 합니다.

타 APM 이 찾아내지 못하는 5%가 바로 이러한 프로파일 예외구간입니다.물론 다른 APM들도 이 구간을 추적하지 못하는 것은 아닙니다. 다른 APM의 경우, 개발자들과 협업하여 추측을 통해 문제를 찾아나가게 됩니다. 그러나 타 APM은 문제를 찾아내기 위해 개발자의 조언과 예측을 필요합니다.   해당 시스템의 개발자의 예측을 토대로 다양한 메소드에 스크립트를 걸어보지만 이러한 방법으로 문제를 찾아내는 것은, 운이 좋아야 가능한 일입니다.

타 APM과 와탭의 차이점을 의사에 비유해 설명한다면 쉽게 이해할 수 있습니다. 타 APM들은 환자에게 무슨 검사부터 받을지 물어본다면, 와탭의 APM은 환자가 왔을 때 MRI부터 찍어보기 때문에 문제를 빠르게 찾을 수 있습니다.

기술적 설명

그렇다면 와탭의 APM은 어떤 원리로 타 APM이 찾지 못하는 문제들을 찾아낼 수 있을까요?

와탭의 APM은 10초마다 기존에 숨겨진 메소드 영역의 스냅샷을 촬영합니다. 스냅샷을 계속해서 찍고있기 때문에, 문제가 발생해도 그 기록이 스냅샷에 남을 수밖에 없죠. 물론 지속적으로 스냅샷의 데이터를 가져오면서도 와탭만의 기술력으로 서버에는 부하를 주지 않습니다.

이렇게 트랜잭션이 진행된 과정에 대한 자세한 기록을 남겨줄뿐만 아니라, 이 기록을 통계적으로 분석하여 시스템의 병목 구간을 찾아내는 것 또한 가능합니다. 이 기능은 다른 회사에서 흉내내지 못하도록 특허가 걸려있기 때문에, 와탭의 APM에서만 제공하는 기능이라고 할 수 있겠죠. 그렇다면 이러한 기술을 활용해서 어떻게 스마트 뱅킹 어플리케이션의 문제를 찾아냈을까요?

실제 사례

위 이미지는 처음에 저희가 방문했을 때의 상황입니다. 많은 트랜잭션이 멈추지 않고 진행중이었고, 20개의  thread에서 2천개의 요청이 발생하면서 CPU가 100% 가까이 사용되는 심각한 상황이었습니다.   그래서 앞서 말씀드린 active stack들의 모음인 Top Stack을 분석해 보니, 대부분의 트랜잭션에서 xml parser관련된 유사한 stack들이 여기 저기 발견되었습니다.

casestudy_mobilebanking_28

이 내용을 통계적으로 분석해 자주 호출하는 클래스를 파악할 수 있었고, 이 부분의 개선하기로 했습니다.  고객사는 6개월동안 찾지 못한 문제를 설치 40분만에 찾으니 당연히 의아해했지만, 솔루션 공급사에게 먼저 이야기를 해서 해당 내용을 수정한 후 서버 열 대 중 한 대의 서버에만 재배포를 하기로 결정했습니다.

개선후 비교

재 배포 후, 6~70%까지 올라가던 CPU 사용량이 2% 이하로 떨어졌습니다. 이 상황을 보고 고객사는 모든 서버에 배포를 하기로 결정하여 문제는 깔끔하게 해결됐습니다. 지금까지의 정리해보면 아래와 같습니다. 2년에 걸쳐 만들어진 솔루션의 문제를 6개월동안 해결하지 못했는데, 와탭은 APM 설치에서 문제를 찾는 것까지 두 시간이 걸렸고, 그 문제는 20일만에 해결되었습니다.casestudy_mobilebanking_31

blog_signup_banner_b (3)