America was built on dreams. And it’s lost. When I say I’ll start a motorcycle company, 99% of the people tell me it’s impossible. Nothing is impossible. It’s America. As an american company, anything is possible.

Scott Colosimo

CEO, Cleveland Cyclewerks

http://www.clevelandcyclewerks.com

Marc Andreessen

American entrepreneur, investor, and software engineer. 

coauthor of Mosaic, the first widely used Web browser

cofounder of Netscape Communications Corporation

cofounder and general partner of Silicon Valley venture capital firm Andreessen Horowitz. 

He founded and later sold the software company Opsware to Hewlett-Packard. 

cofounder of Ning, a company that provides a platform for social networking websites. 

He sits on the board of directors of Facebook, eBay, and HP, among others. 

A frequent keynote speaker and guest at Silicon Valley conferences, Andreessen is one of only six inductees in the World Wide Web Hall of Fame announced at the first international conference on the World Wide Web in 1994.

http://en.wikipedia.org/wiki/Marc_Andreessen

Dave McClure

출처: 
http://practicetrumpstheory.com/innovation-accounting/
http://en.wikipedia.org/wiki/Dave_McClure
https://www.linkedin.com/in/davemcclure

leancanvas-poster-36hx54w.pdf

스타트업을 시작하기전에 다음과 같은 비지니스 플래닝을 해보자.

Lean Canvas (Ash Maurya)

