우리가 이름만 들어도 아는 유명 IT 서비스들의 화려한 웹페이지도, 예쁜 모바일 앱도 그 뒤에는 탄탄하고 강력한 분산 시스템을 기반으로 합니다. 이러한 백엔드 시스템이 부실할 경우 서비스나 앱은 그야말로 사상누각입니다. 본 세미나에서는 이러한 시스템들을 만들때 풀어야 할, 가장 기본이 되는 문제와 이슈들 12가지에 도전해봅니다.
우리가 이름만 들어도 아는 유명 IT 서비스들의 화려한 웹페이지도, 예쁜 모바일 앱도 그 뒤에는 탄탄하고 강력한 분산 시스템을 기반으로 합니다. 이러한 백엔드 시스템이 부실할 경우 서비스나 앱은 그야말로 사상누각입니다. 본 세미나에서는 이러한 시스템들을 만들때 풀어야 할, 가장 기본이 되는 문제와 이슈들 12가지에 도전해봅니다.
이 발표는 [야생의 땅: 듀랑고]의 지형 배포 시스템과 생태계 시뮬레이션 자동화 시스템에 대한 이야기를 다룹니다. 듀랑고의 각 섬은 크기와 지형, 기후 조건이 다양하고 섬의 개수가 많아서 수동으로 관리하는 것은 사실상 불가능합니다. 몇번의 사내 테스트와 베타 테스트를 거치면서 이러한 문제를 해결해주는 자동화된 도구의 필요성이 절실해졌고, 작년에 NDC에서 발표했던 생태계 시뮬레이터와 Docker, 그리고 아마존 웹서비스(AWS)를 이용하여 수많은 섬들을 자동으로 생성하고 관리하는 자동화 시스템을 구축하게 되었습니다. 그 과정에서 했던 고민들, 기존의 애플리케이션을 "Dockerizing" 했던 경험, AWS의 각 서비스들을 적절히 활용했던 이야기, AWS의 각 지역별 요금이 상이하다는 점을 이용해서 비용을 절감한 사례, 그리고 자동화 시스템의 문제점과 앞으로의 방향에 대해서 이야기 할 계획입니다.
(GameTech2015) Live Operation by Adbrix의 Node.js와 MongoDB를 이용한 멀티테넌트 인프라 구축사례Jeongsang Baek
대부분의 중소 모바일 게임 업체는 앱을 잘 만들기에도 시간이 모자라 출시일을 잘 맞추기 급급한 상황이다. 그러다 보니 운영을 위한 툴은 소홀히 개발하는 경우가 대부분이고 운영 캠페인은 날림으로 개발하거나 그때 그때 개발자가 필요한 부분만 개발하기 일쑤다. 그러다보니 마케터는 결국 늘 개발자 눈치만 살피게 된다. 필자는 블루윈드에서 이러한 문제를 절감했고 '모바일 게임 개발사가 앱 개발에만 집중할 수 있게 해주고 싶다'는 IGAworks의 철학에 공감하여 라이브 오퍼레이션 프로젝트를 시작하게 되었다.
라이브 오퍼레이션의 개발 중점과제는 5가지였다. 첫번째, 다수의 개발사가 하나의 큰 클라우드 시스템을 사용하도록 multi-tenant 인프라를 구축해야 한다. 두번째, TCO(Total cost of ownership)를 최소화해야 한다. 세번째, 앱의 핵심유저를 실시간으로 그룹화하여 타게팅 캠페인을 할 수 있어야 한다. 네번째, 캠페인의 성과를 마케터에게 실시간으로 피드백해야 한다. 다섯째, 3개월 안에 정식 서비스가 되어야 한다는 점이었다. (왜 우리에게 주어지는 시간은 늘 3개월인가) 그리고 당연하지만 이 서비스를 혼자 개발해야 했다.
이 다섯가지 이슈를 해결하기 위하여 AWS 클라우드 상에 생산성과 성능이 검증된 node.js 와 mongodb를 이용하여 서비스 백엔드를 구성하였고, multi-tenant를 구성하기 위한 여러가지 고민과 그 해결책을 직접 구현하였다. 필자는 node.js와 mongodb를 사용해 본 경험이 충분하다 생각했지만 대규모 정식 서비스를 진행하며 많은 함정에 빠졌고 결국 해결했다.
이 발표를 통해 청강자는 node.js와 mongodb를 이용하여 multi-tenant 인프라를 구축해야 할 때 고려해야 할 설계 방식과 기술적인 고민, 그것에 대한 현실적인 해법을 얻을 수 있다.
Obfuscation 101
: 난독화, 프로가드, R8, 트랜스포머 API
김용욱
카카오뱅크
영화와 커피를 좋아하는 은행원. 반지 원정대는 극장에서만 15번을 보았다. 데이터베이스를 전공했지만 급변하는 모바일 환경에 반해 안드로이드에 승선했고 Realm을 통해 모바일과 데이터베이스를 융합했다. 그후 새로운 가능성을 찾아 금융으로 왔다.
빌드? 우선 사용부터 매뉴얼? Getting started 한 번 돌려보기 TV 리모컨 버튼 5개 전문가는 교육받아 만들어진다? 경험=시간+시행착오+성공실패 오픈소스 트러블슈팅 “메시지” 구글링 오픈소스 함부로 수정하지 마라 최신 버전을 대하는 우리의 자세 LTS로 대동단결 팀장 설득하기 오픈소스는 공짜가 아닙니다. 저도 기여하고 싶어요 2,000년 톰캣을 시작으로 Ant, Eclipse, JUnit, JMeter를 거쳐 현재 개발에 잘 사용하고 있는 Yona, Git, VSCode, Jenkins, CentOS, VirtualBox, Nginx, Node.js, Express.js, MariaDB, Uptime, Mocha, SonarQube, ZAP 이야기 등입니다.
https://www.youtube.com/watch?v=5LHOTBxG0hc
3. 오늘 할 이야기들
• Redis 3.x 부터 최근까지(2.8도 조금)
• 가볍게 살펴보고 깊게 들어가지 않습니다.
버전 추가된 기능
2.8 HyperLogLog
3.0 Redis Cluster
3.2 GeoHash
4.0 Redis Module
4. HyperLogLog #1
• From 2.8
• 유니크한 유저를 구하는 방법
• 원리는 논문을 참고하세요. 키워드로 검색하면 바로 나옵니다.
• 저도 원리는 모릅니다.(묻지말아주세요. 해당 질문도 사절합니다.)
• http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf
5. HyperLogLog #2
• 화장품 광고의 타켓 두 그룹
• A: 20대 후반 여성(50만명)
• B: 서울의 여성(100만명)
• A+B의 Unique 한 광고 타겟은 몇 명일까?
• 50만명 + 100만명 = 150만명?
• 유니크한 유저를 다시 구해야 할까요?
• 다른 광고 타켓 C가 추가되면?
6. HyperLogLog #3
• 유니크 유저는 어떻게 구해야 하나요?
• A그룹을 로딩해서, B그룹에 존재하는지 일일이 찾아야 합니다.
• 유저 수가 클 수록 시간이 많이 걸리게 됩니다.
7. HyperLogLog #3
• HyperLogLog를 쓰시면 A그룹과 B그룹을 pfmerge 하면됩니다.
• 확률적 자료구조중에 하나!!!
• 실제로 정확한 값 대신에 근사값을 구하는 방법
• 정확성을 포기하는 대신에 속도와 메모리에서 이득을 봄
• 메모리를 더 쓰면, 정확도가 더 올라감.(더 떨어질수도 ㅎㅎㅎ)
• 거의 고정된 메모리를 사용합니다.
• 확륙적 자료구조는 다음페이지를 참고하세요.
• http://d2.naver.com/helloworld/711301
Redis Set HyperLogLog
유일한 개수 67,781 67,640
8. HyperLogLog #4
• PFADD, PFCOUNT, PFMERGE 의 세 가지 명령이 있습니다.
명령어 내용
PFADD HyperLogLog 를 생성한다.
PFCOUNT HyperLogLog 내의 Unique한 값을 보여준다.
PFMERGE HyperLogLog 그룹을 하나로 합쳐준다.
9. HyperLogLog #5
• PFADD pf1 a b c d e f g
• PFCOUNT pf1
• 7
• PFADD pf1 a b c z
• PFCOUNT pf1
• 8
• PFADD pf2 e1 e2 e3 e4 a b
• PFCOUNT pf2
• 6
• PFMERGE pf3 pf1 pf2
• PFCOUNT pf3
• 12
10. HyperLogLog #6
• 당연히 전체 데이터를 가지고 있지 않으므로, 전체 목록을 얻을 수 없음.
• 즉 해당 목록은 따로 관리하고 있어야 함.
11. Redis Cluster #1
• From 3.0
• 모두가 기다리던 Redis Cluster
• 그런데 결과적으로는 좋아하는 곳도 있고,
• 아닌곳도 많습니다.
13. Redis Cluster #3
• Slave 노드는 자신의 Master의 내용만 들고 있음.
• 즉 Node #2의 Master, Slave 가 모두 장애가 났을 때는 그냥 데이터 유실.
• Slot의 재분배를 통해서 데이터의 이동이 가능함.
• Migration 중인 Slot은 잠시 사용 불가.
15. Redis Cluster #5
• No Redirection
Node #1
Master
Node #2
Master
Node #3
Master
Client
set kosslab 123
저장
16. Redis Cluster #6 – no cli cluster mode
• cli> set kosslab 123
• -> (error) MOVED 0 127.0.0.1:7002
• cli> set openfrontier 123
• -> (error) MOVED 13000 located at 127.0.0.1:7000
• cli> get kosslab
• -> (error) MOVED 0 127.0.0.1:7002
• cli> get openfrontier
• -> (error) MOVED 0 127.0.0.1:7000
17. Redis Cluster #6 – cli cluster mode
• cli:7001> set kosslab 123
• -> Redirected to slot [0] located at 127.0.0.1:7002
• OK
• cli:7002> set openfrontier 123
• -> Redirected to slot [0] located at 127.0.0.1:7000
• OK
• cli:7000> get kosslab
• Redirected to slot [0] located at 127.0.0.1:7002
• “123”
• cli:7002> get openfrontier
• Redirected to slot [0] located at 127.0.0.1:7000
• “123”
• 이 부분은 cli에서만 처리해주는 것이므로, Redis Cluster가 해준다고 착각하면 안됨
24. Redis Cluster #13
• 실제로 쓰는 사례가 있나요?
• C모사, L모사
• 특히 L모사에서는 좀 크게, 엄청 잘 쓰고 있다고 합니다.
• 좀 더 안정적으로 운영할려면?
• Slave를 두 개씩 쓰거나…
• 특정 노드의 Master 가 죽으면… 곧, 새 Slave를 하나 추가해주거나…
25. Redis Cluster #14
• 장애 시 동작
Node #1
Master
Node #2
Master
Node #3
Master
Node #2
Slave
Node #3
Slave
Client
New Node
추가
26. GeoHash #1
• From 3.2
• Redis 도 GeoHash가 지원됩니다.
• 우버 같은 서비스를 만든다면?
• 각 우버드라이버의 위치 정보가 존재(지속적 업데이트)
• 우버사용자의 위치가 존재
• 현재 사용자의 위치에서 반경 K 킬로미터에 있는 우버드라이버의 리스트를 가져온다면?
• 우버나 포스퀘어나 MongoDB에 저장하는 걸로…
• K모 서비스도…
• 실제로는 geohash를 만들어서 Sorted Set에 저장합니다.
27. GeoHash #2
명령어 내용
GEOADD GEO Location 정보를 추가한다.
GEOHASH 해당 위치 정보에 대한 해식밧을 출력한다.
GEOPOS 해당 유저의 지역정보를 출력한다.
GEODIST 두 지역간의 거리를 출력한다.
GEORADIUS 특정 지역 반경에 존재하는 객체를 조회한다.
GEORADIUSBYMEMBER 특정 객체 반경에 존재하는 객체를 조회한다.
29. Redis Module #1
• From 4.0
• Redis는 lua script를 지원함.
• lua script 사용의 단점
• 성능이 느리다.(네이티브로 돌았으면 좋겠다.)
• 그러면서 다양한 기능을 커버했으면 좋겠다.
• Redis PR의 대부분은 기능 추가
• 기존에 잘 받아들여지지 않음.(가벼운(?) 서버를 지향.)
30. Redis Module #2
• Redis Module
• Dynamic Loading Library(.so)
• 플러그인 방식으로 Redis Command를 동적으로 등록할 수 있다.
• 기존 명령을 바꿀 수는 없지만, 내부적으로 사용이 가능
• 새로운 명령을 등록함으로써, 자료구조를 추가할 수 있다.
31. Redis Module #3
• RedisLabs Module Repository
• https://github.com/RedisLabsModules
• bloomfilter, Full-Text Search 같은 모듈이 이미 만들어져 있음
32. Redis Module #4
• 모듈 작성시 주의 사항
• Redis는 Single Threaded 이므로, 모듈에서 긴 시간 처리하는 경우 Redis 자체가 블
럭되어 버림.
• 모듈에서 장애가 날 경우, Redis 서버 자체가 종료됨.
• Master/Slave 형태일 경우는, 장애를 대비해서 Slave 들도 해당 모듈을 다 로드해야
함.
• Redis 코드 자체가 익숙할 경우는 모듈 개발이 어렵지는 않음.
33. Redis Module - Rebloom #1
• Bloom Filter Datatype for Redis
• 확률적 자료구조 중의 하나
• 있다고 하면 없을 수 있으나, 없다고 하면 반드시 없는 특징을 가짐.
34. Redis Module - Rebloom #2
• BloomFilter의 원리
• BloomFilter는 BitArray 의 일종
• 3개의 hash(x) 가 있다고 하고, bitarray의 크기가 16이라고 할 때
• foobar 가 들어갈 때 세 개의 hash에 나온 값을 masking 한다.
35. Redis Module - Rebloom #3
• 있는지 검사시에 해당 bit 가 모두 마스킹 되어있으면 있다고 가정한다.
• 실제로 다른 hash 함수에 의해서 이미 masking 되어 있을 수 있으므로, false
positive(없는데, 있다고 하는게…) 발생함
• 그러나 없다고 한 경우는 해당 bit가 masking되지 않았으므로 절대로 없음.