Hubblemon은 Python과 Django 기반의 모니터링 시스템입니다. 네이버의 memcached 기반 메모리 캐시 클라우드인 Arcus를 모니터링하는 목적으로 개발을 시작했으나, 오픈소스로 공개하면서 memcached, Redis, MySQL, CUBRID, jstat 등을 위한 플러그인도 추가했습니다. * GitHub의 Hubblemon 프로젝트: https://github.com/naver/hubblemon 이 글에서는 Python 구문으로 쉽게 그래프와 대시보드를 구성할 수 있는 Hubblemon의 기본 설계 방식을 살펴보고, 이러한 설계 방식으로 확장될 수 있는 eval 구문의 활용과 데이터 분석 방법, 시스템 설정 방법을 설명하겠습니다. 그리고 마지막으로 Hubblemon 인스턴스의 구성을 간략하게 설명하겠습니다. 플랫폼 개발자나 Python 사용자라면 재미있게 볼 수 있을 것이라 생각합니다. 유연한 그래프 구성 사용자 입장에서 모니터링 시스템을 접할 때 가장 아쉬웠던 점은 수집한 데이터를 활용해 원하는 항목으로 이루어진 그래프와 대시보드를 구성하고 필요에 따라 변경하기가 쉽지 않았다는 점이다. 이런 아쉬운 점을 해소하려 Hubblemon에서는 Python 구문으로 그래프와 대시보드를 쉽게 구성할 수 있게 했다. 예를 들어 다음 그림은 Hubblemon의 메뉴에서 arcus_stat를 선택하면 나타나는 Arcus 캐시 클라우드 모니터링 화면이다. 그림 1 Hubblemon의 대시보드 Arcus 캐시 노드에서 수집한 통계 정보 가운데 서로 관련이 있는 정보를 같은 그래프에 모아서 보여 주거나, 값을 합치거나 비율을 계산한 결과를 그래프로 보여 준다. 인스턴스가 클라우드나 그룹을 구성할 경우 인스턴스별 그래프를 보여 주거나 인스턴스를 합쳐서 같은 그래프에 보여줄 수도 있다. 물론 대부분의 모니터링 도구가 사용자 설정으로 그래프의 항목과 대시보드의 구성을 바꿀 수 있지만 보통 사전에 정해진 틀 안에서만 할 수 있다. 반면 Hubblemon은 그래프의 항목과 대시보드의 구성을 Python 구문으로 설정할 수 있으며, Python의 eval 구문을 이용해 서비스 시점에 사용자가 다시 정의할 수 있다. 그림 1의 Arcus 모니터링 화면은 다음과 같이 리스트 형식으로 된 arcus_preset이라는 가공 필터와 arcus_view() 함수로 구현된다. arcus_preset = [['bytes', 'total_malloced', 'engine_maxbytes'], (lambda x: x['get_hits'] / x['cmd_get'] * 100, 'hit_ratio'), ['hb_count', 'hb_latency'], ['rusage_user', 'rusage_system'], 'curr_items', 'evictions', ... ] def arcus_view(path, title = ''): return common.core.loader(path, arcus_preset, title) 사용할 데이터의 위치(설정에 따라서 Hub