출처: Ash Maurya (http://practicetrumpstheory.com/)

+

Happiness in Business (Bud Caddell)

출처: Lean Analytiics

단순히 좋은 비지니스 모델만이 스타트업 성공요인이 되는것은 아니다. 

스타트업을 드라이브하기위해 내 자신이 얼마나 준비되어 있는지도 중요하다.

소셜커머스엔 약점이 하나있다.

소셜커머스의 원래 의미가 모던간에 최근 대한민국 소셜커머스 마케팅 전략은 최저가 보장이다. 고객들도 소셜커머스하면 "싸다", "반값" 등의 이미지가 떠오른다. 그렇기 때문에 고객의 유출입이 가장많은 리테일 비지니스이기도 하다. 

고객이 찾는 싼 가격의 상품이 검색을 통해 있으면 바로 구매를 하고, 심지어 오프라인 매장 방문 후 상품을 눈으로 확인하고 그 자리에서 소셜커머스 구매를 하는 고객도 있다. 많다.

하지만 이건 분명 양날의 검이다. 최저가가 아니면 구지 해당 업체에서 구매를 할 이유가 없기때문이다. 요즘 같은 시대에 누가 한 업체에만 가입하고 한 업체에서만 구입하는가? 5-6 업체의 계정을 보유하고 쇼핑 시 가격을 일일이 비교하며 구입하는게 마치 쇼셜커머스 매니아들에겐 자랑스러운 "소셜 쇼핑 기술"로 여겨지고 있다. 한땐 "옥션 기술"이 대세였지만... 하여튼 소셜커머스에겐 경쟁업체가 너무 많다. 예를들자면 타 소셜업체, 오픈마켓, petpang.com과 같은 전문용품 취급 업체, 브랜드, 오프라인업체. 이러한 경쟁구도에서 최저가로 승부하는게 과연 옳은 마케팅 전략일까?

소셜커머스에서 다른 마케팅전략을 들고 나오면되지 않는가?

아까도 말했지만 최저가 전략의 가장 큰 문제는급변하는 소비자 유출입이다. 먼저 유입을 늘리기위한 가장 공격적인 전략은 물론 광고이다(신규 고객 유치). 마치 이것을 잘 아는지, 한국 3대 소셜업체(쿠팡, 티몬, 위메프)에서는 거액을 들여 광고를 해왔고 특히 쿠팡과 티몬같은 경우 벌써 TV 광고 1ROUND, 2ROUND를 지나 3ROUND까지 왔다. 그 사이 이들은 수많은 타 업체와의 경쟁에서 이겨왔고 그들을 완전 아웃시키는 무서움을 과시해왔다. 대신 많은 사람들이 알고 있듯이 이들에겐 순익이 거의 없다고 보면 된다. ZDNet 조사에 의하면 월평균 100억원을 마케팅 비용으로 날려버리는 악순환에 빠지고 있다. 그만큼 안하면 순위경쟁에서 밀리니까... 마치 월급쟁이가 급여일날 반짝 좋다가 카드값 지출에 통장잔고 차이가 없는것에 멍때리는 것과 비슷하다. 월매출, 총 거래액은 이들에게 빚과 같다. 다음달되면 마케팅 비용으로 빠져나가게 된다.

반면 유출을 막는 방법도 있다. 첫 방문 또는 구매 고객의 로열티(충성도)를 높여 재방문율, 재구매율을 높이는 방법이다. 또는 이탈한 고객의 재방문을 유도하는 방법이 있다. 각각 customer retention, reacquisition 이라 불리는 두 전략은 어느 비지니스에나 중요한 마케팅전략으로, 무에서 유를 창조해야하는 단순 광고를 통한 신규고객 유치 방식보다는, 이미 고객 정보와 심리를 알고 있는 상태에서의 마케팅 비용은 훨씬 적은 비용으로 재방문, 재구매율을 높일 수 있다. 

하지만 주요 소셜커머스에는 이러한 고개 유지/유출방지 전략이 뚜렷하지 않다. 기껏해봤자 이메일 또는 모바일 앱푸시나 티몬과 위메프가 한때 잠깐 시행했던 포인트 적립이 전부이다. 광고비용에는 몇 백억씩 투자하면서...

고객 유지에 신경쓰지 않는 이유는?

티몬이나 위메프 같은 경우 대한민국 3대 소셜커머스 경젱 궤도에 올라가기 위해 공격적인 마케팅을 위해 포인트 적립 전략을 세웠다. 파격적으로 구매금액에 묻지도 따지지도 않고 무조건 3~5%를 적립시켜주는 제도이다. 이미 시장 최저가에서 아무 이유없이 추가할인을 시켜주니 고객 입장에선 그아닌 황금잉어가 아닌가. 티몬위메프 입장에서도 포인트로 돌려주는것이니 고객 재방문율을 높이고 전체적인 PV, UV를 높이는데 큰 일조를 했다. 덕분에 쿠팡을 따라잡고 지금은 3대 경쟁구도에 있다. 하지만 그 놈의 최저가가 문제이다. 3대 소셜커머스 업체는 애초부터 고객 인식을 잘못세웠다. "소셜커머스하면 최저가"라는 전략은 정말 누가세웠는지, 서로 무덤을 판 셈이다. 소셜커머스 = 최저가, 소셜커머스 = 반값이란 소리는 한국에서만 들어본다. 최저가에 부족해서 포인트 rebate 까지 제공하니 너무 많은 피를 흘린 것이다. 최저가가 아니면 소셜을 사용할 필요가 없다는 인식만 늘어가고 있다.

공격적인 고객유지 전략을 세우지 못하는 이유는 이 최저가 인식에 원인이 있다. 일반적인 고객유지 전략은 1) 포인트 2) 할인쿠폰 3) 차별서비스 4) 고객감동인데, 이미 최저가를 제공하는 상태에서 포인트, 할인쿠폰등의 원래 상품의 가격을 단계별로 낮춰 고객을 낚시질하는 전략은 너무 많은 피를 흘리게 한다. 쿠팡은 애초부터 이런 오퍼는 없었고, 위메프도 고객을 실망을 자초하면서 까지 이러한 제도를 없엤다. 티몬이 그나마 아직까지 피를 흘리는 중이다. 이러한 이유에서 3대 소셜 업체에서 차별화된 서비스, 고객 감동 등으로 고객 인식 변화를 바꾸고 마케팅 전략을 바꾸려 하지만 쉽지는 않다. 빠른배송, 모바일앱, 사용자 편의성, 정확한 명칭은 모르겠지만 홈페이지에 보이는 광고드립(?), 야구티켓예매 등이 있지만 이러한 전략은 고객과의 소통에 매우 소극적이고... "저렇게 해서 어느세월에 충성고객 확보할레? 그전에 소셜경쟁 다 끝나겠다 ^^;;"

