SAM 을 통해 Websocket APIGateway, Lambda를 구축할 때 알아둬야할 것들

이번에 SAM 을 통해서 새로운 서비스와 파이프라인을 구축하면서 적절한 레퍼런스와 자료를 찾기 쉽지않아서 난항을 많이 겪었습니다.
추후 정리할 부분을 남기기전에 가볍게 알아두면 좋은 특징들을 기록합니다.

 

목차

• Websocket APIGateway와 Lambda 관련 특징
• 다른 리소스의 특징
• 레퍼런스 링크

Websocket APIGateway와 Lambda 관련 특징

로직상 private VPC의 타 Resource 에 io 작업이 있는 경우, Lambda에서 VPC 구성 할 수 있습니다. 이때외부 통신을 위해서는 다음 중 하나가 필요합니다.

• 다른 Resource에 작업 연결
  • VPC Config 혹은 IAM Provider 등을 구성해서 통신할 수 있습니다.
• 외부 통신
  • VPC Peering 을 통한 접근 : 관리가 더 복잡해질 수도 있습니다.
  • NAT Gateway를 통한 접근 (Private Subnet -> NAT Gateway -> Internet Gateway)
  • VPC Endpoint를 통한 접근 (Private Subnet -> VPC Endpoint)

로컬 테스트 및 모니터링 팁

• 원격 Lambda 함수 호출할 때 아래 명령어로 빠른 호출과 파일로 확인이 가능합니다.

aws lambda invoke --function-name="[함수명]" --region=[리전] output.json

• WSAPIGateway default 로직의 경우 로컬 터미널에서 로그 테일링을 통해 에서 빠른 확인이 가능합니다.
• sam logs -n [함수명] --stack-name [스택명] --profile=[프로파일] --tail

SAM template에서 IAM 설정 시 필수로 등록해야 하는 정책들은 다음과 같은 정책들입니다.(상황에 따라 달라지며, 리소스별로 이런게 필요할 것 이라는 추측이 가능할 것 같아 기록합니다.)

• ElastiCache 접근을 위한 IAM 정책
• VPC 엔드포인트 설정
• 보안 그룹 규칙
• Lambda 함수 VPC 설정

SAM 스테이지 관리방법은 매우 어렵습니다.

• 기본적으로 SAM 은 CloudFormation 기반으로 동작하기 때문에 StackName으로 동작합니다.
• samconfig.toml을 통한 환경별 설정 관리가 더 체계적 입니다.
• 각 환경별 독립적인 배포와 롤백 가능하지만, 구축단계에서 많은 테스트가 필요하고 잘못된경우 직접 aws cloudformation delete-stack 을 해야하는 번거로움이 있습니다.
  • sam deploy 로 덮어지지 않는 경우 다수 있음.

도메인 설정 시 주의사항(APIGateway 를 소유도메인으로 연결할 때)은 다음과 같습니다.

• ACM 인증서는 API Gateway와 같은 리전에 있어야 합니다.
• API Gateway 커스텀 도메인은 리전별로 생성되며, Route53 호스팅 영역이 미리 설정되어 있어야합니다.
• 기존의 도메인이 있을 때, template.yaml 에 서브도메인을 생성하고 라우팅이 가능하지만, 다른 stack/sam 등으로 구축할 경우 이미 구축된 domain 으로 deploy 에러가 발생합니다.
  • 여기서 굉장히 많은 삽질을 했는데, 결국 서브도메인에 stage를 분기해야 했습니다.
    • (ex: dev-subdomain.domain.com)
• SSL 설정과 DNS 전파 시간이 애매합니다.
  • 이건 DNS 시스템에서 주관되기 때문에 언제 반영이 될지 모릅니다.
• dig명령어와 route53에서 확인이 가능합니다.
• APIGateway 에서즌 가용도메인이 세팅되었으나, route53의 레코드에서 보이지 않는 경우도 있습니다.
  • 이런 경우는 AWS::Route53::RecordSet 이 설정되어있는지 확인하고 없다면 만들어야합니다.
    • Propreties에서 Name을 설정해야하는데, 맨뒤에 반드시 “.(쩜)” 을 꼭! 써야합니다.

배포 파이프라인 구성 시 고려사항은 작업 막바지에 방심하기 쉬운 부분입니다.(개인적으로 제일 힘들었음)

• GitHub Actions으로 당연히 배포가 가능합니다.
• working-directory 설정으로 디렉토리를 지정해서 사용했습니다.(향후 확장성?을 일단 고려했기 때문입니다.)
• sam deploy 시에 가장 많이 겪었던 이슈는 아래 명령어를 추가하여 해결했습니다.
  • -no-fail-on-empty-changeset
  • -resolve-s3
• Stack과 관련해서 samconfig.toml 로 환경을 나눠 배포하는 것이 가장 정신건강에 이로웠고 아래 명령어와 환경으로 배포했습니다.
  • --config-env $ENV
  • samconfig.toml 에서 [ENV(요걸로 분기).deploy.parameters] 로 구분됩니다.

다른 리소스의 특징

ElastiCache는 서버/서버리스 두 가지 종류가 있습니다. 직접 콘솔로 들어가거나 세팅값을 확인해보지 않으면 알수 없습니다. ClusterId등을 지정해야하는 부분이 반드시 있기 때문에 아래 명령어로 확인하는 것이 정신건강에 도움 되었습니다.

• Serverless: aws elasticache describe-serverless-caches
• 노드 기반: aws elasticache describe-cache-clusters

ElastiCache 연결 시, SSL 설정이 false인 경우, Redis 클라이언트도 ssl=False 설정 필요 합니다.

• TransitEncryptionEnabled 설정도 확인이 필요합니다.

레퍼런스 링크

• https://docs.aws.amazon.com/ko_kr/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html - SAM 서버리스 앱 자동화 업데이트 가이드
• https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-findinmap.html - CloudFormation FindInMap 함수 레퍼런스
• https://catalog.workshops.aws/complete-aws-sam/en-US/module-5-canaries - AWS SAM 카나리 배포 가이드
• https://docs.aws.amazon.com/ko_kr/serverless-application-model/latest/developerguide/serverless-sam-cli-logging.html - SAM CLI 로깅 가이드
• https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/LambdaRedis.html - Lambda와 ElastiCache Redis 연동 가이드
• https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/aws-resource-apigatewayv2-stage.html - API Gateway V2 스테이지 구성 문서
• https://docs.aws.amazon.com/ko_kr/serverless-application-model/latest/developerguide/serverless-sam-cli-logging.html - SAM CLI 로깅 가이드
• https://www.hongreat.co.kr/blog/aws/aws-sam%EC%9C%BC%EB%A1%9C-api-gateway-websocket%EA%B3%BC-lambda-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0 - 기본구축 가이드