Flitto는 초기부터 Node.js를 사용하여 서비스를 개발 및 운영하고 있습니다. 중국을 포함하여 글로벌 서비스를 운영하면서 여러가지 겪은 문제점과 고민, 그리고 그 해결방법에 대하여 발표합니다.

1. 를 사용한
대규모 글로벌(+중국) 서비스
2016/11/23
Flitto 강동한

2. 발표자 소개
• Flitto에서 5년째 커피를
타고 있습니다.

3. Flitto?
언어 데이터
C O R P U S
번역 플랫폼
T R A N S L AT I O N P L AT F O R M
+

4. Flitto?
1 : 1
전 문 번 역
S O C I A L
M E D I A &
컨 텐 츠 번 역
집 단 지 성
번 역
실 시 간
번 역 추 천커 머 스

5. 기술 스택 소개

6. node.js 사용 환경
• v6.9.1 LTS 버전 사용중 (’16/11/01 현재)
• A사 cloud 3개 리전, 약 20개의 인스턴스에서 사용중
• 스크립트들도 가급적 node.js 를 사용
• CPU, 메모리 적게 먹어서 참 좋음..
• 그런데… 버전업이 참 빠르네?

7. Node.js in Flitto
• v0.8.8 - ’12/09/07
• v0.10.x
• v0.12.x
• io.js test
• v4.2.1 - ’15/10/27 (v4.2.0 LTS ’15/10/12)
• v6.9.1 - ’16/11/01 (v6.9.0 LTS ’16/10/18)
• => 만 4년 넘게 node.js 로 서비스 중..
in

8. Node.js in Flitto
• 왜 node.js 로 시작했나요?
• 혼자 Front-end, Back-end 등 다해야 해서..
• Cloud service 무료 크레딧 최대한 이용하려고…
• 2012년에는 왠지 cool해 보여서..

9. 주요 발표 내용
• node.js로 5년째 개발하면서 만났던 문제들
• 사실 별거 없었습니다만.. 그래도..
• node.js 버전 업데이트는 어떻게 하나요?
• 구조 개선을 통한 효율 증가
• 중국에서 서비스 하기
• 그 외..

10. node.js 버전 관리는 어떻게 하나요?

11. node.js 버전 관리는 어떻게 하나요?
• 또… 새버전 나왔어요…?
• 지난 주에 버전업 했는데…

12. node.js 버전 관리 원칙
• LTS 는 서버에서 얼른 업데이트
• Minor, Patch 업데이트는 Change Log를 보고 중요도에 따라 적용
• Major 버전 업데이트시 사내 Coding Convention도 업데이트
• Current 버전은 개발자의 재량으로 사용
• 아무도 안씀.. 내가 먼저 쓰자
• Open source maintaining 하는 repository 는
최대한 많은 버전을 지원하도록.. (travis ci 사용)

13. node.js 버전업 - 준비
• 각종 라이브러리가 지원하는지 확인
• n 패키지를 통해 틈틈히 작업하면서 테스트
• node-gyp 등으로 컴파일 하는 라이브러리는 점점 사용하지 않게 됨
• ex> geoip, node-xml2json 등
• 특별한 방법이 없이.. 하나씩 올리면서 테스트
• 이때 test case 가 큰 도움
• node 6.x 로 버전업 할때 주의점
• GLOBAL => global
• graceful-fs deprecate warning

14. node.js 버전업 - 작업
• 하루 날 잡고, 빌드 서버부터 update를 함..
• 새벽 작업은 1년에 두세번쯤 하는데 그 중 하나가 node.js 버전업
• 작업 순서(서버)
1.node.js 기존 패키지 삭제
2.node.js 신규 패키지 설치
3.npm cache clean ; rm -rf ~/.node-gyp
4.CI 등을 이용하여 다시 배포

15. node.js 버전업 - 작업후 코딩 컨벤션 업데이트
• v6.9.1 업데이트 후, 새로 추가된 사내 컨벤션 규칙 (예시)
• Arrow Functions

16. node.js 버전업 - 작업후 코딩 컨벤션 업데이트
• Spreading operator
• Destructuring

17. push 구조 개선을 통한 효율 증가

