순서대로라면 '요즘 쓰고 있는거 리포팅, 소감 #1'의 #2가 나와야겠지만, 뭐 언제부터 내가 순서 따졌냐.

당장 쓰고 싶은대로 NoSQL부터.

NoSQL그림 별로 안이쁘다. 근데 이 것만한 그림이 구글에 안보이더라.

요즘 진행하는 프로젝트에 Cassandra를 포팅해보고 있는데, 먼저 밝히고 가야할 것 먼저.

  1. 대용량 데이터? 오우 노. 일단 global 서비스다보니 대용량이 될 가능성은 있지만, 게다가 log성 데이터이기에 또 다시 가능성이 있지만, 굳이 NoSQL을 쓸 필요는 없단게 현재의 판단.
  2. performance 이슈 가능성? 이 역시 희박. 게다가 대기업 답게 눈먼 돈이 많아서 peformace 이슈는 인프라 투자로 생각 외로 쉽게 풀 수 있다는.

그럼에도 불구하고 NoSQL을 건드리는 이유는,

  1. 현재의 화두이니깐(현재라고 말하는 것도 우스울 정도로 몇 년 지났지만, 여전히 화두임에는 의심의 여지가 없지?).
  2. 뭘 알아야 쓰건 안쓰건 선택이라도 할 수 있지.
  3. 기술이 요구를 창출하는 건 비일비재하니깐.
  4. 요즘 시간 많이 남아 도니깐.

NoSQL 솔루션 중 가장 잘나가는 듯한 형국을 보이는 Cassandra 낙점. 그 많은 솔루션 중 Cassandra를 선택한 여러 이유 중 가장 큰 건 아마도 Twitter가 Cassandra를 앞으로도 더 많이 적용할 예정이란 소리를 들어서겠지(by Ryan King of Twitter. 이외에 NoSQL 비교를 잘(?)한 요런 포스트도 있는데,, 비교를 너무 평면적으로 했다는 생각이..)


CassandraCassandra.. 그리스신화의 그녀 이름을 딴 요 센스는, Cassandra의 가장 잘 나가는 high level client인 hector의 명명에까지 영향을 미치네. 근데 난 hector를 안쓰고 그의 아들인 Astyanax를 썼다. CQL3를 지원한다는 단 하나의 이유로.

일단 컨텍스트 먼저 말하자면, 

SQL table 중 in/output이 많고도 join 등의 (쫌) 복잡 연산이 작은 두 놈을 고르고, 첨 배우는 상황이라 요 두 table scheme 모양새까지 그대로 똑같이 포팅. Cassandra의 column family란 개념은 SQL의 table과 그닥 별반 차이가 안나서리,, 용이하게. 게다가 CQL이란 SQL clone인 언어까지 제공하다보니,, 해피하게 진행. 그러다보니 사실 NoSQL을 쓴다는 설계 상 어떤 주요 특이점이 없어진 상황.


  • 실제 고민했던게,, 그럼 내가 왜 고생하면서 NoSQL을 쓰지? 란 근본적 질문까지 자문했다는. 내 초반 설계가 잘못한건 아닌게, 이렇게 시작하는 것이 그닥 틀리지 않았다는 걸 말해주는 요런 포스트가 보인다.
  • CQL을 첨부터 쓴건 아닌데, 이를 본격 쓰게 된 이유는 CQL(version 3 not 2)을 안쓰면 composite key 생성 코드가 아주 지저분하기 때문이다. Cassandra의 composite key는 SQL의 그것과는 다른데, 일단 composite key란 것은 없고, 무조건 단일 key만 수용하는데, composite key 요구에 대해서는 pivoting 비스무리한 개념을 통해 처리한다. 이로 인해 wide row란걸 권장하는 편. 자세한 건 'cassandra composite key'라 구글링하면 우후죽순으로 포스트가 떨어지니 요기선 생략.


근데,, 아니 이게 왠 일인가.


복잡하다고 전혀 말할 수 없는 Where 절의 조건 몇 개.. column 4개 정도 참조하는 그 절 처리 속도가 입이 딱 벌어지게 느린거다(사실, client에서는 connection timeout에 걸려 아예 실패를 해버렸다..).

secondary index 생성 속도가 느려서 나중가면 빨라지겠지..라고도 생각했는데, 이는 헛 생각(Cassandra는 key가 아닌 column에 조건을 걸려면 무조건 해당 column에 index를 넣어야 한다)임으로 결과 보기를 포기.


