IF kakao 참가 후기

IF kakao 참가 정리

9월 1일에 뒤늦게 당첨된걸 깨달아서 부랴부랴 바쁜 와중에 다녀왔습니다ㅠㅠ… 전체적으로는 참고해서 적용해보고 싶은 구조 및 기술 스택이 많았습니다 다만 발표해주신 연사분도 깊은 생각을 한 뒤에 도입을 한 건 아닌거같은 내용이 간혹 있어서, 따로 공부를 더 한 뒤에 실 서비스에 적용 가능한지에 대해서 고민해보려 합니다.

키노트

카카오의 핵심가치?

일종의 세션 소개였습니다.

• 안정성
  • 클라우드 네이티브 플랫폼, 서버사이드 코틀린 등
    • 안정성에서 서버사이드 코틀린을 언급한게 조금 이상하긴 했습니다.
• 사용자 경험
  • 기술의 우수성/ 우월성보다는 사용자의 불편을 어떻게 해결할지에 대해 초점
  • 다음 메인 / 다음 웹툰 메인 개선 등의 세션
• 데이터
• next innovation
  • ai, blockchain (카카오가 집중하고 있고, 앞으로 투자 예정)

카카오 ai (kakao i)

현재 kakao i 의 업무 스타일과 발전 방향에 대한 카카오의 입장을 소개했습니다.

• 30만건의 발화 인식 가능
• 명령어 인식 실패율 5.9% (현재)
  • 데이터, 새로운 알고리즘 적용 및 발전.
• 15개 도메인에 대한 서비스 시작, 6개월 동안 40여개의 도메인에 대한 서비스 중
  • open builder를 사용하게 된 장점들을 소개 open builder가 뭐지?
• open builder를 이용해 카카오 챗봇 / 미니를 동시에 개발하고 있음
  • (클로바와 비슷)

카카오 미니

• 카카오 미니(kakao i)에 카카오 네비를 이식.
• 카카오 네비를 음성으로 조작
  • 내년 중 출시 예정
• 현대 자동차 kakao i 협력, 차량 대시보드 / 에어컨 조작등을 카카오 i로 조작.
  • 19년형 신차에 적용될 예정

카카오 홈

• GS건설, posco 건설과 협력
  • 평택 소사벌 신축 아파트에 적용 (옛날에 유비쿼터스 홈 같은 느낌)

카카오 i, 카카오 미니, 카카오 홈 open api 추가

• 2018년 12월 예정

카카오의 목표

• 개발자들이 모이는 장을 만드는 것.
  • ai 컨퍼런스, csi 워크샵, 봇경진대회, pay talks ,블록 체인 위크, txgx, if kakao, 딥러닝 캠프, 카카오 아레나, 코드페스티벌 등
  • 카카오 블라인드 채용
    • 이건 좀 궁금하긴합니다 - -;
  • 기술 개방을 통한 기여
  • 밋업 @ 카카오 오피스,
  • 개발자 컨퍼런스 및 학계 세미나 후원
  • 대학원생 후원

AI 시대에 맞는 서비스 개발

연사

• 이석영 (zodiac.lee) / 카카오

서비스 개발의 맹점?

• AI Product가 개발자의 일을 대신해 주진 않는다.
• ai product의 종류는 크게 세가지 형태로 나타낼 수 있을 것.

intelligence

• 딥러닝, 텐서플로우, 알파고

NUI

• NUI가 무엇인가요?
  • NLU(Natural Language Understanding)/ ASR(Automatic Speech Recognition)/ VR(Voice Recognition), Alexa, Google Assistant

movable

• 보스턴 다이내믹스

NUI (Natural User Interface)

• 기존 서비스를 NUI에 맞게 변화시키는 것이 중요
  • 음성인식/ 화상 인식 등의 영역을 서비스에 녹여내야 한다.
