스토리 홈

인터뷰

피드

뉴스

조회수 1457

스푼 라디오 안드로이드 개발자 Yong을 소개합니다!

 정말 좋아하는 일을 하면, 주말 또는 정해 놓고 쉬는 날이 없습니다. 어디선가 호탕한 웃음소리가 나면 백발백중 'Yong'의 웃음소리라는 것을 안다. 듣는 다른 이 또한 웃게 만드는 매력적인 웃음의 소유자 안드로이드 개발자이자 클라이언트팀의 리더 용을 지금 소개합니다.호탕한 웃음의 원천이요?"저는 기본적으로 일을 즐겁게 하자 라는 생각으로 일을 합니다. 함께 웃으면서 일하면 서로 함께 기분이 좋아지잖아요! 그게 저의 호탕한 웃음의 원천인 것 같습니다. 다른 분들께 매력적으로 보인다는 것은 처음 알았네요 :) 그리고 저는 원래 웃음이 많은 사람입니다"듣고 싶은 당신의 스푼 라이프클라이언트팀이 궁금합니다."클라이언트 팀은 세 파트로 나뉘어있습니다. IOS, AOS 그리고 Web입니다. 저희 팀은 다른 많은 부서들과 긴밀한 협업을 통해 제품에 대한 틀을 정의하고 프로그래밍이라는 구현 작업을 통해 제품을 만들어 사용자들에게 가치를 전달하고 있습니다. 저희는 사용자들에게 제품을 이용하는 편의성을 제공하며 사용자 상호 간의 소통의 창구적인 역할을 하게 됩니다. 또한, 사용자들의 다양한 행위를 통해 스푼은 사용자들에게 재미, 감동, 그 이상의 의미를 전달합니다. 결과적으로 사용자들이 인식하고 보고 느끼는 모든 것이자 스푼의 가치를 전달하는 최종적인 결과물이라고 할 수 있겠습니다. 그리고 저는 현재 팀에서 클라이언트 팀 리더이자 안드로이드 개발을 담당하고 있습니다."개발자 그리고 팀 리더가 되기까지"저는 원래 전공이 하드웨어 분야였습니다. 사실 원대한 꿈은 없었지만 제 스스로가 이공계에 마땅한 사람이라는 것은 알 고 있었어요. 하드웨어와 소프트웨어 가리지 않고 무언가를 개발하는 것을 좋아한다는 걸 알았거든요. 제가 진로를 선택했을 땐 안드로이드 개발이 구현되기 전이었어요. 그래서 서버랑 클라이언트(윈도우)이 둘 중에 진로를 선택해야 했었고 첫 회사에서 UI 쪽으로 업무를 시작하게 되었어요. 사실 애초 UX/UI에 관심이 많았고 적성에 맞다는 걸 느꼈어요. 제가 만든 제품을 누군가가 사용하는 것을 육안으로 보고 싶었거든요. 개발은 정말 보람된 일이자 저에게 자부심이기도 합니다.개발자로서 코딩만 하다가 팀 리더가 되어보니, 리더가 정말 힘든 일이라는 것을 알았어요. 어쩌면 코딩보다 더 어려운 일인 것 같아요. 상대방을 이해하고, 또 이해시키고 공감해야 하니까요. 제가 일을 하면서 가장 행복할 때는, 함께 한다는 느낌을 받을 때인 것 같습니다. 예를 들어서 아이디어 회의를 할 때 모두가 같은 마음으로 함께 이루어간다고 생각이 들 때가 가장 뿌듯하더라고요."함께 일하고 싶은 사람 저는 솔직한 사람을 좋아합니다. 본인의 생각을 진솔하게 이야기하고, 공감대를 잘 형성할 수 있는 사람이요. 결국 일은 사람과 사람이 함께 하니까요.  알고 싶은 Yong의 이야기나를 표현하는 한마디 - '바람'저는 자유로운 사람이 되고 싶어요. 바람처럼 유유자적하면서, 무언가 하고 싶은 것이 있을 때 자유롭게 즐길 수 있으며, 구속받지 않는 삶을 살고 싶습니다.나만의 스트레스 해소법"제가 게임을 정말 좋아해요. 거의 모든 온라인 게임은 다 했던 것 같아요. 와우, 블리자드, 배그, 오버워치 등등 정말 많이 했는데 사실 지금은 잘 안 하는 것 같아요. 예전에 마케팅팀 테드랑 주말마다 함께 온라인에서 만나서 게임을 했었는데 테드가 결혼하고 저도 아이와 함께 시간을 보내다 보니 점점 게임을 안 하게 되더라고요. 게임을 왜 좋아하냐고요? 일단 재미있잖아요! 그리고 스트레스 푸는데 아주 좋아요. 게임에 몰두하고 나면 잡생각이 없어지거든요. 게임도 개발과 비슷해요. 온전히 집중해서 하지 않으면 모든 게 틀어지거든요. 게임은 집중력 향상에도 굉장히 좋습니다!"개발은 '예술'과 같아요 "주말에 집에서 일하는 이유요? 일이 많아서나 해야 해서 하는 것은 아니에요. 단지 자유롭게 하고 싶을 때 하는 편입니다. 좋아하고 즐거운 일이니까요! 개발은 하나의 예술이라고 생각합니다. 화가가 요일을 정해놓고 그림을 그리지 않는 것처럼 개발자도 똑같아요. 좋아하는 일을 한다면 그건 일이 아니라고 생각이 들거든요. 저에게 개발은 그렇습니다. 제게 개발은 재미있는 하나의 예술과 같아요"Yong은1. 사진, 그림, 음악 등 예술에 관심이 아주 많습니다!(피아노 독주회, 전시회에 종종 가신다고 합니다. 특히나 클래식과 재즈를 좋아합니다)2. 가리는 음식은 없지만, 한식류를 좋아합니다!팀원들이 Yong을 한마디로 표현한다면?Edward Jung 曰: 웃지만 무서운 관리자 - “언제나 웃음으로 대하시지만 내가 웃는 게 웃는 게 아니야라고 느껴짐…”Julia Na 曰: 행복한 리더 - "호탕한 웃음소리가 트레이드 마크. '행복하세요'라고 말하며 팀원들에게 긍정기운을 전파합니다."Michael Chung 曰: 따뜻한 마음을 가진 개발자 - “팀원들 하나하나 직접 챙기기 때문”Roy Choi 曰: 온화한 아버지 - "개발 실력은 기본, 팀원들을 챙기며 일정 조율 및 커뮤니케이션 능력까지 겸비한 그는 클라이언트팀의 아버지"Raymond Hong 曰: 허허실실 웃음 가득 리더 - "꼼꼼히 팀원과 프로젝트를 챙기기 때문"
조회수 757

HBase상 트랜잭션 라이브러리 Haeinsa를 소개합니다 - VCNC Engineering Blog

비트윈에서는 서비스 초기부터 HBase를 주요 데이터베이스로 사용하였습니다. HBase에서도 일반적인 다른 NoSQL처럼 트랜잭션을 제공하지 않습니다. HBase, Cassandra와 MongoDB는 하나의 행 혹은 하나의 Document에 대한 원자적 연산만 제공합니다. 하지만 여러 행에 대한 연산들을 원자적으로 실행할 수 있게 해주는 추상화된 트랜잭션 기능이 없다면 보통의 서비스 개발에 어려움을 겪게 됩니다. 비트윈 개발팀은 이런 문제를 해결하기 위해 노력했으며, 결국 HBase에서 트랜잭션을 제공해주는 라이브러리인 Haeinsa를 구현하여 실제 서비스에 적용하여 성공적으로 운영하고 있습니다. VCNC에서는 Haeinsa를 오픈소스로 공개하고 이번 글에서 이를 소개하고자 합니다.Haeinsa란 무엇인가?Haeinsa는 Percolator에서 영감을 받아 만들어진 트랜잭션 라이브러리입니다. HAcid, HBaseSI 등 HBase상에서 구현된 트랜잭션 프로젝트는 몇 개 있었지만, 성능상 큰 문제가 있었습니다. 실제로 서비스에 적용할 수 없었기 때문에 Haeinsa를 구현하게 되었습니다. Haeinsa를 이용하면 다음과 같은 코드를 통해 여러 행에 대한 트랜잭션을 쉽게 사용할 수 있습니다. 아래 예시에는 Put연산만 나와 있지만, 해인사는 Put외에도 Get, Delete, Scan 등 HBase에서 제공하는 일반적인 연산들을 모두 제공합니다.HaeinsaTransaction tx = tm.begin(); HaeinsaPut put1 = new HaeinsaPut(rowKey1); put1.add(family, qualifier, value1); table.put(tx, put1); HaeinsaPut put2 = new HaeinsaPut(rowKey2); put2.add(family, qualifier, value2); table.put(tx, put2); tx.commit(); Haeinsa의 특징Haeinsa의 특징을 간략하게 정리하면 다음과 같습니다. 좀 더 자세한 사항들은 Haeinsa 위키를 참고해 주시기 바랍니다.ACID: Multi-Row, Multi-Table에 대해 ACID 속성을 모두 만족하는 트랜잭션을 제공합니다.Linear Scalability: 트래픽이 늘어나더라도 HBase 노드들만 늘려주면 처리량을 늘릴 수 있습니다.Serializability: Snapshot Isolation보다 강력한 Isolation Level인 Serializability를 제공합니다.Low Overhead: NoSQL상에서의 트랜잭션을 위한 다른 프로젝트에 비해 오버헤드가 적습니다.Fault Tolerant: 서버나 클라이언트가 갑자기 죽더라도 트렌젝션의 무결성에는 아무 영향을 미치지 않습니다.Easy Migration: Haeinsa는 HBase를 전혀 건드리지 않고 클라이언트 라이브러리만 이용하여 트랜잭션을 구현합니다. 각 테이블에 Haeinsa 내부적으로 사용하는 Lock Column Family만 추가해주면 기존에 사용하던 HBase 클러스터에도 Haeinsa를 쉽게 적용할 수 있습니다.Used in practice: 비트윈에서는 Haeinsa를 이용하여 하루에 3억 건 이상의 트랜잭션을 처리하고 있습니다.Haeinsa는 오픈소스입니다. 고칠 점이 있다면 언제든지 GitHub에 리포지터리에서 개선에 참여하실 수 있습니다.Haeinsa의 성능Haeinsa는 같은 수의 연산을 처리하는 트랜잭션이라도 소수의 Row에 연산이 여러 번 일어나는 경우가 성능상 유리합니다. 다음 몇 가지 성능 테스트 그래프를 통해 Haeinsa의 성능에 대해 알아보겠습니다.아래 그래프는 3개의 Row에 총 6개의 Write, 3개의 Read연산을 수행한 트랜잭션의 테스트 결과입니다. 두 개의 Row에 3Write, 1Read 연산을 하고, 한 개의 Row에 1Read 연산을 한 것으로, 비트윈에서 가장 많이 일어나는 요청인 메시지 전송에 대해 시뮬레이션한 것입니다. 실제 서비스에서 가장 많이 일어나는 종류의 트랜잭션이라고 생각할 수 있습니다. 그런데 그냥 HBase를 사용하는 것보다 Haeinsa를 이용하는 것이 더 오히려 좋은 성능을 내는 것을 알 수 있습니다. 이는 Haeinsa에서는 커밋 시에만 모든 변경사항을 묶어서 한 번에 반영하기 때문에, 매번 RPC가 일어나는 일반 HBase보다 더 좋은 성능을 내는 것입니다.HBase 클러스터가 커질수록 트랜잭션 처리량이 늘어납니다. HBase와 마찬가지입니다.HBase 클러스터의 크기에 따른 응답시간 입니다. HBase와 다르지 않습니다..아래 그래프는 2개의 Row에 각각 한 개의 Write, 나머지 한 개의 Row에는 한 개의 Read 연산을 하는 트랜잭션에 대해 테스트한 것입니다. 각 Row에 하나의 연산만이 일어나기 때문에 최악의 경우라고 할 수 있습니다. 처리량과 응답시간 모두 그냥 HBase를 사용하는 것보다 2배에서 3배 정도 좋지 않은 것을 알 수 있습니다. 하지만 이 수치는 DynamoDB 상의 트랜잭션과 같은 다른 트랜잭션 라이브러리와 비교한다면 상당히 좋은 수준입니다.HBase보다 처리량이 떨어지긴 하지만, 클러스터가 커질수록 처리량이 늘어납니다.HBase보다 응답시간이 크긴 하지만 클러스터 크기에 따른 변화가 HBase와 크게 다르지 않습니다.프리젠테이션Haeinsa에 대한 전반적인 동작 원리와 성능을 소개하는 프리젠테이션입니다. 좀 더 자세히 알고 싶으시다면 아래 프리젠테이션이나 Haeinsa 위키를 참고해주세요.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/2d4b2bd00fc201314ae312fe4cd13937?" 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;">
조회수 873

