'programming'에 해당되는 글 24건

  1. 2008.06.16 오늘 살펴본 것들
  2. 2008.05.29 어떤 웹서버를 사용할까? (5)
  3. 2007.12.06 제5회 루비세미나 - 발표 동영상 (2)
  4. 2007.11.04 TAOCP 스터디 예정 (4)

오늘 살펴본 것들

2008.06.16 20:08 from programming
구독 중인 RSS목록에 ThruDB - faster, cheaper than SimpleDB라는 제목의 글이 있는 것을 보고, 본문을 열어보았다. 최근 생각하던 RDB가 아닌 데이터베이스와 관련있을 것이란 직감. 살펴본 글들에 널린 Amazon WebService관련 내용들. 이전에는 Amazon EC2, S3등이 언급될 때, 아마존 사이트에만 한정된 그들만의 이야기인줄 귀를 닫고 있었는데, 조금 살펴보니 아주 흥미로운 서비스더군. 쭈욱 이어서 다음의 것들을 살펴보게 되었지.

  • Amazon SimpleDB
  • Amazon S3
  • Amazon EC2
  • ThruDB
  • Facebook Thrift

결국은, Amazon SimpleDB와 ThruDB가 내가 원하던 간단한 데이터베이스인거 같다. ThruDB의 경우에는 간단히 설치해보고 사용해 볼 수 있을 것 같다.

더불어 줄기를 따라 살펴보게된 Amazon EC2도 꽤나 흥미롭다. 본인이 운영할 시스템을 VM이미지로 떠서 S3에 올려놓으면 호스팅이 가능한 형태. 과금은 디스크사용량과, 네트웍 사용량, CPU사용량등의 리소스를 실제 사용한만큼 과금하는 시스템. 사용량이 적으면 적은만큼, 크면 큰만큼 돈을 내면 되는 개념.

서버 운영할 일 있으면 한번 시도해봄직 할것 같다.  

요약하면, Amazon이 제공하는 S3라는 디스크 저장소에다, 아마존의 가상머신 운영시스템 EC2로 운영할 VM이미지를 만들어 올려넣고 IP를 받아서 웹서비스를 운영할 수 있다. 그리고, 그렇게 올려놓은 VM에서 SimpleDB를 데이터베이스로 사용할 수 있다는 내용. 물론, SimpleDB대신에 다른 RDB나 ThruDB등을 EC2 VM에서 돌려도 될듯 하다.

살펴보면 볼수록 재밌는 것들이 많구나.

Posted by hatemogi 트랙백 0 : 댓글 0
웹서버하면 떠오르는 것은 Apache HTTP Server이다. 나역시 아무런 고민없이 아파치 웹서버만을 쓰다가, 지금은 기억나지않는 과거의 어떤 계기로 인해 lighttpd를 쓰게 되었었으며, 그러다 다시 nginx로 갈아타고, 그 후 지금까지는 nginx를 선호해 쓰고 있다.

물론 아파치가 가장 강력하고 훌륭한 기능들을 다양하게 제공하겠지만, 내게는 그 쓰지 않는 기능들의 필요성보다는 가볍고 간단함이 더 중요한 가치였다. 지금까지 내가 들어본 가볍고 간단한 웹서버는 lighttpd, cherokee, thttpd, 그리고 nginx였다. 이중에 실제로 사용해본 것은 lighttpd와 nginx이며 둘다 아주 만족스러운 기능과 성능, 그리고 편의성을 보여주었다. 지금으로써는 nginx에 너무도 만족한 나머지, 그다지 다른 웹서버를 바라보지 않고 있다. 아마도 아파치를 사용하는 대부분의 사람들도 그럴것이다. 충분히 만족스럽기 때문에 별다른 대안이 필요없는 상황일지 모르겠다.

내가 웹서버 사용에 있어 기대하는 가치은 무엇이었을까...

  • 성능(performance) & 안정성(stability)
  • 확장성(scalability) & 덩치(footprint)
  • 간편함
    • 간편한 설치(installation)
    • 간편한 설정(configuration)
    • 간편한 운영(operation)
  • 필요한 기능
    • rewrite
    • http_proxy (간단한 부하분산 기능을 포함하면 더 좋겠다)
    • virtual hosting
    • Linux와 MacOS X에서 사용가능

대부분의 웹서버가 이상의 가치를 모두 훌륭하게 실현하고 있을 것이다. 나라는 소비자와 웹서버라는 제품을 볼 때, 나는 이미 초과만족된 소비자인듯 하다. 덩치가 크고 설치/설정등의 작업이 복잡한 웹서버보다는 더 가볍고 간단한 웹서버가 매력적으로 느껴진다.

모든 웹서버가 필요한 가치를 모두 갖추고 있을 때, 어떤 웹서버를 선택해야하는지에 대한 고민이 의미가 있을까? 어떤 것을 써도 상관없는 것이잖아.

처음 아파치 대신 nginx를 도입할때에는 간단한 벤치마크를 해봤다. 아무런 튜닝(tuning)없이 기본 설정값으로 단순히 비교해보니, nginx가 우세했지만, 이미 둘의 성능은 내게 필요한 성능수준을 월등하게 뛰어넘었으므로 우열의 의미는 크지 않다. 결국 결정한 것은 설정의 편의성이었던것 같다.

이런저런 방법들로, 이성적으로 논리적인 판단과 비교를 해보려 애써보지만, 결국은 감성적인 판단을 내리게 되는 이런 상황을 뭐라고 부를지 궁금해진다. 감성적인(!) 판단으로는 이런상황 꽤 많이 있는거 같아. 

