전체 피드 목록

패스트파이브는 멤버들에게 공간, 서비스, 커뮤니티를 제공합니다. 한눈에도 매우 달라 보이는 이 세 가지 가치를 모두 다루는 곳이 바로 프로덕트 본부인데요, 멤버가 직접 만나는 가치인 만큼 아주 작은 디테일까지 신경써야 한다고 하네요. 이번 Humans of FASTFIVE의 주인공은 더 나은 가치를 공유하기 위해 연구를 거듭하는 프로덕트 본부의 고혜경 이사님입니다. 공간, 서비스, 커뮤니티는 뗄래야 뗄 수 없는 연결된 가치라고 설명하는 혜경 님의 인터뷰를 함께 만나보시죠. Q. 혜경 님 안녕하세요, 간단한 자기소개를 부탁드립니다.저를 하는 일로 소개하자면 잡부에 가까운 것 같네요. 잡다한 일을 이것저것 하는 사람이라는 의미에서요. 회사에서 지금 필요한 일을 하다보니 자연스럽게 그렇게 되었습니다. 회사가 성장함에 따라 필요한 일들이 달라지는데, 그에 맞추어 제가 하는 일도 변하거든요. 2017년 4월에 패스트파이브에 입사한 뒤로 거의 6개월마다 포지션이 바뀌었네요.그렇다고 부정적인 의미는 아니에요. 페이스북에서 일했던 Molly Graham이라는 사람이 쓴 칼럼을 읽었는데요, 성공하는 조직에서 3개월마다 포지션이 바뀌는 일은 당연하니 그에 대해 스트레스를 받지 말라는 내용이었어요. 내가 자리를 옮겨도 그 일이 돌아가도록 하는 게 당신의 업무라고 하더라고요. 그걸 읽고 ‘내 이야긴가?’ 싶었어요.Q. 패스트파이브에 합류하기 전에는 어떤 일을 하셨나요?패스트파이브에는 2017년 4월 1일에 입사했습니다. 그 전에는 푸드플라이라는 배달앱 서비스 스타트업에서 초기 멤버로 1년 반 정도 일했어요. Q. 그럼 처음부터 스타트업에서 커리어를 시작하신 건가요?아니요, 푸드플라이 전에는 삼성전자 무선사업부의 모바일 서비스 기획/운영팀에서 일했습니다. 제가 입사한 2009년은 삼성전자가 안드로이드폰을 런칭하기 전이었어요. 그 해에 한국에 아이폰이 처음으로 출시되었죠. 삼성에서 갤럭시S를 출시한 시기가 2010년이고 갤럭시 S3로 정점을 찍은 게 2012년이니 저로서는 운이 좋게도 그 과정을 지켜볼 수 있었습니다.삼성전자는 스마트폰 이전, 피쳐폰 시장에서는 잘 하고 있었지만 스마트폰에 대한 이해는 부족한 상태였습니다. 스마트폰에서는 페이스북이나 유튜브 같은 모바일 서비스가 잘 되는 게 중요한데 당시에는 사람들이 그런 서비스에 대해 잘 몰랐어요. 제가 속한 팀이 그런 측면에서 프론티어 같은 역할을 했죠. 영업팀 임원에게 페이스북이 뭔지, 트위터는 어떤 서비스인지 설명하고 많은 사람들이 이 기능을 원한다는 것부터 설득해야 했어요. 원래 모바일/웹서비스에 관심이 많았기 때문에 빠르게 적응할 수 있었던 것 같아요.삼성에는 3년 정도 다녔는데, 한 달에 한 번 정도 먼 곳으로 출장을 많이 나가야 했어요. 주로 중남미 쪽으로 다니니까 시간이 정말 빨리 가더라고요.Q. 대기업에서 스타트업으로 일터를 옮기신 이유는 뭔가요?회사 생활이 나쁘지는 않았지만 무기력함이 심해질 때가 있었어요. 운동, 연애, 이사 등 여러 가지를 시도해봤는데 잘 나아지지 않더라고요. 마지막에는 ‘내가 가장 많은 시간을 보내는 회사에서의 일을 바꿔볼까?’ 하는 생각을 했죠. 원래는 회사 내에서 부서를 바꾸려고 했어요. 그러던 찰나 푸드플라이 대표가 저에게 같이 일해보자고 하더라고요.또 그 시기가 창업, 스타트업 업계에서 제2의 붐이 일었을 때예요. 제 고등학교 동창 중 한 명이 티몬의 창업 멤버이기도 하고 주위에 스타트업에서 일하고 있는 지인들이 많아서 딱히 어려운 선택은 아니었습니다. 또 푸드플라이의 비즈니스 모델 설명을 들어보니 말이 된다는 판단이 들었죠. 사실 깊이 생각했다기보다는 가벼운 마음으로 옮겼어요. '허황된 일은 아니구나, 나도 같이 해볼까?' 정도의 마음으로요.Q. 다양한 일을 경험하셨는데 이 경험들과 비교했을 때 패스트파이브에서 일한다는 것은 어떤 점이 다르고 어떤 의미를 갖나요?패스트파이브는 저의 생각보다 훨씬 빠르게 성장하고 있다는 점이, 제가 거쳐왔던 다른 곳들과의 차이입니다. 그리고 그 성장이 실시간으로 눈에 보여요. 물론 삼성전자의 스마트폰도 굉장히 빠른 속도로 성장한 사업이었습니다. 하지만 그 과정이 구체적으로 제 눈에 보이지는 않았어요.그런데 패스트파이브는 작년 4월만 해도 스무 명이 채 안 되었던 직원 수가 현재는 팔십 명이 넘는 상황이죠. 또 프로덕트의 특징도 있어요. 규모가 커질 때마다 새로운 지점이라는 실물이 세워지는 거잖아요? 지점이 느는 게 눈에 보이니까 더 직접적으로 ‘체감’의 느낌이 들어요. 푸드플라이에서 고객이 늘어난 건 확실하지만 그 고객들을 제 눈으로 직접 보지는 못했다는 점과 구별되죠. Q. 패스트파이브의 프로덕트에 대한 이야기를 해주셨는데, 프로덕트 본부는 정확히 어떤 일을 하는 곳인가요?프로덕트 본부는 패스트파이브가 고객들에게 제공하는 공간/서비스/커뮤니티를 관리하는 곳입니다. 한 가지씩 나누어 설명드릴게요. 우선 패스트파이브가 제공하는 ‘공간’은 굉장히 복합적인 상품입니다. 실제로 구획된 물리적 공간뿐만 아니라 심미적인 요소도 포함되어 있거든요. 기능적 요소와 심미적 요소를 동시에 충족시켜야 하는, 오프라인 영역의 프로덕트가 공간인 셈입니다.구글, 카카오, 배달의민족처럼 사무실의 심미적 측면에도 크게 신경을 쓰는 일부 기업을 제외하면 보통 사무실에서 심미성을 엄청나게 추구하지는 않잖아요. 저희는 일을 하러 오는 곳에서도 심미적 경험을 할 수 있도록 노력 중입니다. 그 점이 보통의 사무 공간과 패스트파이브의 차이기도 하죠.패스트파이브의 멤버들은 일을 하기 위해 여기에 오기만 하면 됩니다. 가장 중요한 일 말고는 고민할 필요가 없죠. 예를 들어 너무나 당연하게 느껴지는 인터넷이나 정수기, 커피 같은 서비스도 직접 사무실을 꾸려 나가려면 보통 신경쓰이는 게 아니거든요. 직접 전화를 걸어서 인터넷 설치를 신청해야 하고, 정수기 업체를 비교 선택해야 하고, 커피는 인스턴트를 구입할까, 머신을 대여할까 등등의 고민이 필요하고요. 패스트파이브는 이런 서비스를 전부 제공합니다. 서비스는 말 그대로 눈에 보이지 않는 서비스이기 때문에 눈에 보이는 상품인 공간과는 굉장히 다른 영역이죠.패스트파이브의 미션은 고객들이 본질에 집중해서 일할 수 있도록 하고, 영감을 받을 수 있도록돕는 것입니다. 영감을 받게 하는 방법에는 여러가지가 있습니다. 환경을 바꾸거나 만나는 사람을 바꾸는 것도 그 방법들 중 하나죠. 집과 회사만 왕복하다 보면 늘 만나는 사람만 만나게 됩니다. 친구도 점점 편한 사람만 만나게 되고요. 영감을 받기엔 어려운 환경이라고 할 수 있죠. 패스트파이브는 의도적으로 낯선 사람들과 만날 수 있는 커뮤니티를 제공합니다. 그 과정에서 몰랐던 것들을 알게 되고 새로운 자극을 받고 다른 방향의 사고를 할 수 있게 돼요. 더 발전해서 실제로 협업을 하게 되는 경우도 있고요. 이런 커뮤니티 역시 패스트파이브가 제공하는 프로덕트 중 한 가지예요.Q. 프로덕트 본부에서 다루는 요소들은 상당히 복합적이고 어떻게 보면 제각각이라고 느껴지는데요, 이 프로덕트들을 하나로 묶은 이유가 있나요?사실 공간/서비스/커뮤니티는 모두 연결되어 있습니다. 공간이 뒷받침되어야 서비스를 제공할 수 있는 식이죠. 라운지라는 오프라인 공간을 구축해야 그 안에서 커피 서비스를 제공할 수 있게 되는 거니까요.또 이벤트를 개최하거나 소모임을 진행할 수 있으려면 그에 맞게 공간을 설계해야 합니다. 사람들이 왔다갔다하면서 서로 마주칠 수 있으려면 공간에 그 의도를 담아야 하죠. 그러니 커뮤니티, 서비스, 공간이 다 따로인 것 같으면서도 연결되어 있는 맥락인 셈입니다. 극단적인 예로, 기존의 소호 사무실이나 비즈니스 센터처럼 라운지가 없고 사무공간만 있다고 상상해보세요. 그렇다면 행사나 이벤트, 소모임을 개최하기도 어려워질 거예요. 가장 밑바탕에는 공간이 있고 그 위에 서비스와 커뮤니티가 얹어져 패스트파이브의 프로덕트를 완성한다고 할 수 있죠.Q. 굉장히 다양한 일을 하시는 것으로 알고 있는데, 일을 하면서 가장 어려운 부분과 보람있는 부분이 있다면 어떤 점인가요?공간에 관련된, 그러니까 인테리어 디자인이나 건축 쪽 일을 해본 적이 없어서 패스트파이브에 와서 아예 처음부터 배우게 되었습니다. 새로운 분야를 배우는 일 자체는 크게 어렵지 않았지만 디테일한 요소들이 끝이 없더라고요. 디테일에서 퀄리티 차이가 나고, 브랜드 이미지가 달라지기 때문에 굉장히 중요한데 또 그만큼 광범위하니까요.저는 개인적으로 기준이 높은 편이에요. 제 눈에는 별로인데 남들은 괜찮다고 하는 경우도 많고요. 그래서 최대한 저의 기준에 맞추려고 노력합니다. 지금까지 만족한 적은 드물어요. 공간은 예쁘고 만족스러운데 설계를 잘못해서 깔끔하지 않게 사용된다든지 하는 문제가 생기더라고요.Q. 혜경 님의 기준에 따라 디테일을 수정한 경우가 있었다면요?패스트파이브의 라운지는 노출 천장이 기본 컨셉이에요. 노출 천장이 자칫하면 어지럽고 지저분해 보일 수 있거든요. 그래서 새로운 지점에서는 냉난방 배관을 원형 덕트가 아니라 라인 디퓨저 형태로 만들어서 최대한 창측으로 빼봤어요.또, 패스트파이브는 보통 사무공간과 달리 컬러풀한 색을 많이 사용하는 편이에요. 사무실이라고 하면 흰색, 회색 정도가 전부인 경우가 많은데 패스트파이브의 공간은 컬러풀하죠. 그래서 페인트 선택에도 많은 고민을 했는데요, 기존에 사용한 무광 페인트는 세련된 대신 먼지가 잘 묻는다는 단점이 있습니다. 반대로 광이 날수록 매트한 세련됨이 덜하죠. 그런데 최근에 아주 약간 광이 있는 페인트를 찾아냈어요. 매트한 느낌을 살리면서도 아예 무광인 제품보다 먼지가 덜 묻는 제품을 도입했죠.페인트칠을 한 벽에 먼지가 잘 묻는다는 문제 의식은 늘 가지고 있었지만 이 문제를 바로 처리해야겠다는 생각은 못 했어요. 다른 더 급한 일이 많기도 하고요. 대신 저희와 함께 일하는 협력업체들에게 늘 이야기해두었죠. 먼지가 묻는 문제가 있는데 유광은 예쁘지가 않다, 해결 방법이 생기면 알려달라고요. 그랬더니 이런 제품이 있다고 연락이 오더라고요. 이런 시도들을 같은 것을 제공하면서도 좀 더 좋게 만들려는 노력으로 봐 주시면 좋을 것 같습니다.Q. 앞으로 패스트파이브에서 이루고 싶은 가치나 목표가 있으신가요?회사가 빠르게 성장하는 만큼 함께 성장하고 싶어요. 그리고 구성원의 성장을 이끌고, 지원할 수 있는 조직이 되었으면 좋겠습니다. 패스트파이브의 구성원은 대부분 5년 이하의 경력을 가지고 있으신데 이분들의 성장이 회사의 성장과 직결되어 있잖아요. 구성원의 성장과 함께 빠르게 성장하는 회사가 되었으면 해요. 우선 일할 때 사소한 문제들 때문에 성가시지 않도록 해드릴 거고요. 예를 들어 컴퓨터가 느려서 일을 못하겠어요 같은 일은 없도록 해야죠. 또 옳지 않은 일들 때문에 감정적으로 스트레스를 받지 않도록 하려고 해요. 조직 차원에서 룰을 정하는 등의 방식을 통해 쓸데없는 감정 소모가 일어나지 않도록 할 수 있겠죠.Q. 개인적인 목표도 궁금합니다.거창한 목표는 딱히 없어요. 그래서 창업은 못 할 것 같아요. 창업을 하는 사람은 강렬한 욕망이 있어야 한다고 생각하는데, 저한테는 아직 강렬한 욕망이 없거든요. 다만 지치지 않는 사람이 되고 싶기는 합니다. 예전에 번아웃된 적도 있기 때문에 더욱 지치지 않는 게 중요하다고 생각하게 된 것 같아요. 지인 중에 10년째 어떤 일을 하는 분이 있어요. 굴곡은 있지만 일관된 방향성을 가지고 꾸준히 나아가고 있죠. 본인은 이게 굉장히 의미 있는 일이라고 믿고 그 사명감으로 해나가는 거죠. 그런 모습이 부럽기도 하고 대단하게 느껴지더라고요. Q. 요즘 프로덕트 본부 일뿐만 아니라 면접으로도 바쁘신 것 같아요. 프로덕트 본부에는 어떤 사람이 적합하다고 생각하시나요? 저는 사람을 볼 때 그 사람이 왜 여기에서 일하려고 하는가를 주로 봅니다. 그 사람의 스토리가 패스트파이브의 맥락과 맞는가를 함께 보죠. 스토리가 이곳과 맞는 분들은 회사에 와서도 일을 잘 하시더라고요. 그렇지 않은 경우는 많이 힘들어하시는 것 같아요. 더 자세히 말씀드리자면 왜 그 학교에 갔는지, 왜 전 직장에서 퇴사했고 왜 이곳에서 일하려고 하는지 등의 이유를 납득할 수 있도록 설명하는 게 중요하죠.또, 이건 모든 회사가 원하는 사항이 아닐까 싶지만 스스로 알아서 잘 하는 사람이면 좋겠습니다. 저는 경력은 별로 중요하지 않다고 생각해요. 문제를 해결하는 방법을 아느냐, 해결할 의지가 있고 그 방법을 찾아내느냐가 훨씬 중요합니다. 패스트파이브는 새로운 일을 하고 있는 곳입니다. 국내에서는 최초라고 할 수 있고요. 늘 시장을 선도해야 하는 입장이기에 늘 새로운 일을 해야 하죠. 따라서 빠르게 배우고 적응하는 사람이 필요합니다. 협업이 많다보니 커뮤니케이션 능력도 필요하고요.Q. 마지막으로 하고 싶은 이야기가 있으신가요?많은 지원 부탁드립니다!멤버에게는 더 좋은 공간과 서비스, 커뮤니티를 제공하고 패스트파이브의 구성원에게는 함께 성장하는 조직이 되었으면 한다는 혜경 님과의 인터뷰, 재미있게 읽으셨나요? 앞으로 패스트파이브와 프로덕트 본부의 성장을 지켜봐주세요. 그럼 저희는 다음 인터뷰로 돌아오겠습니다. 읽어주셔서 감사합니다 :)- 패스트파이브 마케팅팀 드림

