2020.06.19

영국 은행그룹 RBS, 자동화로 서버 프로비저닝 수작업 비용 700만 파운드 절감

Scott Carey | InfoWorld
로얄 뱅크 오브 스코틀랜드(Royal Bank of Scotland, RBS) 그룹(신임 CEO 앨리슨 로즈의 지휘 하에 곧 냇웨스트(Natwest) 그룹으로 사명 변경 예정)은 2007년 금융 위기에 따른 정부 긴급구제 이후 대대적인 기술 현대화 작업을 진행해왔다.
 
ⓒ Getty Images Bank

이 현대화에서 중요한 부분은 내부 및 고객 대면 애플리케이션을 위한 소프트웨어 제공 주기를 단축하고, 수동 서버 프로비저닝 작업을 자동화함으로써 비효율적인 프로세스와 비용을 없애는 것이다. 자동화는 지난 3년 동안 RBS 전체적으로 빠르게 진행됐다.

데브옵스 툴 솔루션 업체인 퍼펫(Puppet)과 진행한 최근 웨비나에서 RBS의 인프라 엔지니어인 데이비드 샌디랜즈는 과거에는 “릴리스가 충분히 빠르지 않았다”면서 “빌드 위에 수정과 업데이트를 적용해야 하는 프로젝트가 많았다. 이 프로세스는 이메일을 보내고 직접 자리로 찾아가 풀 요청을 하는 등 대부분 수동이었다”고 말했다.

자동화가 필요하다는 점은 분명했다. 그러나 RBS는 효과적인 자동화를 위해 먼저 현대화된 클라우드 인프라를 도입해야 했다.

많은 금융 서비스 기관이 그렇듯이 RBS도 물리 서버에서 가상화된 클라우드 서비스로 꾸준히 전환하고 있다. 지금은 주로 프라이빗 클라우드이지만 워크로드에 따라 차차 아마존 웹 서비스(AWS)와 마이크로소프트 애저의 서비스형 퍼블릭 클라우드 인프라도 늘리고 있다. RBS는 이러한 새로운 플랫폼을 통해 자동화 기술을 도입했고, 2018년 10월부터 지금까지 700만 파운드(약 900만 달러)를 절약할 수 있었다.
 

프로젝트의 시작

샌디랜즈가 입사한 2005년 당시 RBS는 600여 대의 물리 서버로 구성된 대형 유닉스 시스템을 운영 중이었다. 은행 엔지니어들이 빌드를 개발해 운영팀에 요구사항 목록을 전달하면서 운영에 도달할 때까지 장기간의 개발이 시작되고, 운영에 도달한 시점에는 제대로 된 검토를 실시하기에는 너무 늦은 경우가 대부분이었다. 샌디랜즈는 “그 시점에서 요구 사항과 다른 부분을 발견하는 경우 막대한 릴리스 지연으로 이어지거나 다음 릴리스로 연기됐다”고 설명했다.

가시성 지표의 부족, 셸 스크립트를 통한 수동 정책 적용과 확인, 빌드 서버의 예비성과 회복성 부족, 빈번한 빌드 실패(RBS는 자주 발생하는 다양한 문제를 세부적으로 기술한 워드 문서를 작성했다)는 일반적인 릴리스 주기가 어떤 상태였는지를 잘 보여준다. 빌드가 되더라도 담당 직원들이 엄격한 프로덕션 적합성 검사를 수작업으로 하는 데 다시 몇 주가 걸렸다.

현재 RBS의 서버는 대부분 RHEL과 VM웨어에서 실행된다. 물리에서 가상 인프라, 그리고 컨테이너화된 워크로드로 전환하면서 RBS는 자동화 툴 확대의 필요성을 명확하게 인식했다.

그 결과 RBS는 최근 몇 년 동안 앤서블(Ansible), 테라폼(Terraform), v리얼라이즈(vRealize), 콘코스 CI(Concouse CI), 셰프 인스펙(Chef InSpec)에 이르기까지 새로운 코드형 인프라 툴을 다양하게 도입했다.

예들 들어 구성 관리를 위한 퍼펫을 보면, RBS는 8년 전 퍼펫의 오픈소스 버전을 사용해 실험 수준으로 작게 시작했다. 샌디랜즈와 팀은 은행의 릴리스 프로세스에서 몇 가지 중요한 문제를 수정했다.

샌디랜즈는 이러한 모든 툴에서 볼 수 있듯이 “물리 시스템에서 가상, 컨테이너로 중심이 이동됐지만 여전히 이를 둘러싼 변화 관리 프로세스가 필요했고 이것이 자동화 도입의 확실한 명분이 됐다”고 말했다.
 

