( younjin.jeong@gmail.com, 정윤진 )


AWS와 함께 클라우드 서비스의 강력한 주자인 Rackspace 가 Openstack 을 사용한 클라우드 구현에 있어 필요한 내용들을 간단하게 정리한 레퍼런스 사이트를 오픈했다. 

http://www.referencearchitecture.org

이 블로그에서는 그동안 OpenStack 에 대한 내용은 한번도 언급하지는 않았지만, 모 기업에서 현재 서비스 중인 스토리지 클라우드 구현에 참여한 적이 있어 익히 알고 있다. 참여 하였다고는 해도 실제 코드를 반영하거나 했던 부분은 없으며, 주로 인프라 관련 문제의 트러블 슈팅에 참여 했었기에 전반적인 아키텍처라던가 구현의 방법, 자주 발생하는 문제는 어떠한 것들이 있는지에 대해 나름대로 경험을 가지고 있다고 생각한다. 

위의 사이트는 Rackspace가 겪었던 모든 경험을 말해주지는 않는다. 나 역시 주로 기업과의 계약관계에서 일을 하기 때문에 무엇이 어떻다 하고 말하기가 곤란한 경우가 더러 있다. 따라서 가장 중요한 것은 경험해 보는 것이며, 오픈스택이 다른 도구들에 비해 어떠한 장점과 단점을 가지고 있는지, 그리고 단점은 어떻게 다른 솔루션들을 통해 극복 해 낼 수 있는지에 대해서는 구현하고자 하는 서비스의 Use Case 에 따른 충실한 테스트와 튜닝이 함께 고려되어야 할 것이다. 

오픈 스택은 Rackspace 와 NASA 가 공동으로 참여하고 있는 오픈소스 프로젝트이며, 이는 크게 Nova 라 불리우는 컴퓨팅 클라우드의 구현 도구와 Swift 라 불리우는 오브젝트 스토리지, 그리고 Glance 라 불리는 이미지 서비스로 구성되어 있다. 이미지 서비스는 사진과 같은 이미지가 아니라, 클라우드에서 사용되는 VM 의 원본 템플릿을 지칭하는 말이다. 

클라우드에 관심이 있으신 분들이라면 이 오픈 스택에 대해 한번쯤은 들어 보았을 것이며, 이와 비슷한 도구들에도 경험이 있으리라 생각한다. 하지만 이 오픈 스택의 경우 인터넷을 통한 자료를 찾아 내는 것이 보통 어려운 일이 아닐 것이다. Zone 이 무엇인지, Multi-Node 클러스터는 어떻게 만들어야 하는지에 대한 위키페이지는 제공이 되고 있지만, 실제 이 Zone 을 몇개로 구성해야 하는지, 하드웨어 스펙은 어떻게 잡아야 하는 지에 대한 내용들은 찾아 내기가 쉽지 않을 것이다.

위의 사이트는 그러한 부분들에 대한 욕구를 일정 부분 충족 시켜 줄 것이며, 만약 Private 클라우드를 구현 하고자 한다면 도움이 될 수 있다. 다만, 여러분은 이 레퍼런스 페이지와 오픈 스택 사이트의 위키를 참조하더라도, 프로덕션 레벨의 서비스 구현에 있어서는 매우 큰 난관을 겪을 수도 있다. 이는 여러가지의 설정값이나 아키텍처의 선정에 있어서 고려해야 하는 부분이 매우 많으며, Python 으로 개발된 도구이기에 가지는 한계도 일부 발생 할 수 있다. 더군다나 운영의 측면에 있어서도 리눅스에 익숙하지 않다면 고난을 겪을 가능성이 다분히 있다.

오픈 스택 프로젝트는 델에서 지원하고 있다. 이는 Rackspace 와 Dell 이 매우 긴밀한 관계이기 때문인 것으로 보여지는데, 이러한 이유에서인지 델에서는 Crowbar 라 불리는 오픈스택 설치 도구를 최근에 배포하였다. 

http://content.dell.com/us/en/enterprise/by-need-it-productivity-data-center-change-response-openstack-cloud

이는 PXE 부팅과 Chef 를 통한 자동화된 도구이다. 따라서 간단하게 사용하기에는 나쁘지 않을 것으로 생각된다. 사용 방법이나 대해서는 위의 페이지를 참고하며, 개념에 대해서는 다음의 링크를 살펴보는 것도 좋다. 

http://robhirschfeld.com/2011/03/14/how-openstack-installer-works/

나는 지금 국내의 모 기업을 위한 클라우드 프로젝트에서 동일한 부분을 처리하는 코드를 만들고 있다. 이는 Crowbar 와 유사한 형태의 도구이지만, 보다 고객사에 최적화 되어 있다고 생각한다.

