스토리 홈

인터뷰

피드

뉴스

조회수 3144

모니터링 기본 상식 - CPU Steal Time

클라우드 서비스를 사용하시는 많은 분들이 CPU Steal Time에 대해 문의합니다. CPU Steal은 클라우드 서비스와 물리 서버의 환경차이에서 발생하는 대표적인 지표이기도 합니다. CPU Steal Time이 높아지면 CPU 부하율이 높아지기 때문에 웹 서비스에 장애를 초래하기도 합니다. 가상화를 위해 자원을 분배하는 과정에서 cpu의 자원을 빼기는 것이기 때문에 클라우드 사용자 입장에서는 억울한 감이 있는 지표이기도 합니다. 하지만 클라우드 서비스가 공유 자원을 효율적으로 사용하는 것이기에 어쩔 수 없는 부분이기도 합니다. 그럼 이 CPU Steal Time 또는 CPU Stolen Time이라고 불리는 지표에 대해 알아보도록 하겠습니다.  CPU Steal Time이 무언가요?CPU Steal time은 은 하이퍼 바이저가 다른 가상 프로세서를 서비스하는 동안 가상 CPU가 실제 CPU를 기다리는 시간을 백분율로 표시한 값입니다.가상 환경에서 동작하는 가상 시스템 (VM)은 단일 호스트에있는 다른 인스턴스와 리소스를 공유합니다. 공유하는 리소스 중 하나가 CPU주기입니다. VM이 실제 서버에있는 동일한 크기의 4 개의 VM 중 하나 인 경우 해당 CPU 사용률은 모든 CPU주기의 25 %로 제한되지 않습니다. CPU 사용 비율보다 많은 비율을 사용할 수 있습니다.CPU Steal Time은 어떻게 확인하는가?Linux top 명령을 실행하면 주요 성능 메트릭의 실시간보기를 볼 수 있습니다. 그 중 하나는 CPU를위한 것입니다.이미 경험 한 두 가지 통계는 % id (percent idle)와 % wa (percent I/O wait)입니다. % id가 낮 으면 CPU가 열심히 작동하고 있는 것이며 % id가 높으면 남은 용량이 많지 않은 것입니다. % wa가 높으면 CPU는 실행할 준비가되었지만 I / O 액세스가 완료 될 때까지 기다리고 있습니다 (디스크에 저장된 데이터베이스 테이블에서 행을 가져 오는 것과 같습니다).% st 또는 % steal time은 표시된 마지막 CPU 메트릭입니다.CPU steal time이 높으면 어떤 상황이 발생하는가.백그라운드에서 장시간 걸리는 작업의 경우, 다른 VM들과 CPU 주기를 공유하는 과정에서 조금 더 느리게 작업이 마무리 될 수 있습니다. CPU steal time은 이런 경우 작업을 중지시키는 요소로 작용하지 않습니다. 가끔은 리소스를 나누는 과정에서 작업이 더 빠르게 끝나기도 합니다. 하지만 웹앱의 경우 실시간 처리가 필요한 경우들이 있습니다. 많은 웹 응답이 이뤄져야 하는 상황에서 cpu steal time이 높아지고, 그로인해 성능이 4배이상 감소한다면 중요한 리케스트가 처리되지 못하면서 서비스에 장애가 발생할 수도 있습니다. CPU steal time이 높은 원인은?cpu steal time이 높은 원인은 둘 중 하나입니다.  더 많은 CPU 리소스를 가지고 있는 VM을 필요로 합니다. (여러분의 문제입니다.)물리버서가 과대 판매되어 가상화 장비가 공격적으로 경쟁하는 상황입니다. (여러분의 문제가 아닙니다. 아마존 나빠요.)아쉽게도 cpu 매트릭만으로 위 두가지 상황을 판별하는 것은 쉽지 않습니다. 하지만 같은 역할을 하는 복수의 호스트를 여러개 가지고 있다면 다음과 같이 분별해 볼 수 있습니다.  1. 리소스 부족의 경우위 그림처럼 모든 VM에서 %st(cpu steal time)이 높다면 시스템이 더 많은 cpu를 사용해야 한다는 것을 의미합니다. 더 높은 사양의 VM을 선택하셔야 합니다. 2. 클라우드 사업자의 과다 판매의 경우위 그림처럼 일부의 VM에서만 %st(cpu steal time)이 높다면 같은 물리 호스트에 있는 다른 VM들이 서버의 자원을 과다하게 사용하고 있을 확률이 높습니다. 물리적으로 다른 호스트로 이동하여 해결 할 수 있습니다.대처 방법을 알아보자.일반적인 경우 steal time이 20분동안 10%를 넘기는 상태에서 유지되고 있다며, VM은 정량 보다 느리게 동작하고 있을 것입니다.인스턴스를 중지하고 다른 물리 서버로 이동하세요. 그래도 steal time이 높다면 cpu 리소스를 업그레이드하세요. 그리도 steal time이 높다면 클라우드 서비스 제공자에게 문의하세요.클라우드 서비스가 과설계된것은 아닌지 알아보세요. 와탭을 사용해서 cpu steal 매트릭을 추적하세요. 최근 와탭에 들어오는 가장 많은 문의 중 하나가 cpu steal입니다. cpu steal로 인해 cpu 부하율이 80%이상으로 올라가는 경우 클라우드 서비스에 익숙하지 않은 분들은 많이 당항하게 됩니다. 이런 경우 너무 곤란해 하지 마시고 일회성 이슈인지 체크하시고 반복된다면 cpu 리소스를 업그레이드 하거나 서비스를 다른 물리서버로 이동하시기 바랍니다. 제가 가지고 있는 sample중에 cpu steal이 나온 케이스가 없지만 whatap.io는 cpu steal 값을 5초마다 저장하여 제공합니다.  관련 urlhttp://hakurei.tistory.com/67[Linux] 가상환경에서의 CPU Steal Time 개념물리 장비에다가 여러대의 가상머신을 두는 가상환경을 구축하는 경우가 많다. 가상머신이 많아지는 경우, 동일한 물리 장비에서 제공되는 환경이다보니, 특정 가상머신이 CPU를 많이 차지하게 되면, 다른 머신들도 따라서 느려지게 되는데, 이 현상을 CPU Steal이라고 한다. CPU를 많이 차지하고 있는 머신의 CPU Steal Time은 낮게 측정이되고, 같은 물리 장비에 구성된 다른 가상 머신의 경우 CPU Steal Time이 높게 측정이..hakurei.tistory.com http://www.stackdriver.com/understanding-cpu-steal-experiment/» Understanding CPU Steal – An Experimentwww.stackdriver.com http://blog.scoutapp.com/articles/2013/07/25/understanding-cpu-steal-time-when-should-you-be-worriedUnderstanding CPU Steal Time - when should you be worried?blog.scoutapp.com #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1086

자바스크립트 기초 문법 정리 Part 3

