생활코딩_AWS) RDS

이번 수업(https://opentutorials.org/course/2717/11807) 관계형 데이터베이스 서비스(RDS)에 대해서 배웠다. 내가 로컬 호스트 환경에서 깔아서 하던 그 DB를 클라우드 상에서 제공하는 것이 핵심이다. 앞서 배운 S3는 파일 서비스를 클라우드화 한 것이고 지금 배운 RDS는 DB를 클라우드화 한 것이다. S3나 RDS나 모두 클라우드화 한다는 것에서 이점이 발생하기 때문에 상품성이 있는 것 같다. 클라우드화 하면서 여러가지 이점이 발생하고 관리상 용이함이 더 높아지기 때문이다. 아래는 aws에서 공식적으로 내놓은 RDS에 대한 설명 영상이다.

<생성>

생성하는 방법은 너무 간단해서 따로 포스팅 하지 않는다. 절차대로 따라가기만 하면 된다.

<백업 & 복원>

이건 다중 AZ배포를 yes 옵션으로 하고 DB를 만들었을 때 어떤 식으로 DB가 저장이 되고 백업이 되는지를 설명해주는 그림이다. 강의(https://opentutorials.org/course/2717/11809)에서 사용된 그림이다.  핵심은 저장을 하든 뭘 하든 준비된 또다른 DB에 똑같은 CUD를 하고 만일 하나가 죽었을 시에(어떤 이유에서든) 스탠바이 하고 있던 쌍둥이 DB를 바로 활용하는 것이다. 난 프리티어로 실습 중인데 프리티어 옵션만 보도록 활성화 했더니 다중 AZ는 선택되지 않도록 되어서 그냥 영상만 시청했다.

다른 백업 기능으로는 Snapshot이 있다. 원하는 시점에 Snapshot을 찍어서 해당 시점의 DB 상태를 저장해두고 원하면 이 상태로 DB를 되돌릴 수 있도록 하는 것이다. 게임으로 치자면 일종의 세이브 기능이라고도 할 수 있다. 보통 위험한 작업을 하기 직전에 Snapshot을 찍어 두고 문제가 생기면 그대로 다시 돌아간다고 한다.

강의에서는 군대에서 일간정비, 월간정비, 연간정비 등을 예시로 들며 체계적으로 사고를 방지하기 위해서 Snapshot을 정기적으로 찍기를 권하는데 매우 공감이 갔다. 돈이 드는 것도 아니고 시간이 오래 걸리는 것도 아닌데(즉, input은 적은데) 사고가 났을 시 탁월한 보험효과(즉, output은 매우 많다)를 누릴 수 있을 것 같다.

착각하지 말아야 할 것은 Snapshot을 복원할 시에 기존의 인스턴스가 그 시점으로 돌아가는 것이 아니라는 것이다. Snapshot을 복원을 한다는 것은 곧 그 시점의 정보로 새로운 인스턴스를 만드는 것과 같다.

특이한 점은 이미 만들어진 하나의 Snapshot이 있었다는 것인데 이유는 DB를 만들때 자동 백업 기능을 설정해뒀었기 때문이었다. 미리 aws에서 백업을 해주기 위해서 Snapshot을 마음대로 찍어두었던 것이다.

<Scale-Up>

무지무지 간단하다. 인스턴스 수정에 들어가서 DB 인스턴스 클래스를 변경하면 된다. 변경하고 바로 적용하고 싶으면 유지 탭에서 바로 적용을 하면 되고 그게 아니라면 원하는 시각을 유지 탭에서 설정하면 된다. 강의에서는 7분~10분 정도 서비스가 되지 않을 수도 있다고 했다.

하지만 Scale-Up의 단점은 언젠가는 한계에 도달한다는 것이다. 이 말인즉 트래픽이 최고 사양으로 해도 감당이 버거울 정도로 많다는 말인데 흠, 아주 기쁜 한계인 것 같다. 이 때에 사용해야 할 것이 Scale-Out이다.

<Scale-Out>

한 대의 컴퓨터로 감당할 수 없는 요구를 여러 대의 컴퓨터가 분담하여 성능을 향상시키는 방법을 말한다.  Scale-Out시 유의할 점은 DB를 나눠버리면 공통된 DB를 사용하지 않음으로써 데이터의 불일치가 발생하는 것이다. 따라서 여러 대의 컴퓨터를 사용하되 master 컴퓨터를 하나 두고 그 외의 컴퓨터를 slave로 둔 뒤 빠르게 master의 데이터를 동기화해서 slave들이 가져가도록 하여 이러한 문제를 해결한다. 즉, CRUD 중 C, U, D는 오직 master 컴퓨터만 처리하고 R은 slave 컴퓨터들이 나눠서 감당하는 것이다.

그런데 여기서도 결국 master가 혼자 부담을 하기에 한계가 오는데 이 때에는 Sharding이라는 기법을 쓴다고 한다. 1번~100번 사용자는 어떤 인스턴스, 101번 ~ 200번 사용자는 어떤 인스턴스 와 같이 사용자를 나누는 것이 핵심이다.

Scale-Out도 Scale-Up처럼 간단하다. 인스턴스를 누르고 '읽기 전용 복제본 생성'을 하면 읽기 전용의 인스턴스가 생성된다. 그래서 애플리케이션을 만들 때에 Read외 모든 작업은 master와 연결하고 Read작업은 만들어진 복제본에 연결하면 Scale-Out을 구현할 수 있다.