• CUI -> GUI가 자연스럽게 이뤄진것처럼, GUI 이후에는 NUI, VUI (voice user interface)로 변화가 이루어질것
• 한번 변화가 생기면 그 흐름은 지속됨
  • GUI가 대두되고 난 뒤에는 CUI로 돌아가지 않게 되었다.
• GUI는 한계가 있다
  • N-depth touch
    • 여러 터치를 해야함
  • 멀티태스킹 불가
    • 시선과 손 동시 활용해야함
• 아마존 에코 (2014) - GUI가 배제된 순수 음성인터페이스 디바이스의 등장.
• NUI는 일시적 유행이 아니라 사용자 경험 혁신의 큰 방향

카카오 미니

• 일 평균 80분 사용.
• 6개월동안 20만대 배포됨
• 카카오 미니 주중에는 7시~8시에 가장 많이 사용되고 주로 뉴스, 알람, 날씨 주가 등 사용. 주중/주말 오후에는 음악, 라디오, 팟캐스트 등 사용
• 앱의주요기능 =/= 봇의 주요기능
  • 봇에서는 추천 / 재생목록을 여러 형태로 제공할 수 있어야 한다.

개인적인 생각

• 별 내용이 없었다;
  • NUI의 중요성은 알겠지만, 서비스별로 다른 점을 고민하기 보다는 자신이 개발을 하다보니 편하다
  • ai의 중요성은 있지만, 어떻게 품질 관리를 할 수 있는지에 대한 목표가 잘 보이지 않음
    • 어떤 명령이 성공하고, 실패했는지에 대한 판단을 어떻게 할지가 궁금
    • 질문들도 NUI와 VUI보다는 미니 관련 서비스의 출시에 대한 궁금함이 더 많은 느낌이었습니다.

카카오의 광고 지능

연사

• 정부환 ben.hur

광고의 life cycle

• 광고 추천 / 광고 영역의 제공의 반응시간이 100ms 이내로 이뤄져야함 (현재 다음의 기준)
• 광고에 다다르는 청중, 광고주, 플랫폼, 퍼블리셔 간의 목적이 다르다.
  • 청중
    • 화남 vs 정보
  • 광고주
    • 마케팅 채널
  • 퍼블리셔
    • 보장된 수익
  • 플랫폼
    • 효용성 최적화, 유저 만족도
• 광고 수익의 판단
  • eCPM (effective cost per mile, 1000회 노출에 따른 수익)
    • bid amount x likeness
  • 클릭당 과금 (CPC 상품)
    • BA(bid amount) x pCTR(number of clicks / number of impressions)
• 광고 효율

  • Pr(y=1

    x, ad) y = click, x = user

    • 광고 효율은 확률로 측정하게 된다 (0과 1로 표시하기 어려움)
  • reactive method vs predictive method
    • 세그먼트가 많아질 수록 수집해야하는 데이터가 많아지고, 이렇게 되면 정확도가 떨어짐
    • prediction model을 만들어서 예측하는 편이 정확도가 높아짐.
• (여기서부터 머신러닝 관련 수식들이 많이 나와서 정리하지 못했습니다ㅠㅠ)

카카오의 활동

• 광고 목적을 위해 카카오 내부 데이터와 조합할 수 없음
• 추상화 : estimation and aggregation
• de-identificatin and k-anonymity
• 법/guidance 등으로 인한 제약

연령 성별 추정

• 베이지안 추정 사용
• 클러스터링 / LDA (topic modeling). LDA가 좀 더 정확도가 높아서 topic modeling을 사용중
  • classification을 거의 미사용, 차츰차츰 LDA로 교체해도 될듯하다고 생각중
• 해싱 트릭
• gradient boosting tree (현재는 미사용)
• DNN / AE (현재는 미사용)

Conversion real matters

• eCPM = BA * pCTR * pCVR
  • 이제 conversion(실제 사용자 대상을 타겟으로 하기 위해)을 고려해서 광고를 보내줘야 하게됨

Features over Algorithms

• 어떤 모델을 쓸지를 정하는 것보다 어떤 데이터를 쓸 지를 찾아내고 정하는게 더 중요함.
  • retargeting의 성능이 좋은 이유 : 기존 데이터 재활용 등.

