AWS의 DB 관련 서비스에 대해서 알아본다. RDS, Cache, NoSQL 등이 AWS에서는 어떻게 쓰이는지 이해를 목표로 하며, DynamoDB 빼고는 DB관련 모든 기술을 다룰 수 있도록 한다.
RDS
여러 관계형 데이터베이스들(MS, Oracle, MySQL, Maria, PSQL)을 지원한다. 기본 운영체제에 대한 패칭과 자동 프로비져닝을 해주고, 지속적인 백업과 특정시점에 대한 복구를 가능하게 한다. 대시보드 모니터링을 지원하고, 읽기 성능을 위한 복제본 설정이 있다. 재해 대비에 복구가 가능하고, 수평, 수직적인 확장이 가능하다. EBS를 기본 스토리지로 삼으며, SSH로는 접근이 불가하다.
백업
트랜잭션 로그가 5분마다 백업되어서 어느 시점이든 롤백이 가능하고, 자동백업 기능을 7 ~ 35일까지 설정할 수 있다. 스냅샷으로 저장해 놓을 수도 있는데, 이 스냅샷은 기간에 구애받지 않고 유저가 직접 저장해 놓은 시점의 스냅샷이라, 그 시점으로 돌아갈 수 있다.
복제
DB를 복제하는 주요한 이유는 성능과 백업이다. 그렇기 때문에 복제는 백업 파트에 넣을 수도 있지만, 성능까지 올려주는 것이 복제기 때문에 따로 두었다.
읽기전용 복제
DB의 레플리카를 만드는 것이다. 그리고 그 레플리카 DB는 유저가 읽기만 가능하다. 즉, 데이터를 저장할 수 있는 DB는 마스터 DB 하나만 가지고 많은 읽기 요청을 분산시킬 수 있도록 읽기 전용 DB를 따로 만드는 것이다. RDS는 5개까지 레플리카를 둘 수 있고, region, zone에 관계 없이 읽기전용 DB를 만드는 것이 가능하다. 서비스의 정책에 따라 zone, region에 저장하는 것을 다르게 두고, 일반적으로는 같은 zone에 둔다. 네트워크 비용은 동일한 리전내에서는 트래픽 비용은 무료이지만 크로스리전인 경우 네트워크 비용 발생한다.
읽기전용 복제는 일관적이면서 비동기적으로 적재된다. 그렇기 때문에 사용자 입장에서 저장한 데이터에 대해 시간 차가 날 수 있다. 그리고 데이터를 쓸 수 있는 마스터 DB가 죽으면 읽기전용 DB가 그 자리를 대신할 수 있다.
스탠바이 복제
스탠바이는 읽지도 않고, 쓰지도 않는 DB이다. 무조건 마스터DB와 같은 데이터로 만들어지고, 사용자는 사용할 수 없다. 진정한 재해 복구를 위한 백업 DB라고 생각하면 된다. 해당 DB는 다중 AZ를 통해서 다른 zone에 놔두며, 해당 zone에 이상현상이 생겼을 경우, 다른 zone에 있는 DB 데이터를 불러오기 위함이라고 생각하면 된다. 얘는 동기복제로 읽기전용의 비동기복제랑은 다르다.
Auto Scaling
데이터베이스에 용량이 부족해지면 자동으로 오토스케일링해준다. 스토리지 확장하는 오토스케일링의 최대 값을 설정해둘 수 있다.
암호화
마스터 DB를 암호화 안하면 복제본도 암호화 불가능하다. 그렇기 때문에 스냅샷도 암호화되지 않고 저장되며, 암호화 안된 RDS를 암호화하려면 스냅샷을 뜬 후, 그 스냅샷을 복제하면서 암호화하고, 암호화된 스냅샷을 다시 활성화한다. 그리고 기존의 RDS를 지우는 방식으로 가능하다.
전송 암호화(SSL)도 시켜야하는데 이는 각 DB별로 설정(Application Level)을 해주어야 한다.
보안
프라이빗 서브넷에 배포하는 것을 원칙으로 하고, 보안 그룹을 통해 보호한다. 액세스 관리는 IAM으로 할 수 있고, 해당 인증은 PSQL과 MySQL만 지원하며, 15분의 인증시간을 가지는 토큰을 바탕으로 통신한다. 이렇게 하는 이유는 네트워크가 인/아웃으로 SSL 설정이 가능하고, DB대신 IAM이 사용자를 관리해서 중앙집중화 관리전략을 가져가며, 다른 서비스와 결합시키기가 쉽다. 다른 DB 종류는 기존의 사용자, 암호를 사용하면 된다. 물론 PSQL과 MySQL도 사용자, 암호로 사용가능하다.
Aurora
PSQL, MySQL과 호환되는 AWS의 독자적인 DB이다. 클라우드에 최적화되어 있어 MySQL보다 5배 성능 PSQL 보다 3배 성능 이상을 가지며, 읽기 전용 DB도 15개 까지 가질 수 있고, 복제속도도 빠르다. 장애조치도 Mysql의 멀티 AZ에서 장애 조치보다 훨씬 빠를 정도로 즉각적이며, 규모면에서 효율적이라 비용절감도 가능하다. 물론 기본적인 사용량에 대한 비용은 RDS보다 20% 비싸긴한데, 쓰는만큼 나가는 구조라 RDS(용량 설정해야 함)보다 절감이 가능한 것으로 보인다. 오로라 스토리지는 자동적으로 계속 늘어난다. (10GB부터 64TB까지) 일부 데이터가 손상되어도 P2P 복제로 자가 복구 하며, 100개 이상의 볼륨을 통해 재해대비도 가능하다. 또한, 멀티 마스터 DB도 가능하다. (데이터 쓰기를 여러 개로 한다는 말)
RDS의 업그레이드 버전이라고 보면 된다.
Cache
Redis, MemCached 같은 캐시기술 서비스가 있다. Redis는 RDS와 비슷하게 멀티 AZ도 가능하고, 읽기전용 DB도 만들어지고, 백업 등을 지원한다. 하지만 MemCached는 백업 불가에, 지속성도 없고, 고가용성도 불가능하다. 단순한 분산캐시용으로 샤딩으로 데이터 저장을 한다.
레디스 클러스터는 5개까지 레플리카 DB를 지원하고, 클러스터 당 샤드가 500개까지 가능하다. 즉, 레플리카가 4개이고 마스터가 1개이면 각 100개씩 샤드 분할을 진행한다.
캐시 방법
레이지 로딩
캐시 데이터확인 -> 없으면 RDS 요청 -> 요청된 데이터를 캐시하는 형식을 말한다. 즉, 우리가 OS 시간에 배웠던 캐시와 똑같다. 이건 힛률이 저조하면 그냥 깡통이 되어버린다. 그렇기 때문에 힛률에 대해서 되게 조심하도록 어플리케이션 단에서 코드를 잘 짜야한다.(힛을 안하게 될 경우 네트워크 1번 타는게 3번타는 형식이 되어버리기 때문이다.)
이 방식의 안 좋은 점은 예전 데이터가 보일 수 있다는 점이다. 힛을 해서 계속해서 캐시데이터가 삭제되지 않고 남아있다면 예전 데이터가 계속해서 보일 수도 있다. 이 때문에 캐시 삭제에 대한 전략(LRU, TTL 등)이 나온다.
라이트 스루
이 방법은 캐시 이용의 첫 번째 방법으로 쓰진 말고 레이지로딩과 같이 쓸 방법을 고민해봐야 한다. 데이터베이스가 캐시에 업데이트 될 때 캐시에도 업데이트 해 놓는다. 즉, 최신 데이터가 캐시되는 것이다. 해당 방법은 write에 좀 더 시간이 오래걸린다는 단점이 있다.
캐시 삭제
모두 잘 아는 최근에 안 쓴 캐시데이터 삭제 방법인 LRU 방식이 있다. 또한 TTL을 설정해 놓고 시간에 따라 삭제해버리는 경우도 있다. 요즘은 TTL은 무조건 설정해 놓고 LRU를 추가하는 형식으로 사용하는 것 같다.