사실 델은 다른 HP 나 IBM 보다는 이런 부분에서 보다 빨리 움직이고 있는 듯 하다. DevOps 라 불리우는 사람들이 클라우드 인프라 개발에 있어 매우 중요한 역할을 하지만, 전 세계에서 오픈스택을 통해, 아니 클라우드 인프라 개발을 경험한 사람들은 극소수이다. 이는 전 세계를 통틀어도 3백명 이하의 인원들 뿐일 것이며, 따라서 클라우드를 구현하고자 하는 기업들에게 저러한 도구의 지원은 좋은 시작점이 될 수 있다. 물론 저러한 도구를 상용 서비스에서 직접 사용하는 것은 사용자의 판단에 달려있다는 말을 빼 놓으면 안될 것 같다. 

델이나 HP, IBM 하드웨어를 보면 전부 OEM 투성이다. 거기에 각 기업들의 관리 소프트웨어 또는 하드웨어와 서포트를 함께 파는 형국인데, 클라우드에 있어서 특히 저렴한 가격 경쟁력을 가지려는 클라우드 구현에 있어서는 저러한 하드웨어로는 비용이 높아 질 수 밖에 없다. 우분투를 쓰는것이 가장 좋은 시절이 올 줄은 몰랐지만, 아무튼 "우리는 우분투 따위의 리눅스는 지원하지 않습니다" 하는 벤더를 선정하게 되면 골치가 아플 것이다. 가장 범용적으로 많이 사용되고, 가장 많은 사용자들이 선택하는 하드웨어를 선정하는 것, 여기에 약간의 벤더를 지원하는 하드웨어라면 대다수의 기업에서도 만족하지 않을까 생각한다. 저렴하고, 지원되고, 델과 IBM, HP 에 팔리는 서버의 원형을 만드는 회사의 제품이라면 말이다. 


아무튼. 위의 내용들은 클라우드 구현에 관심이 있다면 한번 쯤 살펴보는 것이 남는 것이라 생각한다. 


( younjin.jeong@gmail.com, 정윤진 ) 

 

( younjin.jeong@gmail.com, 정윤진 )


IaaS 의 구조설계를 하게되는 경우, 전체 아키텍처에 가장 크게 영향을 미치지만 사실 별로 필요 없는 것이 2가지가 있다. 이 2가지는 많은 고객들이 아마존을 통해 경험한 사용성에 근간을 두고 있지만, 실제 아마존에서도 바로 이 부분 때문에 심각한 장애를 겪고 있다는 사실을 인지하고 있는 사람은 드물다. 이 2가지가 무얼까? 바로, Live Migration 과 EBS 서비스이다.

이 두가지는 IaaS 구현에 있어 각 클러스터의 크기를 제한하는 역할을 한다. 이 크기의 제한에 대한 핵심은 바로 이 두가지의 기능이 "Shared Storage" 를 필요로 하기 때문에 발생하는 것이다. Compute 클라우드 구현에 있어 이는 엄청나게 중요한 가치를 가지는데, 바로 이 부분 때문에 스토리지에 대한 비용이 급상승하고, 전체 클라우드 구성이 제한을 갖게 되며, 심각한 경우에는 일부 고객의 VM이 특정 하이퍼바이저 클러스터에만 생성되는 문제를 야기하기도 한다.

첫번째로, Live Migration 에 대해 살펴보자. 이 개념은 바로 가상화 기반의 Compute 클라우드에 위치한 VM이 어떠한 이유에서든 물리적으로 다른 위치 또는 클러스터 내의 다른 서버로 옮겨주는 기능을 말한다. 이는 서비스에서 "언제나" VM이 365일 24시간 죽지 않아야 한다는, 일종의 Availability 개념으로 이해 될 수 있다. 또한, 클라우드 내의 어떠한 서버에서든지 VM의 "이동"이 자유로워야 한다는 요구사항 때문에 발생한 것이기도 하다.

image from: http://vcommevirtuel.typepad.com/blog/

서비스 운영 중 하이퍼바이저가 사망하시는 경우는 충분히 발생 할 수 있다. 어떠한 이유에서든 하이퍼바이저를 동작하는 가상 서버의 사망은, 곧장 그 서버 위에서 동작하는 모든 VM들이 타격을 입게 된다는 말과 동일하다. 따라서 고객은 이러한 경우를 대비하여 Live Migration 을 IaaS 구현 요구사항에 넣는다.

