[Server]운영 서버에 대한 정리

🪙운영서버 

---

운영 서버는 개발이나 테스트 목적이 아닌 실제 사용자들을 대상으로 서비스하는 서버를 의미한다. 테스트 목적의 서버라면 많은 요청이 발생할 일도 없고 장애가 발생하더라도 금전적인 문제나 큰 문제가 발생하지 않는다. 하지만 운영 서버는 테스트 목적의 서버와는 다르게 트래픽 대응도 해야 하고 빠은 응답 속도와 높은 가용성을 보장해야 한다. 그러기 위해서는 운영 서버는 테스트 서버와 다르게 다양한 구성 요소를  포함해야 한다.

 

운영 서버 관리에는 세 단계가 있다. 운영 서버 관리는 크게 '환경 구성' , '코드 배포' , '모니터링'으로 나뉜다.

• 환경 구성은 서비스할 코드를 구동시킬 수 있는 서버 인프라를 구축하는 것이다.
• 코드 배포는 환경 구성 과정에서 구성한 최신 버전의 코드를 빠르고 안전하게 배포하는 것이다.
• 모니터링은 안정적인 서비스 운영을 위해 서버와 코드에 어떤 이상이 없는지 바로 파악하고 대응할 수 있게 도와준다.
• 위처럼 운영 서버 환경 구성을 AWS(Amazon Web Services)라는 클라우드 서비스로 할 수 있다.

 

🪙클라우드 서비스(AWS) 플랫폼을 써야 하는 이유

---

꼭 AWS를 쓰지 않더라도 클라우드 서비스 플랫폼은 기존의 운영 서버 관리 방식보다 훨씬 많은 이점을 가져다준다.

블로그에서 다른 클라우드 서비스도 있지만 지금 공부하는 클라우드 서비스가  AWS(Amazon Web Services)이기 때문에 예를  AWS(Amazon Web Services)로 들것이다.

예전에는 서버를 직접 구매한 후 회사나 IDC에 설치해서 관리해야 했다. 이 서버들이 문제없이 돌아가게 하기 위한 전문 인력들이 필요했다. 서버뿐만 아니라 서버에 설치되는 수많은 인프라에 대해서도 전문 인력들이 필요했다. 그리고 유연하게 서버를 늘리거나 줄이기 힘들기 때문에 서버를 넉넉하게 구매해놓고 사용하지 않는 비효율적인 자원 낭비가 심했다.

하지만 클라우드 서비스를 이용할 경우 필요한 사양의 서버를 몇 번의 클릭만으로 추가하거나 제거할 수 있고 사용한 시간만큼만 금액을 지불하게 된다. 또한 클라우드 서비스 제공 업체에는 전문적인 인력들이 있어서 개개인이 안정성이나 성능에 대해서도 고민을 줄일 수 있다.

즉 훨씬 적은 비용 , 시간, 인력으로도 큰 규모의 서비스를 운영할 수 있는 것이다.

 

 

🪙운영 서버 구성 

---

1. 단일 서버

가장 기본적인 구성이다. 요청을 보내는 클라이언트와 요청을 처리하는 서버가 한 대 있다. 여기서 얘기하는 클라이언트는 우리가 흔히 사용하는 휴대폰 앱이나 크롬 같은 웹 브라우저 등을 의미한다. 서버 내에는 애플리케이션 코드와 데이터 베이스가 실행된다. 매우 단순한 구성인 만큼 환경을 구축하기 쉽기 때문에 테스트 서버나 간단한 애플리케이션을 서비스할 때 많이 사용된다. 그리고 데이터베이스와 애플리케이션이 같은 서버에서 실행되고 있기 때문에 별도의 네트워크 설정을 할 필요 없이 로컬 호스트를 상대로 테스트를  할 수 있다. 그러나 생각보다 많은 단점이 존재한다.

• 전체 서비스에 장애가 생길 확률이 높다.
  • 애플리케이션과 데이터베이스가 같은 자원을 공유하기 때문에 둘 중 하나라도 자원을 모두 사용 해버 리거나 서버 하드웨어에 장애가 발생하면 서비스 전체가 죽어버린다.
