폐쇄망 환경의 배포 시스템 개발기

안녕하세요. 뱅크샐러드, Advanced Financial Infra Team(이하 AFIT) 서지원 입니다.

AFIT 은 최고의 개발환경을 구축한다 는 Vision 아래, IDC 에 Nutanix 를 올린 Private Cloud 환경을 멋지게 개선하고 있는 팀입니다. 이번 글은 AFIT 에서 진행한 Alice 라는 이름의 배포 시스템 개발 프로젝트 이야기를 적어보려 합니다.



💁‍♂️ 폐쇄망 환경에서 운영이 필요한 서비스가 있어요

뱅크샐러드는 은행을 포함한 금융 기관과 협업의 대부분을 IDC 내 폐쇄망 환경에서 진행되는 경우가 많아요. 각종 보안 및 법률 규정을 준수하기 위함이죠. 그러다 보니 다양한 managed service 를 제공하고 있는 퍼블릭 클라우드 환경이 아닌 인터넷이 되지 않는 IDC 환경에서의 서비스 운영도 필요한 상황이에요.



😰 개발자가 폐쇄망을 싫어합니다

뱅크샐러드는 대부분의 시스템을 클라우드 환경 내 Kubernetes (이하 k8s) 를 이용해 운영하고 있습니다.

deploy_bot

[ 뱅크샐러드의 Cloud 운영 환경 ]

그리고 Slack을 통해 손쉽게 배포할 수 있는 deploybot 이라는 서비스도 존재하죠. 몇 개의 간단한 명령어 입력을 통해 production을 포함 다양한 운영 환경에 배포와 롤백 그리고 배포 기록 확인까지 손쉽게 가능합니다.

deploy_bot

[ 배포 시스템, DeployBot ]

그런데 인터넷이 되지 않는 폐쇄망 환경에서는 이를 사용할 수 없었죠. 더불어 불편한 점이 한두 가지가 아니였어요. 필요한 걸 구축하지 않으면 모든 걸 수동으로 해야 하니까요.



🤨 우선 배포 시스템부터!

폐쇄망 환경이 강제되는 IDC 환경에서는 기존에 구축된 편리한 인프라를 사용할 수 없는 제약이 존재했습니다. 그럼에도 우리 팀은 서비스를 빠르게 만들고 확장해 나가야 하는 입장이였죠. 그러다보니 아래와 같은 고민으로 생각이 발전했습니다.

-

앞으로 만들어 갈 서비스에 문제가 발생했을 때
빠르게 대응할 수 있는 환경인가?

-


결국 저희는 장기적인 관점에서 서비스를 빠르게 확장하는 것 이전에 이를 안정적으로 운영할 수 있는 기반을 만드는 것이 먼저라고 판단 하였고 서비스를 운영함에 있어 가장 기본이 되는 배포 시스템 구축을 가장 먼저 시도하였어요.

그럼 뭐 부터 해야할까? 🤔

모든 서비스의 시작이 그렇듯 요구사항 및 스펙 산정이 필요하겠죠?
내부 개발자분들께 리서치를 해본 결과 아래와 같은 pain point 및 요구사항이 있었습니다.

  • 현재 우리 폐쇄망 IDC 환경은 Docker 기반의 배포를 운용할 수 없는 상태라 불편하다
  • 버튼 클릭 한번에 배포 / 롤백을 손쉽게 할 수 있었으면 좋겠어요
  • 무중단 배포는 기본 이겠죠?
  • 서비스 별 배포 기록 관리가 되야 합니다
  • 안정적인 운영을 위해 단계적 배포 전략이 필요합니다
  • Authentication/Authorization 기능 지원이 되었으면 해요
  • GUI 기반에 이쁘고 손쉬운 인터페이스를 가졌으면 좋겠어요

이미 많은 Tech 회사에서 배포 시스템으로 사용하고 있는 것이 있죠. 바로 Jenkins, 우리도 고려 해 보았습니다. 위의 요구사항들을 만족할 수 있는지 말이죠.

jenkins

일반적인 요구사항들은 충족할 수 있었지만, 몇 가지 아쉬운 부분이 있었습니다.

  • 단계적 배포 방식 적용의 어려움
  • SSO를 통해 3rd Party Authentication 는 가능했지만, Authorization 은 어려움
  • 방대한 기능때문에 적응이 어려움
  • 올드한 UI (취향을 타는 부분이지만 팀원 모두 동의 🙆‍♂)

의사결정에 가장 중요한 부분은 단계적 배포 환경 부분이 가장 큰 포션을 차지했습니다. 그리곤 GUI 기반에 멋진 자체 배포 시스템을 만들어 보기로 의기투합 하였습니다.