비트윈에서는 HBase를 메인 데이터베이스로 이용하고 있습니다. 유저 및 커플에 대한 정보와 커플들이 주고받은 메시지, 업로드한 사진 정보, 메모, 기념일, 캘린더 등 서비스에서 만들어지는 다양한 데이터를 HBase에 저장합니다. HBase는 일반적인 NoSQL과 마찬가지로 스키마를 미리 정의하지 않습니다. 대신 주어진 API를 이용해 데이터를 넣기만 하면 그대로 저장되는 성질을 가지고 있습니다. 이런 점은 데이터의 구조가 바뀔 때 별다른 스키마 변경이 필요 없다는 등의 장점으로 설명되곤 하지만, 개발을 쉽게 하기 위해서는 데이터를 저장하는데 어느 정도의 규칙이 필요합니다. 이 글에서는 비트윈이 데이터를 어떤 구조로 HBase에 저장하고 있는지에 대해서 이야기해 보고자 합니다.비트윈에서 HBase에 데이터를 저장하는 방법¶Thrift를 이용해 데이터 저장: Apache Thrift는 자체적으로 정의된 문법을 통해 데이터 구조를 정의하고 이를 직렬화/역직렬화 시킬 수 있는 기능을 제공합니다. 비트윈에서는 서버와 클라이언트가 통신하기 위해 Thrift를 이용할 뿐만 아니라 HBase에 저장할 데이터를 정의하고 데이터 저장 시 직렬화를 위해 Thrift를 이용합니다.하나의 Row에 여러 Column을 트리 형태로 저장: HBase는 Column-Oriented NoSQL로 분류되며 하나의 Row에 많은 수의 Column을 저장할 수 있습니다. 비트윈에서는 Column Qualifier를 잘 정의하여 한 Row에 여러 Column을 논리적으로 트리 형태로 저장하고 있습니다.추상화된 라이브러리를 통해 데이터에 접근: 비트윈에서는 HBase 클라이언트 라이브러리를 직접 사용하는 것이 아니라 이를 래핑한 Datastore라는 라이브러리를 구현하여 이를 이용해 HBase의 데이터에 접근합니다. GAE의 Datastore와 인터페이스가 유사하며 실제 저장된 데이터들을 부모-자식 관계로 접근할 수 있게 해줍니다.트랜잭션을 걸고 데이터에 접근: HBase는 일반적인 NoSQL과 마찬가지로 트랜잭션을 제공하지 않지만 비트윈에서는 자체적으로 제작한 트랜잭션 라이브러리인 Haeinsa를 이용하여 Multi-Row ACID 트랜잭션을 걸고 있습니다. Haeinsa 덕분에 성능 하락 없이도 데이터 무결성을 유지하고 있습니다.Secondary Index를 직접 구현: HBase에서는 데이터를 Row Key와 Column Qualifier를 사전식 순서(lexicographical order)로 정렬하여 저장하며 정렬 순서대로 Scan을 하거나 바로 임의 접근할 수 있습니다. 하지만 비트윈의 어떤 데이터들은 하나의 Key로 정렬되는 것으로는 충분하지 않고 Secondary Index가 필요한 경우가 있는데, HBase는 이런 기능을 제공하지 않고 있습니다. 비트윈에서는 Datastore 라이브러리에 구현한 Trigger을 이용하여 매우 간단한 형태의 Secondary Index를 만들었습니다.비트윈 HBase 데이터 구조 해부¶페이스북의 메시징 시스템에 관해 소개된 글이나, GAE의 Datastore에 저장되는 구조를 설명한 글을 통해 HBase에 어떤 구조로 데이터를 저장할지 아이디어를 얻을 수 있습니다. 비트윈에서는 이 글과는 약간 다른 방법으로 HBase에 데이터를 저장합니다. 이에 대해 자세히 알아보겠습니다.전반적인 구조¶비트윈에서는 데이터를 종류별로 테이블에 나누어 저장하고 있습니다. 커플과 관련된 정보는 커플 테이블에, 유저에 대한 정보는 유저 테이블에 나누어 저장합니다.각 객체와 관련된 정보는 각각의 HBase 테이블에 저장됩니다.또한, 관련된 데이터를 하나의 Row에 모아 저장합니다. 특정 커플과 관련된 사진, 메모, 사진과 메모에 달린 댓글, 기념일 등의 데이터는 해당 커플과 관련된 하나의 Row에 저장됩니다. Haeinsa를 위한 Lock Column Family를 제외하면, 데이터를 저장하기 위한 용도로는 단 하나의 Column Family만 만들어 사용하고 있습니다.각 객체의 정보와 자식 객체들은 같은 Row에 저장됩니다.또한, 데이터는 기본적으로 하나의 Column Family에 저장됩니다.이렇게 한 테이블에 같은 종류의 데이터를 모아 저장하게 되면 Region Split하는 것이 쉬워집니다. HBase는 특정 테이블을 연속된 Row들의 집합인 Region으로 나누고 이 Region들을 여러 Region 서버에 할당하는 방식으로 부하를 분산합니다. 테이블을 Region으로 나눌 때 각 Region이 받는 부하를 고려해야 하므로 각 Row가 받는 부하가 전체적으로 공평해야 Region Split 정책을 세우기가 쉽습니다. 비트윈의 경우 커플과 관련된 데이터인 사진이나 메모를 올리는 것보다는 유저와 관련된 데이터인 메시지를 추가하는 트래픽이 훨씬 많은데, 한 테이블에 커플 Row와 유저 Row가 섞여 있다면 각 Row가 받는 부하가 천차만별이 되어 Region Split 정책을 세우기가 복잡해집니다. RegionSplitPolicy를 구현하여 Region Split 정책을 잘 정의한다면 가능은 하지만 좀 더 쉬운 방법을 택했습니다.또한, 한 Row에 관련된 정보를 모아서 저장하면 성능상 이점이 있습니다. 기본적으로 한 커플에 대한 데이터들은 하나의 클라이언트 요청을 처리하는 동안 함께 접근되는 경우가 많습니다. HBase는 같은 Row에 대한 연산을 묶어 한 번에 실행시킬 수 있으므로 이 점을 잘 이용하면 성능상 이득을 얻을 수 있습니다. 비트윈의 데이터 구조처럼 특정 Row에 수많은 Column이 저장되고 같은 Row의 Column들에 함께 접근하는 경우가 많도록 설계되어 있다면 성능 향상을 기대할 수 있습니다. 특히 Haeinsa는 한 트랜잭션에 같은 Row에 대한 연산은 커밋시 한 번의 RPC로 묶어 처리하므로 RPC에 드는 비용을 최소화합니다. 실제 비트윈에서 가장 많이 일어나는 연산인 메시지 추가 연산은 그냥 HBase API를 이용하여 구현하는 것보다 Haeinsa Transaction API를 이용해 구현하는 것이 오히려 성능이 좋습니다.Column Qualifier의 구조¶비트윈은 커플들이 올린 사진 정보들을 저장하며, 또 사진들에 달리는 댓글 정보들도 저장합니다. 한 커플을 Root라고 생각하고 커플 밑에 달린 사진들을 커플의 자식 데이터, 또 사진 밑에 달린 댓글들을 사진의 자식 데이터라고 생각한다면, 비트윈의 데이터들을 논리적으로 트리 형태로 생각할 수 있습니다. 비트윈 개발팀은 Column Qualifier를 잘 정의하여 실제로 HBase에 저장할 때에도 데이터가 트리 형태로 저장되도록 설계하였습니다. 이렇게 트리 형태로 저장하기 위한 Key구조에 대해 자세히 알아보겠습니다.Column Qualifier를 설계할 때 성능을 위해 몇 가지 사항들을 고려해야 합니다. HBase에서는 한 Row에 여러 Column이 들어갈 수 있으며 Column들은 Column Qualifier로 정렬되어 저장됩니다. ColumnRangeFilter를 이용하면 Column에 대해 정렬 순서로 Scan연산이 가능합니다. 이 때 원하는 데이터를 순서대로 읽어야 하는 경우가 있는데 이를 위해 Scan시, 최대한 Sequential Read를 할 수 있도록 설계해야 합니다. 또한, HBase에서 데이터를 읽어올 때, 실제로 데이터를 읽어오는 단위인 Block에 대해 캐시를 하는데 이를 Block Cache라고 합니다. 실제로 같이 접근하는 경우가 빈번한 데이터들이 최대한 근접한 곳에 저장되도록 설계해야 Block Cache의 도움을 받을 수 있습니다.비트윈에서는 특정 커플의 사진이나 이벤트를 가져오는 등의 특정 타입으로 자식 데이터를 Scan해야하는 경우가 많습니다. 따라서 특정 타입의 데이터를 연속하게 저장하여 최대한 Sequential Read가 일어나도록 해야 합니다. 이 때문에 Column Qualifier가 가리키는 데이터의 타입을 맨 앞에 배치하여 같은 타입의 자식 데이터들끼리 연속하여 저장되도록 하였습니다. 만약 가리키는 데이터의 타입과 아이디가 Parent 정보 이후에 붙게 되면 사진 사이사이에 각 사진의 댓글 데이터가 끼어 저장됩니다. 이렇게 되면 사진들에 대한 데이터를 Scan시, 중간중간 저장된 댓글 데이터들 때문에 완벽한 Sequential Read가 일어나지 않게 되어 비효율적입니다.이렇게 특정 타입의 자식들을 연속하게 모아 저장하는 묶음을 컬렉션이라고 합니다. 컬렉션에는 컬렉션에 저장된 자식들의 개수나 새로운 자식을 추가할 때 발급할 아이디 등을 저장하는 Metadata가 있습니다. 이 Metadata도 특정 Column에 저장되므로 Metadata를 위한 Column Qualifier가 존재합니다. 이를 위해 Column Qualifier에는 Column Qualifier가 자칭하는 데이터가 Metadata인지 표현하는 필드가 있는데, 특이하게도 메타데이터임을 나타내는 값이 1이 아니라 0입니다. 이는 Metadata가 컬렉션의 맨 앞쪽에 위치하도록 하기 위함입니다. 컬렉션을 읽을 때 보통 맨 앞에서부터 읽는 경우가 많고, 동시에 Metadata에도 접근하는 경우가 많은데, 이 데이터가 인접하게 저장되어 있도록 하여 Block Cache 적중이 최대한 일어나도록 한 것입니다.Datastore 인터페이스¶비트윈에서는 이와 같은 데이터 구조에 접근하기 위해 Datastore라는 라이브러리를 구현하여 이를 이용하고 있습니다. HBase API를 그대로 이용하는 것보다 좀 더 쉽게 데이터에 접근할 수 있습니다. GAE의 Datastore와 같은 이름인데, 실제 인터페이스도 매우 유사합니다. 이 라이브러리의 인터페이스에 대해 간단히 알아보겠습니다.Key는 Datastore에서 HBase에 저장된 특정 데이터를 지칭하기 위한 클래스입니다. 논리적으로 트리 형태로 저장된 데이터 구조를 위해 부모 자식 관계를 이용하여 만들어 집니다.Key parentKey = new Key(MType.T_RELATIONSHIP, relId);Key photoKey = new Key(parentKey, MType.T_PHOTO, photoId); // 특정 커플 밑에 달린 사진에 대한 키Datastore는 Key를 이용해 Row Key와 Column Qualifier를 만들어 낼 수 있습니다. Datastore는 이 정보를 바탕으로 HBase에 새로운 데이터를 저장하거나 저장된 데이터에 접근할 수 있는 메서드를 제공합니다. 아래 코드에서 MUser 클래스는 Thrift로 정의하여 자동 생성된 클래스이며, Datastore에서는 이 객체를 직렬화 하여 HBase에 저장합니다.MUser user = new MUser();user.setNickname("Alice");user.setGender(Gender.FEMALE);user.setStatus("Hello World!"); Key userKey = new Key(MType.T_USER, userId);getDatastore().put(userKey, user);user = getDatastore().get(userKey);getDatastore().delete(userKey);또한, Datastore는 Key를 범위로 하여 Scan연산이 할 수 있도록 인터페이스를 제공합니다. Java에서 제공하는 Try-with-resource문을 이용하여 ResultScanner를 반드시 닫을 수 있도록 하고 있습니다. 내부적으로 일단 특정 크기만큼 배치로 가져오고 더 필요한 경우 더 가져오는 식으로 구현되어 있습니다.try (CloseableIterable> entries = getDatastore().subSibling(fromKey, fromInclusive, toKey, toInclusive)) { for (KeyValue entry : entries) { // do something }}Secondary Index 구현 방법¶HBase는 데이터를 Row Key나 Column Qualifier로 정렬하여 저장합니다. 이 순서로만 Sequential Read를 할 수 있으며 Key값을 통해 특정 데이터를 바로 임의 접근할 수 있습니다. 비트윈에서는 특정 달에 해당하는 이벤트들을 읽어오거나 특정 날짜의 사진들의 리스트를 조회하는 등 id 순서가 아니라 특정 값을 가지는 데이터를 순서대로 접근해야 하는 경우가 있습니다. 이럴 때에도 효율적으로 데이터에 접근하기 위해서는 id로 정렬된 것 외에 특정 값으로 데이터를 정렬할 수 있어야 합니다. 하지만 HBase에서는 이와 같은 Secondary Index 같은 기능을 제공하지 않습니다. 비트윈 개발팀은 이에 굴하지 않고 Secondary Index를 간단한 방법으로 구현하여 사용하고 있습니다.구현을 간단히 하기 위해 Secondary Index를 다른 데이터들과 마찬가지로 특정 타입의 데이터로 취급하여 구현하였습니다. 따라서 Index에 대해서도 Column Qualifier가 발급되며, 이때, Index에 해당하는 id를 잘 정의하여 원하는 순서의 Index를 만듭니다. 이런 식으로 원하는 순서로 데이터를 정렬하여 저장할 수 있으며 이 인덱스를 통해 특정 필드의 값의 순서대로 데이터를 조회하거나 특정 값을 가지는 데이터에 바로 임의 접근할 수 있습니다. 또한, Index에 실제 데이터를 그대로 복사하여 저장하여 Clustered Index처럼 동작하도록 하거나, Reference만 저장하여 Non-Clustered Index와 같이 동작하게 할 수도 있습니다. Datastore 라이브러리에는 특정 데이터가 추가, 삭제, 수정할 때 특정 코드를 실행할 수 있도록 Trigger 기능이 구현되어 있는데, 이를 통해 Index를 업데이트합니다. 데이터의 변경하는 연산과 Index를 업데이트하는 연산이 하나의 Haeinsa 트랜잭션을 통해 원자적으로 일어나므로 데이터의 무결성이 보장됩니다.못다 한 이야기¶각 테이블의 특정 Row의 Column들에 대한 Column Qualifier외에도 Row에 대한 Row Key를 정의 해야 합니다. 비트윈에서는 각 Row가 표현하는 Root객체에 대한 아이디를 그대로 Row Key로 이용합니다. 새로운 Root객체가 추가될 때 발급되는 아이디는 랜덤하게 생성하여 객체가 여러 Region 서버에 잘 분산될 수 있도록 하였습니다. 만약 Row Key를 연속하게 발급한다면 특정 Region 서버로 연산이 몰리게 되어 성능 확장에 어려움이 생길 수 있습니다.데이터를 저장할 때 Thrift를 이용하고 있는데, Thrift 때문에 생기는 문제가 있습니다. 비트윈에서 서버를 업데이트할 때 서비스 중지 시간을 최소화하기 위해 롤링 업데이트를 합니다. Thrift 객체에 새로운 필드가 생기는 경우, 롤링 업데이트 중간에는 일부 서버에만 새로운 Thift가 적용되어 있을 수 있습니다. 업데이트된 서버가 새로운 필드에 값을 넣어 저장했는데, 아직 업데이트가 안 된 서버가 이 데이터를 읽은 후 데이터를 다시 저장한다면 새로운 필드에 저장된 값이 사라지게 됩니다. Google Protocol Buffer의 경우, 다시 직렬화 할 때 정의되지 않은 필드도 처리해주기 때문에 문제가 없지만, Thrift의 경우에는 그렇지 않습니다. 비트윈에서는 새로운 Thrift를 적용한 과거 버전의 서버를 먼저 배포한 후, 업데이트된 서버를 다시 롤링 업데이트를 하는 식으로 이 문제를 해결하고 있습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!