이번글에서는 버즈아트에서 AWS를 어떻게 활용하여 서비스에 이용하고 있는지에 대해서 한번 써보겠습니다. 많은 기업에서 이미 AWS를 활용하여 서비스를 하고 있고 많은 분들이 기술적인 경험을 가지고 있겠지만 실무에서 활용한 작은 경험이 글을 읽는 블로그 독자들에게 도움이 되기를 바랍니다.

As is

제가 합류한 시점에 버즈아트는 이미 AWS를 이용해서 서비스를 하고 있었습니다. 글로벌 타겟으로 하고 있는 서비스이기 때문에 해외 리전에 서버를 두고 운영을 하고 있었습니다. 그 시점에서의 간단한 서버 구성은 아래 그림처럼 직렬화된 구조 였습니다. 서비스 초기에 인프라에 대한 안정성 혹은 효율성을 염두에 두기가 쉽지 않은 부분이 여실히 드러나는 구조 였습니다.

서버는 그림 처럼 직렬화 되어 있고 어느 한 부분에서 문제가 발생하면 서버스 전체가 중지 될 수 있는 위험성을 안고 있었습니다. 이런 시스템의 문제는 인프라에서 발생하는 문제 보다 서비스 개발 운영중에 나타날 수 있는 소프트웨어의 작은 버그 하나로도 서비스 전체가 중지 될 수 있는 취약한 문제점을 안고 있었습니다. 운영 조직이 따로 없는 작은 스타트업에서는 개발자들이 늘 서버시의 운영상태에 촉각을 곤두세우고 있어야 하고 문제 발생시에 즉각 대응 하지 못하면 서비스가 중단되는 사태를 맞을 수 밖에 없는 치명적인 리스크를 안고 불안한 하루 하루를 보내야만 합니다.

To be

버즈아트에 합류하고 한달쯤 기존 인프라에 대한 스터디를 마치고 마음속으로는 이것이 답이 될 것이다 라는게 있었습니다. 그동안 여러 경로를 통해 공부해온 AWS ELB(Elastic Load Balancing)를 쓰면 최소한 인프라 측면에서 발생하는 몇가지 문제는 해결 할 수 있겠다라는 생각이 있었지만 이것이 옳다고 큰소리로 이야기할 자신이 없었습니다. 이유는 개인적으로 실제 서비스 경험이 없었기 때문입니다. 그래서 확신을 가지고 이렇게 하면 문제가 없습니다 라고 말하기가 좀 어려웠습니다.

AWS ELB의 장점이 여러가지가 있겠지만 제 개인적으로 생각하고 있는 장점은

갑자기 늘어 날 수 있는 사용자에 대한 대응이 가능 하다. 소프트웨어 및 하드웨어 버그로 나타날 수 있는 서비스 장애에 대한 대응이 가능하다. 정도의 두가지를 생각했습니다. 먼저 사용자 폭증에 대해서는 Load Balancer를 사용하는 가장 중요한 목적이므로 따로 언급할 필요도 없을것 같습니다. 하지만 두번째 소프트웨어 버그 및 하드웨어 장애로 인한 시스템 장애의 경우는 항상 나타날 수 있는 문제 이므로 바른 시간내에 적절한 대응을 하여야 하지만 대응을 하는 동안에도 서비스는 계속 되어야 하므로 서비스 중단 사태를 최소화 할 수 있는 대응 방안이 될 수 있다고 할 수 있습니다.

Test Project

앞서 말한대로 문제는 경험이 없어서 아무리 AWS가 안정적인 시스템이라고 하더라도 무언가 한번 만들어 보지 않고 실 서비스에 도입을 하는데는 약간의 꺼리낌이 있었습니다. 그래서 테스트 프로젝트를 하나 만들었습니다. 아래 그림과 같이 AWS에서 가장 비용이 적은 인스턴스 두개를 생성하고 각각에 Node.js를 이용해서 개발한 서비스를 만들고 앞단에 ELB를 이용해서 로드 발란서를 붙이고 인스턴스 뒷단에 RDS 기반의 MySQL 데이터 베이스를 설치해서 시스템을 구성 했습니다.

앞의글 https://bbuzzart.github.io/1/에서도 뭔가 간단한 테스트에는 Node.js가 최고 라고 이야기 한바 있습니다만 Node.js를 이용해서 간단한 웹 서비스와 REST API를 통하여 RDS MySQL 데이터를 조회하는 시스템을 구성 했습니다. 그리고 jMeter를 이용해서 서버에 부하를 가하는 테스트를 수차례 실행 했습니다.