[Buzzvil People] Jin Yoon, Product Manager

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요. 버즈빌의 여러 Product 중 하나인 버즈스크린(BuzzScreen)을 담당하고 있는 Product Manager, Jin 입니다. 요즘에는 사무실에서 알파카 or 라마를 닮았다는 흉흉한 소문이 퍼지면서 이름 대신 불리기도 합니다. 첫 사회생활은 Oil & Gas industry의 한국 대기업에서 시작했습니다. 쉽게 얘기하면 세계 곳곳 석유가 묻혀있는 곳에 그 석유를 캐내고 정제하는 공장을 지어주는일이죠. 몇억 불에 달하는 프로젝트 전반을 관리하는 Project Management가 저의 role이었습니다. 그 후에는 모바일광고, pet food ecommerce, 음식 배달 등 한국/미국의 작은 스타트업에서 일하다가 버즈빌에 조인하게 됐습니다.  2. 어떻게 버즈빌에 오시게 되셨나요? 가장 보수적인 industry의 가장 한국적인 대기업이었던 첫 회사를 그만두고 MBA를 하면서 크게 3가지에 초점을 맞춰 진로를 찾았습니다.  빠르게 변화하는 industry 나의 transferable skill을 사용할 수 있는 position 조금 더 자유로운 분위기에서 일할 수 있는 환경  찾다보니 그 industry는 IT였고, Project Management 에서 나름 배웠던 skillset을 사용할 수 있는 포지션은 여러 가지가 있었지만, Product Manager가 가장 가깝다고 생각했습니다. 자유로운 분위기는 미국에 있는 여러 tech giant 들, 그게 아니라면 스타트업이라는 생각이 확고했고요. 그렇게 들어간 곳이 LA에 있는 작은 스타트업이었습니다. 총 4명 정도의 작은 회사였기 때문에 1년여간 일하면서 마케팅, 기획 등 여러 가지 일들을 배울 수 있었고 개발적인 부분도 일부 배울 수 있었습니다. 하지만 tech 회사라고 하기에는 개발인력도 많이 부족했고, 조금 더 배울 수 있는 곳을 찾다 보니 버즈빌에도 지원하게 되었습니다. 버즈빌에 오기로 결정하게 된 가장 큰 이유는 버즈빌이 인터뷰를 진행하는 방식이였습니다. 3차례의 인터뷰를 보면서 굉장히 재미있었거든요.  PM면접은 1, 2차 두 번 다 과제가 있었고, 타이트한 데드라인에 맞춰 준비하면서 긴장도 많이 하고 엄청난 부담감을 갖고 인터뷰에 들어갔는데… 하지만 막상 인터뷰에서는 제가 해온 과제를 평가받는 게 아니라 “이 문제를 조금 더 잘 풀기 위해서 어떻게 할 수 있을까?”를 같이 머리를 맞대고 자유롭게 얘기하면서 고민하다가 시간이 가더라고요. CEO, CPO와 보는 인터뷰가 이런 거라면 “일할때도 내 생각을 자유롭게 얘기하면서 같이 일할 수 있겠구나” 라는 느낌을 강하게 받아서 조인하기로 결정했습니다. Interviewer로 참석했던 Jay 와 Young이 보여준 “만담” 도 한 몫했습니다.  3. 버즈빌에서 어떤 업무를 담당하고 계신가요? 버즈스크린이라는 Product의 Product Manager 역할을 하고 있습니다. 간단하게 얘기해서 supply side인 파트너사들과 유저의 니즈, 시장의 상황 등을 반영하여 로드맵을 짜고, 그 로드맵에 맞춰 프로덕트를 발전시키고 개선하는 역할이라고 할 수 있겠네요.  특히 버즈스크린은 SDK 상품이다 보니 파트너사와 interaction이 많은 편입니다. 파트너사와 정기적인 미팅을 통해 개선점을 발굴하고 필요한 기능들을 제품에 녹여내기도 합니다. 하지만 한국뿐만 아니라 외국의 여러 파트너사도 하나의 공통된 Product를 사용하기 때문에 너도, 나도 원하는걸 다 세세하게 전부 들어줄 수 없습니다. 그렇게 되면 결국 더는 관리 할 수 없는 Product이 될수 있기 때문이죠. 무엇이 정말 Product의 발전을 위해 필요한것인지, 어떻게 하면 Product의 sustainability를 해치지않고 유저와 파트너사들을 만족시킬 수 있는지 생각을 많이 해야 하는 포지션인 것 같습니다. 또 내부적으로는 Business의 호흡과 Development의 호흡을 조절하는 역할을 담당해야 합니다. 현재 상황을 놓고 생각해봤을 때 어느 한쪽이 너무 빠르거나 느리게 달려간다고 생각할때는 속도를 조절하고, 이에 맞춰 counterpart의 기대치를 조정하는 역할을 해야합니다. 이를 통해 개발자들이 쫓기지 않고 개발할 수 있는 환경을 마련해주어야 하고 사업 담당자들이 파트너사에 적절하게 대응할 수 있는 환경도 마련해주어야 하고요. 결국 각 분야에서 전문성을 가진 사람들이 자신들의 역량을 가장 잘 발휘할 수 있도록 그 일에만 집중할 수 있게 만드는 일을 하고 있다고 (혹은 해야 한다고..) 생각합니다. 4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 스타트업에서 일하는 건 정말 힘든일인 것 같아요. 하지만 힘든 만큼 나름 재미도 있고 보람도 느끼면서 일하고 있어요. “힘들다”는 사실이 큰 장점이 될 수도 있는 곳이 스타트업인것 같습니다. 대기업에서 일했던 경험과 비교해보면 스타트업은 확실히 프로세스가 덜 갖춰져 있습니다. 그러다 보니 프로세스에서 보완될 수 있는 부분들에까지 리소스가 들어간다는 점, 회사에서 이탈하는 한명 한명의 빈자리가 상대적으로 크다는점은 단점이라고 할 수 있을 것 같네요. 하지만 바꿔서 생각해보면, 정해진 프로세스가 없다 보니 자유도가 높고, 일의 진행속도도 빠릅니다. 부서 간에 scope of work를 놓고 논쟁하지 않고, 모두 달려들어 일을 끝낼 수 있는 가장 빠른 방법을 찾아 끝내고, 그 과정에서 내가 할 수 있는 일을 스스로 찾아서 할 수 있는 것도 굉장히 흥미롭습니다. 또한 회사 구조적으로도 이것저것 새로운 시도들을 하는 것도 재미있습니다. 대기업에 있을 때는… 이미 다 채색까지 완성된 그림이 있고 그 위에다가 계속해서 정해진 같은 색으로 조금씩 점을 찍고 있는 느낌이 들었다면, 스타트업에서는 그야말로 스케치만 되어있는 도화지에 그림을 그리는 느낌이 듭니다. (물론 이건 스타트업에서 일하는 느낌이 아니라 버즈빌에서 일하는 느낌일 수도…) 누가 그리느냐에 따라 초등학생의 낙서가 될 수도 있고, 유명한 화가의 명작이 될 수도 있겠지만요. 그 과정은 정말 정말 힘들지만, 회사의 성장에 기여한다는 보람도 느낄 수 있고, 나도 성장할 수 있는 환경이라고 할 수 있겠네요.  욕심 없이 편안하게 주어진 일만 하면서 살고 싶은 분들에게는 스타트업에서 일하는 게 정말 지옥 같고 힘든 일이 될 것 같네요. (지극히 개인적인 의견입니다.) 5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요? 버즈빌은 그야말로 인사가 만사다 라는 말에 딱 들어맞는 회사입니다. 이 사람들과는 어떤 일을 해도 성공할 수 있겠다는 생각을 하게 하는 분들만 모여있는 것 같아요. 제가 힘들 때마다 Steve가 항상 “지금은 공기처럼 당연해서 크게 느껴지지 않겠지만 지금처럼 좋은 사람들과 함께 일할 수 있는 환경은 드물다”라고 하시는 데 공감하지 않을 수 없습니다.  특히 제가 입사한 지 한 달이 채 안 되었을 때 외부적인 요인으로 회사가 힘든 상황에 놓인 적이 있었는데, 각자 할 수 있는 분야에서 최고의 능력을 발휘해서 위기를 넘기는 모습은 짧은 기간에 버즈빌리언들의 뛰어난 개개인의 역량을 느낄 수 있었던 좋은 기회였던 것 같습니다. 업무 외적으로도 좋은 사람들과 일하고 있다는 것을 실감하고 있습니다. 점심시간마다 (낮잠을 포기하고) 탁구를 치거나 게임을 할 때마다 제 부족한 탁구/게임 실력을 걱정해주기도 하고, 실력 향상을 위한 진심 어린!! 조언도 아끼지 않습니다. 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 한마디로 얘기하자면 최고의 2인자가 되는게 꿈입니다. 다른 사람들 앞에 나서지도 않고 조명도 받지 않지만 “이 사람과 함께라면 어떤일도 다 성공할 수 있어” 라는 생각이 들게끔 만드는 사람이 되는 것..이라고나 할까요.. 어릴때는 막연하게 “다른 사람들을 돕는일을 하고 싶다” 라는 생각을 갖고 살았던것 같아요. 평범한 학창시절을 보내고, 대학에 가고, 취업을 하면서 마음 한켠으로 치워두게된.. 그냥 그정도의 생각이었죠. 처음 다니던 회사를 그만두고 나는 평생 어떤 일을 하면서 살아야할까 라는 원론적인 고민을 하게 되었고, 그때 이 생각을 다시 한번 바라보게 된것같아요. 그러다가 기회가 닿아 MBA에 가게 되고 지금까지 만나보지 못했던 사람들을 만나면서 한때는 막연했던 이 생각을 조금 더 구체화시킬 수 있었습니다.  최고의 2인자가 되는 첫번째 step으로.. 우선 주변에 아이디어만 있고 실행으로 옮기고싶은데 어떻게 할 수 있는지를 몰라서 헤매는 친구들에게 작게나마 도움이 되고 싶습니다. 엔젤 투자자나 인큐베이터보다 조금 더 깊게 사업에 참여하고 실질적인 업무를 도와주며 같이 일하고 문제를 해결하면서 그 친구들의 아이디어를 실현하는데 일조하고 싶어요. 지금 버즈빌에서 지금 하고 있는 일이 이와 크게 다른 것 같지 않습니다. PM으로써 하나의 프로덕트를 기획하고 만들고 운영하는 게 결국은 하나의 작은 사업을 시작하는것이라고 생각합니다. 프로덕트를 만드는 과정에서 필요한 일들을 챙기고 처리하고 또 그 과정에서 고통스러워하고 즐거워하다보면, 아이디어를 구체화 시키면서 필요한 일들을 직/간접적으로 경험할 수 있겠죠. 그렇게 저를 잘 단련시키다보면 결국 제가 이루고자 하는 꿈에 다가갈수 있지 않을까요. *버즈빌의 채용공고(전문연구요원 포함)를 확인하고 싶으면 아래 버튼을 눌러주세요!
조회수 1887

빠른 프로토타이핑을 위한 도구 소개

