AWS Lambda RDS Connection

BackEnd_Ash.log·2023년 11월 2일
awslambda
0

AWS람다

목록 보기
1/1

AWS Lambda는 유용한 서비스이다.
비용적인 측면에서도 유용하고 ,
사용적인 측면에서도 손이 많이 가지 않는다.
설정하는것도 간편하고 배포측면에서도 간편하게 배포가 가능하다.

하지만 Lambda 를 사용할때 서버가 down 됐었다.
그당시 대표님과 이사님이 등 뒤에 오셔서 제 모니터를 보고 계시는데
어.........기억하기 싫다

AWS Lambda 는 서버리스 서비스이다.
서버리스라고 해서 서버가 정말 없는것이 아니라
AWS에서 서비스가 실행될 인프라를 관리하므로 사용자가 관리할 서버가 없다는거다.

람다를 사용하게 되면 4가지 장점을 얻을 수 있다.

  • 보안
  • 비용
  • 가용성
  • 확장성

Lambda 함수

Lambda API Gateway

Api Gateway 는 사용자로부터 HTTP 요청을 받으면 GET 과 같은 HTTP 메서드나 /api 등의 요청 경로에 대한 정보가 포함된 JSON 데이터를 Lambda 함수에 전달한다.

API Gatewa도 서버리스 서비스 이므로 사용자는 서버를 구축하지 않고도 웹 응용 프로그램을 만들 수 있다.

API Gateway and AWS Lambda

const Responses = require('./API_Responses');

exports.handler = async event => {
    console.log('event', event);

    if (!event.pathParameters || !event.pathParameters.ID) {
        // failed without an ID
        return Responses._400({ message: 'missing the ID from the path' });
    }

    let ID = event.pathParameters.ID;

    if (data[ID]) {
        // return the data
        return Responses._200(data[ID]);
    }

    //failed as ID not in the data
    return Responses._400({ message: 'no ID in data' });
};

const data = {
    1234: { name: 'Anna Jones', age: 25, job: 'journalist' },
    7893: { name: 'Chris Smith', age: 52, job: 'teacher' },
    5132: { name: 'Tom Hague', age: 23, job: 'plasterer' },
};

lambdas 폴더에

API_Responses.js 파일을 만들어 준다.

위는 200 일때의 규격화를 한것이고 400 일때도 작성해준다.

const Responses = {
    _200(data = {}) {
        return {
            headers: {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Methods': '*',
                'Access-Control-Allow-Origin': '*',
            },
            statusCode: 200,
            body: JSON.stringify(data),
        };
    },

    _400(data = {}) {
        return {
            headers: {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Methods': '*',
                'Access-Control-Allow-Origin': '*',
            },
            statusCode: 400,
            body: JSON.stringify(data),
        };
    },
};

module.exports = Responses;

200 과 400 일때의 response 를 우선 작성한다.

service: myserverlessproject

provider:
    name: aws
    runtime: nodejs10.x
    profile: serverlessUser
    region: eu-west-1

plugins:
    - serverless-s3-sync
    - serverless-webpack

package:
    individually: true

custom:
    s3Sync:
        - bucketName: myserverlessprojectuploadbucket-123123
          localDir: UploadData

functions:
    getUser:
        handler: lambdas/getUser.handler
        events:
            - http:
                  path: get-user/{ID}
                  method: GET
                  cors: true

resources:
    Resources:
        DemoBucketUpload:
            Type: AWS::S3::Bucket
            Properties:
                BucketName: myserverlessprojectuploadbucket-123123

작성하고 난뒤에 sls deploy 하게 되면 배포가 된다.
배포가 된후 url 들어가면 json 데이터가 보이게 된다.

위의 배포 방식에는 이상이 없다.
용량이 작아서 아무런 문제가 생기지 않을것이다.
하지만 트래픽이 몰리고 충분한 스택이 되지 않는다면
데이터베이스부터 문제가 발생하게 된다.
https://hudi.blog/dbcp-and-hikaricp/