함수와 이벤트에 대한 내용이 이렇게 간략할지 몰라 따로 파트를 나누어 포스팅을 진행하였는데 불필요한 나눔이 되었네요. 하지만 곧 더 간략하고 직관적으로 볼 수 있도록 기초 문법 총 정리 포스팅을 하도록 하겠습니다. 혹여 참고 문서로 본 포스팅을 보시는 분들은 곧 올라오는 총정리 포스팅을 참고하시면 좋을 것 같습니다.함수function 함수명() {    실행문;    return 데이터;}참조 변수 = function() {    실행문;}function 함수명() {(매개 변수1, 매개 변수2)    실행문;}   이벤트<button id="btn" onclikc="alert('event!')">버튼></button>이벤트 종류onmouseover - 마우스가 지정한 요소에 올라갔을 때 발생.onmouseout - 마우스가 지정한 요소에 벗어났을 때 발생.onmousemove - 마우스가 지정한 요소를 클릭했을 때 발생.ondvlclick - 마우스가 지정한 요소를 연속 두 번 클릭했을 때 발생.onkeypress - 지정한 요소에서 키보드가 눌렸을 때 발생.onkeydown - 지정한 요소에서 키보드를 눌렀을 때 발생.onkeyup - 지정한 요소에서 키보드를 눌렀다 떼었을 때 발생.onfocus - 지정한 요소에 포커스가 갔을 때 발생.onblur - 지정한 요소에 포커스가 다른 요소로 이동되어 잃었을 때 발생.onchange - 지정한 요소의 하위 요소를 모두 로딩했을 때 발생.onunload - 문서를 닫거나 다른 문서로 이동했을 때 발생.onsubmit - 폼 요소에 전송 버튼을 눌렀을 때 발생.onreset - 폼 요소에 취소 버튼을 눌렀을 때 발생.onresize - 지정된 요소의 크기가 변경되었을 때 발생.onerror - 문서 객체가 로드되는 동안 문제가 발생되었을 때 발생.참고문헌:Do it! 자바스크립트+제이쿼리 입문 - 정인용JavaScript 튜토리얼 문서 (http://www.w3schools.com/js/default.asp)티스토리 블로그와 동시에 포스팅을 진행하고 있습니다.http://madeitwantit.tistory.com#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유
조회수 978

HyperCut으로 인물사진 필터를 만들었습니다

얼마전 하이퍼커넥트의 아이디어 제안 채널에서 나온 이야기입니다.mel 은 사업그룹의 터키지역 담당 팀에 있는 친구인데, 꾸준히 좋은 제안과 아이디어를 주는 훌륭한 동료입니다. 이번에는 최근 여러 스마트폰이나 사진 앱들에서 나타나기 시작한 인물사진 모드 를 아자르에서도 지원하는게 좋겠다는 제안이었습니다.스마트폰이 자체 기능으로 인물사진 필터를 제공하는 경우는 보통 듀얼 카메라를 사용해 인물 외의 배경을 흐릿하게 만들어 심도를 표현합니다. 하지만 모두가 듀얼 카메라를 탑재한 스마트폰을 쓰는 것은 아니기 때문에, 이런 인물사진 모드를 소프트웨어적으로 구현하는 앱들도 존재합니다. mel 이 보여준 링크의 인스타그램도 그렇게 구현했네요.인물사진 모드를 소프트웨어적으로 구현하려면, 영상에서 얼굴을 포함한 사람을 배경으로부터 정확히 분리해 내는 기술이 필요합니다. 그리고 사진을 찍을 때에 실시간으로 프리뷰를 보아야 할테니까 이것을 실시간으로 처리할 수 있을 정도의 성능도 필요하구요.하이퍼커넥트에서는 머신러닝, 특히 영상과 이미지를 다루는 분야에 대해 지속적으로 투자와 연구를 해 왔습니다. 영상에서 인물을 분리해내는 문제는 크게 Image Segmentation 의 범주에 속합니다. 좀 더 직접적으로 Portrait segmentation 이라고 부를 수도 있습니다. 이를 잘 하기 위해서 하이퍼커넥트에서는 자체적인 학습 데이터를 만드는 것부터 시작하여 기술 개발을 지속적으로 추진해 왔고, 그 결과 Machine Learning 팀에서 이미 실시간으로 얼굴과 배경을 분리해내는 - HyperCut - 이라는 기술을 확보한 상태입니다. 아직 실제 서비스에 탑재되진 않았지만 이미 하이퍼커넥트의 주요 서비스인 아자르의 개발 버전에서는 HyperCut을 응용한 여러가지 이펙트를 사용할 수가 있습니다. 그리고, 그 중에 인물사진 모드 필터도 이미 있습니다.mel 의 제안이 있던 날 오후 아이디어 제안 채널에 이런 답이 달렸습니다.모델이 되어 주신 분은 하이퍼커넥트의 CTO 인 ken 이네요. 아자르 개발 버전에서 HyperCut 을 응용한 인물사진모드 필터를 사용하고 찍은 사진입니다. 아자르의 저장하기 기능을 사용했더니 UI 없이 오른쪽 아래에 아자르 로고만 남게 되었네요. 아직 실서비스에는 포함되지 않았지만, 최적화와 튜닝 과정을 거쳐 조만간 많은 사용자들이 HyperCut 을 사용한 이펙트를 쓸 수 있게 될 예정입니다.#하이퍼커넥트 #개발 #개발자 #아이디어 #아이디에이션 #구체화 #협업 #팀워크 #팀플레이
조회수 2294

AWS S3를 이용하여 Vue 배포하기

Vue를 처음 만났을 때, 이것으로 무엇을 할 수 있을지 궁금했다. 하지만 Vue로 데모 앱과 개발 가이드를 따라하면서 의문은 점점 풀렸다. 알다시피 Vue는 front-end 로 활용이 된다. 빌드가 없어도 되고, 빌드를 해서 배포할 수도 있다. Vue는 일반 CDN을 이용하여 페이지를 만드는 방법과 여러 프레임워크를 활용하여 배포하는 방법 외에 다양한 방법이 존재하는데, 무슨 방법을 쓰든 결과물은 html과 js, css 같은 static 파일로만 이루어져 있다.처음에는 일반적인 방법으로 테스트하면서 다양한 디렉티브와 손쉽게 DOM 처리를 하는 방법을 익혔다. 나중엔 프로젝트에 참여하면서 webpack 으로 빌드해 배포하도록 프로젝트를 구성했다. webpack을 이용한 배포방법은 여기 를 참고하면 된다. 참고로 webpack은 nodeJS로 실행되기 때문에 기본적인 환경을 세팅해야 한다.webpack build.js 일부위처럼 직접 스크립트를 만들어서 사용해도 되지만 Vue에서 제공하는 템플릿으로 프로젝트를 생성할 수도 있다. 단 Vue-CLI가 미리 설치되어 있어야 한다.터미널에서 vue init webpack 프로젝트명만 치면 세팅된 템플릿으로 폴더 및 스크립트들이 구성된다. 아래와 같이 프로젝트의 기본 속성들을 입력하자.프로젝트를 만들면 기본적인 파일들로 이루어진 폴더가 생성된다. 현재는 관련 라이브러리들이 없는 상태이므로 npm install 을 통해 설치한다. 설치 후 nom run dev 로 개발모드를 실행하면 브라우저로 화면을 볼 수 있다. 만약 설치하고 빌드 설정을 수정하지 않았다면 기본 8080 포트로 가동된다. 브라우저를 실행해 http://localhost:8080 으로 접속하면 아래와 같은 화면이 나온다.여기까지 하면 webpack 으로 배포할 수 있는 상태가 되었다. 이제 AWS로 가서 회원가입을 하고 S3를 생성한다. 생성 방법은 여기를 참고하면 된다. 버킷까지 생성되었다면 이제 빌드 후 업로드하자.위와 같이 nom run build 를 하면 빌드가 시작된다.빌드가 완료되면 해당 프로젝트 폴더에 dist 폴더가 생성된다. dist 폴더에는 index.html 과 js, css 와 같은 리소스들이 들어간다. 이제 S3로 가서 올리려는 버킷을 클릭하자.업로드 버튼을 클릭하고, dist 폴더에 있는 index.html 과 static 폴더를 업로드한다. 폴더가 업로드되면 아래와 같이 파일과 폴더들이 보인다.업로드가 완료되었다고 지금 바로 웹사이트처럼 접근할 수는 없다. 정적 웹사이트 호스팅 설정을 활성화해야 비로소 가능하다. 속성 탭을 클릭해 정적 웹사이트 호스팅을 활성화 상태로 만든다.위와 같이 활성화하고 인덱스 문서에만 index.html 을 입력한 후 저장 버튼을 클릭한다. 현재 보이는 엔드포인트 주소가 외부에서 접근할 수 있는 사이트 도메인이다. 그 후 엔드포인트 주소로 접속하면 아래와 같이 오류 페이지를 볼 수 있다.이게 무슨 오류란 말인가… index.html 파일도 있는데 403 오류라니..자세한 http 응답코드는 여기를 참고하면 된다. 위의 오류는 권한이 없어서 파일에 액세스할 수 없다는 페이지다. S3는 기본적으로 모두에게 공개하진 않는다. 그래서 특정 파일이나 특정 버킷만 공개형으로 변경해줘야 한다.이 문제를 해결하려면 권한 탭으로 이동해 버킷 정책을 설정해야 한다. 아래와 같이 설정해주면 누구에게나 공개되어 접근할 수 있다.위 내용을 아래와 같이 버킷 정책으로 설정한다.설정을 저장한 후 다시 엔드포인트로 접속하면 아래와 같이 로컬에서 보였던 페이지가 보인다.이렇게 보이면 성공!다음엔 Vue가 어떤식으로 동작을 하는지 알아보도록 하겠다.마치며Vue는 간결하면서도 강력한 기능을 가지고 있는 front-end 프레임워크다. 개념과 디렉티브, 이벤트 핸들링, 보안 등 궁금한 게 많았지만 신통방통한 놈인 건 확실하다. 아직 큰 프로젝트에 사용하는 건 힘들 수도 있으나 아래와 같이 장점이 많아 서버단과 클라이언트단 분리 개발, 외부 라이브러리와 사용하면 훌륭한 프레임워크가 될 거라는 생각이 든다.재사용 가능한 기능별 컴포넌트 개발훌륭한 라우터 탑재서버와 통신 가능한 ajax 모듈이 다양함 ( jQuery Ajax, Axios )다양한 호환 라이브러리를 활용하면 분명 훌륭한 프레임워크가 될 것!편집자 주) 함께 보면 좋아요!Vue, 어디까지 설치해봤니?PHP Codeigniter 환경에서 VUE 사용해보기JQuery 프로젝트에 VUE를 점진적으로 도입하기Vue와 Vuex, 컴포넌트간 통신과 상태 관리글장현준 팀장 | R&D 개발3팀[email protected]브랜디, 오직 예쁜 옷만
조회수 2522

타다 시스템 아키텍처 - VCNC Engineering Blog

2018년에는 VCNC에 큰 변화가 있었습니다. 오랫동안 비트윈 기반의 서비스들을 개발하고 운영했지만 2018년 10월에 기사 포함 렌터카 서비스를 포함한 종합 모빌리티 플랫폼인 타다를 기획하고 출시하였습니다. 변화가 많은 모빌리티 시장에서 신규 서비스를 성공적으로 출시하기 위해 많은 고민을 하였습니다. 이번 글에서는 타다의 시스템 구성과 이를 위해 사용한 여러 기술을 소개하면서, 타다 개발팀의 기술적 결정을 공유해보고자 합니다.타다에서 사용하는 기술들의 로고. 왼쪽부터 Kotlin, Spring Boot, Kubernetes, Terraform, gRPC, Redis.기존과 다른 선택비트윈의 경우 Netty를 이용해 인하우스 네트워크 라이브러리를 만들기도 하였고, 메인 데이터베이스로 NoSQL인 HBase를 사용하는 등 남들이 통상적으로 사용하지 않는 기술 스택을 선택한 경우가 많았습니다. 그 배경에는 나름대로 이유가 있었지만, 서비스 초기에는 안정성에 어려움을 겪기도 하였고 서버 배포 과정이 느리고 복잡하여 쉬운 길은 아니었습니다. 여러 문제를 해결하기 위해 Haeinsa 등 라이브러리와 소프트웨어를 직접 만들기도 하였습니다.타다는 이슈가 많은 모빌리티 시장을 타겟으로 하고 있기 때문에 Time to Market이 특히 중요했습니다. 개발하는 기간 동안 시장 상황에 따라 기능의 우선순위가 변하기도 하였습니다. 이에 따라 서비스를 빨리 출시하고 외부의 변화에 유연하게 대처할 수 있도록, 완성도 있게 만들어져 있는 프레임워크나 라이브러리를 선택하였고, AWS에서 이미 잘 관리되고 있는 서비스를 적극적으로 활용하였습니다.사용 중인 기술들Kotlin: Java는 불편한 점이 많지만, JVM에 대한 경험을 무시할 수는 없어 비교적 새로운 JVM 기반 언어인 Kotlin을 사용하기로 하였습니다. 다른 여러 JVM 기반의 대안 언어들이 있지만, Spring Boot에 쉽게 적용할 수 있고 커뮤니티에서 적극적으로 권장하고 있는 점 등 여러 이유로 Kotlin을 선택하게 되었습니다.Spring Boot: 널리 쓰는 웹 프레임워크이며 이미 지원하는 기능 또한 많기 때문에 보일러 플레이트 코드 작성을 줄이고 서비스 개발에 집중할 수 있습니다. SQS 메시지 처리, HTTP 요청 및 응답으로 Protocol Buffers 메시지 사용 등 프레임워크에서 제공하는 기능을 많이 활용하고 있습니다.Kubernetes: 컨테이너 오케스트레이션 플랫폼으로 배포 자동화와 스케일링 등 여러 가지 운영적인 편의성을 제공합니다. 처음에는 kops를 이용해 클러스터를 직접 띄웠지만, 지금은 EKS를 이용하고 있으며 직접 object를 만들기보다 helm을 이용하고 있습니다.gRPC: 실시간성이 중요한 차량 위치나 운행 상태 변화 등은 Streaming을 이용하여 전달하고 있습니다. 직접 개발할 수도 있었지만, 서비스 개발에 집중하고 앞으로의 관리 오버헤드를 줄이기 위해 gRPC를 이용하기로 하였습니다.Redis: 서버 간 메시징을 위해 Redis의 Pub/Sub 기능을 사용하고 있습니다. 메시지 브로커 기능을 제공하는 RabbitMQ, ActiveMQ, Kafka 등 여러 옵션이 있었지만, 개발을 시작하던 당시에는 Redis만이 ElastiCache를 이용하여 쉽게 띄우고 관리할 수 있어 Redis를 선택하게 되었습니다.Protocol Buffers: gRPC 뿐만 아니라 HTTP/2로 주고받는 메시지를 정의할 때도 이용하고 있습니다. 덕분에 따로 문서화 하지 않고 proto파일을 공유하여 더욱 명확하고 편리하게 API 명세를 공유할 수 있었습니다.Terraform: HCL을 이용해 인프라스트럭처 프로비저닝 및 관리를 편하게 해주는 도구입니다. AWS 서비스의 생성 및 관리를 콘솔에서 직접 하지 않고 Terraform을 이용하고 있습니다.사용 중인 AWS 서비스들AWS는 개발팀이 오랜 기간 사용하여 가장 익숙한 클라우드 플랫폼이기 때문에 큰 고민 없이 선택할 수 있었습니다.EKS: Kubernetes 클러스터의 마스터 노드들을 쉽게 띄우고 관리해주는 서비스입니다. 서울 리전에 EKS가 출시된 후에는 관리 오버헤드를 줄이기 위해 EKS로 옮겼습니다.ECR: 타다 서버를 배포할 때는 Docker Gradle Plugin을 통해 docker 이미지를 만들고 ECR에 푸시합니다. 그 후 helm 명령을 통해 Kubernetes에 배포합니다.SQS: 배차 요청을 처리하기 위해 SQS를 이용합니다. 배차 요청을 구현하는 방법에는 다양한 옵션이 있었지만 AWS 서비스를 최대한 활용하여 빠르게 개발할 수 있었습니다.RDS: 타다의 대부분 데이터는 Aurora에 저장하고 있습니다. RDS를 이용하면 DB의 배포와 관리가 쉬우며, Aurora는 MySQL과 호환될 뿐만 아니라 같은 비용이면 성능이 더 좋습니다.Kinesis: 실시간 차량 위치 정보 및 로그를 수집하기 위해 사용하고 있습니다. 다른 오픈소스 소프트웨어를 직접 이용하기보다는 AWS에서 제공하는 서비스를 최대한 이용하고 있습니다.Firehose: 비트윈에서는 KCL를 활용해 Acheron이라는 프로그램을 직접 만들어 로그들을 S3에 저장하였지만, 이제는 서울 리전에서 Firehose를 사용할 수 있으므로 큰 고민 없이 사용하기로 하였습니다.시스템 구성타다에서는 필요에 따라 서비스를 여러 종류로 분리하여 운영하고 있습니다. 일반적인 모바일 앱 API와 실시간 차량의 위치 정보를 바탕으로 사용자의 요청에 대해 적합한 차량을 배차하는 기능이 필요했습니다. 핵심적인 역할을 하는 일부 서비스와 시스템 구성에 대해 간단하게 소개합니다.라이더 앱: 아이폰은 Swift, 안드로이드는 Kotlin으로 작성하였으며 여러 오픈소스 라이브러리를 적극적으로 활용하였습니다. 서비스 특성상 RIBs라는 아키텍처를 사용하여 개발하였습니다.드라이버 앱: 아이폰과 안드로이드를 모두 지원하려면 기술적, UX적으로 고려해야 할 점들이 많고 불특정 다수의 유저를 대상으로 하는 앱도 아니었기 때문에 안드로이드 버전으로만 개발하게 되었습니다.서버: 모바일 앱의 요청을 대부분 처리하며 Spring Boot로 작성된 HTTP/2 API 서버입니다. Protocol Buffers로 정의된 메시지를 JSON 형태로 주고받습니다.gRPC 서버: 서버에서 발생하는 이벤트를 실시간으로 전달하기 위한 서버입니다. Redis Pub/Sub을 통해 받은 이벤트 메시지들을 클라이언트들에게 전달합니다.Dispatcher: 배차 요청을 처리하는 서버입니다. 주변 차들의 ETA 계산을 위해 외부 API를 이용하는데, Reactor를 이용해 비동기적, 동시적으로 요청하여 쓰레드 점유 없이 효율적으로 처리되도록 구현하였습니다.Tracker: 차량 위치 정보 수집 서버입니다. KCL를 이용해 위치 정보 레코드를 읽어 들여 TrackerDB에 기록합니다.Redis: 서비스 초기에는 차량의 최신 위치 등을 저장하기도 했지만, 지금은 주로 서버 간 메시징을 위해 Pub/Sub 기능을 이용하고 있습니다.DB: 운행 기록, 사용자 데이터 등 대부분 데이터를 기록합니다. 비트윈에서는 HBase를 이용했지만 타다의 경우 아직 절대적인 트래픽이 많지 않기 때문에 트랜잭션 등 다양한 편의 기능을 제공하는 RDB를 이용하고 있습니다.TrackerDB: 차량 운행 정보 및 차량의 최신 위치 등을 저장합니다. Aurora를 이용하며 대부분의 요청이 차량 위치 정보 업데이트이므로 안정성을 위해 별도의 인스턴스를 띄워 사용하고 있습니다.Kinesis Log Stream: 타다의 여러 서비스에서 로깅을 위해 이용합니다. Firehose를 통해 S3에 기록됩니다.Kinesis Tracker Stream: 드라이버의 실시간 위치 정보는 Kinesis를 통해 Tracker로 전달됩니다.서비스 플로우차량 위치 업데이트차량 위치 업데이트는 요금 계산, 차량 위치 제공 등 서비스에서 가장 많이 일어나는 요청입니다. 드라이버 앱에서 안드로이드 Foreground 서비스를 이용해 GPS 정보를 수집하고 일정 주기마다 서버로 현재 위치를 전송합니다. 이렇게 전송받은 GPS 위치 정보는 데이터 크기를 최소화하기 위해 Protocol Buffers로 직렬화되어 Kinesis 레코드로 만들어지게 됩니다. Tracker에서는 전달된 Kinesis 레코드를 읽어 간단한 처리를 한 후에 TrackerDB에 삽입합니다.서비스 초기에는 차량의 마지막 위치에 대한 정보만 Redis에 적었습니다. 그러나 차량의 이동 경로를 효율적으로 조회해야 할 일이 생겼는데, 당시 차량 이동 경로는 로그로만 저장되고 있었습니다. S3 Select나 Athena를 이용해 조회하는 방안도 고려했지만, 일단은 Aurora에 저장하기로 하였습니다. 당분간은 Aurora로도 충분했고 RDB를 쓰는 것이 가장 쉽고 편한 방법이었기 때문입니다.차량 배차차량 배차는 서비스의 가장 기본적인 기능으로 배차 요청에 가장 적절한 주변 차량을 할당하는 플로우입니다. 라이더 앱에서 유저가 배차를 요청하면 서버가 배차 요청 정보를 DB에 기록하고 배차 요청 메시지를 SQS 대기열에 집어넣습니다. Dispatcher가 배차를 처리하는 로직을 수행하여 차량이 매칭되면 드라이버 앱으로 이벤트가 전달됩니다.드라이버가 배차를 수락하면 서버로 수락 요청이 전송되고 서버에서는 DB의 배차 요청 상태를 수락 상태로 변경합니다. 배차 요청이 수락되었다는 이벤트는 결과적으로 gRPC 서버를 통해 해당 이벤트를 구독하고 있던 유저에게 전달됩니다.Dispatcher에서 배차를 처리하는 로직은 여러 옵션이 있었지만 가장 간단하고 효율적으로 개발하기 위해 SQS의 기능을 최대한 활용하였습니다. Dispatcher 수를 늘리는 것만으로도 처리량 확장이 가능하며 Dispatcher가 갑자기 종료되어도 한 대라도 살아있다면 결국에는 잘 처리가 됩니다. Dispatcher가 배차 요청을 받으면 다음과 같은 로직을 수행합니다. 종료 조건을 만족하지 않았다면 일정 시간 후 동일한 로직을 다시 반복합니다.배차가 가능한 상태라면 배차 로직을 수행합니다. 이동 경로와 교통정보를 고려하여 적합한 주변 차량을 찾습니다.만약 적합한 차량이 있다면 배차 요청을 해당 드라이버에게 할당되었다는 정보를 DB에 적고 배차 할당 이벤트를 전파합니다. 드라이버의 수락을 기다리기 위해 일정 시간 후 로직을 재시도합니다.만약 적합한 차량이 없다면 일정 시간 후에 로직을 재시도합니다.배차 요청이 드라이버의 수락을 기다려야 하거나 타임아웃이 남아있는 상태라면 적절한 시간 후 재시도합니다.배차 요청이 수락되어 완료된 상태거나 취소되었거나 타임아웃이 지난 상태라면 SQS에서 메시지를 삭제합니다.못다 한 이야기타다를 런칭하는 날, 기사 간담회에서 쏘카의 VCNC 인수 이후 짧은 기간 동안 타다를 만들 수 있었을 리 없으니, 실제 개발 기간은 어느 정도냐는 질문이 있었습니다. 짧은 기간 내 서비스를 성공적으로 런칭할 수 있었던 것은 상황에 맞는 올바른 기술적 선택들뿐만 아니라 훌륭한 팀원들이 있었기에 가능했던 일이었습니다. 타다는 개선해야 할 부분도 많고 앞으로 새로운 기술적 도전들이 많이 있을 것입니다.네 그렇습니다. 결론은 기술적 난제들을 고민하면서 좋은 팀과 서비스를 함께 만들고 키워나갈 좋은 분들을 기다리고 있다는 것입니다.
조회수 2249

리디북스 서버 스택 소개

2대의 서버로 시작한 리디북스는 각 기능의 요구사항에 최적인 솔루션들을 채용하고, 고가용성(High Availability)을 지향하면서 매우 복잡하고 다양한 구성으로 변모해왔습니다. 이 글에서는 리디북스가 어떤 스택에서 서비스를 제공하고 있는지 간략히 소개하려고 합니다. 각 스택의 선택 이유나 문제에 부딪히며 배운 노하우 등은 차차 포스팅하겠습니다.대략적인 구조리디북스 백엔드 구조도로드 밸런싱로드 밸런싱은 소프트웨어 로드 밸런서인 HAProxy를 이용하고 있습니다. HAProxy는 L4, L7 스위치의 기능 및 로드 밸런싱을 제공하고 구성 역시 매우 간편합니다. 리디북스는 고가용성을 위해 Active - StandBy 서버 한 쌍이 가상 IP를 공유하고, keepalived를 통해 서로의 상태를 확인하며 자동 failover 됩니다. 각 서버군이 사용하는 네트워크 트래픽에 따라 스위치와 연결되어 있는 네트워크의 속도가 다른데, 이를 효율적으로 사용하기 위해 HAProxy 서버 쌍을 2개 구성하여 DNS를 통해 HAProxy로 들어오는 트래픽도 분산하는 방식으로 네트워크 효율화를 이루었습니다.웹 서버Ubuntu 14.04 LTS 기반에 웹서버로는 Apache, Nginx를 사용하고 있습니다. 서점 용 웹 서버, 정적 파일 서버(CSS, JS 등), 통계용 서버, 책 파일에 DRM을 씌워 전송하는 다운로드 서버 등 여러 개의 웹 서버 그룹을 나누어 관리하는데, 각 서버가 하는 역할이나 테스트를 통해 확인한 병목 지점을 고려해 웹서버를 채택합니다.API 서버리디북스는 서점이나 앱에서 이용하는 수많은 API가 존재하는데 종류에 따라서는 초당 수만 개의 호출이 발생하는 경우도 있습니다. 이러한 트래픽을 감당하기 위해 비동기 처리가 필요한 경우 Node.js를 주로 이용하여 구현하고 있습니다. Node.js 프로세스는 PM2를 통해 클러스터 모드로 실행되어 요청을 처리합니다. 클러스터 모드는 프로세스에 대한 로드 밸런싱을 지원하며 프로세스를 순차적으로 재시작할 수 있어 무정지로 서비스를 재시작할 수 있습니다데이터베이스서비스 초기에 MySQL을 사용했고 현재는 MariaDB로 변경한 상태입니다. 한때 DB가 SPOF(Single Point Of Failure)였던 시기를 겪으면서 read/write의 분산을 위해 많은 노력을 들였습니다. 리디북스에서 실행하는 대부분의 데이터 연산은 읽기 동작이므로 애플리케이션 레벨에서 읽기/쓰기 접근을 구분하여 1차적으로 부하를 분산하고, HAProxy를 통해 여러 대의 slave로 분배해 2차적으로 부하를 분산합니다. 쓰기 동작이 빈번하거나 데이터 성격상 NoSQL이 필요한 경우 Couchbase와 Redis를 적극적으로 사용하고 있으며, MariaDB 상에서도 쓰기 동작의 분산 필요성이 대두됨에 따라 상반기에 샤딩을 준비하고 있습니다. 사용자 행동, 트랜잭션 로그 등 하루에도 방대한 양이 쏟아지는 데이터의 경우 Azure 내에 구성한 Hadoop 클러스터에 보관하며, Hive 저장소를 BI(Business Intelligence) 시스템 기반으로 활용하고 있습니다.파일 시스템리디북스에서 다루는 책 파일은 매우 방대하고 중요한 데이터입니다. 어떠한 일이 있어도 데이터 유실이 발생해서는 안되며, 일부 하드웨어 혹은 노드에 장애가 발생하더라도 서비스 장애 없이 파일을 서빙할 수 있어야 합니다. 저희는 GlusterFS로 6대의 노드를 클러스터를 구성하고 이를 파일 접근이 필요한 서버에서 NFS-like 형태로 마운트하여 사용하고 있습니다. 동일 데이터는 여러 노드(3 replica)에 분산 저장되며, 각 노드에도 RAID 구성을 하여 빠른 장애 대응 및 데이터 유실 방지에 노력하고 있습니다.검색리디북스의 책/저자 검색 등은 ElasticSearch를 통해 이루어집니다. 형태소 분석기는 오픈소스인 은전한닢에 따로 정의한 dictionary를 조합해 사용하고 있고, 2대의 노드로 클러스터가 구성되어 있습니다. 추가/변경되는 도서 정보는 증분 색인을 통해 실시간으로 검색 서버에 반영됩니다.작업큐이메일 발송, PUSH 발송 등의 작업들은 웹 애플리케이션이 직접 실행할 경우 페이지 응답속도를 떨어뜨리고, 진행상황 파악이나 실패 시 재시도하는 등의 실행 관리가 어렵습니다. 이런 문제를 해결하기 위해 Beanstalk라는 Work Queue에 작업을 일단 쌓아두고, 여러 대의 서버에서 실행되고 있는 컨슈머들이 작업을 가져와 순차적으로 진행하는 형태로 구성되어 있습니다.모니터링장애 발생 포인트와 시점을 예측할 수 없는 만큼 장애 발생의 빠른 인지를 위해 모니터링은 매우 중요합니다. 리디북스는 99.999%의 고가용성(High Availability)을 목표로, 버그와 장애 없는 안전한 운영을 위해 아래와 같이 다양한 오픈소스 및 유료 솔루션을 도입하여 활용하고 있습니다.30+ 이상의 서버 리소스를 모니터링하기 위한 Munin(On-Premise) 및 NewRelic(SaaS)서버에서 발생하는 각종 오류와 예외를 모니터링하기 위한 Sentry로그인, 결제 등 서점의 핵심적인 기능의 정상 여부를 모니터링하는 Pingdom각종 배치작업과 주기적으로 실행되는 스크립트를 모니터링하기 위한 PushMonNode.js 프로세스나 Redis 상태 모니터링을 위한 Keymetrics(SaaS)데이터의 무결성을 주기적으로 감지하는 각종 In-house 스크립트#리디북스 #서버 #서버개발 #스택 #백엔드 #node.js #개발자 #개발언어 #스킬스택 #소개
조회수 2820

Radix? Redis!

얼마전부터 antirez twitter에서 radix tree 관련 트윗이 올라왔습니다. 얼마 지나지 않아 antirez가 radix tree를 구현한 rax 프로젝트를 공개하고 redis의 cluster hash_slot의 저장구조를 radix tree로 수정 되는것을 보았습니다.그동안 antirez의 코드 읽으면서 배우는 게 많았고, 자료구조에 관심이 많아서 살펴보기 시작했습니다. radix tree를 왜 구현 했는지, 어떻게 구현쟀는지 알아보고 radix tree를 redis에 어떻게 적용하였는지도 알아보겠습니다.antirez는 redis의 hash-slot -> key 구조에서 중복으로 인한 메모리 사용을 줄이기 위해 radix tree 를 만들었다고 합니다. 이 포스트에선 rax를 적용시킨 redis cluster로 이야기를 진행 하겠습니다.“현재는 hash-slot -> key에만 사용되지만 추후에는 다양한 곳에 사용 예정”이라는 트윗redis cluster?redis에는 cluster 기능이 있습니다.6대 이상의 redis 노드를 cluster 구성하면(최소 leader 3대, follower 3대 구성해야 cluster 가능) 16384개의 hash_slot이 노드 갯수에 맞게 분배가 됩니다. 즉 3대의 leader로 cluster 구성하면 각각의 leader는 0 ~ 5460, 5461 ~ 10922, 10923 ~ 16383 hash_slot을 나눠 가집니다.cluster 구성 후 client가 데이터 저장/삭제/조회 명령어를 redis server에 전송할 때 마다 key의 hash값을 구하고 어떤 leader hash_slot에 포함되는지 찾습니다.# example 127.0.0.1:7000> set hello world # hash_slot = crc16("hello") & 0x3FFF 계산된 값이 현재 접속한 leader의 hash_slot 범위에 있다면 그대로 실행 되지만 다른 leader의 hash_slot 이라면 에러를 발생하고 다른 leader로 이동하라고 힌트를 줍니다.cluster 구성 후에 노드를 추가 하거나 제거 할 경우 각 leader의 hash_slot을 재분배 하고, hash_slot에 맞게 key도 재분배 되어야 합니다. 단순하게 생각하면 leader의 hash_slot 재분배한 후 모든 key를 재계산하고 hash_slot에 맞는 leader에 할당 하는 겁니다.[현재까지 저장된 keys].forEach(v => { hash_slot = crc16(v) & 0x3FFF // leader에 할당된 hash_slot에 맞게 분배 }) 하지만 antirez는 redis Sorted set 데이터 타입의 구현체인 skiplist 을 이용하여 문제를 풀었습니다. skiplist는 member와 score를 저장하고, score를 기준으로 정렬합니다. skiplist의 member에는 key를 저장하고 score에는 key의 hash_slot을 저장합니다.(변수명 slots_to_keys)slots_to_keys 정보는 cluster 구성된 모든 노드가 저장합니다. 이후 재분배가 필요해지면 16384개 hash_slot을 leader 갯수에 맞게 재분배 하고 slots_to_keys에 저장된 “key:hash_slot” 정보를 가지고 해당 hash_slot의 key를 조회 및 재분배 합니다. 즉 slots_to_keys에 이용하여 재분배시 발생하는 계산을 없앤것입니다.잘 했구만 뭐가 문제냐?redis에 key가 추가/삭제 될때마다 slots_to_keys에 데이터가 저장되고 지워집니다. redis에 저장되는 key 갯수가 증가 할수록 slots_to_keys의 크기도 커짐을 의미 합니다.(※ 메모리 사용량)또한 leader 갯수에 맞게 16384개 hash_slot을 leader에 재분배하고, 각 hash_slot에 맞는 key를 찾고 할당 합니다. 예를들어 slots_to_keys에서 score 0인(hash_slot 0을 의미) member를 조회해서 0번 hash_slot에 할당, score 1인 member를 조회해서 1번 hash_slot에 할당 하는 방식으로 0 ~ 16383 hash_slot을 진행합니다.앞에서 말한 hash_slot에 속한 key를 조회 하는 GETKEYSINSLOT 명령어가 있는데 여기에 이슈가 있습니다.cluster GETKEYSINSLOT slot count # slot: hash_slot 번호 # count: 특정 hash_slot에서 조회할 key 갯수 # example 127.0.0.1:7000> cluster GETKEYSINSLOT 0 3 # 0번 hash_slot의 key를 3개 조회한다. "47344|273766|70329104160040|key_39015" "47344|273766|70329104160040|key_89793" "47344|273766|70329104160040|key_92937" 사용자가 특정 hash_slot에 몇개의 key가 저장 되었는지 모르기때문에 count에 Integer.MAX 를 대입하는데, redis는 hash_slot에 실제로 저장된 key 갯수와는 상관없이 client가 전달한 count만큼의 메모리를 할당합니다.} else if (!strcasecmp(c->argv[1]->ptr,"getkeysinslot") && c->argc == 4) { /* cluster GETKEYSINSLOT */ long long maxkeys, slot; unsigned int numkeys, j; robj **keys; // ... 명령어의 4번째 인자를 maxkeys에 할당, 즉 사용자가 입력한 count if (getLongLongFromObjectOrReply(c,c->argv[3],&maxkeys,NULL) != C_OK) return; // ... keys = zmalloc(sizeof(robj*)*maxkeys); numkeys = getKeysInSlot(slot, keys, maxkeys); addReplyMultiBulkLen(c,numkeys); for (j = 0; j < numkeys>zmalloc maxkeyscluster GETKEYSINSLOT unnecessarily allocates memory그래서 메모리도 적게 차지하면서(압축 가능) key와 key의 hashslot을 효율적으로 저장 및 조회가 가능한 자료구조가 필요했고 antirez는 radix tree를 선택합니다.※ 뜬금 없는데 2012년, redis 자료형에 Trie를 추가한 P/R이 생각났습니다.radix tree 구현한 rax 알아보기시작하기전 radix tree (Wikipedia) 위키 페이지의 그림을 보고 감을 잡은 후에 아래를 보시면 잘 읽힙니다.자! 이제부터 rax의 주석과 코드를 보면서 어떻게 구현됐는지 알아보겠습니다.Noderax의 노드 구성은 다음과 같습니다.typedef struct raxNode { uint32_t iskey:1; /* Does this node contain a key? */ uint32_t isnull:1; /* Associated value is NULL (don't store it). */ uint32_t iscompr:1; /* Node is compressed. */ uint32_t size:29; /* Number of children, or compressed string len. */ unsigned char data[]; } raxNode; 노드의 정보를 담고있는 32 bit(iskey, isnull, iscompr, size)와 key/value 그리고 자식 노드의 포인터를 저장하는 unsigned char data[]가 있습니다. 특이한 점은 key/value를 동일한 노드에 저장 하지 않고 key가 저장된 노드의 자식 노드에 value를 저장합니다.※ 사진 출처위 그림을 예로 32 bit 정보가 어떤걸 의미하는지 알아보겠습니다.iskey는 노드가 key의 종착역(iskey:1)인지 중간역(iskey:0)인지 나타내는 flag입니다. 1, 3 노드는 iskey:0 이고 2, 4, 5, 6, 7 노드는 iskey:1이 됩니다.isnull은 value의 null 여부를 표시합니다. unsigned char data[]에 key/value 그리고 자식 노드의 포인터를 저장하므로 value를 찾으려면 계산이 들어갑니다. 불필요한 연산을 줄이기 위해 만든 필드 같습니다.Trie는 각 노드에 한글자씩 표현 하지만 Radix는 압축을 통해 한 노드에 여러 글자 표현이 가능합니다. 이를 나태내는 플래그 iscompr 입니다. 노드가 압축된 노드(iscompr:1)인지 아닌지(iscompr:0)를 나타냅니다.size는 iscompr 값에 따라 의미가 다릅니다. iscompr이 1이면 저장된 key의 길이를 의미하고 iscompr이 0이면 자식노드의 갯수(저장된 key의 갯수)를 의미합니다.위 4개 정보를 이용해서 한 노드의 크기를 구하는 코드는 아래와 같습니다.#define raxNodeCurrentLength(n) ( \ sizeof(raxNode)+(n)->size+ \ ((n)->iscompr ? sizeof(raxNode*) : sizeof(raxNode*)*(n)->size)+ \ (((n)->iskey && !(n)->isnull)*sizeof(void*)) \ ) ※ 노드에 value 주소를 저장하거나, 마지막 자식 노드 포인터를 알고 싶을때 사용합니다.FindraxLowWalk 함수를 이용해 key가 존재 하는지 판단합니다.size_t raxLowWalk(rax *rax, unsigned char *s, size_t len, raxNode **stopnode, raxNode ***plink, int *splitpos, raxStack *ts) rax에 “ANNIBALE” -> “SCO” -> [] 로 저장 되어있을때 어떤 값을 리턴하는지 알아보겠습니다.*s 가 “ANNIBALESCO”이고 len이 11 인 경우# splitpos: 0, return value: 11 "ANNIBALE" -> "SCO" -> [] ^ | *stopnode *s가 “ANNIBALETCO”이고 len이 11인 경우# splitpos: 0, return value: 9 "ANNIBALE" -> "SCO" -> [] ^ | *stopnode *s의 길이 len과 return value가 같다면 rax에 key가 존재하는 것입니다. *s의 길이 len과 return value가 다른 경우 어디까지 매칭됐는지 보여주는 return value와 어떤 노드에 어디까지 일치했는지 표현하는 *stopnode, splitpos를 통해 추가 정보를 얻을수 있습니다.InsertraxLowWalk 함수를 이용해서 저장할 위치를 찾습니다. (*stopnode, splitpos, return value)1번에서 구해진 데이터를 이용해서 새로운 노드 생성 및 링크를 연결합니다.rax에 “ANNIBALE” -> “SCO” -> [] 상태에서 “ANNIENTARE”를 저장하는 과정입니다.1. raxLowWalk 함수를 이용하여 저장할 위치 탐색 splitpos: 4, return value: 4 "ANNIBALE" -> "SCO" -> [] ^ | *stopnode 2. *stopnode, splitpos 데이터를 이용하여 노드 분리 "ANNI" -> "B" -> "ALE" -> [] 3. iscompr: 0인 노드 "B"를 기준으로 새로운 key 저장 ("B"와 "E"는 같은 노드) |B| -> "ALE" -> [] "ANNI" -> |-| |E| -> "NTARE" -> [] RemoveraxLowWalk 함수를 이용해서 저장할 위치를 찾습니다. (*stopnode, splitpos, return value)1번에서 구해진 데이터를 이용해서 노드 제거 및 compress가 가능다면2가지 경우가 있습니다.마지막 노드만 iskey: 1이고, 연속으로 iscompr:1인 노드가 된 경우마지막 노드만 iskey: 1이고, iscompr:1 -> iscomplr:0 -> iscomplr:1 노드 구조가 된 경우입니다.첫번째 경우를 알아 보겠습니다. rax에 “FOO” -> “BAR” -> [] 상태에서 “FOO”를 지우는 과정입니다.1. raxLowWalk 함수를 이용하여 저장할 위치 탐색 splitpos: 3, return value: 3 "FOO" -> "BAR" -> [] ^ | *stopnode 2. 해당 key 삭제, 여기서는 자식노드가 있으므로 노드 삭제는 하지 않고 노드의 iskey: 0으로 세팅 "FOO" -> "BAR" -> [] 3. compress가 가능한 경우 진행 "FOOBAR" -> [] 두번째 경우를 알아 보겠습니다.0. "FOOBAR"와 "FOOTER"가 저장된 상황입니다. FOOTER를 지우는 경우입니다. |B| -> "AR" -> [] "FOO" -> |-| |T| -> "ER" -> [] 1. raxLowWalk 함수를 이용하여 저장할 위치 탐색 splitpos: 0, return value: 6 |B| -> "AR" -> [] "FOO" -> |-| |T| -> "ER" -> [] ^ | *stopnode 2. 해당 key 삭제 "FOO" -> "B" -> "AR" -> [] 3. compress가 가능한 경우 진행 "FOOBAR" -> [] cluster 정보는 어떻게 저장되나?기존 skiplist 자료구조를 이용했던게 어떻게 변경 되었는지 알아보겠습니다.server.cluster->slots_keys_count[hashslot] += add ? 1 : -1; if (keylen+2 > 64) indexed = zmalloc(keylen+2); indexed[0] = (hashslot >> 8) & 0xff; indexed[1] = hashslot & 0xff; memcpy(indexed+2,key->ptr,keylen); if (add) { raxInsert(server.cluster->slots_to_keys,indexed,keylen+2,NULL,NULL); } else { raxRemove(server.cluster->slots_to_keys,indexed,keylen+2,NULL); } 먼저 slots_keys_count 변수를 이용하여 각 hash_slot의 key 갯수를 저장합니다.그리고 key는 hash_slot(2 byte) + key, value는 NULL로 rax에 저장하여 특정 hash_slot에 속한 key 조회를 쉽게 만들었습니다.마치며rax 구현과 rax가 어떻게 redis에 적용됐는지 보면서 오랜만에 재밌게 코드를 읽은것 같습니다. 개인적으로 데이터 관련 유용한 무언가를 만드는게 목표인데, 이런 좋은 코드들을 하나 둘씩 제것으로 만드는것도 과정이라 생각하며 진행했습니다.앞으로 rax가 redis에서 어떻게 쓰일지 흥미롭고, Redis를 Saas 형태로 제공하는 업체들이 언제 적용할지도 궁금합니다.긴 글 읽어주셔서 감사합니다.cluster, rax 관련 antirez twitterRedis cluster Insertion cluster Issuesame amount data hash table vs radix treehashset + ziplist -> radix tree + listpack 1/5replace Hashset with Radix treeraxNode에서 사용한 flexible memberflexible memberrax 를 이용한 Redis Streams(2017.12.17일 업데이트)Redis Stream#잔디 #토스랩 #JANDI #기술스택 #도입후기 #Redis #인사이트
조회수 1602

Humans of TODAIT : 안드로이드 천재 개발자 김범준을 만나다

‘Humans of TODAIT’의 네번째 주인공, 투데잇 안드로이드 개발자 김범준씨를 만나보았습니다. 투데잇의 천재 개발자로 불리는 그의 이야기를 함께 들어볼까요?(2017.08)Q. 자기소개 부탁드려요.안녕하세요! 투데잇에서 까칠남을 맡고 있는 안드로이드 개발자 김범준입니다. 퇴사자 인터뷰를 하게 되니, 정들었던 팀원분들과 헤어질 생각에 아쉽고 싱숭생숭하네요. (웃음) 작년 초 쯤 ‘SW 마에스트로’ 프로그램에서 만난 멘토님께서 제게 투데잇 안드로이드 개발자 자리를 추천해주신 덕분에 이렇게 투데잇과 인연이 닿게 되었어요. 사실 처음에는 큰 생각이 없었는데, 대표님과 팀장님을 만나보니 저와 코드도 잘 맞고 개발 쪽으로도 많이 배워볼 수 있을 것 같아서 그 날 바로 입사 결정을 내렸고, 지금은 퇴사를 앞두고 있네요.Q. 그렇게 좋은 투데잇을 떠나는 이유는 무엇인가요?원래 병특을 가야 했어요. 제가 군대를 아직 안 갔기 때문에, 군대 문제를 해결 해야 더 많은 기회도 생기고 지금 가지고 있는 마음의 짐 같은 것도 덜 수 있거든요. 아쉽게도 투데잇이 병특 산업기능요원지정업체가 아니어서 군대 문제를 해결하기 위해서는 퇴사할 수 밖에 없는 상황이에요. 사실 원래부터 군대 문제 때문에 잠시 동안만 일하기로 했던건데, 회사생활이 너무 만족스럽고 일이 즐거워서 계속 미루다가 이제서야 결정을 내렸네요. 지금도 많이 아쉬워요. 투데잇만한 회사 없거든요.Q. 팀 내에서 평소 자기계발을 많이 하는 것으로 유명한데, 혹시 자기계발 노하우가 있나요?사실 공부는 진짜 하는 것보다 시작하는 것이 어렵잖아요. 그래서 저는 일부러 저한테 강제성을 주는 편이에요. 매주 하는 동아리 활동이라든지 발표 기회를 만든다든지 관련 세미나를 참여한다든지 그런 일정이 생기면 자연스럽게 하게 되더라고요. 하면 또 잘하고 싶은 게 사람 마음이니까 자꾸 강제적으로 그런 기회를 만들죠.그리고 저는 일상에서 배울 수 있는 기회를 얻으려고 해요. 일하다가 힘들거나 머리가 잘 안 돌아갈 때 저장해둔 아티클을 보곤 하죠. 또 술마실 때도 같은 직업군의 친구들을 만나면 그런 얘기를 많이 하잖아요. 너 이거 시도해봤냐 어땠냐 이건 어떻게 하는거냐 같은 이야기요. 제가 주위 사람들에게 자극을 많이 받거든요. 책상 앞에 앉아서 하는 공부보다는 일상적 시간을 활용하고 뭔가를 준비하기 위한 공부의 자기계발을 하는 것 같아요.Q. 지난 1년을 돌아보는 의미에서, 개발자로서의 좌우명이나 철학이 있을까요?저는 어떤 일을 하든 명확한 근거가 있어야 한다고 생각해요. 커뮤니케이션에서도 그렇고 개발에 있어도 마찬가지예요. 내가 하는 일에 대한 충분한 이유가 있어야 하고 그게 코드에 녹아 있어야 해요.예를 들면, 같은 풍경을 보고 글을 쓸 때도 여러 방법이 있잖아요. 사람마다 글 쓰는 방법이 다르고. 그 방법을 선택한 데엔 저마다 이유가 있어요. 코드도 마찬가지예요. 어떤 기능을 개발할 때 그 기능을 구현할 수 있는 여러 방법이 있는데, 개발자라면 내가 만든 코드에 대해 내가 왜 이렇게 짰는지 다른 사람에게 자신 있게 말할 수 있는 개발자가 되어야 한다고 생각해요.저는 힙한 개발자가 되고 싶어요. 그러니까 최신 트렌드에 민감하고, 새로운 것에 도전하고 두려워 하지 않는 그런 개발자요. (웃음)Q. 힙한 개발자 멋지네요. 그렇다면 10년 후에는 무엇을 하고 싶은지 궁금한데요?제 꿈은 그냥 행복하게 사는거예요. (하하) 추상적인 이야기 같겠지만, 행복하게 살기 위해선 많은 것들이 필요하잖아요? 우리가 말하는 이상적인 행복이란 것은 돈, 인간관계, 사회적 직위, 건강과 같은 모든 박자가 잘 맞아 떨어졌을 때 이루어지는 행복이거든요. 그래서 저는 행복하기 위해서는 끊임없이 노력해야 한다고 생각해요. 장차 10년 후에 제가 뭘 하고 있을지는 모르지만, 지금 현재의 상황에서 제가 할 수 있는 최선의 선택을 하면서 열심히 단계적으로 이루어나가면, 10년 후에도 충분히 행복할 것 같아요. 저는 지금 행복하거든요. (웃음)Q. 일하다 보면 해결하기 힘든 난제를 만날 때가 있을 것 같은데, 그럴 땐 어떻게 극복하나요?내가 스트레스를 많이 받고 있다는 걸 깨달으면, 그냥 최대한 스트레스 받지 않으려고 해요. 그냥 뭐 하면 되지 라는 생각이죠. 하면 되지 하면서 하다보면 결국 되는 것 같아요. 어차피 해야 될 일인데, 스트레스 받으면서 하기 보다는 그냥 아무 생각 없이 열심히 하는 게 나으니까요. 만약에 제가 몰라서 못하고 있는 일이면 여러 사람들에게 물어보려고 하면서 어떻게든 해결하려고 하고요.Q. 그렇다면 투데잇에서 가장 만족스러운 결과물은 무엇인가요? 개인적으로 뿌듯하다거나 실제 반응이 좋았다거나 그런 것들이요!‘스탑워치’ 기능이 두 개 다 포함돼요. 이전 개발자가 스파게티 코드(엉망진창의 코드)로 만들어 놓았던 것이 있는데 그 코드를 제가 깔끔하게 다 수정했고, 계속 유저분들이 요청해주셨던 시간 잠금, 극강의 잠금 모드 같은 기능들을 추가해서 코드를 예쁘게 잘 만들어놓았거든요. 일단 제가 기발한 기능과 함께 코드를 예쁘게 잘 만들어냈다는 점에서 스스로도 만족을 했었고, 유저분들도 팀원분들도 좋은 피드백을 해주셔서 굉장히 좋았습니다.Q. 지금 이 글을 보고 계시는 스탑워치 기능 애용 유저분들께 한마디 해주세요!우선 잘 사용해주셔서 감사해요! 제가 만든 기능을 이용해 공부하시는 걸 보면, 저도 정말 큰 자부심을 느끼거든요. :) 다만, 아직 스탑워치 기능에 문제가 조금 있는 거로 알고 있어요. 약간 불편하더라도 이왕이면 둥글게 좋게 별 5점으로 리뷰 주시면! 저희와 의사소통하면서 함께 좋은 서비스 만들어 나갈 수 있을 것 같아요. 안 보는 것 같지만 투데잇 개발자 전체가 매일 열심히 읽고 있거든요. 정말 리뷰 하나에 울고 리뷰 하나에 웃습니다. 저희 투데잇 지금까지 사랑해주셨지만, 앞으로도 계속 사랑해주시면 감사하겠습니다. :)Q. 반대로 투데잇 안드로이드 개발에 있어 아쉬운 부분도 있을 것 같아요. 나 이거 진짜 욕심났다! 혹시 있을까요?음.. 저는 옛날에 있던 아키텍처를 일단 전부 바꾸고 싶어요. 최근에 꽂힌 아키텍쳐가 있는데, 그 아키텍쳐에 맞게 코드를 다 변경해보고 싶다는 욕심이 있거든요. 근데 그 아키텍쳐 특성상 현재 코드에서는 완전히 대대적인 수정이 들어가야되는데, 제가 남은 시간이 얼마 없어서 많이 수정을 못했죠. 우리가 좀 더 많은 시간이 있고 여유가 있었더라면 더 바꿔볼 수 있었을텐데 그런 부분들을 못한 게 조금 아쉬워요.“투데잇의 힘은 서로에 대한 믿음인 것 같아요”Q. 범준님에게 투데잇이란? 투데잇 팀의 힘이 무엇이라고 생각하시나요?무엇보다 투데잇의 힘은 서로에 대한 믿음인 것 같아요. 커뮤니케이션이 잘 되려면 그 사람에 대한 믿음이 있어야 되잖아요. 근데 저흰 그게 되게 잘 되고 있다고 생각되거든요. 업무적으로 제 이야기를 자신있게 할 수 있었던 이유도 이 사람들은 전부 다 각자 일을 열심히 하고 책임을 지려는 사람, 멋있는 사람이라는 걸 알고 있었기 때문에 가능했거든요. 다들 맡은 바에 있어서 최선을 다하고 정말 열심히해요. 그 분위기가 서로에 대한 믿음을 만들고 우리의 원동력을 만들죠. 확실히 저희 팀은 일단은 진짜 서로에 대한 믿음이 강하다? 업무적 믿음이 강하다? 그런 게 있는 것 같아요.Q. 투데잇에서 가장 고마웠던 사람은 누구였나요?솔직히 다 고마운데, 저는 대표님께 가장 감사했어요. 이번에도 혼자 고민하다가 힘들게 퇴사 의사를 밝혔는데, 대표님께서 그건 당연한 거라고 이야기해주시더라고요. 저는 투데잇 팀이 참 좋은 게 어떤 이야기를 했을 때 명확한 근거가 있다면 그 후에 뒤끝이 하나도 없어요. 이번 일도 그렇고 일적으로 이야기 할 때도 그렇고, 이유가 확실하면 OK하고 쿨하게 가곤 하셨거든요. 다 업무적 믿음이 있기 때문이라고 생각해요 저는. 여러모로 저를 많이 믿어주신 대표님한테 제일 감사하죠. 대표님 에너지도 너무 좋고 카리스마도 본받고 싶고 제가 되게 좋아하는 분이에요.Q. 범준님의 다음 타자가 될! 투데잇에 입사하고 싶은, 입사할 분들에게 한 마디 부탁드려요!“팀원 하나하나가 굉장히 중요한 역할을 하고 있는 사람들이어서 그만큼 책임감이 있지만, 그만큼의 자율성도 있는 회사에요”굉장히 좋은 팀이에요. 일적에서는 절대 스트레스 주는 일이 없고요. 뭔가 일이 밀리거나 못하는 거에 있어서는 스트레스가 있을 수도 있어요. 팀원 하나하나가 굉장히 중요한 역할을 하고 있는 사람들이어서 그만큼 책임감이 있지만, 그만큼의 자율성도 있는 회사에요. 노력하는 그대로의 모습을 사람들에게 보여줄 수 있고 인정 받을 수 있기 때문에 흔히 말하는 꼰대 문화가 싫으신 분들은 투데잇에서 행복하게 일할 수 있을 거예요. 업무적으로나 환경적으로나 대우도 근무 환경도 굉장히 좋으니까 관심 있으신 분이면, 특히 안드로이드 개발자 분이면 지금 바로 들어오실 수 있을 것 같아요. 유저한테 피드백도 받을 수 있고 개인적으로 리스펙하는 멋진 CTO분도 계시고, 개발자로서 특히 굉장히 좋은 곳입니다. 주저 마세요!#투데잇 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화
조회수 2384