새로운 아이디어를 검증하는 방법은 여러 가지가 있습니다. 비슷한 도구들을 사용하면서 간접체험을 해보기도 하고, 종이, 혹은 목업 도구를 활용한 프로토타입을 만들어보기도 합니다.스포카 팀은 새로운 아이디어를 검증하기 위해 더욱 직접적인 프로토타입을 만들어야 했습니다. 매장에서의 오프라인 경험에서부터 Facebook, Twitter 등의 온라인 경험까지 이어지는 총체적인 경험 선을 시험하기 위해선 실제로 어느 정도 동작하는 프로토타입을 만드는 것이 제일 확실하였기 때문이죠.하지만 막상 그럴싸하게 동작하는 프로토타입을 만드는 것은 생각보다 시간이 오래 걸리는 일입니다. 최소의 UI 디자인, 빠른 기능 개발, 배포 환경이 제대로 준비되어있지 않다면 실제로 유효한 수준까지 만드는 것이 많은 시간이 필요하게 될 것입니다.스포카 팀은 아이디어가 떠오를 때 어떻게 하면 그것을 빠르게 구현해서 확인할 수 있을지에 대해 많이 고민하였습니다. 그러면서도 해당 아이디어가 좋을 때 제대로 된 서비스로 확장하거나 기존 기능에 통합하는 것도 수월하게 가능하다면 더 좋겠지요. 이번 글에서는 제대로 작동하면서 확장성도 고려한 고 수준의 프로토타이핑을 빠르게 할 수 있게 도와주는 도구들을 모두 소개해보고자 합니다.어떤 언어를 고를까?특별히 교육의 목적이 있는 것이 아니라면 언어는 자신이 가장 잘 활용할 수 있게 미리 교육된 언어가 효과적입니다. 새로운 언어를 공부하면서 프로토타이핑을 한다면 지엽적이고 모르는 문제에 부딪혀 시간을 허비하는 상황이 많아 프로토타이핑 속도가 지연되기 쉽기 때문입니다. 다만 컴파일 가능한 언어와 불가능한 언어 중 선택해야 한다면 대부분 컴파일 과정이 필요없는 언어를 선택하는 것이 큰 효과를 경험하실 수 있습니다.스포카 팀은 서버 개발에 Python을 주 언어로 활용하며, 그 외에 Ruby나 Node.js 같은 언어도 추천합니다.마이크로 프레임워크를 활용하자규모가 커지면 구조에 손을 대야 하지만, 다양한 기능을 빨리 구현해서 넣고자 할 때 마이크로 프레임워크로 시작하는 것이 좋습니다. 간편하면서도 초기 구조를 아주 간결하게 들고 갈 수 있기 때문입니다.웹 서비스나 앱 서비스의 서버로 이용할 HTTP 프로토콜 서버를 구축한다면 Sinatra 스타일의 마이크로 프레임워크를 활용하는 것이 효과적입니다.아래는 주요 언어에서 볼 수 있는 마이크로 프레임워크입니다. 이 외에도 Sinatra style microframework을 검색해보시면 여러 언어에서 비슷한 형태로 구현된 마이크로 프레임워크를 보실 수 있습니다.Sinatra (Ruby)Flask (Python)Express (Node.js)스포카팀에서는 Flask를 즐겨쓰고 있습니다. Flask에 관심이 있으시다면 지난 기술 블로그의 소개글을 참조해주세요.디자인을 빠르게 하는 툴킷들기본적인 기능들을 빠르게 구현하였다면 이를 활용할 사용자 인터페이스를 만들어야 합니다. 하지만 웹 서비스나 웹뷰를 기반으로 하는 서비스를 만든다면 HTML/CSS/JS 기반의 디자인을 하는 일도 상당히 시간이 많이 필요한 일입니다. 이 때, 각 목적에 맞는 툴킷들을 이용한다면 디자인을 크게 고민하지 않으면서도 보기 좋은 서비스를 만들어 볼 수 있습니다.Bootstrap from Twitter는 디자인에 대한 여러 가지 기초적인 고민을 상당히 잘 흡수해주는 훌륭한 툴킷입니다. 크로스 브라우징을 지원하며, 우리가 쓰는 컴포넌트 대부분에 대해 심미적으로, 기능적으로 우수한 디자인을 제공합니다. 그리드 인터페이스를 제공해서 레이아웃도 간편하게 잡을 수 있으며, 곧 출시 예정인 2.0에선 반응형 디자인도 정식으로 지원하고 있습니다.Bootstrap은 LESS로도 제공해주기 때문에, 디자인 튜닝이 간편하고 Mixin을 활용해 의미적인 HTML 마크업을 하면서 디자인을 적용할 수도 있습니다.위의 툴킷과 같은 인터페이스를 가지고 디자인만 Facebook 형태로 바꾼 Fbootstrapp도 있습니다. Facebook 앱을 만든다면 이쪽을 쓰시는 편이 더 좋을 것 같습니다.터치 환경에 한정한 서비스를 디자인 중이라면 범용성이 조금 떨어지지만 jQuery Mobile을 추천합니다. 여러 기기의 웹뷰 환경을 지원하는 다양한 컴포넌트를 제공하고 있습니다.서비스를 최대한 쓰기모든 기능을 직접 전부 구현할 필요는 없습니다. 여러 회사에서 한 두 줄의 추가만으로 사용할 수 있는 서비스를 제공하고 있습니다. Google은 특히 Maps API, Chart Tools, QR Code, Font API 등 개발에 도움이 되는 수많은 기능들을 간단한 API로 쓸 수 있게끔 공개하고 있으며, Facebook 또한 소셜 플러그인으로 다양한 소셜 도구들(Like Button, Comments, Registration 등)을 제공하고 있습니다. 이런 서비스들을 잘 알고 있다면 가끔은 단지 여러 서비스 기능을 연결하는 것만으로 새로운 서비스를 만들 수 있기도 합니다.서비스 배포는 Platform as a Service(PaaS)를 활용하자위 도구의 협력으로 서비스를 만들었다면 이제 배포를 해야 합니다. 어디서나 접근할 수 있는 공용 서버에 서비스를 올리고, 서버를 세팅하고, 도메인을 연결해야 합니다. 이 과정들 또한 시간을 많이 필요로 하는 일들입니다.최근 Heroku를 시작으로 미국에서 Amazon Web Service를 기반으로 한 많은 Platform as a Service가 출시되고 있습니다. 이 서비스들은 대체로 Failover System, 쉬운 서비스 규모 스케일링, 잘 설계된 서버 스택, 편리한 배포환경을 강점으로 내세우고 있으며, 특히 처음 사용자가 가입부터 서비스 배포까지 아주 간편하고 빠른 속도로 진행할 수 있게끔 도구를 제공하고 있습니다. 게다가, 대부분 무료 플랜이 존재하기 때문에 비용 부담이 없다는 장점도 가지고 있습니다.Heroku의 서비스 배포 과정을 보시면 그 과정이 얼마나 편리한지 쉽게 알 수 있습니다.$ heroku createCreated sushi.herokuapp.com | [email protected]:sushi.git$ git push heroku master-----> Heroku receiving push-----> Rails app detected-----> Compiled slug size is 8.0MB-----> Launching... done, v1http://sushi.herokuapp.com deployed to Herokuview rawgistfile1.sh hosted with ❤ by GitHub단 두 줄로 git에 의해 관리되는 애플리케이션을 서버에 배포하고 접근 URL을 받았습니다.아래는 다양한 플랫폼에서 쉽게 이용 가능한 PaaS 목록입니다.저장소 이용아무리 빠르게 하고 싶다고 해도 저장소는 두고 하세요. 개인이 작업하는 것이라면 로컬에서도 저장소 관리가 가능한 분산형 버전관리 시스템 (git, mercurial)로 바로 이용하시고, 2명 이상이 동시에 작업한다면 반드시 저장소 호스팅 서비스를 이용해서 작업하시기 바랍니다. 변경사항을 공유하는 방법에 대해 버전관리 시스템보다 빠르고 깔끔한 방법은 아직까진 없기 때문입니다.저장소 호스팅은 많은 곳에서 제공해주고 있지만, 돈을 조금 투자해서 Github를 쓰시는 것을 추천해 드립니다. 저장소뿐만이 아닌 훌륭한 협업 플랫폼을 제공해주고 있기 때문입니다. 당장은 무료로 시작해야 한다면 Bitbucket의 무료 비공개 저장소를 이용하는 것도 좋은 방법니다.실제 케이스아래는 최근 사내에서 이루어진 아이디어 서비스 프로토타이핑이 이루어진 과정을 나열해보았습니다.Github에 저장소 생성. 팀원들에게 전달한 명은 Flask로 서버 사이드 개발QR코드 생성이 필요한 부분을 Google API로 해결한 명은 Bootstrap from Twitter로 뷰 작업을 진행작업이 되는대로 Github, Heroku에 배포개발에 필요한 시간은 약 5시간 정도였으며, 사실 이 기간은 그 이전에 해당 아이디어의 가치에 대해 토론하는 데 쓴 시간과 비슷한 시간이었습니다. 토론에선 답이 나오지 않은 채로 끝났지만, 프로토타입을 이용해보고 답을 내는 것은 그리 오랜 시간이 걸리지 않았습니다.마치며실용 가능한 프로토타이핑은 앱의 첫인상과 인터페이스 전반에 대한 이해를 넘어 아이디어의 가치평가를 확신할 수 있는 좋은 방법입니다. 우리가 토론에서 의견이 많이 갈리는 이유는 사실 보지 못한 것에 관해 이야기하기 때문인 경우가 많아서, 만약 토론하는 시간보다 더 짧은 시간 안에 말하는 것을 볼 수 있다면 의사 결정을 더 빠르고 정확하게 할 수 있습니다. 이 글은 그 방법에 대해 구체적으로 설명하였습니다.이번에 소개한 도구와 방법은 단지 돌아가는 것을 확인하는 것을 넘어 장기적인 확장성도 갖추고 있습니다. 언급한 언어들 모두 대형 서비스에서 실제 이용 중인 언어들이며, 마이크로 프레임워크들도 모두 커지는 구조에 대한 대응법을 준비하고 있습니다. 디자인은 Bootstrap의 일부 코드를 재작성하거나 튜닝하는 것으로 서비스에 최적화시킬 수 있으며, PaaS는 애초에 Fast scaling이 주요 강점이기 때문에 손쉽게 커지는 서비스의 사용량에 유연하게 대처할 수 있습니다.새로운 아이디어를 준비하고 계신다면, 이 글에서 소개한 도구들을 십분 활용하여 빠르게 실용할 수 있고, 확장 가능한 프로토타입을 반복해서 만들어 보시는 것을 적극 추천해 드립니다.#스포카 #개발 #개발자 #꿀팁 #스킬스택 #스택소개 #조언
조회수 1604

HBase 설정 최적화하기 - VCNC Engineering Blog

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다. hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다. HBASE_HEAPSIZE = 61440 #(60GB) HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.
조회수 2165

