조대협의 블로그

소셜 시스템이라고 이름은 지었는데, 정의는 Google,FaceBook,Twitter들과 같이 B2C 서비스를 지향하면서 대용량 서비스를 제공하는 웹서비스 시스템을 정의한다. 이 시스템들은 기존의 J2EE나 APM (Apache PHP MySQL) 다음 세대의 기술셋을 사용하는데 특징적으로 - 오픈 소스를 많이 이용한다. - NoSQL을 이용한 대용량 데이타 저장 구조 - 분산 처리 아키텍쳐 등등이다. J2EE 시대에 Servlet/JSP + EJB + JDBC가 필수 기술이었고 J2EE 다음 시대인 오픈 소스 과도기에는 Spring + IBatis (or Hibernate) + Struts 가 필수 기술이었다면 다음은 무엇일까? 나름 여러 문건이나 트랜드들을 조사해본 결과 1. NoSQL - 대용량 데..

요즘 잘나간다는 SNS 서비스 (텀블러, PInterest)등의 내부 서비스 아키텍쳐나 운영 구조를 공개된 글을 보면 SNS 시스템들의 기술 트렌드를 읽을 수 있다. 1. 소규모 조직이다. 얼마전에 FB에 인수된 Instantgram이나 다른 잘나가는 SNS서비스 업체들을 보면 대부분 인력이 20명이내이다. 영업 조직이 있는 솔루션 업체의 경우는 영업이나 Director들을 포함하더라도 40명이 안넘는 것이 대부분이다. 이는 빠른 의사 결정을 가능하게 하기 때문에, 상당히 빠른 서비스 개선을 가능하게 한다. 기술적이나 기획적으로 대단한게 아니라, 하나의 기능을 편하게 만들고 사용자 경험에 상당한 노력을 쏟는다. 2. 오픈 소스로 치덕치덕. & Don't invent wheel again 이런 서비스들 치..