개인적인 생각이지만 이들 TV광고에 누가나오는지는 더이상 중요하지 않은것같다. 요즘 쿠팡,티몬,위메프 모르는 온라인 샤퍼도 있나? 신규고객확보 전략은 이제 적당히 하면될것같다. 이들에게 중요한건 이미 한번 방문/구매를 했던 고객을 사로잡것이 더욱 중요하고, 역으로 이러한 고객 집단이 블루오션이고 낚시(?)하기 좋은곳이다. 아직까지 포인트제도와 고객등급제도를 유지하는 티몬의 전략 결과도 궁굼해진다. 셋중 어느 업체가 최저가 전략과 상반되는 보유고객유지 퍼즐을 풀 수 있고, 어떻게 풀어갈까? 싸움을 구경하는 입장에서는 참 흥미로운 싸움이다^^;

One character I found among Koreans is that they're afraid of losing so many things.

They follow very imaginative ideology, great in number of directions, which it could be a good thing, but the actions never come into reality. They are always progressive in directions, but never progressive in distance. I wondered why.

Americans are accustomed to losing many things while they are grown up. They learn what sacrafices mean, and it dosn't always mean bad. Which makes them ready to take on any challenges ahead.

Kids in Korea rarely do understand what losing means. They are only accustomed to gain. More allowances, more studying, better education, better house, and better vehicle. As if all these gains are promised even before they were born. They are not taught to sometimes take a traceback or sacrifice something for better mean, as if tracing back means "loser" in their society.

When they come to deciding something, as any decision requires some sort of sacrifice, their profeciency of imagery bewilders, and their imagination becomes an imagination.

Coudera 5 beta 2 설치 영상을 준비해봤습니다.

아무리 하둡 전문가라해도 클라우데라를 처음 설치하시는 분은 한두번은 재 설치하게되고 OS 구성이 꼬이게 되는 경험을 해보셨을 것입니다.

타르볼 수동 설치와는 달리 클라우데라는 실수를하거나 전단계로 돌아가는게 안되, 한번 잘못 진행하면 처음부터 다시 시작해야하기 때문입니다.

비록 어려운 과정은 아니지만 클라우데라 설치를 한방에 완료하기 위해 동영상을 준비했습니다.

보통 NoSQL을 처음 접하고 서비스에 사용될 오픈소스 NoSQL을 찾다보면 가장 먼저 하는 질문이 어느 제품을 써야하나? 이다. 간단히 말하면 빅데이터 개발자는 모든 schema-less Bigdata DB 제품을 통틀어서 NoSQL이라 부르지만 사실상 모든 NoSQL 제품마다 사용되는 용도와 적합한 환경이 제각기 다르다. 그렇기 때문에 각 NoSQL의 용도와 접근 패턴별 성능, 확장성, 안정성 등을 요구사항에 맞춰 선택해야 한다. 