결론부터 말하자면, 이는 완전히 잘못된, 또는 엄청난 제한을 가지게 되는 아키텍처를 만들어 낸다. 이 제약 사항 이라는 것은 바로 공유 스토리지가 필요하다 라는 부분이며, 이로 인해 얼마나 큰 사이즈의 스토리지를 어떠한 형태로 얼마나 많은 서버에 공유해야 하는가 하는 문제에 당면하게 된다. VM 하나, 하이퍼바이저 서버의 장애 한대를 피하기 위해 공유 스토리지가 붕괴하면 더 많은 수의 하이퍼바이저가 붕괴하는 구조의 선택이 필요해 지게 된다는 말이 된다는 것이다. 이제는 다시 공유 스토리지를 이중화 해야 하나 하는 고민에 빠지게 되며, 더 심각한 것은 (수 대의 하이퍼바이저 + 공유스토리지 ) 로 이루어진 하이퍼바이저 클러스터 한 덩이가 장애 대응의 최소 유닛이 된다는 점이다. 

한가지 더, 대부분의 하이퍼바이저는 Live Migration 을 위해 양쪽 서버가 모두 정상적으로 동작해야 한다는 요구사항을 가진다. 사실 서버가 잘 동작하고 있는데 VM을 옮겨야 하는 이유는 전체 서비스 퍼포먼스를 위한 오케스트레이션 밖에 없다. 이는 무슨 말인가? Live Migration 의 전제조건은 클러스터 내의 모든 서버가 정상인 상태에서만 정상적으로 동작하는 기능이다 라는 말이다. 

따라서 최초의 요구사항이었던 Availability 관점에서, 이는 필요 없는 기능이 된다. 애초에 모든것이 정상 동작하는 경우라면 Live Migration 을 해야 할 이유가 없다. 오케스트레이션은 클라우드 스택의 VM 분배 알고리즘이 충분히 똑똑하다면 Provisioning 단계에서 적절히 분산하여 처리해 주면 되는 일이다. 결론적으로, Live Migration 은 필요 없는 기능이 된다. 

서비스를 구현할 때 이보다 더 중요한 것은, 바로 VM은 언제나 잘못 될 수 있다 라는 생각을 가지는 것이다. 잘못되면 동일한 역할을 하는 VM을 새로 만들고, 기존의 VM을 중지시켜 지워버리면 될 일이다. 이게 보다 클라우드에 맞는 서비스 구조 설계가 된다. 

두번째로, EBS 와 같은 기능이다. 사실 아마존은 처음부터 EBS 서비스를 내놓지는 않았다. 기본적으로 클라우드의 VM은 몇대의 가상 서버를 사용하여 원하는 형태로 구성된 VM이 동작하는 환경과는 완전히 다른데, 그 중의 하나가 바로 이 디스크의 사용에 대한 부분이다. EBS 를 사용하지 않는 일반 VM의 디스크는 마치 메모리처럼 휘발성을 가진다. "영원히" 저장되는 기존의 물리 서버의 로컬 디스크와는 완전히 다른 것이다. 따라서 이러한 사용성을 보완하기 위해 개발한 것이 바로 EBS 서비스가 된다. 

아마존의 EBS 서비스는 DRBD를 기반으로 한 것으로 보인다. 실제 어떠한 구현 기술이 사용되었건 간에, 이는 기본적으로 하이퍼바이저와 네트워크로 연결된 별도의 (가상화된)스토리지에 데이터를 쓰는 것이다. 가상화란 무엇인가. 물리 서버 한대로 구성할 것을 여러대의 가상 서버를 사용하는 것이기에, 네트워크, 디스크, 프로세서 등 모든 자원을 나누어 사용한다. 따라서 일반 Public 클라우드를 사용할 때 누구인지는 모르지만 다른 사람의 VM이 나의 VM과 동일한 하이퍼바이저에서 동작하고, 둘 다 EBS를 사용하는 경우는 필연적으로 발생한다. 헌데 만약 이 다른사람이 서비스를 클라우드에 올려보려고 디스크에 대한 벤치마킹을 dd 같은 도구를 사용하여 진행 중이라면, 그 하이퍼바이저 내의 모든 EBS 사용 고객은 심각한 성능 문제를 겪게 될 수 밖에 없다. 

아마존은 이러한 사실을 알면서 왜 이 기능을 EBS에 넣었을까? 바로 Legacy 패턴, 즉 VM을 기존의 물리적 서버와 동일한 환경으로 사용하고 싶어하는 고객들이 많았기 때문이다. 따라서 그들은 각 고객의 인스턴스와 가상화된 볼륨의 매핑을 위해서 제법 복잡한 시스템을 구현하여 서비스에 성공했지만, 이로 인한 장애도 빈번하게 발생하게 된다.