스켈티인터뷰 / 스켈터랩스의 N잡러 엄단희 님을 만나보세요:)

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 N잡러 엄단희 님을 만나보세요:)사진1. 스켈터랩스의 N잡러 엄단희 님Q. 자기소개를 부탁한다.A. 스켈터랩스에 입사한 지 이제 8개월 정도 된 신입 소프트웨어 엔지니어, 엄단희다.Q. 스켈터랩스에서 어떤 업무를 맡고 있는가.A. 현재는 아이리스(Iris) 팀에 소속되어있다. 아이리스 팀은 맥락 인식(Context Recognition) 기술을 기반으로 SDK를 비롯한 여러가지 서비스 출시를 준비하고 있는데, 사실 지금은 레고(L.ego)팀이 준비하는 신제품인 스마트 미러 샘(Samm) 개발 업무가 주요 업무이다. 샘은 스켈터랩스가 가지고 있는 맥락 인식 기술 뿐만 아니라 음성, 얼굴, 제스처 인식을 비롯한 대화형 엔진이 모두 집약된 인텔리전트 디바이스(Intelligent Device)다. 여러 기능이 하나의 디바이스에 구현된 만큼, 샘은 다양한 모듈로 나누어져있다. 예를 들어 센서 정보를 모으는 모듈과 그 정보를 처리하는 모듈, 처리한 내용을 보여주는 UI 모듈 등이 있는데, 나는 이러한 모듈들을 gRPC 또는 bluetooth 등을 통해 서로 통신할 수 있도록 해주는 작업을 주로 진행했다. 최근에는 샘의 구매자에게 필요한 샘 어플리케이션 개발을 진행하고 있다. 아이리스 팀 관련해서는 파이어베이스(Firebase) 관련 작업을 서포트한 적이 있고, 얼마 전에는 스켈터랩스 웹사이트 개발에 참여하기도 했다.Q. 맡고 있는 업무의 가짓수가 많아 보인다. 한번에 여러 개의 프로젝트를 진행하는 것이 어렵진 않나.A. 쉽다고 말하기는 힘든 것 같다. 여러 업무에서 동일한 지식이 요구될 때도 있지만, 기본적으로 하나의 일을 처리하기 위해 집중하고 있다가 다른 업무로 전환할 때, 그 업무를 위한 나의 베이스를  바꾸는 등의 일들이 녹록치 않다. 처음에는 무엇보다 일의 우선순위를 정하는 것이 가장 버거웠다. 사실 업무마다의 기한이 정해져 있으면 당연히 급한 업무를 먼저 처리할텐데, 우리 회사는 그보다는 본인이 직접 업무량을 조정해서 기한을 정하고 처리하는 편이다. 그래서 하나의 일을 쪼개고 쪼개어, 그 중에서도 가장 빨리할 수 있는 일부터 먼저 처리하는 나만의 업무 프로세스를 만들고 있다. ‘빨리 할 수 있는 일'이라고 해서 마냥 쉬운 일을 말하지는 않는다. 그 때마다 내게 가장 맞는 일, 내가 가장 준비되어 있는 일을 자연스럽게 추려내어 업무 효율을 높이려고 한다.Q. 스켈터랩스에 어떻게 입사하게 되었는지 궁금하다.A. 재작년, 앤드비욘드라는 회사에서 인턴으로 근무했다. 당시 스켈터랩스가 앤드비욘드와 함께 개발중이던 스마트 포스(POS)기, GABE 프로젝트를 진행하며 한남동에서 같은 사무실을 쓰고 있었다. 그 프로젝트 팀에서 파견직처럼 일을 하게 되었는데, 가장 놀란 점은 ‘사람'이었다. 이렇게 누구 하나 빠짐 없이 개발을 잘하는 사람들이 모여있는 곳에서 개발하는 것은 처음이었다. 학교에서는 나름 ‘나도 잘하는 편이지 않을까’ 생각했는데 여기 와서 한없이 부족하다는 걸 깨달았다. 그런데 그렇게 부족한 신입 인턴임에도 불구하고 모두가 나를 평등하게 대해주셨고 개발 관련해서도 많이 배울 수 있었다. 덕분에 스켈터랩스는 내게 아주 좋은 이미지로 남아있었는데, 작년 스켈터랩스의 CTO인 조성진님께 오퍼를 받아서 스켈터랩스 인턴으로 일과 학업을 병행하다가 올해 정직원으로 입사하였다.Q. 인턴으로 일을 하며 학업과 병행했는지 몰랐다. A. 학교 스케줄을 우선시할 수 있도록 회사가 많이 배려해주었다. 다행히 학교가 회사와 멀지 않은 거리에 위치하기도 한다. 그래서 학교 수업은 주 2-3일 정도, 오전 타임으로 몰아서 구성했다. 시험기간이라고 하면 팀원들이 모두 나서서 ‘어서 집에 가서 공부부터 해라'라며 조언해주시고 업무적으로도 많이 도와주신 덕에 학업에 대한 지장 없이 일을 할 수 있었다.Q. 인턴을 마치고 정직원으로 입사했다면, 인턴 시절과 현재를 비교할 때 업무적으로 무엇이 가장 다른가.A. 우리 회사는 매 분기마다 분기의 목표 설정과 유사한 OKR(Objectives and Key Results)을 정하고, 이를 완료하는 방식으로 일을 진행한다. OKR에서 중요도가 높은 업무는 P0로, 가장 중요도가 낮은 업무는 P2로 표기한다. 인턴으로 처음 입사했을 때는 P1~P2 레벨의 자잘한 이슈들을 처리하는 업무가 많았다. 정직원이 되고 나니, 그만큼의 지식과 스킬이 쌓인 만큼 P0의 업무들을 조금 더 맡게되었다. 그러나 전반적인 업무의 결은 유사하다. 다만 확실히 책임감은 늘어났다고 생각한다. 인턴일 때는 ‘난 인턴이니까 몰라도 괜찮겠지?’와 같은 마인드가 있었는데, 정직원이 된 지금은 ‘정직원이 이 정도는 알고 있어야겠지?'라고 생각한다. 덕분에 공부하는 양도 이전보다는 늘어났다.사진2. 파워 코딩 중인 단희 님Q. 최근 스켈터랩스가 여러 학교의 커리어페어에 다녀오면서 많이 들었던 질문 중 하나가 ‘인공지능을 전문적으로 공부하지 않았는데, 일을 할 수 있을까요?’였다. 혹시 이 질문에 대한 답변을 해줄 수 있을까.A. 나도 입사 때 면접을 보며 같은 질문을 던졌다. 입사해서 느끼는 점은 정말 인공지능에 관련된 개발 외에 다른 영역에서도 개발해야 하는 일이 정말 많다는 점이다. 때문에 인공지능 분야를 잘 모른다고 해서 (물론 알면 좋지만) 막연한 두려움은 갖지 않아도 좋다. 물론 좀 더 코어한 부분을 개발할수록 인공지능 공부의 필요성을 점점 느끼게 된다. 이러한 기술적 갈증은 사내에서 열리는 테크톡(Tech Talk)과 같은 세미나를 통해 어느 정도 해결할 수 있으며, 업무를 위해 관련 공부가 필수적이라면 팀별로 스터디가 진행되기도 한다. 실제로 다른 팀에서는 주기적으로 관련 논문을 스터디하고 그 지식을 공유하는 세션이 진행되고 있다.Q. 스켈터랩스 입사 후 가장 뿌듯했던 순간과 힘든 순간을 꼽는다면?A. 나는 내가 무언가를 직접 만들고, 그 결과물을 선보이는 과정을 좋아한다. 그래서 가장 뿌듯한 순간으로는 회사 웹사이트를 런칭했을 때를 꼽고 싶다. ‘웹' 특성 상 내가 짠 코드들의 결과를 바로 눈으로 확인할 수 있기 때문에 개발하는 재미도 있었고, 아무래도 회사를 대표하는 사이트라 많은 사람들에게 보여질 것이라 생각하니 더욱 자부심을 갖고 일할 수 있었던 것 같다. 그런 측면에서 나중에 샘을 런칭하게 될 날도 기대된다. 반면 가장 힘들었던 순간은 작년 블루투스 개발 관련 디자인 문서 작업을 진행할 때 였다. 일단 블루투스 기술도 잘 모르는 데다가 디자인 문서 자체도 제대로 써본 적이 없어 생소했다. 사실, 개발이 안 풀리고 막혀있을 때는 그 순간만 힘들 뿐 어떻게든 해결책을 찾고 결과물을 낼 수 있었다. 그런데 디자인 문서 작업은 내가 어떤 방향성을 취해야 하는지, 지금 하고 있는 과정이 맞는 것인지가 계속 의구심이 들었다. 하루종일 컴퓨터 앞에 앉아 있어도 결과물이 없으니 마음만 조급해지는 일도 많았다. 다행히 당시 리뷰를 해주신 조성진님 등 기타 다른 개발자분들의 도움으로 문서는 마무리지을 수 있었는데, 내 한계에 대해 반성하기도, 많이 배우기도 했다.Q. 스켈터랩스 게임동호회 회장을 맡은 것으로 알고있다. 게임동호회를 소개하자면?A. 먼저 오류부터 수정해야할 것 같다. 나는 현재 게임동호회 회장은 아니다. 사내 게임동호회인 ‘Game of Troll’은 한달에 한 두번 모여서 게임을 함께 하는데, 그 게임에서 꼴찌를 한 사람이 회장이 된다. 나의 경우 저번 달 클래시로얄 게임에서 꼴찌를 하여 회장을 맡았었다. 하지만 회장이 정한 게임으로 다음 회장을 뽑기 때문에 내가 자신있는 게임인 오버워치를 9월 게임으로 선정했고, 현재는 정태형 님에게 회장 자리를 넘겨주었다. 게임은 종류에 따라 사내 블루룸 또는 PC방에서 진행한다. 블루룸에는 플스와 닌텐도 등의 각종 게임기가 완비되어 있어, 토너먼트 식으로 철권을 하거나 마리오카트를 했었다. 또 휴대폰으로는 클래시 로얄을 함께 플레이하기도 한다. PC게임인 경우에는 저녁에 함께 피씨방에 가는데, 재미있는 점은 원래 저녁을 먹고 피씨방에 가다가, 피씨방에 가서 저녁을 먹는 걸로 바뀌었다는 점이다. 저녁먹는 시간이 아까워서다. 이렇게 피씨방에서 플레이한 게임들은 스타1, 스타2, 카운터 스트라이크 온라인2, 오버워치, 히어로즈 오브 스톰 등이 있다.처음 게임 동호회에 들어올 때만 해도 ‘같은 회사 사람끼리 게임을 하는 것이 과연 재미있을까'란 생각을 했다. 그런데 막상 게임을 같이 해보니, 회사에서 일할 때는 보이지 않았던 그 사람의 의외의 면을 발견하는 재미도 있는 것 같다. 개인적으로는 초등학교 때부터 게임을 워낙 많이 했던 탓에 스스로 ‘내 인생을 게임에 너무 낭비한 것이 아닐까'란 자괴감을 느낀적도 있는데, 다른 훌륭한 개발자의 게임 덕후스러운 면모를 보면서 ‘나만 이렇게 게임에 빠진 것은 아니었구나'하는 위안도 받을 수 있었다.사진3. 스켈터랩스의 게임동호회 Game of Troll의 뒷풀이 모습Q. 와우, 플레이하는 게임이 정말 많다. 단희님이 가장 좋아하는 게임을 그 중 꼽는다면?A. 나는 단연 오버워치다. FPS게임을 선호하는 편인데 그 중에서도 오버워치를 주로 플레이한다. 개인적으로 스토리가 재미있기도 하고, 팀플레이를 진행하며 합을 맞춰가는 맛이 있다. 무엇보다 사람끼리 대결하는 PVP로 진행을 하면 정말 짜릿함이나 즐거움이 배가 되는 것 같다. 물론 협동 게임인 만큼 팀플레이가 제대로 되지 않는다거나 비매너 유저들과 붙을 때는 기분이 아주 다운되는 경우도 있지만 말이다. 그럴 때는 ‘GTA5’ 또는 최근에 시작한 ‘데스티니 가디언즈'에서 PVE를 하며 마음을 진정시킨다. 물론 이것만 하면 지루하겠지만 오버워치와 적절히 번갈아가면서 하다보면 고유의 재미가 느껴진다.Q. SNS에 웹툰도 연재하고 있는 것으로 알고있다. 어떻게 웹툰 연재를 시작하게 되었는지.A. 어렸을 때부터 만화 그리는 것을 좋아했다. 내가 상상하는 이야기들을 만화로 풀어내는 것도, 그 날 있었던 일을 재미있게 연출해서 일기 대신 그림으로 하루의 기록을 남기는 것도 좋아했다. 그렇게 학교에서 있었던 재미있는 에피소드를 글과 그림으로 남기다 보니, 이걸 모두에게 공개하면 재미있지 않을까란 생각을 했다. 때마침 한창 페이스북 페이지가 유행이었는데, 그때부터 노트에 끄적거린 짧은 만화들을 올리기 시작하면서 현재의 인스타그램 웹툰까지 오게되었다.   사진3. 단희 님이 연재 중인 <초코롤의 코딩일기>, 인스타그램과 페이스북에서 만나볼 수 있다Q. 웹툰 소개를 부탁한다.A. 인스타그램에선 @sw_chocoroll, 페이스북에서는 <초코롤의 코딩일기>라는 제목으로 게재하고 있다. 취미생활 겸 하다 보니 정기연재는 아니다. 제목에서 드러나 듯 주로 코딩(개발) 이야기를 다루고 있는 생활툰이다. 생활툰의 특성상 어쩔 수 없이 주변인들에 대한 묘사가 많고, 에피소드가 없을 때면 웹툰을 그리기도 쉽지 않다. 약간 과장하더라도 실제 있었던 일들을 중심으로 작업하기 때문에, 업로드 전 꼭 등장 인물들에게 검수를 거치기도 한다. 웹툰 그리는 것이 생각보다 집중도를 요하는 작업인지라 보통 주말에 진행하는데, 그래서 평일에는 에피소드를 꼼꼼히 기록해두는 습관이 생겼다. 무엇보다 웹툰을 그리며 가장 많이 느꼈던 점은 내 인생에 대해서 조금 더 알게됐달까, ‘나’를 다시 보게 된 느낌이 있다. 내가 기록한 에피소드가 대부분 게임과 개발에 편중되어 있는 점을 보면서, 인생에서 많은 지분을 ‘게임', ‘개발' 이 두 가지에 할애하고 있다는 것을 새삼 알게되었다.  Q. 재능 부자, N잡러로 보인다. 게임에도 웹툰에도 이렇게 관심이 많았는데 어떻게 개발자의 진로를 선택하게 되었나.A. 이유는 생각보다 단순하다. 위에 웹툰에서도 그렸듯이 영화를 보면 꼭 대형 모니터를 여러 개 띄워놓고 멋지게 주인공을 돕는 해커들이 등장하지 않나. 게임을 많이 하게 되면서 자연스럽게 컴퓨터에 친숙해지기도 했고, 영화를 보면서 ‘나도 컴퓨터 관련 전공을 택하면 저렇게 멋있는 사람이 될 수 있지 않을까’라고 생각했던 것 같다. 다만 어떤 분야의 개발자가 될 것인가에 대한 고민은 많았다. 영화처럼 정보보안 쪽도 잠깐 발을 담갔지만 지금 당장 할 수 있는 분야는 아니라는 생각을 했고, 그 다음은 게임 개발자에 관심을 가졌다. 그런데 당장 게임 회사에 들어간다고 해도 꼭 내가 만들고 싶은 게임만 만들 수는 없다는 것을 알게 되서 보류했다. 나는 일단 스토리가 탄탄하고 재미있는 게임을 정말 사랑한다. 예를 들어 <화이트데이>라는 공포 게임을 정말 재밌게 플레이했었는데, 공포 요소도 한국 정서에 맞게 잘 구현되었으면서 미연시(미소녀 연애 시뮬레이션) 요소도 가미되어 신선한 느낌을 주었었다. 제일 중요한 스토리도 배경 시나리오부터 인게임 진행까지 반전에 반전을 거듭하며 게임이 끝나고도 생각해볼 여지가 많았다. 이런 게임을 만들고 싶지만 우선 희망 사항으로 남겨둔 상태이다. 그러다 우연히 입사한 스켈터랩스에서 훌륭한 선배 개발자들을 보며 ‘개발' 자체의 즐거움을 느꼈고 당장은 어떤 특정 분야에 국한하지 않고 순수한 개발 능력을 향상시키기 위해 노력하고 있다. 스켈터랩스에서 중요하게 다루는 인공지능은 특히 기술적으로 미래의 변화를 주도하고 있기에, 여러 방면에서 매우 배울 점도 많고 발전할 수 있는 것 같다.Q. 최근 몰두하고 있는 것이 있다면?A. 여전히 웹툰과 게임이다. 웹툰을 그릴 수록 기초적인 그림 실력이 부족하다는 것을 많이 느꼈다. 전문적으로 그림을 배워볼까 싶다. 그리고 유튜브에 게임 채널을 열어보려고 한다. 내가 관심있었던 모든 일은 기본적으로 ‘창작'과 ‘기록'의 맥락을 가지고 있다. 개발 또한 어떻게 보면 내가 짜는 코드를 통해 하나의 프로그램을 만들어 내는 역할이지 않나. 웹툰도 내 일상에 대한 기록이다. 나의 일상에서 가장 큰 관심사 중 하나인 게임을 기록하는 방법에 대해 고민했는데, 역시 동영상이 최고라는 결론에 도달했다. 유튜브에는 게임 영상을 편집하여 조금씩 선보이고 있다.Q. 진부할 수 있지만, 이 인터뷰의 마지막 질문이다. 개인적인 꿈을 얘기해줄 수 있나.A. 언젠가는 접어두었던 게임 개발자의 꿈을 꾸려고 한다. 1인 개발자로서 스토리와 작화, 개발을 모두 맡은 개발자 말이다. 그러기 위해서는 그림 뿐만 아니라, 유저의 마음을 사로잡을 수 있는 스토리와 촘촘한 개발력 또한 갖추어야 한다. 개발력은 일단 스켈터랩스에서 빵빵하게 키워놓고, 스토리와 작화에 관련된 역량을 조금씩 갖추어간다면 1인 개발자로서 내 이름을 건 게임을 출시할 날이 조만간 올 수 있지 않을까.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #팀원인터뷰 #팀원소개 #팀원자랑
조회수 2266