요즘 스마트 폰이 일상화 되면서, SNS 애플리케이션의 형태에도 많은 변화가 있는것 같다. 예전에는 블로그나, 카페, 미니홈페이지 같은 것이 주를 이루었다. 주로, 디카로 찍고 몇장의 사진과 장문의 글을 올리는 것이 사용 형태였으며, 컴퓨터와 인터넷에 익숙한 소수(스마트폰 대비)를 대상으로 사용되었고, 업데이트 주기와 시간역시 빨라야 하루였다. (저녁에 편집을 해야 했으니) 스마트폰의 도입으로 바뀐 SNS의 시나리오는 스마트폰에 달린 카메라와 인터넷 연결 기능 내장에서 많은 혁신을 불러왔는데, 일단 바로 찍어서 올린다. 글은 스마트 폰의 특성상 장문보다는 단문의 Comment성이 많아지고 업데이트 주기는 하루에 수번으로 많아졌으며, 사용 대상 역시 10대~40대까지 넓어졌다. 스마트폰이 PIMS (Per..

원문 : http://www.isi.edu/~gideon/publications/JuveG-DataSharing.pdf 아마존에서 과학관련 HPC 분산 컴퓨팅 시에, 공유 스토리지 (NFS, Shared Storage)에 대한 성능 비교 및 Cost 비교를 해 놓은 문서 입니다. EBS나 Local Disk와 같은 스토리지가 아니라 공유 스토리지에만 한정합니다. Amazon S3, Gluster, NFS, PVFS를 중심으로 비교했는데, 결론 적으로 GlusterFS(NUFA Configuration)이 성능도 높은편에 속하고 Cost도 저렴합니다. 그림 1. Cost 비교 그림 2. 성능 비교 저도 Gluster를 AWS에서 사용했는데, 무엇보다 AWS에 Gluster를 Deployment하기 위한 B..

Remote Fx 드디어 WAN 지원 드디어 Remote Fx가 WAN환경을 지원합니다. 강력한 기능에도 불구하고, 네트워크 사용량이 문제였는데 Windows 8에서 지원하네요. 주요 기능을 발췌합니다. http://uksbsguy.com/blogs/doverton/archive/2012/03/01/windows-server-8-remote-desktop-and-vdi-enhancements.aspx The goal of the RemoteFX for WAN feature of Windows Server "8" Beta is to deliver a great user experience beyond the corporate network, whether the user is in a branch offi..

좋은 스위치는 iSCSI SAN의 핵심 부분이다. 그렇다, 어떤 기가비트 스위치도 iSCSI와 잘 어울리지만, 값싼 비관리형 제품에는 몇 가지 아주 중요한 기능들이 없다. 우선, 스위치는 넌블로킹(Non-blocking)이어야만 한다. 즉, 모든 포트에서 회선 속도의 입출력을 동시에 처리할 수 있어야 한다. 모든 스위치가 이렇게 할 수 있는 것이 아니며, 심지어 일부 엔터프라이즈급 스위치도 인접 포트(Adjacent Port) 그룹끼 리는 대역폭을 공유한다 (특히, 시스코 카탈리스트4500 시리즈의 구형 모델처럼 섀시 기반의 스위치,물론 그렇지 않은 모델도 많다). 둘째, 흐름 제어를 지원할 수 있어야 한다. 흐름제어란 수신 호스트가 송신 호스트에게 송신하는 데이터 양을 줄이라고 요청할 수 있게 해주는 ..

국내만 아니라, 해외에도 서비스 하는 플랫폼을 설계할때 고려해야 할 기술적인 사항을 인프라(하드웨어+데이타 센터) 관점과 소프트웨어 관점에서 간략하게 정리하였습니다 Global platform View more PowerPoint from Byungwook

훝어 보기 - 인터페이스 기존의 Gmail이나, Google Docs와 상당히 유사하다. 일관된 인터페이스를 제공하는 것은 사용자 경험 관점에서 제대로 된 선택인듯 - 기능 기능적인 차이는 크게 없다. 검색이 강화된 것과 GDocs 연동 기능이 있는 것 정도 기본적으로 저장과 Sync 기능을 제공하고, GDocs와 연동하여 문서를 협업으로 작성할 수 있는 기능을 제공한다. 개인 클라우드 스토리지는 이미 Box나 DropBox같이 여러 서비스들이 강력한 기능을 제공하는 레드 오션이기 때문에 기능적으로 혁신적인 차별화는 어렵고, 기존 서비스와 연동 정도 및 사용자 경험이 관건인데, G Drive는 아무래도 기존 서비스 연동과 함께, Android 플랫폼에 PreLoad되고, 기존 Gmail등 기존 서비스 사..

이 구성은 Cassandra나 Riak과 같은 Dynamo 계열에 공통 적용 가능하다. 다른 것들도 마찬 가지일테지만. 1. RAID 5 사용 : NoSQL 클러스터는 Quorum 사용을 통해서 노드에 (서버) 대한 FAIL을 방지 하지만 디스크 장애 자체에 대해서는 보장이 불가능하다. 고로 비용 대비 적정한 RAID 5 사용이 권장 2. IO Scheduler : NOOP 사용. NOOP은 IO Scheduling을 다른 계층이 한다는 것을 전제 한다. 즉 중간에 RAID 구성이나 iSCSI 를 사용하는 경우를 전제한다. 테스트용이나 개발용으로 사용하면서 RAID 구성등을 하지 않는다면, NOOP을 사용할 필요가 없다. 3. ext4 또는 XFS 파일 시스템 사용 : ext3는 1 volume의 max..

http://seancribbs.com/tech/2010/02/06/why-riak-should-power-your-next-rails-app/

NoSQL 하드웨어 구성에 있어서, DISK IO에 대한 메모. RAID 구성은 5가 정답 NoSQL의 N-Value를 통한 장애 대처 능력은 노드간 장애를 대처하기 위함이지, 노드의 디스크 장애 극복은 불가능함. 아주 큰 클러스터가 아니면 RAID 5가 정답, 아니면 스트라이핑 기반의 RAID 0가 정답(대규모 클러스터의 경우, 단 이 경우, 디스크 장애는 해당 노드의 장애를 의미함, 검출도 어려울듯...) IO Scheduler가 성능 튜닝 포인트라고는 하는데... 오늘 구글링에서 본 자료로는 Scheduler 바꾼다고 IO 자체 성능이 큰 차이가 없는 듯.. 이건 한번 테스트 해봐야 할듯. 결국은 네트워크 분리,캐쉬 튜닝을 어떻게 하느냐가 가능 큰 팩터가 될듯.

어렸을때 부터 가장 많이 들어온 말이, "사고 방식이 참 기계적이다." 라는 말을 많이 들어왔다. FACT를 기반으로 장단점을 분석하고, 그에 대한 백업 플랜까지 계획을 한 후에, 의사 결정을 하는 프로세스가 머릿속에 박혀있다. 그래서 일하기는 편하고, 나름 논리적이라는 평을 많이 들었는데, 얼마전 팀원으로 부터 "조금 더 팀을 감성적으로 관리 하는 것은 어떻냐?" 라는 말을 들었다. 한 2~3주 되었나? 아마 금년에 풀어야할 가장 큰 숙제가 될 것 같다. 96년에 대학교 후배한테 들었던 이야기가 있다. 후배에게.. "세상은 이끌어 가는 리더와, 이끌려 오는 평범한 사람들로 이루어져 있다. 그러니 너도 리더가 되기 위해서 노력해라..." 라고 했더니.. 후배 왈.. "형 저는 이끌어가는 리더보다는 같이 ..

지금까지 파악한 Riak 장점 1. Masterless 아키텍쳐로 Single Failure Point가 없다. 2. Replication이 빵빵하다. 3. Multi data center replication이 빵빵 (유료 버전만 지원) 4. Full Text Search (Lucene을 내장하여 FTS를 그냥 지원.. 인스톨도 쉬움) 5. Secondary Index 지원 6. 상당히 향상된 Map & Reduce 지원. Erlang 기반이라서 훨씬 신뢰가 감 7. Basho의 Support도 좋음. (경험해본 결과 좋음) 8. Physical storage를 Basho의 bitcask, oracle innostore, google level db,memory 지원 9. Luwak을 이용하여, Big..

http://blogs.digitar.com/jjww/2011/03/riak-vs-couchdb-for-storing-100000-coupons/ CouchDB와 비교한 Performance Report가 있는데 Riak 0.14 버전 기준 작년 3월(1년전)이니 많은 변화는 있었겠지만 얻을만한 데이타가 많다. Indexed insertion is 91% slower than storing just the key data. MapReduce with indexes is 20% faster than MR on the data keys alone. MapReduce with indexes and key filters is 32% faster than MR on the data keys alone. Addin..

NoSQL @ Qbranch -2010-04-15 View more presentations from Mårten Gustafson CouchDB의 Kick-ass replication만 기억에 남네 그랴.

그토록 배우고 써먹었던 걸 왜 까먹고 있었을까? 새로운 비지니스 모델이나 서비스를 만들기 위해서 해야 될것 3가지. 투자를 받고 비지니스를 허가 받기 위해서는 첫번째, 파트너쉽 확보 개발 파트너,장비,컨설팅등 든든한 파트너를 확보하고, 파트너들에게 본 비지니스가 성공할것이라는 확신을 심어주어야 한다. 이는 파트너가 가질 수 있는 Benefit을 설명하고, 그를 바탕으로 확신을 가지게 해야 한다. 레퍼런스 확보, revenue 확보 두번째, 비지니스 모델 확보 비지니스 모델은 이 비지니스가 실제적인 수익을 내고 수익을 재 투자해서 비지니스가 돌아가는 원리를 만들어야 한다. SNS 등의 업체들은 펀딩은 받지만, 자체적인 비지니스 모델을 만들어내지 못해서 (수익모델) 쓰러지는 것일지도 여기에는 중,단기적인 투..

짧으나마 NoSQL 경험해보고 배운 내용을 정리해보면 1. RDB는 Entity를 정의하고 데이타 모델링을 정의한 후에, 쿼리와 APP을 개발한다. 반대로 NoSQL은 App을 먼저 디자인하고, 필요한 쿼리 결과를 먼저 정의 한후에, 그에 맞춰서 데이타 모델링을 해야 한다. 2. 절대 Normalization은 하지 말고, DeNormalization을 할것. 데이타 중복을 허용하여 성능을 높이고, 데이타안에 데이타를 넣는 (Composition) 모델등을 사용하여 Query 수를 줄여야 한다. 3. 내 애플리케이션의 서비스 특성과 이에 맞는 NoSQL을 선택한다. BigTable 계열, Cassandra 계열, Document DB 계열등 많은 계열의 NoSQL이 있고, 그 특성도 매우 다르다 (언뜻 ..

MongoDB 깜빡 잊고 있었다. Read / Write 성능이 빠를 수 밖에 없다는 걸.. Mongo는 Write시에, Memory에 먼저 Write후에, 1분 단위로 Flushing하는 Write Back 방식을 쓴다. 즉 메모리에만 쓰면 되니까는 Write가 무지 빠르다. 반대로 Read시에는 파일의 Index를 메모리에 로딩해놓고 찾는다(memory mapped file). 이러니 성능이 좋을 수 밖에, 단 Flushing전에 Fail이 되면 데이타 유실에 의해서 Consistency 가 깨지는 문제가 발생하고, Configuration 구조상 메모리 사용량이 많으며, 확장성에 제약이 있다. 특히 Write 구조에서는 비동기 식으로 Write를 하기 때문에 Disk 성능에 덜 Sensitive하다..

http://rainblue.kr/1045 트위터에서 재미있는 글을 찾아서 읽다보니, 발상의 전환이 필요하다고 생각되서 정리해 봅니다. -- 국내에는 사용자가 많지 않지만, 트위터보다 많은 트래픽을 자랑하는 마이크로 블로깅 도구입니다. (소셜 네트웤의 넘버 투 라고 자랑하네요.) 하루에 5억 PV, 초당 4만 request, 하루에 3TB 데이터를 저장하는 서비스를 위해 1천대 이상의 서버를 운용하는 텀블러. 4명의 엔지니어가 전형적인 LAMP 스택으로 시작했지만, 지금은 20명의 엔지니어가 점점 성장하는 사이트를 분산환경으로 진화시키고 있다네요 -- 초당 4만 TPS, 경이로운 숫자입니다. 처음에는 LAMP로 개발했고 현재는 Scala로 전환중이며, 메인 데이타 베이스는 아직도 MySQL에 Shardi..

분산 환경 기반의 NoSQL은 예전 포스팅에서도 설명했듯이 크게 Google의 BigTable 논문을 기반으로한 시스템과, Amazon의 Dynamo를 기반으로 한 시스템 두가지로 나뉘어 진다. Dynamo 계열의 NoSQL의 장단점을 간단히 정리해보면 Dynamo 계열 NoSQL의 개요 1. Ring과 Consistent Hasing 먼저 Dynamo 계열 (Cassandra, Riak) 의 NoSQL의 특징은 Ring 토폴로지를 기본으로 하고 있다. Ring 구성이란, 전체 데이타를 1~N (2^160과 같이 큰 범위로) 이라는 특정 레인지로 정의한후 전체 데이타 저장 구조를 Ring 형으로 정의한 후에, 이 Ring을 피자 조각을 나누듯이 여러 Slice로 나눈다. 이를 Partition이라고 하는..

Riak 계보 Riak은 이미들 잘 알고 있는 NoSQL 데이타 베이스이다. Basho.com이라는 회사에서 만들어서 배포하고 있고, 무료 버전인 Community version과 상용 기술 지원을 받을 수 있는 Enterprise version을 지원하고 있다. NoSQL 계보는 크게 두 가지로 나눠지는데, Google의 Big Table 논문을 기반으로 한 HBase,HyperTable 등과, Amazon Dynamo 논문을 기본으로 한 Cassandra등의 계열로 나뉘어 지며, Riak은 Dynamo 계열에 속한다. 데이타 모델에 있어서는 Key,Value 저장형식을 취하는데, Value는 JSON 문서가 저장되는 문서 저장형 데이타 베이스 형식을 취하며, 이는 MongoDB나 CouchDB와 유사..

Vnode - vnode - process (One Erlang process per partition in the ring) partition - data - Vnode는 MR 처리를 하는 Worker가 따로 있음 - VNode Master : Receieve msg from request corrdinator - FSM (Finate State Machine) 1) Type 1 : Preference list-based : single key 2) Coverate based : entire keyspace W+R > N : Consistency 를 보장할 수 있다. (W : Write Replica 수) (R : Read Replica 수) Java SDK 에 Load Balancing Logic 이..

