[서버리스] 백엔드

hellonayeon·2021년 11월 1일
45
post-thumbnail

🖥 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델

✏️ 인프라 관리 작업을 클라우드에게 위임함으로써 서버를 고려하지 않고 서비스를 개발할 수 있다.


EC2 / EB 배포 환경의 한계

EC2EB 로 배포 환경을 구성하는 데에는 몇 가지 문제가 있다. EC2 의 경우 유연한 인프라 를 구축하는 데에는 한계가 있다. 생성한 인스턴스만으로 요청이나 서비스 로직을 처리하는게 부족하다면 직접 인스턴스의 개수를 늘려줘야하고 서비스 요청을 각각의 인스턴스로 분배하기 위해 Load Balancer 를 구축해줘야한다. Load Balancer 를 만들기 위해서는 AMI Auto Scaling Target Group 등 추가적으로 해줘야할 설정들이 여러개다. 이를 자동화 시켜놓은 서비스가 EB 이고 이를 사용하면 EC2 보다 유연한 인프라 확장이 가능하다. 결국 이러한 작업들은 개발자가 서버 를 직접 관리하는 것이다.

하지만 이 두 가지 아키텍처의 근본적인 문제점은 모든 내용을 한번에 배포 한다는 것이다. 배포 시점마다 백엔드에서 필요한 프로그램 파일들을 한 번에 업로드하니까 프로그램의 덩치가 커질수록 배포하는데 많은 시간이 소요될 것이다. 무엇보다 하나의 비즈니스 로직 또는 API에 문제가 발생하더라도 코드 뭉치들을 한 번에 올려야 하기 때문에 시간적인 측면에서 낭비가 크고 비효율적이다. 따라서 백엔드에서 처리하는 API를 나눠서 관리함으로써 단위별로 배포와 유지보수를 효율적으로 하기 위해 Lamda + API Gateway 클라우드 서비스를 이용한다.

Labmda는 생각보다 제한도 많고 비싸서 클라우드 환경에서 간단하게 API를 테스트 해보는 용도로 사용하는게 좋겠다!

📝 정리

  • EC2만으로는 유연한 인프라 구축이 불가능
  • EC2 / EB 는 배포하기 위해 파일 전체를 업로드
  • API 를 부분적으로 관리 불가능

서버리스 백엔드

EC2/EB 를 사용해서 만드는 배포 환경의 문제점을 알았으니 서버리스 백엔드 환경을 만들어보자!


🌱 사용 서비스

  Lambda  
정의   서버리스 컴퓨팅 서비스

장점

  • 서버에 대한 걱정없이 코드를 실행 가능
  • 백엔드 로직 단위별로 관리 가능
  • EC2는 켜놓기만 해도 비용이 지불되지만 Lamda 는 함수 호출 건수에 따라 비용 지불
  • EC2의 용량과 성능이 부족하지 않은지 관리할 필요 X

단점

  • 리소스 제한: 메모리 최대 10GB / 처리 시간 최대 900s
  • Stateless: DB 연결 유지 불가능, 로직마다 DB 연결
  • Cold Start: 오랜만에 람다 함수를 호출할 경우 딜레이 발생
  • 동시성 제한: 동시 요청 건수 최대 1000회

  API Gateway  
정의   API 구축, 배포 및 관리 서비스

사용 이유

  • Lamda 를 외부에서 호출할 수 있도록 API 엔드 포인트 역할 수행
    |__ Lamda는 함수일뿐! 외부에서 호출해줘야해!

  RDS  
정의   관리되는 관계형 데이터베이스 서비스

사용 이유

  • 데이터베이스 설정과 백업이 편리
  • RDBMS를 직접 운용하지 않고 AWS에 대행 가능

  SecretsManager  
정의   보안 암호 교체 및 관리 서비스

사용 이유

  • 데이터베이스 암호를 주기적으로 교체
  • 비밀번호에 대한 고민 필요 X

  VPC  
정의   가상 사설망 구축 서비스 격리형 클라우드 리소스

사용 이유

  • 모든 사람들이 접근 가능한 인터넷 망과 분리해서 사용 가능

  • 외부에서 데이터베이스에 연결하지 못하도록 설정

  • 망을 분리해서 사용함으로써 보안 강화

  • ex. 중요한 데이터가 저장된 데이터베이스는 외부에서 연결할 수 없게 프라이빗 서브넷에만 연결

  • RDS 프록시는 프라이빗 서브넷에만 있어야한다. 따라서 Lambda도 프라이빗 서브넷에 위치시켜야만 한다.

  NAT  
정의   네트워크 주소 변환 서비스 프라이빗 서브넷을 인터넷 망과 연결 격리형 클라우드 리소스

사용 이유

  • 사설IP ➡️ 공인IP 로 변환: 사설망에서 인터넷 망으로 나갈 수 있도록 해준다.
  • Lambda에 VPC를 구축했기 때문에 NAT가 없으면 Lambda에서 외부 오픈 API 호출 불가능

  Proxy  
정의   클라이언트와 서버 사이에서 대리로 통신해주는 기능(중계) 프록시 기능을 하는 서버 = 프록시 서버 RDS 기능