Tabnabbing 피싱 공격의 동작 원리와 대응책

브라우저에서 사용자의 개인 정보를 가로채는 여러가지 피싱 공격 기법이 있습니다. 이 글에서는 그 중에서도 상대적으로 단순해서 과소평가된 Tabnabbing 공격의 동작 원리와 대응책을 함께 알아보겠습니다.Tabnabbing 의 동작 원리Tabnabbing은 HTML 문서 내에서 링크(target이 _blank인 Anchor 태그)를 클릭 했을 때, 새롭게 열린 탭(또는 페이지)에서 기존의 문서의 location을 피싱 사이트로 변경해 정보를 탈취하는 공격 기술을 뜻한다. 이 공격은 메일이나 오픈 커뮤니티에서 쉽게 사용될 수 있습니다.(출처: blog.jxck.io 영어 스펠링이 이상해 보이는 것은 기분 탓입니다)공격 절차는 다음과 같습니다:사용자가 cg**m**.example.com에 접속합니다.해당 사이트에서 happy.example.com으로 갈 수 있는 외부 링크를 클릭합니다.새 탭에 happy.example.com가 열립니다.happy.example.com에는 window.opener 속성이 존재합니다.자바스크립트를 사용해 opener의 location을 피싱 목적의 cg**n**.example.com/login 으로 변경합니다.사용자는 다시 본래의 탭으로 돌아옵니다.로그인이 풀렸다고 착각하고 아이디와 비밀번호를 입력한다.cg**n**.example.com은 사용자가 입력한 계정 정보를 탈취한 후 다시 본래의 사이트로 리다이렉트합니다.예제: 네이버 메일 vs. Gmail시나리오를 하나 그려볼까요?공격자가 네이버 계정을 탈취할 목적으로 여러분에게 세일 정보를 담은 메일을 보냅니다. 그 메일에는 [자세히 보기]라는 외부 링크가 포함되어 있습니다. 물론 이 세일 정보는 가짜지만 공격자에겐 중요하지 않습니다. 메일을 읽는 사람이 유혹에 빠져 링크를 클릭하면 그만이죠.(상단의 주소를 주목하세요)하지만 Gmail은 이 공격이 통하지 않습니다. Gmail은 이러한 공격을 막기 위해 Anchor 태그에 data-saferedirecturl 속성을 부여해 안전하게 리다이렉트 합니다.rel=noopener 속성이러한 공격의 취약점을 극복하고자 noopener 속성이 추가됐습니다. rel=noopener 속성이 부여된 링크를 통해 열린 페이지는 opener의 location변경과 같은 자바스크립트 요청을 거부합니다. 정확히 말해서 Uncaught TypeError 에러를 발생시킵니다(크롬 기준).이 속성은 Window Opener Demo 페이지를 통해 테스트해볼 수 있습니다. 크롬은 버전 49, 파이어폭스 52부터 지원합니다. 파이어폭스 52가 2017년 3월에 릴리즈 된 것을 감안하면 이 속성 만으로 안심하긴 힘들겠네요. 자세한 지원 여부는 Link types를 참고하세요.따라서, 이러한 공격이 우려스러운 서비스라면 blankshield 등의 라이브러리를 사용해야 합니다:blankshield(document.querySelectorAll('a[target=_blank]')); 참고로, noopener 속성은 이 외에도 성능 상의 이점도 있습니다. _blank 속성으로 열린 탭(페이지)는 언제든지 opener를 참조할 수 있습니다. 그래서 부모 탭과 같은 스레드에서 페이지가 동작합니다. 이때 새 탭의 페이지가 리소스를 많이 사용한다면 덩달아 부모 탭도 함께 느려집니다. noopener 속성을 사용해 열린 탭은 부모를 호출할 일이 없죠. 따라서 같은 스레드일 필요가 없으며 새로운 페이지가 느리다고 부모 탭까지 느려질 일도 없습니다.성능 상의 이점에 대한 자세한 내용은 The performance benefits of rel=noopener을 참고하세요.참고자료Tabnabbing: A New Type of Phishing AttackTarget=”_blank” - the most underestimated vulnerability ever링크에 rel=noopener를 부여해 Tabnabbing을 대비(일어)The performance benefits of rel=noopener
조회수 1693

