[ 이준형 애플리케이션 배포 자동화와 CI/CD #4 ] 무중단 배포에 대해

이번 내용에서는, 기존에 실행중이던 애플리케이션이 종료되고 새로운 애플리케이션이 실행되는 과정에서 발생하는 중단. 즉, 다운 타임을 없앨 수 있는 무중단 배포에 대해서 알아보자.

먼저, 지금 우리가 겪고있는 중단이 발생하는 이유에 대해 알아보고, 이 상황에선 어떻게 중단을 해결할 수 있을지 알아보자.

• 참고)
  
  • 우리는 현재 하나의 서버를 이용해서 서비스를 하고있다. 그리고 이 상황에서 새로운 버전의 애플리케이션을 반영하기 위해서, 기존 실행중이던 애플리케이션을 먼저 종료하고, 새로운 애플리케이션을 실행시켰다.
  • 여기서, 기존 애플리케이션이 종료되고 ~ 새로운 애플리케이션이 실행되기까지 그 사이에 중단이 발생하게 된다.

🤔 이것을 해결하기 위해서는 어떻게 해야할까?

다음과 같이 서버를 여러대 사용해서 서비스를 한다면 어떨까?

• 참고)
  
  • 이렇게 되면, 하나의 서버를 배포하고 있을 동안에, 다른 서버들은 사용할 수 있을 것 같다.
  • 그런데 이 방식에는 문제가 있다.
    
    • 클라이언트가, 접속을 시도하는 모든 서버의 IP 주소를 알아야 한다는 것이다.
      • 참고) 보통 서비스는 도메인 주소를 사용해서 접속하니까 문제없지 않을까라고 생각할 수 있겠지만, 도메인 주소로 여러 서버를 하나로 묶더라도, 배포 상황에서 즉각적으로 다른 서버로 연결되지는 않는다. 따라서 위와 같은 방식은 보완이 필요하다.

 

🤔 어떻게 보완하면 좋을까?

이런 경우는, 클라이언트가 서버를 각각 직접 바라보도록 하는게 아니라, (서버로 가는 요청을 중간에서 중개해줄 수 있는) 중개 서버를 바라보도록 구성하는 게 좋다.

• 참고)
  
  • 그 역할을 해줄 수 있는 솔루션 중 하나가 바로 NGINX 이다.
  • 참고) NGINX 역시 Jenkins 처럼 서버에 설치가 필요하다.

---

NGINX 를 설정해서 무중단 배포 환경을 구성하기 전에, NGINX 와 무중단 배포에 대해서 좀 더 알아보자.

먼저, NGINX 와 같은 솔루션을 이야기할 때, 여러가지 용어로 지칭을 하곤 하는데, NGINX 를 지칭할 때 언급되는 용어들을 살펴보면 다음과 같다. ( 참고로 이 각각은 사실 역할을 이야기 하는 것이다. )

• 리버스 프록시
  • 프록시: 클라이언트가 자신을 숨기기 위해 사용 (클라이언트 입장)
    
    • e.g. 다른 나라 OTT 같은 것을 보기 위해서 사용하는 VPN 같은 것도 일종의 프록시라고 이야기할 수 있다.
  • 리버스 프록시: 서버가 자신을 숨기기 위해 사용 (서버 입장)
    
    • 클라이언트가 원래라면, 각각의 서버에 대해서 알고 있어야 했지만, NGINX 가 중간에 끼어듦으로써, 서버의 존재들에 대해선 클라이언트가 알지 못하게 된다. 이 개념이 바로 리버스 프록시 라는 개념이다.