네이버가 전국 지방 개발자들과의 소통과 성장에 보탬이 되고자 올해부터는 부산을 필두로 전국을 순회하고 있습니다. 이번에는 <광주광역시>로 달려갑니다. 제8회 오픈 세미나는 광주정보문화산업진흥원과 함께하며, '네이버의 웹개발 프로세스 A to Z-프론트엔드부터 백엔드까지'라는 테마로 진행합니다. 무엇보다도 네이버 현업엔지니어들이 프론트엔드부터 백엔드 뿐만 아니라 반응형웹/웹개발 아키텍쳐/협업/빌드배포까지 웹개발에서 일어나는 거의 모든 프로세스를 보여주는 세션들로 준비하였습니다. 아울러 네이버가 대규모 웹 서비스에서 성능향상을 위해 사용하고 있는 오픈소스 'Arcus'와 소스코드/이슈관리  협업 도구인 'Yobi'를 활용한 개발 프로세스를 함께 설명합니다. 함께 배우며 발전할 수 있는 '제8회 오픈 세미나 in 광주'에 개발자 여러 분들의 뜨거운 열정을 보여주세요! -------------------------------------------------------------------------------- * 오픈 세미나: 함께 성장하는 개발자들의 모임이라는 취지로 2012년 5월부터 개최되었으며 국내 SW생태계에 기여하고 네이버 개발자들이 외부 개발자들과 소통하기 위한 노력의 일환으로 진행하고 있는 세미나입니다. 제6회부터는 외부 개발자 커뮤니티와 함께 더 다양한 기술주제들을 공유하고 있으며 지난 1~7회 발표자료는 네이버 개발자 센터 > 기술 공유/지원 > 오픈 세미나 에서 확인하실 수 있습니다. -------------------------------------------------------------------------------- > 일시 : 6월27일(금) 13:00 ~ 17:30 > 장소 : 광주영상복합문화관 6층 세미나실 (오시는 길, 주차 불가) > 프로그램 : 5개 세션, 강사와 함께 Q&A (상세사항은 아래 소개 참조) > > 1. 반응형 웹 개발 전략 및 사례 (NHN Technology Services UIT 개발실 민경환 대리) > 2. 네이버 프론트엔드 개발 프로세스 (NHN Technology Services 프론트엔드개발팀 김지태 과장) > 3. 웹서비스 성능 향상을 위한 오픈소스 Arcus 주요 기능 및 활용 사례 (네이버 랩스 시스템스컴퓨팅G 박준현 부장) > 4. 네이버 웹서비스를 지탱하는 백엔드 아키텍쳐 (네이버 랩스 웹플랫폼개발랩 정민우 대리) > 5. Yobi를 활용한 개발자 협업 및 배포 프로세스 (네이버 랩스 시스템스컴퓨팅G 김창성 대리) > > 참가인원 : 120명 선착순 > 참가신청 방법 : 네이버 개발자 센터 > 오픈 세미나 페이지에서 신청(접수는 6월 20일(금) 오전 11:00 부터 무료신청) > 관련 문의 : Naver D2 공식SNS(트위터, 페이스북) 및 이메일(d2@navercorp.com)로 해주세요 -------------------------------------------------------------------------------- 반응형 웹 개발 전략 및 사례

