프로젝트를 수행해본 개발자라면 클라우드 인프라 서비스를 이용한 서버 구축을 진행해본 경험이 있을 것이다.
오늘은 내가 해당 과정을 어떻게 수행했는지, 그리고 유지보수를 위한 새로운 방안에 대해서 이야기 해볼 것이다.
Ncloud Platform Service
내가 프로젝트를 수행하며 선택한 Cloud Platform은 Ncloud이다. AWS도 있지만 프로젝트 비용 지원을 받는 NCloud를 선택할 수 밖에 없었다.
NCloud Plaform Service에서도 충분한 서비스를 제공 받을 수 있었고, 내가 선택한 서비스는 당연히 서버 구축을 위한 Server Service였다.
DB와 WAS 서버를 위해서 각각 하나씩 Public, Private 서버를 구축해야 했다.
Reverse Proxy를 위해서 Nginx Web Server도 하나 만들어야 했는데 이는 다른 포스트에서 다루었으므로 넘어가겠다.
프록시 이해 및 적용하기 : https://velog.io/@rmsgur/%ED%94%84%EB%A1%9D%EC%8B%9CProxy-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0
여러 서버 타입이 있었는데 내가 선택한 타입은 Standard-g2서버 였다
추천 용도와 같이 내가 참여한 팀 프로젝트의 경우 완전한 회사의 프로젝트가 아닌 팀 단위로 성장을 위한 프로젝트를 수행하는 것이었기에 너무 많은 비용을 초래하는 다른 타입을 사용할 수는 없었다.
해당 타입에서도 충분히 트래픽을 통한 서버 부하 개선을 할 수 있을 것이라 판단하였고 팀원 모두가 동의했다.
운영체제는 Ubuntu 20.04버전을 사용했다. 20.04는 VPC Only를 지원한다고 써져있는데 마침 프로젝트에서 서버 구성을 위해 VPC를 사용할 계획이었으므로 20.04 버전을 사용했다.
VPC 설정
서버를 구성하기 전에 VPC 및 서브넷 설정을 먼저 적용해야 했는데, Classic을 사용하지 않고 VPC를 사용한 이유는 사용자 정의 네트워크로써 IP 주소 범위, 서브넷, 네트워크 게이트웨이, 보안 규칙 등을 내가 직접 설정할 수 있었기 때문에 클라우드에서 자체적으로 제공하는 Classic보다 이를 직접 관리해보고 싶어 선택했다.
VPC에서 CIDR 기반 IP 주소 할당을 위해서 네트워크/호스트 부분을 10.0.0.0/16으로 적용했는데 이것이 의미하는 것은 네트워크 식별 16비트/호스트 식별 16비트로 일반적으로 대규모 네트워크에서 사용되는 설정이다.
사실 프로젝트의 규모가 그렇게 크지 않으므로 네트워크/호스트를 24/8로 설정해도 되었지만 추후 확장성을 고려하여 범위를 크게 잡아놓았다.
ACL 설정
다음으로는 Network ACL 설정을 해야했다.
ACL은 Access Control List로 네트워크 보안에서 인바운드 , 아웃바운드 규칙과 같은 접근 제어에 대한 규칙을 설정하는 목록이라고 할 수 있는데, 예를 들어 was,db server를 vpc 내 private 서버로 둔다 하더라도 각 서버들이 통신하는 ip는 서로밖에 없다.
그렇기 때문에 private 내 모든 ip및 포트번호에 대한 접근을 허용할 필요는 없으므로, 이를 제어하는 것이다.
이러한 규칙을 Subnet에 적용하여 네트워크 접근 제어를 하는 것으로 이해했다.
Subnet 설정
다음으로는 생성한 VPC내에 각각 둘 server들에 대한 subnet을 설정해야 했다.
Nginx Web Server과 WAS, DB Server가 같은 VPC 내에 위치한다고 하더라도, Nginx Web Server는 Public 즉, 외부 네트워크에서 접근이 가능해야 하고 WAS, DB Server의 경우에는 내부 네트워크 통신만 가능하도록 설정해야하므로 보안을 생각해서라도 Nginx Web Server와 WAS, DB Server를 같은 Subnet으로 사용하도록 할 수는 없었다.
각 Subnet에서는 위에서 생성한 ACL 규칙을 적용해 Nginx의 경우 HTTPS 프로토콜을 적용하는 443 포트번호만 접근이 가능하도록 설정했다.
DB server의 경우 WAS의 IP만이 접근 가능하도록 설정했다.
이러한 규칙은 보안 측면에서 고려해야할 중요한 사항이었다.
서버리스 어플리케이션
위와 같이 서버를 설정하고 개발을 하다 Apache Jmeter를 통한 부하 테스트 과정에서 서버의 트래픽이 한순간 몰리는 시점에 어쩔 수 없이 Delay가 생기게 되었다.
DB 쿼리 개선 및 비동기 처리를 통한 개선에서도 한계가 있었다.
Node Cluster를 통한 멀티 프로세스가 개선점이 뚜렷할 것이라 생각했는데, 지금 내가 설정한 서버에서는 Dual Core CPU였기에 그다지 좋은 개선을 할 수가 없었다.
이러한 관점에서 "아 트래픽이 몰리면 서버가 자동으로 확장되는 그런 좋은 클라우드 서비스는 없나? 를 생각하게 되었는데 찾아보니 이미 적용하고 있는 개념이었다.
해당 개념은 서버리스 어플리케이션 이라는 개념이었고, 서버 관리의 복잡성을 줄이기 위해 효율적으로 사용할 수 있는 서비스였다.
"서버리스"라는 말 그대로 이것은 사용자가 서버의 관리에 대한 수고를 덜어주는 것인데, 서버에 도달하는 트래픽이 한순간 매우 커지게 된다면 서비스 측면에서 알아서 해당 트래픽을 처리하기 위해서 서버를 확장하는 개념으로 생각하면 된다. 반대로 축소도 당연히 가능하다.
나는 위 개념을 보고 "와, 이걸 왜 안쓰지?"라는 생각이 들었는데 다시 생각해보니 여러 문제가 있을 것 같았다.
1. 비용 측면
서버가 트래픽이 몰림에 따라 자동으로 확장을 하고 해당 트래픽을 처리 후에 자원을 회수하는 과정에서 서버 확장 및 관리를 전부 클라우드 서비스에 맡기는 것이므로 자동 확장 및 축소에 따른 비용 관리가 힘들 수도 있겠다는 생각을 했다.
예측을 할 수 없다는 것이 무서운 점으로 생각되었다. 사용한 만큼 비용을 지불하는 구조에서 "변동성이 큰 어플리케이션이라면 감당할 수 있을까??" 싶었다.
서버리스 어플리케이션에서 확장 및 축소의 최대 범위를 정할 수 있으면 해당 문제를 해결할 수 있겠다는 생각을 했지만, 서버를 직접 운영해본 관점에서 무시무시한 비용을 초래할 수 있어 무섭기도 하였다.
2. 콜드 스타트?
해당 개념은 서버리스 어플리케이션을 학습하며 알게 된 내용이었다.
위에서 말한 것처럼 서버리스에서는 트래픽이 증가하거나, 감소함에 따라 서버의 확장 및 축소가 자동으로 이루어진다고 하였다. 그럼 당연히 자주 사용되지 않는 리소스에 대해서는 잠시 배제해둔다거나 하는 기능이 적용될 것 같은데 후에 배제해놓은 자원에 대한 요청이 들어온다면 서버리스에서 해당 기능을 다시 활성화해야 하기에 첫 요청에는 응답 시간이 더 걸린다는 단점이 있었다.
나는 여기서 추가로 궁금했던 점이 이러한 "콜드 스타트"가 사용자의 첫 요청마다 적용되는가? 였다.
사용자의 첫 요청마다 콜드 스타트가 이루어진다면 사실 비효율적인 것이 아닌가 싶었지만, 알아보니 각각의 사용자마다의 첫 요청이 아닌, 리소스에 접근하는 첫번째 사용자의 요청에만 콜드 스타트가 이루어지고, 이후 다른 사용자의 요청에는 이미 활성화된 기능을 그대로 사용만 하면 되는 것이었기에 콜드 스타트가 이루어지지 않았다.
이러한 점은 나름 굉장히 효율적이라고 판단되었고, 나도 서버리스를 적용해보고 싶다는 생각을 하게 했다.
정리
프로젝트를 수행하며 직접 Cloud Service를 이용한 VPC 서버 구축하는 방법에 대해서 알아보았고, 더 나아가 이러한 서버의 설정을 Cloud Service에게 맡기는 서버리스 어플리케이션에 대한 개념도 알아보았다.
추후, 서버리스를 내 프로젝트에도 적용해보고 싶다는 생각이 들었다.
물론, 비용 감당을 위해 충분한 준비를 해야겠지만!
다른 사람들도 이 글을 보고 도움이 되었으면 좋겠다!