비트윈 시스템 아키텍처 - VCNC Engineering Blog

VCNC는 커플을 위한 모바일 앱 비트윈을 서비스하고 있습니다. 비트윈은 사진, 메모, 채팅, 기념일 등 다양한 기능을 제공하며, 오픈 베타 테스트를 시작한 2011년 11월부터 현재까지 연인 간의 소통을 돕고 있습니다. 그동안 비트윈 시스템 아키텍처에는 많은 변화가 있었으며 다양한 결정을 하였습니다. 비트윈 아키텍처를 발전시키면서 배우게 된 여러 가지 노하우를 정리하여 공유해보고자 합니다. 그리고 저희가 앞으로 나아갈 방향을 소개하려 합니다.소프트웨어 스택Java: 비트윈 API서버는 Java로 작성되어 있습니다. 이는 처음 비트윈 서버를 만들기 시작할 때, 서버 개발자가 가장 빨리 개발해낼 수 있는 언어로 프로그래밍을 시작했기 때문입니다. 지금도 자바를 가장 잘 다루는 서버 개발자가 많으므로 여전히 유효한 선택입니다.Netty: 대부분의 API는 HTTP로 호출되며, 채팅은 모바일 네트워크상에서의 전송 속도를 위해 TCP상에서 프로토콜을 구현했습니다. 두 가지 모두 Netty를 통해 사용자 요청을 처리합니다. Netty를 선택한 것은 뛰어난 성능과 서비스 구현 시 Thrift 서비스를 통해 HTTP와 TCP 프로토콜을 한 번에 구현하기 쉽다는 점 때문이었습니다.Thrift: API서버의 모든 서비스는 Thrift 서비스로 구현됩니다. 따라서 TCP뿐만 아니라 HTTP 또한 Thrift 인터페이스를 사용합니다. HTTP를 굳이 Thrift서비스로 구현한 이유는, TCP로 메세징 전송 시 똑같은 서비스를 그대로 사용하기 위함이었습니다. 덕분에 빠른 채팅 구현 시, 이미 구현된 서비스들을 그대로 사용할 수 있었습니다. 또한, 채팅 패킷들은 패킷 경량화를 위해 snappy로 압축하여 송수신합니다. 모바일 네트워크상에서는 패킷이 작아질수록 속도 향상에 크게 도움이 됩니다.HBase: 비트윈의 대부분 트랜젝션은 채팅에서 일어납니다. 수많은 메시지 트랜젝션을 처리하기 위해 HBase를 선택했으며, 당시 서버 개발자가 가장 익숙한 데이터베이스가 HBase였습니다. 서비스 초기부터 확장성을 고려했어야 했는데, RDBMS에서 확장성에 대해 생각하는 것보다는 당장 익숙한 HBase를 선택하고 운영하면서 나오는 문제들은 차차 해결하였습니다.ZooKeeper: 커플들을 여러 서버에 밸런싱하고 이 정보를 여러 서버에서 공유하기 위해 ZooKeeper를 이용합니다. Netflix에서 공개한 오픈 소스인 Curator를 이용하여 접근합니다.AWS비트윈은 AWS의 Tokyo리전에서 운영되고 있습니다. 처음에는 네트워크 및 성능상의 이유로 국내 IDC를 고려하기도 했으나 개발자들이 IDC 운영 경험이 거의 없는 것과, IDC의 실질적인 TCO가 높다는 문제로 클라우드 서비스를 이용하기로 하였습니다. 당시 클라우드 서비스 중에 가장 안정적이라고 생각했던 AWS 를 사용하기로 결정했었고, 지금도 계속 사용하고 있습니다.EC2: 비트윈의 여러 부가적인 서비스를 위해 다양한 종류의 인스턴스를 사용 중이지만, 메인 서비스를 운용하기 위해서는 c1.xlarge와 m2.4xlarge 인스턴스를 여러 대 사용하고 있습니다.API 서버: HTTP 파싱이나 이미지 리시아징등의 연산이 이 서버에서 일어납니다. 이 연산들은 CPU 가 가장 중요한 리소스이기 때문에, c1.xlarge를 사용하기로 했습니다.Database 서버: HDFS 데이터 노드와 HBase 리전 서버들이 떠있습니다. 여러 번의 테스트를 통해 IO가 병목임을 확인하였고, 따라서 모든 데이터를 최대한 메모리에 올리는 것이 가장 저렴한 설정이라는 것을 확인하였습니다. 이런 이유 때문에 68.4GB의 메모리를 가진 m2.4xlarge를 Database 서버로 사용하고 있습니다.EBS: 처음에는 HBase상 데이터를 모두 EBS에 저장하였습니다. 하지만 일정 시간 동안 EBS의 Latency가 갑자기 증가하는 등의 불안정한 경우가 자주 발생하여 개선 방법이 필요했는데, 데이터를 ephemeral storage에만 저장하기에는 안정성이 확인되지 않은 상태였습니다. 위의 두 가지 문제를 동시에 해결하기 위해서 HDFS multiple-rack 설정을 통해서 두 개의 복제본은 ephemeral storage에 저장하고 다른 하나의 복제본은 PIOPS EBS에 저장되도록 구성하여 EBS의 문제점들로부터의 영향을 최소화하였습니다.S3: 사용자들이 올리는 사진들은 s3에 저장됩니다. 사진의 s3키는 추측이 불가능하도록 랜덤하게 만들어집니다. 어차피 하나의 사진은 두 명밖에 받아가지 않고 클라이언트 로컬에 캐싱되기 때문에 CloudFront를 사용하지는 않습니다.ELB: HTTP는 사용자 요청의 분산과 SSL적용을 위해 ELB를 사용합니다. TCP는 TLS를 위해 ELB를 사용합니다. SSL/TLS 부분은 모두 AWS의 ELB를 이용하는데, 이는 API서버의 SSL/TLS처리에 대한 부담을 덜어주기 위함입니다.CloudWatch: 각 통신사와 리전에서 비트윈 서버로의 네트워크 상태와 서버 내의 요청 처리 시간 등의 메트릭을 CloudWatch로 모니터링 하고 있습니다. 따라서 네트워크 상태나 서버에 문제가 생긴 경우, 이메일 등을 통해 즉각 알게 되어, 문제 상황에 바로 대응하고 있습니다. Netflix의 Servo를 이용하여 모니터링 됩니다.현재의 아키텍처처음 클로즈드 베타 테스트때에는 사용자 수가 정해져 있었기 때문에 하나의 인스턴스로 운영되었습니다. 하지만 처음부터 인스턴스 숫자를 늘리는 것만으로도 서비스 규모를 쉽게 확장할 수 있는 아키텍쳐를 만들기 위한 고민을 하였습니다. 오픈 베타 이후에는 발생하는 트래픽에 필요한 만큼 여러 대의 유연하게 서버를 운영하였고, 현재 채팅은 TCP 위에서 구현한 프로토콜을 이용하여 서비스하고 있습니다.HTTP 요청은 하나의 ELB를 통해 여러 서버로 분산됩니다. 일반적인 ELB+HTTP 아키텍처와 동일합니다.채팅은 TCP 연결을 맺게 되는데, 각 커플은 특정 API 서버로 샤딩되어 특정 커플에 대한 요청을 하나의 서버가 담당합니다. 비트윈에서는 커플이 샤딩의 단위가 됩니다.이를 통해, 채팅 대화 내용 입력 중인지 여부와 같이 굉장히 빈번하게 값이 바뀌는 정보를 인메모리 캐싱할 수 있게 됩니다. 이런 정보는 휘발성이고 매우 자주 바뀌는 정보이므로, HBase에 저장하는 것은 매우 비효율적입니다.Consistent Hashing을 이용하여 커플을 각 서버에 샤딩합니다. 이는 서버가 추가되거나 줄어들 때, 리밸런싱되면서 서버간 이동되는 커플들의 수를 최소화 하기 위함입니다.클라이언트는 샤딩 정보를 바탕으로 특정 서버로 TCP연결을 맺게 되는데, 이를 위해 각 서버에 ELB가 하나씩 붙습니다. 어떤 서버로 연결을 맺어야 할지는 HTTP 혹은 TCP 프로토콜을 통해 알게 됩니다.Consistent Hashing을 위한 정보는 ZooKeeper를 통해 여러 서버간 공유됩니다. 이를 통해 서버의 수가 늘어나거나 줄어들게 되는 경우, 각 서버는 자신이 담당해야 하는 샤딩에 대한 변경 정보에 대해 즉각 알게 됩니다.이런 아키텍처의 단점은 다음과 같습니다.클라이언트가 자신이 어떤 서버로 붙어야 하는지 알아야 하기 때문에 프로토콜 및 아키텍처 복잡성이 높습니다.서버가 늘어나는 경우, 순식간에 많은 사용자 연결이 맺어지게 됩니다. 따라서 새로 추가되는 ELB는 Warm-up이 필요로 하며 이 때문에 Auto-Scale이 쉽지 않습니다.HBase에 Write연산시, 여러 서버로 복제가 일어나기 때문에, HA을 위한 Multi-AZ 구성을 하기가 어렵습니다.한정된 자원으로 동작 가능한 서버를 빨리 만들어내기 위해 이처럼 디자인하였습니다.미래의 아키텍처현재 아키텍처에 단점을 보완하기 위한 해결 방법을 생각해보았습니다.Haeinsa는 HBase상에서 트렌젝션을 제공하기 위해 개발 중인 프로젝트입니다. 구현 완료 후, 기능 테스트를 통과하였고, 퍼포먼스 테스트를 진행하고 있습니다. HBase상에서 트렌젝션이 가능하게 되면, 좀 더 복잡한 기능들을 빠르게 개발할 수 있습니다. 서비스에 곧 적용될 예정입니다.Multitier Architecture를 통해 클라이언트와 서버 간에 프로토콜을 단순화시킬 수 있습니다. 이 부분은 개발 초기부터 생각하던 부분인데, 그동안 개발을 하지 못하고 있다가, 지금은 구현을 시작하고 있습니다. 커플은 특정 Application 서버에서 담당하게 되므로, 인메모리 캐싱이 가능하게 됩니다. 클라이언트는 무조건 하나의 ELB만 바라보고 요청을 보내게 되고, Presentation 서버가 사용자 요청을 올바른 Application 서버로 릴레이 하게 됩니다.Multitier Architecture를 도입하면, 더 이상 ELB Warm-up이 필요하지 않게 되므로, Auto-Scale이 가능하게 되며, 좀 더 쉬운 배포가 가능하게 됩니다.Rocky는 API 서버의 Auto-Failover와 커플에 대한 샤딩을 직접 처리하는 기능을 가진 프로젝트입니다. 현재 설계가 어느 정도 진행되어 개발 중에 있습니다. 알람이 왔을 때 서버 팀이 마음을 놓고 편히 잠을 잘 수 있는 역할을 합니다.기본적인 것은 위에서 언급한 구조와 동일하지만 몇 가지 기능이 설정을 추가하면 Multi-AZ 구성이 가능합니다.특정 커플에 대한 모든 정보는 하나의 HBase Row에 담기게 됩니다.HBase의 특정 리전에 문제가 생긴 경우, 일정 시간이 지나면 자동으로 복구되긴 하지만 잠시 동안 시스템 전체에 문제가 생기가 됩니다. 이에 대해 Pinterest에서 Clustering보다는 Sharding이 더 낫다는 글을 쓰기도 했습니다. 이에 대한 해결책은 다음과 같습니다.원래는 Consistent Hashing을 사용하여 커플들을 Application 서버에 샤딩하였습니다. 하지만 이제는 HBase에서 Row를 각 리전에 수동으로 할당하고, 같은 리전에 할당된 Row에 저장된 커플들은 같은 Application 서버에 할당하도록 합니다.이 경우에, 같은 커플들을 담당하는 Application 서버와 HBase 리전 서버는 물리적으로 같은 머신에 둡니다.이렇게 구성 하는 경우, 특정 HBase 리전이나 Application 서버에 대한 장애는 특정 샤드에 국한되게 됩니다. 이와 같이 하나의 머신에 APP과 DB를 같이 두는 구성은 구글에서도 사용하는 방법입니다.이와 같이 구성하는 경우, Multi-AZ 구성이 가능하게 됩니다.AWS에서 같은 리전에서 서로 다른 Zone간 통신은 대략 2~3ms 정도 걸린다고 합니다.Presentation의 경우, 비동기식으로 동작하기 때문에 다른 리전으로 요청을 보내도 부담이 되지 않습니다.HBase에서 Write가 일어나면 여러 복제본을 만들게 됩니다. 하나의 사용자 요청에 대해 Write가 여러번 일어나기 때문에 HBase연산의 경우에는 서로 다른 Zone간 Latency가 부담으로 작용됩니다. Haeinsa가 적용되면, 한 트렌젝션에 대해서 연산을 Batch로 전송하기 때문에 AZ간 Latency 부담이 적습니다.프리젠테이션다음은 2월에 있었던 AWS 유저 그룹 세미나에서 발표했던 자료 입니다. 비트윈 서버 아키텍처에 대해서 배포 방법을 중심으로 설명이 되어 있습니다. 비슷한 내용이 많이 있으니 살펴보시기 바랍니다.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/e4af60d05bb6013025f71231381b23b3?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">
조회수 878