이리저리 뒤져봤지만 딱히 답이 안보여, 걍 내 설계에 문제가 있겠거니 하고 잠시 진행을 중단하고 데이터 모델을 되돌아보는 상황 ㅜㅠ.


이제부터는 그간의 깨달음(?)과 의문.

물론 아래 나열할 깨달음은 추후 update될 즉, 잘못된 깨달음일 가능성이 아주 풍부하다(내가 지금 NoSQL을 얼마나 안다고 '깨달음'씩이나 언급할까 ㅡㅡ;;).


  1. denormalization은 내게 duplication과 별로 다른 개념이 아니다(물리적 관점에서). 그나저나 denormalization한 데이터에 대한 update는 어떻게 이루어야 하나? 해당 중복 데이터의 일치성 보장은 어떻게 이루나? => 내 잠정적 결론은 update가 필요없는 데이터에만 denormalization을 적용하는 것임(Cassandra의 초창기에는 insert, delete, retrieve 연산만 있었다나? CRUD 중 Update가 빠졌다는 데에 힌트가).
  2. join은 말할 것도 없고 where 절 사용할 만한 query가 있다면 이는 잘못된 scheme design을 탓해야. 만약 design으로도 해결 못본다면 그건 NoSQL을 사용할 곳이 아니라는 뜻.
  3. query를 먼저 생각하고 scheme design을 하라는 NoSQL design practice가 보이는데(위의 링크도 마찬가지), 이 말은 NoSQL은 용도 확장성에 닫혀 있다는 뜻으로 들린다. 대강 potential과 performance/scalability를 트레이드오프한 것이라 봐도 될까?
  4. NoSQL이 그토록이나 SQL과는 다른 놈이라면, Cassandra는 SQL이나 다름없는 CQL을 도대체 왜 제공할까?(CQL 뿐 아니라 JDBC까지 제공하고 있는 형편이다!) 많은 NoSQL practice에서 SQL 설계 패턴을 잊으라는데, CQL을 제공한건 그 잊으라는 설계 방향과 완전히 반대로 나아가는 진행이다.

뭐 이리저리 질문만 많이 던지며 NoSQL - Cassandra에 대한 의구심을 잔뜩 표한 듯 한데, 이 모든 것은 무지의 소치이겠지... 하는 맘으로 더 디벼볼 예정. 어여 위와 같은 데이터 모델링 문제를 끝내고 sharding 등의 물리 설계 부문으로 나아가고픈 맘과 함께 말이다.

저작자 표시 비영리 변경 금지
신고
Posted by 어쨌건간에

간만에 블로깅,, 이를 위해 마주친 티스토리 editor를 마주친 순간의 느낌. '아,, 졸 싸보이는 UI이다.'

잠시 WordPress에 계정을 만들 일이 있어 이를 지나쳤더니 그새 비교가 된 듯.


여하간,

요즘 하고 있는 거 정리 한번 할 때가 된 듯 해서리 그간 스팸 지울 때나 들어왔던 여기에 포스팅을.

JIRA - anyflow역시 UI는 이쁘고 봐야 한다. JIRA를 선택한 여러 주요 이유 중 하나는 이쁜 UI.


