Software Development

Steve Vinoski의 ‘Convenience Over Correctness‘라는 글에 대한 글이다.

Steve Vinoski는 CORBA Guru라고 불리우고 대형 CORBA 벤더 중 하나였던 IONA의 수석 아키텍트 (chief architect and fellow)였으며 CORBA 분야에선 바이블이라고 볼 수 있는 Advanced CORBA Programming with C++의 저자 중 한명이다. 현재는 CORBA와 같은 approach에 회의를 느끼고 IONA를 그만두었으며 최근에 그의 블로그를 보면 REST에 특히 관심을 보이고 있다.

예전에 A Note on Distributed Computing라는 제목의 페이퍼에 관해 요약한 적이 있다. 당시에 Sun RPC나 CORBA 등의 예를 들어 이 문제를 논해주면 좋겠다고 언급했었는데, ‘Convenience Over Correctness’가 바로 그런 글이다.

RPC 시스템의 본질

RPC-oriented systems generally represent remote services using the same abstractions and facilities used to represent local services, thus letting developers stay conveniently within the comfortable confines of their programming languages.

RPC 시스템의 본질은 A Note on Distributed Computing에서 언급된 문제들 – partial failure 등과 같은 문제를 가지고 있음에도 불구하고 프로그래머의 편이성을 얻기 위한 시스템이란 것이다.

RPC 시스템의 문제점들

그는 이어서 ‘A Note…’에서 언급된 문제 이외의 문제를 얘기하는데, 첫번째는 ‘Impedance Mismatch’ 문제로, CORBA IDL을 CORBA가 지원하는 여러 언어들로 mapping할 때 발생하는 문제를 얘기하고 있다. 두가지 이상의 언어를 대상으로 RPC 시스템을 만들어본 사람이라면 금방 이해할텐데, 서로 다른 언어의 타입 등을 mapping하기란 쉽지 않고, 설령 mapping이 가능하더라도 그것이 그 언어에 자연스럽지 않다는 것이다.

두번째 문제는 ‘Scalability Concerns’ 문제다. 분산된 시스템은 흔히 performance나 scalability를 위해 캐싱이나 필터링, 모니터링, 로깅 등을 관장하는 intermediary 시스템을 두는데, 이를 RPC 시스템에서 표현하기 위해서는 RPC call을 위한 정보 이상의 정보 즉, 메타데이터가 필요하다. 이를 위해서 현대의 RPC 시스템에서는 Java나 C# 등에서 지원하는 annotation을 이용하는데, 이러한 접근은 transparency라는 환상을 위해 복잡성을 추가할 뿐이라는 것이다.

이 문제에 있어서, Steve는 REST를 대안으로 내세운다. 네트워크의 영향을 시스템이 인지하면서도 깔끔한 layering과 separation of concerns를 유지한다는 것이다. REST를 다시 programming language 아래로 숨기려는 시도들을 비판하고 있다.

그는 RPC 시스템이 개발자의 편이성을 위해서 그 문제를 정확히 인지하고 있음에도 불구하고, 취약한 abstraction layer들과 임시 방편(bandages)들을 쌓아 올린 것에 불과하다고 본다. 그리고, distributed computing과 programming languages의 역사가 distributed computing의 necessary complexity를 너무 어려운 문제로 보고 프로그래머의 편이성을 위해 제대로 동작하지 않는 시스템을 만들어냈다고 비판한다.

대안

그는 RPC 시스템 대신 message queing 시스템이 발전했어야 한다고 강조하며, message queuing 시스템이 상용 제품에서도 대단히 비싸고 OSS 제품들도 최근의 XMPP나 AMQP 구현 외에는 없다는 점에 대해서 유감을 표하며, Facebook Thrift나 Cisco Etch가 XMPP/AMQP를 지원하거나 RESTful HTTP에 기반해야 하지 않겠냐는 의견을 피력한다.

결론

결론은 Steve의 글을 인용하는 것으로 마무리 하겠다.

(Facebook Thrift and Cisco Etch); perhaps both cases are instances of those not knowing history being doomed to repeat it.

It’s time for RPC to retire. I won’t miss it.

의견