상용 솔루션을 사용할 경우 각 제품 세일즈 대표나 컨설턴트가 각기 제품의 특성을 잘 설명해주겠지만, 오픈소스의 경우 그렇지 않다. 온라인 BMT 자료도 오래된 것이 많다. 그렇기에 본인이 직접 NoSQL 성능 테스트를 쿼리 유형 및 패턴별 성능 테스트를 할 수 있게하는 오픈소스 툴이 있는데 YCSB (Yahoo Cloud Service Benchmark: https://github.com/brianfrankcooper/YCSB)이라 한다. 

NoSQL 테스트 프레임은 이미 brianfrankcooper라는 사용자가 이미 3년전에 개발하였고 정말 다양한 사용자가 각기 시스템과 NoSQL에 맞춰 참여하고 있다. 별도의 코드리뷰 및 CI 없이 진행되는 오픈소스라서 테스트 프레임과 초기에 제공된 NoSQL 모듈 (HBase, Cassandra, MongoDB, Redis)를 제외하면 코드가 약간 중구난방이다. 코드 라인 수에 비해 포킹된 수는 300개 가량이다. 각 회사와 개발자의 특화된 시스템과 NoSQL에 맞추어 테스트 하다 보니 포킹 수가 많아진 듯하다. 여러분도 신규 버전이나 특화된 NoSQL을 테스트하려면 최소한의 코드 수정 또는 모듈 개발은 필수적으로 보인다.

YCSB 내부 아키텍처를 설명하기 전에 짚고 넘어가야 할점은 온라인 커뮤니티에 올라온 대부분의 NoSQL 성능 비교 자료를 믿으면 안된다. 자료가 사실적이지 못하다는 말이 아니고 그 자료에서 결론지은 성능이 여러분이 사용할 시스템에서도 똑같이 나올 확률은 비교적 적다. 비슷하게라도 나오면 다행이다. 한명의 시스템 디자이너가 로우레벨부터 사용자 인터페이스까지 모두 동일하게 구성하지 않는 이상 작은 설정차이 하나에도 시스템 성능은 매우 크게 급변할 수 있다. YCSB는 그런점에서 NoSQL 커뮤니티에 제공할 객관적인 성능비교 툴로 사용되기 보다 현재 손앞에 놓여진 시스템 클러스터와 사용자 엑세스 패턴에 가장 적합하고 빠른 성능을 내는 NoSQL을 주관적으로 선택하고자 사용되는 Decision-making 툴에 가깝다. 그러므로 야후에서 발표한 YCSB 성능비교 자료(http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf)나 앞으로 본 블로그에 올라오는 성능비교 자료는 참고자료로만 사용하면 좋겠다.

각 시스템 별로 성능 변화에 영향을 줄 수 있는 영역은 다음과 같다.

• 하드웨어 성능 - 동일 클러스터에 YCSB 테스트를 진행하여 하드웨어 성능 차를 최소화 할 수 있다. 
  
  
• 네트워크 성능 및 구조 - 네트워크 의존도가 높은 NoSQL과 그렇지 않은 NoSQL을 비교할 경우 네트워크 성능은 큰 변화를 줄 수 있다.
  
• NoSQL 아키텍쳐 또는 소프트웨어 버전 - NoSQL 코어와 아키텍쳐에 따라 사용되는 용도가 결정되는데 이 부분이 YCSB를 사용하여 확실한 성능을 확인하고자 하는 부분이다.
• Consistency
• Read 최적화 or Write 최적화
• Availability (데이터 이중화 및 복제)
• 캐쉬 기술 적용
• B+tree, B-tree, Log-structured Merge Tree 등
  
• NoSQL 설정 및 튜닝 노하우 - NoSQL 시스템 운영자의 숙련도 및 튜닝 노하우 깊이에 따라 결정되는 부분이라 YCSB 결과를 크게 결정하는 부분이며 NoSQL 성능 비교에 가장 큰 논점이 되는 부분이다. 
  
• 데이터 스키마 및 키 디자인 - 스키마 디자인에 따라 NoSQL 성능 역시 크게 변할 수 있다. 흔히 Row Key 디자인과 Column Key 디자인을 일컫는데, 데이터 쿼리 요구사항에 맞추어 Workload Generator를 적당히 구성하면 된다.
  
• 사용자 엑세스 패턴 - 스키마 디자인이랑은 다른 영역이다. 스키마 디자인은 어떻게 데이터를 DB상에 보관하느냐이고 엑세스 패턴은 데이터를 어떤 패턴으로 읽느냐는 것이다. 
• Read와 Write 비중
• 랜덤 및 시퀀셜 쓰기
• 배치 및 실시간
• 최신 데이터 및 아카이브 데이터 쿼리 
  등 다양한 패턴이 있지만 이도 스키마 디자인과 마찬가지로 요구사항에 지정되어 있으므로 비교 NoSQL 양측에 동일하게 Workload 를 구성하면 된다.

YCSB

Yahoo! 에서 사용되는 PNUTS와 최근 급격히 늘어나는 타 NoSQL 솔수션을 비교하기 위해 자체 오픈소스 NoSQL 벤치마크 테스트 툴을 개발하였다

YCSB는 크게 다음과 같이 두 부분으로 나누어진다

• YCSB 클라이언트 – 워크로드를 생성하고 NoSQL DB Connector 역할을 한다
• 워크로드 패키지 (Property file 포맷) – 워크로드를 생성하는데 필요한 설정 값 리스트

Cloud DB는 테스트 대상인 NoSQL을 말하는데 현재 다음과 같은 제품을 모듈 형태로 지원한다.

• PNUTS
• BigTable
• HBase
• Hypertable
• Azure
• Cassandra
• CouchDB
• Voldemort
• MongoDb
• Infinispan
• Dynomite
• Redis
• GemFire
• GigaSpaces XAP
• DynamoDB

기본 제공되는 제품 버전은 최상위 pom 파일을 보면 알수 있는데, 대부분 조금씩 시대에 뒤떨어진 버전일 것이다. 최신 버전을 테스트 하는 경우면 pom 파일을 수정하여 버전을 바꾸고 컴파일 하면 되고 (다소의 코드 수정 필요), 신규 NoSQL 모듈을 추가하고 싶으면 https://github.com/brianfrankcooper/YCSB/wiki/Adding-a-Database 위키를 참조하면 된다. CREATE, READ, SCAN, UPDATE 등의 DB 인터페이스 레이어만 작성하면 간단히 추가할 수 있다. 다른 개발자에 의해 포킹된 버전을 찾는것도 한 방법이긴 하지만 메인프레임에 없는 코드면 새로 작성하는게 더 빠를듯 하다.

테스트

Workload

성능 테스트는 사용자 접근 패턴에 맞는 워크로드를 사용하여 YCSB 내부적으로 테스트를 진행한다. 워크로드는 다음과 같이 기본 제공되는 워크로드와 사용자 정의 워크로드를 사용할 수 있다.

(다음 워크로드는 YCSB 프로젝트 홈 아래 workloads 디렉토리에서 확인 가능)

Workload A: Update Heavy (read 50%, update 50%)
실무 예) 최근의 액션을 저장하는 세션 정보 어플리케이션