• 웹 서버
  • 웹 서버 - 정적 콘텐츠(HTML, JavaScript, 이미지 등)
  • 웹 애플리케이션 서버 - 동적 콘텐츠
  • 참고) 대부분의 웹 서비스에서는 정적 콘텐츠와 동적 콘텐츠가 함께 사용된다.
    • 모든 사용자에게 동일하게 보여줘야 할 데이터는 정적 콘텐츠로 제공하고,
    • 사용자마다 다르게 보여줘야 할 데이터는 동적 콘텐츠로 제공한다.
    • Q1) 웹 애플리케이션 서버만 사용을 해서 웹 서비스를 하면 안될까? (동적 콘텐츠, 정적 콘텐츠 모두 제공)
      • But, 일반적으로 웹 서비스를 구성할 때는 웹 서버와 웹 애플리케이션 서버를 모두 사용한다. 왜냐하면 정적 콘텐츠를 제공하는 데에는 웹 애플리케이션 서버보다는 웹 서버가 더 좋은 성능을 보여준다.
      • 따라서 보통 다음과 같이 서버를 구성한다.
        
        • 정적 콘텐츠라면 웹 서버가 응답, 동적 콘텐츠라면 웹 애플리케이션 서버에게 전달
• 로드 밸런서
  • 로드 밸런서는 번역하면 부하를 분산해 준다는 것을 의미한다.
    
    • 즉, 하나의 서버가 처리해야 할 요청을 여러개의 서버가 나눠서 처리할 수 있도록 만들어 준다. 이렇게 하면 각 API 서버가 받는 부하가 줄어들 수 있다.
• 게이트웨이
  • 마지막으로 게이트웨이로써의 역할도 있다.
    
    • 게이트웨이로써의 NGINX 는 요청이 어떤 서버로 라우팅되어야 할지를 지정해줄 수 있다.
    • 각종 인증/인가 설정도 가능하다. 또한 요청에 대한 로깅이나, HTTPS 에 대한 설정도 NGINX 에서 가능하다.
    • 이것들은 각각의 서버에서도 해줄 수 있는데 NGINX 가 하는게 특별한 게 있냐 ? 라고 할 수 있겠지만,
      • 각각의 서버에서 해주지 않더라도, 오직 NGINX 를 통해서 HTTP 요청과 응답이 들어오고 나가는, 관문 역할을 하기 때문에, 장점을 분명 가지고 있다.
      • (라우팅, 인증/인가, 로깅, HTTPS 설정 등) 여러가지들을 NGINX 하나에서 집중해서 관리할 수 있는 것이다.
        • 실무에서 서비스를 운영하다 보면, 집중화된 관리가 큰 장점으로 다가오기도 한다.
• 참고) NGINX 는 리버스 프록시 이기도 하면서, 웹 서버 이기도 하고, 로드 밸런서로써의 기능도 수행을 한다. 그리고 API에 대한 게이트웨이 역할도 수행을 한다.

 

✔️ 참고) 서버끼리 의존하는 상황은 되도록 피하는게 좋다.

• 애플리케이션을 개발하다 보면, 서버 내부에서 서버와 서버 사이에도 통신이 일어나는 것을 자주 경험한다.
  
  • 그렇게 되면, 결국 서버 사이에 의존성이 생기게 된다.
  • 이런 경우, 한 서버에 문제가 생기게 된다면 전체 시스템이 함께 동작하지 않을 수도 있다. ( 서버끼리 의존하는 상황은 되도록 피하는게 좋다. )
  • 따라서 서비스 내부에서 내부 서버간 통신을 할 때에는, API 통신보다는 kafka 같은 메시징 시스템을 사용하는 게 좋다.
    
    • 서버끼리 의존하지 않고, 오직 kafka 로 의존한다.
    • 서버간 통신을 kafka 로 대체하면, 많은 이점이 있다. ( 잘 구성만 하면, 서버간 API 통신보다 훨씬 안정적이기도 하고, 성능도 좋고, 데이터 분석에도 용이하다. )

 

지금까지 무중단 배포에 대한 개념과 NGINX 의 여러가지 역할에 대해 알아보았다.

다음 내용에서는 NGINX 를 서버에 설치해보고, NGINX 를 활용해서 무중단으로 배포할 수 있는 환경을 만들어보자.

---

강의를 듣고 정리한 글입니다. 코드와 그림 등의 출처는 이준형 강사님께 있습니다.