RDS 프록시에 관해 얘기하겠습니다
먼저 RDS 프록시가 왜 필요한지 이해해야 합니다
Lambda 함수가 있고 RDS 데이터베이스에
접근하고자 하면 기본적으로
실행을 할 때 함수는 VPC
밖에서 실행될 것입니다
AWS 소유의 VPC입니다
따라서 공개 서브넷에 없는 리소스에
접근할 수 없습니다
비공개 RDS 데이터베이스나
비공개 ElastiCache 또는 개인 내부 ELB가 있으면
접근이 안됩니다
기본값인 Lambda 배포를 이용하여 Lambda는
공용 엔드포인트나 DynamoDB와 통신할 수 있습니다
그러나 비공개 RDS가 있는 비공개 서브넷이 있으면
Lambda는 이것에 연결할 수 없습니다
RDS 데이터베이스를 공개한다면 당연히
Lambda 함수와 연결할 수 있지만
RDS 데이터베이스를 비공개 서브넷에서
생성하는 것만큼 안전하진 않습니다
이제 VPC에서 Lambda를 시작할 수 있습니다
그러기 위해서는 VPC ID, 서브넷과 보안 그룹을 정의해야 합니다
그러면 Lambda는 서브넷에서 탄력적 네트워크 인터페이스를 생성해
RDS 데이터베이스에 직접 연결합니다
이 ENI를 생성하려면 IN 역할을 지정해야 합니다
그러면 Lambda는 비공개 서브넷 내에서
자체 보안 그룹을 가진 ENI에
연결할 수 있게 됩니다
Lambda는 이 ENI에 직접 연결을 설정합니다
그러면 이 ENI는 RDS 데이터베이스에 직접 접근합니다
이것을 작동하려면 보안 그룹을 몇 개 설정해야 합니다
그래야 연결이 가능합니다
이것으로 여러분의 VPC에 Lambda 기능을 배포하고
RDS 데이터베이스의 비공개 리소스에 접근할 수 있습니다
이로써 잠시 동안은 작동하겠지만 Lambda 함수가
RDS에 연결하면
데이터베이스 연결을 열고 유지할 것입니다
동시에 여러 Lambda 함수 인스턴스가 있는 경우
RDS 데이터베이스에
많은 연결을 열 수 있는데
이것은 RDS 데이터베이스에서 TooManyConnections 예외를 초래할 수 있습니다
너무 많은 연결이 열려 있기 때문입니다
특히 Lambda 함수가 연결을 제대로
정리하지 못한다면 더 발생할 수 있습니다
그렇다면 RDS 프록시라는 것을 배포할 수 있습니다
RDS 프록시를 이용하면 유휴 연결을 제거기 위해 코딩할 필요가 없습니다
RDS 프록시는 RDS 데이터베이스에 연결된
연결 풀을 관리합니다
예를 들어, 비공개 서브넷의 VPC에 RDS 데이터베이스가 있으면
RDS 프록시를 이 비공개 서브넷이나 다른 서브넷에
배포할 수 있습니다
공개 서브넷도 가능하며
서브넷들이 연결만 되어있으면
문제 없습니다
이 예제에서는 제가
공개 서브넷에 RDS 프록시를 표시했습니다
그런 다음 Lambda 함수들을 설정하면
이 함수들이이 RDS 프록시에 직접
연결할 수 있습니다
이 예제에서
Lambda 함수는 공개 서브넷의 RDS 프록시에
연결돼 있으므로 VPC 연결은 필요 없습니다
그러나 RDS 프록시가 비공개 서브넷에 있다면
Lambda 함수 또한 비공개 서브넷에
배포해야 합니다
도표에서 보이듯이
Lambda 함수들은 RDS 프록시에 5개의 연결을
설정하고 있는데
RDS 프록시는 연결 풀링이라는 것을 통해
RDS 인스턴스에 연결 하나만 설정하고 있습니다
이로써 TooManyConnections 예외를 피하게 해주는 것입니다
Lambda 함수들이 프록시와의 연결을
정리하지 않더라도 괜찮습니다
프록시가 이것을 처리할 줄 알기 때문에
잠시 후 유휴 연결을 닫습니다
이 방법론에는 IAM
인증을 지원합니다
그러므로 프록시에서 RDS 데이터베이스 인스턴스로
IAM 세부정보를 전달할 수 있습니다
또한 사용자 이름과 암호를 사용한 데이터베이스
인증도 지원합니다
RDS 프록시에 연결이 많이 설정될수록 더 확장되기 때문에
RDS 프록시 레이어의 자동 스케일링이 있습니다
앞서 말했듯 Lambda 함수는 프록시에
연결되어야 합니다
따라서 공개 서브넷과 공개 프록시가 있다면
공개 Lambda 함수나 적어도 일반적으로 배포된
Lambda 함수가 있으면 됩니다
비공개 RDS 프록시가 비공개 서브넷에 배포됐다면
당연히 VPC에 Lambda 함수를
배포해야 합니다
RDS 프록시 덕분에 TooManyConnections 오류를 피할 수 있습니다
프록시를 생성하는 방법을 살펴보겠습니다
프록시를 생성하는 옵션을 보여드리겠습니다
여기 옵션이 있습니다
프록시 자체를 바로
생성하지는 않겠습니다 돈이 들기 때문입니다
그러나 적어도 옵션은 보여드릴 수 있습니다
DemoProxy라고 이름을 짓고
다음은 Engine compatibility인데
MySQL인지 Postgres인지
또한 전송 중 암호화를 하려면 TLS가 필요합니다
그리고 Idle client connection timeout이 있습니다
이것은 프록시 자체가 연결 정리를 어떻게 처리하는지
보여줍니다
몇 분에서 8시간 까지 설정 가능합니다
여기는 30분까지 설정했습니다
그 말은 애플리케이션이 30분 이상
연결을 사용하지 않았다면 그 연결을
지우라는 의미입니다
프록시는 똑똑해서 최종 데이터베이스를 과부하시키지 않고
직접 정리할 수 있습니다
그런 다음 Database를 선택하고
Connection pool maximum connections를 지정합니다
프록시에서 주 데이터베이스까지 허용되는
최대 비율을 의미합니다
여러분의 데이터베이스에 직접 연결이 있다면
80%가 적당하겠지만
데이터베이스를 프록시에만 연결할 경우
100%까지 가능해야 합니다
다음은 Connectivity입니다
RDS 프록시는 데이터베이스에 연결할 수 있어야 합니다
이를 위해서는
Secrets Manager에서 데이터베이스에 대한
secret을 생성해야 합니다
그래서 Create a new secret으로 갑니다
비싸지는 않은데 비밀 하나당 한 달에
40센트가 듭니다
30일 시험 사용이 가능하긴 하지만 돈이 좀 듭니다
생성한다면 유형은 Credentials for RDS database고
사용자 이름과 암호를 지정하게 됩니다
암호는 여기 있습니다
이 암호는 보여드리기 위한 것입니다
그 다음 이 내용은
이 데이터베이스와 관련 있다고 지정합니다
제가 하려는 것은 아니지만
여러분에게 비밀을 어떻게 생성하는지
보여드렸습니다
그 비밀은 여기서 RDS 프록시에 의해 사용될
수 있습니다
다음은 IAM role이 필요합니다
프록시가 Secrets Manager로부터
비밀에 접근할 수 있도록 하기 위해
IAM role을 생성해야 합니다
그런 다음 사용자가 프록시에 어떻게 연결할지 지정합니다
IAM authentication을 사용할 수도 있고
MySQL과 RDS와 같이 사용자 이름과
암호를 사용할 수도 있습니다
따라서 IAM 인증을 활성화하거나 비활성화할 수 있습니다
다음은 Subnets인데
데이터베이스 프록시를 어디에 배포할지입니다
여기서 원래 데이터베이스와 다른
공개 또는 비공개 서브넷에 생성할 수 있고
여러분의 프록시가 RDS 데이터베이스에 연결할 수 있게 하는
보안 그룹도 설정할 수 있습니다
끝으로 데이터베이스로 통과되는
모든 쿼리에 대한 로깅을 활성화할 수 있습니다
하지만 24시간 후에는 비활성화 됩니다
프록시가 느려지기 때문입니다
여기까지가 모든 옵션입니다
프록시가 생성되면
연결 URL을 제공하며 애플리케이션이나
Lambda 함수에 이것을 즉시
활용할 수 있습니다
이번 강의는 여기까지입니다 마음에 드셨으면 좋겠습니다
다음 강의에서 뵙겠습니다