EBS는, 역설적으로 데이터의 중요성이 높다면 반드시 사용하지 말아야 하는 서비스가 된다. 어떠한 데이터가 반드시 영원히 저장되어야 하고, 자주 변경된다면, 이러한 데이터는 EBS를 통해 저장하면 안된다. 아마존은 EBS를 기반으로 RDS 서비스도 구현하고 있기는 하지만, 이들 역시 성능과 사이징에 대한 제한이 있다. 이는 주제를 벗어난 좀 다른 이야기이지만, 클라우드에서 RDS와 같은 서비스를 사용하고자 한다면 반드시 Sharding 과 같은 기술을 고려해야 한다. IaaS 입장에서 RDS와 같은 서비스를 구현하고자 한다면, 이는 기존의 Compute 클라우드와 구분된 별도의 PaaS 형태로 독립적으로 구축해야 할 것이다. 


아무튼, EBS를 IaaS 구현시 고려사항에 넣게 되면 문제가 매우 복잡해 진다. 사실 EBS가 필요한 이유는 인스턴스에서 "영원히 데이터가 저장되어야 하는 로컬디스크" 때문이다. 하지만 인스턴스 자체가 영원하지 않다고 생각해 버리면, 구현과 운영이 힘들며 아키텍처에 심각한 제한 사항을 유발하는 EBS 와 비슷한 기능을 구현해야 할 이유가 별로 없다. 

이런식으로 생각 할 필요가 있다. 인스턴스를 처음 만들때 필요한 정보를 다운로드 받아 구성하도록 하고, 여기에 문제가 발생했을때 인스턴스를 그냥 없애버린다. 그리고 새로 만들면 된다.  이런 기능을 위해 이미지 서비스가 존재하고, Chef 나 Puppet, 또는 일반 스크립트등을 적절히 사용하면 된다. 아울러 무언가 지속적으로 저장되어야 하는 데이터들, 이를테면 AD 서버나 Exchange 서버를 클라우드에 올리고 싶은 경우도 있을 것이다. I/O 가 중요하거나, 저장되어야 하는 데이터가 매우 중요하다면 EBS를 쓰지 말고 하이브리드 형태로 구현하는것을 권고한다. AD나 Exchange는 그 사용량이 폭발적으로 늘어날 가능성이 있는 서버들이 아니다. 중요하고, 항상 동작해야 하는 Oracle 과 같은 서비스들은 클라우드가 지향하는 인프라의 개념과는 완전히 다름을 인지해야 한다. 

오히려 클라우드가 필요한 부분은 이미지 서비스, 영상 서비스, 미들웨어와 같은 언제든 사용량이 폭발적으로 증가 할 수 있는 서비스여야 한다. 이러한 서비스들은 클라우드에 매우 적합하며, 바로 넷플릭스스 서비스가 성공할 수 있는 이유이기도 하다. 렌더링이나 인코딩과 같은 기존의 병렬 또는 분산처리 시스템을 클라우드에 올리는 것도 좋다. 이들은 계산을 위해 "임시로" 로컬 디스크를 사용하지만, 더 중요한 것은 프로세싱 파워이기 때문에 I/O 로 인한 문제가 발생할 확률이 적다.

이러한 클라우드의 사용성에 비추어 보면, EBS는 Compute 클라우드와 직접 밀착되어야 하는 무엇은 아니다. Live Migration 과 EBS는, 함께 일하는 클라우드 아키텍트의 말을 빌리자면 "Fancy" 한 기능 이상의 무엇도 아니다.  클라우드의 컨셉에 맞는 서비스 설계는 이러한 사항들로 인해 매우 중요하다. 별로 빠르지도고, 그다지 안전하지도 않은 EBS 비슷한 시스템의 구현은 완전히 다른 방법으로 접근해야 하는 것이다. 

강력한 프로세싱 파워를 원하는 고객을 위해, 아마존은 HPC 클라우드를 별도로 제공한다. 마찬가지로, 강력한 I/O 를 원하는 부분은 분명히 있다. 그렇기에 지속적인 저장공간을 Compute 용 인스턴스에 반드시 붙여야 한다면,  I/O를 위한 별도의 서비스 오퍼링을 만드는 것이 훨씬 현명할 것이다. 높은 I/O 성능이 필요한 서비스는 보통 높은 프로세서 성능과, 많은 메모리를 함께 요구하게 되는 경우가 많다. 따라서 하이퍼바이저에 얼마만큼의 인스턴스를 올려 줄 것인가 하는 고민과 함께, EBS형태의 서비스가 필요한 고객 또는 서비스를 위한 별도의 고비용 아키텍쳐를 준비하는 것이 옳다고 생각한다. 


( younjin.jeong@gmail.com, 정윤진 ) 




 