페이스북의 Photo 서비스 시스템 아키텍쳐 The Photos application is one of Facebook’s most popular features. Up to date, users have uploaded over 15 billion photos which makes Facebook the biggest photo sharing website. For each uploaded photo, Facebook generates and stores four images of different sizes, which translates to a total of 60 billion images and 1.5PB of storage. The current growth rate is 220 millio..

개인 클라우드 서비스를 하다보니.. 고민할 것이 정말 많다. 특히 공유 부분에서 기존의 슈가싱크처럼 B2C 기반으로 공유된 대상이 READ만 가능한 형태로 갈것인가? MS 쉐어포인트 처럼, WRITE 가 가능한 형태로 갈것인가? 이건 서비스 특성에 대한 변화 부터 요구 한다. 슈가 싱크는 B2C 기반의 개인 클라우드 서비스, 쉐어포인트등은 SmartWorkPlace처럼 Share보다는 Collaboration에 대한 요구 사항이기 때문에 서비스의 사상 자체가 변한다. 또한 이러한 개인 클라우드 서비스는 클라우드에 대한 어마어마한 투자를 바탕으로 하고 있기 때문에 안정적인 수익 모델이 있지 않는 이상은 쉽게 대규모 서비스를 하기가 어렵다. 드롭박스야 이미 20% 유료화 전환율을 가지고 있고, 국내의 통신사..

