[중요][AWS] 잘 사용하고 있던 DB가 갑자기 중지된다고? - AWS RDS DB 인스턴스 유지 관리 !!

 

 

안녕하세요. 이번에는 서비스를 운영하면서 겪었던 아주 초보적인 실수로 심각한 문제를 야기할 수 있었던 경험을 공유드리려고 합니다.
 
AWS RDS의 DB 인스턴스 유지 관리 기능을 무심하게 넘겼던 것이 원인이었는데 이참에 제대로 알게 되었습니다 ㅜㅠ

여러분은 이런 초보적인 실수 하지 마세요ㅋㅋㅋ쿠...

TL-DR

• DB 유지 관리 기능을 사용할 때에는 서비스 정기 점검 시간을 활용할 것
• 혹은 blue-green 배포를 이용해서 DB 업데이트로 인한 다운 타임을 최소화할 것
• DB 인스턴스 백업도 DB 성능에 영향을 줄 수 있으므로 서비스 운영 시간을 피할 것(벤치마크는 없음)
• 아무런 조치 없이 무중단 인스턴스 업데이트를 지원하는 것은 굉장히 어려움. 이상하다 싶으면 조금 더 알아볼 것!

---

1. Amazon RDS DB 인스턴스 유지 관리 기능을 아시나요?

AWS 콘솔에서 RDS DB 인스턴스를 살펴보면 '유지 관리 및 백업'이라는 항목이 있습니다.

DB 인스턴스 유지 관리 기능

딱 여기까지만 보고 '오 자동으로 업데이트 되는 건가? 좋은 기능이네! 무조건 활성화 해야지' 하고 넘어간 것이 화근이었습니다.

2. 서비스 오전 운영 시작 15분 전에 갑자기 데이터 조회가 안된다;;;

 문제가 발생한 그날도 여느 날과 다름없이 평범한 날이었습니다. 오전 점검도 무난하게 끝나고 여유롭게 모니터링을 준비하고 있었습니다.

그러던 중 불길한 소리가 제 오른쪽 귓구멍에 들려옵니다.
"어? 데이터 조회가 안 되는데요?"

처음에는 서비스가 스케일아웃 되는 매우 극초기에 요청을 처리하지 못하는 엣지 케이스인 줄 알았지만 현상이 몇 분 간 지속되는 것을 보자 분위기가 심각해졌습니다.

저희 제품은 사용자에게 현재 상태를 보여주고, 기능을 계속해서 진행시키기 위해서 주기적인 데이터 조회가 필수적입니다.
데이터 조회에 실패하면 기능이 정지되어 고객이 제품을 사용할 수 없게 되는 심각한 상황이 야기될 수 있습니다.

다행히 데이터 조회가 되지 않는 문제는 별다른 조치 없이 해소되었지만 실서비스 운영 중이기에 문제의 원인을 파악하고 재발하지 않을 것이라는 확신을 가져야 합니다.

서비스 상태, 로그, 캐시 상태, DB 상태 등 시스템 전반적인 정보를 살펴보고 나서야 원인을 알아낼 수 있었습니다.

• 그리고 문제가 재발하지 않을 것이라는 확신도 얻을 수 있었습니다!

 

 

3. DB 인스턴스가 업데이트될 때는 DB 인스턴스가 잠시 정지될 수 있다...

원인은 생각보다 단순했습니다. 바로 DB 인스턴스가 업데이트되면서 잠깐 정지된 것이 문제의 원인이었습니다.

처음에는 서비스 상태, 캐시 상태, DB 상태, 로그에서 이상을 찾을 수 없어서 많이 헤맸지만
문제가 발생한 시간대와 DB 유지 관리 기간이 일치한다는 것을 발견할 수 있었습니다.

DB가 업데이트 되면서 서비스와 DB와의 연결이 끊긴 것으로 추정했습니다.

실제로 서비스 로그와 DB 로그에서 DB 인스턴스가 종료되었다는 것을 확인하였고, DB 유지 관리 기능을 비활성화하는 것으로 상황을 일단락 지었습니다.

P.S.
'AWS는 기본으로 DB 인스턴스 무중단 업데이트를 지원해 주는구나' 같은 잘못된 생각을 고칠 수 있었습니다.

 

 

4. RDS의 DB 유지 관리 기능 제대로 검토하기

일단 문제는 해결되었지만 DB 유지 관리 기능이 정확히 뭔지도 모르고 계속 비활성화시켜 놓는 것은 미봉책일 뿐입니다.
 
DB 유지 관리 기능이 무엇을 하고 어떤 리스크가 있고 어떤 best practice가 있는지 한번 제대로 검토하기로 했습니다.