한마디로 말하자면, Steve의 의견은 ‘Convenience가 정말 중요하고 실재하는 것인가? 오히려 Correctness가 중요하지 않은가?’인데, 내 생각은 ‘Convenience의 이익은 생각보다 크고 Correctness보다 Convenience가 중요할 때도 있다.’라는 것이다.

그럼에도 불구하고 Steve의 생각들은 구구절절 옳기 때문에, 주어진 문제에 따라서 접근 방법을 다르게 해야한다고 생각한다. 이를테면, intermediation이 많이 게재되거나 게재될 가능성이 있는 시스템에서는 애초에 RPC 접근을 하기 보다는 MQ 접근을 한다든가, RPC 시스템을 만들더라도 완벽한 transparancy에 목매지 않는 것이 그것이다.

기술이 항상 옳은 방향으로 발전하는 것은 아니지만, 실제적인 프랙티스로 반영되지 않는 것은, 그 기술의 방향이 옳지 않다는 것 이외의 다른 이유들 – 그런 기술을 수용하기 위한 기반 기술들이 마련되지  않았다라든가 – 이 있을 수 있다고 보는 편이다. 아직은 MQ/RESTful HTTP는 실험적이다. 하지만, 이들을 주시하고 지켜볼 일이다.

Ubuntu에서 VMware를 사용하고 계신 분이라면 이미 경험해봤으리라고 생각하지만, 이 문제의 원인과 Workaround를 찾아내는데도 오랜 시간이 걸렸기 때문에 혹시 도움이 될까 해서 적어둔다.

증상

잘 사용하다가 갑자기 Control, Shift 등의 키가 동작하지 않는다. xev 등에서 체크해봐도 이벤트는 발생하지 않는다.

발생 조건

Linux Host에 Windows Guest로 VMware를 사용하고 있다. gutsy에서는 아무런 문제 없이 VMware를 사용하고 있었는데, hardy로 업그레이드 하고나서부터 발생하기 시작했다. VMware는 윈도우 모드로 사용하고 있고, guest OS에 VMware Tools를 설치하고 seamless 모드 (키보드 입력 없이 마우스 이동 만으로 포커스)를 사용하고 있다.

원인

처음에는 hardy의 문제 – 특히 Xorg 7.3의 문제라고 생각하고, 결국 hardy를 새로 깔게 되었지만, 결국 찾아보다보니 VMware와 Ubuntu (정확히는 Xorg 7.3)사이의 문제이고, 어느 쪽의 버그인지는 정확히 모르겠다.

Ubuntu와 VMware 각각에 버그 리포트들도 존재하지만, (증상이 복잡하다보니 아래 외에도 여러 유사 증상에 대한 리포트가 존재한다.) 원인은 밝혀져있지 않은 상태다.

• Ubuntu의 Launchpad: https://bugs.launchpad.net/ubuntu/+bug/187165
• VMware communities: http://communities.vmware.com/thread/150155

해결책

해결책은 현재 없는 상태고, Workaround만이 존재하는 상태다.

두가지 해결책이 있다.