배포 전략 선택하기 📈

일반적으로 알려진 배포 전략은 Rolling, Canary, BlueGreen 이렇게 3가지가 있습니다
이 3가지 전략은 상황에 따라 장점 및 제약이 존재할 수 있는데요. 자세한 설명은 Dzone Link를 참고 해 주세요.

deployment_type

[ 배포 전략 ]

현재 k8s 환경의 뱅크샐러드가 사용하고 있는 방법은 rolling 방식으로 Router에서 각 pod에 트래픽을 조정하여 Sleep 상태로 만든 후 하나씩 Update 하는 방식을 취하고 있습니다

우리가 운영중인 IDC 환경은 Nutanix 환경으로 BlueGreen 전략을 채택하기에는 AWS의 노드 대비 기동 속도가 느리기 때문에 오히려 전체적으로 더 느린 배포가 될 수 있습니다. (리소스도 더 들테니 💵 측면에서도 더 증가하겠죠) 이에 Canary 배포 전략을 취하기로 결정했어요. 🙆‍♂


CI/CD는 무엇을 사용할까? 📦

현재 뱅크샐러드는 Github Actions 을 이용하고 있어요. 하지만 폐쇄망에서 사용하는 Github Enterprise 는 아직 GitHub Actions 을 제공하지 않았습니다. 그래서 아래와 같은 기준에 따라 Jenkins 외 다른 선택지가 있는지 조사해 보았습니다.

  • 기술적인 새로운 시도
  • 간단하고 직관적인 기능
  • Github Enterprise 계정 연동이 가능
  • 폐쇄망에서 구축할 수 있어야함

droneio

[ drone.io ]

그러던 와중 찾게 된 drone.io는 매우 심플한 UI에 CD 외 다른 부분에 대한 지원, 그리고 손쉽게 Github Enterprise 계정 연동을 취할 수 있는 장점이 있어 팀원 모두가 drone 을 도입해 보는것에 찬성 하였습니다.

CD의 경우 기존 IDC 환경에서 L4와 Nutanix api 컨트롤을 담당하기 위해 만들었던 Friday라는 이름의 서비스를 개량해서 사용하기로 했습니다.



😗 자 그럼 어떤 모양으로 만들어 볼까요

시스템은 크게 3가지 서비스로 만들었어요. 실제 사용자가 작동하는 deploy-web 과 deploy-api 그리고 배포를 담당하는 Friday 서비스 이렇게 3가지 입니다.

deploy 구조

[ 폐쇄망 IDC 내 배포 시스템 ]


1차 스펙 📝

그리고 앞선 요구사항을 바탕으로 아래와 같은 컨셉 디자인을 잡았어요. 뱅크샐러드의 SSO를 통해 로그인 후 Github Enterprise 에 존재하는 repository를 보여줍니다.

배포시스템 상세화면

[ 서비스 목록 ]

배포시스템 상세화면

[ 배포 시스템 상세화면 ]

  • 선택한 서비스에 각종 정보 표현
  • VM의 갯수와 상태 및 배포 Image Tag (master-mered 된 github commit sha) 표현
  • 누가 언제 어떤 이미지에 무슨 Action 을 취했는지 표현
  • Github Enterprise 에서 merge 된 코드가 CI를 거쳐 build 된 이미지 표현
  • 배포를 원하는 이미지를 선택하면 5번 위치에 Insert 되는 것을 표현
  • 단계별로 버튼 한번 클릭에 배포 및 롤백이 될 수 있도록
  • 배포 진행중에 사용자 간 간섭이 생기지 않도록 이미지에 Lock 기능 제공
  • Docker 이미 기반의 build 및 배포
  • SSO 인증을 통한 로그인

Docker를 활용해 개발 및 배포의 편의성 확보 🐳

금융 IDC 환경에서 Kubernetes 와 같은 Container Ochestration 플랫폼을 이용한 레퍼런스가 없기에 각 VM에 빌드 된 Docker 이미지를 배포하는 방식을 취하였고, 이를 통해 개발 및 배포의 속도와 편의성 그리고 일관성을 확보 하였습니다. 이는 앞으로 모니터링 및 다양한 시스템을 붙이고 고도화 할 수 있는 기반을 마련한 것입니다.


누구나 손쉽게 사용할 수 있는 배포 시스템 🤩

배포 단계별로 시각화 된 GUI를 통해 누구나 손쉽게 클릭 한번에 배포와 롤백을 할 수 있게 되었습니다 단계별 배포 UI

[ 단계별 배포 UI ]


세부적인 권한 관리는 아직.. 하지만 😉