로봇 택시가 산업 지형을 바꾼다

로봇 택시가 산업 지형을 바꾼다"자율 주행 전기차의 등장으로 유가가 배럴당 25달러까지 떨어지고, 새로운 세계 질서가 도래할 것이다."'에너지 혁명 2030' 의 저자로 2015년 한국을 방문한 적 있는 토니 세바 스탠포드대 교수(RethinkX의 공동 설립자)가 최근 미국 CNBC와 인터뷰에서 "기름 수요가 2020년~2021년 사이 1백만 배럴로 꼭지를 찍은 뒤 10년 내(2030년경)로 70만 배럴까지 줄어들면서 유가가 하락세를 면치 못할 것”이라며 이같이 예견했다.점차 많은 사람들이 공유경제의 축으로 자율 주행 전기차를 사용하게 되면서 ▽오일 회사는 생존이 어렵게 되고 ▽심해, 세일가스업체와 정유 파이프라인 회사들도 문을 닫게 될 것이라는 게 그의 예측이다.차량도 소유의 대상에서 서비스의 대상, 이른바 TAAS (transport as a service) 로 바뀐다. 차량을 더 이상 구입하지 않고, 편리하게 앱으로 로봇 택시를 호출해 이용하면 그만이다. 자율 주행 전기차의 가격도 싸지면서, 전기차 이용이 소유에 비해 10배 정도 저렴해질 것이라는 것.  경제학자인 그의 섬뜩한 전망은 계속된다. 급속한 기술의 진보로 인해 값비싼 정유회사나, 적응력이 떨어지는 카 메이커(의 주식)가 매력이 없어지며, 차량과 관련된 직업 중에서 차 딜러도 2024년까지 사라질 것이라는 예상이다.뿐만 아니라, 주차공간의 80% 이상이 쓸모없게 되고, (자동차)보험의 비용도 급격하게 떨어지기 때문에 보험회사도 설 땅이 좁아진다는 것.이 같은 그의 전망이 혼자만의 견해는 아니지만,  다른 사람들은 이런 변화에 훨씬 많은 시간이 걸리고, 그렇게 극적이지도 않을 거라고 내다본다.반대로 그는 차량 관련 지출이 줄면서 가계 소비가 늘어나 경제성장을 촉진할 것이라고 예상했다. 아울러 차세대 차의 개발과 관련된 차 운영체제, 컴퓨터 플랫폼, 배터리, 지도 소프트웨어 회사들을 눈여겨 보라고 조언했다.세바 교수의  유가 하락 전망이  결코 급진적인 것은 아니다.  유가는 WTI(서부 텍사스중질유)기준으로 2016년 2월에  배럴당 20달러대 중반까지 급락한 바 있다.  6월 14일 현재는  40달러대 중반에 머물러 있다.다만, 차량이 소유의 대상에서 이용 서비스의 대상으로 바뀐다든지, 차 딜러가 사라진다든지 하는 등의 혁신적이거나 과격한 전망이 실현될 지는 두고 볼 일이다.참조 : 다음은 토니 세바 교수가 참여한 화제의 보고서 ‘Rethinking transportation 2020-2030’ 원문 링크https://static1.squarespace.com/static/585c3439be65942f022bbf9b/t/591a2e4be6f2e1c13df930c5/1494888038959/RethinkX+Report_051517.pdf
조회수 1612