( younjin.jeong@gmail.com, 정윤진 )

온전한 정신으로 살아가는 사람들 누구에게나 아름다웠던 시절을 회상하게 하는 것들이 있다. 좋았던 시절의 음악, 아직 망하지 않은게 신기한 전파사, 오랜만에 다시 걷게되는 장소의 익숙함. 언젠가의 그녀와 함께 보았던 영화의 사운드 트랙도, 특별한 선물을 해 보겠다며 손바닥 만한 오르골을 그녀의 손에 쥐어 주었던 것도, 어쩌면 그렇게 한 없이 그리워만 지는 기억인지. 이소라 누님의 노래처럼 서로의 추억은 다르게 적히겠지만.

누군가에겐 삼디다스 신발을 못신어 괴로웠던 시간도, 첫사랑과의 슬픈 사연으로 컴컴한 방에서 책상이 홍수가 나도록 울어제끼던 기억도 십수년이나 지난 지금 돌이켜 보면 웃음이 난다. 어리고 겁없던 시절, 앞으로 무엇이 어떤 사람이 될 지에 대한 실마리조차 없었던 그 시절이 그토록 아름다웠던 것은 아마도 어리기 때문에 당장 눈앞에 있는 무엇에 전부를 걸었기 때문이 아니었나 생각도 해본다.  

사회 생활을 하면서 고교시절 친구들을 만나면 매번 뭐 그리 할 말들이 많은지, 또 살면서 힘든 말을 섞으면 얼마나 위안이 되는지. 몇년을 붙어다니던 서로의 어린시절이 소중하기 때문에, 다시 올 수 없는 그 시절을 함께 추억 할 수 있는 사람이 또 소중하다. 십수년이나 연락이 없어도 다시 만나면 반가운 그 얼굴들이 바로 함께 야간 자율학습 도망치던 그 놈들이 아닌가 말이다. 

써니라는 영화는 명성은 자자했지만 도무지 극장에서 보고 싶었는데 못봤던 영화중의 하나이다. 어떤 영화 소개 프로그램에서 나왔던 80년대 민주화 운동의 새중간에서 코믹스러운 파이팅을 연출하는 장면을 보고 정말로 보고 싶다는 느낌을 받았더랬다. '아 이런건 봐 줘야 한다' 하고. 

영화에서는 시대의 아픔이 마치 아픔이 아니었던 것처럼 절묘하게 나타난다. 추억을 다루는 영화는 대부분 억지 눈물을 빼는 구성을 가지는 경우가 많지만, 이 영화는 복고라는 소재를 통해 현실을 되짚는다. 영화가 보여주는 영상을 그저 즐겁게만 바라보면 슬픈구석이 별로 없는 영화지만, 이 영화의 모든 소재가 온통 슬픈 것들 뿐이다. 그렇지만 그 슬픈 소재들을 누구나가 가지고 있을 법한 추억으로 절묘하게 감싸기에 또 묘한 감정이 인다. 

말만 하면 뭐에 그리 매일 화가 나 있는지 제대로 얼굴도 마주치지 않는 딸. 침대에 누우면 서로의 영역이 있어 어지간 하면 침범하지 않는 결혼 십수년차 남편, 사위의 명품 백 선물을 문병보다 좋아하는 어머니. 

민주화 운동한다고 밥상머리 앞에서 등록금 대주는 아버님께 대거리하는 아들이 잡혀갔다가 돌아오며 친구들 다 팔아 먹고 일그러진 얼굴로 현관에 주저앉으면, 우리의 어머님들은 그런 아들을 끌어안는다. 

그 아들이 나이들어 외국인 노동자들 등골 빼먹는 사장이 되고, 동생 보는 앞에서 그들에게 상욕을 들어 먹는다. 자본주의 욕하며 민주화 운동한다고 도망칠때 마주치던 눈빛과 이제 사장이 되어 착취를 하다 걸려 법원에서 판결 받을때 마주치던 눈빛을 가진 사람은 주인공의 오빠이고, 이 세상에 분명 있는 사람이다.  

밤새 친구와 통화하다가 라디오가 나오면 전화통과 라디오를 함께 붙들고 있다 보면, 또 그걸 이쁜 내새끼 하고 봐 주는 것도 할머니 밖에 없다. 

그시절, 본드나 가스를 불며 다른 친구들에게 막나가는 친구로 기억되며, 교육이란 마치 경찰서의 강력계와 같은 느낌의 교무실 학생과 학생 주임 선생님의 회초리만이 매섭던 그 떄. 