요즘 일이 바뻐서 블로그 포스팅을 거의 못하고 있습니다. 많이 버는 만큼, 그동안 충전해왔던 지식이나 노하우를 주로 방전하는 느낌입니다. 어쨌거나, 클라우드의 양대 산맥인 아마존 AWS와 Microsoft Azure에 대한 이야기를 해보려고 하는데.. Azure vs AWS의 승자가 누구이냐? 인데. 결론 부터 이야기 하면 AWS의 손을 들어주고 싶습니다. Blob Storage나 DB 서비스와 같은 액세사리성 서비스는 양쪽다 어느정도 구색을 갖춰 놨다고 했을 때, 핵심인 Compute Service가 문제인데. 기본적으로 Azure는 .NET 기반의 PaaS만 지원하지만, Amazon은 모든 플랫폼을 올릴 수 있는 IaaS 수준 서비스를 제공합니다. 이말인즉슨, 내가 필요한 소프트웨어를 마음대로 올릴 ..

요즘 예전의 해왔던 일의 경험을 최대한 쏟아 부어서 열정적으로 일을 하고 있습니다. 서비스도 기획해보고, 분석도 해보고, 딜 네고도 해보고, 사람도 뽑고, 예산 관리도 하고, 일정 조정도 하고 사람 관리도 하고, 테스트도 하고,튜닝도 하고, 설계도 하고, 설득도하고... 코딩 빼놓고는 대부분 다하는 군요.. 시점이 바뀌다 보니까는 사람을 보는 눈도 조금 바뀌지 않았나 싶습니다. 요즘 IT 인력, 특히 개발자가 없다 보니까는 개발자 단가는 올라가고, 일의 강도도 쉽게 높일 수 없어지는 것 같습니다. 이제야 제대로 IT 인력들이 대접받기 시작하지 않나 싶은데, 아마 많은 시니어 개발자들이 IT의 길을 떠나거나 앱쪽으로 전향을 하고, 새로운 주니어 인력의 충원이 적기 때문에 한참 노련한 30대 중반 개발자들이..