개발자에게 필요한 좋은 개발도구들

안녕하세요. 크몽 개발팀 입니다~ 개발자는 무엇인가 개발하기 전에 준비해야될게 있습니다. 바로 개발도구들 과 자신에게 잘 맞는 셋팅이 필요하죠.그래서 이번에 개발환경을 셋팅하면서 알게 된 정보를 공유하기위해 이번 포스트를 작성하게 되었습니다.첫번째 개발도구는 'ampps' 입니다.  ampps는 개발에 있어서 필요한 다양한 개발도구들을 제공해주고 있는데요. 정석대로 하나씩 개발도구들을 설치하게 된다면 많은 시간을 투자해서 설치 및 셋팅을 해야하지만ampps는 한번의 설치만으로 Apache, MySQL, PHP, Python, MongoDB 등등 기본적인 셋팅을 통해 초보개발자이더라도 쉽고 편리하게 사용할 수 있다는점이 가장 큰 장점이라고 생각하고 있습니다.지원되는 운영체제는 Windows, Mac, Linux 모두 지원하기때문에 어느 운영체제는 지원이 안되는 불편함은 없겠네요.사이트 :http://www.ampps.com/ 두번째 개발도구는 'WebStorm' 입니다.  WebStorm은 비쥬얼스튜디오나 이클립스와 같은 통합 개발환경을 제공하고 있습니다.그리고 현재 자바스크립트 프로그래밍에서 절대적인 최고의 에디터로 개발자 사이에서 유명하고 많은 개발자들이 사용하여 개발하고 있습니다. WebStorm의 좋은점은 작성한 코드에서 에러가 있다면 JSHint가 에러부분 밑에 워드프로세서 철자법검사기처럼 빨간 줄로 에러를 표시해 주기때문에 개발자의 실수들을 바로 잡아줄 수 있어서 정말 좋습니다. 그러나 사용자는 30일 평가기간이 끝나면 추가비용을 지불해야 사용할 수 있는데요. 비용을 지불할 만큼 좋은 에디터인점은 변함이 없습니다.  사이트 : https://www.jetbrains.com/webstorm/  앞으로도 공유할 정보들이 생길때마다 크몽팀 블로그에 업데이트 할 예정입니다.포스트 내용에서 찾으시는 정보들을 찾으셨으면 좋겠고 크몽팀 개발자이야기에 많은 관심 부탁드립니다. :)이상 포스트를 마치겠습니다. #크몽 #개발팀 #인턴 #인턴생활 #경험공유
조회수 926

DevOps 문화 안에서의 APM의 역할 [2] (DevOps+JENNIFER)

전편에서는 개발 프로세스 내에서 모니터링 단계의 문제점과 이를 해결하기 위한 방법으로 APM의 역할이 DevOps 진영에서는 매우 중요한 이슈가 되고 있다고 정리했었다. 또한 모니터링 프로세스의 세부 단계와 모니터링 기준 값 설정에 대한 내용을 다뤘는데, 이를 기반으로 제니퍼를 활용하여 모니터링하는 방법에 대해 알아보려고 한다.장애 발견 및 알림제니퍼에서 이벤트 발생 조건은 컴파일 에러나 응답 시간 초과, OOM과 같은 애플리케이션 에러 유형이나 액티브서비스 개수, 응답 시간, CPU 사용률, 힙 메모리 사용률 등 서비스나 시스템의 상태 값으로 설정될 수 있다. 그리고 이벤트 설정시 외부연동 활성화 기능을 사용할 수 있으며, SMTP(Simple Mail Transfer Protocol) 모듈을 기본으로 제공한다. 또한 고객이 직접 이벤트 모듈을 구현할 수 있도록 인터페이스와 유틸리티를 제공한다. 참고로 제니퍼를 사용하는 고객사 중에서 자체적으로 구축한 관제 시스템에 제니퍼 이벤트를 연동하여, 별도의 WAS 경고 시스템을 만든 사례도 있다.   서비스 부하량 제어 (운영)제니퍼는 PLC(Peak Load Control)라는 서비스 부하량을 제어할 수 있는 기능을 제공한다. 트랜잭션 유입 차단의 기준이 되는 최소/최대 액티브서비스 개수를 설정하고, 해당 임계치 값 초과시 사용자에게 가이드해줄 수 있는 메시지나  리다이렉트 페이지를 설정할 수 있다.   만약에 대상 애플리케이션(서버 또는 WAS)이 처리 중인 액티브서비스 개수가 설정한 임계치 값을 초과하면 들어오는 사용자 요청은 거절되며 액티브서비스 이퀄라이저 차트의 요청 효과가 반사되고, 색상 또한 붉은색 계통으로 변하게 된다.사용자의 요청(Request)이 거절되면 PLC 관리 화면에서 설정한 메시지가 보이거나 아래와 같은 화면으로 리다이렉트 되며, 모니터링 대상 애플리케이션의 액티브서비스가 임계치보다 낮아지면 원래의 화면으로 돌아올 수 있다.  장애 원인 분석 (개발)개별 트랜잭션에 대한 프로파일 데이터를 분석하기 위해서는 대상이 되는 패키지나 클래스를 알아야 하는데, 적용 범위에 따라 프로파일 데이터 크기가 매우 커질 수 있으므로 실제로 운영되는 서비스에는 큰 부담이 될 수 있다. 하지만 제니퍼의 자동 프로파일링과 스택트레이스 기능은 설정한 응답시간을 초과한 트랜잭션에만 적용되기 때문에 실제 운영 단계에서 사용하기에 적합하다. 프로파일이란 트랜잭션의 시작점이 되는 메소드의 호출 구조를 상세하게 분석하는 기능을 말하며, 스택트레이스는 앞에서 설정한 기준 값을 초과하는 순간에 호출된 메소드 구조에 대한 로그를 남기는 것을 말한다. 만약에 설정한 응답시간을 초과하여 의심이 될만한 트랜잭션을 분포도 차트에서 찾았다면, 트랜잭션 분석 화면을 통해 문제 시점의 스택트레이스 정보를 참고하거나 응답이 지연되는 프로파일 데이터를 구간 별로 검색하여 콜-트리를 통해 문제가 되는 메소드 위치를 정확히 알아낼 수 있다.소스코드가 배포되었다면 트랜잭션 분포도 차트에서 배포 시점에 세로 축이 하나 그려진다. 해당 축을 선택하면 새로 추가되거나 수정된 리소스 목록을 조회할 수 있으며, 리소스의 배포 전/후의 내용을 분석하는 코드리뷰 기능은 개발 환경에서 반영된 소스코드를 분석해야하는 번거로움을 덜어준다.배포 이후에 액티브서비스가 빠르게 처리되지 못하고, 트랜잭션 분포도 차트가 기존의 패턴과 다르게 형성이 된다면 새로 반영된 소스코드에 문제가 있을 가능성이 매우 높다.결론인류 사회에서 자신이 속해 있는 환경과 전혀 다른 이질적인 문화나 새로운 생활 양식을 접할 때 받는 충격과 공포를 문화 충격(Culture Shock)라고 하는데, 이는 IT 분야에서도 크게 다르지 않다. 사실 DevOps는 몇년 전부터 계속 주목받고 있으며, 많은 소프트웨어 개발 조직에서 시도하고 있는 개발 방법론이다. 하지만 새로운 문화에 대한 거부감으로 인해 제대로 적용되지 못하고 있는 것이 현실이다.DevOps가 추구하는 가치인 존중과 신뢰를 바탕으로 개발과 운영의 원활한 의사소통과 협업 관계 형성은 말처럼 쉽지 않다. 어떻게 보면 이상적일 수 밖에 없는 추상적인 개념이지만 본문에서 다뤘듯이 APM을 상호 간의 의사소통 도구로써 잘 활용한다면 이상이 아닌 보다 현실에 가까워질 수 있다고 필자는 확신한다. APM은 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목표로 하는 DevOps를 개발 문화로 성공적으로 정착시키는데 가장 중요한 역할을 하는 도구라고 생각한다.
조회수 1667

코인원코어 엔진, PM과 개발자가 직접 답해드립니다!

