전체 피드 목록

바크 (Bark) 앱은 개의 대화법을 적용하여 주변의 서로 모르는 사람들과 소소한 소통이 가능하게 만들어주는 위치기반 채팅 서비스 이다. (앱을 모르는 분들은 아래 프리뷰 동영상을 참고해 주세요). 이번 글에서는 아주 단순해 보이는 바크 앱의 인터페이스가 의도한 사용자 경험에 대한 이야기를 해 보려고 한다. 결론부터 얘기하자면, 바크 앱의 '서로 개처럼 짖는다'라는 매우 심플한 인터페이스 이면에는 나름 깊게 고민한 태스크 분석 및 목표가 존재하고 있다는 것이다.https://www.youtube.com/watch?v=blwic1sMpOo<iframe width="940.000000" height="529.000000" src="//www.youtube.com/embed/blwic1sMpOo" frameborder="0" allowfullscreen="">'서로 개처럼 짖는다'의 심플한 인터페이스에 숨겨진 이야기나는 왜 모르는 사람과 대화를 하고 싶은가미국 유학시절 나를 종종 당황하게 했던건 바로 모르는 사람들이 아무렇지도 않게 내게 말을 걸고 대화를 건내던 순간이었다. 한국에서는 심지어 동네 주민이라 할 지라도 엘레베이터에서 서로 눈도 안마주치고 애써 대화를 피하던 우리나라사람으로서는 매우 어색하지 않을 수 없다. 지나가다 우연히 눈이 마주친 사람이 내게 인사를 건네고, 수업시간에 옆에 앉은 사람이 갑자기 어제 풋볼 경기 봤냐고 말을 건네고, 지하철에서 옆자리에 앉은 사람이 내가 읽던 책을 슬쩍 보더니 본인도 이거 읽어봤다며 갑자기 토론모드로 들어가던 기억들을 떠올려 보면, 우리나라사람들은 서로 단절된 삶을 사는것 같아 보인다.물론 모르는 사람들과 대화를 한다는게 얼핏 생각해보면 그리 유쾌할것 같은 느낌은 아니다. 우선은 내가 굳이 왜 모르는 사람과 대화를 해야하는지 목적이 불분명하기도 하거니와, 애써 말을 걸었다가 무시받거나 이상한사람 취급받을지도 모른다는 두려움, 또는 왠지 내가 어떤 불순한(?) 목적을 지닌 사람처럼 비춰져 보일수 있다는 불안감들로 인해 우리나라에서는 그 누구도 먼저 모르는 사람과 대화를 나누려 하지 않는다.하지만, 한편으로는 이런 생각도 든다. 내가 아무리 친한 친구들이 많아도 그들과 항상 대화하면서 살지 않는다. 여자친구나 아내, 남편이 아니고서야 매일처럼 서로 대화를 나눌 수 있는 '아는사람'들은 손까락에 꼽을 정도이다. 실제로 내가 회사다닐때를 떠올려 보면, 하루에 3시간씩 소모되는 그 지루한 출퇴근 시간동안 나는 친구들과 대화를 나누기 보다는 페이스북에서 뉴스를 읽거나 다른사람의 인스타피드를 보면서 시간을 보냈었다. 회사에서의 9시간동안은 거의 일과 관련된 대화들이 오가고, 심지어 점심시간에도 주로 동료들과 식사를 하기 때문에 역시 회사의 바운더리를 벗어난 대화를 해본적이 별로 없었다. 우리는 위에 언급한 여자친구, 아내, 남편 등 가족이외에 뭔가 대화를 나눌 수 있는 사람들이 정말 거의 없는 세상에 살고 있는 것이다.우리가 만일 내 주변에 같이 숨쉬고 있는 저 수 많은 '모르는' 사람들과 아무 거리낌 없이 대화를 나누고 뭔가 소소한 교류를 할 수 있다면 어떨까? 내가 아침에 일어났는데 모르는 사람들이 '지금 밖에 엄청나게 덥다'고 알려주고, 내가 야근하고 있는데 '나도 야근중인데 힘내세요!' 라며 서로 격려해주고, 점심시간에 서로 밥은 잘 먹었냐고 챙겨주는, 이런 아주 소소한 대화들이 주변의 모르는 사람들과 오갈 수 있는 온라인 세상에 대해 꿈꾸기 시작한 것이다.이런 배경으로 인해 바크 앱 인터페이스 디자인 목표는 바로 주변의 모르는 사람들과 소소한 대화를 가로막는 모든 장벽이 제거된 위치기반 채팅 서비스를 구현하는 것이 되었다.바크 앱의 목표는 주변의 모르는 사람들과 장벽 없이 소통하는 작은 세상을 만들어 주는 것이다.대화의 장벽에 대한 정의(데이팅 니즈와 같은) 특정한 목적이 있지 않고서야 저런 소소한 대화들을 온라인상에서 모르는 사람들과 나눈다는것은 거의 불가능에 가까운 일이다. 모르는 사람들끼리의 대화를 가로막는 수많은 장벽들이 존재하기 때문이다.1) 성별, 나이, 직업, 외모 등의 아이덴티티 요소우리가 대화를 서로 건낼 때 상대방에 대해 자연스럽게 파악하게 되는 (또는 파악하고 싶은) 다양한 아이덴티티 요소이다. 이런 아이덴티티 요소는 사람의 선호나 기대를 형성하는데에 아주 중요한 정보가 되기 때문에 서로의 선호가 맞지 않게 되었을때 초기 대화 자체가 성사되지 않는 원인이 된다.2) 대화의 정보를 전달해주는 언어 및 대화의 코드 요소실제 대화에 정보를 심어서 전달하기 위해 우리는 '언어'라는 도구를 사용한다. 당연히 영어, 중국어, 일본어 처럼 서로 사용하는 언어가 다르면 대화가 어려워 지고, 10대들이 쓰는 말, 50대가 쓰는말 등 세대적인 언어형태의 차이 역시 대화를 가로막는 장애물이 된다. 하지만 언어보다 더 큰 장벽은 바로 '대화의 코드'인데, 이는 사람들이 건내는 말의 이면에 숨겨진 목적이나 정보를 의미한다. 예를들어 누가 "오늘 날씨 참 좋죠?"라고 물어본다면 이 말은 단순히 오늘 날씨에 대한 정보를 전달하는것이 아닌 상대방에 대한 관심 표현, 지루하기 때문에 대화상대가 필요하다는 어떤 목적에 대한 표현 등 수 많은 레이어가 존재하고 있음을 의미한다. 이런 대화의 코드가 서로 명확하게 교환되지 않으면 그 대화는 어색해지거나 제대로 이어지지 못하게 된다.3) 대화가 서로 자연스럽게 진행되는데 필요한 대화의 맥락 요소대화의 맥락은 위에서 설명한 대화의 코드가 모여서 형성된다. 예를들어 "오늘 날씨 참 좋죠?"라는 질문에 "네 그러네요."라고 상대방이 답변을 했다면 그 이면에는 말은 건넨사람은 상대방에게 관심이 있는데 그 상대방은 별 관심이 없는 상황이다 라는 하나의 맥락을 발견할 수 있다. 대화의 맥락이 잘 연결되지 못하면 보통 대화가 중간에 끊기거나 서로 의도했던 목적이나 정보가 제대로 전달되지 않는 문제가 생긴다.앞서 말했듯이, 바크 앱의 UX 목표가 '대화의 장벽'이 제거된 채팅 서비스 구현이기 때문에, 바크 앱의 모든 인터페이스는 철저하게 위의 3가지 장벽을 완벽하게 제거하거나 줄이는 방향으로 설계되었다. 첫째, 아이덴티티 요소를 제거하기 위해 개의 캐릭터와 번호 부여바크 앱에서는 모든 유저가 8마리의 강아지 캐릭터 중 하나를 선택해야 한다. 물론 내 프로필에서 이 개의 '주인'이라는 의미에서 내 프로필 사진을 올릴수는 있지만 기본적으로 모든 채팅의 주체는 본인이 선택한 이 강아지 캐릭터를 중심으로 이루어 진다.모든 유저가 8마리의 강아지 캐릭터 중 하나가 된다.또한 바크 앱은 가입한 순서대로 번호를 부여받게 된다. 예를들어 처음 가입한 사람은 #1, 그 다음은 #2, #3 ... 등 번호가 계속 올라가는 방식이다. 2016년 7월 29일 4시 현재 #9845번까지 들어와 있다. 이 부분이 매우 중요한데, 번호를 부여받는 방식으로 인해 유저는 본인의 이름, 성별, 나이 등 그 어떤 아이덴티티요소를 노출하지 않음과 동시에 서로 오랫동안 소통한 사람이 아닌 경우 상대방의 아이덴티티를 잘 식별 불가능하게 하기 위한 의도가 있다. 이는 익명성과 비익명성을 동시에 지니게 하기 위해 나름 의도된 설계인데, 예를들어 내 번호가 #245번이라고 한다면, 내가 자주 짖는 우리집 근처의 유저에게는 나름 '아 저 번호가 내 근처에 살고있는 사람'이라는 아이덴티티 식별이 가능하지만 내가 다른 지역에 가거나 새로운 사람이 우리 지역으로 와서 서로 짖을경우 #245번이라는 번호는 누구인지 전혀 식별 불가능한 익명성을 띄게 된다.이렇게 강아지 캐릭터와 식별번호를 통해 바크 앱의 모든 유저는 서로 철저하게 모르는 사람이 됨과 동시에 짖는 행위를 통해 아는사람이 되기도 하는 익명성과 비 익명성을 동시에 지니게 설계한 것이다.모든 유저는 이름이 아닌 식별번호를 부여받는다.둘째, 언어 및 대화의 코드 요소를 제거하기 위한 개의 대화법 적용개들이 서로 소통하는 방법은 여러가지가 있겠지만 우리가 주목한 방법은 '서로 짖는다' 이다. 물론, 개들끼리 서로 짖는 목소리 이면에 숨겨진 다양한 코드와 맥락을 이해하면서 대화를 나눌 것이다. 하지만 위에서 언급한바와 같이 대화의 코드와 맥락이 복잡할 수록 대화를 가로막는 장벽으로 작용한다. 따라서 바크 앱 에서는 서로 짖는 행위는 철저하게 '내가 익명의 주변 사람들에게 말을 걸다'의 의미로 사용된다. 다시말해서 내가 지하철에서 옆에 앉은 사람에게 "오늘 날씨 좋네요?"라고 물어보는 행위가 '나는 너에게 말을 걸고있다'라는 의미로 사용되듯이, 바크 앱에서는 내가 바크 버튼을 눌러서 반경 1마일 이내의 유저들에게 짖는 행위로써 말을 거는 것이다.또한 단순히 짖는 행위에 다양한 감정을 실어서 전달할 수 있도록 바크의 파형, 짖는 소리가 누르는 액션에 최대한 연속적으로 반응 가능하도록 설계되었다. 즉, 내가 뭔가 신이 나서 좀더 리드미컬하게 짖고 싶다면 바크 버튼을 보다 연속적으로 빠르게 누를 수 있고, 이 반응속도를 최소화 하여 리드미컬한 사운드와 바크의 파형이 퍼져나가도록 디자인 된 것이다. 이를 통해서 유저들은 이 '서로 짖는다'라는 개의 대화법 하나로 말을 거는 것 이상의 의미가 포함된 복잡한 대화를 연결해 나가곤 한다. 실제로 강남 지역에서 누가 한번 짖기 시작하면 많은 유저들이 습관적으로 반응하여 서로 짖게 되고, 마치 그룹 챗에서 카톡 메시지가 오가듯이 바크 사운드와 파형이 지도상에서 번쩍거리는 진풍경이 연출된다.셋째, 대화의 맥락요소를 제거하기 위한 메시지 바크위에서 언급한 3가지 대화의 장벽을 너무 최소화 할 경우 필연적으로 부딪치는 문제가 있다. 바로 '대화가 지속되지 않는다'라는 문제이다. 대화라는 것은 서로의 언어를 통해 정보를 교환함으로써 의미가 있다. 이 정보 교환에는 굳이 말 자체가 가진 의미 뿐만 아니라 대화의 코드 및 맥락요소도 같이 조합되어 이루어지기 때문에, 맥락요소를 아예 제거해 버리면 대화가 길게 진행되지 않는 문제가 생기는 것이다.이 부분을 해결하기 위해 디자인 된 것이 바로 메시지 바크이다. 메시지 바크 인터페이스의 목적은 대화의 맥락요소를 최소화하면서도 유저들간의 대화가 계속 이어지도록 정보교환이 가능하게 하기 위함이다. 아래 그림과 같이 유저는 바크 버튼을 3초간 누르고 있으면 영문 20자 이내, 한글 10자 이내의 짧은 단문 메시지를 전송할 수 있다. 이때, 메시지가 표현되는 방식에서 다른 채팅방식과 큰 차이가 있는 것인데, 일반적인 채팅에서는 말풍선 메시지가 순차적으로 올라가면서 대화가 연결되기 때문에 대화의 맥락이 형성된다. 따라서 누가 다른 말을 하게되면 그 대화의 맥락이 끊어지게 되서 대화가 종결되거나 어색해 지는 경우가 생긴다. 하지만 바크 앱에서는 메시지가 맵 상에서 캐릭터의 말풍선 메시지로 표현된다. 이 방식이 주는 장점은 유저가 능동적으로 저 맥락을 만들수도 있고, 맥락에 상관 없이 받아들일수도 있다는 것이다. 다시 말해서, 메시지를 보내는 사람은 지금까지의 맥락과 전혀 상관 없는 대화를 건네도 전혀 상관이 없다는 것이다.실제 사람들의 바크메시지 대화. 맥락요소가 최소화된 그룹챗 인터페이스 이다.또한, 좌측 사이드바를 통해 지금까지의 메시지 바크를 위도-경도 약 2km의 zoning으로 구역화하여 저장하고, 유저들은 해당 지역에 지금까지 건네진 메시지 바크를 읽어볼 수 있다. 마치 그룹 채팅방에서 이전 대화를 각 위치별로 열람해 보는것과 같은 기능이다. 이를 통해서 유저가 맥락을 능동적으로 찾게 되고, 맥락때문에 대화가 끊어지는 문제를 최소화 하면서 대화가 지속 가능하도록 설계된 것이 바로 메시지 바크인 것이다.지역별로 2km의 존이 있어서 해당 지역의 대화내용을 열람해 볼 수 있게 함으로써 맥락을 이어나갈 수 있도록 유도했다.위치기반 채팅의 새로운 실험바크 앱은 분명 기존의 소셜네트워크가 설정한 일반적인 소통방식의 컨벤션을 완전히 벗어나 있다. 소비자가 너무 새로운 방식을 접했을 때 그 가치를 이해하지 못하면 그 서비스는 정착하기 어렵다. 이 때문에 바크 앱은 아직도 베타테스트 중이다. 2016년 5월 18일 첫 버전을 iOS 버전으로만 런칭하였고, 아이폰에서 유입되는 유저만으로 다양한 기능들을 테스트하면서 지금까지 왔다. 이제 약 3개월간의 베타테스팅 기간 끝에 8월 중순경 안드로이드 버전을 런칭하면서 정식 서비스를 시작할 계획이다.이 실험이 성공할지 실패할지는 사실 아직도 잘 모르겠다. 현재까지 유저의 사용성을 분석해 보면 분명 강남역, 홍대, 신사등과 같은 유저 밀집지역에서는 Day 60 리텐션이 60%를 상회할 정도로 높게 나온다. 하지만, 지금처럼 서로 비슷한 목적의 카피캣만 난무하는 소셜미디어 영역에서 특정 목적을 가지고 새로운 방식을 시도해 보는것 하나로도 의미가 있다고 생각한다.글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기

비트윈에서는 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]로 이메일을 주시기 바랍니다!