[Infrastructure] 재배포 및 배포 롤백: 서비스 장애 발생 시 피해를 최소화하기 위한 롤백의 중요성

💋 인트로

이 포스팅은 우아한테크코스5기 깃짱이 코치 토미의 강의를 듣고 작성했습니다. 

해당 글을 읽기 전에, 아래 포스팅을 먼저 읽는 것이 이해에 도움이 될 것 같다! 

 

[Infrastructure] 무중단 배포 시 고려사항: 서비스 장애를 막기 위한 백엔드 개발자의 눈물나는 노력쿠

[Infrastructure] 무중단 배포 시 고려사항: 서비스 장애를 막기 위한 백엔드 개발자의 눈물나는 노력

 

💋 서비스 장애가 발생한다. 

대규모 서비스를 운영하다 보면, 코드를 병합하기 전에 CI를 통해서 빌드 및 테스트가 통과되는지 확인하는 과정은 필수적이다. 

이런 절차를 강제해서 어느 정도 코드의 질을 관리할 수 있지만, 그럼에도 잘못된 코드로 인해 서비스 장애가 발생할 수 있다. 

 

개발자들은 지속적인 ci, cd로 배포도 자동화한다. 수동으로 배포를 할 때도 존재한다. 

모두들 배포에는 익숙하지만, 롤백에는 익숙하지 않다.

그런데 배포한 코드에 문제가 생겨서 서비스에 장애가 발생한다면?

 

✔ 서비스 장애는 왜 발생할까?

서비스 장애는 왜 발생할까?

크게 아래와 같은 원인으로 요약할 수 있을 것 같다. 

• 데이터 양의 변화
  • 하나의 서비스를 운영하더라도 각 테이블에 따라서 누적되는 데이터의 양은 다르다.
  • 쇼핑몰을 운영한다고 하면, 등록된 상품데이터가 빠르게 늘어남에 따라서 주문량은 더 더 더 더 더 더 빠르게 늘어날 것이다.
  • 어느 순간에는 SQL로 조회도 잘 되지 않고, 성능이 떨어지게 되겠지만 트래픽을 열심히 추적하지 않는다면 어느 순간 장애가 발생하게 될 수도 있다.
• 트래픽 양의 변화
  • 예전에는 12월 31일 24시가 되면, 다들 새해 인사를 보내려고 트래픽이 늘어나기 때문에 카카오톡 및 통신사 서비스가 굉장히 느려지는 경향이 있었다.
  • 배민의 경우에도 점심 저녁 시간이나, 월드컵과 같은 특수한 행사 때에 트래픽이 튀기도 한다.
  • 위처럼 예상 가능한 경우도 있지만, 지진 등 자연재해가 발생하는 경우에도 트래픽이 급격히 많아져서 서비스에 장애가 생기기도 한다.
• 새로 작성한 코드의 배포

 

참고: https://m.blog.naver.com/naver_search/221150527232

지진에도 흔들리지 않는 네이버 검색 시스템 - 1편

 

✔ 내 컴퓨터에서 잘 돌아가는 코드는 배포해도 잘 돌아갈까?

 

내가 작성한 코드가 안정적인지 어떻게 알 수 있을까?

일단 로컬, 개발 환경에서 기능을 테스트 해본다.

아마도 큰 규모의 서비스일 수록, 브랜치에 병합하기 전에 최대한 많은 테스트를 해보도록 노력할 것이다. 

하지만, 내 컴퓨터에서는 잘 작동하더라도 배포 서버에서 제대로 작동하지 않을 수도 있다.

 

운영 서버와 로컬 개발 환경이 비효율적인 경우도 있고, 환경을 통일하기 굉장히 어렵다.

내 컴퓨터와 운영 서버는 뭐가 다를까?

• 인프라 구성
  • 예를 들어서, 내 로컬에서와 달리 운영 서버에서는 데이터베이스를 여러 대의 서버에서 운영하기도 한다. 
  • 운영 서버의 데이터베이스는 읽기 전용과 쓰기 전용 데이터베이스를 별도로 운영하는 master-slave 구조라고 생각해 보자.
    • 내 로컬 데이터베이스에서 읽기와 쓰기를 동시에 할 수 있다.
    • 실제 운영 서버에서는 쓰기를 한 직후에 읽기 서버에 해당 변경 내용이 반영되기 전에 읽기 서버에 접근하게 된다면 부정확한 정보를 가져올 수 있다. 읽기용 데이터베이스를 구성할 경우에 반영 시간은 상황에 따라 다르다. (master slave db replication lack)