‘코인원코어 엔진을 탑재하고 새로운 심장을 품게 된 코인원.’오늘은 차세대 엔진 프로젝트 ‘랩터TF’ 구성원들과 함께 엔진을 탑재하기까지의 비하인드 스토리와 코인원에서 일하는 이유에 대해 들어보려고 합니다.차세대 엔진 프로젝트는 코인원 크루의 치열했던 고민과 협업의 결과물입니다. 짧게 주어진 시간 동안 출산을 경험한 크루, 공휴일을 반납하고 개근상을 탄 크루 등 여러 에피소드를 남기고 무사히 서비스를 오픈할 수 있었습니다. 이 모든 것은 크루들의 헌신과 열정이 모여 이룰 수 있었던 성과였어요.'랩터TF'를 성공적으로 이끈 랩터 5총사. 지금 바로 이들이 만들어낸 성공 스토리를 공개합니다.Q. 안녕하세요, 자기소개와 함께 현재 하고 계신 일을 소개해주세요!요한 : 이번 랩터 프로젝트 PM과 더불어 블록체인셀에서 Cell Owner (이하 ‘CO’)로 이중생활(?) 하고 있는 조요한입니다. 블록체인셀에서는 주로 암호화폐 자산 입출금을 위한 지갑을 개발하고, 코인원에 블록체인 기술을 연구하고 적용하고 있습니다!자현 : QA셀의 CO 겸 Release Manager를 맡은 구자현입니다. (저도 이중생활을 하네요!) QA셀은 SW테스팅을 통해 코인원 서비스의 품질 경쟁력을 확보하는 것을 목표로 하고 있어요. 그리고 서비스 일정에 차질이 없도록, 전사 배포 프로세스와 일정을 관리합니다.지훈 : 모바일셀의 백엔드 개발자로 일하고 있는 김지훈입니다. 백엔드 개발자에 대해 간략하게 말씀드리면, ‘눈에 보이지 않는 부분을 개발한다.’라고 말씀드릴 수 있겠네요. 저는 코인원 모바일 애플리케이션의 백엔드 API 서버를 담당하고 있습니다. 은호 : 트레이딩셀의 백엔드 개발자 이은호입니다. 지훈님이 모바일 쪽이라면, 저는 웹 영역에서 ‘보이지 않는 손’의 역할을 맡고 있습니다. 서버 뒷단의 작업을 통해 코인원 유저가 안정적이며 신속하게 거래를 할 수 있는 환경을 제공하고 있고요. 랩터 프로젝트에서는 주로 매칭엔진 API 개발을 담당했습니다.허민 : 플랫폼셀의 시스템 엔지니어 허민입니다. 코인원을 지탱하는 인프라 플랫폼의 아키텍처 설계부터 구축과 운영까지 통합적으로 담당하고 있습니다. 특히 이번 랩터 프로젝트가 안정적으로 운영될 수 있도록 서비스 구성부터 많은 정성을 기울였습니다.Q. 차세대 엔진 프로젝트에 왜 랩터라는 별칭이 붙게 되었나요?요한 : 새로운 엔진으로 교체한 이후에 유저들이 서비스적으로 크게 체감할 수 있는 부분은 아무래도 속도일 겁니다. 요새 제 첫째아들이 동물도감에 푹 빠져있어요. 동물도감에서는 지구상에서 가장 빠른 동물로 ‘랩터'라는 공룡을 지칭하고 있습니다. 엔진교체로 거래 속도가 빨라지는 것을 가장 잘 표현할 수 있는 단어라 생각되어 이렇게 별명을 붙여보았어요. 자현 : 저도 랩터 별칭 때문에 찾아본 것이 또 하나 있어요. 전투기 중에서도 가장 빠른 기종을 ‘랩터'라고 하더라고요. 랩터 전투기는 신기술의 집합체이며 아주 정밀하게 만들어졌다고 하네요. 새롭게 교체된 엔진을 가장 잘 표현하는 것 같아 TF원으로서 맴이 아주 뿌-듯합니다!Q. 코인원의 새로운 차세대 엔진 ‘코인원코어'에 대한 자세한 설명 부탁드릴게요.요한 : 코인원코어는 초당 300만 건 이상의 거래 체결 처리가 가능한 고성능 엔진입니다. 수백 대의 서버로 수평 확장이 가능한 분산시스템을 갖추고 있어요. 서비스 중단 없이 거래 엔진을 확장할 수 있고, 신규 암호화폐 상장도 가능합니다. 또한 예상치 못한 장애 상황에서도 별도의 점검 없이 실시간으로 대응할 수 있습니다.코인원은 2014년에 출발해 4년이라는 적지 않은 시간 동안 거래소를 운영하면서 발생한 한계점들을 해결할 솔루션이 필요했어요. 이에 코인원의 다년간 거래소 운영 경험과 서버 엔진 전문기업 아이펀팩토리의 대규모 분산처리 기술이 융합된 거래엔진을 탄생시켰습니다.※ 코인원코어에 관한 자세한 설명은 (https://coinonecore.com/)에서 확인할 수 있습니다!▲화기애애하게 회의중(?)인 랩터TF 크루들!Q. 코인원이 새로운 엔진을 장착하기 이전과 이후, 무엇이 달라졌나요?은호 : 먼저, 시스템 확장성 부분에 대해 말씀드릴게요. 이전에는 상장되어 있는 암호화폐의 개수가 늘어날수록 시스템에 많은 부하가 발생했어요. 시스템을 수평 확장할 수 없는 구조적 한계를 지니고 있었죠. 기존 자원을 더 높은 사양의 자원으로 업그레이드하여 시스템의 부하를 해결했었는데, 이는 매우 높은 유지 비용을 요구하고 확장성 측면에서 한계점이 명확했어요.이제는 코인원코어 엔진을 새롭게 탑재하면서 이러한 부분들을 해결했습니다. 무한히 확장할 수 있는 병렬구조의 아키텍처를 구성했고, 더 많은 암호화폐를 상장해도 끄떡없는 코인원이 되었어요.고가용성과 장애 극복 측면에서 보자면, 모든 서버가 이중화 요건을 만족하여 단일 장애점(Single Point of Failure : SPOF)없는 안정적인 아키텍처로 구성되었습니다. 예상치 못한 장애 상황에서도 별도의 점검 없이 실시간 대응이 가능해 더 안정적인 거래소 운영을 할 수 있습니다.요한 : 이어서 성능에 관한 부분입니다. 거래체결량이 이전보다 100배 이상 향상되었습니다. 암호화폐 거래소 운영에 있어 안정적인 서버 운영은 가장 중요한 요소로 꼽히고 있어요. 특히 거래 서버의 경우 단시간에 수많은 요청을 처리해야 하는데, 코인원 코어는 초당 300만 건 이상 체결 처리를 합니다. 이는 증권사 수준 이상의 체결 엔진 성능이라 말씀드릴 수 있습니다.Q. 이번 코인원코어에 새롭게 적용된 기술적 특징이 있다면?허민 : 한국의 ‘Amazon EKS (Kubernetes Management Service)’가 오픈하고 나서, 가장 빠르게 도입한 회사가 코인원일겁니다. 대부분의 작업을 코드화 한 후, GUI 화면에서 반복적으로 작업하느라 속도가 나지 않던 부분들을 개선하게 되었고요. Kubernetes를 구축하면서 대부분의 서비스를 도커 컨테이너로 전환시키고 서비스들을 마이크로화 했습니다. 이제는 각각의 서비스 배포를 분리해서 업데이트 할 때, 다른 서비스에는 영향을 주지 않도록 시스템을 설계했어요. 개발한 서비스를 안정적이면서도 손쉽게 배포할 수 있고, 문제가 발생했을 때는 빠르게 복구가 가능하게 되었답니다.지훈 : 모바일쪽에서는 이번에 랩터 프로젝트를 하게 되면서 기존 베이스 코드를 리팩토링 한 부분이 절반정도 됩니다. 좀 더 효율적으로 프레임워크를 쓸 수 있도록 리팩토링 작업이 많이 들어갔고요. 많은 성능 향상을 기대하고 있어요!은호 : 앞서 요한님께도 말씀해주셨지만, 코인원코어의 가장 큰 특징은 세계적인 증권 거래엔진을 상회하는 체결성능과 이를 뒷받침하는 안정성이라고 생각해요. 백엔드 개발자 입장에서 성능과 안정성이라는 두가지 품질 요건은 대부분의 상황에서 Trade-off 관계에 놓이게 되는 아키텍처 요건이거든요. 한가지 요건을 달성하게 되면 다른 한가지 요건은 어느정도 희생을 감수할 수 밖에 없습니다. 그러나 코인원코어는 두 마리 토끼를 모두 포기하지 않았어요.초당 300만건이상의 주문을 체결할 수 있는 성능을 제공함과 동시에 장애 발생 상황에서도 단 한 건의 주문 누락 없이 서버가 복구되고 대체됩니다. 이 모든 과정이 전략적으로 자동화 되어 고객의 자산을 보다 더 안전하게 지킬 수 있게 되었어요. 코인원과 코인원코어의 뛰어난 기술력으로 이뤄낸 성과라 자부합니다.▲늦은 시간까지 열정적으로 진행되었던 '랩터TF'▲랩터 TF의 파워업을 위한 영양제와 야식 또한 빠질 수 없겠죠? ;)Q. 코인원 크루로 일하시면서 가장 큰 장점은 무엇인가요?요한 : 직무에 상관없이 자유롭게 소통하는 코인원 크루의 모습이 좋습니다. 코인원에서는 PM, 개발자, 디자이너가 모여 데일리 스탠드업 미팅, 회고 등 원활하게 소통하는 문화가 잘 구축되어 있습니다. 일하면서 좋을 때도 있지만 때론 힘든 부분들도 있을 거에요. 이에 대해 코인원 크루는 서로 투명하게 소통하고 피드백을 건네며 함께 성장합니다.지훈 : 코인원 입사 후에 개발 시간을 그래프로 나타내보았어요. 제 고향인 모바일셀보다 랩터 프로젝트에서 보낸 시간이 더 많더라고요. 랩터 프로젝트를 하면서 느낀 것 중, 코인원 크루는 자부심과 일에 임하는 태도가 남다르다는 것입니다. 저 또한 다른 크루분들의 열정적인 모습을 보고 다시 불태우게 되더라고요. 앞으로 코인원에서 새롭고 재미난 개발작업들을 많이 할 것 같아요.은호 : 코인원이라는 공간은 혼자가 아닌 모두가 함께 만들어나가는 공간이라는 것을 느끼고 있어요. 코인원에서 일하면서 함께 도전하고 성취하려는 크루들의 마인드가 무척 좋습니다. 더불어 모두가 거리낌 없이 새로운 기술을 받아들이려고 하는 스타트업 정신을 잘 가지고 있다는 것이 큰 장점이라고 생각해요. 새로운 기술을 이곳저곳 적용해보면서 시행착오를 겪어야 하는 개발자에게 있어서 가장 중요한 부분입니다. 허민 : 코인원은 이전에 몸담았던 다른 산업군의 회사들보다 훨씬 스펙타클한 곳이에요. 저는 그동안 새로움에 대한 갈증이 매우 컸어요. 시스템 엔지니어의 특성상 기존 서비스를 안정적으로 운영하면서 새로운 기술을 도입하는 부분에는 어려움이 많았거든요. 현재는 다양한 인프라 환경과 블록체인 기술에 관해 공부하고 도전해 볼 수 있는 제 모습이 좋습니다. 그리고 코인원의 크루분들도 새로운 기술에 대해 적극적으로 수용하려 하고, 회사 차원에서도 투자도 많이 이뤄져 뿌듯하네요!자현 : 코인원은 책임감으로 똘똘 뭉친 좋은 사람들이 모여있는 곳이에요. 빠듯한 일정 속에 고생하신 분들이 정말 많습니다. 힘들다고 하기 전에 먼저 알고 서로 응원해주는 모습들이 보기 좋아요. 그렇기 때문에 더욱 힘을내서 랩터 프로젝트를 할 수 있었고요. 또한 새로운 기술에 대해 회사 차원에서 끓임 없이 지원 해줍니다. 저 또한 QA 엔지니어로서 새로운 툴들을 찾아보고 활용할 수 있도록 노력하고 있죠! ▲크루 여러분, 정말 고생 많으셨습니다 :-)Q. 앞으로 코인원에서 이루고 싶은 목표가 있다면?요한 : 블록체인셀의 CO로서 좀 더 안정적인 무중단 입출금 플랫폼을 구축하고 운영하고 싶어요. 아직 블록체인과 암호화폐 생태계가 기술적 관점을 요구할 때가 많아, 일반 유저들이 이해하는데 상당히 어려움을 겪고 있습니다. 저는 유저가 쉽고 편리하게 이용할 수 있는 서비스를 만들고 싶습니다. 마지막으로, 유망한 블록체인 프로젝트들을 더 많이 코인원에 상장하고 싶네요!자현 : QA는 SW제품의 품질을 높이기 위해 개발 전 단계에 걸쳐 코인원의 품질을 체계적으로 잡아가는 조직입니다. 테스팅을 통해 결함을 조기 발견하고 제품 품질을 높여 유저가 서비스를 이용하는 데 문제가 없도록 하고 있어요. 현재 코인원 서비스가 놀이터 수준이라면 고도화된 서비스로 유저들이 즐길 수 있는 놀이동산이 되었으면 좋겠습니다. 코인원 놀이동산에 모여 많은 분이 다양한 서비스를 즐길 수 있으면 좋겠네요!지훈 : 제가 코인원에 입사한 지 얼마 되지 않아, 전체적인 개발을 이해하는데 조금은 감이 오지 않았던 때가 있었습니다. 그래서 특히 랩터TF에 감사해요. 하드코어 심화 속성(?) 수업으로 코인원에 대한 모든 것을 숙지할 수 있게 해주었거든요. 이제는 모바일셀의 백엔드 개발자로서 새로운 서비스나 기능을 많이 개발하고 싶어요. (P.S. 모바일 개발에 대한 A to Z까지 크루분들에게 알려드릴 수 있도록 하겠습니다.)은호 : 개발자의 자아실현 실천법 중에 ‘기여’라는 방법이 있습니다. 개발자는 누구나 오픈 소스 커뮤니티의 도움을 받아 개발을 해왔고, 앞으로도 하고 있을 거에요. 저는 제 멘토와도 같은 오픈소스 커뮤니티에 기여하는 것을 소소하게 목표로 삼고 있어요. 오픈소스 프로젝트를 기획하고, 관심있는 프로젝트에 더 큰 기여를 해 제가 받았던 도움들을 보답하고 싶네요. 이러한 기여의 방법은 저의 개발 커리어로서도 명예이고, 제가 속한 조직에 더 큰 선순환을 불러일으킬거에요.허민 : IT업계 중에서 좋은 개발문화가 회자되는 곳으로 넷플릭스와 페이스북을 꼽습니다. 이들의 경우,  좋은 아이디어나 유저의 요구사항을 빠르게 적용해서 서비스에 반영하고 있어요. 이러한 실행속도는 안정적인 플랫폼이 뒷받침되기에 가능하다고 생각합니다. 코인원 또한 지속적으로 플랫폼을 개선해 나갈 생각이고, 이러한 개발문화를 스며들게 하는것이 제 목표라고 할 수 있겠네요.Q. 코인원에 합류할 예비 PM 그리고 개발자분들에게 한 말씀 부탁드려요!요한 : 코인원은 크루들에게 많은 오너십을 부여하고 있어요. 자신이 맡은 Product에 많은 역할과 권한을 갖는 것을 좋아하고 블록체인을 좋아한다면 코인원으로 오세요! 자현 : 책임감이 강한 분이 오셨으면 좋겠어요. 최소한 자신이 구현한 것에 대해서 끝까지 책임질 수 있는, 마지막 실행단계까지 끝까지 확인할 수 있는 분이었으면 좋겠네요. 모두가 편해지는 개발 월드를 위해!지훈 : 아무래도 금융 쪽에 서비스를 하다 보니까 머리가 좋으신 분들이 정말 많이 지원하실 것 같아요! 아, 추가로 테스트코드를 같이 작성하시는 분이 오시면 정말 좋을 것 같네요!은호 : 자신의 결과물에 자부심과 책임감이 있는 크루가 함께했으면 좋겠습니다! (진지,궁서체입니다.) 허민 : 수평적인 협업을 하고 싶으신 분! 같이의 가치를 소중히 여기시는 분! 어려운 문제가 앞에 있어도 즐기면서 넘어갈 수 있는 분들! 창의적이면서도 효율적으로 일하고 싶으시다면 저희와 함께해요!▲수줍게 웃음짓고 계신 랩터TF 인터뷰이들!지금까지 랩터TF 크루들의 이야기를 들어봤습니다.인터뷰 내내 엔진 서비스를 개발했을 때의 열정이 고스란히 전해졌어요. 함께 서비스를 만들고 성장하면서 서로의 신뢰가 더 두터워졌다는 코인원 크루들. 이러한 믿음 안에서 불가능한 일도 가능하게 만든 힘을 엿볼 수 있었습니다.앞으로 코인원은 더 빠르고, 더 안전하고, 더 단단해진 서비스로 여러분들을 찾아뵐 예정입니다. 엔진 프로젝트를 시작점으로 최고의 서비스를 만들어나가는 이들의 모습이 기대됩니다!끝으로, 특별한 개발문화를 경험할 기회! 코인원 채용에 함께하는 것도 잊지 마세요 :-)
조회수 4195

