시작 전 몇몇 오류
- EC2를 계속 켜놨음에도 ip주소가 재설정되었음.
- Jenkins도 속도가 느려졌는데, Jenkins setting->systen -> Jenkins URL을 맞게 설정하니까 속도가 돌아옴.
- Github Webhook의 주소도 바꿔야됨.
ip변경 이후 재대로 들어오는거 확인함.
Todo = IP 고정
아키텍처
이전에 구성했던 아키텍처를 보자.
Github -> GithubAction이라고 적어놓은것도 모자라서
AWS CodeDeply와 LoadBalance 까지 집어넣는 등 난리가 났다.
지금 CI 구현을 한 것을 다르게 말하자면
이렇게 표현할 수가 있겠다.
아키텍처를 짤때 뭐가 뭔지 몰라서 막 넣은거 같다.
이후 어떻게 해야되나 생각을 해봤다.
먼저 로드밸런싱을 할 예정이다. 서버를 여러개 만들어 가동하게 되면 하나의 서버가 멈춰도 나머지 서버로 운영이 가능하고, 무엇보다 무중단 배포가 마음에 들었기 때문이다.
로드밸런싱?
레퍼런스 : https://en.wikipedia.org/wiki/Load_balancing_(computing)
간단하게 알아보면
- 내부 내트워크 구조를 숨길 수 있다.
- 실서비스 서버들을 관리하는 역할을 수행한다.
여기서 역할 관리라는 측면에서 봤을때
Admin용 서버를 하나 만들어서 라이브 테스트도 가능하겠구나하고 생각했다.
이처럼 로드밸런싱은 단순히 서버의 부하를 줄이거나 안정도를 높히는것 뿐만 아니라
Admin의 마음대로 테스트 할 수 있는 라이브서버 확보, 무중단 배포 등의 이점이 있다고 생각한다.
하지만 여기에는 크나큰 단점이 있다.
그것은 바로 내 서버가 넉넉하지 못하다는 것이다.
젠킨스에 빌드 요청을 5번 돌리니 이모양이다.
이게 왜 심각한거냐면 지금 Jenkins 빌드는 단순히 Hook을 이용해서 데이터를 가져오는것 뿐이고, 복잡한 빌드를 하지 않기 때문에 코드의 크기가 커졌을때 어느정도 용량을 먹는지 알 수 없다.
서버 인스턴스의 성능이 좋지 않은데 꼭 써야하나 싶다.
로드밸런싱이 서버에 부하를 줄인다는 것은 독립적인 인스턴스에 있는 서버를 말하는 것이지,
하나의 서버에 서로 자원을 나눠서 쓰는곳에 해당하는 것은 아니다.
따라서 앞으로의 중요한 과제로는
- 서버의 과부하를 어떻게 잡을 것인가
- 로드밸런싱을 성공적으로 할 수 있는가
- 사이트가 성공적으로 배포될 수 있는가
3개로 나뉜다고 보면 되겠다.
로드밸런싱이 나한테 유용한가?
위의 글을 보면
'그냥 인스턴스 좀 좋은거 쓰면 되는거아님?' 이라고 생각할 수 있다.
하지만 프리티어 인스턴스를 쓰고 있기 때문에 더 좋은 인스턴스를 쓴다면 요금을 지불해야 한다..
따라서 수직적 규모 확장 보다는 수평적 규모 확장을 노려야 한다.
그런데 여기서도 문제가 되는것이 있다.
프리티어는 1달에 750시간 무료다
그 말이 무엇인고 하니, 인스턴스 2개를 쓰면 1달에 30일 기준 720*2, 1440 시간을 사용하는데
그러면 얄짤없이 750-1440 = 690 시간의 요금을 지불해야 한다
따라서 사실상 수평적 규모 확장도 아무짝에 쓸모가 없다.
왜?
어짜피 인스턴스 하나인데 로드밸런싱의 분산서버 효과를 받을 수 있나?
-> 절대없음
왜냐?
인스턴스 하나로 여러개의 서버를 돌렸을때
이 인스턴스가 터지게 되면(작동을 멈추면) = 전체 서버가 다운 된다.
따라서 로드밸런싱을 그렇게 말을 했고 중요성도 인지했음에도 불구하고
나는 로드밸런싱을 할수도, 할 이유도 없다.
억지로 하나의 인스턴스에 여러개의 서버를 띄우면 로드밸런싱이라는 구조는 만들 수 있겠지만
과연 이것을 성공적인 로드 밸런싱이라고 봐야 할까?
난 아니라고 본다.
따라서, 로드밸런싱 부분은 과감하게 빼는게 맞다고 본다.
이런 고민을 하는데 몇시간을 쓴 줄 모르겠다.
하지만 토이프로젝트의 성격을 띈다고 해도, 과도한 비효율을 감안하고서 도입할 이유는 없다고 생각한다.
물론 여기서 인스턴스를 여러개 쓰고 Nginx/Jenkins 인스턴스 + 분산서버 인스턴스 여러개
를 한다면 실질적인 로드밸런싱 효과를 받게 된다.
하지만
t2.micro 인스턴스 기준 1달에 7천원 이상의 돈이 나간다.
위의 글로 봤을때
- Jenkins + Nginx 인스턴스 하나
- 로드밸런싱용 서버(3개~)
를 하면 적어도 4개정도는 써야되며
로드밸런싱을 공부하는 비용 + DB 로드밸런싱 시간 + 요금 까지 추가적으로 붙을 것이다.
월 5만원 이상이 예상되며(여기에 적진 않았지만 DB도 인스턴스 종료를 예상해 여러개의 DB를 가진다) 이는 상당한 부담으로 예상된다.
따라서
과감하게 로드밸런싱을 빼버리기로 했다.
정글 프로젝트 할때 지원받은게 정말 큰거구나 세삼 느낀다.
결론
- 로드밸런싱 좋아보여서 알아봤는데
- 인스턴스 여러개 써야 해서 프리티어를 넘어섬
- 금전적인 문제로 포기
- 결국 로드밸런싱도 돈으로 성능을 사는 거였다
- (혹시나) 사이트가 커져서 광고수익이 나온다면 트래픽 문제 때문에 가능하지 않을까?
그럼 배포는?
역설적이게도 로드밸런싱을 써야 한다
(이랬다 저랬다 장난하나)
안쓰겠다고 저리 길게 설명해놓고 뭔소리냐 라고 할수있다.
하지만 위에서 말했다시피 무중단 배포를 할 계획이다.
레퍼런스 : https://www.nttdata.com/global/en/insights/focus/service-pauses-on-release-is-a-thing-of-the-past--non-stop-deploy-strategies-by-argo-rollouts
위는 무중단 배포중 하나인 Blue-Green 배포 방법이다.
- Blue 서버를 운영한다.
- Green 서버를 만들어서 업데이트를 배포한다
- Green 서버로 라우팅 하고
- Blue 서버를 닫는다.
위와 같은 작업을 하게 되면
본 서버를 켜놓은 상태로 배포가 가능해진다!
그러니까 업데이트 하는동안 서버도 정상적으로 돌아간다는 소리다.
이 외에도 카나리아, 롤링 배포가 있지만
단일 서버를 사용하기에 둘다 의미가 없다.
왜냐면 카나리아 서버를 만들지도 못할 뿐더러
롤링배포를 하게 되면 그게 BlueGreen배포가 된다.(롤링 할게 없음)
따라서 제한적인 상황에(배포) 선택적으로 로드밸런싱을 사용하겠다는 것이다.
Nginx vs ELB
사전지식
ELB는 Elastic LoadBalancer이란 뜻으로,
- ALB = 7계층(HTTP/HTTPS)
- NLB = 4계층(TCP/UDP)
- CLB = 4~7계층
위 그림을 참고하자.
레퍼런스 : https://nginxstore.com/blog/aws/amazon%EC%97%90%EC%84%9C-load-balancer-%EC%84%A0%ED%83%9D-aws-application-load-balancer-vs-nginx-plus/
Nginx와 ELB를 비교해놓은 사이트 이다.
일단 여기서 먼저 짚고 넘어가야 할 것은
Nginx가 서버에서 돌아가는 패널티 이상으로 ELB보다 이득이 있는가? 이다.
그야 그럴것이 안그래도 인스턴스 용량 빡빡한데 Nginx까지 올려야 한다.
위의 레퍼런스 및 여러곳에서 얻은 정보를 정리하자면
Nginx
- 리버스 프록시 기능
ELB
- 오토스케일링(트래픽 많아지면 자동으로 서버늘림)
- SSL 암호화 지원
- ddos 같은 공격 자동으로 방어해줌
정도로 요약할 수가 있겠다.
근데 곰곰히 생각해보니까
ELB를 앞에 세우고 Nginx로 라우팅하면 안되나?
라는 생각을 했다.
아니 생각을 해보자.
- ELB 쓰면 돈이드나? (X)
- ELB 썼을때 이점이 있나? (SSL처리, 보안강화)
- ELB가 서버에 부하를 주나? (AWS에서 처리해줌)
따라서 Nginx와 ELB를 모두 사용해 무중단 배포도 구현해 보도록 하자.
여담
이번 글은 뭔가 횡설수설하는거 같다는 생각이 든다.
프레임워크와 기술에 대해 재대로 알지도 못하고 아키텍처부터 짜버려서 내가 뭘 하는지 감을 못잡는거 같다.
ELB - Nginx - Spring서버 배포 자동화만 시키면 이제 코딩 시작이다.
물론 프론트 서버를 S3에 올리는등 많은 작업이 필요할 것이다..
