토요일, 8월 30, 2014

[B급 프로그래머] (Quora) 페이스북 아키텍처는?

Quora에 페이스북 아키텍처에 대한 질문이 올라왔기에 독자 여러분을 위해 정리해드린다.

  • 웹 프론트 엔드는 PHP로 작성되었다. 페이스북의 힙합 컴파일러는 PHP 코드를 C++ 코드로 변환하며, g++를 사용해 컴파일하므로 고성능 템플릿 엔진과 웹 논리 수행 층을 제공한다.
  • 정적 컴파일에 완전히 의존하지 못하는 제약으로 인해, 페이스북은 힙합 인터프리터 해석기와 PHP 코드를 해석해 힙합 바이트 코드로 변경하는 힙합 가상 기계를 개발하기 시작했다.
  • 비즈니스 논리는 Thrift를 사용해 서비스 형태로 만든다. 서비스는 서비스 요구 사항에 맞춰 PHP, C++, 자바로 만들어진다.
  • 자바를 사용한 서비스 구현은 일반적인 엔터프라이즈 애플리케이션 서버가 아니라 페이스북이 직접 만든 전용 애플리케이션 서버를 사용한다. 처음 보기에는 바퀴를 재발명하는 듯한 느낌이 들지도 모르겠지만, 톰캣이나 심지어 제티의 오버헤드가 페이스북의 요구 사항에 부가가치를 더하지 못하므로 대부분 Thrift를 사용한 형태로 공개되어 있다.
  • 영속적인 자료 저장은 MySQL, Memcached, 하둡 HBase를 사용한다. Memcached는 일반적인 범용 캐시 목적 뿐만 아니라 MySQL용 캐시로 사용된다. (옮긴이 주: 최근에는 SSD를 고려한 MySQL 패치로 성능 개선이 가능해져 Memcached 사용을 대폭 줄였다는 소식도 있다)
  • 오프라인 프로세싱은 하둡과 하이브를 사용해서 수행한다.
  • 로깅, 클릭, 피드와 같은 데이터는 Scribe를 사용해 전송하며, Scribe-HDFS를 사용해 HDFS에 저장된다. 맵리듀스를 사용해 후속 분석이 가능해진다.
  • BigPipe는 파이프라인 논리를 사용한 페이지 렌더링 가속 기술이다.
  • HTTP 프록시를 위해 Varnish Cache를 사용한다. 고성능 고효율로 인해 페이스북에서는 이를 선호한다.
  • 사용자가 올린 수십 억개의 사진은 Haystack을 사용해 처리한다. 저수준 최적화와 append만 존재하는 쓰기를 지원하는 전용 자체 스토리지 솔루션이다.
  • Facebook Messages는 샤딩과 동적 클러스터 관리에 기반한 독자적인 아키텍처를 사용한다. 비즈니스 논리와 영속성은 'Cell'이라는 단위로 캡슐화되어 있다. 각 셀은 사용자 일부를 처리한다. 사용자가 늘어나면 새로운 셀을 추가할 수 있다.
  • Facebook Messages의 검색 엔진은 HBase에 저장된 역 색인(inverted index)로 만들어진다.
  • 자동 완성 검색 기능은 전용 스토리지와 인출 논리를 사용한다.
  • 채팅은 Erlang으로 개발된 Epoll 서버에 기반하며, Thrift로 접근한다.
  • 적절한 복구 작업 흐름을 시작하거나 문제를 극복할 수 없을 경우 사람이 처리하게끔 감시 경고에 반응하는 자동화된 시스템을 구축했다.
  • 옮긴이 주: 페이스북이 보유한 서버는 백만대를 넘어선 것으로 추정한다. 페이스북은 최근 샌디스크로 넘어간 퓨전 아이오에서 엔터프라이즈급 고성능 SSD를 가장 많이 구매한 고객이다. MySQL 서버는 모두 SSD 기반으로 동작하고 있다고 추정한다.
  • 옮긴이 주: 최근 페이스북은 brtfs 메인테이너를 영입했다. 웹 서버의 파일 시스템부터 brtfs/SSD 조합을 사용해 성능 향상 작업을 벌이고 있는 것으로 추정한다.