LSTM Tutorial

Summary:이 포스팅은 LSTM에 대한 기본 개념을 소개하고, tensorflow와 MNIST 데이터를 이용하여 구현해봅니다.LSTM1. 개념 설명LSTM(Long Short Term Memory)은 RNN(Recurrent Neural Networks)의 일종으로서, 시계열 데이터, 즉 sequential data를 분석하는 데 사용됩니다.기존 RNN모델은 구조적으로 vanishing gradients라는 문제를 가지고 있습니다. RNN은 기본적으로 Neural network이기 때문에 chain rule을 적용하여 backpropagation을 수행하고, 예측값과 실제 결과값 사이의 오차를 줄여나가면서 각 시간 단계의 gradient를 조정합니다. 그런데, 노드와 노드(시간 단계) 사이의 길이가 길어지다보면, 상대적으로 이전의 정보가 희석됩니다. 이 문제는 시퀀스 상 멀리 떨어져 있는 요소, 즉 오래 전에 발생한 이벤트 사이의 연관성을 분석할 수 없도록 만듭니다.LSTM은 RNN의 문제를 셀상태(Cell state)와 여러 개의 게이트(gate)를 가진 셀이라는 유닛을 통해 해결합니다. 이 유닛은 시퀀스 상 멀리 있는 요소를 잘 기억할 수 있도록 합니다. 셀상태는 기존 신경망의 은닉층이라고 생각할 수 있습니다. 셀상태를 갱신하기 위해 기본적으로 3가지의 게이트가 필요합니다. Forget, input, output 게이트는 각각 다음과 같은 역할을 합니다.Forget : 이전 단계의 셀 상태를 얼마나 기억할 지 결정합니다. 0(모두 잊음)과 1(모두 기억) 사이의 값을 가지게 됩니다. Input : 새로운 정보의 중요성에 따라 얼마나 반영할지 결정합니다. Output : 셀 상태로부터 중요도에 따라 얼마나 출력할지 결정합니다.게이트는 가중치(weight)를 가진 은닉층으로 생각할 수 있습니다. 각 가중치는 sigmoid층에서 갱신되며 0과 1사이의 값을 가지고 있습니다. 이 값에 따라 입력되는 값을 조절하고, 오차에 의해 각 단계(time step)에서 갱신됩니다.2. 응용 (MNIST data)MNIST는 손으로 쓴 숫자 이미지 데이터입니다. 하나의 이미지는 가로 28개, 세로 28개, 총 784개의 값으로 이루어져 있습니다.Many-to-One model는 여러 시퀀스를 넣었을 때 나오는 최종 결과물만을 이용하는 모델입니다. 이를 이용하여 784개의 input으로 1개의 output값(A) 을 도출합니다. 이 A를 하나의 층에 통과시켜 10개의 숫자 label중 하나를 할당합니다.784개의 입력값을 사이즈가 28인 벡터가 28번 이어지는 시퀀스(time step)로 보고, input의 크기를 28, 시퀀스 길이를 28로 각각 설정합니다. 28개의 input은 C라고 표현되어 있는 LSTM 셀로 순차적으로 들어가게 됩니다.output의 크기는 셀의 크기와 같으며, 64로 설정하였습니다. 셀크기가 너무 작으면 많은 정보를 담지 못하기 때문에 적당히 큰 값으로 설정합니다. 전체 output은 64개의 값을 가지고 있는 벡터 28개의 집합이 되고, 마지막 벡터만 사용합니다.1층의 fully connected layer를 이용하여 64차원 벡터를 10차원으로 줄이고 softmax를 이용하여 0부터 9까지 중 하나의 값을 예측합니다.LSTM으로부터 나온 예측값을 실제갑과 비교하여 cost를 개산합니다. cost function은 cross-entropy를 이용합니다. AdamOptimizer를 이용하여 cost를 최소화하는 방향으로 모델을 최적화 시킵니다.3. 토의구현 시 어려웠던 점을 중심으로 서술하였습니다. 전체 코드는 여기를 참고해주세요.batch sizebatch_size = 128 batch_x, batch_y = mnist.train.next_batch(batch_size) MNIST의 train data의 크기는 55,000개 입니다. 이는 (55000, 784) 크기의 데이터를 학습시켜야 한다는 것을 의미합니다. 이것을 한번에 학습시킨다는 것은 매우 어려운 일입니다. 전체 데이터를 메모리에 올리기 힘들뿐만 아니라, 너무 큰 data 한번에 학습시키면 가장 작은 cost값으로 수렴하기 힘들어진다는 문제가 있습니다. (너무 작아도 마찬가지입니다.) 그렇기 때문에 큰 덩어리를 일정크기의 작은 덩어리로 잘라서 모델에 넣어 학습시는데, 이 작은 덩어리의 크기를 batch size라고 합니다.작은 덩어리로 짜르는 것이 중요한 이유는, 작은 덩어리 단위로 모델에 밀어넣고(propagation) 네트워크의 파라미터들을 조정(update)하기 때문입니다. batch size는 분석하려고 하는 데이터가 어떻게 구성되어있는지에 따라 결정되는 경우가 많습니다. 어떤 수준의 batch size가 좋다고 이야기하기 어렵고, 아주 크지 않은 값으로 설정합니다.unstack모델 구현 시 static RNN을 사용하였습니다. Static RNN에서는 unstack을 해주지 않으면 TypeError가 발생합니다.unstack( value, num=none, axis=0, name=‘unstack’)unstack은 R차원(rank)의 데이터를 R-1 차원으로 줄여주는 역할을 합니다. value로부터 axis 차원을 기준으로 num개로 자른다고도 할 수 있습니다. 이 예제로 예를 들어보겠습니다.batch_x = batch_x.reshape((batch_size, input_steps, input_size)) x = tf.unstack(X, input_steps, axis=1) outputs1, states1 = tf.nn.static_rnn(lstm_cell, x, dtype=tf.float32) 실제 학습이 진행되는 순서로 보자면, batch size만큼 불러온 인풋 데이터는 (128, 784)에서 (128, 28, 28) 형식의 3차원 벡터로 reshape해 줍니다. 그리고 다시 unstack을 통해 time step을 기준으로(axis=1) 28개의 텐서를 만듭니다. 다시말해, (128, 28, 28)이라는 3차원 형식의 벡터는 (128, 28)이라는 2차원 벡터 28개로 변환되어 모델에 입력되게 됩니다. 이런 변환이 필요한 이유는 28*28의 크기를 가진input들을 차례로 넣게 되면 처리속도가 제한적이기 때문입니다. unstack을 이용하면 하나의 batch 안에 있는 input을 한꺼번에 한줄씩 병렬적으로 처리할 수 있게 됩니다.Dynamic RNN에서는 unstack을 해주는 과정이 필요 없습니다. Static과 Dynamic의 차이는 추후 포스팅에서 자세히 다루도록 하겠습니다.Training cycle참고한 다른 예제코드들은 서로 다른 스타일의 사이클로 학습시키고 있었습니다. 스타일은 크게 두가지로 나누어볼 수 있었습니다. 하나의 방법은 전체 학습 횟수를 정해놓고 while문을 통해 학습시키는 방법이었습니다. 다른 방법은 똑같은 데이터를 몇번 반복해서 학습시킬지 결정하는 것입니다. 이 반복 횟수를 epoch이라고 합니다. epoch의 사전적 의미는 ‘시대’ 또는 ‘세’이지만 예제 코드에서 만나는 epoch은 전체 데이터를 학습시키는 반복회수라고 이해하시면 되겠습니다. (이 두가지 방법은 스타일의 문제일 뿐입니다. 이것을 언급한 이유는 개인적으로 epoch을 처음 접했을 때 생소했기 때문입니다.for epoch in range(training_epochs): avg_cost = 0 total_batch = int(mnist.train.num_examples/batch_size) for i in range(total_batch): batch_x, batch_y = mnist.train.next_batch(batch_size) batch_x = batch_x.reshape((batch_size, input_steps, input_size)) c, _ = sess.run([cost2, optimizer2], feed_dict={X:batch_x, Y:batch_y}) avg_cost += c/total_batch 위의 코드는 두번째 스타일이고, 각 epoch마다 cost값과 test data로 예측의 accuracy를 계산하여 출력하였습니다. 당연하게도 학습이 반복 될수록 cost는 감소하고 accuracy는 증가하였습니다.4. 정리기본적으로 도식을 통해 input size, time step, hidden_size에 대한 개념을 이해하는 것이 도움이 됩니다.tensor의 shape을 이해하는 것이 중요하다고 생각합니다. input과 output의 형식(shape)을 머리속에 떠올릴 수 있다면 에러를 줄일 수 있고 해결하기도 수월합니다.batch size의 의미, unstack을 하는 이유, epoch의 의미를 알아두면 좋겠습니다.ReferenceDEEPLEARNING4J 초보자를 위한 RNNs과 LSTM 가이드Colah’s blog, Understanding LSTM Networks이태우, 엘에스티엠 네트워크 이해하기김성훈, 모두의 딥러닝 lec 9-2. Vanishing gadient
조회수 2714

웹 개발자 react native와 친구 되다

안녕하세요. 프론트엔드 bk입니다.자존감이 폭발하는 요즘. 제 자신이 뿌듯하여 이 기분을 오래 간직하고 싶어 쓰는 글입니다. 물론 react native 설치법, 꿀팁 같은 건 없고(react native 경력 2개월) 제가 느꼈던 react native 장단점과 크몽에서 새롭게 선보인 단기 알바 매칭 앱 SOON react native 개발기에 대해 겸손히 적어보려 합니다.어떻게 React Native로 개발하게 되었는가우선 별 볼 일 없는 저를 소개하자면 개발 경력 3년 반 쯤 넘고 React 2년 6개월, Vue 9개월 정도를 프론트 메인 라이브러리로 사용했습니다. 그 동안 훌륭한 분들과 함께 개발을 해왔고, 현재 크몽에 입사한 지는 10개월쯤 되었네요,개발자라면 react native (이하 RN)에 대해선 한 번쯤 들어보셨을 겁니다. 저도 2년 전쯤 처음 들어봤는데요 그때는 네이티브 앱에 비해 느리다, 성능을 못 따라간다, 역시 네이티브!라는 말이 많아서 아 그런가 보다 하고 웹 개발에만 집중했었죠. 그렇게 2018년 9월, 열심히 휴게실에서 크몽의 Vuejs 구조를 잡던 중에 저희 크몽 CTO(a.k.a 크알)가 크몽에서 신규 플랫폼 단기 알바 앱을 기획 중인데, 빠르게 시장 반응을 확인하고, 개발 리소스를 최소화하기 위해 RN로 개발하면 어떨까 하고 React를 경험했던 저에게 권유하셨습니다. 무덤덤한 척했지만 사실 기분 째 질 뻔했습니다. 누군가에게 필요로 하는 사람이 된다는 건 기분 좋은 일이니까요.그렇게 약 1주일간 RN을 필사적으로 공부하여 10월 초부터 본격적인 SOON 폭풍 개발을 시작했습니다. 기본적인 개발 스택은 python + RN + mobx 조합으로 구축되었습니다. (백엔드분 들도 python으로 처음 도입!) 여러 레퍼런스들을 보며 나만의 best practice를 찾아갔고 mobx와의 조합도 훌륭했습니다. react는 익숙하지만 처음 앱 개발을 하는 터라 수많은 시행착오를 겪어야 했죠. 그만큼 새로운 경험도 엄청나게 했습니다. RN 개발자가 당연히? 저 혼자 였기 때문에 누구에게 물어볼 수 도 없었고 그냥 헤딩하며 하나하나 알아갔던것 같네요 ㅎㅎ..... 불과 얼마 전까지도 초창기에 (1달 전..) 짰던 코드를 보고 한숨을 깊게 쉬고 리팩터링을 한 것 수두룩합니다. 그 사이 실력이 늘어났나 보다!라고 열심히 행복 회로를 돌렸죠.RN... 정말 할만할까?정말 할만합니다. 우선 RN은 웹 개발자 (초급 이상의 javascript를 이용한다는 전제하에)라면 10초도 안 걸려 hello world를 띄울 수 있을 만큼 쉽게 만들어져 있습니다.요즘은 expo라는 툴 덕분에 안 그래도 쉽게 개발할 수 있게 만들어진 RN을 더더 더욱 쉽게 접할 수 있게 되어있습니다.hello world기본적으로 RN은 React 기반으로 되어있기에 나는 React를 못써~ 나는 vue or angular 밖에 안 해봤어~라고 하더라도 충분히 빠르게 배울 수 있으리라 생각합니다. React나 vue나 거기서 거기 (위험한 발언이지만 둘 다 상용서비스로 사용해본 입장에선 하나 배우면 다른 라이브러리를 배우는 시간은 처음 배울 때 대비하여 절반도 안 걸렸던 것 같네요)앱 개발이라고 안 하기 보기보단 일단 hello world만 찍어보면 와 재밌다~ 하고 이것저것 더 해보는 자신의 모습을 볼 수 있을 겁니다. 앱 개발을 위해서 RN을 해본다기보다 React를 아주 재미있게 배울 수 있는 도구로서도 훌륭합니다. 그냥 지루하게 docs 보면서 하는 것보단 전혀 새로운 분야를 배우면서 자연스레 React도 배울 수 있습니다. Facebook에서 React를 내세우며 앱 개발 RN도 할 수 있다! 의 기술력 과시가 아니라 RN은 정말 쓸만했습니다.뭘 선택해도 훌륭한 선택. 하지만 난 react와 vueRN의 미친 장점첫 번째는 ios, android 동시 개발하나의 코드로 ios, android가 만들어집니다. 여기서 한술 더 떠 view 부분을 html, css로 변환 후 몇몇 로직들만 수정하면 web으로 그대로 가져올 수 있습니다. 반대로 react로 만들어진 web 기반 서비스를 react native로 변환도 가능합니다. RN이 접근한 Learn once, write anywhere가 뭔가 멋있었죠. (95% 정도는 사실이고 5%의 코드는 ios, android를 나누어 개발합니다 ㅜㅜ)두 번째는 미친 수준의 개발 속도딱히 RN만의 장점은 아니지만.. React는 live-reload(코드가 변경되면 자동으로 새로 고침)와 hot-reload(코드가 변경되면 변경된 딱 그 부분만 렌더링)를 지원합니다. 그 어떤 복잡한 설정 없이 도요. 일단 RN은 compile, build 과정이라는 게 없다고 봐도 되기 때문에(속도 면에서) 굳이 live, hot reload가 없이도 빠른 개발이 가능합니다. 하지만 저 두 놈이 있기에 코드를 수정하면 그 화면을 직접 보는 데까지 오버 좀 섞으면 1초도 채 안 걸립니다. 사실 1~5초 걸림QA 시에도 변경사항을 바로 확인할 수 있습니다. 디자이너, 기획자와의 피드백을 빠르게 반영할 수 있어 UX/UI를 잡는데 아주 효과적입니다. 상상보단 직접 보는 게 더 와 닿으니까요. expo환경에서 개발하고 있다면 가상 simulator가 없어도, xcode, android studio를 건들지 않아도 개발/배포하는 데 아무 지장이 없습니다.(SOON이 론칭되고 나서도 android studio는 아직 설치도 안 했습니다.) 이 정도만 해도 장점이 꽤 큰데 사실 진짜 장점은 다음입니다.마지막으로 OTA(실시간 배포) 기능입니다.정말 이것이 제일 미친 장점입니다. RN으로 만들어진 앱은 기능 추가, 버그 수정, 디자인이 바뀌어도 앱 배포를 위한 심사를 거치지 않습니다. 앱 실행 시 언제나 최신 javascript를 다운로드하고 실행하여 유저는 언제나 최신 상태의 앱을 경험할 수 있습니다. 물론 몇 가지 제한 사항이 있긴 합니다. (앱 아이콘이 바뀌거나 앱과 관련된 config가 바뀔 시엔 심사 필요) 언제나 덤벙대고 맨날 까먹는 저는 정말 유용하게 쓰는 기능입니다. 항상 노트북을 가지고 다니기 때문에 뭔가 오류가 생기면 아 이 부분 예외처리 깜빡했네? 수정하고 publish만 하면 끝이라 오류에 대한 심리적인 부담감이 엄청나게 줄었습니다.당연히 단점도 존재합니다.RN은 성능이 아무래도 딸린다던데...native 코드로 변환작업이 필수 ㅜㅜ태생이 네이티브가 아니라 생기는 해결하기 힘든(불가?) 단점이 있습니다. 저도 이 얘기를 수도 없이 들었습니다. 하이브리드 앱, 웹앱 등이 태생이 Swift와 Java 등의 Native를 따라갈 수 있을 리 만무했죠. RN이 세상에 나오고서도 하브, 웹앱보다는 빠르지만 네이티브와 비교하기엔 민망했다고 합니다. (사실 잘 모름) 그 이후에 주기적으로 성능 향상과 효율성에 대한 업데이트가 있었다는 정도..?  성능에 대해선 딱 이 정도의 정보만 알고 있었고 SOON을 만들기 시작했습니다. 당연히 SOON에는 많은 기능이 담겨있진 않았고 오류 투성이었지만 성능에 대해선 한 번도 이슈가 된 적은 없었습니다. 물론 기능이 계속 추가되고 규모가 커지다 보면 성능이 느려집니다. ms로 비교하여 테스트하지 않는 이상 유의미한 결과라고 생각되진 않았습니다.SOON의 핵심가치는 '빠르고 간편하게 단기 알바를 매칭 시켜준다'입니다. 이것저것 앱의 몸집이 아주 크게 늘어날 것 같지 않다고 판단했고, RN이 가장 최적이라 생각했습니다.(@CTO) 객관적으로 보면 아무리 RN이 나르고 긴다한들.. 성능적으로 보면 네이티브에 대적할 수 없을 것입니다. 하지만 언어를 고르고 서비스를 생각한다기보다 서비스 성격에 맞게 언어를 선택하는 것이 옳다고 생각합니다. 언어는 도구일 뿐이니까요.(참고자료 RN, swift의 성능 테스트)아무래도 javascript와 react에 대해 좀 친해야..RN이 아무리 쉽게 앱 개발을 할 수 있다지만, javascript와 React에 대해 조금(꽤 적당히 많이) 알아야 초기 진입 장벽이 많이 낮아질 것입니다. 이 두 가지를 잘 모르는 상태로 무턱대고 RN을 시작하면, RN보다 javascript, React를 공부하다가 포기하는 경우가 많을 겁니다.사라지지 않는 네이티브에 대한 두려움전 네이티브 코드와 환경을 전혀 모릅니다. 앱 등록 시 인증서가 필요하다는 것도 처음 알았고, 정말 아무것도 몰랐습니다. 초기에 러닝 커브가 꽤나 있었죠. Swift, Java를 공부한 것은 아니지만, 앱 등록/배포는 어떻게 진행되는지 하나의 앱이 존재하는 생태계 등 전반적으로 공부했습니다. 아직도 네이티브 관련 에러가 터지면 앱 개발자 분들을 찾아갑니다. 그렇게 하나하나 배워가고 있죠. 아직은 제가 혼자 해결할 수 없는 부분이 있습니다. RN에 좀 더 적응하면, 기초 앱 개발 정도는 따라 할 수 있도록 공부해야 할 것 같습니다. 이러다 앱 개발로 전향할 지도..Hello World...어쨌든! 장단점이 너무 뚜렷합니다. 새로운 서비스를 론칭 준비 중이면, 내 서비스에 RN이 어울리는지 고민 후 적용하시면 됩니다. 단, 이미 개발된 Native App이 존재하는데, 장기적 관점으로만 RN을 다시 개발하는 것은 강력히 비추합니다. 아무리 RN 개발자가 앱을 만들고 해도 누적된 Native의 경험치를 따라잡긴 힘들거든요. 진짜 어쨌든!앱 개발 관심도 있고, Native를 배울 엄두가 없는 분들.일단 Hello World 만 띄워보세요.아주 아주 재밌습니다.   앞으로 얼마나 더 RN을 하게 될지는 모르겠지만 웹 개발만 하던 제가 할 수 있는 영역이 굉장히 크게 늘어났다는 걸 느낍니다. 그래서 말인데.. 어떻게.. 내년 연봉협상에 반영이 될까요?#크몽 #개발자 #개발팀 #React #기술스택 #도입후기 #인사이트 #경험공유
조회수 1047

Jeykll에서 플러그인 없이 sitemape 생성하기

오늘은 구글에서 블로그를 검색할 수 있도록 설정하는데에서 크게 삽질했다.. 구글 웹마스터에 사이트맵을 등록해야 했는데 그 사이트맵이 자꾸 테스트를 통과못해서 3시간이나 삽질했다.. ㅠㅠ계속 삽질하다가 찾은 이유는.. _config.yml 파일에 url 속성이 없어서 url을 가져오지 못해 생긴 문제였다. ㅠㅠ 정말 허무하고 신나고.. 아무튼 모든 문제를 해결하여 성공적으로 완료했으니 그 방법에 대해 정리하도록 하겠음.참고한 블로그: 스우의 게임서버와 클라이언트! 미친듯이 영어 검색어들로 오류를 찾으며 삽질했었는데 의외로 한글 블로그에서 이 부분에 대해 언급되어 있어 해결할 수 있었다. 감사합니다 ㅠㅠsitemap 생성하기1. sitemap.xml 파일 생성블로그의 root 디렉토리에 sitemap.xml 파일 생성.2. sitemap.xml 파일 작성하단의 코드를 복사하여 만들어준 sitemap.xml 파일에 붙여넣기.            3. url 설정추가_config.yml 파일에 url 설정이 없는 경우 url 설정을 추가하여 sitemap.xml에서 site.url 변수값을 사용할 수 있도록 해줌. (이 부분 때문에 무한 삽질 ㅠㅠ)4. 구글 웹마스터 툴에서 테스트 혹은 제출구글 웹마스터 툴에서 테스트 혹은 제출을 통해 만들어준 sitemap이 제대로 동작하는지 확인.여태 GA나 기타 여러가지를 설정하느라 공개하지 않았는데 이제서야 공개합니다.제 블로그는 https://heelog.github.io/about/ 입니다!#트레바리 #개발자 #안드로이드 #앱개발 #Jeykll #백엔드 #인사이트 #경험공유

기업문화 엿볼 때, 더팀스

로그인

/