위에서 언급한 것 처럼 1차 스펙에서는 SSO 인증을 통해 로그인 하는 정도로만 만들었습니다. 하지만 우리가 배포 서버를 자체적으로 구현한 것은 앞으로 서비스 별 세부적인 권한 관리까지 만들기 위한 초석을 다진 것이기도 합니다.


배포 중 순단이 일어나지 않게 고려 ⚡️

모든 배포방식이 그렇듯, 로드밸런서 역할을 하는 Router 에서 일방적으로 서버를 1개씩 내리며 배포를 하게되면 해당 서버를 보고 있던 사용자는 순단을 겪게 됩니다. 때문에 L4에서 배포를 하고자 하는 VM 으로의 트래픽을 점차 낮춰 0%가 되면 VM에 새로운 이미지를 배포 후 전개를 하도록 개발 하였습니다.


-

완성되어 실제 배포 하는 모습을 살펴 볼까요?

-



PR 을 merge 하면 배포 시스템에 짠! 🌟

작성된 코드를 Github 에 Push 하면, webhook 을 이용해 아래와 같이 drone 이 작동합니다. drone 을 통해 빌드 된 docker 이미지는 Nexus 라는 registry 시스템에 저장되어 이를 Web 에서 불러와 배포에 사용하게 되는 구조인거죠.

build 이미지 올리기

[ Push 된 내용이 배포 시스템에 올라오는 과정 시연 ]

위 영상에는 모든 화면을 보여드리고자 왔다 갔다 하다보니 복잡해 보일 수 있지만, 쉽게 말해 Approve 된 PR 을 merge 하고 기다리면 되는겁니다


배포는 이렇게 작동합니다 😉

배포를 원하는 서비스 이미지를 선택 후 Canary Deploy 버튼을 누르면 즉시 1번 VM에 배포를 시작합니다. 물론, Force Deploy 옵션을 켜면 한번에 전체 배포도 가능합니다만 Canary 배포 전략을 취하고 있는 만큼 권장하지 않고 있습니다.

canary 배포 실행

[ Canary Deploy ]



배포가 시작되면, 하단의 Docker 이미지 리스트 부분에 Lock 이 걸리게 됩니다. 배포가 진행되는 도중에 혹여나 다른 사용자가 다른 이미지를 배포하며 꼬일 수 있는 상황을 방지하기 위함이죠.

전체 배포 실행

[ Deploy All : gif 용량 상 배포 시간은 편집 하였습니다 ]



1번 VM에 배포가 완료되면, 서비스에 이상이 없는지 모니터링 후 이어서 DeployAll 을 실행 할 수 있습니다. 물론 각 단계에서 Rollback 도 가능합니다.



🌳 개발기를 마치며

만들다 보니 계속해서 필요한 기능들이 떠오르며 욕심이 생겨 처음 계획했던 것 보다 조금 더 추가된 기능들이 생겨났지만, 이쯤에서 1차 스펙을 마무리 하게 되었습니다.


처음 개발 시작할 때 “당장에 만들어야 할 서비스도 많은데 이거 언제 만들지?” 하는 우려도 있었지만, 이제 뱅크샐러드는 폐쇄망에서 도커를 사용할 수 있게 되었고, k8s 환경에서 개발하는 개발자들이 도커라는 동일한 경험으로 개발을 할 수 있게 되었습니다. 그리고 CI/CD 를 통해서 자동으로 도커 빌드와 이미지 등록을 할 수 있게 되었습니다. 또한 GUI 툴을 이용함으로써 ssh 에 들어가서 배포하는일이 없어졌으며, Canary무중단 배포까지 구현하였습니다.

calp


이 시스템을 보고 두 손 들고 환영해 주는 사용자(사내 개발팀)들을 보니 뿌듯하기까지 합니다 🥺
역시 서비스는 누군가에게 도움을 줄 수 있는 모습을 보았을 때 뿌듯함과 함께 행복이 밀려오는 것 같습니다. 아직 배포시스템에도 개선하고 싶은 기능이 많아 욕심나지만 잠시 내려두고 더욱 편리한 뱅크샐러드의 IDC 환경을 만들기 위해 빈 곳을 좀 더 매꿔야 겠습니다.

서툰 글을 읽어주셔서 감사합니다 🙏
그리고 멋들어진 서비스를 함께 만들어 주신 AFIT 팀원들께 많은 감사드립니다.



✏️ 참고


더 나은 개발 환경에 관심이 있는 분, 배포 자동화에 관심이 생긴 분, 금융 인프라 개선을 함께 하고 싶은신 분 모두 💚뱅크샐러드💚에서 함께 이야기해요! 🙂

보다 빠르게 뱅크샐러드에 도달하는 방법 🚀

지원하기