그래도 조금이라도 더 이성적인 비교를 원한다면,

http://en.wikipedia.org/wiki/Comparison_of_web_servers

여기를 뒤져볼 수 있겠다.


TAG nginx
Posted by hatemogi 트랙백 1 : 댓글 5
제5회 한국 루비사용자 세미나에서 우리 서비스를 기술적으로 소개하는 시간이 있었다. 매번 다른 분들의 발표를 듣기만 하다가, 우리의 서비스를 소개할 수 있는 뜻깊은 자리였다. 개발자 3명이 시간을 나누어 모두 발표해볼까 했으나, 산만할 것 같아서, 우리의 완소 개발자 성진님이 발표하시게 되었다.

난, 이날 얼떨결에 진행을 맡았는데, 동영상에 잠시 등장하여 질문과 답변시간을 몸빵했지.



또 발표할 수 있는 기회가 있으면 좋겠구나.
(아! 난 12분경에 등장 ^^)








Q&A

질문과 답변 내용을 가감및 보충해서 짤막히 다시 적습니다.

1. 레일스(rails)캠핑(camping)을 혼용해 썼다고 했는데, 그 비율은?
대부분의 주요 서비스는 레일스가 담당하고 있고, 주요서비스와는 조금 구분되는 간단하고 작은 별도의 업무에 대해, 별도 서버에 캠핑을 쓰고 있다. 캠핑의 비율은 매우 적다.
2. 캠핑 디플로이(deploy)는 어떻게 해서 쓰고 있는지?
엔진엑스(nginx) -> 몽그렐(mongrel) -> 캠핑으로 구성되어있다. 앞단에 엔진엑스가 요청을 받아주며, 캠핑은 몽그렐 프로세스안에서 실행된다.  
3. 캠핑의 앞단에 몽그렐이 있다는건, 몽그렐이 로드된 다음에 캠핑이 실행되는 것인가? 리퀘스트 하나에 대해서 몽그렐이 하나씩 뜨는 것인가?
몽그렐은 자바 서블릿 엔진처럼, 프로세스가 하나 떠있는 상태에서 매 리퀘스트마다 처리 쓰레드가 실행된다. 즉, 몽그렐 프로세스는 하나만이 실행된다.
4. 캠핑과 mod_ruby를 비교해서 어떤지?
캠핑은 가벼운 웹프레임웍이고, mod_ruby는 웹서버에서 루비로 처리할 수 있는 하나의 수단이라 비교 대상은 아닐 수 있지만, mod_ruby는 아파치(apache) 프로세스 안에서 돌아가기 때문에 단점이 될 수 있다고 생각한다. 캠핑자체는 단순한 업무를 구조적으로 해결하기에 꽤 재밌는 해결책이다.

5. 앞단에 L4 로드밸런서가 있는데, 왜 nginx를 써야하는가? L4에서 몽그렐로 바로 연결해도 되지 않는지?
첫번째로, Layer 4 로드밸런서로는 사용자 요청을 여러대로 나누어 처리하는 것은 가능하지만 Layer 7수준의 처리를 할 수 없다는 문제가 있다. http access log를 남기는 작업을 비롯해 http 프로토콜 수준의 url_rewrite등의 작업이나, 정적(static) 파일을 신속히 서비스하기 위해서는 중간에 L7수준의 작업을 간편하고 쉽게 처리할 수 있는 레이어나 웹서버가 하나 더 필요하다.

두번째는, 정책적인 사항인데, L4스위치를 관리운영해주는 본부가 따로 있기때문에, 개발자가 직접 제어하는 것이 바람직하지 않다는 이유이다. 중간에 개발자가 운영상황에 따라 손쉽게 제어할 수 있는 레이어가 하나 더 있는 것이 좋다는 판단이다. 
6. 개발인원은 몇명인가?
레일스개발자는 세 명이 자바스크립트 개발도 함께 하고 있으며, UI개발자분이 한분 더 있다.
7. 서비스를 살펴보니 RESTful하게 개발했는데, 오픈API에대한 고려가 있는것인가?
꼭 오픈API를 위해서가 아니더라도, RESTful 서비스 방식은 꽤 매력적인 개념이라고 생각한다. 내부적으로 RESTful 방식으로 개발되어있고, 캘린더 미니 역시 같은 방식으로 접근해 xml 데이터를 가져가서 사용한다. 우선은 다음내의 플랫폼 연동에 주력하고, 추후에 오픈API를 고려하고있다.

8. 자바개발자로써 루비를 써보니 어떤가?
코딩하는 재미가 있고, 코드 분량이 상당히 줄어든다. 처음엔 낯설고, 자바에 비해 참고문서가 적다는 점이 불편하기도 하지만, 그외에는 꽤 만족하고 쓰고 있다.

Posted by hatemogi 트랙백 0 : 댓글 2

TAOCP 스터디 예정

2007.11.04 13:56 from programming
사용자 삽입 이미지

개인적으로 "The Art Of Computer Programming" 공부를 시작하려합니다. 오래전부터 공부해야지 해야지하면서, 장식용으로만 활용되던 책이지요.


우선 1권을 조금씩 꾸준히 해보려 합니다. 혹시나 함께 공부하면 서로 도움이 될 수 있지 않을까 기대해봅니다.

함께하실 분은 댓글 달아주세요. ^^
Posted by hatemogi 트랙백 0 : 댓글 4

티스토리 툴바