신한은행이 클라우드 구축에서 배운 것 “이론에 기대지 말라”

*본 기사는 BylinePlus+ 웨비나 ‘금융산업을 위한 AI&Cloud 활용 전략’ 신한은행 발표 사례를 정리한 것입니다.

발표자: 한상훈 신한은행 ICT운영부 셀장

금융권 회사가 클라우드를 구축할 때 고려해야 할 점은 규정, 보안, 거버넌스 등 고려해야 할 영역이 많다. 신한은행의 경우 단순 구축뿐 아니라 이슈 리포팅, 운영 표준 메뉴 구축 등 지속 활용 가능한 시스템까지 제작했다. 신한은행의 구축 사례를 통해 금융권 클라우드 구축의 어려움에 대해 알아보자.

우선 은행의 경우 클라우드 제작 관점과 서비스 관점에서의 차이가 있다. 신한은행의 경우 클라우드 업체(CSP, Cloud Service Provider)의 성능 자체는 문제가 없다고 여기고, 이 성능에서 업무에 필요한 서비스를 얼마나 잘 구축하느냐가 중요하다는 지점에서 출발했다. 즉, EC2, 가상머신, EKS 등의 개념만으로는 업무 서비스가 만들어지지 않는다.

금융권 클라우드 담당자가 고민해야 할 것

위 그림은 신한은행 프로젝트 추진 구현 범위를 도식화한 장표다. 1. 업무 서비스가 동작될 클라우드 환경을 먼저 설계하고, 2. 이를 바탕으로 집을 짓듯이 클라우드 기반 환경을 구축한 뒤, 3. 인테리어, 가구 등 서비스 영역을 구현하는 것을 기본으로 했다. 탑다운 방식으로 거꾸로 말하면 AI 서비스, 블록체인, 앱 서비스를 구축하기 위해 미들웨어, 프레임워크, CICD, 배포 체계 등을 구축하고, 그 위에 완벽한 아키텍처를 그려야 한다. 거기다 금융회사 경우에는 클라우드 서비스 전환 시 금융 감독기관에 보고를 하는 행정 절차도 존재한다.

즉, EKS 등의 클라우드 이론은 중간에 있는 IaaS 구축 영역뿐이다.

일반적으로 가상머신 위에서 서비스를 동작시키거나, PaaS 위에서 서비스를 배포하더라도 핵심은 소비자가 사용하게 되는 업무 서비스가 얼마나 잘 작동하느냐다.

이론대로 구축했으나 실제로 발생했던 난제

신한은행의 경우 고난도 서비스 구성 요소를 많이 갖고 있어 기반 환경을 잘 다졌다고 생각했다. 그러나 실제로는 인프라 부분에서 문제가 발생했다. 설치형 오픈 DB로 인해서 1년 동안 지속적인 문제가 발생했다. 원인은 오픈 DB 기본 세트인 마스터 노드와 그리고 리플리카 노드만으로 구성할 경우 추가 장애 요인이 발생하게 된다. 이를 고가용성 측면과 업무 활용 측면을 명확히 분리하고 재구성함으로써 해결했다.

즉, 역할 분리를 위한 아키텍처를 새롭게 재정의했고, 오픈 DB의 구조를 신한은행의 서비스에 맞춰 전부 수정했다.

두 번째 문제는 보안과 거버넌스였다. 당시 온프레미스 제품과 클라우드 네트워크 호환 이슈가 꾸준히 발생했는데, 통신 및 보안에 대한 내부 표준 구축 설계를 통해 해결했다. 구체적으로는 웹소켓 서비스가 필요했는데, 클라우드 연결 서비스에서 세션 끊김 현상이 지속적으로 발견됐다. ALB에서 NLB로 변경해 해결했으며, GWLB를 통해 네트워크 구조 전체를 개편하기도 했다.

세번째 문제는 CSP 가이드를 제대로 파악하지 못해서 발생했다. 임의로 구현했다가 낭패를 본 셈이다.

요구사항은 업무 서비스에서 세션 정보 저장을 위해서 레디스(Redis) 사용 요구가 필요했다. 이를 좀 더 안정적으로 운영해 보고자 클라우드 매니지드 레디스를 사용했다. 그런데 앱 세션이 비정상적으로 종료하는 경우가 발생했다. 예를 들어 강제로 앱이 종료되거나, 통신상 문제로 세션이 끊기는 경우가 발생할 경우 신한은행의 로직 상에서는 로그아웃될 경우에 실시간 정보를 지우도록 레디스의 명령을 주게 되는데, 레디스가 해당 역할을 하지 못해 메모리에 데이터가 계속 누적되고 있었다. 이를 파라미터 수정 하나로 해결했다.