EOB
작성자: 시간: 댓글 2개:
라벨:

토요일, 8월 23, 2014

[B급 프로그래머] 8월 3주 소식

금주에도 알차고 흥미로운 소식을 꽉꽉 채워서 전해드리겠다.

  1. 웹/앱 소식
  2. 개발/관리 도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 8월 19, 2014

[B급 프로그래머] 개발자를 강하게 만드는 것은 규율

Discipline Makes Strong Developers라는 글을 코딩 호러에서 읽었다. 물론 2007년 8월에 작성된 글이라 벌써 7년이 넘은 시점에서 끄집어 내는 이유가 궁금할 것이다. 간단하다. 여전히 유효하니까. 오늘은 개발자에게 규율이 중요한 이유를 정리해봤다.

스캇 쿤의 말을 한번 들어보자.

매달, 새로운 프로그래밍 언어나 방법론이 등장한다. 현신적인 추종자들이 인터넷 여기저기서 찬송가를 부른다. 생산성과 품질 향상에 대한 장미빛 전망을 약속한다. 하지만 모든 성공적인 개발자가 보유한 한 가지 특질이 존재한다. 모든 프로젝트를 성공하게 만들거나 실패하게 만드는 한기지 특질말이다.

바로 규율이다.

규율없는 개발자는 정시에 출시하지 못하며, 쉽게 유지보수 가능한 코드를 작성하지도 못한다. 규율이 잡힌 개발자는 프로젝트 성공을 이끌뿐만 아니라 다른 사람들의 생산성도 높일 것이다. 소프트웨어 아키텍트와 개발자들은 성공의 원인을 방법론으로 돌리지 않는다. 성공은 얼마나 규율이 제대로 잡혔는지로 귀결된다.

규율이 없다면, 도구나 언어가 아무리 좋아도 소용없다. 그렇다면 스티브 맥코넬의 코드 컴플리트에 나온 이야기도 살펴보자.

전산과 신입생에게 관례와 공학적인 규율이 필요한 이유를 설명하기란 어렵다. 내가 학부생이었을 때, 내가 작성했던 가장 큰 프로그램은 500행이었다. 전문가로서 500행보다 작은 유틸리티 수십 개를 만들었지만, 평균적인 프로젝트 크기는 5,000에서 25,000 행 정도였고, 500,000 행이 넘튼 프로젝트에도 참여한 적이 있었다. 소규모 프로젝트와 대규모 프로젝트에서 쓰이는 기술은 다르다. 규모가 큰 프로젝트에서는 완전히 새로운 기술 집합이 필요하다.

미항공 우주국에서 15년 동안 일한 내용을 회상하며, 맥게리와 파저스키는 사람의 규율을 강조하는 방법론이나 도구가 특히 효과적이라고 보고했다(1990). 아주 창의적인 사람들은 엄청난 수준의 규율이 잡혀있다. "형식이 해방을 이끈다"는 말도 있다. 위대한 아키텍트는 물리적인 재료, 시간, 비용이라는 제약 사항 내에서 작업한다. 위대한 예술가 역시 마찬가지다. 레오나르도 다빈치의 그림을 살펴보는 모든 사람이 잘 훈련된 세부 사항에 대한 주목을 찬양한다. 미켈란젤로가 시스티나 성당의 천장을 설계할 때, 미켈란젤로는 삼각형, 원, 사격형과 같은 기하학적 형태를 사용해 대칭적인 집합으로 구분했다. 이런 구조와 규율이 없었더라면, 300명에 이르는 인물은 예술적인 걸작품이라는 질서 정연한 구성 요소가 되기는 커녕 완전히 일대 혼란을 초래했을지도 모른다.

자 여기까지 왔으면, 규율의 중요성에 대해 독자 여러분들도 어느 정도 감을 잡으시리라 믿는다. 마지막으로 로버트 L. 글래스가 소프트웨어 크리에이티비티 2.0에서 언급한 규율에 대한 내용을 정리해보겠다.