18. push 구조 개선을 통한 효율 증가
• 어제까지는 잘 돌았는데..
• 오늘은 왜..?

19. • 플리토 서비스 내 푸시 로직
• 특정 이벤트 발생시, 푸시를 개인화 하여 보냄
• redis에 개인의 push id list와 push 내용을 저장
• 이 때 redis key에 TTL을 7일로 설정
user_id: 홍길동
id[0]: 1
id[1]: 11
push 구조 개선을 통한 효율 증가
id: 1
상태: 읽음
내용: 새로운 요청
id: 11
상태: 안읽음
내용: 새로운 컨텐츠

20. push 구조 개선을 통한 효율 증가 - 첫번째 코드
• 먼저, 이벤트 발생 시, 대상 user list 추출함.
• Step 라이브러리의 this.group() 을 사용하여
• 개인별 push 내용을 redis에 넣고, 개별 push를 전송

21. push 구조 개선을 통한 효율 증가 - 첫번째 코드

22. push 구조 개선을 통한 효율 증가 - 첫번째 코드
• 간단하게 개발했는데, 잘 동작하네..?
• TTL에 따라 push 내용 자동 삭제도 되니 좋은걸?
• 수만개가 되니 갑자기 서버가 응답 없음..

23. push 구조 개선을 통한 효율 증가 - 두번째 코드
• (이 시점엔 문제를 심각하게 생각하지 않았습니다)
• 요즘 대세는 Step이 아니고 async 이니,
• async를 이용해 볼까?

24. push 구조 개선을 통한 효율 증가 - 두번째 코드

25. push 구조 개선을 통한 효율 증가 - 두번째 코드
• 예상대로 서버는 또 죽었습니다..

26. push 구조 개선을 통한 효율 증가 - 세번째 코드
• 근본적인 문제를 생각하기 시작
• Maximum call stack size exceeded 를 막기 위하여
나누어 하기로 함
• 5,000개씩 쪼개서.. async.queue 사용
• queue concurrency 는 1로

27. push 구조 개선을 통한 효율 증가 - 세번째 코드

28. push 구조 개선을 통한 효율 증가 - 세번째 코드
• 다행히도 이제 죽지는 않음
• 하지만 전송 시간이 7분

29. push 구조 개선을 통한 효율 증가 - 네번째 코드
• push의 공통 요소 별로 묶되,
개인화 요소는 개인의 key에만 관리
• async.queue를 이용하되 한번에 push서버로 보냄
user_id: 홍길동
id[0]: 1:읽음
id[1]: 11:안읽음
id: 1
내용: 새로운 요청
id: 11
내용: 새로운 컨텐츠
user_id: 김길동
id[0]: 11:읽음

30. push 구조 개선을 통한 효율 증가 - 네번째 코드
user_id: 홍길동
id[0]: 1:읽음
id[1]: 11:안읽음
id: 1
내용: 새로운 요청
id: 11
내용: 새로운 컨텐츠
user_id: 김길동
id[0]: 11:읽음
user_id: 홍길동
id[0]: 1
id[1]: 11
id: 1
상태: 읽음
내용: 새로운 요청
id: 11
상태: 안읽음
내용: 새로운 컨텐츠
user_id: 김길동
id[0]: 12
id: 12
상태: 읽음
내용: 새로운 컨텐츠

31. push 구조 개선을 통한 효율 증가 - 네번째 코드

32. push 구조 개선을 통한 효율 증가 - 네번째 코드
• 기존 7분 걸리던 것에서 반만 줄여도 성공인데..
• 적용해 보니 20초 만에 수십만 push 처리

33. 중국에서 서비스 하기

34. 중국에서 서비스 하기
• 한국 인구의 1%는 50만
• 중국 인구의 1%는 1,350만
• 니…하오?

35. 중국에서 node.js 서비스 하기
• 들어가기 전에
• 비즈니스, ICP 관련된 내용은 여기서 다루지 않음
• 제한 사항
• 서버가 중국에 존재해야 할 수 있음
• Frontend/Backend가 두벌이 필요할 수 있음

36. 생각의 전환이 필요합니다
• 중국은 단지 하나의 국가가 아닌
• 또 하나의 global이라고 생각해야 합니다.