본격적인 이슈 해결 사례 1 – 인프라

신한은행이 클라우드 매니지드 서비스를 구축할 때 고려한 것은 두가지였다. 고가의 DB를 사용하기에는 비용 문제가 있었고, 온프레미스와의 연동도 고려해야 하므로 결국 오픈 DB를 사용하게 되었다. 이러한 오픈 DB의 경우 운영상에서 문제가 발생했다. DB 서버 마스터 노드에서 장애가 발생할 경우 리플리카 노드로 마스터 권한이 넘어가면서 고가용성을 확보했지만, 분산돼 있는 트랜잭션이 결국은 리플리카 노드 한쪽으로 몰리게 됨으로써 성능 이슈가 발생하게 됐다.

신한은행은 리플리카 노드를 리드 온리 방식으로만 활용하거나, 업무 서비스 중 배치, 이벤트 발송 정보 수집 등 트랜잭션 자체를 분리했다. 그러나 마스터 노드의 실시간 거래성에 문제가 생기면서 리플리카 노드의 거래로 합쳐지게 되다 보니 리플리카 노드에 부하가 발생했다. 결국 리드 온리 처리만 가능하게 했던 리플리카 노드가 스탠바이 노드 역할까지 받음으로써 활용성 문제가 생겼다.

이를 고가용성 관점에서 재설계를 했다. 마스터 노드와 스탠바이 노드를 역할을 명확하게 분리했으며, 두 번째로 역할, 업무, 활용성 관점에서 마스터 노드와 리플리카 노드의 역할을 철저하게 분리함했다. 이를 통해 오픈 DB를 사용하면서도 온프레미스와 유사한 고가용성을 확보하게 되었다.

또한, 이 문제를 해결하다 보니 리플리카 노드 확장을 통해서 DW 전용 노드, 배치 전용 노드, 이벤트를 발송하기 위한 전용 노드 등을 분리함으로써 서비스 성능이 향상되는 효과도 얻었다.

업무 관점에서는 마스터 노드(실시간 거래 처리)와 리플리카 노드)(정보 조회성 노드)를 분리함으로써 안정적인 운영이 가능했다.

본격적인 이슈 해결 사례 2 – 보안

클라우드 서비스를 통해 네트워크 구조를 설계하면 된다는 것은 모두 알고 있다. 그러나 업무 서비스 사이에 사용하는 보안 솔루션 간의 연관관계에 있어서 호환성 또는 네트워크 구조 설계를 다시 해야 됨을 느끼게 되었다. 클라우드는 기본적으로 스케일 인아웃의 기능을 가지고 있는데, 신한은행의 업무 서비스 중 웹 소켓은 세션을 계속 유지해야 하는 요구사항이 있다. 당시 로드 밸런스에는 ALB를 사용 중이었는데, 스케일 인아웃 시 세션을 다 끊어버리는 현상을 발견했다. 이를 통해 클라우드 매니지드 서비스를 맹목적으로 사용하는 것에 대해서는 다시 한번 고민하게 되었다.
두 번째는 네트워크 트래픽 흐름 문제였다. 기존에는 인라인 방식으로 구성하는 것이 일반적이었는데, 일렬 구성 중간에 보안 솔루션을 중간 배치하다 보니 소스 IP를 NAT 처리하는 현상이 발견됐다. 문제 분석에 많은 공을 들였으나 실제 원인은 매우 간단했는데, 클라우드 네트워크 구조는 최초부터 보안 솔루션을 어디에 끼울지 새롭게 아키텍처를 지정해야만 한다는 것이었다.

신한은행의 경우 타임웨이트 설정 부분을 튜닝하라는 가이드를 받았다. 이 경우 일부 문제는 해결되었으나 근본적으로 세션이 끊기는 문제는 해결되지 않았다. 결국, 외부와의 통신 관문 역할을 하고 있는 통합 네트워크 존에서 트래픽 양에 대한 분산, 유연성을 가지려고 사용했던 클라우드 매니지드 서비스인 ALB를 업무 용도별로 분리를 하고, 그리고 다중 구성한 NLB로 변경함으로써 트래픽 양을 분산 처리하는 효과와 그리고 첫 번째 이슈인 웹 소켓 세션 끊김 현상까지 해결했다.