변화 관리의 변화

그러나 신중한 변화 관리팀을 설득하는 것이 문제였다. 변화 관리팀은 초기 대부분이 오픈소스였던 새로운 툴에 대해 여러 가지를 우려를 제기했다. 샌디랜즈는 “변화 관리팀과는 주로 전체 파이프라인에 대해, 그리고 모든 툴의 조합을 통해 변화를 철저히 테스트하고 안정적으로 제공하는 방법에 관해 논의했다”고 설명했다.

RBS는 이와 같은 우려를 불식시키기 위해 워크숍을 열고 워크플로우와 툴을 하나씩 시연하면서 작은 규모로 충실한 테스트를 거친 변화를 통해 더 안전하 배포가 가능하다는 사실을 보여줬다. 이와 함께 동료 간의 검토(Peer review)를 문서화하고 IT 기능 전반에 걸쳐 풍부한 작업 지침이 공유됐다.

샌디랜즈는 “이 마케팅 부분이 중요했다. 페이스북 워크플레이스를 사용해서 데모를 공유하고 세션을 실행하고 정기적인 모임과 워크숍도 열었다”고 강조했다.

퍼펫에 관해 가장 우려한 부분은 퍼펫 엔터프라이즈가 모든 서버에서 동시에 변경 작업을 할 수 있다는 점이었다. 샌디랜즈는 “루트로 뭔가를 배포하면 변화 관리에 대한 우려가 발생한다. 또한 방대한 규모의 전사적인 변화가 동시에 일어나고 있다”고 설명했다. 또 “다른 우려는 주기적인 작은 변화에 대한 것이었다. ‘더 정기적인 변화’라는 말에 대해 뿌리깊은 두려움이 있기 때문”이라고 덧붙였다.

자동화에는 고용 안정 측면의 우려도 있다. 샌디랜즈는 “프로젝트 팀에서는 ‘이렇게 하면 우리는 일자리를 잃게 되는가?’라는 질문을 많이 한다. 아니다. 우리는 스택의 위로 올라가게 된다”고 강조했다.
 

주요 지표

접근 방법의 변화로 RBS는 프로덕션 적합성에 대한 내부 SLA 테스트 기간을 자동화 이전의 2주에서 3일로 줄였다. RBS의 목표는 가까운 미래에 이 프로세스를 완전히 자동화하는 것이다.



2020.06.19

영국 은행그룹 RBS, 자동화로 서버 프로비저닝 수작업 비용 700만 파운드 절감

Scott Carey | InfoWorld
로얄 뱅크 오브 스코틀랜드(Royal Bank of Scotland, RBS) 그룹(신임 CEO 앨리슨 로즈의 지휘 하에 곧 냇웨스트(Natwest) 그룹으로 사명 변경 예정)은 2007년 금융 위기에 따른 정부 긴급구제 이후 대대적인 기술 현대화 작업을 진행해왔다.
 
ⓒ Getty Images Bank

이 현대화에서 중요한 부분은 내부 및 고객 대면 애플리케이션을 위한 소프트웨어 제공 주기를 단축하고, 수동 서버 프로비저닝 작업을 자동화함으로써 비효율적인 프로세스와 비용을 없애는 것이다. 자동화는 지난 3년 동안 RBS 전체적으로 빠르게 진행됐다.

데브옵스 툴 솔루션 업체인 퍼펫(Puppet)과 진행한 최근 웨비나에서 RBS의 인프라 엔지니어인 데이비드 샌디랜즈는 과거에는 “릴리스가 충분히 빠르지 않았다”면서 “빌드 위에 수정과 업데이트를 적용해야 하는 프로젝트가 많았다. 이 프로세스는 이메일을 보내고 직접 자리로 찾아가 풀 요청을 하는 등 대부분 수동이었다”고 말했다.

자동화가 필요하다는 점은 분명했다. 그러나 RBS는 효과적인 자동화를 위해 먼저 현대화된 클라우드 인프라를 도입해야 했다.

많은 금융 서비스 기관이 그렇듯이 RBS도 물리 서버에서 가상화된 클라우드 서비스로 꾸준히 전환하고 있다. 지금은 주로 프라이빗 클라우드이지만 워크로드에 따라 차차 아마존 웹 서비스(AWS)와 마이크로소프트 애저의 서비스형 퍼블릭 클라우드 인프라도 늘리고 있다. RBS는 이러한 새로운 플랫폼을 통해 자동화 기술을 도입했고, 2018년 10월부터 지금까지 700만 파운드(약 900만 달러)를 절약할 수 있었다.
 

프로젝트의 시작