Bidding Amount

• 얼마의 광고비를 입력해야 광고가 노출될까?
  • BA가 높을수록 노출 확률 높음, 그러나 돈이 많이 듦.
  • BA를 자동으로 정할 수 있으면 광고주가 고민을 덜 해도 될것 같다.
• Budget smoothing
  • 하루에 광고로 소모하는 예산을 정하는 방식
  • 초반에 많이 쓰면 실제 유저가 들어오는 시간대 이전에 (새벽 등) budget이 전부 소모되기도 함.
    • 트래픽 별로 분산을 시켜주기도 함
• auto bidding
  • 적정 금액에 맞게 지속적으로 노출하는 방식

테스트 및 적용

• research, offline 테스트 후 online test
• 매출 위주로 테스트 진행
  • random bucket을 이용해 허점 발견하기
  • a/a test, a/b/.. test
  • 안정성 체크
• 그 후 적용

카카오 광고 플랫폼 MSA 적용 사례(api gateway와 인증구현에 대한 소개)

연사

• 황민호 (robin.hwan)

디지털 광고 시스템

• DSP , SSP (Demand Side Platform - AD investment, Supply Side Platform - publisher)
  • audience targeting

MSA

• API Gateway, 인증.
• NETFLIX ZUUL 사용
  • 스프링 프레임워크, 간단, netflix에서 실제 운용
• Netflix OSS
  • EUREKA, RIBBON, HYSTRIX, ZUUL
• 카카오 광고 DSP 구성
  • L7으로 서버들 연결

서비스 장애 대응

• Aggregation 문제로 인한 서비스 장애, RestTemplate Timeout 미설정 (Hystrix 미사용으로 인해)
  • Hystrix Circuit 오픈이 되면 장애가 생겼다고 인지 가능.
• Eureka 미도입, RIBBON의 로드밸런싱 사용.
  • Hystrix 뒤에 Ribbon을 서버들에 연결하여 서버 로드밸런싱하도록 수정
• 서버를 내리면 항상 서킷 오픈이됨
  • Ribbon에 연결된 여러 서버중 하나만 문제가 생겨도 격리가 되는 이상한 사례가 생김;;
  • Timeout Exception이 발생하면 바로 격리가 되서 확인해보니 Hystrix 타임아웃이 Ribbon 타임아웃 시간보다 길어야하는 것을 확인
    • 그러나 해결 안됨
  • ribbon 로드 밸런서는 유레카를 사용해서 서버 사용여부를 갱신하게됨. 사용하지 않을때는 프로퍼티 파일의 서버목록을 주기적으로 갱신
  • ribbon 헬스체크 (더미핑)의 디폴트가 항상 true를 리턴하도록 되어있었음;;
    • 서버가 내려갔을 때 정상적으로 제외되는 것을 확인

서버 버전업

• NETFLIX ZUUL2, Spring Cloud Gateway
  • 웹플럭스 기반, 스프링 5
• redis rate limit을 통해 요청수 제한
• Zuul에서는 filter를 통해 서비스 요청을 관리했지만, Zuul2는 비동기 작업을 위해 Netty Server 도입.
  • 핸들러도 Netty Client 도입

Spring Cloud Gateway Filter Factory

• 각종 제한을 필터를 통해 걸 수 있다.

MSA 구성

• 분산세션관리, 클라이언트 토큰 관리
• API Gateway를 통한 클라이언트 토큰 관리
  • api g/w에서 토큰 생성 및 검증을 하게됨.
• JWT(JSON WebToken)로 토큰을 발행함

카카오 광고 플랫폼

• Refresh Token, Access Token 사용
  • RefreshToken - 적은 정보를 갖고, 긴 만료시간을 가짐. AccessToken 발행용
  • AccessToken - 실제 사용자 정보를 갖고 인증권한을 가진 토큰. 짧은 만료시간을 가짐.
