RDS 와 Aurora 의 보안, RDS Proxy, ElastiCache

RDS와 Auroa 의 보안

• RDS 및 Aurora 의 DB 는 저장된 데이터를 암호화할 수 있다.
  • 이는 데이터가 볼륨에 암호화 된다는 뜻
  • KMS 를 사용해 마스터와 모든 복제본의 암호화가 이루어지며, 이는 DB를 처음 실행할때 정의된다.
  • 어떤 이유에서든 마스터 DB를 암호화하지 않았다면 -> 읽기 전용 복제본을 암호화할 수 없다.
  • 암호화 X 인 기존 DB를 암호화 하려면 암호화 X DB의 DB SnapShot을 가지고 와서 암호화된 DB 형태로 DB SnapShot 을 복원해야한다. 
    -> 따라서 스냅샷 생성 및 복원 작업을 거쳐야 한다.

저장 데이터 암호화

• 클라이언트와 DB 간의 전송 중 데이터 암호화가 있다고 가정
• 그러면 RDS 및 Aurora의 각 데이터베이스는 기본적으로 전송 중 데이터 암호화 기능을 갖추고 있다.
  • 따라서 클라이언트는 AWS의 TLS 루트 인증서를 사용해야 한다.
    1. 사용자 이름과 패스워드의 조합으로 사용해서 DB 인증 가능
    2. IAM 역할을 사용해서 DB 인증 가능
    -> 보안 그룹을 사용하여 DB에 대한 네트워크 액세스를 통제할 수도 있다.( 특정 포트, IP, 보안 그룹을 허용하거나 차단할 수 있다.)
• RDS 와 Aurora에는 SSH 엑세스가 없다. -> 관리형 서비스가 있기 때문 + RDS 커스텀 서비스를 사용하면 예외
• Audit Logs (감사 로그) 가 있어서, 시간에 따라 어떤 쿼리가 생성되고 있는지 DB 를 확인하려면 감사 로그 작성을 활성화 하면 된다.
  -> 로그는 시간이 지나면 자동으로 삭제되며, 장기간 보관하고 싶다면 AWS CloudWatch Logs 라는 전용 서비스로 전송해야한다.

 

RDS Proxy

• VPC 내에 RDS DB 를 배포할 수 있는 것 처럼, RDS Proxy 도 배포가 가능하다.
  -> RDS DB 에 바로 액세스 하면 되는데, 왜 프록시가 필요할까??
• RDS Proxy 를 사용하면 애플리케이션 데이터베이스 내에서 DB 연결 풀을 형성하고 공유할 수 있다.
• 즉, 애플리케이션을 RDS DB 인스턴스에 일일이 연결하는 대신 Proxy 에 연결하면 Proxy가 하나의 풀에 연결을 모아 RDS DB 인스턴스로 가는 연결이 줄어든다. --> 왜 이렇게 할까??
  • RDS DB 인스턴스에 연결이 많은 경우 CPU, RAM 등 DB 리소스의 부담을 줄여 DB 효율성을 향상시킬 수 있고, DB에 개방된 연결과 시간초과를 최소화할 수 있기 때문이다.
• 즉, RDS Proxy 는 완전한 Serverless로 Auto Scaling 이 가능해 용량을 관리할 필요가 없고 가용성이 높다. + 다중 AZ도 지원 
• RDS DB 인스턴스에 장애 조치가 발생하면 기본 인스턴스가 아니라 대기 인스턴스로 실행되어 RDS Proxy 덕분에 RDS 와 Aurora의 장애 조치 시간을 66% 까지 줄일 수 있다.
  • 즉, 장애 조치를 각자의 인스턴스가 처리하는 대신 장애 조치와 무관한 RDS Proxy에 연결하는 것이다.
  • RDS Proxy 가 장애 조치가 발생한 RDS DB 인스턴스를 처리하므로 장애 조치 시간이 개선된다.