사용 이유

  • 데이터베이스 연결을 풀링하고 공유하도록 허용하여 확장 기능을 향상
  • 데이터베이스의 연결을 관리: Connection Pool 관리
  • Lambda 함수를 RDS와 연동하기 위해 RDS Proxy 사용을 권장

🕸 서버리스 백엔드 구성도


🔨 서버리스 백엔드 구축 과정

    [1] Lambda 함수 생성
    
    [2] Lambda와 API Gateway 연결
        
    [3] RDS 생성
        └── 보안그룹: inbound 3306
        
    [4] Secret Manager 보안암호 생성
        ├── RDS에 대한 자격 증명
        ├── Lambda > 구성 > 권한 > 'SecretManagerReadWrite' 추가
        └── 보안암호 교체 편집
            ├── 자동 교체 활성화 / 새 Lambda 함수를 생성하여 교체
            └── 새롭게 생성된 보안암호 확인
    
    [5] Lambda VPC 추가
        ├── 보안그룹 생성: outbound all traffic allow
        ├── Lambda > 구성 > 권한 > 'AmazonVPCFullAccess' 추가
        └── Lambda > 구성 > VPC 추가 [서브넷 C, 생성한 보안그룹]
        
    [6] NAT 설정
        ├── 퍼블릭 서브넷 편집 [인터넷 게이트웨이로 연결되는 4개의 서브넷 중 서브넷 C 제외]
        ├── NAT 게이트웨이 생성
        |   ├── 외부망과 연결된 서브넷으로 설정 [서브넷 A,B,D 중]
        |   └── 탄력적 IP 할당
        └── 라우팅 테이블 생성
            ├── 라우팅 편집 > NAT 게이트웨이 설정
            └── 서브넷 연결 편집 > 서브넷 C 설정
        
    [7] Proxy 설정
        └── RDS > Proxies > 프록시 생성
            ├── 보안암호: Secret Manager
            └── 보안그룹: [3]에서 생성한 inbound 3306
            ├── Inspect: All query parameters
            ├── Match type: Contains SQL injection attacks
            └── Text transformation: URL decode, Lowercase
        
    [8] 데이터베이스 프록시 추가
        ├── 기존 데이터베이스 프록시 선택: [7]에서 생성한 프록시 선택
        └── SecretManager 수정: 프록시 엔드포인트 (읽기/쓰기)

SAM

Serverless Application Model 의 약자로 Lambda를 빌드하는데 사용할 수 있는 프레임워크이다. AWS 콘솔에서 Lambda를 생성하고 배포할 경우, 로컬에서 작성한 코드와 의존하는 모듈들을 압축해서 업로드해줘야한다. 그리고 배포하고 난 이후에 간단한 오류의 경우 콘솔 코드 편집기를 통해 수정하기도 한다. 이렇게 Lambda를 관리할 경우 로컬 환경과 배포 환경의 코드 동기화가 이뤄지지 않아 관리가 어렵다. 하지만 SAM을 이용하면 로컬에서 작성한 코드와 설정 파일을 명령어를 통해 Lambda를 생성할 수 있고, 프로그램을 배포하고 관리할 수 있다. 따라서 로컬 개발환경과 배포된 Lambda의 코드를 동기화할 수 있고 구성설정들을 templates.yaml에 기술해주기만 하면 되므로 콘솔을 사용하는 것 보다 훨씬 수월하다🤓

CloudFormation

코드형 인프라 프로비저닝 서비스이다. 템플릿 에 기술한 내용을 바탕으로 해당 리소스의 프로비저닝과 구성을 담당해준다. 로컬에서 작업한 Lambda Handler 코드와 templates.yaml을 배포하면 이 내용들을 가지고 실질적으로 Lambda 함수를 생성해주는 역할을 하는게 CloudFormation 이다. 하나의 AWS 서비스에 대한 리소스를 스택 이라는 단위로 관리한다.

참고문서

📌 AWS Documentation. AWS Lambda 기능

📌 godpearl. "[Lambda] 람다의 장점과 단점 | 콜드스타트와 동시성제한", 그럼에도 불구하고, 9 Aug. 2021

📌 AWS Documentation. Amazon RDS 프록시 사용

📌 Harry The Great. "[AWS] 서버리스를 위한 RDS Proxy서비스", 해리의 유목코딩, 29 Dec. 2019

📌 AWS Documentation. Using Amazon RDS Proxy with AWS Lambda

📌 Junghyo Cho. "AWS CloudFormation으로 인프라 자동화 시작하기", pplink, 27 Nov. 2018


🖼 AWS Korea. "AWS SAM Local (베타) – 로컬 기반 서버리스 앱 테스트 및 개발 도구", Amazon Web Services 한국 블로그, 14 Aug. 2017.

🖼 AWS. AWS CloudFormation 작동 방식

5개의 댓글

comment-user-thumbnail
2021년 11월 1일

정리...좋아용...👍👍

1개의 답글
comment-user-thumbnail
2021년 11월 1일

정리 넘모 감사합니다ㅠㅠ 👏👏👏👍
수고하셨어요!!!

1개의 답글
comment-user-thumbnail
2021년 11월 11일

ㅇㅂㅈㅇ

답글 달기