Music Radio Architecture

2014년에 뮤직 라디오(Music Radio)서버를 설계, 개발, 운영했었다. 뮤직 라디오는 음원 스트리밍 서비스였다. 기본적인 구성은 각 지역별로 음악을 공급하는 콘텐스 제공자(CP: Content Provider)가 달랐기 때문에, 각 지역마다 격리된 스택(Stack)을  두기로 했다. 그리고 스택은 각지역에 한 개씩 만들었다. 그리고 사용자는 가장 가까운 스택에 먼저 접속 하도록 최소 지연시간 기반 라우팅(Routing)을 사용하였다. 그래서 사용자는 거의 모든 경우 자신이 있는 곳과 가장 가까운 스택를 이용하게 되었다. 그래서 빠른 속도로 서비스(Service)를 이용할 수 있었다.

 
위 그림은 2개의 스택을 어떻게 구성했는 지 보여준다. 도쿄와 시드니에 2개의 스택을 구현하였는데, 한국의 사용자는 대부분 도쿄에 있는 스택에 접속해서 서비스를 이용할 수 있도록 했다. 만약 순간적으로 서울과 도쿄의 통신이 느려져서 일부 사용자가 시드니로 접근한 경우에는 시드니 스택에서 도쿄 스택으로 돌려보내도록 처리하였다. 그 과정을 자세히 보면 다음과 같다. 먼저 모바일 어플리케이션(Mobile Application)은 API 서버(API Server)에 접속했다. 그리고 위에서 설명한 것처럼 가장 가까운 스택에 연결해서 원하는 정보를 얻어가도록 만들었다. 많은 비율은 아니었지만, 가끔씩은 사용자가 접속한 지역에 사용자가 너무 많아서 다른 지역의 API 서버에 연결되는 경우도 있었다. 이 때는 사용자의 서비스 계정(e.g., G mail 계정, Facebook 계정 등)의 국가정보를 확인하고 보고 원래 접속해야 하는 곳으로 다시 연결하게 만들었다. 기술적인 이유도 있었지만 가장 큰 원인은 법률 문제였다. 음원 제공업체들이 제공하는 음악은 해당 지역 외에서 재생할 수 없었다. 따라서 여러 가지 이유를 만족시키기 위해 여러 개의 스택을 구성하면서도 최소지연시간 기반 라우팅을 사용하도록 하였다.

관리자를 위한 어드민 웹사이트(Admin Website)도 모바일 어플리케이션과 비슷하게 멀티(Multiple) 스택으로 구성하였다. 그러나 동작은 약간 달랐다. 그 이유는 요구사항이 달랐기 때문인데, 한국에 있는 본사에서 전 세계에 퍼져있는 정보를 한 곳에서 모두 보고 싶어했고 각 지역에서는 해당 지역에 국한된 정보를 빠르게 확인하고 싶어했다. 상충하는 요구사항을 모두 맞추기 위해서 다음과 같이 설계했다. UI 서버를 각 스택에 만들었다. 그리고 관리자는 UI 서버를 통해 통해 접속하는데, 자신이 접속한 곳의 정보를 가장 먼저 보여 주었다. 그리고 화면 상단에 보고 싶은 지역을 바꿀 수 있는 기능을 넣었다. 그래서 지역을 변경하면 각 지역의 어드민 API 서버를 호출해서 화면을 바꾸어 주었다. 보다 쉽게 이해하기 위해서 비슷한 방식으로 구현한 예제를 찾아보겠다. AWS 관리 콘솔(Management Console)을 보면 비슷하게 동작한다. 각 지역을 선택하는 곳 화면 오른 쪽 위에 있는 것을 볼 수 있다. 그리고 여기서 지역을 변경하면 그 지역에 해당하는 정보를 확인할 수 있다. 이 동작과 비슷하게 동작하도록 만들었다. 어드민 웹사이트의 클라이언트(Client)는 Node.js 와 AngulaJS를 사용해서 구현했으며, API 서버는 Wildflly와 Spring Web Framework를 사용했다. API 서버는기본적으로 RESTful API를 지원했고, 추가적으로 웹소켓(Websocket)도 지원했다. RDBMS(Relational Database Management System)는 RDS for MySQL을 사용했고, CDN(Content Delivery Network)은AWS CloudFront를 사용했다.

 
각 스택의 내부는 위의 그림과 같이 구성했다. 스택 VPC는 2개의 가용영역 (AZ, Availability Zones)에 총 8개의 서브넷(Subnet, Sub-network)을 두었다. ELB/퍼블릭서브넷은 외부에서 직접 접근 가능했다. DB/프라이빗 서브넷은 외부에서 직접 접근이 불가능하도록 했다. 보안을 위해서 문지기 서버(Bastion host)를 두었으며, 문지기 서버에는 SSH 기능만 남기고 거의 모든 기능을 껐다. 문지기 서버의 이름처럼 검문 및 사용자 인증 역할만 할 수 있도록 했다. 또한 보안을 높이기 위해서 문지기 서버의 SSH 포트 번호를 클라우드 포메이션(CloudFormation)에 정의한 EC2UserData에서 변경할 수 있도록 자동화 했다. 그리고 문지기 서버는 회사내에서만 접근 가능하도록 방화벽 규칙을 적용하였다. 따라서 원칙적으로 인가받은 사용자가 회사 내에 있는 컴퓨터를 이용할 때만 시스템 내부에 들어 갈 수 있도록 만든 것이다. 그리고 스택 내부의 서버들은 다 프라이빗(Private IP) 주소만 갖도록 해서 직접적인 외부와의 통신을 사전에 차단하였다. 그리고 보안그룹(Security Group)은 체인 형태처럼 꼬리에 꼬리를 무는 형태로 설계했다. 따라서 상호 지정된 서버끼리만 통신이 가능하도록 보안 수준을 높였다. 보다 자세한 내용은 Security as Code에 기록하였다.