언어는 Erlang을 많이 쓰는것 같고, 특히 Scale Out이나 Concurrency 처리가 용이하며, 에러 핸들링 처리 기능이 강력하다. 여기에 생산성 측면에서 Python이 사용되고 Native Handling을 위해서 C가 여전히 강세 맨 앞단에 Reverse Proxy 개념으로 nginx가 apache를 대처하면서 올라오고 있고, DataGrid는 memcahed보다는 이제는 Redis를 많이 사용하는 것으로 보이고 NoSQL은 Dynamo 계열의 Riak이 많이 사용된다. RDB야 여전히 MySQL이고 대규모 시스템이 자바로 짜여지는 일은 드문듯 앞으로 살아 남을려면 NoSQL 하나랑 Erlang정도는 기본으로 익혀야 할듯

요즘 대규모 분산환경 관련 기술에 대해서 기웃거려 보고, 개발언어 관련해서도 자바는 아무래도 사양세 같아서 이것 저것 언어들을 살펴보고 있는데, Erlang이 자료도 적고, 유명하지는 않지만 요즘 해외에서 유난히 많이 언급되서 좀 찾아봤다. 일단 한마디로 하면.. "이건 턱시도 + 자바네...." Functional Programming이라고 하는데, 알아서들 찾아보시고, 완전히 Tuxedo의 Service 개념이다. (SOA의 서비스 개념과도 비슷하고..) 구조또한 Tuxedo다. Process 단위로 구동하면서, 안에 Thread로 나눠서 돌고, 그로 인해서 장애 전파가 안되고, Process가 늘어나면서 Schedule Out이 가능하다. 또한, Function은 여러 서버에 Deployment하더..