시를 쓰는 사람들은 시 형식이 창의력을 구속하기보다 새로운 가능성을 제시한다는 사실을 안다. 운율을 맞추려고 고민하는 과정에서 (알맞은 단어가 눈에 띄기 바라는 마음으로 사전을 가나다순으로 뒤지는 등) 체계적으로 운율이 맞는 단어를 찾거나 창의적인 시어로 자신의 생각을 표현한다.

소프트웨어를 제작하는 과정도 크게 다르지 않다. 여기서도 체계와 창의력이라는 기묘한 단짝이 필수적이다. 예를 들면, 설계는 창의력이 필요하고 구현은 체계가 필요하다. 설계 방법론은 흔히 설계를 체계화된 활동으로 변환하려 들지만, 새로운 문제가 계속 쏟아지는 한 성공은 절대로 불가능하다. 물론 구현 단계에서도 창의력은 필요하다. 멍청한 컴퓨터에게 바람직한 해법을 하나하나 묘사하는 구현 단계에서는 엄청난 체계가 필요하지만, 완벽한 설계란 불가능하므로 설계에서 놓친 문제를 해결하려면 구현 단계에서도 창의력은 필수적이다.

오늘의 결론: 창의력과 규율을 조화롭게 가져가는 능력이 개발자의 필수 덕목이라는 사실을 잊지말자!

EOB
작성자: 시간: 댓글 1개:
라벨:

토요일, 8월 16, 2014

[일상다반사] 클린 코드 2쇄 임박과 특별 이벤트

작년 12월 말에 클린 코드 복간 소식을 전해드렸는데, 9개월 만에 1쇄가 다 팔려 2쇄 추가 인쇄에 들어간다는 기쁜 소식이 들어와 있다. 복간판임에도 불구하고 성원해주신 애독자 여러분 모두에게 진심으로 감사의 말씀을 전한다. 꾸벅.

여러분의 성원에 보답하기 위해, 클린 코드 발표 자료를 하나 올려드린다. 책을 읽는 과정에서 참고하면 좋겠다.

그리고, 클린 코드 2쇄 기념 특별 이벤트를 하나 준비하고 있다. 클린 코드로 그룹 스터디를 진행하려는 분들을 위해 초기 시작 단계에서 이 책을 효과적으로 읽는 방법과 핵심 포인트(상기 슬라이드 참고)를 소개해드리려 하는데(물론 특별 이벤트이므로 장소만 확보되어 있다면 당연히 무료로 진행해드린다!), 이메일(jrogue 에뜨 gmail.com)로 다음 내용을 간략하게 보내주시면 검토 후에 알려드리겠다. 꼭 필요한 분들께 기회가 가기 위해 프로 개발자분들께서는 넓은 아량으로 양보를 해주시면 감사하겠다. 신청 팀이 너무 많을 경우에는 두세 팀 정도를 선별할(아무래도 초기 단계를 타겟으로 하므로 이제 막 시작하는, 그리고 초보자들로 구성된 팀이 확실히 유리하다) 예정이다.

  • 동아리, 팀 이름(회사 소속이거나 일반 동호회거나 상관 없다)
  • 참여 인원 수
  • 클린 코드로 그룹 스터디를 시작한(할) 시점과 그룹 스터디 목표
  • 특별 이벤트를 신청한 이유와 바라는 바(구체적으로 기술하면 아주 좋다)
  • 그룹 스터디/세미나 장소

계속해서 '클린 코드'에 대한 많은 성원 부탁드리겠다.

EOB
작성자: 시간: 댓글 없음:
라벨:

목요일, 8월 14, 2014

[일상다반사] 2014년 FALinux 공개세미나 소식

오는 8월 20일 2014년 FALinux 공개세미나 소식이 있어, 혹시 자바와 IoT 관련해 관심이 있는 분들께 도움이 될까 글을 올려드리겠다. 기술 세미나 이외에 비즈니스 타임도 예정되어 있으므로 조금 색다른 만남의 장이 되지 않을까 예상한다. 참고로 블로그 주인장도 행사에 참석할 예정이며, 혹시 당일 세미나 또는 비즈니스 세션에 참석하실 애독자분이 계시면 댓글 부탁드리겠다. :)