• API G/W에서 헤더에 넣어서 보냄.
• JWT - 만료시간이 기술되어 있어서 서버에서 로그아웃 하더라도 인증정보를 폐기하지 않음.
  • opaque token 고려중
  • 게이트웨이에서 JWT를 opaque 토큰으로 변경. gw에서는 auth token을 jwt로 변경해서 체크.
  • 로그아웃시에는 opaque 토큰을 만료처리 => jwt의 문제 해결.

Q&A

• 트랜잭션 어떻게 관리했나요?
  • 요청을 단일화, 대신 롤백을 넣지 않음. 알람시스템을 보강 - 문제가 있으면 개발자가 직접처리..
• 트래픽이 몰리는 부분은 따로 구현하지않음
  • 광고주 / 플랫폼사이라서.. 아직 트래픽이 몰리는 경험이 없었습니다.
• api g/w 액세스 부분 어떻게?
  • 중요한 부분은 server to server로 진행되도록 하고, white list로 관리
• Gateway를 왜쓰나요?
  • 보안 측면의 문제가 있어서 전부 gateway로 몰아 넣음, 권한 처리도 g/w로 몰은 이유.

모바일 게임 플랫폼과 인프라 구축 경험기(글로벌 적응 삽질기)

연사

• 이강인(kai.lee) 카카오게임즈

• 최양민(ringgo.choi) 카카오게임즈

동남아 지역에 신규 게임 소프트 런칭

게임 서비스 인프라를 어떻게 할까?

• AWS 리전 사용 (IDC)
• AWS VPC / VLAN
  • Configuration Manager를 위해 글로벌 서버 관리.
• 그러나 서비스 대상 지역의 네트워크 품질이 걱정.
  • 네트워크 품질 상시 관리하는 지표를 만들어야겠다고 결심.
  • ICMP 를 이용해 서비스 네트워크 품질 관리
• 동남아 서비스를 위해 싱가폴 AWS를 사용
  • 인프라를 직접 구성할지, AWS를 정말 사용할지에 대한 고민도 병행.
  • 비용(money) 시뮬레이션
• 9개월 이후부터는 IDC가 직접 나가는 것이 AWS 사용보다 저렴하다는 것을 확인함.
  • 그러나 소프트 런칭 예정. 게임 서비스의 라이프사이클이 짧아서 IDC를 구축해야할지에 대한 고민이 높아짐.
  • 매몰 비용이 많음. 따라서 초기에는 AWS, 추후에는 IDC 사용하도록 변경.

플랫폼은 외부 IDC에 나갈 수 없음.

• Akamai 부스트 사용 (가속 솔루션)

API G/W를 싱가폴에

• client -> api g/w 요청, https와 wss(web socket secure)로 통신.
• GSLB 사용
• 아카마이 부스트 솔루션의 원리
  • handshake를 줄인다(RTT 감소)
• api g/w를 싱가폴에 나가고, api g/w와 서버간에 통신을 wss로 하도록 수정.
  • 우리는 gRPC를 사용하면 되지 않을까?

서버팀의 모니터링 업무

• machine/jvm metrics -> cloudwatch
• api metrics -> hystrix
• server logs -> ELK

서비스 오픈

• svn deploy 문제 발생
  • seoul - singapore 레이턴시가 증가.
  • amazon s3 사용으로 해결.
• 마케팅 대비 auto-scaling
• DNS Policy 적용 실패?
  • 말레이시아에서 일본에 접속하는 케이스가 관찰됨.
    • 원인 : 구글 dns사용 경우 global dns의 위치를 기반으로 판단하게 됨.
    • 해결 : 클라이언트 ip를 이용해 위치를 파악하고 선택된 접속 주소를 사용하도록 수정.
  • 싱가폴 edge로 안가고 서울로 가는 문제
    • GSLB GeoIP DB 노후화가 문제, GeoIP db 수정.
• 국가별 법령 대응
  • 국가코드를 사용 (USIM, OS 등등)
  • Country 코드가 잘못 전달되는 경우 (통신사가 보내짐)
    • 블루스택 에러