사채에 쩌들어 화류계로 빠져 자식과도 찢어져 사는 친구, 보험 설계사로 실적이 좋지 않아 매번 팀장에게 찐빵을 먹는 친구, 또 암에 걸려 오늘 내일 하는 친구, 어린 시절의 꿈을 잃고 시집살이에 쩔어사는 친구. 

이 영화는 추억을 가지고 좋았던 시절만 추억하는데 그치지 않는다. 오히려 지금 살고 있는 현실 또한 언젠가의 추억이 될 수 있다는 것을 보여주며, 지금도 그 시절처럼 살아야 한다 말한다. 하지만 현실은 어떤가. 친구와 친구로 지낼 수 있으려면 많은 것들이 필요해져 버렸다. 영화는 그런 것 조차 다 버리라 하지만, 그것이 어디 쉬운 일이던가. 결국엔 친구가 죽고 나서야 얼굴 비출 수 있는것이 지금 우리네 삶 아닌가 한다. 그런 날 정도 되어야 밥상 엎을 용기가 생기거든. 

영화 마지막의 크레딧에는 친구들이 함께 어떻게 늙어가고, 하나 둘 씩 써니의 멤버가 사라지지만, 모두 웃는 얼굴을 보여준다. 영화는 참 아련하다. 분명히 영화속 캐릭터들을 보고 있는데, 나를 보고 있는 듯한 환상에 빠진다. 그의 친구가 마치 내 친구 같다. '맞아 그때 저런녀석 있었지' 하는 생각, 그리고 '그래, 지금 저렇게 사는 친구가 있지' 하는 생각과 함께 우리의, 내 친구의 이야기를 한다. 그래서 그런지 캐릭터들 이름 중에 머리에 남는 친구는 '장미' 밖에 없다. 

내가 감독판을 보아서 그런진 모르겠지만, 얼음공주 같던 그녀의 마지막 등장은 살짝 의외였다. 사람들 사는게 참 신기해서, 누구하나 똑같은 모습으로 사는 사람이 없다. 그렇기에 서로 다른 그들 중 한 명 정도는 나타나지 않으리라 생각했었기 때문이다. 왜, 우리들도 이제는 어떠한 이유로든 연락이 되지 않는 친구 한둘 정도는 있지 않은가. 나 역시도 누군가에겐 이제 연락되지 않는 친구일 지도 모르는 일. 

슬프고 아픈 이야기를 하지만 밝은 영화가 된 것은 그 시절의 그들이 아름다웠기 때문이리라. 항상 아름다운 일들만 생긴 것은 아니지만, 어린 시절이기에 큰 일을 감당하기 더욱 힘들 었지만, 나이를 먹어 다들 다른 모습의 인생을 모두 친구로 만들어 주기 위한 오야의 능력은 대단하고, 그래서 영화에서의 밝음에 대한 정점을 찍는다. 그래서 그들의 지난 시절의 아름다움은 다시 몇십년이 지난 후에도 '적어도 내 인생의 주인공은 나' 라는 단순한 진실을 깨닫고, 그 깨달음이 주는 행복으로 다시 아름다워진다. 

어디서 누구와 함께 무엇을 하던, 그것은 또 다른 추억과 기억이 된다. 그 어린시절을 항상 되새기며 살긴 하겠지만, 더 늙어서 지금을 또 생각할 수 있는 것이 좋지 않겠는가. 

'복고' 라는 것은 지금 이 순간 좋은 추억을 만들고 있는 누군가에게 언젠가는 다시 좋은 향수를 일으키는 단어이기에, 또 그것이 모든 사람마다 서로 다른 것이기에 진부하지만 아름다운것.

언제의 누군에게나 사진 한장, 음악 한곡, 고교 시절에 보던 책에 끼워져 바래버린 낙엽, 이런 아주 작은 것들로 부터 일렁이는 소중한 감정들이 있을게다. 그 모든 것들이 한꺼번에 녹아있는 영화, 그래서 러닝타임 내내 무언가 아련한 영화. 지금은 나보다 10살쯤 많은 누님 형님들의 이야기. 

'길가는 저 머리 벗어지고 부하직원 잘 쪼을것 같은 40대 아저씨에게도 청춘은 있는 법이다' 

라는 별것 아닌 상상 만으로 한번은 웃게 해줄 영화. 


주말에 책과 코딩으로 지친 머리를 쉬게 하기엔 과분한 영화였나 보다. 여운이 너무 짙어 일요일 밤임에도 불구하고 친구놈을 불러다가 소주라도 한잔 해야 직성이 풀릴 것 같으니 말이다.

이런 한국영화 격하게 사랑한다. 

( younjin.jeong@gmail.com, 정윤진 )  

( younjin.jeong@gmail.com, 정윤진 ) 

