"Life is Full of Possibilities" - Soul, 2020

AWS 3

개발 서버와 운영 서버의 환경변수만 다른데 운영 서버 배포만 안되는 이유?! (AWS S3, CDN, CodePipeline, CodeBuild)

EC2와 Nginx를 사용한 첫 번째 버전의 배포 과정은 여기서 확인하실 수 있습니다. Devel Up 프로젝트의 브랜치 전략Devel Up 프로젝트에서는 dev 브랜치와 main 브랜치를 활용해 각각 개발 서버와 운영 서버의 파이프라인을 독립적으로 구축하고 배포하는 것을 목표로 했습니다.   처음에는 GitHub Actions를 사용하려 했지만, 제공받은 AWS 계정의 S3 정책 설정 상 access key 발급이 불가능했습니다. 이에 따라 AWS CodePipeline과 CodeBuild를 사용해 파이프라인을 구축하기로 결정했습니다.   AWS를 선택한 이유와 장단점 AWS는 GUI를 통해 파이프라인을 간편하게 설정하고 실행할 수 있는 장점이 있습니다. 디버깅 과정에서도 CloudWatch를 활용하면..

S3, AWS CloudFront(CDN) 캐시 설정의 차이점

성능 개선 중 S3와 CDN에 배포를 진행하며 캐시를 설정했다. CDN과 S3의 데이터에 새롭게 변할 데이터가 거의 없을 것이라 판단하여 모두 캐싱 기간을 1년으로 설정해 두었다. 여기서 궁금한 점이 생겼는데, S3에도 캐시 기간 설정을 할 수 있고 CDN에서도 캐시 설정을 할 수 있다. 그렇다면 각 캐싱이 어디에 적용되는지 헷갈렸다😵‍💫 정리하자면, 1. S3의 max-age : 브라우저가 캐시를 저장하는 시간이때, CDN의 최소 TTL < max-age < 최대 TTL인 경우 : CDN의 캐싱 시간은 max-agemax-age < 최소 TTL인 경우 : CDN의 캐싱 시간은 최소 TTL최대 TTL < max-age인 경우 : CDN의 캐싱 시간은 최대 TTL2. S3의 s-maxage : CDN이 캐..

개발 환경 개선을 위한 노력 (CD 구축, 전역 스타일 코드 갈아엎기)

4차 스프린트에서는 프로젝트의 목표였던 "개발 환경 개선"에 집중할 수 있었습니다. 저희 팀의 프론트엔드 인원이 다른 팀에 비해 한 명이 적다 보니 개발 환경의 효율화와 생산성 향상이 꼭 필요했습니다. 그래서 프로젝트를 하면서 제가 어떤 부분에 기여할 수 있을지 고민하다, 개발 환경을 개선시켜 생산성을 높여보자는 목표를 정했습니다.  1. 자동 배포 (CD) 개발 환경을 개선하기 위한 방법 중 첫 번째로는 자동 배포(CD)에 도전했습니다. 프론트엔드의 CI는 이미 구축되어 있었지만, CD는 구축되지 않은 상태였습니다. 그래서 배포 환경에서 테스트를 하려면 pem 키를 가진 크루에게 부탁해서, 우분투에 접속한 후 수동으로 배포를 해야 했습니다. 환경 변수가 추가되거나 변경 사항이 생길 때에도 우분투 CLI..