• Timezone에대한 문제
  • 결제로그가 안보이는 오류
    • api time format을 epoche time millisecond로 통일.
  • 이벤트 푸시 (국가별 문제)
    • 유저들의 timezone을 저장하게 수정
• global network 불안정
  • api g/w <-> relay service 간의 네트워크 불안 (글로벌 망)
    • 중요 api의 경우 kafka, kinesis를 통해 이벤트 저장 관리
  • edge를 이동 (모두 싱가폴로)
• edge존의 철수
  • GSLB이용해서 자동으로 뺄 수 있음.
  • 스토리지의 경우 kinesis를 서울로 이동하고 나머지를 순차적으로 빼냄
  • 이미 몇번 뺌

스프링5 웹플럭스와 테스트 전략

연사

• 이일민(toby) / Epri
• 스프링 웹플럭스, 플럭스와 테스트, 리액티브 API 호출 테스트, 웹플럭스 서비스 테스트, 함수형 엔드포인트의 테스트

스프링 웹 플럭스

• 스프링 5.0에 새로 등장한 리액티브 스택.
• 플럭스 = 리액티브

스프링 웹플럭스 vs MVC

• reactor라이브러리가 flux, mvc 양쪽에 존재함.
• jpa, jdbc가 mvc에만 존재함.
• servlet이 양쪽에 따로 존재함.

코드로 보기

• 스프링 웹플럭스 / 스프링 MVC는 같은 코드로도 동작이 동일함.
  • Flux 객체로 리턴하도라도, stream으로 리턴하더라도 둘 간의 코드 차이는 없음.
• 다만, 웹플럭스의 @Controller에는 MVC에서 지원하지 않는 기능이 있음.

스프링 웹플럭스 도입 이유

• 제일 중요한 내용은 본격적인 함수형 프로그래밍 모델 사용 가능

스프링 웹플럭스를 사용하지 않는게 좋은 이유

• 웹플럭스가 왜 필요한지 분명하게 모름
  • 비동기/논블록킹 방식 도입 X
  • 리액티브라이브러리 (Reactor, RxJava) 미사용
• 블록킹이 서버, 코드, 라이브러리에 존재
  • 블로킹 IO, 블로킹 서블릿 필터 존재
  • JPA, JDBC 그대로 사용
  • ADBA(O), AoJ(?), R2DBC(?) <- 사용 시 DB를 논블로킹으로 사용 가능.
    • Asynchronous DB Access , Asynchronous on JDBC, Reactive to DB Connector
• 스프링 MVC로 개발했더니 아무문제없음

스프링 웹 플럭스

• 서버의 자원을 효율화하자.
  • RestTemplate (동기 / 블로킹 API 호출)
  • I/O동안 블록킹
• 비동기 / 논블로킹 API 호출
  • AsyncRestTemplate(Spring4)
  • Async/Await (Java8+)
  • WebClient(Spring5)
• 비동기/논블로킹은
  • 확장성이 뛰어나고 높은 처리율과 낮은 레이턴시
  • 버그가 생기면 감당불가능

테스트

• 테스트는 항상 동기방식
• 비동기/논블로킹의 특성에 주의

• 블록킹/동기화가 필요.

• StepVerifier로 비동기 논블로킹으로 동작하는 코드를 테스트할 수 있음.
  • 데이터 스트림 검증, 예외 완료도 검증, 가상시간을 이용해 오랜 시간의 이벤트 테스트 등이 가능

원격 리액티브 API 호출 테스트

• WebClient 사용
  • 비동기 /논블록킹. Back Pressure,
• MockWebSerer를 이용한 테스트

함수형 엔드포인트

• 스프링 5.x 에 새로 도입될 spring container를 사용하지 않는 웹 요청 처리방식
• RouterFunction을 이용해 함수 레퍼런스를 찾고 그 결과를 Response로 가지게 된다.
  • 리액티브 핸들러를 활용해야함.