생애 첫 번역서가 출간 되었다. 원서는 'Building Application in the Cloud: Concepts, Patterns, Projects' 이며, 원 저자는 Amazon Web Service 의 파이썬 클라이언트 프레임워크인 boto 개발에 참여했던 개발자다.

이 책에서 소개하고 있는 내용은 Hello World 를 찍어내는 것을 시작으로 하는 일반적인 개발서적은 아니다. 저자가 소개하고자 했던 내용은 기존의 애플리케이션을 어떻게 클라우드에 반영해야 하는가에 대해 설명한다. 설명의 도구는 기존에 많이 사용하고 있는 퍼사드, 커맨드, 맵/리듀스 등과 같은 일반적인 개발 패턴들의 클라우드 인스턴스에 대한 적용과, 클라우드 환경에서만 존재하는 이미지를 어떻게 생성해야 효율적인가 등에 대한 내용을 다룬다. 마지막에는 클라우드 환경에서 블로그를 만들때 필요한 개념들을 프로젝트를 통해 소개한다. 

이 책은 아마존의 클라우드가 어떠한 것인지, 또 어떠한 개념에 의해 현재의 서비스 제품군을 만들어 내었고 어떻게 사용할 수 있는지에 대한 간략한 설명들도 포함하고 있다. 따라서 대상 독자는 일반 웹 애플리케이션 개발자 뿐만 아니라 클라우드에 대한 이해가 필요한 영업, 클라우드 서비스 입안자 등에도 도움이 될 만한 내용이 있을 것으로 생각된다. 

책에 소개되는 코드는 대부분 파이썬을 기반으로 설명 되었으며, boto 라는 AWS 서비스의 클라이언트 프레임워크를 사용한다. 이 책에 소개된 코드는 글의 내용을 뒷받침하기 위한 도구로 사용될 뿐이므로, 책을 읽으시는 독자분들께서는 파이썬이나 개발 코드에 관련한 지식이 부족하더라도 분산에 대한 핵심 개념을 이해 하시면 될 것으로 생각된다. 

한가지 힘들었던 점이라면, 아무래도 번역을 위주로하는 역서이다보니 원 저자가 저술한 내용을 변경하거나 추가해야 하는 부분들이 있었지만 저작자의 의도하는 바를 거스르면 안된다는 부분이 아니었나 싶다. 뭐 전체의 흐름과 내용을 크게 거스르지는 않은듯 하다.  

역서를 소개하고 작업을 진행해 주신 제이펍의 장성두 실장님과, 서적을 출간하는데 많은 도움을 주신 SK Comms 의 장현희 (웹지니) 팀장님, 그리고 자바 스크립트와 전체 리뷰를 도와주신 경준호 매니저 (파이어준) 님 모두에게 감사를 드린다.

아, 그리고 Chef 를 통한 자동화 서적 출간이 준비중이다. 빠르면 11월 중순 경에 탈고를 할 수 있을 듯 싶다. 이것은 저서이므로 좀 자유로워서 편한 구석이 좀 있다.
 
아무튼, 클라우드 환경에서 애플리케이션을 개발하는데 조금이라도 도움이 되는 책이 될 수 있으면 좋겠다.

( younjin.jeong@gmail.com , 정윤진 )  

(younjin.jeong@gmail.com, 정윤진)

친구랑 술을 먹다가, WebLogic 과 Jboss 의 클러스터링 기능 때문에 매년 일정 라이센스 비용을 내고 서비스를 구축한다는 친구의 이야기를 들었다. 그녀석의 조직은 오픈소스를 워낙 겁내서, lighttpd 로 구현한 단순 static 파일 전송용 이미지 서버가 잘 돌아가지 않을까봐 걱정하는 조직에 몸담고 있다.

일이 이정도 되면, apache 를 왜 서비스에 사용하냐고 물어 볼 염두 조차 나지 않게 된다. 당연하겠지만 이런 대부분의 조직의 경우, 지원이 없는 제품을 굉장히 겁내곤 한다. 아... 생각해 보면 굳이 내 돈 들여서 라이센스 구매하는 것도 아닌데 왜 친구랑 박터지게 소맥을 마셔가며 언쟁을 했는지도 모를일이다.

아마도, 내가 웹 개발자가 아니어서 그런 듯.

세션 데이터의 특징을 보자.

1. 한번 쓰여지고, 자주 참조 된다.
2. 만료 시간이 되면 삭제해도 무방하다.
3. 여러대의 서버에서 참조될 가능성이 있다.
4. 데이터의 구조가 간단하다.
5. 전체 데이터를 잃어도 서비스에 크나큰 해악을 끼치는 경우가 드물다.