• 서버 자원을 효율적으로 사용하기 어렵다.
  • 애플리케이션과 데이터베이스는 각 속성에 따라 더 중요한 자원의 종류나 최적화를 위한 OS설정(I/O 컨트롤러, 디스크 설정)이 다를 수 있다.
  • 둘 다 만족시키기 위해서는 필요 이상으로 고사양 서버를 사용해야 할 수도 있다.
• 보안성이 떨어진다.
  • 데이터베이스는 보안상 포트나 IP 등 접속 지점을 최소한으로 하는 것이 좋다. 하지만 웹 애플리케이션 특성상 다양한 IP주소와 포트 번호에 대해 요청을 받을 수 있어야 하고 서버 내 여러 파일들도 업로드될 수 있으므로 데이터 베이스가 공격당할 가능성이 높아진다.
• 서버의 수를 여려대로 늘려서 자원을 확장하는 스케일 아웃(Scale out)이 힘들다.
  • 서버를 여러 대로 늘려야 하는 경우 클라이언트에서는 추가된 서버들의 주소를 새로 알아야 하며 데이터도 똑같은 복제본이 생기므로 비효율적이고 관리하기 힘들어진다.

 

2. 애플리케이션 /데이터베이스 서버 분리

단일 서버 구성에서 데이터베이스를 별도의 서버로 분리한 구성이다. 애플리케이션과 데이터베이스가 다른 자원을 사용하기 때문에 단일 서버에서 나온 전체 서비스 장애 확률, 효율적인 자원 사용, 떨어지는 보안성과 같은 단점들이 해결된다. 

다만 서버 두 개를 관리하기 때문에 구성이 조금 더 복잡해지고 서버 사이의 지연 시간과 네트워크 보안을 고려하기 시작해야 한다. 그리고 클라이언트에서는 하나의 서버를 바라보고 있기 때문에 서버 자원 확장을 위해 서버의 수를 늘리는 스케일 아웃(Scale out)은 여전히 힘들다.

 

 

3. 서버 단위의 로드 밸런서

 

클라이언트가 애플리케이션을 실행하는 서버와 직접 통신하는 대신 로드 밸런서라는 서버와 통신하고 그 뒤에 여러 대의 애플리캐이션 서버를 두는 방식이다. 클라이언트는 로드 밸런서 하고만 통신하고 로드 밸런서가 클라이언트에게 받은 요청을 뒤에 있는 서버들에게 나눠준다. 뒤에 있는 서버들이 요청을 처리하면 로드 밸런서를 통해 클라이언트에게 전달된다.

이 구성의 가장 큰 장점은 스케일 아웃이 가능해진다는 것이다. 애플리케이션 서버 중 일부 서버에 장애가 발생해도 로드 밸런서에서 정상 서버에만 요청을 주면 되기 때문에 서비스 장애를 최소화할 수 있다. 다만 모든 요청이 로드 밸런서를 통해 지나가기 때문에 로드 밸런서에 장애가 생기면 나머지 서버들이 정상이어도 전체 서비스 장애로 이어지기 때문에 주의해야 한다. 그리고 구성이 매우 복잡해진다는 단점이 있다.

+OSI 7 Layer의 L4 스위치라고 얘기하는 것이 이 로드 밸런서의 역할을 하는 장비다.

4. 서버 내 앱 단위의 로드 밸런서 

 

여러 서버에게 요청을 분산하는 서버 단위의 로드 밸런서 외에도 여러 애플리케이션 프로세스들에 요청을 분산시키는 애플리케이션 단위의 로드 밸런서가 추가됐다. 애플리케이션 서버 안에서 똑같은 애플리케이션을 여러 프로세스로 만들어 실행해 놓고 외부에서 들어온 요청을 프로세스 중 하나로 보내주는 역할을 하는 방식이다. 이처럼 구성할 경우 하나의 서버에 여러 개의 프로세스를 실행에 하나의 서버에서 여러 개의 요청을 동시에 처리할 수 있으며 서버 자원을 최대한으로 사용할 수 있는 만큼의 프로세스를 실행해 서버 자원도 더욱 효율적으로 사용할 수 있다.

 

 

---

REFERENCE

• 서비스 운영이 쉬워지는 AWS 인프라 구축 가이드