출처: https://www.wearethemighty.com/mighty-memes/11-best-deployment-memes/
배포 과정 돌아보기
Section 3의 마지막 부분에서 처음으로 배포에 대해 배웠습니다. HA(시험)를 앞두고 있는 상황이라 사실 배포가 막 머리에 잘 들어오는 편은 아니었어요. 아무래도 프로젝트를 대비한 교육과정에 가깝다보니 당장은 흐름을 이해하는 것도 쉽지 않았습니다.
당시에는 교육과정에 쓰인대로 충실하게 진행해서 어찌저찌 진행을 하긴 했지만, 직접 배포를 맡아 진행해보니 확실히 굴러가며 배우는 것이 생기긴 합니다. 그래서 오늘은 까먹기 전에 배포 과정에서 발생했던 문제들을 최대한 적어보려고 합니다. 예전에도 블로깅을 했었던 것 같기는 한데, 최종 배포를 진행하는 중인 만큼 다시 한 번 리마인드를 하는 차원에서 말이죠.
참고로 모든 배포 과정은 AWS 를 사용해 진행했습니다. S3(클라이언트 배포), EC2(서버 배포), RDS(데이터베이스 구축), CloudFront(https 및 CDN), Route53(도메인 구입 및 연결), CodePipeline/CodeDeploy/CodeBuild(배포 자동화), Parameter Store(서버 환경변수 연결), Certificate Manager(https 인증서) 까지. 깊이 파고들기에는 방대한 양이었지만 이제 최소한 서버와 클라, 데이터베이스를 연결하고 배포를 할 수는 있겠다는 생각이 드네요.
클라이언트
클라이언트 배포에서 가장 힘든 지점은 왜 내가 배포한 결과물이 즉각적으로 반영되지 않는가 입니다. S3, Route53, CloudFront 를 이용해 클라이언트를 배포하고 있다면 다음의 과정을 거쳐서 무엇이 문제인지를 확인할 수 있습니다.
-
S3 의
버킷 웹사이트 엔드포인트로 접속해 빌드한 결과물이 잘 반영되었는지를 확인합니다. 만약 배포 자동화를 구현해두었는데 S3 에 제대로 반영되지 않았다면 자동화의 문제부터 짚고 넘어가야 합니다. -
S3 에 결과물이 잘 반영되었다면 그 다음은 CloudFront 입니다. 이 과정에서는 같은 도메인으로 접속해도 서로 다른 버전을 경험하게 되기도 하는데요. 그 이유는 CloudFront 가 각지의 엣지 로케이션에 결과물을 캐시하기 때문입니다. 기본값이 24시간으로 설정되어 있기 때문에 결과가 반영되기까지 최대 24시간이 걸릴 수도 있는 것이죠. 빠르게 결과물을 반영하는 방법에 대해서는 이전에 블로깅으로 정리해둔 내용을 링크하도록 하겠습니다.
클라이언트는 기본적으로 빌드를 마치고 빌드한 결과물을 올리게 되어있습니다. 따라서 자동화 과정을 구현했을 경우, 환경변수는 빌드할 때 함께 적용되어야 합니다. 배포 과정에서 환경 변수를 적용하려면 CoreBuild 의 환경 편집에서 환경 변수를 추가하면 됩니다.
프로젝트 단계에서 자동화 과정은 대체적으로 5분을 넘기지 않았던 것 같습니다. 만약 이보다 더 긴 시간동안 자동화가 진행되지 않았다면 중간 과정 어디엔가 문제가 있다고 생각해도 될 것 같습니다.
지금껏 경험한 한도 내에서 도메인을 구입한다는 것은 도메인 이름 + 최상위 도메인 을 의미합니다. 구입한 도메인에 서브 도메인을 붙여 다른 용도로 활용하는 것이 가능하죠. 예를 들어 www.codestates.com 이라는 주소는 서브 도메인.도메인 이름.최상위 도메인 으로 구성되어있는 것이기 때문에 서브 도메인을 변경해 urclass.codestates.com 으로 만들어 전혀 다른 용도로 활용이 가능합니다.
클라와 서버도 이런 방식으로 나누는 것이 가능합니다. 하나의 도메인을 구입해 서브 도메인으로 나누어 사용하는 식으로 말이죠. First Project 에서는 시간이 부족해 이 부분을 제대로 이해하지 못해서 도메인을 2개나 구입해야만 했었습니다만, 배포에 대해 더 공부할 기회가 생기면서 Final 에서는 도메인 하나로 클라와 서버를 구축할 수 있었습니다.
서버
서버와 관련해서 가장 난감한 이슈는 환경변수의 문제였습니다. First 때는 결국 .env 파일을 생성하는 것으로 해결을 했었는데요. Final 에서도 이 부분을 해결하지 못하고 있다가 오늘 최종 배포를 하는 과정 중에 드디어 문제를 해결할 수 있었습니다.
해결은 의외로 간단했습니다. ec2 에 aws-cli 를 설치해주지 않아서 생긴 문제였습니다. 그러다보니 start.sh 안에 담아둔 환경변수를 설정하는 명령어들이 다 제대로 동작할 수 없었던 것이죠.
참고로 start.sh 안에 들어있는 환경변수 관련 명령어들이 제대로 동작하지 않는다고 해서 배포 자동화 과정이 멈추는 것은 아닙니다. 배포 자동화를 돌렸을 때 멈추는 일이 없이 성공 메시지를 띄워주다 보니 자동화에 문제가 있을 거라고는 생각하지도 못했었죠.
환경변수 문제를 해결하고 나니 자동화 과정도 매우 빨리 끝이 나는 것을 확인할 수 있었습니다. 일반적으로 1~2분 남짓한 시간이 걸렸는데, 기존에 서버 자동화 과정이 4~5분 정도가 걸린 것에 비하면 매우 짧은 시간이죠. 만약 서버 자동화에 생각보다 오랜 시간이 걸린다면 명령어가 제대로 동작하지 않는 것은 아닌지 의심해 볼 필요가 있습니다.
ec2 는 로드밸런서를 이용해 구입한 도메인을 연결할 수 있습니다. 자료를 찾다보니 예전에는 로드 밸런서라는 기능이 분리되어서 서비스 되었던 것 같더라구요. 이 글을 작성하는 현재 기준으로는 ec2 안의 사이드 메뉴에서 로드 밸런서 기능을 찾을 수 있습니다.
그 외에
freenom 에서 구입한 도메인의 경우 무언가 제대로 동작하지 않는 경우가 많았습니다. 특히 제가 사용했던 .tk 최상위 도메인이 그랬는데요. 다른 도메인들도 조금 들쭉날쭉한 경우가 많다고 합니다.
Route 53 에서 도메인을 구입하게 되면 여타 문제가 대폭 간소화되기는 합니다. 다만 비용이 발생하죠. 비용은 가장 싼 것이 5달러 정도였는데요. 짧고 의미가 강한 최상위 도메인일수록 비용이 비싸니, 도메인을 구입할 때 참고하시면 되겠습니다.
AWS 에서 배포 자동화를 진행하게 되면 시간을 기준으로 요금이 부과됩니다. 매일매일 배포를 진행하게 되면 요금이 부과될 수 있는 것이죠. 초반에 hello world 정도로 배포를 진행해두고, 로컬에서 어느 정도 구현이 될 때까지는 배포를 하지 않는 편이 요금 추가를 막을 수 있습니다.