스택 내부의 서버들은 전부 셰프(Chef)를 통해서 관리했다. 각 서버(Application Server)들은 클라우드 포메이션을 통해서 생성했는데, EC2 인스턴스(Instance)를 새로 만들면 자동으로 셰프클라이언트를 설치하고 셰프서버에 등록했다. 그래서 대상 서버에 접속해서 들어가지 않더라도, 셰프의 관리도구인 나이프(Knife)를 이용해서 EC2 인스턴스를 원하는 서버로 만들었다. 당시 회사에서는 서버에 접속하기 위한 계정을 중앙관리하는 시스템을 만들고 이 정책을 강제하고 있었는데, 뮤직 라디오는 서버에 들어갈 일이 없었기 떄문에 그 계정관리 서비스가 필요하지 않았다.

셰프(Chef)는 서버설정을 자동화하는 도구이다. 셰프가 하는 일을 간단하게 말하면, 미리 만들어 놓은 쿡북과 레시피(Cookbook, Recipe)를 원하는 서버에서 실행해 준다. 여기서 레시피는 서버에서 수행해야 할 일들을 미리 프로그래밍 해놓은 작업 절차서같은 것이고 쿡북은 레시피의 묶음이다. 쿡북이 단순한 레시피의 묶음 보다는 더많은 기능을 포함하고 있지만, 그 정도로 이해하더라도 나쁘지 않다. 그래서 당시에는 각 서버가 해야할 역할에 맞게 쿡북을 개발했다. 그 쿡북은 미리 개발환경에서 점검한 다음 운영환경에서환경변수 정도만 변경하고 그대로 적용했다. 그래서 항상 기대하는 것과 똑깥은 결과가 나타났으며, 더불어빠르고 정확하게 새로운 서버를 만들수 있었다. 이렇게 서버를 소스코드로부터 동일한 형상으로 만들어 내는 것은 서비스의 가용성을 높일 수 있는 장점이 있다.

먼저, EC2 인스턴스에 문제가 생기거나 AWS Maintenance Event 때문에 동작 중인 서버를 교체해야 하는 일이 쉬워진다. 오토 힐링(Auto Healing)이라고 부르는데, 문제가 생긴 인스턴스를 제거하면 지정한 숫자를 채우기 위해 새로운 인스턴스가 생성되는 기능을 이용하는 것이다. 새로 생성한 인스턴스는 이미 셰프를 이용해서 만든 이미지 (Image, Machine Image)이거나, JeOS (Just Enough OS) 일지라도 셰프를 통해 즉시 서버 설정이 가능하므로 빠르게 교체 선수를 투입할 수 있게 되는 것이다.

다음, 사용자의 증가에도 탄력적으로 대응할 수 있다. 사용자가 늘어나면 늘어난 만큼 쿡북과 레시피를 이용해서 서버를 늘리면 된다. 실제로 이러한 일을 겪은 적이 있었다. 뮤직 라디오 전에도 셰프를 사용했었다. 기존에 있던 여러 서비스(비디오, 북, 러닝, 뮤직 등)를 통합해주는 게이트웨이(Gateway) 서비스 였다. 당시 가장 뜨거웠던 Exo 라는 아이돌 가수의 미니 앨범을 예약판매하는 이벤트가 있었는데, 이 이벤트 때문에 순식간에 접속량이 폭증하였다. 그래서 관련된 거의 모든 서비스(뮤직, 계정 등)가 마비가 되었다. 그런 상황이었지만 다행히 셰프와 오토 스케일링을 적용한 허브 서비스는 늘어난 요청을 무리없이 잘 받아 주었다. 앞에서 언급한 오토 힐링과 오토 스케일링은 일종의 피닉스서버(PhoenixServer) 패턴^[각주:1]이라고 볼 수 있다. 또한 그 당시의 경험을 바탕으로 더욱 많은 부분을 자동화하여 운영 안정성을 높이려고 노력했다. 그래서 많은 경험과 노력을 바탕으로 현재는 스핀에커(Spinnaker)^[각주:2]와 지속적 전달(Continuous Delivery)을 여러 과제에 적용하려고 노력하고 있다.

---

 

1. https://youngookkim.tistory.com/16 [본문으로]
2. https://youngookkim.tistory.com/3 [본문으로]