NDC Replay

라이브 상황에서 윈도우 서버 개발자가 겪은 좌충우돌 Redis 적용 경험담
박상기, 박근희
넥슨코리아, 넥슨코리아
박상기 : 현재 CSO 프로젝트에서 근무 하고 있으며, 서버 프로그래밍을 담당하고 있음. 총 개발 경력은 4년 정도 박근희 : 현재 CSO 프로젝트에서 근무 하고 있으며, 서버 프로그래밍을 담당하고 있음. 총 개발 경력은 2년 정도
CSO의 라이브 서비스에서 REDIS 서버를 추가하기까지의 개발 및 적용 사례, 문제점, 고민에 대한 이야기를 이 세션에서 들을 수 있습니다. 왜 CSO는 REDIS라는 메모리 DB를 선택하였으며 그 결정을 하기까지의 내부적 고민과 라이브에 REDIS를 투입, 실제 운영할 때의 부딛쳤던 문제, 그리고 이를 해결하기 위한 저희가 적용한 문제 해결 방법을 공유합니다. 특히, 윈도우 서버만 라이브에서 운영하는 환경에서 리눅스 서버를 추가했을 때의 고민과 문제점, 해결책에 대한 이야기를 중점적으로 다루겠습니다. REDIS를 라이브 서비스에 적용할 예정이거나 고려 중인 청강자 분들은 REDIS를 적용하기 전 구체적인 사례를 통하여 준비할 사항과 라이브 서비스에서 발생할 문제를 미리 알아볼 수 있습니다.
[새 창에서 슬라이드 보기]
(박상기)_ 안녕하세요. 저는 CSO 프로젝트의 서버 프로그래머로 재직중인 박상기입니다. 1부, 2부로 구성되어 있는데요. 2부는 저기 계신 박근우님이 진행해 주시겠고요. 그럼 발표 진행하도록 하겠습니다. 저희가 준비한 이야기는요. 성능 튜닝, 퍼포먼스 튜닝에 대한 이야기가 아니고요. 분산 처리에 대한 주제도 아니에요. 저희가 준비한 이야기는요. window 서버 개발자가 redis라는 보스몹을 상대하는데 갑자기 Linux라는 중간 보스가 나오죠? 이 역경들을 이겨내 나가는 그런 이야기가 되겠습니다. 즉, 이런 얘기죠. C++과 MsSQL로 무장한 window 프로그래머가 lua와 redis를 무장한 ubuntu를 공략하는 얘기가 되겠습니다. 발표는 총 2부로 구성되어 있고요. 1부는 이런 순서로 진행하도록 하겠습니다. 1부 동기편 시작하도록 할게요. 어느 날 갑자기 제가 작업을 하나 끝내고 퇴근을 하려고 하는데, 디렉터님이 실시간 랭킹이란 걸 하고 싶은데, 가능하냐고 하시더라고요. 저는 사실 멘붕에 빠졌는데요. 그 이유는 실시간이라는 단어 때문이었어요. 랭킹에서 순위를 산정한다는 말은 전체 데이터를 정렬해야 된다는 이슈가 있고요. 실시간 랭킹이라는 말은 실시간으로 데이터를 정렬해야 되는데, 만약 데이터가 작으면 괜찮겠지만 그렇지 않았죠. 하지만 해야 했으니까 이것 저것 생각을 해봤는데요. 그 중에 첫 번째도 DB로 구현하는 걸 생각해봤어요. DB는 데이터를 다루는 데 가장 효과적인 솔루션이고요. 그리고 기존 데이터가 MsSQL로 만들어져 있기 때문에 기존 데이터를 가공하는데 용이했고요. 그리고 전문 DBA분들이 계셔서 그 분들에게 기술 지원도 받을 수 있다는 게 장점이었는데요. 하지만 좀 DB는 어렵다고 생각이 들었던 게, 저희가 전문 DBA가 아니라서, 프로그래머라서 SQL을 좀 잘 못 다뤄요. 그렇게 되니까 퀄리티도 낮아질 거고, 나중에 유지보수 할 때도 굉장히 어려움이 많을 것 같더라고요. 그래서 SQL은 좀 어렵겠다 싶었고요. 그래서 다음으로 생각했던 게, 그렇다면 랭킹만 산정하는 전용 서버를 만들어보자. 라고 생각을 해봤는데, 주어진 기간 동안에 새로운 서버 코드를 만드는 일과 나중에 유지보수, 서버 관리 비용을 따져보니까 배보다 배꼽이 더 클 것 같더라고요. 그래서 이것도 안되겠다. 그러다가 제 지인 분한테 조언을 한번 구해봤더니 요즘 랭킹 같은 경우는 redis라는 솔루션을 쓰는 게 괜찮다더라. 라고 말씀을 하시더라고요. 그래서 redis에 대해서 조사를 해봤는데요. Redis는 NoSQL중에 하나고요. Key-Value 형식의 자료구조를 제공해요. 그리고 하나의 instance가 싱글쓰레드로 구현이 되었고요. 그리고 가장 큰 특징은 메모리 기반의 데이터베이스라는 거죠. 특히 Sorted Set이라고 있는데, 그 자료구조가 랭킹 구현에 굉장히 적합하고요. 그래서 한번 해보기로 했습니다. 다음으로는 redis를 투입하기 전에 이것저것 알아본 거에 대해서 이야기를 할 건데요. 우선은 첫 번째로 생각했던 게 가능할까? 였어요. 그 이유는 제가 라이브 개발에 있었기 때문이죠. 제가 생각하는 라이브의 특성은 안정성이 위주고요. 그 다음에 컨텐츠 개발이 우선이 되요. 그리고 데드라인은 정말 칼 같이 지켜야 되요. 조금이라도 어기면 안 되고요. 그리고 유지보수 이슈도 있고, 보안 이슈도 있는데, 제가 또 하나 생각한 거는 얼마나 관리가 편하냐? 거든요. 패치를 얼마나 쉽게 할 수 있느냐? 이런 부분이 굉장히 중요하다고 생각이 됐어요. 라이브에 있기 때문에 새로운 기술에 대한 도전을 좀 미루게 되는데, 라이브에서는 새로운 기술을 도전하면 안되느냐? 저는 그렇다고 생각하지 않는 게, 언젠가는 개발하는 시스템이 노화가 될 거고, 노화된 시스템이 새로운 요구사항을 받아들이기 어렵죠. 언젠가는 도전해야 하는 타이밍이 오는데, 저는 redis 투입 당시가 그 타이밍이라고 생각을 했고요. Redis 투입에 앞서서 저희 프로젝트 시스템 구성을 제가 확인을 해봤는데, 대부분의 서버가 window 기반으로 되어 있었고요. 그래서 redis도 window 위에서 돌리면 좋겠다. 라고 생각을 했어요. 그래서 찾아봤는데요. Redis window 버전이 있긴 해요. 있었는데, 자세히 보니까 ‘unofficial’ 이라는 단어가 붙더라고요. 비공식 버전이죠. 그래서 저는 멘붕에 빠졌습니다. 엄청 쉽게 될 줄 알았거든요. window 버전 찾아서. 그래서 사실은 회사에 전문가 분이 계시는데, 그 분에게 문의를 구했어요. 그랬더니 window 버전은 좀 어렵겠다고 말씀을 하시더라고요. 그 이유가 안정성이 좀 확보가 안 됐고요. 그리고 마이크로소프트에서 OpenTec 라는 그룹에서 개발을 하고 있는데, 사실은 지원이 불투명했어요. 계속 지원을 하는가? 버전 업을 할 수 있는가? 이런 것들이 불투명했고요. 그래서 저는 Linux를 쓰기로 결정했는데요. Linux도 사실 다양한 종류가 있어요. 그 중에서 저희는 CentOS와 ubuntu를 후보군으로 놨고요. 그 중에서도 ubuntu로 결정을 했는데, 특별한 이유는 없었고, 개발자분 중에서 ubuntu를 써보신 분도 계셨고 해서, 조금 더 익숙한 거를 쓰자고 해서 ubuntu를 선택했었어요. 이제 OS도 결정했고, 실질적으로 투입하기 위해서 머신을 샀어야 했는데, 사기 전에 스펙 선정을 해야 하겠죠? 여러 가지 CPU라던지 그런 요소가 있었는데, 저희 같은 경우는 메모리를 가장 중요한 자원으로 봤고요. 그래서 레코드 크기를 산정하는데 좀 많은 노력을 들였습니다. 그런데 저희가 실수한 부분이 하나 있었는데, 저희가 그렇게 redis 머신을 한 대만 구성했어요. 사실 그 이유가 여러 가지가 있었는데… 사실은 라이브 서비스를 안정적으로 하려면 master-slave 구성은 필수적이거든요? 그런데 그렇게 못 했고, 만약 master-slave 구성을 했으면, redis에 sentinel이라는 강력한 failover 기능이 있어요. 그것도 쓸 수가 있는데, 저희는 못 쓰고 있고요. 만약에 redis를 사용할 계획이 있으시면 이런 점도 있다라는 걸 고려하시면 되겠습니다. 사실은 계속 머신 구입을 진행하고 있었는데, 갑자기 요구사항이 바뀌었어요. 20명 단위 실시간 랭킹이었는데, 20명 단위 그룹 랭킹으로 바뀌었는데, 요구 사항이 사실은 redis를 안 써도 되는 그런 상황이었거든요? 조금 난감했었는데, 이미 장비는 샀고 어쩔 수가 없어서 그냥 쓰기로 했습니다. 다음으로는 설치에 대해서 말씀 드릴 건데요. 제가 했던 것부터 언급을 드릴 게요. 우선 redis를 설치했고요. CSO서버에 hiredis 라는 라이브러리를 적용했고요. 그리고 Cron과 Lua를 이용해서 DB에 JOB 같은 역할을 할 수 있게 끔 만들어 봤어요. 그리고 데이터 백업에 사용하기 위해서 window 공유 폴더를 ubuntu에 mount 시키는 일을 해봤거든요? 우선은 redis 설치하기에 앞서서 ubuntu에 대해서 간단히 설명을 드릴 건데요. 우선 패키지인데, 패키지는 간단해요. 그냥 window의 설치 프로그램과 비슷하다고 보시면 되고요. APT 명령어에 대해서 소개해 드릴 텐데, window에 보면 제어판에 프로그램 추가 설치라는 그런 메뉴가 있잖아요? 그거랑 좀 비슷한 건데, 얘 같은 경우 특이한 게 ubuntu에 공식 패키지 레퍼토리가 있는데 거기에서 패키지를 다운받아서 설치, 제거, 업데이트까지 되는 거여서 굉장히 강력한 명령어고요. 이제 redis를 설치해볼 건데요. APT 명령어를 이용하면 공식 레퍼토리에서 redis를 받을 수 있는데, Ubuntu 12.04에서 제공하는 redis의 경우는 2.2 버전이에요. 지금 redis가 2.8 버전 stable 버전인데요. 좀 버전 차이가 많이 났어요. 그리고 실제로 라이브 서버를 구축하면, 웬만하면 DB쪽은 외부 네트워크를 단절시키거든요? 그래서 공식 레퍼토리에 접속이 불가능하다는 그런 이슈도 있었고요. 그래서 생각을 한 게 패키지를 다운받아서 설치를 하면 되지 않느냐? 라고 했었는데, redis 공식 홈페이지를 가보니까 소스만 제공을 하고 있더라고요. 그래서 처음에는 소스를 길들여서 각각 설치를 하는 식으로 진행했었어요. 그래서 설치한 방식을 간단하게 설명을 드리자면, 압축파일을 풀어서 빌드를 하고, bin 폴더에 바이너리 옮긴 다음에 권한이라든지, 계정이라든지 설정을 해 주고요. 이렇게 했는데 그게 조금 이상한 방법이라고 느낌이 왔어요. 그래서 더 좋은 방법이 없느냐? 해서 그 전문가 분한테 문의를 해봤는데, PPA라고 사설 패키지 레퍼토리가 있는데, 그걸 잘 알아보면 최신 버전의 redis 패키지를 물려주는 레퍼토리가 있다고 하시더라고요. 그래서 그쪽에서 받으면 되고요. 물론 APT 명령어를 이용해서 설치가 가능해요. 하지만 보안 이슈 때문에 저희는 그렇게 못 했고요. 그냥 패키지를 받아서 설치하는 방식으로 사용했습니다. 그런데 사실은 거기에 제공하는 패키지가 굉장히 많아요. 종류가 많은 건 아니고 바이너리 버전이 막 다른 건데, 사실 최신 버전인 2.8.9 버전도 네 가지나 제공을 하는데 뭘 받아야 될지 모르겠더라고요. 그런데 간단해요. 저희는 precise라는 태그가 붙은 걸 받았는데, 그 이유는 얘내들이 각 Ubuntu 버전 별로 코드 네임이란 걸 붙이는데, 12.04의 경우는 precise Pangolin 이라는 코드 네임이 붙고요. 그래서 그거를 쓰면 되요. 여기서 추가적으로 12.04 같은 경우는 LTS라는 수식어가 붙은 데, LTS 같은 경우는 원래 Ubuntu 기술 지원이 1~2년 정도로 알고 있는데, 이게 한 5년정도 더 긴 버전으로 기술 지원을 해주는 버전이거든요? 그래서 그런 식으로 버전을 보시면 될 것 같고요. 그래서 바꿨더니 이 한 줄로 끝났죠. 패키지 그냥 설치하면 됩니다. 참 쉽죠? 그리고 제가 조금 난감했던 부분이 window에서 접속을 해서 들어가야 했기 때문에 파일을 어떻게 옮겨야 할지 난감했어요. 간단합니다. 그냥 pscp라고, putty 사이트 가면 받을 수 있고요. 이걸 쓰면 ssh 포트로 파일이 전송이 가능 해요. 그래서 이걸 쓰시면 될 것 같습니다. 그리고 이제 Daemon을 구성해야 했는데, ubuntu에는 inittab과 upstart 라는 방식의 daemon을 구성할 수가 있는데, 저희는 upstart를 사용했고요. 그 이유는 inittab보다 더 편했다. 라는 게 있고요. 다음으로는 API 넣는 거에 대해서 얘기를 할 건데요. 저희는 C++을 사용하고 있어서, 여기 화면에 보시는 거가 후보군이었는데, 그 중에서 hiredis를 쓰긴 했는데, 사실은 hiredis가 고려 대상이 아니었고요. 그 이유는 window에서는 빌드가 안 되는 것도 있고, 실행이 안 되는 것도 있어요. 그래서 window에서 돌아가기만 하면 됐어요. 그래서 어딘가 있지 않을까? 라고 생각을 해보니까 아까 보셨던 window 버전 redis 있잖아요? 거기에 보면 서버 바이너리도 나오는데, 클라이언트도 나오거든요. 그래서 그 클라이언트가 어떤 거를 쓰고 있을까? 봤더니 내부적으로 hiredis를 porting 해서 쓰더라고요. 그래서 저희는 그거를 빌드해서 쓰고 있고요. 6개월 정도 쓰고 있는데 큰 문제는 없어요. 그래서 그거를 window 서버를 구성하시면 그 버전을 쓰면 될 것 같습니다. 그리고 DB JOB 같은 기능을 만들었다고 했잖아요? 그 부분에 대해서 얘기할 건데요. Cron이라고 ubuntu에 보면 window에 scheduler와 비슷한 게 있어요. 그걸로 주기적으로 명령어를 실행하는 거를 Cron으로 이용했고, Lua로 Stored procedure 역할을 하는 것과, JOB을 triggering 하는 그런 부분이 있는데, 그 부분을 구성했는데. Lua 같은 경우는 2부에서 좀더 자세하게 다룰 거고요. 저는 Cron에 대해서 설명을 드릴게요. Cron은 윗줄 같이 쓰시면 되고요. –u 옵션을 쓰면, 특정 계정에 Cron을 설정할 수 있어요. 아래는 어떤 의미냐면 첫 번째가 분, 두 번째가 시인데, 매주 월요일 새벽 3시에 weekly-job을 실행해라. 라는 거에요. 이렇게 쓰시면 되고, 다음으로 redis 백업에 대해서 얘기를 할 건데, 만약에 redis 서버가 꺼진다면 메모리 DB에 있기 때문에 전부다 날라가겠죠. 메모리가 휘발되니까. 그러면 굉장히 난감하겠죠? 그래서 redis 같은 경우는 그런 이슈를 보안하기 위해서 RDB라는, 파일 이름인데, 방식과 AOF라는 방식을 제공해요. RDB 같은 경우는 메모리 스냅샷이라고 생각하시면 되요. 메모리를 그대로 파일로 쓴 거라고 보시면 되고, 당연히 스냅샷이기 때문에 스냅샷이 뜬 후에 사이의 공백 기간에 쿼리는 날라가겠죠? 그런 특징이 있고 AOF는 약간 로그성 방식인데, 모든 set query를 저장하지만 모두 저장하기 때문에 파일이 어디까지 퍼질지 예측을 할 수가 없어요. 그런 특성이 있습니다. 저희는 데이터를 좀 백업하는데 RDB를 백업하는 방식을 썼고요. 그러면 이 RDB를 어디에 둘까... Redis 로컬에 두기는 좀 무섭고, 그렇지만 서버는 더 없어서 window에 저희 백업 스토리지가 있는데, 그거를 쓰기로 했고요. 그래서 window와 ubuntu를 연결하는 게 필요했어요. 그래서 공유폴더를 쓰기로 했거든요? ftp나 http 서버를 만들까도 생각을 해봤는데, 가장 간단한 걸로 가자고 해서 공유 폴더를 mount하는 방식으로 갔고, 또 mount도 여러 가지 방식이 있는데, 그 중에서 fstab이라는 파일이 있는데, 거기에 mount 정보를 추가하는 방식을 썼고요. 거기에서 credential이라는 거를 설정할 수가 있어요. 그거를 이용했는데 그 이유는, 우선은 이렇게 fstab을 설정했어요. 이게 원래 한 줄 짜리인데, ppt가 조금 짧아서 이렇게 갔고요. 여기 보시면 credential이라고 있어요. 이게 저희 같은 경우는 window 공유 폴더에 있는 계정들의 정보를 따로 모아놓은 거를 이용했는데, 보안 이슈상 window 공유 폴더 계정에 패스워드가 변경되는 이슈나 계정 자체가 바뀌거나 그럴 수 있잖아요? 그래서 변경이 안 되는 부분은 여기에 적고요. 변경이 자주 될 것 같은 부분은 따로 뺐습니다. 그런 식으로 RDB 파일을 주기적으로 옮겨서 데이터 유실에 좀 대비를 하고 있고요. 그런데 옮긴 RDB를 열어볼 수가 없으면 그렇게 큰 의미가 없어요. 그래서 얘내들을 확인할 수 있는 방법이 필요한데, 저희 같은 경우는 이런 식으로 쓰고 있거든요? RDB 파일을 redis 서버로 다시 띄워서. window용 redis로 띄워도 되요. 저희는 그렇게 하고는 있고요. 처음에는 콘솔로 계속 명령어를 쳐서 했는데, 찾아보니까 Redis Desktop Manager라는 GUI 클라이언트가 있어요. 그래서 그거가 쓰기 편하지는 않지만 그래도 없는 것 보다는 나으니까 그걸 한번 써보시면 좋을 것 같고요. 이상으로 설치까지는 이렇게 했고, 다음으로 저희가 서버 운영을 할 때에 겪었던 문제점이랑 해결책에 대해서 소개를 드릴 겁니다. 이런 일들이 있었는데요. 데이터가 완전히 망가져버린 적도 있었고요. Redis 버전 업을 해야 할 때도 있었고, 최근에 Openssl 보안 취약점 생겼다고 기사가 떴는데, 그게 저희도 확인해보니까 있더라고요. 그래서 그 부분을 처리하는 점을 말씀 드릴 거고요. 우선은 데이터 복구에 대해서 얘기를 할 건데, 사실은 프로그램이 버그가 나서 데이터가 망가지거나 한 게 아니라 제가 점검을 하다가 쿼리를 잘못 날려먹었어요. 그래서 그 때 롤백을 RDB 백업본으로 하려고 했는데 그것도 실패하고 그 RDB 파일마저 날려버린 거에요. 그래서 굉장히 난감한 상황이 왔는데, 하나 더 있었잖아요? AOF라고. AOF로 복원이 가능하다는 걸 알아서 AOF로 복원을 해봤어요. 그래서 그거를 설명드릴 건데, AOF 같은 경우는 일반 텍스트 에디터로 열 수 있고요. 편집할 수 있습니다. 그리고 편집한 거를 redis로 띄우면 그대로 떠요. 형식을 보자면 오른쪽에 별표로 숫자 되어있잖아요? 그게 칸 명령어에 토큰 개수에요. 몇 개의 토큰으로 명령어가 되어 있나? 그리고 달러 표시 같은 경우는 다음 라인에 올 스트링의 길이에요. 여기 네 개면 아래 네 개가 오는 식으로. 그래서 이 숫자부분을 제외하고 보면 SADD, Members, woodtalk 라고 되어 있는데, Members라는 set에 woodtalk라는 거를 넣은 명령어죠. 형식은 이렇고요. 오른쪽에 보면 이 부분이 제가 잘못 날린 거에요. 한 줄인데 이게 스크립트가 굉장히 쿼리가 많이 포함된 파일이었거든요? 그래서 엄청난 파급력이 있었고요. 그래서 어떻게 했냐? 간단합니다. 그냥 지우고, 저장하고, 띄웠습니다. 그랬더니 복구가 잘 되더라고요. 그런데 AOF 같은 경우는 잘못 수정하거나 하면 전체 데이터가 다 날라갈 수 있어요. 그래서 사실 추천 드리는 방법은 아니고요. 웬만하면 RDB로 백업을 해서, 그거를 복구에 사용하시면 될 것 같고요. 그렇지만 라이브에는 다양한 일이 나오잖아요? 그래서 이런 방법도 있다라는 거를 말씀 드리는 거고요. Redis나 Openssl 이라든지. 그런 거는 패키지 업데이트를 하는 이슈였는데요. 그냥 dpkg 명령어를 이용해서 새로운 패키지를 설치하면 되는 이슈였어요. 그런데 보안 이슈는 계속 나올 거고, 그걸 일일이 다 따져가면서 해야 하느냐? 다른 방법이 없을까? 라고 찾아봤는데, 저희가 하지는 못했는데 제가 시간이 더 있었으면 이런 구성을 해봤을 것 같아요. Mirror Repository를 좀 고려해봤을 것 같은데, sources.list라는 데에 보면 APT가 접근할 수 있는 repository 정보들이 있어요. 그거를 이제 Mirror Repository로 바꾸면 되고요. Repository를 ftp 서버로도 구성해도 되고, http, 심지어는 같은 서버에 있는 디렉토리로 지정해도 되요. 그렇게 어려운 방법은 아니고, 만약에 공식 repository랑 동일한 패키지를 구성하고 싶다. 그러면 APT Mirror라는 패키지를 설치하면 될 것 같습니다. 이제 1부의 마지막 시간인데요. 간단하게 팁들을 정리해봤어요. 저희는 못했는데, 머신을 미리 확보를 하셔서 sentinel 구성과 Mirror Repository를 미리 구성하시는 게 운영상 더 편할 것 같고요. 그리고 window에서 Linux로 파일 옮기는 거 당황하시지 마시고 pscp로 이동하면 편하게 이동하실 수 있고요. 그리고 저는 redis 최신 버전을 구하려고 패키지를 썼는데, 혹시나 다른 패키지를 쓸 때에도 이쪽에 최신 버전의 패키지들이 올라올 수 있거든요? 그래서 PPA을 찾아보시면 최신 버전을 구하기 더 쉬울 것 같고요. 그리고 RDB 파일을 서버로 띄워서 데이터로 확인할 때 콘솔을 이용하는 것보다 GUI 클라이언트가 있으니까 그걸 활용해보시면 좋을 것 같고. 웬만하면 RDB를 데이터 복구에 사용하시는 게 좋은데, 그걸로도 안 되는 경우가 있다. 하실 때는 AOF 파일 복구를 쓰시면 될 것 같습니다. 이상으로 1부 순서를 마치겠고, 2부는 근희님이 진행해주시도록 하겠습니다. 
(박근희)_ 안녕하세요. CSO 프로젝트에서 서버 프로그래머를 맡고 있는 박근희라고 합니다. 전형적인 프로그래머고요. 말재주가 좀 없어서 좀 지루하고 답답하게 느껴질 수 있으니까 잘 참고 들어주시면 감사하겠습니다. 지금부터 Redis만의 기능을 소개해드리려고 하는데요. 어쩌면 RDB에서도 이용할 수 있는 기능이나 자신이 전형적인 프로그래머로서 DB에 대해서 공부 안하고 코딩만 하겠다. 하시는 분들이 redis에서 제공하는 인터페이스를 통해서 쉽게 이용할 수 있는 기능들을 소개하고자 합니다. 고난이도 기술 공유보다는 redis라는 DB를 이런 식으로도 사용할 수 있구나. 라를 말하는 자리임으로 ‘이놈 하나만 걸려라.’ 이런 자세보다는 무념무상의 마음 가짐으로 편하게 들어주시면 됩니다. 발표 순서는 앞에 보시는 바와 같이 도입 배경을 소개하고, 간략한 소개 후에, 활용 부분, 정리 순으로 진행하겠습니다. 우선 저는 게임을 좋아하고, 게임을 만들고 싶어서 게임회사에 입사를 했고요. 그런데 이제 라이브 서버 프로그래머이기 때문에 대부분의 일들이, ‘A 유저의 아이템이 없어졌어요. 확인해주세요.’ 그리고 ‘B 유저가 이러이러한 버그를 사용합니다. 맞는지 확인해주세요.’ 라는 파일 로그와 데이터베이스를 뒤져서 분석, 확인하는 작업이 거의 주된 업무였어요. 그래서 어느 날 메인 퀘스트가 등장하죠. 새로운 랭킹 시스템을 만들어라. 설레고 기대됐습니다. 그래서 가장 처음으로 목표한 일이 기존의 CSO 랭킹 방식이었던 다음날 몇 시 몇 분에 업데이트 됩니다. 라는 이런 방식을 없애고 싶었어요. 그래서 실시간 랭킹을 최종 목표로 합니다. 그렇게 고민하던 중에 앞에 발표하신 상기님이 redis를 써 보자고 말씀을 하시고, 평소에 저는 귀가 매우 얇기 때문에 이거는 꼭 써야 되! 이렇게 해서 그냥 redis를 씁니다. 그래서 처음 랭킹 시스템에 기존 컨셉은 전체 유저에 대한 랭킹이었는데요. 이게 앞서 말했다시피 그룹 단위의 랭킹으로 변경이 되었어요. 또 그러면서 생긴 문제가 소규모 그룹 내에서 특정 순위의 유저들은 승단이 이루어져야 되고, 전체 유저들이 새로운 그룹에 재편성 되야 되는 문제가 있었습니다. 그래서 특정 기간에 전체 유저를 대상으로 데이터를 확인하고 변경해야 하는 작업이 필요했고요. 이 시간대에는 다른 데이터의 변화와 유입이 없어야 했기 때문에 최대한 빨리 진행하고자 했어요. 또 다른 문제로는 이러한 작업들이 게임 서버에서 부담하기에는 매우 부담이 컸기 때문에 새로운 클라이언트를 개발할 필요성이 있었습니다. redis라는 기술이 워낙 최근에 핫한 기술이기 때문에 홈페이지를 보시면 오픈 소스 클라이언트들이 많이 있는데요. 하지만 redis가 Linux버전을 공식적으로 지원하기 때문에 이러한 오픈 소스 클라이언트들 역시 Linux 버전을 공식적으로 지원하기 때문에 윈도우 프로그래머인 저에게 큰 거리감이 느껴졌습니다. 그래서 고민을 하죠. 유지보수는 누가 해야 되고, 개발일정이 빡빡한데 공부는 언제 해야 하는지? OS는 윈도우로 할지 Linux로 할지, 어떤 언어를 사용해서 개발할지, 개발은 직접 개발할 것인지 아니면 오픈 소스 클라이언트를 쓸 것인지, 그리고 redis를 왜 써야 하는지 까지. 그러다가 redis 내에 script라는 기술이 있는 걸 알고 그걸 사용하기로 합니다. 일단 redis 내의 Lua script를 설명하기 전에 redis에서 지원하는 5가지 기본형 타입에 대해서 훑고 지나가겠습니다. 첫째로 string인데요. String은 모든 redis에서 저장하는 데이터의 기본형이고요. Intset 과 같은 특수한 경우를 제외하고는 모든 데이터는 string 기반으로 저장됩니다, 사용하는 방식은 아래 볼 수 있는 명령어같이 set과 get을 이용해서 사용하시면 되고요. 이 때 주목해야 할 점이 redis에서 사용하는 명령어들이 대부분 이런 방식으로 직관적이고 프로그래머 친화적인 명령어들이 많았습니다. 그래서 쉽게 사용하실 수 있으실 겁니다. 두 번째는 list인데요. 일반적인 Deque라고 생각하시면 되고, index 접근이 가능합니다. Lpush, Lpop, Lindex 이런 명령어들을 통해서 데이터를 읽고 쓰시면 됩니다. 세 번째는 set이고요. 일반적인 set과 같다고 생각하시면 되고, 주요 특징으로는 교집합이나 합집합 같은 집합 연산이 사용 가능하고, set 내의 멤버들에 대해서 랜덤 추출이 가능합니다. 그래서 sadd, spop과 같은 명령어를 통해서 데이터를 읽고 쓰시면 되요. 네 번째는 hash입니다. 일반적인 map과 같다고 생각하시면 되고, 주요 특징으로는 이미지 등의 빅데이터를 저장할 때 zipmap 방식을 사용하기 때문에 좀더 효율적으로 저장할 수 있습니다. Hset, hget 명령어를 통해서 데이터를 읽고 쓰시면 됩니다. 마지막으로 저희가 redis를 선택하고자 했던 가장 큰 이유인 zset인데요. Zset은 내부 데이터들에 대해서 자동 정렬기능을 제공하고요. 스코어 오름차순, 키 오름차순 순으로 데이터를 정렬합니다. 이때 주의해야 할 점이 zset은 동순위 처리가 없기 때문에 이러한 점을 유의해서 개발해주시면 될 것 같습니다. Zadd, zrank 명령어를 통해서 데이터를 읽고 쓰시면 됩니다. 다음 표는 redis에서 제공하는 다섯 가지 타입에 대해서 1부터 100만까지를 기본적으로 redis에 write하였을 때 메모리 사용량인데요. 여기에는 redis 서버가 기본적으로 사용하는 메모리 양이 포함되어있기 때문에 데이터의 직접적인 메모리 양은 이거보다 적다고 생각하시면 됩니다. 결과를 말씀 드리자면 list가 가장 작게 소비되었고, 그 다음으로 set, hash, string, sorted set 순으로 소비하고 있습니다. 그러므로 redis를 사용하실 때는 첫째로 사용하고자 하는 기능이 무엇인지 고려를 하시고, 그러한 기능이 두 가지 타입에서 동시에 지원한다면 메모리 양이 적은 자료구조를 사용하시면 될 것 같습니다. 기본 설명은 여기까지 하고 이제 redis 내에 Lua script에 대해서 설명 드리겠습니다. redis에서 사용하는 Lua script 명령어들은 앞에 보시는 명령어들이 전부고요. 좀 위에서부터 순서대로 스크립트를 실행하고 등록, 확인, 삭제, 취소하는 명령어들입니다. 제가 redis 내의 Lua를 선택했어야 했던 이유를 설명 하기 위해 몇 가지 테스트 결과를 보여드리겠습니다. 횟수는 총 10회씩 진행됐고요. 외부 클라이언트 역시 내부 Lua script와 동일한 환경을 제공하기 위해 Lua script를 활용하였습니다. 외부에서 1부터 100만까지 기본적으로 set을 하였을 때, 10회 평균 걸린 시간이 133.53초가 걸렸고요. 내부 스크립트를 활용하여 똑 같은 테스트를 하였을 때, 평균 3.45초라는 시간이 걸립니다. 그래서 또 다른 테스트로 데이터를 가져와서 변경하고 다시 set하는 방식을 테스트해봤는데요. 외부에서 get-set 테스트를 해봤을 때 10회 평균 263.95초가 걸렸고요. 내부에서 get-set 테스트를 하였을 때는 5.21초라는 시간이 걸렸습니다. 정리해보면, 외부의 경우에는 set과 get-set 테스트를 비교해보면 걸린 시간이 2배가량 증가된 것을 볼 수 있는데요. 내부 같은 경우에는 2배 약간 못 미치게 증가합니다. 그래서 사용되는 명령어들이 많을수록 외부 클라이언트보다는 내부 스크립트가 더 효율이 좋다는 거를 예상해 볼 수가 있어요. 또 redis에서는 Pipeline이라는 기능을 제공하는데요. Pipeline 기능을 사용해서 10개의 명령어를 한번에 redis에 write 하였을 때, 10회 총 걸린 시간은 27.96초입니다. 앞서 테스트했던 set 테스트와 비교해보면 실행속도가 4배에서 5배 정도 빨라진 것을 볼 수 있는데요. 이러한 것들을 하더라도 결과적으로는 내부 스크립트가 훨씬 빠르다는 걸 알 수 있습니다. 추가적으로 저희가 쓰는 MsSQL에서 stored procedure로 똑 같은 작업을 진행하였을 때 총 걸린 시간은 312초였습니다. 놀라운 결과죠. 그래서 결론을 말씀 드리자면 redis에서 내부 스크립트를 실행하는 것은 매우 실행시간이 빠릅니다. 실제로 테스트해보았을 때 2G 정도의 유저 데이터를 확인하고 변경하는 작업을 해봤는데요. 실행 시간이 한 100초 내외 정도 걸렸었습니다. 저는 안정성을 위해서 랭킹에서 필요한 작업들을 2시간 잡고 실 서버에 올렸었는데, 지금은 여러 가지 결과들을 바탕으로, 5분으로 축소한 상태로 운영을 하고 있습니다. 그래서 결과적으로 저희가 랭킹 시스템에서 쓰는 방식은 crontab에서 주기적으로 외부 Lua script로 실행하고, 외부 Lua script에서 다시 내부 Lua script를 실행하는 방식을 도입하고 있습니다. 다음 시스템을 맡았을 때 저는 redis에 대해서 어차피 들어가는 리소스니까 좀더 다르고 많이 활용해보자고 결심을 했는데요. 그렇게 했던 이유가 랭킹 시스템을 통해서 본 redis는 처리속도가 매우 빠르고, I/O를 그렇게 많이 신경 쓸 필요가 없다는 이유였습니다. 실제로 랭킹 시스템에서 게임이 끝날 때나 랭킹 보드를 조회할 때 약 100개 정도의 커맨드를 redis에 전송을 하는데요. 실질적으로 redis서버에는 아무런 장애가 아직까지는 없었습니다. 그래서 결론적으로 redis를 DB가 아닌 확장 메모리로 생각해도 크게 무리는 없다고 얘기할 수 있습니다. 랭킹 시스템을 하면서 내부 Lua script를 활용했을 때, 두 가지 문제점이 있었는데요. 첫째는 일반적으로 작업을 하다 보면 DB내에 데이터를 확인하고, 변경한 후에 다시 업데이트 하는 그런 트랜잭션 작업들이 필요할 경우가 있습니다. RDB에서는 이러한 작업을 stored procedure을 통해서 구현하면 되는데, redis에는 sp가 없죠. 그래서 한 결론이 Lua 스크립트로 stored procedure을 대신해서 어떤 유사 기능을 할 수 있지 않을까? 라고 생각을 했습니다. 그리고 스크립트를 수정이 되면 Linux 머신에 직접 접속을 해서 Linux 서버에 업데이트를 해줘야 되는데요. 저희가 window 프로그래머이기 때문에 Linux에 대한 공포증이 좀 있어요. 그래서 이를 window 게임 서버에서 직접 스크립트의 업데이트를 관리하도록 기능을 합니다. 저희가 사용했던 방식은 일단 첫 번째로 Lua script를 작성하고 서버 프로세스가 실행이 되었을 때 redis에 등록되어 있는 모든 스크립트를 다 삭제해줍니다. 그리고 파일로 스크립트를 읽어와서 이거를 script road 명령어를 통해서 redis에 등록을 합니다. 이때 반환 값으로 sha 값이 반환되는데, 이걸 저장해 놨다가 실행될 때 script가 있는지 확인하고, 없으면 다시 load를 실행합니다. 그리고 스크립트 실행하는 명령어로 실행을 하시면 됩니다. 지금부터 말씀 드릴 거는 Lua script를 내부에서 사용하다가 뭔가 실수할 부분이 있거나, 유의해야 될 점에 대해서 말해보겠습니다. 스크립트 실행이 길어지면 redis는 싱글쓰레드이기 때문에 다른 커맨드 실행이 아예 불가능 하고요. 이때 다른 커맨드를 날리게 되면 그 커맨드는 허공으로 날라가 버립니다.  그렇기 때문에 이러한 점을 고려하셔서 개발하시면 나중에 문제가 생기더라도 그걸 커버할 수 있을 거고요. 실제로 테스트를 해봤을 때는 매우 빠르기 때문에 그렇게 무거운 스크립트가 아니면 크게 신경 쓸 필요가 없을 것 같네요. 그리고 스크립트를 실행하는 명령어에는 return 값이 따로 없어요. 그래서 스크립트가 도중에 실패되더라도 유저가 즉각적으로 알아차리기 힘듭니다. 그래서 특정 키에다가 현재 스크립트 기능 상태를 저장해놓고, 스크립트 실행이 끝나면 특정 키 값을 확인해서 추가 작업을 진행해주시면 좀더 깔끔한 작업 과정이 될 것 같습니다. 또 redis의 명령어들은 상황에 따라서 return 값들이 다른데요. 앞에 보시는 화면은 zrank의 return 값에 대한 설명입니다. 멤버가 존재할 경우에는 int 타입으로 반환을 하고요. 키나 멤버가 없을 경우에는 nil 타입으로 반환합니다. 또한 키가 sorted set이 아닐 경우에 error 타입으로 반환합니다. 그렇기 때문에 이러한 타입들을 자 정리해서 체크해두시면 좀더 오류 없는 개발 과정이 될 것 같습니다. Redis에서 사용하는 명령어들의 상황들은 특수한 명령어들을 제외하고는 5가지 정도로 정리할 수 있는데요. 성공하거나, 실패하거나, 키가 존재하지 않거나, 멤버가 이미 존재하거나, 키가 해당 명령어에 안 맞는 타입이 아니라는 상황을 고려하시면 될 것 같습니다. 또 redis에서 redis와 Lua의 conversion을 확인해보실 필요가 있는데요. 해당 conversion은 아래 보이시는 경로를 통해서 홈페이지에서 확인해보시면 되고요. 한 가지 말씀 드릴 거는 redis의 nil 타입과 Lua의 nil 값은 다르다는 것입니다. 그래서 결론을 말씀 드리자면 redis의 nil 타입은 lua의 false로 반환이 되고요. 이런 것들을 체크하시면 될 것 같습니다. 또한 redis 반환 값 중에 empty라는 값이 있는데, 이 또한 nil과는 다르고요. Lua 테이블의 사이즈가 0이라는 것으로 체크하시면 될 것 같습니다. Redis 내에서 사용할 수 있는 Lua 함수는 좀 한정적이고요. 화면에 보이시는 40개 내외 정도의 함수가 전부입니다. 이런 함수를 확인하실 때는 아래 보이시는 명령어를 redis에 날려서 확인하시면 되고요. 한가지 짚고 넘어갈 점이 redis에는 파일 출력에 관련된 Lua 함수가 없어요. 그래서 print 함수의 경우에는 redis 프로그램에 종속적으로 출력되게 되는데, redis 소스들을 막 뒤지다 보시면 lbaselib.c라는 파일이 있습니다. 거기에 luaB_print 라는 함수가 있는데요. 화면에 보시는 바와 같이 이 부분을 고쳐서 파일 출력을 하라는 주석을 개발자가 친절히 달아놨습니다. 또한 사용자 정의함수를 추가하기 위해서는 같은 파일에 있는 base_funcs라는 배열이 있는데, 여기에 추가하시고 함수도 같이 작성하시면 그 함수 역시 redis에서 사용하실 수 있습니다. 이러한 값들은 이제 안정성이 좀 떨어질 수 있는데 책임은 다 각자의 몫이니까 판단은 알아서 하시고, 저 같은 경우에도 테스트 환경에서만 많이 써보고 아직 라이브에서는 이렇게 변경해서 적용해 본적은 없어요. 그리고 스크립트 외적으로 주의하시거나 말씀 드리고 싶은 부분은 redis를 활용하다 보면 순회 조회할 경우가 있는데, 특정 키들을 그룹 삼아서, 테이블이 없기 때문에 이러한 방법을 어떻게 하면 좋을까? 라고 고민을 해봤을 때, 첫째로 list나 set 같은 경우는 메모리가 적게 들기 때문에 여기에 특정 그룹 키를 묶어서 집어넣고 그 부분을 활용하시면 될 것 같습니다. 다른 방법으로는 keys라는 명령어를 사용하시면 되는데요. Keys 같은 경우에는 공대생들에게 친숙한 ?나 *, [ ] 등을 지원해주긴 하지만 keys 명령어 자체가 모든 키를 순회해서 해당 키를 뽑아주기 때문에 라이브 환경에서는 자제를 하시는 편이 좋을 것 같아요. 또 sorted set은 0부터 시작이 되고, Lua는 1부터 base로 시작이 된다는 거를 체크해주시면 되고요. 여러 개의 값들을 set, get 해야 될 경우에는 pipeline도 있지만 기본적으로 제공하는 mset, mget 명령어들을 활용하시면 명령어 수를 더 줄일 수 있을 것 같습니다. 스크립트에 대한 얘기는 여기까지 하고 다음으로 pup/sub 기능에 대해 말씀 드리고 싶은데요. Pub/sub 기능은 쉽게 말해서 publish와 subscribe 간에 통신을 말하는 것입니다. 사용법은 psubscribe나 Subscribe로 구독하고자 하는 키 값을 등록하고요. 이때 키 값은 여러 개도 등록 가능하고, Psubscribe를 사용할 경우에 패턴 또한 사용이 가능합니다. 그 다음으로 publish 명령어를 통해서 특정 키 값에다가 메시지를 날려주면 그 키 값을 구독하고 있던 모든 클라이언트들에게 해당 메시지가 날라가고요. 이런 것들을 저희 CSO에서는 이번에 추가적으로 유저 로그인이나 로그아웃, 서버 어디에 속해있는 지를 이를 통해서 관리하고 있고요. 아직까지는 서버가 떨어지거나 하는 큰 문제는 없었습니다. 또 말씀 드리고 싶은 거는 pub/sub 명령어를 사용하면 메모리에는 데이터가 남지 않아요. 즉 수만 번 publish와 subscribe를 진행하더라도 메모리에 직접적으로 write를 하지 않기 때문에 이러한 기능을 사용하실 때는 메모리에 대한 걱정은 접어두시고 I/O에 대한 고려만 해주시면 될 것 같습니다. 다음으로 메모리 관리에 관한 명령어들을 소개해 드릴까 하는데요. Redis는 memory DB이기 때문에 비활성 데이터나 일회성 데이터, 그리고 유효기간 데이터는 제때 제때 삭제해 주는 게 효율적으로 사용할 수 있어요. 그런데 점검시간에 Linux에 직접 들어가서 정리하기에는 좀 부담이 있는데요. 이런 것들을 redis에서는 쉽게 사용할 수 있도록 몇 가지 명령어들을 제공해줍니다. 일단 Del 명령어 같은 경우에는 키를 삭제하는 데 사용되고요. 이때 키와 관련된 모든 데이터들은 동시에 삭제가 됩니다. 그리고 expire 시리즈가 있는데, expire를 통해서 expire time을 설정하면 redis 서버 자체에서 시간이 지날수록 1씩 감소시키고요. 이게 0이 되면 삭제가 됩니다. ttl 명령어를 통해서 expire time을 확인하실 수 있고, 그리고 expire time을 삭제하고자 하실 때는 persist 명령어를 사용해주시면 됩니다. 이를 저희 CSO에서는 어떻게 활용했냐면, redis에 어떤 데이터를 집어넣을 때 기본적으로 expire time을 설정하고요. 그리고 저장하고자 하는 특정 데이터가 있으면 그 키를 일단 삭제시킨 다음에 persist를 통해서 새로운 키에 expire time을 삭제하고, rename을 통해서 다시 그 키를 새로운 저장 데이터로 지정합니다. 이런 식으로 지난주 데이터 등을 관리했습니다. 마지막으로 정리를 하자면, redis는 명령어들이 프로그래머들한테 사용하기 쉽게 되어 있어요. 그리고 pub/sub 기능을 사용하면 동기화 문제도 쉽게 해결할 수 있고, 명령어 순서 역시 쉽게 구성하실 수 있습니다. 또한 sorted set 사용하면 정렬 속도도 빠르고요. Memory DB인 만큼 데이터 I/O의 속도도 빠르고, Lua script를 사용하시면 데이터 처리 속도 역시 빠르다고 보실 수 있습니다. 단점으로는 Linux만 정식 버전이 나와있다는 것과 멤버들을 조회하기 위해서 RDB 같은 where 나 join 기능이 없기 때문에 약간 스크립트를 매번 생성해서 조회를 해야 한다는 단점이 있는데요. 역시 RDB 파일을 사용하시면 쉽게 조회가 가능합니다. 그러므로 결론은 redis는 쉽고 빠르기 때문에 한번 사용해보시는 것도 좋을 것 같아요. 제 발표는 여기까지입니다. 감사합니다.
(박근희)_ Sorted set에서 동률 처리는 어떻게 했냐면, 일단 sorted set에 저장 되어있는 스코어에다가 부가 정보를 붙였어요. 부가 정보를 붙여서 그 스코어를 재가공해서 절대 동 순위가 안 나오도록 처리를 했고요. 이때 유의하셔야 할 점이 유효 숫자에 대해서 좀 생각을 하시고 스코어를 증가시키면 될 것 같네요. 또 다른 방법으로는 일단 순위를 알고자 하는 멤버의 스코어를 얻어온 다음에 해당 스코어와 같은 멤버들을 동시에 얻어올 수 있는 명령어가 있어요. 같은 스코어들의 멤버들을 전부다 얻어와서 게임 서버에서 자체적으로 순위를 매기는 방법도 있고요. 또 다른 방법으로 redis 자체에서 제공하는 가중치를 이용해서 sorted set을 재구성하는 방법도 있습니다. 마지막 방법은 사용해보지는 못했어요.
(박상기)_ 두 번째, “redis가 C++ 지원이 약한데, 어떤 거 썼나…” 
아까 말씀을 드리긴 했는데, 저희는 hiredis라는 C 라이브러리를 쓰고 있는데, 그거를 C++ 개발하니까 좀 쓰기 어려워서 porting을 하긴 했고요. 사실 그것보다 window 지원이 얼마나 되냐가 더 문제가.... 그렇고
그 다음 질문은 “메모리 기반의 DB이고, master-slave가 바뀌면 당연히 쿼리가 유실될 수 있는데, 어떻게 보안하셨나?” 
이런 건데요. 사실 저희는 master-slave 구성을 안 했어요. 저희가 redis 넣고 6개월 정도 써봤는데, 사실은 여러 서버가 있어요. 많은 서버를 redis로 투입했는데, 4~5만 되는 데에도 사실은 redis 서버가 한번도 장애가 일어난 적이 없어요. 아직 1년이 안됐기 때문에 확답은 드리기 어렵지만 만약에 자원이 부족하면 master-slave를 굳이 안 해도 될 것 같고요. 
이거 할게요. “처음부터 그룹단위 랭킹이 요구사항이었으면 redis를 도입하겠냐?”
라는 데, 저는 무조건 할 거였어요. 할 생각이었고, 필요한 건 명분이었습니다. 명분이어서 랭킹은 무조건 필요하다. 이런 식으로 설득은 하긴 했어요. 그런데 처음에는 이게 얼마나 좋을까? 라는 게 좀 의문이었는데, 넣어 보니까 저희 랭킹 외에 매칭 시스템이라고 있는데 그런 것도 쓰고 있고요. 유저 세션 관리도 쓰고 있어서 redis를 쓰는 게 저는 성공한 것 같고요. 라이브 개발 중이시면 명분을 찾아서 하면 될 것 같습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