EOB
작성자: 시간: 댓글 없음:
라벨:

화요일, 8월 12, 2014

[B급 관리자] 리더에게 가장 필요한 기술

하버드 비즈니스 리뷰 기사 중에 The Skills Leaders Need at Every Level라는 내용이 올라와서 재미있게 읽었다. 독자 여러분들께 여러 관리 위치에서 리더에게 가장 필요한 기술을 정리해드리겠다.

  1. 다른 사람들에게 영감을 주고 동기를 부여하는 능력(38%)
  2. 진실성과 정직을 보여주는 능력(37%)
  3. 문제 해결과 이슈 분석 능력(37%)
  4. 결과를 이끌어내는 능력(36%)
  5. 힘있고 왕성한 의사 소통 능력(35%)
  6. 협동과 팀워크 배양 능력(33%)
  7. 관계 형성 능력(30%)
  8. 기술적이고 전문적인 지식(27%)
  9. 전략적인 균형 감각(24%)
  10. 타인 계발(21%)
  11. 혁신 능력(16%)
  12. 변화 능력(16%)
  13. 그룹을 외부 세상과 연결하는 능력(12%)
  14. 도전적 목표 수립 능력(10%)
  15. 자기 계발 능력(9%)

사람들이 조직 상위로 올라갈수록 필요한 근본적인 기술은 급격하게 변하지 않는다. 물론 상대적인 기술의 중요도는 바뀌기 마련이라서, 중간 관리자는 문제 해결 능력이 아주 중요하다. 위로 올라가면 힘있고 왕성한 의사 소통 능력이 중요해진다.

스스로에게 현 상황에서 어떤 역량이 가장 중요한지 물어보는 이외에도 향후에 어떤 역량이 중요해지는지 물어보기 바란다. 앞으로 나갈 방향은 언제나 자기가 정하니까.

EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 8월 09, 2014

[B급 프로그래머] 기능으로 변한 버그

Software Engineering: What are the best examples of software bugs that became features (a.k.a. misbugs)?(소프트웨어 공학: 기능이 되어버린 소프트웨어 버그(소위 misbug)의 좋은 예제가 무엇일까요?)라는 재미있는 질문이 Quora에 올라와서 독자 여러분을 위해 몇 가지 재미있는 내용을 정리해드리겠다.

  1. 윙커맨드 종료 문구: 게임 중에 윙커맨드를 기억하고 계신 분이 있다면, 게임 끝날 때마다 "Thank you for playing Wing Commander!"라는 문구가 생각할지도 모르겠다. 이 문구가 출력되는 이유는 게임이 종료될 때 EMM386(!) 메모리 관리자에서 "EMM386 Memory manager error. 어쩌구 저쩌구"라는 예외가 출력되었기에 급히 출시하기 위해 메모리 관리자를 16진 편집기로 열어 오류 메시지를 수정한 결과라 한다. :)
  2. Gmail 취소 기능: 아는 사람들은 다 알고 있겠지만 Gmail에서 이메일 메시지를 처리할 때 대략 5초 정도 지연이 있다. Gmail 개발자들은 취소 옵션을 구현하는 방식으로 이 문제를 기능으로 바꿨다. 이왕 지연이 있는 김에 Gmail은 사용자에게 어떻게든 전송 전에 취소할 수 있는 버튼을 추가했다. 물론 사용자들은 이 기능을 무척 즐기고 있다.
  3. UNIX의 숨김 파일(.): 롭 파이크에 따르면 유닉스 파일 시스템에서 숨김 파일 기능은 버그였다고 한다. 오래 전 유닉스 파일 시스템이 개발될 당시에 .과 .. 항목이 등장해 탐색을 쉽게 만들었다. 하지만 ls 명령을 내릴 때, .과 ..이 나타나서, 켄과 데니스는 프로그램에 간단한 테스트를 추가했다(if (name[0] =='.') continue;와 등가인 어셈블 코드). 하지만 원칙적으로는 이름을 구성하는 모든 철자를 검사해야 마땅했다(if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;). 결국 이런 구현 때문에 점으로 시작되는 파일을 세지 못했고, 게으른 개발자(?)들은 이를 기능으로 여겨 홈 디렉터리에 안 보이는 파일이 늘어나기 시작했다. 참고로 Plan 9에는 숨김 파일이 없다.