• 데이터의 양
  
  •  
• 트래픽의 양
• 엣지 케이스
  • 한 사용자의 주문 데이터가 몇 개 정도 될 것이라고 가정해서 API를 만들어 두었는데, 실제 운영 환경에서는 한 사용자가 몇만 개를 구매하는 경우가 있다.
    • 이럴 경우 자신의 주문 데이터를 조회할 때, 데이터베이스에도 부하가 생기고, 병목이 생길 수 있다.
  • 마이페이지에서 좋아요한 게시글을 보여주는 경우에도, 100개 정도 좋아요가 되어있다고 가정하고 만들 수 있다. 
    • 하지만, 모든 게시글에 좋아요를 누르는 사람도 있다. 
  • 엣지 케이스를 해소하는 방법으로는, 한 번에 데이터를 조회하는 경우에 리스트에 개수 제한을 두는 방법이 있을 수 있다. 

 

💋 재배포 및 배포 롤백의 필요성

 

코치 토미가 묘사해준 서비스 장애 시의 시뮬레이션을 들으면서 어쩌면 배포보다 중요한 것이 침착한 롤백일 수도 있겠다는 생각이 들었다. 

 

✔ 서비스 장애가 발생했을 때 시뮬레이션

실제로 장애가 나게 되면, 슬랙으로 온 회사 사람들이 이 기능 안된다고 연락이 오고, CTO가 자리로 찾아와서 뒤에서 팔짱끼고 있고, 모회사 n분째 서비스 장애와 같이 기사도 난다…… 되던 것도 안될 수 있는 손발이 달달달달 떨리는 상황이다…

따라서 배포와 롤백, 특히 롤백에 대해서는 굉장히 꼼꼼히 매뉴얼을 작성해 놓아서 아무리 긴장한 상태더라도, 팀 내 구성원 누구나 간단히 복사 붙여넣기 수준의 작업을 통해서 배포한 코드를 롤백할 수 있도록 해야 한다.

 

✔ 배포 전에 주의사항

코드 변경과 스키마 변경을 함께 하면 장애가 발생했을 때 대응하기 굉장히 힘들다. 
따라서 코드와 스키마는 별도로 배포하는 것이 좋다.

장애가 발생했을 때, 프론트엔드와 백엔드 중 어떤 것부터 롤백해야 고객이 불편을 겪는 상황이 줄어들 지에 대해서도 생각해봐야 한다. 현업에서는 중간에 문제가 발생했을 때 어떤 순서로 롤백을 해야 하는지에 대한 계획도 다 세우게 된다고 한다. 

배포를 하고 나서 문제가 생겨서 hotfix로 코드 변경을 통해서 해당 버그를 잡기로 결정을 했다고 하자.

그런데, 해당 문제를 해결하려고 하는 도중에 더 많은 에러가 올라오는 경우에는 어떻게 해야할까?

진짜 hotfix를 하게 되면 뒤에서 보는 사람도 많아지고, 장애 시간도 늘어나는 경험을 하게 된다.

이런 상황에서 롤백을 할 수 있도록, 롤백을 할 때 어떤 버전으로 롤백을 할건지 등도 지정해주면 좋다. 

롤백을 하려다가 실패하는 경우도 있다. 

현업에서도 장애가 그렇게까지 자주 발생하지는 않기 때문에 배포는 자주 하지만, 롤백을 자주 할 일이 없다. 

따라서 배포 관련해서는 계속해서 고도화가 되는데, 롤백에 관해서는 팀 내 구성원들의 지식이 멈춰있는 경우가 많다.

롤백도 주기적으로 해보면서 제대로 동작하는지 확인해 봐야 한다. 

무언가 변경할 때는, 늘 원상태로 복구할 수 있는 방법에 대해서도 고민해 봐야 한다.

 

💋 참고자료

• https://d2.naver.com/helloworld/2047663
• https://logicalread.com/mysql-replication-mc13/
• https://aws.amazon.com/ko/what-is/sre/
• https://bcho.tistory.com/1328