개발과 일상

앞서 이야기했지만 Go도 알아야되는 상황이 됐다. 그 이유는 Go로 개발한 Lambda가 있기 때문이다. 아무것도 몰라서 바닥부터 머리를 박아가면서 알게된것들이 많다. Go로 Lambda를 개발할 때 주의할 점이 몇가지 있다. 1. yarn이나 npm 같은 패키지매니저가 없어서 makefile을 이용해 빌드 방식을 관리한다. 2. 올해(2024년)부터는 runtime을 go 1.x보다 Amazon Linux 2를 사용하길 권장한다. 3. binary를 생성하고, Amazon Linux 2에서 사용되는 bootstrap으로 람다에 배포해야한다. 참고자료 : https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/golang-package.html 추가적으로, Go의 함수..

AWS S3는 저장하는 건 저렴한데, S3에 직접 엑세스하는건 비싸고 느리다. 그래서 CDN을 이용해 캐싱을 많이하는데, AWS에서는 CloudFront 서비스를 이용해서 CDN을 사용할 수 있다. CloudFront란? Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다. CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공됩니다. AWS에서 사용하는 기능이니 고가용성은 기..

이전 글에는 문제가 있다. 현재 DDB Table에는 이미 3천개 이상의 데이터가 쌓여있고, 앞으로 꾸준히 데이터가 쌓일 예정이다. 그런데 조회 쿼리 ScanCommand를 사용했다. 이 조회 방식은 언젠가 문제를 일으킬 것이다. 어떤 문제인지는, AWS의 DDB 스캔 사용 모범사례를 보면 알 수 있다. 일반적으로 Scan 작업은 DynamoDB의 다른 작업보다 비효율적입니다. Scan 작업은 항상 전체 테이블이나 보조 인덱스를 스캔합니다. 그런 후 값을 필터링하여 원하는 결과를 얻기 때문에 결과 세트에서 데이터를 제거해야 하는 단계가 추가됩니다. 가능한 경우, 대용량 테이블 또는 인덱스에서 필터를 사용해 다수의 결과를 제거해야 하는 경우에는 Scan 작업을 최대한 피하는 것이 좋습니다. 여기에 테이블이..

상용 배포를 앞두고, dev 서버에서 잘 동작하던 Lambda에서 문제가 발생했다. Dynamo DB(이하 DDB) 조회해서 데이터의 존재여부를 검증하는데, 분명 조회 데이터가 존재하는데도 Count가 계속 0으로 찍히는 문제였다. dev에선 분명히 잘 동작했고 prod에서도 에러가 나지 않았기 때문에, 오류를 찾기가 너무 힘들었다. 커넥션이 올바르게 되고 있는지부터 쿼리가 올바른지, 로직에 문제가 없는지 다 검증해봤는데, 의외의 곳에서 실마리를 얻었다. prd DDB에 저장된 데이터는 3000개 이상이었는데, 위 조회 방법으로 조회하니 ScannedCount가 709개로 나왔다. 여기서부터 문제가 있음을 인지하게 되었다. 조회 쿼리를 날렸을 때 결과물이 아래와 같이 나왔다. { '$metadata': ..

단일 AWS의 리소스를 사용할 때는 몰랐던 것들이 있다. (루트 사용자로서 EC2만 하나 덜렁 사용할 때는 다른것들을 고려할 필요가 없었다.) AWS 리소스가 다른 AWS 리소스를 사용하려면, 리소스를 사용할 수 있다는 것을 명시해야 한다는 것이다. 그리고 AWS에서는 루트 사용자로 AWS 리소스 접근을 권장하지 않는다. AWS 사용자 별로 역할을 부여해 AWS 리소스에 대한 권한을 주고 사용하길 권장한다. (실수 방지, 모니터링 등 많은 이유가 있다) 이 두 가지는 IAM(AWS Identity and Access Management)이라는 이름으로 관리된다. 해당 페이지에 진입해보면 생소한 내용이 많은데, 하나씩 알아보자. IAM 이란? AWS Identity and Access Management(..

이전 글들에서 람다와 람다를 사용하기 위해서 Serverless 프레임워크를 사용해봤다. 이 상태로도 사용할 수 있지만 사용 편의를 위해서 Serverless에서는 더 다양한 기능을 제공한다. 진짜 많은 기능들이 있는데, 내가 사용했던 기능들을 순차적으로 알아보려고 한다. 1. yarn 설정 2. 스테이지 설정 가져와서 쓰기 3. 파일 정보 읽어오기(yaml) 4. 환경변수 설정 5. tag 설정 6. 이미 존재하는 API Gateway 가져와서 사용하기 하나씩 알아보자. 1. yarn 설정 가장 첫 글에서 serverless를 설치하면서 yarn도 같이 설치했었는데, 여기서 사용하기 위해서다. package.json에 yarn설정을 해뒀다. { "name": "serverless-options", "v..

이번엔 serverless에서 제공하는 다양한 기능을 써보려고 한다. 이전 포스팅에서는 너무 한가지만 써봤어서 재미가 없었기 때문에 다양한 기능을 엮어서 엔드 투 엔드로 하나의 세트를 만들어 보려고 한다. 약간의 콘솔 작업이 필요하지만, 차근 차근 진행해보려고 한다. 작업 내용은 이렇다. 1. serverless로 람다, API gateway 생성 후 연동 2. Route 53에서 도메인 발급, 서브도메인 생성 3. 발급받은 서브도메인과 API gateway 연동 4. servless에서 API gateway 재사용하도록 설정 5. 람다와 DDB 연결 정리하면, 발급받은 url로 들어와 api gateway로 들어온 이벤트를 람다에 라우팅해, api gateway의 이벤트 정보들을 ddb에 저장하는데까지..

현재 서비스하는 서버에는 DB에 직접 접근하지 않거나 이벤트 성으로 관리할 것들은 람다로 관리한다. 그러다보니 람다가 계속해서 늘어나는데, 각각의 람다들을 매번 콘솔에서 람다를 관리하기는 꽤나 번거롭다. 이럴 때 여러 serverless 서비스(AWS Lambda의 Event나 function)을 관리하기 위한 도구가 있다. Serverless framework인데, BE 개발만 하던 나에겐 좀 생소해서 가볍게 사용해보면서 사용법을 익혀보려고 한다. Installation 패키지 매니저로 yarn을 사용할 것이다. npm 설치, yarn 설치 sudo apt install npm sudo npm install --global yarn serverless 설치 npm install -g serverless..