Deployment
Deployment란 Build 된 파일을 WAS 등의 Application을 제공할 Server에 올려 사용자들이 실제로 이용할 수 있도록 하는 것이다.
여기서 Build란 Application의 소스코드를 실제로 활용할 수 있는 실행 파일로 변환하는 과정을 말한다.
Packaging
Build 과정이 Application의 소스코드를 실제로 활용할 수 있는 실행 파일로 변환하는 과정을 말한다고 위에서 언급했다.
그리고 이 Build 과정에서 Build Tool이라는 것이 활용되는데 이 Build Tool이 하는 역할 중 하나가 패키징이다.
Build 과정은 아래와 같은 단계로 이뤄진다.
먼저 설정했던 Dependency들을 다운로드한다. 이후 Source Code를 Binary Code로 컴파일하게 된다.
이후 Binary Code를 Packaging 하여 Server에서도 실행 가능한 파일로 만들어 준 뒤 테스트를 실행, 모든 테스트가 정상적으로 진행되면 실제 운영 환경에 Build 된 실행 파일이 배포(Deployment)되는 과정을 거친다.
조금 더 자세히 들어가자면 Compile 하여 만들어진 Binary Code를 Link 과정과 Packaging 과정을 거쳐 실행 파일로 만들어주는 것인데 이 부분은 Build에 대한 CS 지식을 공부할 때 제대로 알아보는 것을 추천한다.
일단 지금 단계에서는 Source Code를 실행 파일로 만들어주는 과정이라고만 이해하고 넘어가자.
이번 Deployment & Packaging에서는 과연 개발한 Application을 "어떻게" User가 사용할 수 있게 하는지에 대한 방법론에 대해 알아볼 것이다.
Physical Server
Physical Server란?
물리 서버라고도 부르는 Physical Server는 우리가 가장 직관적으로 이해할 수 있는 서버 형태이다.
우리는 보통 "서버"라는 것을 생각할 때 커다란 서버실에 여러 대의 고사양 컴퓨터가 들어가 있는 것을 생각한다.
그리고 이런 실제 고사양 컴퓨터를 통해 운영하는 Server를 "Physical Server"라고 부른다
Physical Server란 서버를 위한 HW를 직접 구입하고 환경 설정을 수행하여 운영하는 서버를 의미한다.
사실 물리 서버는 우리가 사용하는 일반 컴퓨터보다 매우 고사양이라는 점을 제외하면 사실 똑같은 컴퓨터라고 이해해도 될 것이다.
Physical Server는 구성된 HW에서 Server에서 수행해야 하는 모든 일을 처리해야 하기 때문에 Memory, 하드 드라이브, Network Connectivity, OS, 내부 HW 자원들을 위한 Application들이 모두 포함되어 있어야 한다.
즉, Server가 수행해야 하는 일을 처리할 수 있는 HW를 구매하고 설치해줘야 실제 Server로 활용할 수 있다는 의미이다.
사실 말로 하니 어려워보이지만, 개념은 매우 간단하다.
Spring을 통해 웹 개발을 수행하고 Local 컴퓨터에서 개발한 Application을 실행해보자. 이후 우리는 localhost:8080이라는 URI를 통해 개발한 Application에 접근할 수 있다.
이 경우에 Local Computer 자체가 하나의 작은 Physical Server가 되는 것이다.
즉, Physical Server의 개념은 어려운 것이 아닌 Application을 실제로 배포시켜 실행시킬 수 있는 HW Server라고 이해하면 되는 것이다.
Physical Server 단점
사실 물리 서버가 존재하지 않으면 이후에 배울 Virtual Server, Conatiner들도 모두 활용할 수 없게 된다.
하지만 이런 물리 서버를 직접 구축하고 활용하는 데에 있어서는 많은 단점이 존재한다.
매우 비싼 초기 비용
Physical Server를 활용하기 위해서는 우선적으로 HW를 구매해야 한다.
그런데 물리 서버를 위한 HW Spec은 당연히 높아야하고, HW는 Spec이 높을수록 가격이 천정부지로 뛰게 된다.
그렇다고 HW를 모두 구매한 뒤에 비용이 들지 않는 것도 아니다.
HW를 구매하였다면 이를 조립해야하고, Server에서 활용할 수 있는 OS를 구매해야 할 것이다.
또한 운영자가 원하는 서버(http, ftp 서버 등)를 설치해야 한다.
따라서 Physical Server는 HW, SW를 0부터 직접 쌓아나가는 과정이 필요하기 때문에 초기 비용이 많이 들고 인적 자원도 많이 필요한 Server라는 것을 알 수 있다.
어려운 확장
트래픽이 많아질 경우 서버를 증설해야 할 필요가 있다.
위 사진처럼 Physical Server가 1개의 Web Server만 담당하도록 사용했다고 가정하자.
만약 Web Server에 트래픽이 많아질 경우 운영자는 서버를 증설해야 할 필요성이 존재한다.
그런데 Physical Server는 이미 사용하고 있는 Web Server만으로도 포화 상태이기 때문에 Physical Server에 새로운 Web Server를 만들 수는 없다.
결국 Physical Server에서는 서버 증설을 위해 처음 Physical Server를 구축했던 것처럼 HW를 구매하고, 조립하고, 필요한 OS 및 서버 등을 까는 과정이 반복되어야 할 것이다.
만약 이 과정에서 처음 구축한 Server와 설정 값이 조금이라도 다를 경우 커다란 문제를 발생시킬 수도 있으며, Application이 제대로 동작하지 않을 수도 있다.
즉, Server 확장에 드는 비용도 만만치 않은데 확장에 대한 안정성도 떨어진다는 단점을 가지게 되는 것이다.
낮은 사용률
Physical Server를 활용할 경우 사용률이 낮아진다는 단점도 존재한다.
Server에서 구동되는 Application의 사용률이 100%가 되기는 사실상 쉽지 않다. 하지만 사용률이 100%가 아니더라도 특정 기능에 몰리는 Traffic 문제를 해결하기 위하여 어쩔 수 없이 Physical Server를 확장시켜야 하는 경우도 존재한다.
예를 들어 Application A는 사실 10%의 사용률만 보인다. 문제는 10% 사용률 중 8%가 예약 시스템에 몰려 있으며, 이 8%로 쏠려 있는 Traffic을 처리하기 위해서 서버를 증설해야 할 수도 있다.
이 경우 Application 1개의 Size는 변하지 않기 때문에 예약 시스템을 제외한 다른 Application 기능들도 Physical Server에 올라가게 되고, 이는 그대로 메모리의 낭비로 이어지게 된다.
즉, Traffic을 처리하기 위하여 서버를 확장했지만 Traffic이 몰리는 기능은 한정되어 있을 경우 해당 기능을 제외한 다른 기능들까지 Server에 올라가게 되어 메모리 낭비로 이어지는 문제점이 발생하는 것이다.
Resource 할당 문제
위 사진에서는 1개의 Physical Server에 1개의 Web Server만 올렸지만 사실 1개의 Physical Server에 여러 개의 Web Server가 올라갈 수도 있다.
문제는 이 경우 Resource 할당 문제가 발생할 수 있는 것이다.
Physical Server 1개에 여러 개의 Application을 실행시킬 경우 Resource 경계를 설정하는 방법이 존재하지 않는다.
따라서 5개의 앱이 실행되고 있는 Server에서 만약 1개의 Application이 너무나 많은 Physical Server 자원을 활용할 경우 다른 4개의 Application이 활용해야 할 자원이 부족해져 다른 4개의 Application 성능이 저하되는, 그렇다고 많은 자원을 활용하는 1개의 Application의 성능이 좋아진다는 보장을 할 수도 없는 최악의 상황이 발생하게 된다.
Physical Server 활용을 추천하는 경우
사용 가능한 Resource를 1개의 Application에게 할당하고 싶은 경우
Physical Server는 1개의 Application만 Server에 배포할 경우에는 가장 좋은 선택일 수 있다.
Applicatoin에 대한 사용자가 적어 Traffic이 몰릴 걱정이 없는 경우 굳이 Physical Server를 나누어 여러 개의 Application을 띄울 필요성이 존재하지 않는다.
따라서 이 경우 초기 비용이 조금 들더라도 Physical Server를 구축해 1개의 Application에 Physical Server의 전체 자원을 할당함으로써 Resource 할당 문제가 발생하는 것을 막고 OS나 서버 등을 편하게 관리하는 것이 좋다.
가상화가 불가능한 HW를 사용하는 경우
모든 HW가 가상화가 가능하여 Virtual Server로 활용할 수 있으면 좋겠으나, 현실에서는 그렇지 않다.
Server에서 활용해야 하는 HW 중 가상화가 불가능한 것이 존재하면 어쩔 수 없이 Physical Server를 활용해야 한다.
IT팀이 Server에 대한 설정에 기술력이 존재하여 Server에 대한 직접적인 작업이 많은 경우
Physical Server는 HW와 OS 등의 SW를 IT팀이 직접 권한을 가져 관리할 수 있다는 장점을 가진다.
Cloud 같은 경우 외부에 존재하는 HW 및 SW를 빌려 쓰는 방식이기 때문에 사용자가 직접적으로 핵심 시스템에 대한 수정이 불가능하다.
하지만 Physical Server는 IT팀이 Server에서의 가장 높은 액세스 권한을 가지고 있기 때문에 핵심 시스템에 대한 설정값이라고 해도 설정값들을 변경할 수 있게 된다.
따라서 IT팀이 Server 설정 및 운영에 전문성이 있을 경우 사용자의 Needs나 Traffic 같은 문제에 가장 최적화된 Server 설정을 수행할 수 있으므로 서버 운영에 있어 큰 효율성을 가지게 될 것이다.
