[DevOps] GCP 하나의 LB로 여러 서비스 운영하기

개요

로드 밸런서는 운영관리 입장에서 상당히 많은 편의성을 제공한다.

그래서 그런지 규모가 작은 프로젝트 즉, "부하 분산"이 필요없는 프로젝트임에도 불구하고 정말 많은 사람들이 로드 밸런서를 활용한다.

 

그런데 나의 경우, 작은 프로젝트에 LB를 쓰는게 그 기술의 취지에 맞지 않고, 그렇기에 많은 자원이 낭비가 된다는 생각에 쓰기가 싫었다. (뭔가 괜히 패배하는 기분이랄까..?)

 

여기서부터 지옥 시작이었다.

 

이게 그 당시의 나를 설명하는 짤....

 

포트로 분리된 서버에 LB 없이 하나의 서버로 각각의 포트에 SSL을 적용하는 테스크를 진행 (이 가설엔 논점이 굉장히 많은데, 다른 포스팅에서 다뤄보겠다.)했는데, 사실 이건 로드 밸런서로 뚝딱뚝딱 1-2시간이면 할 수 있는 업무다.

 

[사건의 발단🥹] 그런데 위와 같은 이유로 로드밸런서를 사용하기 싫었고, 일일이 수작업을 하기로 했다. ➡️ 심지어 이 수작업을 하는 기술들을 한국에서도 많이 사용하고 있었고(certbot) 의심없이 시작을 했지만, 결국 해내지 못했다!

그래서 패배를 인정하고 로드밸런서를 각각 서버마다 만들어서 쓰게되었다. 

 

 

운 좋게도 회사에서 비슷한 솔루션(?)과 같은 업무가 주어져서 이 삽질에 대해 다시 생각해볼 기회가 생겼다.

 

솔루션은 로드밸런서 하나로 여러 서버를 운영해보는 것이었다. 처음엔 이 아키텍처가 위와 똑같은 이유로 이해가 안됐다.

로드 밸런서는 부하를 분산하는 것인데, 다른 여러 서비스(멀티 모듈)로 분산을 설정 해버리면 어떢함??? 아키텍처에 맞지 않아! 이런 생각이 나를 지배했다.

 

---

 

그런데 이 아키텍처 설계의 의도를 생각해보면, 그냥 있는 기술을 나의 상황에 맞게 잘 설계한 것이다.

 

시중에 나온 기술을 어떻게 응용할 수 있냐에 따라 구축할 수 있는 건 무한했고, 기술을 잘 사용하기 위해서는 유연성과 응용력이 정말 필요한 소양이라는 깨달음을 얻었다. 정석대로 하는 것이 반드시 좋은 결과로 도출되는 건 아니다! 나의 꼼꼼함에 유연성을 첨가하자...

---

설계

 

• 여러 서브 도메인을 하나의 로드 밸런서 라우팅을 통해 이용한다. (로드밸런서가 주는 설정 편의가 크니까)
• 주의할 점
  • 트래픽이 급격하게 많이 몰리면 당연히 이런 구조는 당연히 장애가 발생한다. (부하 분산을 하나의 서비스에 대해 하는 것이 아니니까) 따라서 테스트 서버 등과 같이 비용 절감이 필요하되, 로드 밸런서의 편의성이 필요한 곳에만 한정하여 사용한다. 

 

크게 구조는 다음과 같다.

---

사용할 로드밸런서 생성

위 아키텍처처럼, default 서버를 제외하고는 라우팅을 해서 사용할 거기에 로드 밸런서 하나를 설정해준다. 

 

 

 

서브 도메인 지정

사용하는 도메인 서비스에 A 레코드로 각각의 테스트 서버 A, B, C 서브 도메인을 생성한다. 이때, 각각에 로드밸런서 외부 IP를 등록해준다.

 

 

 

 

로드밸런서 설정

필자는 GCP 서비스로 이 테스크를 진행했다. (사이드 프로젝트는 AWS로 사용하고 있어서 주요 API 개발이 끝나면 AWS 클라우드에서도 POC를 해볼 예정이다. POC가 완성되면 과정을 추가하겠다. 🤗)

 

필요한 것들을 설정해준다.

ssl 인증서를 로드밸런서 없이 여러 서버에 한번에 적용해보면, 로드밸런서가 정말 편한 서비스임을 알 수 있다...... 

 

 

사용할 백엔드 버킷은 총 3개이므로, 3 개를 모두 추가한다. 이후 라우팅 규칙에서 이를 구분한다.

 

 

 

 

아래 호스트 및 경로 규칙 추가를 누르고, 라우팅할 각각의 서브 도메인과 서버를 연결해준다.

 

 

 

---

 

결과 확인

 

 

 

 

각각의 서브 도메인으로 접속이 잘 되는 것을 확인하였다.

개인적으로 어떤 가설을 세워서 검증하는 과정 자체가 재밌었고, 깨달음이 많은 작업이었다.