이 글에서는 LINE의 소셜 네트워크 서비스인 홈과 타임라인에서 급격하게 증가하는 트래픽과 데이터를 처리하기 위한 아키텍처와 기술을 살펴봅니다. LINE의 소셜 네트워크 서비스, 홈과 타임라인 > 붉은 여왕이 3V(volume, velocity, variety)가 새겨진 셉터(scepter)를 턱밑에 들이대며 말했다. 앞으로 엄청난 > 양의 데이터가 밀려들 것이라고, 아무리 버티려 해도 더는 HTTP 500 Error를 막을 수 없을 것이라고. 서비스를 만들면서 가장 큰 기쁨이라면 바로 꾸준히 늘어가는 사용자일 것이다. 하지만 기쁨도 잠시, 사용자가 급격하게 늘기 시작하면서부터는 공포감이 점점 커지기 시작한다. 물론 회사 사람들은 대부분 쾌재를 부르며 백만장자의 꿈을 꾸겠지만, 한쪽 모퉁이에서는 겁에 질린 표정으로 트래픽 지표를 지켜보는 사람들이 있을 것이다. 다다익선과 과유불급이 상충하는 이중주가 모니터들 속에서 음울하면서도 무거운 레퀴엠의 선율을 뽑아내는 그곳은 바로 붉은 여왕과의 일전을 앞둔 기사들의 진영이다. 창과 방패 대신 키보드로 정보를 처리하는 기사들이긴 하지만 말이다. > 참고. 붉은 여왕과 붉은 여왕 가설 붉은 여왕을 비유한 상황은 "소셜네트워크서비스의아키텍처에대하여"에서도 언급했다. 붉은 여왕은 영국 작가 > 루이스 캐럴의 작품 『거울 나라의 앨리스(Through the Looking-Glass and What A1ice Found There)』에 > 나오는 인물이다. 붉은 여왕과 붉은 여왕 가설에 관한 자세한 내용은 Wikipedia의 "Red Queen (Through the > Looking-Glass)"와 "Red Queen hypothesis"를 참고한다. 초기 설계부터 확장성을 과도하게 고려하면 오버엔지니어링일 수도 있고, 고려했다고 해도 그 증가 속도가 너무 빠르다면 속수무책이거나 인해전술과 물량전으로 다급하게 대응해야 하는 경우가 비일비재할 것이다. 그렇다면 사용자 증가의 속도가 Facebook이나 트위터를 압도하는 서비스라면 어떨까? 사용자가 5천만 명이 되기까지 Facebook은 1,325일이 걸렸고, 트위터는 1,096일이 걸렸다. 2011년에 6월에 출시한 이 서비스는 단 399일이 걸렸다. 그리고 지난 3년간 6개월마다 두 배씩 성장해 4억 사용자를 거침없이 넘긴 이 서비스는, 이미 여러분들이 알고 있듯, LINE이다. 그렇다면, 이러한 LINE의 진영에서는 어떤 일들이 벌어지고 있는 것일까? 그림 1 Facebook과 트위터, LINE의 사용자 5천만 명 도달 기간(원본 출처) 그림 2 2013년 11월 기준 라인 다운로드 수(원본 출처: http://linecorp.com/en/press/2014/0402714) "소셜 네트워크 서비스의 아키텍처에 대하여"에서는 대표적인 SNS 아키텍처인 Pull 방식과 Push 방식을 비교했다. 이어지는 이 글에서는 LINE의 소셜 네트워크 서비스(이하 SNS)가 어떤 아키텍처와 기술을 사용하는지 살펴보겠다. 이러한 대규모의 SNS 아키텍처는 웹, 앱, 게임

더 빠른 결과를 제공하기 위해 여러 시스템의 메모리에 데이터를 분산시켜 저장하는 사례가 늘고 있습니다. 이런 제품을 IMDG라고 합니다. 현재 IMDG가 어디까지 발전했고 어떻게 활용할 수 있을지 알아보겠습니다. IMDG의 특징 저장소로 디스크 대신 메인 메모리를 사용하는 것은 전혀 새로운 시도가 아니다. 디스크보더 더 빨리 수행 결과를 얻기 위해 MMDB(Main Memory DBMS)를 사용하는 사례는 일상에서도 찾을 수 있다. 대표적인 예는 휴대 전화를 사용할 때이다. SMS나 통화를 시도할 때 상대방 정보를 빠른 시간 안에 찾기 위해 대부분의 통신사는 MMDB를 사용하고 있다. IMDG(In Memory Data Grid)는 메인 메모리에 데이터를 저장한다는 점에서 MMDB와 같지만 아키텍처가 매우 다르다. IMDG의 특징을 간단히 정리하면 다음과 같다. * 데이터가 여러 서버에 분산돼서 저장된다. * 각 서버는 active 모드로 동작한다. * 데이터 모델은 보통 객체 지향형(serialize)이고 non-relational이다. * 필요에 따라 서버를 추가하거나 줄일 수 있는 경우가 많다. 즉, IMDG는 데이터를 MM(Main Memory)에 저장하고 확장성(Scalability)을 보장하며, 객체 자체를 저장할 수 있도록 구현됐다. 오픈 소스와 상용 제품을 구별하지 않으면 다음과 같은 IMDG 제품이 있다. * Hazelcast * Terracotta Enterprise Suite * VMware Gemfire * Oracle Coherence * Gigaspaces XAP Elastic Caching Edition * IBM eXtreme Scale * JBoss Infinispan 이 글에서는 제품의 기능과 성능을 비교하지는 않고, IMDG의 아키텍처를 살펴보고 어떻게 활용할 수 있을지 검토해 볼 것이다. 왜 메모리? 2012년 6월 현재 SATA(Serial ATA) 인터페이스를 사용하는 SSD(Solid State Drive)의 성능은 약 500MB/s 정도이고, 고가의 PCI Express를 사용하는 SSD는 약 3,000MB/s에 이른다. 10,000 RPM SATA HDD의 성능이 약 150MB/s 정도니까 SSD가 HDD보다 4~20배 정도 빠르다고 할 수 있다. 하지만 이에 반해 DDR3-2500의 성능은 20,000MB/s에 이른다. 메인 메모리의 처리 성능은 HDD보다 800배, 일반적인 SSD보다 40배, 가장 빠른 SSD보다 약 7배 빠르다. 게다가 요즘의 x86 서버는 서버 하나당 수백 GB 용량의 메인 메모리를 지원한다. Michael Stonebraker에 따르면 전형적인 OLTP(online transaction processing) 데이터 용량은 약 1TB 정도이고, OLTP 처리 데이터 용량은 잘 증가하지 않는다고 한다. 만약 1TB 이상의 메인 메모리를 사용하는 서버 사용이 보편화된다면, 적어도 OLTP 분야에서는 모든 데이터를 메인 메모리에 둔 채 연산을 하는 것이 가능해진다. 컴퓨팅