요즘 대규모 분산 환경이나 빅데이타 관련해서 NoSQL중에서 Riak이 많이 언급되는데... 생각보다 괜찮은 듯 http://nosql.mypopescu.com/post/632057783/riak-search-and-riak-full-text-indexing 주요 특징은 - Cassandra와 같은 Dynamo 계열 - ★ Secondary Index가 지원 된다.. (메이져 NoSQL 중에 유일하지 않을까?) - ★ FTS (Full Text Searching)도 지원된다. 그리고, Commercial Support도 가능하다. ==== 최근 포스팅한 좀더 자세한 Riak 정보 http://bcho.tistory.com/621

기존의 개발 프로세스에서는 요구 사항을 받아서 개발하는 형태였는데, 이 요구 사항이 완벽하지 않다는 것은 누가나 알고 있고, 이를 전재로 해서, 변경 가능한 요구 사항을 기반으로 개발하는 프로세스가 애자일 프로세스 이다. 관리 관점 뿐만 아니라, 요구 사항을 수집하는 관점도 변화가 필요한데 요구 사항은 고객이 정해주는 것이 아니라, 스스로 정하는 것이다. 고객에게 요구 사항을 받은 것이 완벽하다고 판단하지 말고, 요구 사항이 부족한 부분은 Develop하고, 완벽하게 만들어 나갈것. 즉 고객이나 다른 사람에게 요구 사항 정의에 대해 의존하지 말고, 커뮤니케이션, 가정, 레퍼런스를 통하여 스스로 요구 사항을 정리할 수 있도록 해야 한다. 완벽하지 않은 요구 사항에 대해서는 1. 고객에게 요구 사항을 커뮤케..