EtoC
배포(Deployment) 본문
배포란?
배포는 개발된 소프트웨어나 웹 어플리케이션을 다른 사람들이 접근할 수 있는 환경으로 만들어 개발된 소프트웨어르 실제 사용가능 한 상태로 만드는것.
사람들이 항상 서비스를 이용하기 위해서는 서버와 인프라를 구축하고 24시간동안 가동되게해야한다.
하지만 내컴퓨터를 24시간 돌리는것은 말이 안되고.. 항상 가동되는 컴퓨터를 제3자가 제공할 수 있는데, 이를 클라우드 서비스라한다.
클라우드 서비스는 퓨터를 일정 비용을 내고 구입해서 하루종일 서버를 켜놓을 수 있으며, 다양한 형태와 모델을 제공한다.
클라우드 서비스의 특징
1. 확장성(Scalability): 필요에따라 리소스를 확장/축소 할 수 있다.
2. 유연성(Flexibility): 다양한 서비스와 모델을 사용할 수 있다.
3. 자동화(Automation): 자동화된 관리/배포가 가능하며, CI/CD같은 개발프로세스를 효율적으로 지원한다.
4.엑세스 가능성(Accessibillity): 어디서나 접근이 가능하며 멀티ㅡㄹ라우드나 하이브리드 클라우드 환경을 쉽게 만들수있다.
1. 정적페이지 배포
기본적인 배포(1차적 배포)로, 만들어둔 서비스를 클라우드에 빌드하기만 하면 된다.
빌드후 build/boards 폴더안의 index.html을 다운해와서 브라우저에 표시하면된다.
하지만 이경우 storage 주소를 알려줘야하는 불편한 점이 있다.
이경우 도메인을 주소를 사서 그 주소를 storage 주소와 바꾸는 DNS 서비스를 사용하면 된다.
(AWS에서 기능을 제공하는데 Route53이라 한다.)
DNS(Domain Name system)
트래픽이 많아져도 클라우드 서비스에서 트래픽 관리를 해주기때문에 안정적인 장점이있다.
단점은 다이나믹 라우팅된 주소를 사용할경우 들어오는 값이 바뀌는데 그 값과일치하는 폴더를 board안에 일일이 생성할 수 없기때문에
데이터가 왔다갔다하는 동적인 페이지에서는 사용하기 힘들다.
때문에 다이나믹한 데이터가없는 간단한 소개 홈페이지를 배포하는데 사용된다.
2. 동적인 페이지 배포
프론트엔드의 서버를 켜고 브라우저에서해 프론트엔드 서버에 접속한다.
그러면 DNS가 프론트엔드의 IP주소로 바꿔주고, 그 IP주소에서 index.html 파일을 받아온다.
쉽고 간단하며 안정적이기때문에 가장 많이 사용되는 배포 방식이다.
storage에서는 불가능했던 동적인 주소를 사용할 수 있다.
index.html 이 없더라도 빌드명령어를 통해 프리랜더링된 index.html을 생성하여 전달해준다.
보통 배포를 할때 위의 2가지 방법을 사용하는데, 사용하는 컴퓨터가 1대이기때문에 많은 사용자가 접속시 부하가 높아지는 문제점이 있다.
이경우 scaleup, scaleout을 할 수 있다.
이런 부하를 낮추는 방법으로는 부하분산기(Load Balancer)를 사용하는 방법이 있다.
3. 로드 밸런싱
로드밸런스도 IP주소가 있기때문에 DNS는 로드밸런싱의 IP주소로 바꿔준다.
로드밸런서에는 트래픽을 분산하여 프론트엔드 서비스로 이동시켜준다.
이때 클라우드에서 어떤 알고리즘을 통해서 분산해주는데 주로 round-robin과 least-connection 알고리즘을 사용한다고한다.
round-robin : 한명씩 한명씩 돌아가며 분배하는 알고리즘
least-connection : 접속자가 최소인 곳에 접속을 몰아주는 알고리즘
트래픽이 초과될경우 컴퓨터를 사서 인스턴스 그룹안에 생성해두면 로드밸런서가 알아서 트래픽을 분배해준다.
또한 로드밸런서에 조건을 등록해두면 자동으로 컴퓨터를 복제하여 만들어 분산해주는 기능이 있는데 이를 auto-scaling이라한다.
오토스케일링
auto scaling(자동확장)
클라우드 환경에서 메모리나 CPU가 지정된 수치이상 넘어가는 경우 자동으로 인프라를 확장하거나 축소하여 성능과 가용성을 최적화하는 기술이다.
클라우드에서 오토 스케일링을 지원하면서 배포가 상당히 간단화 되었다.
하지만 배포후에 고도화나 롤백같이 관리해야할 일들이 디테일해지고 많아졌다.
큰 회사일 경우 배포팀(데브옵스팀)이 따로 만들어지기도 한다고한다.
데브옵스
DevOps(Develop & Operation)
클라우드 서비스를 잘 활용하여 개발과 운영을 함께 하는 사람들
로드밸런서를 사용함으로써 트래픽에 관한 문제는 해결되었으나 저 많은 컴퓨터들이 제대로 실행되고 있는지 모니터링 해야한다.
만약 실행되고 있지않다면 트래픽을 넘겨주더라도 접속한 컴퓨터에 문제가 있다면 사용자는 페이지가 뜨지 않는 문제가 발생 할 것이다.
서비스가 너무 커지고 트래픽이 더 늘어나서 안정성을 좀 더 높이고 싶다면 CDN을 사용하는 방법이있다.
4. CDN
정적인 페이지는 storage를 사용하고 동적인 페이지는 서버에 배포를 두 곳에 하게된다.
만약 소스코드가 바뀌게된다면 당연히 두군데 다 배포를 해야한다.
DNS를 통해 CDN에 접속하게되면 CDN은로 정적페이지(/boards)라면 S3로, 동적페이지(/boards/*)라면 로드밸런서로 이동하도록 분기처리를 해준다.
프론트로 학원에서 알려준 배포가 너무 간단해서 S3로 배포하는 거라는건 알았지만
언제 S3로 배포를 해야하는지 vercel로 해야하는지 이런걸 몰랐다.
공부를 해보니 aws S3에 build하는 방법은 가장 기초적이고 쉬운 배포였다.
머릿속에 어지럽게 흩어져있던 개념들이 그림으로 그려보니까 이해도 되고 좋다.
왜 직접 그려보라는지 알겠다.