샌디랜즈가 입사한 2005년 당시 RBS는 600여 대의 물리 서버로 구성된 대형 유닉스 시스템을 운영 중이었다. 은행 엔지니어들이 빌드를 개발해 운영팀에 요구사항 목록을 전달하면서 운영에 도달할 때까지 장기간의 개발이 시작되고, 운영에 도달한 시점에는 제대로 된 검토를 실시하기에는 너무 늦은 경우가 대부분이었다. 샌디랜즈는 “그 시점에서 요구 사항과 다른 부분을 발견하는 경우 막대한 릴리스 지연으로 이어지거나 다음 릴리스로 연기됐다”고 설명했다.

가시성 지표의 부족, 셸 스크립트를 통한 수동 정책 적용과 확인, 빌드 서버의 예비성과 회복성 부족, 빈번한 빌드 실패(RBS는 자주 발생하는 다양한 문제를 세부적으로 기술한 워드 문서를 작성했다)는 일반적인 릴리스 주기가 어떤 상태였는지를 잘 보여준다. 빌드가 되더라도 담당 직원들이 엄격한 프로덕션 적합성 검사를 수작업으로 하는 데 다시 몇 주가 걸렸다.

현재 RBS의 서버는 대부분 RHEL과 VM웨어에서 실행된다. 물리에서 가상 인프라, 그리고 컨테이너화된 워크로드로 전환하면서 RBS는 자동화 툴 확대의 필요성을 명확하게 인식했다.

그 결과 RBS는 최근 몇 년 동안 앤서블(Ansible), 테라폼(Terraform), v리얼라이즈(vRealize), 콘코스 CI(Concouse CI), 셰프 인스펙(Chef InSpec)에 이르기까지 새로운 코드형 인프라 툴을 다양하게 도입했다.

예들 들어 구성 관리를 위한 퍼펫을 보면, RBS는 8년 전 퍼펫의 오픈소스 버전을 사용해 실험 수준으로 작게 시작했다. 샌디랜즈와 팀은 은행의 릴리스 프로세스에서 몇 가지 중요한 문제를 수정했다.

샌디랜즈는 이러한 모든 툴에서 볼 수 있듯이 “물리 시스템에서 가상, 컨테이너로 중심이 이동됐지만 여전히 이를 둘러싼 변화 관리 프로세스가 필요했고 이것이 자동화 도입의 확실한 명분이 됐다”고 말했다.
 

변화 관리의 변화

그러나 신중한 변화 관리팀을 설득하는 것이 문제였다. 변화 관리팀은 초기 대부분이 오픈소스였던 새로운 툴에 대해 여러 가지를 우려를 제기했다. 샌디랜즈는 “변화 관리팀과는 주로 전체 파이프라인에 대해, 그리고 모든 툴의 조합을 통해 변화를 철저히 테스트하고 안정적으로 제공하는 방법에 관해 논의했다”고 설명했다.

RBS는 이와 같은 우려를 불식시키기 위해 워크숍을 열고 워크플로우와 툴을 하나씩 시연하면서 작은 규모로 충실한 테스트를 거친 변화를 통해 더 안전하 배포가 가능하다는 사실을 보여줬다. 이와 함께 동료 간의 검토(Peer review)를 문서화하고 IT 기능 전반에 걸쳐 풍부한 작업 지침이 공유됐다.

샌디랜즈는 “이 마케팅 부분이 중요했다. 페이스북 워크플레이스를 사용해서 데모를 공유하고 세션을 실행하고 정기적인 모임과 워크숍도 열었다”고 강조했다.

퍼펫에 관해 가장 우려한 부분은 퍼펫 엔터프라이즈가 모든 서버에서 동시에 변경 작업을 할 수 있다는 점이었다. 샌디랜즈는 “루트로 뭔가를 배포하면 변화 관리에 대한 우려가 발생한다. 또한 방대한 규모의 전사적인 변화가 동시에 일어나고 있다”고 설명했다. 또 “다른 우려는 주기적인 작은 변화에 대한 것이었다. ‘더 정기적인 변화’라는 말에 대해 뿌리깊은 두려움이 있기 때문”이라고 덧붙였다.

자동화에는 고용 안정 측면의 우려도 있다. 샌디랜즈는 “프로젝트 팀에서는 ‘이렇게 하면 우리는 일자리를 잃게 되는가?’라는 질문을 많이 한다. 아니다. 우리는 스택의 위로 올라가게 된다”고 강조했다.
 

주요 지표

접근 방법의 변화로 RBS는 프로덕션 적합성에 대한 내부 SLA 테스트 기간을 자동화 이전의 2주에서 3일로 줄였다. RBS의 목표는 가까운 미래에 이 프로세스를 완전히 자동화하는 것이다.



X