4.1. Basic of DB 유지 관리

DB 유지 관리 중에는 인스턴스가 실행되고 있는 하드웨어, 인스턴스의 운영 체제, DB 엔진 버전이 업데이트 될 수 있습니다. 그리고 업데이트 동안에는 DB 인스턴스가 잠시 동안 중지될 수 있습니다.

혹시 '다중 AZ를 사용하면 다운 타임 없이 업데이트가 되지 않을까?' 라고 생각하셨나요?

다중 AZ를 사용하고 있는 상태에서 DB 인스턴스를 업데이트 한다면
모든 AZ의 DB 인스턴스가 동시에 업데이트 되서 다운 타임이 발생합니다!

 
그러면 'DB 유지 관리를 비활성화 시키고 처음 버전 그대로 쓰면 되는 거 아니야?'라고 생각하실 수 있지만 보안 및 인스턴스 안정성과 관련된 패치가 필요할 때가 있습니다.
 
DB 유지 관리를 비활성화 하더라도 DB 인스턴스의 업데이트가 필요한 순간은 오게 되고, DB의 다운 타임을 해결해야만 합니다.
 

• 참고 링크: Amazon RDS DB 인스턴스 유지 관리

 

 

4.2. DB 업데이트 중 다운 타임을 어떻게 해소할 수 있을까?

어떻게 하면 DB 업데이트로 인한 다운 타임을 없앨 수 있을까요?
 

4.2.1. 서비스 정기 점검 시간

조직에서 가장 먼저 시도할 수 있는 방법은 서비스 정기 점검 시간을 이용하는 것입니다.
고객들에게 서비스 정기 점검 시간을 공지하고, 해당 시간 동안은 서비스 점검을 위해서 고객들의 제품 사용을 잠시 동안 제한하는 것이죠.
 
생활 속에서는 뱅킹 서비스에서 많이 볼 수 있는 정책이고, Session time이 매출에 큰 영향을 주지 않는 서비스들이 사용합니다.

• 쇼핑몰, 광고 플랫폼, 게임처럼 Session time이 매출에 직접적으로 영향을 주는 경우에는 아주 큰 문제가 있지 않는한 서비스 점검 시간을 갖지 않습니다.

제품의 BM이 서비스 정기 점검 시간에 영향을 받지 않는다면 추가해보는 것도 좋은 방법입니다.

4.2.2. blue-green 배포

서비스 정기 점검 시간이 운영 단계의 해결책이었다면 blue-green 배포는 기술적인 해결책입니다.
 
일반적으로 blue-green 배포는 기존에 실행되고 있던 서비스(blue)들을 동일한 구성을 가지고 있는 새로운 버전의 서비스(green)으로 점진적으로 바꾸는 것을 뜻합니다.
 
DB 인스턴스 업데이트의 다운 타임을 개선하기 위해서 다음과 같이 blue-green 배포를 활용합니다.

1. blue 환경에서 실행되고 있는 DB 인스턴스를 복사하여 green 환경에 생성됩니다.
2. green 환경에서 생성된 인스턴스에서 필요한 업데이트가 이뤄집니다.
3. green 환경 DB 인스턴스의 업데이트가 완료되면 blue 환경과 green 환경을 바꿉니다.

P.S.
하지만 blue-green 배포를 활용하더라도 다운 타임이 없는 것은 아닙니다.
blue 환경의 인스턴스가 사용하던 엔드포인트를 green 환경의 인스턴스가 사용하려면 서로 리소스 ID를 바꿔야 하는데 여기서 다운 타임이 생기게 됩니다.

+++ DB 백업도 성능에 영향을 주는 거 아니야?

DB 유지 관리 기능을 알아보니 DB 자동 백업 기능도 제품에 영향을 주지 않을까 걱정이 되었습니다.

• DB 백업이 DB 인스턴스를 중단시키지는 않겠지만 읽기/쓰기 성능에 영향을 끼칠 수 있을 것이라고 생각했습니다.

하지만 생각과는 다르게 DB 자동 백업 기능으로 인해 문제를 경험한 적이 없었고, 인터넷에서도 구체적인 사례를 찾지는 못했습니다.
 
그나마 찾은 내용은 AWS 공식 문서로 DB 백업을 위해서 스냅샷을 생성하는 동안 DB I/O에 지연 시간을 발생시킬 수 있다는 것이었습니다.
적게는 밀리초에서 크게는 수초까지도 걸릴 수 있다고 하는데 실제로 테스트 해볼 수 있으면 좋겠네용...!

• 참고 링크: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html

Managing automated backups - Amazon Relational Database Service

 

 

출처 : https://goodahn.tistory.com/195