개발과 일상

문제 발생상용 배포 당일 정신없던 배포 준비를 마친 후, 상용서버 배포를 진행했다. 그리고 몇 번의 핫픽스를 내보낸 후 FE 개발자 분이 안보이는 부분에 문제가 있다고 연락이 왔다. FE에서 자기들이 쓰려고 FE의 서버로 보내는 API를 만들었는데 이 URL로 요청을 보내면 403 에러가 난다는 것.  403 Forbidden을 가장 많이 보는 경우는 CORS 문제다. 하지만 해당 요청이 들어온 CloudFront(이하 CF)의 옵션을 보면 CORS 문제가 아니다라는 걸 바로 알 수 있다. AWS에서도 403 에러 관련 문서를 제공하는데 나에겐 큰 도움이 되지 않았었다. 함정이 도사리고 있어서 매우 고통스러웠던, 문제 해결과정을 알아보자.. 문제 분석1. 정말 CORS 문제가 아닌가?이 도메인으로 접근하..

문제 상황 정리작년 9월쯤부터 비용절감을 위해 dev 서버를 spot 인스턴스로 변경했다. 약 30% 정도 비용절감이 효과가 있어서 당시에는 꽤 괜찮은 선택이었는데, 운영하면서 문제가 발생했다. dev 서버가 spot 인스턴스를 너무 자주 뺏기고, 다시 할당 받는데 시간이 오래 걸리는 현상이 반복됐다. 한두번이면 상관 없는데 하루에도 몇 번씩 뺏기고 다시뜨는데 10분씩 걸리니까, 개발에 차질이 생기는 경우가 생겼다. 이 문제를 해결하고 싶었다. 문제 정의spot instance란?스팟 인스턴스는 실행 중인 동안에는 온디맨드 인스턴스와 정확히 동일합니다. 그러나 스팟은 실행 중인 인스턴스를 워크로드를 완료할 수 있을 만큼 충분히 오래 유지할 수 있다고 보장하지 않습니다. 또한 스팟은 찾고 있는 인스턴스의 ..

Amazon VPC (Virtual Private Cloud) 를 사용하면 정의한 논리적으로 격리된 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다. Amazon VPC(Virtual Private Cloud)는 AWS 계정 단위의 논리적으로 격리된 가상 네트워크다. 대부분의 AWS 서비스는 VPC 없이 사용할 수 없다. 별도의 설정을 하지않으면 디폴트로 생성되어 있던 public VPC가 설정된다. 격리되지 않은 네트워크를 사용한다면, 여러가지 문제가 발생할 수 있는데 대표적인 예로는 AWS 리소스들이 공개된 망에 노출되어 WAS, DB가 보안 공격에 취..

S3를 퍼블릭으로 관리하게 되면서, 파일을 주기적으로 지워야하는 정책이 추가됐다. S3에서는 다행히 주기적으로 파일을 삭제하는 기능이 있다. 바로 수명 주기 규칙이다. S3 > 버킷 > 버킷 선택 > 관리 > 수명 주기 규칙 생성으로 들어간다. 수명 주기 규칙은 알아보기 쉽게 짓고, 내 목적은 파일 전체를 지우는 거기 때문에, 버킷의 모든 객체 적용을 선택. 그리고 이전 버전 영구 삭제를 하루로 설정한다. 다만, 수명 주기 규칙 생성은 최소 단위가 1일이다. 이 간격을 더 짧게 만드는 가장 쉬운 방법은 람다나 서버에서 스케줄러를 돌려서 주기적으로 데이터를 지워주는 방식이다. 심플하지만 재미없는 방식이다. 조금 색다른 아이디어를 내보자면, S3에 저장된 객체만 퍼블릭하게 접근할 수 있는 시간을 지정할 수 ..

온라인에서 문서를 PDF로 변환하는 프로젝트를 진행 중이다. 가장 큰 걸림돌이라 예상됐던, PDF 변환 솔루션은 다행히도 잘 동작하고 있다. (몇몇 확장자는 지원한다더니 안되지만 말이다) 문제는 사용자에게 파일 크기가 큰 파일을 어떻게 사용자에게 전달할 것인가? 였다. 가장 먼저 떠오르는 방식은 Base64나 ByteArray로 변환하고 FE에서 파일로 변환하는 거였지만, 사용자가 요청하는 파일 크기가 커진다면 응답의 크기가 얼마나 커질지 알 수가 없다. 이런저런 방법을 알아보다가 퍼블릭한 S3를 만들어서 S3 경로를 던져주고 PDF 뷰어는 브라우저에게 맡기는게 가장 손이 덜 가는 방법이라는 결론을 짓게 됐다. 퍼블릭한 S3 버킷를 만드는건 어렵지 않을거라 생각했다. 왜냐면 생성할 때 주는 옵션이 있기 ..

AWS EC2에서 작업을 하다가 HTTPS 설정을 해야하는 필요한 이슈가 발생했다. HTTPS 설정을 하기 위해서는 SSL/TLS 인증서를 발급받아야 한다. SSL/TLS 인증서를 서버에 적용하기 위해서는 몇 가지 방법이 있다. 1. secure sign과 같은 정식 발급해주는 곳에서 발급 받고 가이드 대로 적용하기 https://www.sslcert.co.kr/guides/Spring-Boot-SSL-Certificate-Install 2. Let's encrypt를 사용하기(얘는 자동 갱신도 됨) https://jiwontip.tistory.com/83 3. ACM(AWS Certificate Manager) 사용하기 https://docs.aws.amazon.com/ko_kr/acm/latest/u..

이전 글들은 이 글을 쓰기위한 빌드업이 었다. 1. AWS S3와 CloudFront 연동 끝까지 가보기 2. WSL/WSL2에 Go(Golang) 설치하기 3. Go + serverless framework로 Lambda 관리하기 4. 꼭 읽어줬으면 하는 AWS Lambda@Edge의 특이 사항들 정리 개인적으로는 Lambda@Edge를 시작하기전에 4번은 꼭 훑고 갔으면 좋겠다. 1번 글의 마치며에서도 언급한 내용이지만, 이미지가 아직 CloudFront(CDN)에 등록되지 않았을 경우 첫 로딩에 문제가 발생할 수 있다. 그리고 그 문제는 이미지의 크기가 커질수록, 더 커질 것이다. 그래서 이미지의 사이즈를 작게 만드는 과정이 필요하다. (리사이징이든, 확장자 변환이든 여러가지 방법이 있다) 하지만 ..

직접 인프라를 구축하고, 개발하면서 고통받았던 사항들 정리한 것이다. 공식 가이드 문서를 다 봤어도 놓칠만한게 꽤 있었을 것 같다. 1. Lambda@Edge는 Nodejs, Python으로만 사용가능하다. AWS 인프라도 정리해볼 겸, Go 사용법도 익힐 겸 Lambda@Edge를 이용해서 이미지 변환을 해보려고 했다. 이미지 변환 라이브러리를 이용해서 Go 코드를 다짜놨는데 웬걸? Go는 Lambda@Edge에 사용할 수 없었다. 함수를 만들기 전에 Lambda@Egde를 미리 만들어볼걸 그랬다. 2. 아키텍처와 리전의 제한이 있다. 리전은 us-east-1, 아키텍처는 x86_64이 고정이다. 리전 고정은 CloudFront와 동일한 리전에 위치하기 위해서 인 것 같고, 아키텍처는 클라우드 호환성 ..