Java의 json 라이브러리 google-gson

문제 상황안드로이드 어플리케이션을 개발하다 보면 주소록을 다루는 일이 종종 있습니다. 어플리케이션에서 주소록에 관련된 정보를 접근할 일이 있는 어플이라면 ContentResolver를 통해 단말의 주소록에 접근해서 필요한 정보를 가져오게 됩니다.그런데, 최근 개발하고 있는 스포카 어플을 통해 아주 많은 사람의 연락처가 저장된 주소록을 가지고 이런 저런 로직을 실행하는 상황을 테스트 하다보니, OutOfMemory(OOM)에러가 발생하는 현상을 볼 수 있었습니다. 모바일 디바이스들은 PC와 다르게 자원이 제한적이기 때문에 어떻게 하면 OOM을 일으키지 않을 수 있을까 라는 고민을 해야 하는 상황이었습니다.대강 문제가 되었던 클라이언트 사이드의 로직을 살펴보면 이렇습니다.단말의 주소록에 접근하여 필요한 정보를 추출 후 서버에 전송서버에서 정보를 가공하여 필요한 json 문자열을 생성 후 반환, 이 문자열은 주소록에서 보낸 정보의 양에 비례해서 늘어나게 됩니다.클라이언트 측에서 서버 측에서 보낸 json 문자열을 이용하여 JSONObject객체를 만든 후 이 JSONObject를 이용 리스트 완성eclipse의 MAT(Memory Analyzer)을 이용하여 어느 시점에서 OOM이 일어나는지를 추측해보았습니다. 서버에서 보내준 json형식의 문자열을 HttpURLConnection을 통해 전달받고 이를 StringBuilder를 이용하여 완전한 문자열으로 만들던 도중에 OOM이 일어나는 것으로 의심되었는데 이 때문에 JSONObject의 생성자에 json 문자열을 전달하기도 전에 메모리가 가득 차 버리니 매우 난감한 상황이었습니다.대게 주소록에 사람이 그렇게 많지 않으므로 (200~500명 정도) 아무런 문제가 없었지만 10000명 정도의 더미데이터를 주소록에 저장하고 테스트하다 보니 append 메서드를 호출하다 OOM에러를 뱉으면서 어플이 종료되었습니다. 문제는 append 메서드를 호출 시 StringBuilder의 capacity를 넘을 경우 내부적으로는 메모리 재할당과 copy과정이 일어난다는 것이었습니다. 그렇다고 초기 StringBuilder생성시 capacity를 무작정 높게 잡기도 애매한 상황이었습니다.gsongson은 Java객체를 json형식으로 변환하고 그 역으로도 변환할 수 있도록 도와주는 라이브러리입니다. gson의 사용법이 궁금하다면 gson user guide를 읽어보면 되고 api가 궁금하다면 gson api document를 참조하면 됩니다.gson 적용대략 이런 방식으로 프로젝트에 gson라이브러리를 적용하였고, HttpURLConnection을 통해 받아온 InputStream을 이용 바로 객체를 생성할 수 있었습니다. 이전에 StringBuilder를 이용할때 생기는 오버헤드가 사라진 셈이죠. 위와 같은 방식으로 OOM이 생기는 문제 상황을 해결 할 수 있었습니다.위의 예는 상황을 최대한 단순화하여 설명하려고 작성한 예제이고 이 사이트를 통해 더 상세하게 설명된 사용예를 보실 수 있습니다.#스포카 #개발 #개발자 #GSON #Java #인사이트 #google_gson

기업문화 엿볼 때, 더팀스

로그인

/