Workload B: Read Heavy (read 95%, update 5%)

실무 예) 포토 태그 – 태그는 한번만 작성하고 주로 읽기 작업이 실행된다

Workload C: Read Only (read 100%)

실무 예) 사용자 프로파일 캐시 – 외부 저장소에 저장되어 있는 사용자 정보를 조회

Workload D: Read Latest Record (read 95%, insert 5%)

레코드 선택 알고리즘: Zipfian

실무 예) SNS 사용자 상태 업데이트 – 가장 최근의 상태와 뉴스만이 중요함

Workload E: Short Range Scan (read 95%, insert 5%)

각 작업마다 100개 내외의 레코드 영역을 한번에 쿼리 한다

실무 예) 쓰레드 형식의 게시판 – 각 조회마다 포스트의 쓰레드를 스캔 한다

Workload F: read-modify-write

읽기, 수정, 쓰기의 단계를 순서대로 수행

실무 예) 사용자 데이터베이스 – 각 사용자 활동마다 사용자 레코드를 읽고 업데이트 한다

DB 접근 패턴은 매우 다양하므로 사용자 요구사항에 맞춰서 워크로드를 구성하면 된다.

아래부터는 YCSB에서 제공하는 프레임은 아니고 사용자가 위에서 설명한 YCSB 툴을 이용하여 직접 테스트 해볼 수 있는 항목이다.  

Tier1 - Performance