이러한 문제는 온프레미스 전문가들도 찾지 못하는 문제였는데, 맹목적인 ALB 사용보다는 환경에 맞게 여러 기술 요소를 혼합해 쓸 수 있어야 한다는 것을 깨달았다.

인라인 통신 구성 방식도 암 구성으로 변경했다. 인라인 구성에서 서드파티 보안 솔루션을 사용했을 때 작동 방식이나 호환성 문제가 발생했다. 거래량이 많을 경우 병목현상이 발생한다는 것도 찾아냈다. 이를 원암 구성(병렬적)으로 분산 처리함으로써 시큐리티 존(방화벽 존, IPS 존, 멀웨어 차단 존 등)을 여러 개 생성할 수 있었다.

원암 방식은 대규모 데이터를 처리하는 데이터센터에서 주로 사용하는 방식이다. 클라우드 서비스에서 비슷한 방식을 제공하기는 하지만 갓 출시됐거나 베타 버전인 경우가 대부분이다. 따라서 GWLB 같은 기술을 도입하면서도 꾸준히 새로운 기술을 도입하기 위한 연구를 진행 중이다.

본격적인 이슈 해결 사례 3 – 서비스

개발 언어 중 자바 스프링 기반으로 업무 서비스 개발을 진행할 때 사용자 로그인 세션 정보를 서버가 아닌 Redis에 저장하는 요구사항이 있었다. 이에 설치형보다는 클라우드 매니지드 레디스를 사용했다. 그러나 실제로 운영해 보니 메모리가 증가하는 추세를 보였다.

예를 들어 사용자 로그인 세션이 정상적으로 로그아웃될 때는 삭제가 잘 되지만 비정상적인 경우, 세션 정보를 삭제하지 않고 계속 저장하고 있다는 것이 문제였다. 이 같은 문제가 해결되지 않자 3개월 후에는 메모리 사용률이 지나치게 높아져 있었다. 매뉴얼을 제대로 참조하지 않은 것이 문제였다.

결론적으로, 클라우드 매니지드 레디스의 기본적인 설정은 임의로 삭제가 불가능한 것이 기본 설정이었다.

또한, 사용자 입장에서는 각 업무 환경 또는 프로젝트 단계에 따라 파라미터를 조정을 해야 하는데, 그 사실을 몰랐기 때문에 발생한 문제였다. 그 결과 파라미터를 변경함으로써 해결하게 되었다.

해당 파라미터는 엘라스틱 캐시였는데, 그중 “notigy-keyspace-events” 파라미터 설정을 변경함으로써 모든 문제가 해결되었다. 그 결과 늘려놓은 레디스 메모리까지 축소할 수 있게 돼 클라우드 비용을 축소시키는 효과도 얻었다.

즉, 서비스는 기술 관점이 아닌 서비스 관점에서 먼저 접근한다면 문제 해결이 더욱 쉽다.

기대효과

기술이 아닌 서비스 관점에서 바라보자, 신한은행의 클라우드 서비스는 다음과 같은 절차를 갖게 되었다.

첫 번째, 이슈 발생 시 클라우드의 특수성을 고려한다. 예를 들어 온프레미스와 다른 통신 보안 구조가 있으므로, 클라우드의 특성에 따라 튜닝해야 할 부분이 있다는 것을 인지하는 게 제일 중요하다. 이를 위해 신한은행은 클라우드 전문가뿐 아니라 온프레미스의 서버 통신 또는 보안 전문가들, 서비스 개발자들 전체가 모여서 다각도로 분석하고, 이를 통해 문제를 해결하고 새로운 아키텍처까지 만들 수 있었다.

두 번째, 해결에만 초점을 맞추게 되면 지속 가능성이 사라지게 된다. 담당자가 변경될 경우 같은 이슈를 다시 경험할 수 있으므로, 이슈 리포팅을 정기적으로 하고 또는 문제에 대한 표준 가이드북을 제작했으며, 새 아키텍처를 개정할 경우 표준 아키텍처까지 개정해 활용 가능한 기술서를 제작하고 있다. 아키텍처 역사서가 되는 셈이다.

그 결과 서비스 작동에 최적화된 클라우드 구현이 가능했으며, 신규 사업 추진 시 과거의 활용서를 참고해 프로젝트 구축 기간을 단축할 수 있는 효과도 얻었다.

정리. 바이라인네트워크

<이종철 기자> jude@byline.network