stateless 가 주가 되는 현대의 많은 웹 서비스들이 있지만, 그렇다고 세션 처리가 필요 없어지는 것은 아니다. 세션을 처리하는 방법에는 다음과 같은 것들이 있다.

1. L4 장치의 도입
2. Cluster 옵션 또는 라이센스가 제공되는 프레임웍 또는 WAS 의 사용
3. memcached / repcached 를 사용하여 각 페이지의 코드레벨에서 세션을 저장, 참조 하는 방법.

대부분의 국내 웹 사이트에서는 L4 를 사용한다. 클라우드에서는 apache 의 모듈 또는 nginx 와 같은 서버가 제공하는 proxy 를 사용하는 경우가 대부분이다. 이런 1~3번 구조와 같은 것들은 이미 그 구성을 다이어그램으로 그리기 조차 민망한 지경이라고 할까.

다만 3번의 경우, 많은 업장에서 그 효용성을 모르는 듯 하다. 지난번의 오픈소스 관련 포스팅에도 썼지만, 3번과 같은 방법을 꺼리는 가장 큰 이유는 보안도 아니고 코딩의 어려움도 아니고 바로 고장나면 누가 고쳐줄건데 의 인식이 제일 큰 듯 하다.

묻고 싶다.

L4 에서 persistent 또는 sticky 로 클라이언트 별 session 을 이미 기억하고, 클라이언트가 접근했던 웹서버로 이미 던져주고 있는데, 왜 WAS 레벨의 session clustering 이 필요한가. 만약 동작중인 WAS 가 사망했을 경우, L4 의 healthcheck 에 의해서 지정한 retry 와 지정한 timeout 이후에 고객은 '다시 로그인' 외에 다른 행위가 없을 텐데. 만약 세션에 기반한 장바구니와 같은 기능을 구현하고 있었다면, 저렴한 WAS의 N 대 만큼의 고객만 다시 로그인 하면 될 일이다.

만약 3번을 통해 구현했다면, L4 에서 굳이 비용을 들여 session state 를 저장할 필요가 없지 않겠는가.

repcached 사용시 multi-master session cache 로서의 사용은 논의가 필요한 부분이라고 볼 수 있다. heartbeat 을 사용한 repcached 의 구현과 같은 것들이 있을 수 있다고 본다. 다만 안타까운 것은, 상용이 아니면 불가능하다고 생각하고, 만약 오픈소스로 구현 했을 때 문제가 발생한 경우 1빠로 '전에 오픈소스로 바꾼거 그게 문제 아냐?' 라고 생각하는 어간없는 상식이 문제가 아닐까.

세션이 은행의 DB 트랜젝션 만큼 중요하다면 돈을 아낌없이 투자해도 할 말은 없다만, 단지 세션때문에 L4 구매하고, WAS의 클러스터 라이센스를 구매하고 있다면 해 줄 말이 없다. 1인 블로그 만들려고 오라클 엔터프라이즈 구매하는 경우랄까..

Cache 를 쓰는 방법에는 여러가지가 있지만, session 이라는 데이터 특성을 잘 고려해 보는 것이 필요할 수 있다. 물론 내가 틀렸을 수도 있지만, 국내의 잘 나가는 쇼핑몰의 세션 공유 처리에 잘 들 사용하는 것을 보면 많이 잘못 되지도 않은 것 같다.

JSP 는 많이 다를까?

음...
 

위와 같은 repcached 의 사용은 애플리케이션 별 검증이 필요하다.

한가지 더, memcached, memcachedb, repcached 등은 단순 세션 처리에만 사용되는 것은 아니다.
그리고, nodejs 짱이더라... 

NCache
http://cgeers.com/2010/07/11/ncache-distributed-in-memory-object-cache/

Nginx Subsystem, NCache
http://code.google.com/p/ncache/
http://code.google.com/p/ncache/wiki/HowToNcacheV3
http://code.google.com/p/ncache/wiki/HowToNcacheV2

Repcached
http://repcached.lab.klab.org/

Memcached
http://memcached.org/

Consistent Hashing
http://weblogs.java.net/blog/tomwhite/archive/2007/11/consistent_hash.html

Terracotta
http://www.terracotta.org/

Java EE scaling article
http://www.theserverside.com/news/1320914/Scaling-Your-Java-EE-Applications-Part-2

Hazelcast ( In Memory Grid )
http://www.hazelcast.com/documentation.jsp

memcached-session-manager
http://code.google.com/p/memcached-session-manager/

PHP session memcached
http://www.ducea.com/2009/06/02/php-sessions-in-memcached/

EHCache
http://ehcache.org/



(younjin.jeong@gmail.com, 정윤진)