아주 간단한 서비스 시스템이라 버그의 가능성으로 인한 서비스 오류의 가능성이 적은탓에 일부러 서버 하나를 중단 시키거나 서비스를 수동으로 내리는 방법으로 테스트를 진행 했고 개인적으로 이 정도면 가능 하지 않을까 하는 확신과 함꼐 ELB 셋팅 방법을 숙지 했습니다. 제 생각엔 이게 중요한 문제 였던것 같습니다. 알고는 있지만 셋팅과정에서 나타날 수 있는 문제들을 미리 한번 시뮬레이션 해보는 것이 자신감을 높이는 좋은 방법이라고 생각 됩니다.

DNS & Running

한번 해보면 두번째는 쉽습니다. 실제 운영할 사이즈의 인스턴스를 n개 만들어 API서버와 웹서버를 각각의 인스턴스에 설치하고 RDS에 DB 인스턴스를 생성해서 기존 데이터를 리스토어 하고 실제 운영 테스트를 시작 했습니다. 그런데 기왕에 사용하기 시작한 AWS인데 아예 DNS까지 AWS것을 사용하는게 시스템 호환성 측면에서 더 좋은 것이 아닐까 하는 생각이 들었습니다. 이미 AWS에는 Route53이라고 하는 꽤 쓸만한 DNS시스템을 가지고 있기도 합니다.

그래서 기존에 국내 업체를 통하여 운영중이던 DNS 시스템을 AWS Route53으로 이전 하는 작업을 준비 했습니다. AWS ELB 기반으로 모든 서버 셋팅을 완료 하고 일정 기간 테스트를 거쳐서 테스트가 마무리 되는 시점에서 DNS를 국내업체에서 Route53으로 이전 했습니다. DNS 이전 작업중에 서비스가 이전 서버와 AWS 서버로 중복 접속되는 부분이 일부 있었고 사용자 데이터의 일부가 양쪽 서버에 분산되는 격미한(?) 오류가 있었고 이런 데이터는 수작업(?)으로 이전 하는 작은 사고가 있었지만 크게 무리 없이 서버 이전 작업을 마무리 할 수 있었습니다.

결론

아마존 AWS는 이미 많은 업체들이 사용하고 있는 대표적인 클라우드 시스템입니다. 안정성 면에서나 비용면에서 타의 추종을 불허 하지만 모든 기능을 제대로 알고 사용하고 있는 곳이 그렇게 많지 않은것 같습니다. 물론 제 의견입니다. 아닐 수도 있습니다(다들 이미 아시는데 저 혼자 생각일 수도 있습니다.) ^^;

ELB를 도입하고 나서 버즈아트는 API서버, WEB서버의 업그레이드시에 서비스를 중단하지 않고 서버 개별 업그레이드를 진행할 수 있습니다. 소프트웨어는 언제나 오류를 발생 시킬 수 있고 하드웨어 또한 항상 문제 발생의 가능성이 있습니다. 하지만 가장 중요한건 서비스는 항상 정상적으로 가동 되어야 한다는 것일 것 같습니다.

글을 쓰고 보니 AWS 광고 하는것 같이 되어 버렸습니다만 전혀 그렇지 않습니다. 우리(버즈아트)가 어떻게 일을 하고 어떻게 하면 좀 더 편하게 시스템을 관리 할 수 있을까 하는 고민의 끝에 실행한 결과를 블로그 독자들과 나누고 싶은것이 이 글의 의도 입니다. 그리고 앞으로 계속 합류할 더 많은 개발자들을 위한 업무 히스토리를 남기는 일이기도 하구요.

사족

비용의 측면에서 보면 기존의 시스템과 ELB시스템은 그리 큰 차이가 나는 것은 아닌것 같습니다. 기존의 1개의 서버는 매우 큰 인스턴스를 사용 했고 이후에 인스턴스는 좀 더 작은 것들을 병렬로 연결 했기 때문에 비용이 비슷하고 DNS에서 약간의 비용이 더 발생하는 정도로 방어(?) 한것 같습니다. 더 큰 이득은 이전에도 큰 문제는 없었습니다만 불안감이 좀 줄었고 고민하지 않고 편안하게 밤잠을 잔다는 정도?

마지막으로

개발자를 충원하고 있습니다. 개발자가 일하기 좋은 문화를 만들어 보겠다는 생각은 많지만 혼자 되는 일은 아닌것 같습니다. 함께 만들어 가실분! 아래 링크를 참조 하세요

https://www.rocketpunch.com/companies/bbuzzart/jobs

박병일(billy@bbuzzart.com)