혹시 독자 여러분들께서도 버그를 기능으로 사용하는 경우가 없는지?

EOB
작성자: 시간: 댓글 2개:
라벨:

화요일, 8월 05, 2014

[B급 프로그래머] 8월 1주 소식

8월 1주 소식을 전해드리겠다.

  1. 웹/앱 소식
  2. 개발/관리도구 소식
  3. 고성능 서버/데이터베이스 소식
  4. 기타 읽을거리
EOB
작성자: 시간: 댓글 없음:
라벨:

토요일, 8월 02, 2014

[B급 프로그래머] 이 세상에서 가장 큰 압축 파일은?

직전에 소개한 폴리글랏 프로그래밍의 '폴리글랏'을 소개하기 위해 위키피디아를 참조하다 The Polyglot List이라는 페이지를 방문하게 되었다. 여기서 퀸(Quine, /kwi:n/)이라는 단어가 나와서 GEB가 생각나고 말았다. 퀸은 출력 결과로 자신의 소스 코드와 완벽하게 동일한 텍스트를 만들어내는 프로그램이다. 잠시 예제를 볼까?

char*f="char*f=%c%s%c;main(){printf(f,34,f,34,10);}%c";main(){printf(f,34,f,34,10);}

이런 예제도 흥미롭지만, Quora를 읽다 더욱 흥미로운 질문을 발견했다. 바로 이 세상에서 가장 큰 압축 파일은 무엇일까?

정답은 42.zip이라는 ZIP 폭탄인데, 압축되면 42.374 bytes에 불과한 파일이 압축을 푸는 순간 4.503.599.626.321.920 bytes (4,5 petabytes)로 변신한다. 혹시라도 호승심에서 이 파일을 구해 압축을 푸는 순간 여러분 컴퓨터의 하드디스크가 꽉 차버린다는 사실에 주의하자. 42.zip 파일은 16개 압축된 파일로 구성되어 있으며, 각각은 다시 16개 압축된 파일로 구성되어 있으며, 다시 한번 각각은 16개 압축된 파일로 구성되어 있으며, 또 다시 한번 각각은 16개 압축된 파일로 구성되어 있으며, 또또 다시 한번 각각은 16개 압축된 파일로 구성되어 있으며, 최종적으로 4.3기가 바이트짜리 파일 하나를 포함한다. 헉헉 설명 한번 힘들다.

한 술 더 떠 Droste라는 파일은 무한히 자신을 증식하는 특성이 있다. 어떻게 이런 일이 가능할까? 바쁜 독자 여러분을 위해 미리 답을 드리자면, 퀸을 사용해 허프만 코딩에 따라오는 LZ77 명령을 복제하는 방법을 사용한다. Zip Files All The Way Down라는 글에 나온 LZ77 퀸 코드를 살펴보자.

눈치빠른 독자분들께서는 이미 짐작했을테지만, No-op을 사용해 일단 자기 자신을 그대로 복제하는 코드 작성에 성공했으므로, 여기서 앞뒤로 접두어와 접미어를 붙이는 방법만 찾아내면 경기는 끝난다. 무한히 자신의 코드를 실행하며 계속 크기를 늘일 수 있기 때문이다.

뱀다리: 이런 유형의 해킹은 재미도 있지만 함수형 언어(응?)에 대한 관심을 유도하기도 한다. Scheme을 사용해 퀸을 만들면 어떻게 될까?

((lambda (x) `(,x ',x))
'(lambda (x) `(,x ',x)))

아무리 봐도 정말 멋지다!

EOB
작성자: 시간: 댓글 없음:
라벨:
피드 구독하기: 글 (Atom)