데이터베이스와 데이터베이스를 사용하는 서버는 다른 시스템이다.
그래서 이 두개의 시스템은 연결을 시켜줘야한다.

이것을 데이터베이스 커넥션이라고 한다. 번역그대로이다.
데이터베이스 커넥션 풀은
미리 여러개의 데이터베이스 커넥션을 생성해놓고, 필요할 때 마다 꺼내쓰는 방식이다.

데이터베이스 커넥션 풀을 사용하게 되면 요청이 들어올 때 마다 데이터베이스 연결을 수립하고, 통신한 뒤, 닫는 과정을 거치지 않아도 된다.

진짜로 알고싶은 내용->Lambda RDS Connection

이러한 데이터베이스에서 connection 에러가 발생하게 된다.

show variables like 'max_connections'

라고 입력하게 되면 사용할 수 있는 connections 양이 나오게 된다.
나는 이럴때 단순히 max_connections 를 올렸다.
그리고 데이터베이스 유형을 변경했다.

그때 생각해보면 트래픽으로 서버가 다운 되고 난후 유저가 빠져나가서
서비스가 살아난것 같다.

이후에 이런 상황이 또 온다면 어떻게 해야할까 ??
또 그냥 서버가 다운되면 max_connection 만 올리기에 급급해야할까 ?

https://dulki.tistory.com/138

나 말고 이런 상황을 경험해보고 고민해본 사람들이 있었고
방법은 RDS Proxy 를 사용하면 된다고 한다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/rds-proxy.html

RDS Proxy는 Amazon RDS 및 Amazon Aurora와 함께 사용되는 데이터베이스 프록시 서비스입니다. 데이터베이스에 대한 애플리케이션의 요청을 관리하여 데이터베이스 워크로드의 확장성, 복원력 및 가용성을 향상시키는 데 도움을 줍니다. 주요 특징 및 이점은 다음과 같습니다:

  1. 확장성 향상: RDS Proxy는 데이터베이스와 애플리케이션 사이의 연결을 재사용하므로 연결 오버헤드가 줄어듭니다. 이로 인해 애플리케이션은 급격한 트래픽 증가에 더 잘 대응할 수 있습니다.

  2. 복원력 향상: 데이터베이스 실패 시 RDS Proxy는 애플리케이션 연결을 다른 데이터베이스 인스턴스로 자동으로 재지정하여 애플리케이션의 복원력을 향상시킵니다.

  3. 보안: RDS Proxy를 사용하면 애플리케이션 및 데이터베이스 사이의 트래픽을 안전하게 유지할 수 있습니다. Amazon VPC에서 실행되며, SSL을 사용하여 데이터를 암호화하고, IAM 권한과 네트워크 권한을 통해 연결을 제어합니다.

  4. 응답 시간 최적화: RDS Proxy는 쿼리 결과를 캐싱하여 일부 읽기 쿼리에 대한 응답 시간을 줄일 수 있습니다.

  5. 가용성 향상: RDS Proxy는 읽기 복제본을 지원하는 데이터베이스에서 트래픽을 주 데이터베이스 인스턴스와 복제본 사이에서 분산시켜 가용성을 향상시킬 수 있습니다.

  6. 서버리스 애플리케이션과의 호환성: RDS Proxy는 AWS Lambda와 같은 서버리스 애플리케이션에서 발생할 수 있는 동시 연결 수가 많은 상황에 잘 대응할 수 있습니다.

RDS Proxy를 사용하면 데이터베이스 앞에서 중요한 연결 관리 작업을 처리하므로, 백엔드 데이터베이스의 부하를 줄이고 전반적인 애플리케이션 성능을 향상시킬 수 있습니다.

Lambda Serverless 를 이용해서 배포하게 된다면 Connection 풀에 대해서 염두를 둬야하고 , RDS Proxy 를 생각하자 !

profile
BackEnd_Ash.log
꾸준함이란 ... ?
이전 포스트

AWS 람다 함수 데이터베이스 연결

0개의 댓글