이 글은 구 블로그에서 옮겨온 글이며, 원본 글은 2018년 7월 25일에 작성되었다.
2016년부터 서버 정리와 블로그 제작 등을 조금씩 아주 조금씩 진전시키고 있었는데, 이번 여름에 몰아서 일을 처리하기로 했다. (참 오래도 해왔다...) 그 김에 이때까지 해온 일들도 미래의 나를 위해 정리를 해보기로 했다. 나를 위한 정리이기에 이 글은 다른 사람이 가상 서버 서비스를 선택할 때 그다지 큰 도움은 안 되리라 생각한다.
제일 먼저 했던 것은 서버 서비스 선정 및 구획 정리였다. 세상에는 정말 많은 가상 서버 서비스가 있었는데, 그 중 일부를 사용해보았고 최종적으로는 TOAST Cloud에 정착하였다.
계획한 서버 구조 (처음)
아무래도 큰 하나의 거대 서버에 여러 서비스를 몰아 넣는 일은 좋아하지 않는지라 (이 습성은 나중에 AWS에서 환경을 구성할 때 매우 큰 도움이 되었다), 적당히 서버의 역할을 쪼개서 구상하였다.
- 개발 서버
나는 개인적으로 물리적으로 소장한, 서버로 사용하는 장치가 없었으므로 언제 어디서나 접속가능하고 상시 켜져있는 개발 서버가 필요했다. - 웹 서버
정적으로 파일을 서비스하는 서버가 필요했다. 이때까지만 해도 Github Pages를 이용할 생각을 못 하고 있었다. - 앱 서버
내가 제작한 서버사이드 애플리케이션과 API를 항상 프리뷰 형태로 제공할 계획인데, 이 백엔드 서비스를 돌리는 서버가 필요했다. - 노드 밸런싱 서버
노드 밸런싱에 관심을 가지고 있었고, 혹시나 모르는 DDoS 상황에 대비할 필요가 있었다. 아주 오래 전 코노하에서의 안 좋은 추억이 있기도 하고, 항상 모든 상황에 대한 준비를 하고싶었기에...
세상에는 좋고 편한 서비스가 많지만 처음 서버 구조를 생각할 때까지만 해도 나는 그것들을 이용할 생각이 없었다. 그렇기에 이런 돈낭비가 심한 서버 구조를 구상하게 된 것이다. 여하튼, 이렇게 꾸밀 생각으로 난 각 가상 서버 제공업자들을 떠돌아다니기 시작했다.
가상 서버 서비스계의 떠돌이
1. Linode
가장 먼저 이용했던 곳은 Linode였다. 서버 대 개편을 시작하기 전 이용하고 있던 곳이 리노드였기에, 바로 리노드에서 시작하려 했으나...
Ping이 너무 높았다.
내가 Linode를 이용할 때까지만 해도 도쿄 시설이 없었기 때문에, 런던 지역의 인스턴스를 이용했고, 반응 속도가 너무나도 느렸다. 그래서 빠르게 Vultr로 넘어가보게 되었다.
2. Vultr
정말 좋았다. Vultr은 정말 쉽게 모든 것을 할 수 있게 해주는 최고의 서비스였다. 가격도 좋았으며, ping은 들쑥날쑥했지만 가장 좋지 않을 때도 나름 쓸만한 ping을 내 주었다. 서버 관리 패널도 최신식이었고, DNS 서비스까지 제공해주었다.
내부 네트워크의 경우 수동 systemd-networkd로 설정해주어야 한다는게 귀찮기는 했지만, 한 번 설정하면 정말 빠르고 탄탄한 백본망을 제공하기에 만족스러웠다.
Vultr의 서비스를 이용하면서 리눅스 시스템에 대해서 많이 배울 수 있었는데, 서버 디스플레이를 VNC로 제공해주어 네트워크 설정이나 SSH 설정을 잘못해서 접속이 안되게 망쳐놨을 때도 VNC로 들어가서 복구를 스스로 할 수 있었기 때문이다.
하지만 1년 정도 이후 Azure로 옮겨가게 되는데, 좀 더 체계적이고, 더욱 직접 관리를 하고 싶고, (Vultr도 매우 대형 서비스이지만) 더욱 대형 서비스를 체험해보고 싶었기 때문이었다.
3. Microsoft Azure
정말 복잡했다. 처음으로 써 본 대형 서비스라서가 아니었다. 마이크로소프트 특유의 번역과 특유의 느낌이 나는 서비스명 선정 등이 내가 이해하기에 너무 어려웠다. 물론 나중에 차츰 적응이 되긴 했지만, 와닿지는 않았다. 서비스 관리 패널에서의 원인을 알 수 없는 오류도 많이 났다.
서비스 자체의 질은 나쁘지 않았고, Vultr보다 성능이 좋았다. '한국 Azure 사용자 모임'이라는 페이스북 그룹도 존재하여, 가끔 도움을 구할 수 있다.
그래도, 상기한 단점들로 결국 GCP(Google Cloud Platform)로 자리를 옮겨가게 된다.
4. Google Cloud Platform
Azure와는 확실히 다르게 메뉴를 이해하기 쉬웠다. 이건 구글이 잘 했다기 보다는 Azure가 너무 나에게 어려웠기 때문이다.
여하튼, 성능도 괜찮고 통합/연계 서비스 (G-Suite 등)도 매력적인 상품이었으나, 다소 비용이 비쌌다. 다른 곳보다 월등히 비싸지는 않지만, 내 개인적인 기준과 판단으로 비용이 많다고 생각되어 3개월 정도 후 AWS로 옮기게 되었다. 자세한 비용 비교는 기억나지 않으므로 생략한다. 내가 기억이 난다면 나중에 이 글을 업데이트 하길...
5. Amazon Web Services
남들이 다 쓴다는 AWS이기에, AWS를 안 써 볼 수가 없었다. 써 본 결과는... 정말 컴퓨팅 서비스의 명가이구나를 느낄 수 있었다. 컴퓨팅 성능도 우수했고, 핑도 상당히 괜찮았다.
하지만 AWS에서도 2달 이후 자리를 옮기게 되는데, AWS에서 제공하는 사양 중 메모리가 다른 저렴한 서비스와 비교해봤을 때 상당히 부족함을 느꼈기 때문이다. 타사에서 같은 가격으로 1GB의 메모리를 제공할 때 AWS EC2는 0.5GB를 제공했는데, Docker 위에서 nginx를 하나 돌리면 0.5GB 메모리가 가득 차서, 더이상 다른 도커 이미지를 올릴 수가 없었다.
물론, 0.5GB 인스턴스에 도커를, 그도 이미지 두개를 올린다는 것 자체가 원래부터가 정말 말도 안되는 억지인 일이고, 좋은 서비스를 이용하려면 그에 상응하는 가격을 지불하는 건 당연한 일이지만... 그냥 적어도 학생 신분일 때 까지만은 세상 공짜로 살고싶은 (혹자가 보면 매우 짜증날 만 한) 소비자가 되어보기로 했다.
AWS를 지나면서 나의 서버 계획도 바뀌었는데, 서버사이드 언어로 돌아가는 서비스를 제외하고는 모두 Github 페이지를 이용하고, 개발 서버는 내가 쓰던 예전 노트북을 DDNS와 결합하여 서버로 쓰기로 하고, 서버사이드 언어로 돌아가는 메일서버, 404 페이지 서비스, 기타 앱 서비스만을 가상 서버 서비스에 올리기로 했다.
6. TOAST Cloud
이제 고려할 만 한 다른 외국 서비스는 그다지 없었고, 핑이 중요한지라 국내 서비스를 찾아보았는데, ucloud는 개인 서비스를 종료했고, 대신 새로 떠오르는 TOAST 서비스가 있어서 이 기회에 이용해보게 되었다. 이렇게 말하니까 기승전광고글같지만 이건 그냥 개인 기록일 뿐이다.
아직까지는 지원하는 리눅스 이미지 종류도 매우 적고 (CentOS/Ubuntu/Debian/RHEL/Windows), 콘솔 로그인 계정에 대해 보안도 매우 허술하다 (TOTP 미지원 및 이메일/비밀번호만 알면 로그인이 가능).
하지만 꽤 경쟁력이 있다 (고 내가 생각하는) 가격 정책, 무엇보다도 국내 서비스라 국내 고객센터이고, 말이 잘 통하는 사람들이 답변을 달아준다. 문의를 하면 고객 센터 직원뿐 아니라 내부 운영 및 개발 직원이 직접 답변을 해주기도 한다. 이 점은 나머지 어떤 서비스에서도 찾아볼 수 없는 고객 관리라고 생각이 든다. 내가 현재 TOAST 서비스에서 떠나지 않는 이유도 이것이 주이다. 여하튼, 핑과 성능도 좋으므로, 현재 만족하며 사용중이다. 다만 TOAST Cloud에서 docker를 이용한다면 손이 많이 가게 될 것이다. docker-ready OS를 제공하지 않기 때문이다.
현재 서버 구조
현재는 상기한 TOAST Cloud 위에 아래와 같은 서비스를 굴리고 있다.
- 404 페이지 서버
- 메일 서버
- 채팅 앱 데모용 백엔드 서버
- 공용 콘텐츠 저장용 오브젝트 스토리지 두 개
나머지는 모두 Github Pages로 이전했으며, 개발은 개인 노트북 서버에서 진행한다.
두서 없이 글을 썼지만, 나중에 언젠가 나 자신에게 참고가 되겠지?