일단, JIRA(https://anyflow.atlassian.net).

JIRA에 대한 ALM - issue tracking system이란거, Apache 재단에서도 채용한,, 대세가 된 도구란 정도만 언급하면, 더 상세한 설명은 굳이 여기서 할 필요 없겠지. 근간에 개인적으로 진행하는 프로젝트는 모조리 JIRA를 통해 task logging을 하고 있다. 첫 번째 이유는 무엇보다 나 자신의 tasking 습관을 best practice 그것에 맞추고 싶었다는 것. 그리고 이를 통해 내가 이끄는 팀 범위로 해당 practice를 넓히고 싶었다는 거. 이외 세부 장점은 너무 수두룩해서 일일이 쓰기 번거롭다.

(회사에서도 전사적으로 JIRA와 Confluence를 적용 중인데, 이에 대한 반발도 만만찮은데, 원인은 여지없이 MSF v5.0의 Scrum 템플릿을 보는 도중 떠오른 생각: 성공 요소는 '믿음, 존경'에서 논했던 '투명성의 증대. 이에 따른 상부의 감시 가시성 대폭 증가'가 가장 큰 듯.


Github - anyflowGithub 역시 UI가 매우 뛰어나다. 뭐 그 자체 - 기능, 철학으로도 사람을 끌었겠지만, UI,,, 이거 무시 못한다. 또 하나 뛰어난 컨셉이라면, coding에 SNS 개념을 넣었다는 거.

둘째. Github(https://github.com/anyflow)

여기에서도 git 및 Github에 대한 소개는 아주 짧게. 먼저 git은 Tovalds가 만든 분산 SCM이고 요즘 가장 잘 나가며, Github은 git을 기반으로 꽁짜 git repository + 여러 필수 부가 서비스를 제공하는,,, 이역시 요즘 가장 잘 나가는 서비스.

분산 SCM이 SVN 등 보다 피부에 와닫게 좋다..란 생각은 아직까지는. 이를 최초로 소개해줬던 예전 팀 동료 왈, 뚱딴지 같게도 branching에서 빛을 발한다는데,, 이거하구 분산 개념하구 뭔 상관?

여하간 내게 Github가 특히나 의미있는 것은, 고품질의 부가 서비스를 겸비한 나만의 Source Repository를 갖는다는 건데 내 PC에 있는 Repository는 사실 Repository(Source Safe, SVN 등)의 역할을 거의 못했다는 사실을 비춰보자면(주로 관리적 이슈. 관리적 이슈라 함은 대부분 손이 많이 가기 때문에 귀차니즘까지 겹쳐 안쓰게 된다는 뜻), 나아가 Github에 올린 놈들이 활성화가 좀더 잘되어 간다는 측면을 보자면,, 상당히 긍정적인 선택(긍정적 결과이니 여기에 썼겠지? ㅡㅡ;;)



이들 둘은 모두 Open Source 진영의 것이란 점...(그렇다구 MS Platform code를 여기에 못 올리는 것은 아니지만) 이는 더 이상 Microsoft(MS) 먹물이 내 몸에서 나오지 않는 뜻이란 것을 뜻한다. MS의 것을 안 만진지 꽤 오래되었는데, 소감이라면,,, 뭔가 안정적인 발판 아래서 하나씩 쌓아 올린다는 느낌 정도?(이게 상당히 중요한데 MS platform 위에서 지내던 시절은 뭔가 밟고 있는 바닥이 불안하다..란 불안을 언제나 달고 살았기 때문이다. 이게 타당한 불안인게, MS의 것은 당장 OS부터 Unix가 아니기에 - 즉, de facto 표준하고는 거리가 멀었기에 - 뭘 하나 익히더라도 그 de facto 표준의 것을 항시 찾아봐야 했기 때문이다.)



이번 posting은 요기까지.

중요한 건, JIRA는 돈을 내가면서까지 쓰고 있단 점. 그리고 그 돈은 전혀 아깝지가 않았다는 점. best practice를 얻고 있다는 점, best practice의 분위기에 편승하고 있다는 점. 글구 이러한 모든 것들이 외부 표출 가능한 형태로 history로 남고 있다는 점. 그 history는 단순히 표출 뿐 아니라 이슈 발생 시 tracking을 위한 발판이 된다는 점. 그리고 내 몸땡이로 얻은 지식이기에 딴 사람(구체적 예는 나의 팀..)으로 자신 있게 전파 가능하단 점. 그리고 이렇게, 변명 없이 블로깅으로 남길 수 있는 수준의 무엇이란 점이다.



p.s. 제목을 '~ 리포팅, 소감'으로 했다가 뒤에다가 '#1'을 붙였는데, 이는 프로젝트 관리 환경이 아닌 coding platform에 대한 리포트를 '#2'로 넣기 위한 포석임... 근데 '#2'를 내가 쓰게 될까?... 란 의문이 갑자기 불쑥 났다. ㅋ

저작자 표시 비영리 변경 금지
신고
Posted by 어쨌건간에

유럽 배낭여행 시리즈,, 그 마무리는 커녕 1/10도 몬쓴 마당에 이렇게 또다시 지르고 나면,,,


뭐가 문젠데? 그럴 수도 있는거지.


이번에는 미 서부. 참고로 미 동부 - 뉴욕, 보스턴, 시카고, 나이아가라 폭포, 워싱턴DC 등 - 은 아주 오래 전에 왔고, 서부 - 특히 그랜드캐년 - 만 디비면 대강 미국은 왠간한 곳은 다 들른다.. 생각이 그간 맴돌았었고. 산호세 - 실리콘밸리로 출장을 가게 되었는데, 아주 재수 좋게 바로 뒤로 추석이 끼어서리, 그 기간 중에 이루어진 여행이었다는.

여행 trail 지도하단 샌디에고 출발하여 화살표 방향 대로 진행(시계 반대 방향). 붉은 핀은 사진 찍은 곳. 굵은 점은 숙소 위치. 우하단 작은 지도는 미 본토 중 어디에 해당하는 것인지를 알리는 포스트 열람자에 대한 배려(클릭하면 크게 보임)


여행 기간은 9월 28일부터 10월6일로서 7박 8일인데, 렌트카 측 정산은 7일이었으니 이는 만으로 따져서 그런 것이겠네.


일단 루트 먼저.

첫 날은 샌디에고 내 숙소정하고 렌트카 하느라 위 그림 중 하단 샌디에고에서. 

둘째 날. 위 그림 중앙 하단의 샌디에고에서 출발, 라스베가스까지 달려 거기서 하루 묵기.

셋째 날. 그랜드캐년 South Rim으로 들어갔다가 North Rim 옆 동네인 Page에서 잠자리를.

넷째 날. 그랜드 캐년 North Rim과 마블 캐년을 들르고 다시 Page에서 하루 더 숙박. 

닷째 날. 아침 일찍 출발하여 Powell 호수(글랜 캐년)를 거쳐 Zion 국립공원을 관통하여 라스베가스에서 늦은 점심 후 Death Valley 앞 숙소에 밤 늦게 도착. 

엿째 날. Death Valley를 뚫고 세콰이어를 옆에 두면서 요세미티까지 진행하여 산맥 넘은 서부 마을인 매리포사에서 굿 나잇.

이래 날은 출장지였던 실리콘 밸리를 뚫고 애플/구글 캠퍼스 갔다가 구글 캠퍼스에서 점심, 이제는 LA까지 캘리포니아 해변 달리기. LA에서 3시간 정도 거리인 산타마리아에서 마지막 밤을.

마지막 날 LA 도착 13시 10분 뱅기타고 come back to Korea.


Utah 주 경계 도로 및 주 표지판Powell 호수 서편(글랜 캐년)에서 Zion 캐년으로 이동 중 Utah 주 경계에서. 사실 죽어라고 이런 사막 도로 달리는 게 본 여행의 주 목적이었다. 그랜드캐년이 걍 iternary 정도의 의미라면 넘 의미를 축소한건가?

Apple Campus성지 순례 사진 #1. Apple Campus에서. 거리이름이 진짜 infinite loop이다. 이런 센스를 관공서까지 침투시킬 수 있는 파워가 느껴지는?Google Campus성지 순례 사진 #2. 구글 캠퍼스에서.

위 일정이 사실 졸 쉽지 않은건데, 하루 활동 시간 12시간 중 8~9시간은 온전하게 운전만 한 것이기 때문이다. 일반적인 여행의 움직임하고는 졸 다르다는거, 상당히 빡센 움직임이라는 거. 그래도 나에게 이게 맞았던게, 이번 여행에서 가장 기대했던 바가 지평선까지 일직선을 뻗은 사막 한 가운데의 도로를 달리기였기 때문. 라스베가스니 그랜드캐년이니 해서 유명 장소를 다 찍긴 했지만, 말 그대로 이들 장소는 걍 itinerary 수준의 의미였을까?(초기에 말이다. 보고 나서는 완전히 의미가 달라졌지만) 어디 갔다왔다 자랑질을 할 여지 남겨두는 수준? 흘흘.

근데, 이게 일반의 여행에서도 의미가 있는게, 운전 중간에 나타나는 광경,, 즉, 유명 장소가 아닌 곳의 광경이 하나하나 놀랍다는 사실. 운전 내내 끊임없는 볼거리였다고 할까? 특히나 그랜드캐년 - 마블캐년 - 글랜캐년 일대(위 지도에서 우측 붉은 점이 모인 곳들)에서의 소감은,,, '내가 외국에 온 것이 아니라, 외계 행성,, 화성에 왔군...'


마블 캐년 주변에서머, 이정도면 화성이라 속여도 될만하지 않나?(하늘 푸른 빛만 없애면,, 말이다)


아, 출근할 시간이다.

일단 미 서부 자동차 여행 첫 빠다 포스팅은 여기까지만 해야지. 많이도 썼다. 

여하간, 이번 미 서부 자동차 여행을 끝내고 딱 한마디 하자면, 


"미국에서 대자연을 빼면 시체다!!!" 까지는 아니고 시체보다 쫌 더 난 수준이라고 말하면 오버인가? ㅋㅋ


더 세부적인 이야기, 사진은 나중 이어질 포스트에서.(근데 언제?)

저작자 표시 비영리 변경 금지
신고

'프로젝트! > 미 서부 자동차 여행' 카테고리의 다른 글

미 서부 자동차 여행. Prelude.  (0) 2012.10.17
Posted by 어쨌건간에