37. 어느 cloud를 이용할 것인가
• 설마 서버를 직접 사서 넣진 않았겠죠?
• 각 cloud별 비교 테스트
• Aliyun
• AWS
• Qingcloud

38. 중국의 network 환경
• GFW
• 참고: 만리장성(the Great Wall)
• 중국의 Great FireWall 을 뜻함
• 외부 ping test
• 중국 서버 => 해외 서버(singapore) 24시간 ping test
• 패킷 loss 평균 7%
• 평균 27X ms

39. 구축 초기
• npm이 왜 이렇게 느리지…
• npm loves you, but doesn’t love China?
• npm install 실행하고 오랜 시간이 걸릴 때가 종종 있음
• 긴급 배포시 문제가 될 가능성
• npm이 지금은 많이 빨라졌으나, cnpm도 사용 고려

40. cnpm이란?
• cnpm이란?
• china…npm?
• https://npm.taobao.org
• npm을 중국내 CDN에 주기적으로 동기화
• sync 등의 명령어를 통한 수동 동기화도 지원
• cnpm을 이용한 패키지 인스톨시,
내부적으로는 npminstall package를 이용합니다.
• GitHub private repo 사용 시 문제 발생할 수 있음: --by=npm 옵션 고려

41. 구축 초기
• OS package 업데이트도 오래 걸림
• 즉, node.js 버전업도 오래 걸림
• 가끔 github도 많이 느림
• 긴급 상황에 bug fix 배포가 안될 수도 있음
• 빌드/배포는 중국 서버에서
• 중국내에서 해외로, 해외에서 중국으로 API 호출시
timeout 이 종종 발생

42. 서비스 속도 향상
• 중국내 CDN 사용
• 해외 CDN vs 중국 CDN
• 118kb file D/L test: 7.8초 vs 100ms
• 글로벌 서버와 전용망 구축 고려
• 하지만 비용이 많이 비쌈

43. 회원 가입 부터가 문제
• 휴대폰 번호 가입을 지원해야 함
• SMS 발송 기능 추가시 abuser 주의
• CAPCHA - ccap
• WeChat, Weibo, QQ 등의 중국 SNS 로그인
• passport를 이용
• 중국 외 서버에서 중국 SNS API호출시 느릴 수 있음

44. 결제는 어떻게?
• 중국인은 신용카드 사용하지 않음
• iOS: 인앱결제가 가능은 함
• android: 100여개의 앱스토어..
• 현지 PG이용해야 함
• Alipay
• Wechatpay

45. 결제는 어떻게?
• 대부분 중국어 문서 밖에 없음
• 개발자 문서 번역은?
• 번역은 플리토!
• 플리토를 이용한 번역 후 작업
• github.com/flitto/wechatpay

46. 개발 문서 번역 예시
除被扫支付场景以外，商户系统先调用该接口
在微信支付服务后台生成预支付交易单，返回正
确的预支付交易回话标识后再按扫码、JSAPI、
APP等不同场景生成交易串调起支付。
vs
G사 번역
Flitto 번역

47. App Push 는?
• iOS 는 apn을 그대로 사용
• android 는 baidu push를 사용
• node.js 용 공식 라이브러리는 없어서, 직접 개발..
• app SDK 업데이트를 꾸준히 해줘야 함

48. 그 외..

49. 그 외..
• node.js 특성상 서버 리소스가 비교적 적게 필요함
• 대부분의 인스턴스를 A사의 t2시리즈 사용 중
• 수십만개 push를 보내는 서버도 t2.small 인스턴스 사용중
• 비동기 처리는 사내에 Rule이 있으면 좋음

50. 앞으로 해결해야 하는 문제들
• 더 좋은 번역가 추천 알고리즘
• 지속적인 서비스 개선
• open API
• AR, AI, Machine Learning
• 쌓여 가고 있는 데이터를 활용한 무언가
• …

51. 앞으로 해결해야 하는 문제들 - 해결책
• 해결하실 수 있는 분은 바로 여러분!
• 세상에 없던 서비스를 만들어 나가며, 세상에 없던 문제를
같이 해결해 나갈 분을 찾고 있습니다.
• jobs@flitto.com

52. kang@flitto.com
github.com/dankang
감사합니다.