1. 문제가 발생할 때마다, setxkbmap을 실행해주는 방법. (본인의 경우에는 실행아이콘을 패널에 등록.)
2. Seamless 모드를 끄는 방법. (http://shhan.tistory.com/87 를 참고.)

VMware로 포커스를 주는 빈도에 따라 문제가 발생할 확률이 높기 때문에, 두가지 방법 모드 매우 불편하다.

다른 분들(태미 님, 한상헌 님)은 대체로 2번 방법을 사용하시는 것 같은데, 오늘부터 본인도 2번 방법을 사용하기로 했다.

MySQL Replication은 MySQL이 기본적으로 지원하는 데이터 복제 방식입니다.

MySQL Replication은 read-write가 가능한 Master와 read-only인 Slave로 구성되는데, Master는 쿼리 로그에 해당하는 binary log를 남기고, Slave는 asynchronous하게 이를 가져가서 반영하는 역할을 합니다. 설정도 간단해, 1-3줄 정도의 설정만 해주면 됩니다. 간단한 동작 방식에 기초해서 Multi-slave, Multi-master, Replication chaining 등의 구성 등이 가능합니다.

MySQL Replication의 문제점들

Master와 Slave가 최소한의 정보만 공유하는 단순한 방식이 장점인 동시에 단점으로 작용합니다.

1. Master-Slave pair 관리:서버들이 많아질 경우, Master와 Slave의 짝을 관리하는 것이 쉽지는 않습니다. Master와 Slave의 짝을 다른 어디선가 관리해주어야 합니다.
2. 실패 상황에서의 복구:당연히 자동으로 복구한다든가 하는 기능을 MySQL이 제공하지는 않습니다. Master가 실패했을 경우, Slave를 Master를 바꾼다든가, Slave의 데이터를 Master로 복사해준다든가 하는 작업은 순전히 수작업이 됩니다. Slave가 실패했을 때도, 마찬가지 입니다. Slave의 일시적인 오류라면, Slave는 자신이 반영한 로그의 위치를 기억하고 있긴 하지만, 이에 따른 복구도 사람 손이 갑니다.
3. binary log의 관리: Master는 Slave에 대해서 don’t care이므로, 언제 binary log를 삭제할 지는 주기 등을 사용합니다. 물론 삭제하는 command가 있지만, Slave들의 정보를 반영해서 자동으로 삭제하는 기능은 없습니다.
4. asynchronicity: Slave는 Master와 같은 데이터를 가지고 있다고 보장할 수 없으므로, Slave가 Master의 쿼리 처리량을 따라가지 못하게 되면, consistency 문제가 발생할 소지가 있습니다. 따라서, 애플리케이션에서 이러한 점을 신경써주어야 합니다. 이러한 점들 때문에, MySQL Replication을 백업으로 생각하지 말라는 조언들이 등장합니다.

1, 2, 3번의 경우에는 도구를 이용해서 극복할 수 있습니다. 1번, 2번에 대해서는 어느 정도 도구를 만들어 쓰고 있는데, 인터페이스를 웹 인터페이스로 개선하고 좀 더 자동화할 필요가 있습니다. Maakit이라든가 MySQL Replication Manager 등을 참고해볼만 합니다.

4번의 문제에 대해서는 MySQL Replication이 아닌 대안을 찾는 것이 옳을지도 모르겠습니다. 구글에서는 semi-sync 모드를 위한 패치를 내놓기도 했습니다.

MySQL Replication의 대안들

일반적으로 MySQL Replication을 얘기할 때는 다음과 같은 대안들을 함께 얘기합니다.

• MySQL Cluster: MySQL이 직접 지원하는 것 중에는 MySQL Cluster가 있지만, 아직은 메모리 기반 엔진인 NDB만 지원하기 때문에 메모리의 크기에 제약을 받습니다.
• DRDB: 디바이스 수준에서 디스크를 분산하는 DRDB를 MySQL과 함께 사용합니다. MySQL Replication보다 failure에 안전한 것은 아니지만, sync가 어긋난 상태는 최소화됩니다. 하지만, failover node (i.e. slave)는 MySQL 쿼리를 처리할 수 없다는 크나큰 제약이 있습니다. 백업의 용도로는 적절하리라고 생각합니다.

예전부터 관심을 두고 있던 Sequoia와 같은 데이터베이스 클러스터링 솔루션도 한번 써보고 싶고, 최근에 화제가 되고 있는 MySQL Proxy 와 같은 Proxy들(SQL Relay, dpm, Spock Proxy)을 사용해서 Replication을 잘할 수 없을까 생각이 들기도 하는데, 당장은 시간이 없다는 변명을 하렵니다.

어제부터 Introduction to Information Retrieval의 스터디를 시작했습니다. 최철호 군과 둘이서 하는데, 정해진 분량을 미리 읽어온 후, 스터디 시간에는 규칙 없이 번갈아가면서 요점들을 설명하고 이해가 안되는 부분들을 서로 토론하는 방식으로 진행하고 있습니다. 2명이서 하기 때문에 가능한 방식인 것 같습니다. 어제는 본문만 진행했는데, 레퍼런스에 있는 중요한 페이퍼들은 따로 읽어보아야 할 것 같고, 다음부터는 연습문제도 풀기로 했습니다.

첫 인상일 뿐이지만, 이 책에 대해서 칭찬하자면 다음과 같은 점들을 들 수 있을 것 같습니다.

• 쉬운 설명: 구성이나 내용의 측면에서 쉽고 간결합니다.
• 충실한 레퍼런스: Chapter 마다 레퍼런스가 달려있는데, 역사적인 측면까지 잘 정리해놨습니다.
• 실제 프랙티스 반영: 서로 다른 접근을 하는 이론들을 설명한 후에는 항상 실제 프랙티스에서는 어떤 접근을 사용하는가에 대해 설명합니다.

어제는 Chapter 1, 2를 진행했습니다. 일단 Chapter 9까지를 목표로 하고 있고, 매주 난이도에 따라 1개 또는 2개 Chapter로 진도를 나가면, 앞으로 두 달 내에 끝낼 수 있을 것으로 보입니다. 이 후에는 다른 책을 공부할지 그대로 진행할지는 고민해봐야 할 것 같습니다.

From An Introduction to Systems Biology: Design Principles of Biological Circuits by Uri Alon et. al. (via perky)

Understandability is a central feature of engineering, because engineers build complex systems out of simpler subsystems that are well understood.

소프트웨어 개발에서 흔히 Rocket Science는 대규모, 복잡성, 무거운 프로세스, 반복불가능 함을 비유하는 의미로 자주 사용됩니다.

매주 월요일 오전은 팀에서 (주로 엔지니어링에 관련된) 다큐멘터리를 보는 시간입니다. 얼마전에 BBC의 ‘Space Race’란 다큐멘터리를 EBS에서 ‘우주 전쟁’이라는 제목으로 방영한 것을 봤습니다. 말그대로 2차 대전 이후, 미국과 소련의 우주 경쟁을 주역들을 중심으로 극화해서 보여주는 다큐멘터리입니다. 지루하지 않고 가볍게 보기에 좋은 것 같으니 한번 보셔도 좋을 듯 합니다.

1. 나치 로켓의 비밀
2. 지구 밖으로
3. 최초의 우주인
4. 달을 향하여

이 다큐멘터리를 보고 나면 인간이 달에 착륙하기까지 얼마나 많은 치명적인 실패들이 있었는가를 깨닫게 됩니다. 로켓 발사 프로젝트란 비용 제약에 의해 반복하기 힘든 성격을 가지고 있고, 그 규모와 복잡성을 관리하기 위해 정확한 계획과 체계적인 테스팅을 위한 프로세스를 채용하고 있지만, 그렇다고 해서 실패하지 않는 것은 아니라는 것입니다.

하물며 우리가 경험하는 소프트웨어 프로젝트를 돌이켜보면, 역시 모두가 성공한 것은 아닙니다. 우리가 하루하루 부닥치는 일과의 업무들도 아마 모두 성공적이지는 않을 것입니다. 정확한 계획과 체계적인 테스팅, 그리고 프로세스가 중요하지 않다는 얘기가 아닙니다. 중요한 것은 실패가 발생했을 때, 무엇을 하느냐 입니다.

실패했을 때, ‘미안하다’라는 말을 하지마세요. 그 말이 자신과 동료의 기분을 조금 나아지게 할 지는 몰라도, 반경 10km 밖의 거주지에 떨어진 녹아들어간 파편 조각과 폭발에 휩쓸려간 우주인의 생명을 원래 자리로 되돌려 놓지는 못합니다. 엔지니어라면, 실패가 발생했을 때, 그것이 왜 발생했는가, 왜 방지하지 못했는가를 돌아보고, 다시 발생하지 않도록 하려면 어떻게 해야하는가를 가장 먼저 생각해야할 것입니다.

Excerpted from Code Isn’t Beautiful by Jeff Atwood:

The code itself is not beautiful. The beauty of code lies in the architecture, the ideas, the grander algorithms and strategies that code represents.

글을 쓰는 일은 쉬운 일이 아니다. 자신의 생각을 글로 변환하는 과정이 어렵다는 얘기는 아니다. (물론 그것은 어렵다.) 약간은 성격 탓이기도 할텐데, 자신의 생각이 다른 누군가의 뇌리 속에 또는 영원히 검색 엔진의 캐시를 떠돌며 다른 사람들에게 보여질지도 모른다는 생각은 글을 쓰는 행위 자체를 불편하게 만든다. 글을 한번 쓰게 되면 관련된 모든 정보 – 초기 역사로부터 모든 권위있는 평가 – 를 모아서 써야한다는 강박증도 있다. 이런 강박관념을 떨쳐내야지 하면서도 매번 잊게 된다. 어차피 내가 쓴 글은 일시적인 나의 생각일 뿐이고, 수정 가능하며, 사람들이 심각하게 생각하지도 않는다는 것.

XP의 프랙티스 중에 Small Releases라는 것이 있다. 말그대로 작은 릴리즈, 즉 릴리즈를 작은 단위로 자주 하라는 것이다. 작은 릴리즈의 장점은 여러가지가 있지만 내가 얘기하고 싶은 것은 즐거움이다. 릴리즈를 하면 ‘뭔가를 만들었다는 기쁨’을 느낄 수 있다. 그런 조그만 즐거움은 그 일을 계속 즐겁게 할 수 있도록 해주는 힘이 된다. 하루만에 릴리즈할 수 있는 일은 하루만에 릴리즈하라. 퇴근할 때 즐거운 마음으로 퇴근할 수 있을 것이다.

다른 하나 중요한 것은 필요한 일의 양을 초과하지 않게 해준다는 것이다. 작은 릴리즈를 하기 위해서는 필연적으로 일의 범위를 줄일 수 밖에 없는데, 그 과정에서 핵심적인 일이 무엇인지 가려내는 작업이 들어가게 된다. 다음 릴리즈에서 그 다음으로 핵심적인 일이 무엇인지도 쉽게 파악이 될 뿐만 아니라, 핵심적인 일이 더이상 없다면 일을 하지 않아도 된다!

작은 릴리즈는 소프트웨어 개발에서만 적용되는 것은 아니다. 뭔가가 비효율적인 것 같다는 생각이 들면, 당장은 부족하다 싶을 정도로 시간 제약을 두고 다음으로 미루어라. 정말 중요한 것만 다룰 수 있게 되고 덜 중요한 것은 버려지게 될 것이다. 만약 중요하나 잊어버린 것이 있다면 자연스럽게 생각이 날 것이다.

예를 들어, 회의가 너무 짜증나게 길다고 생각되면, 당장 회의 시간을 반으로 줄여보면 된다. 부족하다고 생각될지도 모르지만, 의외로 알찬 회의가 될 지 모른다. 물론 모자랄 수도 있다. 작은 릴리즈의 정신은 조그만 실험을 반복함으로써 더 좋은 방법을 찾아나가는 방식이다. 실패를 두려워하지 말고 변화에 적응하라는 것은 그런 얘기다.

문득 매일 매일 일터에서 생각하고 다른 사람들에게 특히 후배들에게 얘기한 것들을 돌아보면서 어딘가에 남겨두면 나중에 좋은 기록이 될거라는 생각이 들었다. 이 글도 그런 작은 릴리즈의 시도 중 하나다.

리눅스 데스크탑에서는 VMware Workstation을 구입해서 윈도우즈를 사용하고 있고, 윈도우즈 데스크탑에서는 VMware player를 이용해 리눅스를 사용하고 있습니다. VirtualBox는 국내 리눅스 사용자들의 IRC 대화와 블로그를 통해 알게 되었는데, VirtualBox는 VMWare, Microsoft의 Virtual PC와 함께 국내에서도 어느 정도 지명도가 있는 VM 소프트웨어 입니다. VirtualBox에 대한 재미있는 소식이 있더군요.

Sun이 VirtualBox를 만든 Innotek을 인수한다고 합니다. (via Tim Bray)

VM 기술은 사용자에게 매력이 있는 기술이나 중요한 기술의 수준을 넘어서서, 기술 자산으로 보유할 매력이 있을만큼, 점점 보편화된 – 다르게 말하면 싼 – 기술이 되어가고 있는 것 같습니다. ‘싼 기술’이란 것은 중요하지 않다는 것이 아니라 ‘시장’이 그 기술이 중요하다는 것을 인정했다는 것을 의미하는 것이죠.