RDS Proxy 예시

 

 

 

ElastiCache

• RDS 가 관계형 데이터베이스를 관리하는 것과 같은 방식이다.
• ElastiCache 는 캐싱 기술인 Redis 또는 Memcached 를 관리할 수 있도록 도와준다.
  
  • 캐시: 매우 높은 성능과 짧은 지연 시간을 가진 In-Memory 데이터베이스 + 읽기 집약적인 워크로드에서 DB의 로드를 줄여준다.
  • 일반적인 쿼리는 캐시에 저장되므로, 매번 데이터베이스를 쿼리하지 않아도 된다. -> 캐시만 사용하여, 쿼리를 검사할 수 있다
  • 캐시 = Stateless 즉, 상태 비저장형으로 할 수 있게 도와주는 것이 ElastiCache다.
  .
• AWS 는 DB 운영 체제를 유지 관리할 수 있다. -> 패치, 최적화, 설정, 구성, 모니터링, 장애 복구, 백업 등

 

ElastiCache 를 사용하기 위한 아키텍처

• ElastiCache, RDS DB, 애플리케이션이 있다고 가정
  • 애플리케이션은 ElasticCache 를 쿼리한다. -> 쿼리가 이미 발생했는지 확인하려고, 이미 발생하여 ElasticCache 에 저장되어 있다면, 캐시 히트라고 한다. ElastiCache 에서 답을 가져오는 것
  • 캐시 미스가 발생한다면, DB 에서 데이터를 가져와야한다.
  • 다른 애플리케이션이나 다른 인스턴스에서 같은 쿼리가 발생하면 데이터를 캐시에 다시 쓸 수 있다. 
  • 이렇게 캐시에 저장하면 RDS DB 의 로드를 줄이는데 도움이 된다. 
    -> 이를 사용하기 위해서는 캐시 무효화 전략이 있어야 한다. 왜냐하면, 가장 최신 데이터만 사용되어야 하기 때문

Cache 하는 예시

• 사용자가 세션을 저장하여 애플리케이션을 Stateless 로 만들기
  • 사용자가 어떤 애플리케이션에 로그인하면, 애플리케이션이 세션 데이터를 ElastiCache 에 쓰는 것
  • 사용자가 애플리케이션의 다른 인스턴스로 리디렉션되면, 애플리케이션은 그 세션의 세션 캐시를 ElastiCache에서 직접 검색할 수 있으므로, 사용자는 여전히 로그인 상태다. 즉, 다시 한번 더 로그인할 필요가 없다.
  • 즉, 애플리케이션을 Stateless 로 만들어서, 사용자의 세션 데이터를 ElasticCache에 기록한다.

애플리케이션 Stateless 예시

 

 

Redis 와 Memcached 의 차이

• Reids
  • 자동 장애 조치 기능이 있는 다중 AZ 가 있고, 읽기 복제본이 있다. 
  • 읽기를 확장하고 고가용성을 가지며, RDS 와 매우 유사하다.
  • AOF 지속성을 이용한 데이터 내구성이 있으며, 백업 및 복원 기능이 있다.
  • Redis = 데이터 내구성에 대한 것, 기능 면에서는 캐시로서 세트및 정렬된 세트를 지원한다.
  • 즉, Redis 는 가용성과 내구성이 뛰어난 복제되는 캐시
• Memcached
  • 데이터 분할을 위해 멀티 노드를 사용한다. -> 이를 샤딩이라고 함.
  • 고가용성이 없고 복제가 일어나지 않으며, 영구 캐시가 아니고 백업 및 복원도 없다.
  • 멀티스레드 아키텍쳐이다.
  • Memcached = 여러 인스턴스가 모두 샤딩을 통해 작동한다.
  • 즉, Memcached 는 분산되어 있는 순수한 캐시이다. -> 데이터가 손실되어도 괜찮으며, 백업과 복원기능도 없다.