동일한 하드웨어 구성에서 데이터 로드에 변화를 주어 성능을 측정하는 테스트이다. 사용자가 목표 쓰루풋을 지정하고 위의 워크로드를 실행하면 평균 응답시간(latency)을 받을 수 있다. 쓰루풋을 높일 수록 응답시간은 길어지는데 특정 쓰루풋에서 응답시간이 매우 높아지거나 응답이 안오는 지수가 있다. 이 지수를 해당 시스템위에서의 NoSQL 최대 쓰루풋이라 보면 된다.

Tier2 - Scaling

Scale Up - 클러스터의 워커 노드가 증가함에 따른 성능 차이 테스트이다. 테스트 방식은 데이터를 미리 클러스터에 로드 하고 10분정도 기다린다 (데이터가 클러스터에 분산되고 안정화되는 시간). 그 다음엔 원하는 워크로드와 쓰르풋 (Tier1에서 찾은 최대 쓰르)을 지정하여 성능을 테스트한다. 테스트를 종료하고 노드를 추가한다음 같은 테스트를 다시 진행하여 응답속도에 대한 변화를 찾아낸다. 노드를 증가하면서 테스트를 반복한다. 
테스트 중간중간에 쓰루풋 목표치를 변경하여 노드 증가에 대한 쓰루풋 변화도 테스트 해볼 수 있다.

Elastic Speedup - 작동중인 클러스터에 워커 노드를 추가했을 경우 성능 측정을 위한 테스트이다. 위 Scale Up 테스트와 혼돈 될 수 있는데 Elastic Speedup은 응답속도 성능을 측정한다기 보다, 노드가 추가되는 순간 클러스터에 가해지는 성능 임팩트와 클러스터가 안정화되는 시간을 측정해볼 수 있다. 예를 들어 카산드라의 경우 노드가 추가되는 경우 리전 별 키 영역을 다시 계산하고 데이터 발란싱 또는 이동이 집약적으로 발생한다. 이러한 노드 추가에 대한 클러스터 성능 영향도를 측정해 볼 수 있다. 

Tier3 - Availability

야후에서는 Availability라고 부르는데 사실은 Failure Test이다. 위의 Scale Up과 Elastic Speedup 과 비슷한 테스트이지만 노드를 증가 하는 대신 클러스터에 장애를 발생한 후 클러스터의 성능을 측정하는 테스트이다. 테스트 가능 장애 유형에는 호스트 셧다운, 디스크 장애, 네트워크 장애 등이 있다. 대부분의 NoSQL의 경우 CAP 정의 Partition Tolerance를 적용하므로 특정 노드 접근이 안되어도 클러스터는 정상 작동할 것이다. 대신 이러한 장애 발생시 성능에는 필시 변화가 발생하고 데이터 손실에 따른 안정성 변화가 있을 것인데 이를 측정하기 위한 테스트이다.

Tier4 - Replication

각 클러스터에 설정한 복제계수(Replication Factor) 변화에 따라 필시 성능 변화도 있을 것이다. 복제계수에 변화를 주며 테스트할 수 있는 영역은 Performance, Availability, Consistency, Locality (server, rack, cluster, datacenter..)이다. 눈으로만 외우지 말고 각 항목이 무엇을 의미하는지 생각해 보자.

야후에서 발표한 벤치마크 테스트의 경우 Tier3와 Tier4는 테스트에 따른 장애 유형과 테스트 방식이 복잡하여 향후과제로만 남겨뒀다. 내가 보기에도 왠만한 NoSQL 성능 측정은 Tier1과 Tier2로도 충분해 보인다.

참고자료

https://github.com/brianfrankcooper/YCSB
Yahoo! Cloud Serving Benchmark. Brian F. Cooper. Yahoo! Research
Benchmarking Cloud Serving Systems with YCSB. Brian F. Cooper. Yahoo! Research

이진분류 (Binary Classification)

True Positive = 코드에 문제가 없으며, 테스트가 문제를 발견하지 않음

True Negative = 코드에 문제가 있으며, 테스트가 문제를 발견함

False Positive = 코드에 사실 문제가 없지만, 테스트가 문제를 발견함

False Negative = 코드에 문제가 있지만, 테스트가 문제를 발견하지 못함