Category Archives: Crew Ship Log

독일 ‘로맨틱가도’를 포함하는 여행, 인/아웃을 못 정하겠어요!

Would you prefer English? (Clink this!)

Neuschwanstein Castle

Neuschwanstein Castle

Photo Credit: Marco Cortese

“프랑크푸르트 – 쾰른 – 로만틱가도(1일) – 파리(2일) – 스트라스부르(1일) – 루체른(1일) – 인터라켄(2일) – 밀라노(2일)- 베네치아(2일) -로마(3일)

유럽 여행을 계획 중인데, 독일 In/로마 Out 으로 할지, 쇼핑도 좀 해야해서 파리In/로마 Out 할지 고민입니다. 루트를 어떻게 할까요? “

오늘의 루트 뽀개기는 로맨틱가도를 포함하는 일정입니다.
인/아웃은 “여행의 시작 – Arrangy”로 정하셔야죠 🙂

로맨틱 가도는 뷔르츠부르크(Würzburg) ~ 로텐부르크(Rothenburg) ~ 뇌르틀링겐(Nördlingen) ~ 아우크스부르크(Augsburg) ~ 퓌센(Füssen) 까지 이어지는 독일의 대표적인 관광코스입니다.

Bayern - Romantische Strasse

로맨틱 가도

Photo Credit: Roos Postcards

Würzburg

Würzburg

Photo Credit: Floris Oosterveld

• 로마 In/파리 Out (2,895 Km)

클릭하면 직접 볼 수 있어요!

• 로마 In/프랑프쿠르트 Out (3,193 Km)

클릭하면 직접 볼 수 있어요!

로마 In/파리 Out (2,895 Km) < 로마 In/프랑프쿠르트 Out (3,193 Km)

로마 In/파리 Out 이 효율적이고, 거꾸로 파리 In / 로마 Out 도 괜찮은데 쇼핑은 마지막에 하는 것이 적절하니 파리 Out 이 더 좋겠네요.

“로마(3박) – 베니스(2) – 밀라노(2) – 인터라켄/루체른(3) – 로만틱가도(퓌센(1)/아우구스부르크/뇌르들링겐(1)/로덴베르크/뷔르츠부르크(1)/프랑크푸르트) – 퀠른(2) – 스트라스부르(2) – 파리(5)” (Arrangy 기준 일정)

Arrangy 기준 일정과 원래 일정을 비교해보면, 독일, 프랑스 일정이 타이트 하네요.

Colorful Rothenburg

Colorful Rothenburg

Photo Credit: Mathias Liebing

• 로만틱가도를 좀 줄이면?

클릭하면 직접 볼 수 있어요!

로만틱가도를 좀 줄이면,

로마(3박) – 베니스(2) – 밀라노(2) – 인터라켄/루체른(3) – 로만틱가도(퓌센(1)/아우구스부르크/뇌르들링겐(1)) – 스트라스부르(2) – 퀠른(2) – 파리(5)

정도 되는데, 더 줄이고 싶다면 퓌센/아우구스부르크 정도에서 빠져 나와야 겠네요;;

여행 일정과 가고 싶은 곳을 타협하는 것은 언제나 어렵네요.


이 글은 Arrangy 페이스북 페이지에서도 볼 수 있습니다.
Advertisements

Adieu 2015!

20151229_152644

텐트 설치 중~

20151229_160618

텐트 완성!

20151229_192524

2015년 수고했어요!

IMG_0697

내 고기는 언제 줘요?

20151229_180939

2016년은 더 활활 타오릅니다!

2015년을 마무리하고 창업 7주년을 기념하기 위해서 캠핑을 떠났습니다.
2015년 모두들 수고하셨습니다!
새로운 모습으로 2016년에 뵙겠습니다.

bcache on Xenserver 6.5 by static linking

Would you prefer English? (Clink this!)

Why bcache?

bcache는 빠르지만 용량이 제한적인 SSD를 느리지만 저장 공간이 충분한 HDD의 캐시로 활용하는 linux kernel 모듈입니다.(like OSX fusion drive) 리눅스 커널 버전 3.10 이상이면 포함되어 있어서 Ubuntu (14.04.3 ~, 15.04 ~), Fedora (20~) 에서는 아래 명령어로 손쉽게 적용가능합니다.

ubuntu, install bcache-tools

apt-get install bcache-tools

fedora, install bcache-tools

yum install bcache-tools

우분투 15.04 + bcache + lvm2 + iscsi tgt으로 꽤 재미를 봐서 Xenserver 에 사용할 수 없을까 고민 중이었습니다.(4K 32 랜덤억세스 5MBytes/sec, core2duo 32bit)

Using bcache on XenServer 6.5

Xenserver 6.2 까지는 Linux Kernel Version 2.6 을 사용하기 때문에 bcache를 사용하기 어려웠지만, Xenserver 6.5 는 CentOS 5.10 기반으로 Kernel v3.10을 사용하기 때문에 bcache를 사용할 수 있습니다.

bcache는 bcache kernel module + bcache-tools user module 로 구성되어 있는데, 커널에 포함되어 있다면 bcache-tools 만 설치하면 사용할 수 있습니다. Ubuntu, Fedora 의 bcache-tools 도 커널 모듈이 아닌 bcache를 제어하기 위한 모듈을 설치해주는 패키지 입니다. Xenserver 에서도 커널에 bcache 모듈을 이미 포함하고 있기 때문에 bcache를 제어하는 bcache-tools (User space 모듈)만 Xenserver 에 올리면 됩니다.

다만, Ubuntu, Fedora 는 bcache-tools 설치 패키지가 존재하는데, Xenserver 가 오래된 CentOS 5 를 기반으로 하고 있기 때문에 Ubuntu나 Fedora 처럼 설치패키지가 존재하지 않습니다.

CentOS 5에서 bcache-tools package 가 존재하지 않는 가장 큰 이유는 CentOS 5.10 이 아직 2.X kernel 을 사용하기 때문일 것입니다. Xenserver 6.5 는 CentOS 5.10을 기반으로 하지만, 커널은 3.10 이상을 사용하기 때문에 bcache 를 사용할 수 있는 것입니다. (Xenserver 6.5 != CentOS 5.10)

bcache-tools가 yum/apt package에 없다면 직접 빌드해서 설치하면 됩니다.

다만, bcache-tools 을 설정 그대로 빌드하면 shared library 를 사용해서 빌드되는데, 이 경우 Xenserver 6.5 의 .so 와 일치 시켜야 되는데 일치 시키기가 쉽지 않습니다. shared library 를 일치 시키려면 bcache-tools 를 Xenserver 6.5 에서 빌드하면 가장 좋은데, build 에 필요한 libblkid, libuuid 가 오래된 버전이어서 bcache-tools 에서 사용되는 함수가 빠져 있습니다. (CentOS 5 epel repository 의 libblkid, liquid) 그렇다고 Xenserver 6.5 의 shared library 를 업그레이드 하자니 다른 모듈이 영향을 받을 것이기 때문에 일이 너무 커집니다.

커널 모듈은 올라가 있고 user space excutable 만 있으면 실행할 수 있는데, shared library version 맞추기가 어려워서 빌드하기 어렵습니다. 어떻게 해야 할까요?
그러면 Xenserver 의 Shared Library 에 영향받지 않도록, bcache-tools 를 Static Library 로 빌드하면 됩니다.

그래서 우리는 bcache-tools 를 libblkid, libuuid 를 포함해서 static library 로 빌드하기로 했습니다.

Xenserver 를 사용하거나 또는 kernel 은 지원하는데 user space module 실행에 어려움을 겪는 분들을 위해서 아래에 삽질한 내용을 공유합니다.

Check Kernel Support

 # uname -a

Linux xenserver 3.10.0+2 #1 SMP Tue Dec 9 12:45:36 EST 2014 x86_64 x86_64 x86_64 GNU/Linux

Xenserver 에서 Kernel version 을 확인합니다. 3.10 이상이면 bcache 가 포함되어 있습니다.

# modprobe bcache

# lsmod|grep bcache

bcache 200549 4

# ls /sys/fs/bcache/

register register_quiet

확실하게 하기 위해서 커널 모듈을 로딩하고, /sys/fs/bcache 가 존재하는지 확인합니다. bcache 모듈이 로딩된다면 /sys/fs/bcache/ 가 반드시 존재해야 합니다.

Build Dependency (On Build Machine Not “XenServer”)

build util-linux – libblkid,libuuid

Xenserver 6.5 DDK 에서도 빌드가 가능할 수도 있는데, 개발환경을 맞추는 것이 번거로워서 Fedora 20 (linux kernel 3.11.10-301) 에서 bcache-tools을 빌드하기로 합니다.

bcache-tools 가 libblkid, libuuid 를 필요로 하는데, Fedora 20 의 패키지인 (libblkid-devel libuuid-devel) 이 shared library 만 설치하고 가장 필요한 static library는 포함하지 않아서 libblkid, libuuid도 직접 빌드 합니다.

 $ git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git util-linux

$ cd util-linux

$ ./autogensh

$ ./configure

$ make

$ sudo make install 

install glibc

$ sudo yum install glibc-static

아마도 glibc 도 shared library 만 설치되어 있을 것입니다. 그래서 glibc도 static version 을 설치합니다.

Build Bcache-tools (On Build Machine Not “XenServer”)

get source

$ git clone http://evilpiepirate.org/git/bcache-tools.git

dependency 를 맞추었으면, 이제 bcache-tools 을 빌드합니다. 빌드하기 위해서 source 를 가져옵니다.

edit Makefile

#make-bcache: LDLIBS += `pkg-config –libs uuid blkid`

make-bcache: LDFLAGS += -static

make-bcache: LDLIBS += -lblkid -luuid

#make-bcache: CFLAGS += `pkg-config –cflags uuid blkid`

make-bcache: CFLAGS += -I/usr/include/blkid

make-bcache: bcache.o

#probe-bcache: LDLIBS += `pkg-config –libs uuid blkid`

probe-bcache: LDFLAGS += -static

probe-bcache: LDLIBS += -lblkid -luuid

#probe-bcache: CFLAGS += `pkg-config –cflags uuid blkid`

probe-bcache: CFLAGS += -I/usr/include/blkid

#bcache-super-show: LDLIBS += `pkg-config –libs uuid`

bcache-super-show: LDFLAGS += -static

bcache-super-show: LDLIBS += -luuid

bcache-super-show: CFLAGS += -std=gnu99

bcache-super-show: CFLAGS += -I/usr/include/blkid

bcache-super-show: bcache.o

bcache-register: LDFLAGS += -static

bcache-register: bcache-register.o

원래 bcache-tools Makefile 을 위와 같이 수정해 줍니다. 살펴보면 shared library 를 static library 를 사용하도록 변경하고, pkg_config 을 사용하지 않기 때문에 빠진 header 를 include 하도록 변경하는 내용입니다.

build bcache-tools with static library

$ make

Makefile 을 수정했다면 make 로 bcache-tools 를 Fedora 에서 static build 합니다.

Install Static Linked Bcache-tools (On “Xenserver”)

get bcache-tools with static library

static library 로 build 한 bcache-tools 에서 필요한 것은 모듈을 모아서 Xenserver 6.5 로 옮겨 줍니다. (make-bcache, bcache-super-show, probe-bcache, bcache-register, 69-bcache.rules)

위의 build 가 귀찮은 분들을 위해서 저희가 빌드한 모듈을 링크해 둡니다. (static linked bcache-tools by Hubrite) 링크의 파일에서 69-bcache.ruls 는 Fedora 20 를 참조해서 수정했고, 원래 bcache-tools 에는 없는 bcache.modules 를 포함하고 있습니다.

install bcache-tools

# install -m0755 make-bcache bcache-super-show /usr/sbin/

# install -m0755 probe-bcache bcache-register /lib/udev/

# install -m0644 69-bcache.rules /lib/udev/rules.d/

옮긴 파일을 위와 같이 Xenserver 6.5 에 설치합니다.

create /etc/sysconfig/modules/bcache.moduels

lsmod|grep -q bcache||/sbin/modprobe bcache >/dev/null 2>&1

# chmod +x /etc/sysconfig/modules/bcache.modules

부팅할 때 로딩하기 위해서 bcache.modules 를 추가해 주고, 실행 권한을 줍니다.

run bcache (automatic attach)

# make-bcache -C /dev/md2 -B /dev/md3 –writeback –discard

bcache 를 로딩하고 (modprobe bcache), bcache-tools 를 설치했다면 이제 bcache 를 동작시킬 수 있습니다. 위의 예는 /dev/md2 를 cache device (SSD) 로 사용하고, /dev/md3 를 backup device (HDD) 로 사용하는 예입니다.

makebcache 에서 -B,-C 를 한꺼번에 지정하면 추가 과정 없이 (attatch) bcache를 사용할 수 있습니다. 따로 하는 방법은 뒤에서 다시 설명합니다. (manual attach)

edit /etc/rc.local

echo /dev/md2 > /sys/fs/bcache/register

echo /dev/md3 > /sys/fs/bcache/register

blkid 버전이 높으면 (2.24 이상) 다음번 부팅에서 bcache device 를 자동으로 찾겠지만, Xenserver 의 blkid 는 버전이 낮기 때문에 bcache device 를 부팅할 때마다 register 해줘야 합니다. 그래서 make-bcache 에서 포맷한 bcache device 를 rc.local 에 넣어 줍니다.

/etc/sysconfig/modules/bcache.modules 에 추가해도 되는데, 저희는 md device를 사용하기 때문에 부팅 시퀀스가 모두 끝난 후에 register 해야 원할하게 동작하기 때문에 rc.local 에서 bcache device 를 registration 합니다.

edit /etc/lvm/lvm.conf

types= [ “nvme”, 64, “mtip32xx”, 64 , “bcache”, 251,]

위의 과정까지 하면 bcache block device 를 사용할 수 있습니다. (/dev/bcache0) 이제 /dev/sdX 를 사용하는 것 처럼 /dev/bcache0 을 사용할 수 있는데, Xenserver 에 필요한 lvm 을 사용하기 위해서는 lvm 에 bcache type 을 위와 같이 알려줘야 합니다. lvm.conf 를 수정하지 않으면 pvcreate 에서 filter 되는 것을 확인할 수 있습니다. (kern.log or pvcreate -vvv /dev/bcache0)

create SR

# xe sr-create content-type=user device-config:device=/dev/bcache0 \

host-uuid=”YOUR XenServer HOST UUID” name-label=”Local Storage (bcache)” \

shared=false type=lvm

LVM 에 bcache type 을 알려 주었으면 이제 Xen Storage Repository 를 드디어 만들 수 있습니다. 이 것 만들려고 여기까지 삽질한 것 아니겠습니까? 🙂

그 밖에

Bcache Manual Attach

 # make-bcache -C /dev/md2

# make-bcache -B /dev/md3

# echo /dev/md2 > /sys/fs/bcache/register

# echo /dev/md3 > /sys/fs/bcache/register

# cat /sys/block/bcache0/bcache/state

no cache

# bcache-super-show -f /dev/md2|grep cset.uuid

XXXXXXXXXXXXXXXX

# echo XXXXXXXXXXXXXXXX > /sys/block/bcache0/bcache/attach

# cat /sys/block/bcache0/bcache/state

clean 

make-bcache -C /dev/md2 -B /dev/md3 처럼 cache device (SSD) 와 backup device (HDD) 한꺼번에 만들지 않으면 backup device 에 cache device 를 attach 하는 과정이 필요합니다. 위의 attach 는 딱 한 번만 해주면 됩니다.

HDD 에 SSD 를 attach 하는 과정이라고 이해하면 됩니다. 그래서 ssd 의 cset.uuid 를 hdd 에 write 하는 것이고, 실제로 attach 전 후의 HDD 의 cset.uuid 를 bcache-super-show 로 관찰해보면 attach 하면 HDD 의 cset.uuid 가 ssd 의 cset.uuid로 변경되는 것을 볼 수 있습니다.

유용한 command

bcache 동작확인

# cat /sys/block/md2/bcache/running

1

cache mode 확인 및 변경

# cat /sys/block/md2/bcache/cache_mode

writethrough [writeback] writearound none

# echo writeback > /sys/block/bcache0/bcache/cache_mode

SSD trim 을 위해서 discard 명령 활성화

# echo 1 > /sys/block/bcache0/bcache/cache/cache0/discard 

Segmentation Fault, make-bcache –wipe-bcache

# make-bcache -C /dev/md2 -B /dev/md3 –wipe-bcache

segmaentation fault

# dd if=/dev/zero of=/dev/md2 bs=512 count=1000

# bcache-super-show -f /dev/md2 

위에서 빌드한 static linked bcache-tools 는 –wipe-bcache 옵션을 주면 segmentation fault 가 발생합니다. 그래서 사용하던 bcache 장비를 다시 bcache 장비로 만들 때, bcache signature 를 지우는 wipe-bcache 는 사용할 수 없고 대신 dd 를 사용해서 bcache super block 을 지워줘야 합니다. wipefs -a 를 사용해도 되는데, Xenserver의 wipefs 도 버전이 낮아서 -a 를 사용할 수 없습니다.

꼭 이렇게까지 해야하나요???

서비스하고 있는 여행의 시작 – Arrangy.com 의 메인 서버는 All SSD 로 구성되어 있습니다. SSD 값이 아무리 내리고 있다지만 TB 단위로 SSD 를 구매해서 서버를 채우는 것이 쉬운 일만은 아닙니다. 그래서 추가되는 서버들은 조금 더 경제적인 방법을 찾기 위해서 위해서 위의 삽질들이 필요합니다.

그래서 위의 삽질의 결과가 아래의 performance 입니다. bcache write-back 모드에서 테스트한 결과인데, write 는 HDD 를 어느 시점에서든지 거쳐야하기 때문에 read 성능보다 떨어지지만 추가 비용 없이 read/write 를 어느 정도 수준에서는 확보할 수 있을 것으로 예상합니다.

cache 가 SSD 에 있을 때의 이야기겠지만, 4K random 기준으로 read 13Mbytes/Sec, write 15Mbytes/Sec)는 전체가 SSD로 구성된 서버보다 우수한 결과를 보여주고 있습니다.

bcache performance (Windows10 VM, 4 x SSD RAID 0 + 2 x HDD RAID 1, SR)

All SSD Performance (Windows10 VM, 4 x SSD RAID 10)

우리가 한 삽질이 다른 분들에게도 도움이 되기를 기대하고, 더 깔끔한 솔루션은 다른 분들이 만들어 주시겠지요?

‘bcache’는 아래의 ‘여행의 시작 – Arrangy’ 서비스를 만드는데 사용하고 있습니다. 서버 보충했으니 다시 서비스 만들러 갑니다~

 

유럽 축구 성지 순례, 4,026Km
여행의 시작 – Arrangy (지도 클릭하면 실제 확인)


Fez

모로코 Fez 여행 계획,  Arrangy

왜 Arrangy 를 사용해야 할까요?  ‘여행의 시작 – Arrangy’ 가 궁금하지 않으세요? (클릭)


Voeasy 서비스 종료 알림 – 2015.4.15

안녕하세요? 함께 만드는 투자정보 – Voeasy를 서비스하고 있는 허브라이트 주식회사입니다.

Voeasy를 사용해 주셨던 사용자님들께 2015년 4월 15일로 Voeasy 서비스를 종료하게 되는 것을 알려드립니다.

무엇보다도 그동안 Voeasy를 이용해주신 여러분께 진심으로 감사의 말씀을 드립니다.
지난 4년간 Voeasy 서비스를 운영해 왔지만, Voeasy로 여타의 수익을 만들지 못해서 결국 오랜 고민끝에 서비스를 종료하기로 하였습니다.

지난 4년간 보내주신 Voeasy 회원 여러분의 관심과 기대에 끝까지 부응하지 못하게 되어 거듭 죄송한 말씀 드립니다.

Voeasy 서비스는 종료하지만, 새롭게 시작하는 여행지에서 꼭 봐야하는 곳을 찍어 주는 “Arrangy – Where to Go?” (https://arrangy.com) 를 통해서 다시 만나뵙게 되었으면 좋겠습니다.

여행의 시작 – Arrangy.com | Mauritius, Africa

저희가 새로운 서비스에 집중하기 위해서 Voeasy 서비스를 종료하는 것을 다시 한 번 너그럽게 이해 부탁드리겠습니다.

기타 추가적인 문의 사항은 help@hubrite.com 으로 보내주시면 친절히 말씀 드리도록 하겠습니다.

그 동안 Voeasy에 보내주신 관심과 성원에 다시 한번 감사의 말씀을 드립니다.

고맙습니다.

허브라이트 드림


  • 4/15 서비스 종료 이후에는 https://voeasy.com 으로 voeasy 서비스에 접속하실 수 없습니다.
  • [인터넷익스플로러 8/9] 보안콘텐츠만 표시됩니다. 어떻게 해야하나요?” 는 여기서 보실 수 있습니다.

 

 

We need 128GB or more RAM!

in English (Google Translate)
97년에 Pentium Pro에128MB 램을 설치하고 좋아했었는데(풀뱅!), 이제는 128GB 이상의 메모리가 필요한 작업이 생겼습니다. 간단할 줄 알았는데, 128GB 이상을 서버에 꽂으려니 이것저것 고려해야 하는 사항이 있어서 정리 해봅니다.

 

모든 CPU가 가능한게 아니야!

Intel CPU를 기준으로 64GB 를 초과하는 RAM을 설치하려면 Xeon 클래스 이상이 필요합니다.

일반 데스크탑 CPU의 최고 사양인 Intel Core i7-4960 Extreme Edition 을 사용한다고 해도, 최대 설치할 수 있는 램은 64GB 로 제한됩니다. (i7-4960 Extreme 이 일반 사양은 아니지…)

 

128GB 이상의 램은 데스크탑 CPU로는 만들 수 없는 사양이라서 서버 CPU 인 Xeon 클래스에서 찾아봐야 하는데,  이 경우에는 Xeon E5 이상에서 가능합니다. 제온 E3는 최신이지만 32GB 가 최대 구성이고, 제온 E5 이전 세대 (예, 웨스트미어 288GB까지 가능)도 가능한데 단종된 CPU여서 추가 구매가 아니라면 굳이 선택할 이유가 없다고 판답됩니다.

 

Intel Xeon E5-2620 v2

제온 E5 v2 혹은 제온 E5 프로세서들은 최대 768GB 메모리를 설치할 수 있기때문에 모두 후보 제품이고, 제품도 다양합니다. 그렇지만 어쩔 수 없이 비용을 고려하면 이야기가 달라집니다.(전문용어로 가성비~~~) 현재 시장에서 구할 수 있는 가장 고성능 CPU인 E5-2697 v2(12 cores, 2.7Ghz, Apple Mac Pro 2013도 사용하는 CPU)를 지금 당장 구매한다면 300만원대에서 구매할 수 있습니다. 가장 대중적인 CPU 중의 하나인 E5-2620 v2 (6 cores, 2.1Ghz)는 50만원 전후로 구매할 수 있습니다. 그런데 2697v2 와 2620 v2가 가격 차이는 6배가 넘지만, 성능 차이는 약 2배 정도입니다.

 

128GB 이상이 필요한 작업이 CPU 성능에 좌우되는 작업이 아니라 Memory 크기에 더 영향을 받는 작업이기 때문에 당장 빠른 CPU보다는 적당한 CPU를 선택했습니다.  보다 저렴한 E5-2603 v2 혹은 E5-2609 v2 (4 Core) 를 선택할 수도 있지만, 해당 CPU는 dual socket으로 구성하더라도 E5-2620 v2 보다 10% 정도만 빠르기 때문에 가격 효율성은 더 떨어질 것으로 판단합니다. (굳이 말하자면, E5-2620 v2 = E5-2609 v2 x 2)

그래서 우리는 Xeon E5-2620 v2 로 128GB 서버를 만들기로 했습니다.

 

128GB = 8GB RDIMM x 16 or 16GB RDIMM x 8?

메모리 구동에 필요한 CPU와 딸려오는 CPU 칩셋(C2xx, C6xx)에 선택의 이슈가 있는 것 처럼, 가장 중요한 메모리에도 선택의 이슈가 있습니다. non-ECC DRAM, ECC unbuffered DRAM은 128GB 이상을 구성하기가 어렵기 때문에 제외하고, 남아 있는 것은 ECC registered DRAM(RDIMM) 용량의 선택입니다.

시장에서 쉽게 구할 수 있는 RDIMM은 8GB, 16GB 이고, 8GB가 다소 저렴합니다.

8GB RDIMM x 16 = 128GB (CPU 2개 필요)

16GB RDIMM x 8 = 128GB  (CPU 1개 필요)

그래서 8GB RDIMM 으로 128GB를 만들면 될 것 같지만, 이렇게 구성하려면 CPU를 하나 더 추가해야 합니다. 즉, E5-2620 v2 를 하나 더 사서 듀얼소켓으로 구성해야만 16개를 모두 동작시킬 수 있습니다. 듀얼 소켓 구성의 경우, 하나의 CPU(칩셋)가 램 슬롯의 절반을 컨트롤하기 때문에 16개 정도되면 CPU 하나로는 구성이 불가능하게 됩니다.

그리고 대개의 듀얼 소켓 서버 메인 보드들이 최대 16~24개 정도의 램슬롯이 있는데, 추후에 램을 128GB 이상으로 늘린다면 8G RDIMM 구성으로는 램 슬롯이 없어서 기존의 램을 걷어내고 새로운 램을 설치해야 하기때문에 투자 보호가 어렵게 됩니다.

8GB RDIMM과 16GB RDIMM의 가격차이가 크지 않고, CPU 추가비용, 추후 투자보호를 생각한다면 16GB RDIMM 이 합리적인 선택이라 판단합니다.

 

128GB = 32GB LRDIMM x 4?

메인 보드의 램 슬롯이 16개라면, 16 GB RDIMM x 16 = 256GB 가 단일 서버로 구성할 수 있는 최대 메모리 용량이 됩니다. 이것보다 램이 더 필요하다면 32GB LRDIMM x 16 = 512 GB 구성을 해야 합니다.

현재 램 슬롯 한개에 32GB 이상 설치하기 위해서는 LRDIMM 밖에 없기 때문에 선택의 여지가 없지만, 문제는 가격입니다. 32GB LRDIMM 을 시장에서 구하려면 USD 500 ~ 600 부근에서 형성되는데 16GB RDIMM의 거의 2배 정도 되는 가격(단위 용량 기준)이 됩니다.

지금 당장 단일 서버에서 256GB  이상이 필요하다면 32GB LRDIMM으로 돈을 신경쓰지말고 구성해야 겠지만, 그렇지 않다면 추후 확장 가능성보다는 가격 대비 성능비가 우선이라서 16GB RDIMM이  타당합니다.

 

1U 랙마운트 – Air Flow!

이번에 서버를 만들 때, 서버의 샤시는 기존에 사용하던 1U 샤시를 그대로 사용하기로 했습니다. 그래서 1U 에 Rack mount 구성이 가능해야 하는데, 1U로 구성할 때에는 공기 흐름을 고려해야 합니다. CPU를 2개까지 설치가능한 보드의 경우 Extended ATX form factor를 갖는 경우가 많은데, 이 경우 2개의 CPU를 1열로 레이아웃하는 보드의 경우 1U 샤시에 설치하기 곤란합니다. 그림 참조

1U 서버는 CPU 위에 팬이 돌아가는 쿨러를 사용할 수 없고 CPU에 heat sink를 붙이고 샤시의 팬에서 공기를 불어넣어서 CPU를 식혀야 합니다. 참조된 사진에서는 아래에서 위로 공기가 흐르게 되는데 이 경우 위쪽에 있는 2번째 CPU는 앞쪽 1번 CPU와 램에 막혀서 공기 흐름이 원할하지 않을 수 있습니다. 그림참조 그래서 그림처럼 CPU를 엇갈린 형태로 구성해야 해서 최종적으로 선택한 메인보드는 Supermicro X9DRD-7LN4F  입니다.

 

뭐가 이렇게 복잡해! 그냥 AWS를 사용하면 안되나요?

128GB RAM 이상을 설치할 수 있는 서버를 직접 만들려니 신경 쓸 일이 많네요. 이것 저것 신경쓰지 않으려면 Amazon AWS, Microsoft Azure, Google Compute Engine 등의 Cloud Iass 를 사용하면 됩니다. AWS EC2 r3.4xlarge 122GB RAM 을 1달 사용하면 USD 1,000 이상이 됩니다.  아마존 서버를 1Q 돌리는 비용보다 서버를 직접 만드는 비용이 저렴하기 때문에 위와 같이 직접 만드는 방법을 선택했습니다.

일반적으로 쇼핑할 때와 같습니다. 돈보다 시간이 더 싸면 시간과 노력을 들여서 저렴한 제품을 찾는 것이고, 돈이 시간보다 싸다면 이것 저것 생각하지 말고 만들어진 비싼 제품을 사면 됩니다.

 

그래서 이 서버 어디에 쓸 건데?

우리의 시간이 돈보다 더 비싸지려면 본업인 인터넷 서비스를 잘 만들어야 겠지요.

메가 서비스를 꿈꾸는 웹서비스를 만들고 있습니다. 공장(IDC)에 기계(서버) 들여놨으니, 곧 제품 나올 겁니다. 🙂

그게 무엇인지는 하나씩 풀어 가겠습니다~

 

 


Fez

모로코 Fez 여행 계획,  Arrangy

왜 Arrangy 를 사용해야 할까요?  ‘여행의 시작 – Arrangy’ 가 궁금하지 않으세요? (클릭)


OpenSSL, Heartbleeding… !

Heartbleed : OpenSSL 1.0.1 ~ 1.0.1f

피 흘려서 수술해야 하는 OpenSSL 버전: 1.0.1 ~ 1.0.1f

업데이트 필요한 OS : CentOS 6.5, Ubuntu 12.04.4 LTS (OpenSSL 1.0.1 이상 사용, 반드시!)

업데이트 필요없는 OS: CentOS 6.4 이하, XenServer (OpenSSL 1.0.0 이하 사용)

업데이트 방법:

 

뭔데 난리야?

한국은 조용한데, 미국에서는 CVE-2014-0160가 CNN에도 등장하네요. 무심코 본 CNN에서 이야기하고, AWS 에서도 ‘너네 시스템 패치 안했던데, 업데이트 해라!’라고 메일와서 알았습니다.

영향 받는 OpenSSL을 사용하는 시스템에서는 버그로 인해서 메모리를 읽을 수 있고, 메모리의 인증서 비밀키, 사용자 암호 등등등을 가로챌 수 있고 어떤 흔적도 남지 않는다네요! (The Heart Bleed Bug) 문제는 버그를 2년 동안이나 모르고 있다가 최근에 발견되었고 그 사이 어떤 탈취가 있었는지 모르기 때문에 인터넷 서비스 업체는 인증서 재발급하고, 사용자는 암호 변경해야 합니다.

CVE-2014-0160 이 2013.12.3 에 보고 되었고 OpenSSL Patch는 2014.4.6 에 이루어 졌는데, OpenSSL 같은 대형 프로젝트도 이런 버그를 수정하는데 4개월이 소요된다는 점, 완전히 기술적인 문제인데 개인 정보 유출 때문에 미국 사회에서도 난리인가? 라는 생각이 드네요.

그리고 Microsoft Azure 에서도 CentOS로 영향받는 서버가 있는데, Azure에서는 아직 아무 소리가 없네요. 🙂

서버들 빨리 패치 합시다! (함께 만드는 투자기준 – Voeasy, 우린 다 했음~)

 

 


Fez

모로코 Fez 여행 계획,  Arrangy

왜 Arrangy 를 사용해야 할까요?  ‘여행의 시작 – Arrangy’ 가 궁금하지 않으세요? (클릭)


Google PageSpeed 사용하기 (with Nginx SSL Load Balancer & SPDY)

in English (Google Translate)
함께 만드는 투자 기준 – Voeasy 개편을 하면서 다시 Google PageSpeed Module를 적용했습니다. 2013년 여름에 PageSpeed를 도입한 적이 있지만, 당시에는 SSL 환경에서는 페이지스피드를 사용하는 것이 효과적이지 않았습니다. SSL을 사용할 경우 HTML 본문의 최적화만 가능하고 css/js/jpg 등의 기타 리소스들은 전혀 최적화 되지 않았습니다.(0.6.X 버전, 2013) 다시 설명하겠지만, fetching 이 http로만 가능하고 MapOriginDomain 을 지원하지 않아서 SSL 환경에서는 사용할 수 없었습니다.

아래는 Nginx를 사용하는 SSL 환경에서 Google PageSpeed Module을 적용하는 방법에 대한 설명입니다.

왜 Google PageSpeed Module이 필요한가요?

구글 페이지스피드 모듈은 이미지/CSS/JS/HTML을 변경(rewriting)하는 다양한 필터를 사용해서 적은 수고로 웹 페이지를 최적화해서 서비스 로딩 시간을 조금이나마 더 줄여 줍니다. 기본적으로 서비스 환경, 필터 조합 등에 따라서 성능 향상은 정도는 달라지지만, 페이지에 따라서 1초 이상 로딩이 빨라지는 결과를 얻었습니다.(Voeasy 내부 측정)

SSL에서도 PageSpeed를 적용할 수 있나요?

2013년 여름에는 SSL에서 PageSpeed를 적용하는 것이 어려웠지만, 시간이 흘러서 이제는 SSL에서도 적용할 수 있는 방법이 추가되었습니다.

PageSpeed를 적용하면 신경쓰지 않아도 많은 부분을 최적화해주지만, SSL에서 적용하기 위해서는 신경써야 하는 작업이 있습니다.

But by default, PageSpeed will only rewrite non-HTML resources which are served via http.

그런데 Nginx를 사용한다면, 위의 구글의 설명은 아래와 같은 의미가 됩니다.

But, PageSpeed will only rewrite non-HTML resource which are served via http or accessed file directly if you use Nginx.

PageSpeed가 HTML/CSS/js/JPG/PNG 등의 리소스를 최적화하기 위해서는 최적화 해야하는 리소스에 접근하는 것이 필요합니다. (당연합니다!) 그런데 PageSpeed가 리소스를 최적화하는 작업이 ‘on the fly’ 로만 되는 것은 아닙니다. 웹서버가 서비스하는 과정에서 바로바로(on the fly) rewriting이 가능하다면 별도의 작업이 필요없지만, PageSpeed를 동작시키기 위해서는 해당 리소스에 PageSpeed가 접근할 수 있어야 합니다.(fetching)

PageSpeed는 http fetching 이외에 file fetching, https(or SPDY) fetching 도 지원합니다. 그러나 https(or SPDY) fetching은 Apache에서만 가능합니다.(Fetch HTTPS resources directly as of PageSpeed 1.7.30.1, Apache-Only)

Nginx에서 Google PageSpeed를 사용하려면 리소스를 HTTP 혹은 직접 파일로 접근할 수 있어야만 합니다.
(Apache 에서만 https fectching 을 지원합니다.)

Reverse Proxy에서도 PageSpeed를 사용할 수 있나요?

Voeasy는 다음과 같은 구성으로 서비스 됩니다.

Client Browser <- HTTPS -> Nginx SSL Reverse Proxy (+ PageSpeed) <- HTTP -> Nginx Web Server

제일 앞에 있는 Nginx SSL Reverse Proxy가 모든 SSL 처리를 하고, 후방 웹서버에는 http 만 전달합니다. 그리고 http를 전달하면서 각각의 웹서버에게 적절하게 부하를 분산하는 구조입니다. (like AWS ELB) Reverse Proxy를 사용하기 때문에 여러대의 웹서버를 사용하고 있어도 SSL 인증서는 reverse proxy에만 설치해도 되고, 비교적 간단하게 웹서버의 로드 밸런싱도 가능합니다. 그리고 Reverse Proxy가 설치된 서버만 상대적으로 성능이 좋다면(예, AES-NI), 후방 웹서버는 http 만 처리하기 때문에 비교적 평범한 장비를 사용해도 쉽게 전체 서비스에 SSL을 적용할 수 있습니다.

그렇지만, 위의 구성으로는 PageSpeed가 설치되는 reverse proxy는 웹서버와 다른 곳에 위치하기 때문에 직접 파일로는 웹서버의 리소스를 접근할 수 없습니다. Proxy 본래의 임무에 충실하게 http 만을 사용해서 웹서버에 리소스를 요청하고 접근할 수 있습니다.

Nginx Reverse Proxy에서 Google PageSpeed를 사용하려면 리소스를 HTTP로 접근할 수 있어야만 합니다.
(Reverse Proxy 가 웹서버와 다른 서버에 존재한다면, file fetching 이 가능하지 않습니다.)

네?? 우리는 SSL만 사용하는데요?

함께 만드는 투자 기준 – Voeasy 는 http를 사용하지 않고 https만을 사용해서 서비스합니다. 사용자가 http 로 url을 요청해도 https로 강제로 변경되기 때문에 눈치채기 어려울 수도 있지만, 모든 페이지를 SSL로만 서비스합니다.

그렇지만, Nginx Reverse Proxy 환경에서 PageSpeed를 사용하기 위해서는 반드시 http 를 열어야 합니다. 그리고 구글의 설명처럼, https 를 적용했던 원래의 목적을 잃지 않기 위해서 안전한 방법으로 http를 열어야 합니다.

As discussed above, using http to fetch https resources URLs should only be used when communication between the front-end and back-end servers is secure as otherwise the benefits of using https in the first place are lost.

그래서 어떻게 설정하란 말인가요?

다음과 같이, 외부에서는 접근할 수 없고 내부에서만 접근할 수 있는 http reverse proxy를 proxy 서버 내부 ip(192.168.24.101:38000, Reverse Proxy for PageSpeed)에 추가로 설정했습니다.

Browser <- HTTPS -> SSL Reverse Proxy(+PageSpeed) <---------           HTTP            --------> Web Server
                                                  <- HTTP -> Rev. Proxy for PageSpeed <- HTTP -> Web Server

PageSpeed 의 http resource fetch는 nginx.conf에 다음과 같이 설정합니다.

...
pagespeed Domain https://voeasy.com;
pagespeed MapOriginDomain http://192.168.24.101:38000 https://voeasy.com;
...

설명

참 간단하죠? 🙂
PageSpeed의 기본 설정 방법을 Google 보다 잘 설명할 자신도 없고, 그리고 Nginx 가 동작하고 있다면 어렵지 않게 설정할 수 있기 때문에 여타의 다른 설명은 생략합니다. (죄송합니다;;)
Voeasy팀의 시행착오가 조금이라도 도움이 되셨으면 좋겠고, 그래도 ‘잘 모르겠는데?’ 혹은 기타 문의 사항이 있으면 코멘트 남겨 주시면 성심 성의껏 말씀 드리겠습니다.

One more thing…, SPDY!

개편하면서 Nginx를 손 볼때, SPDY 도 적용하였습니다. voeasy는 이미 모든 페이지를 SSL로 서비스하기 때문에 SPDY를 적용하는 것 놀라울 정도로 간단합니다. SSL을 기본으로 사용하는 서비스들은 다음의 Nginx 설정 추가만으로 SPDY 추가가 가능합니다.

server {
    listen 443 ssl spdy;
    ...
}

물론 Nginx build 할 때, --with-http_spdy_module는 추가해 주셔야 합니다.

./configure --with-http_spdy_module \
...

개발에 지친 눈, 잠시 쉬어 가세요!

Segovia Station, Spain | Arrangy.com

 


Fez

모로코 Fez 여행 계획,  Arrangy

왜 Arrangy 를 사용해야 할까요?  ‘여행의 시작 – Arrangy’ 가 궁금하지 않으세요? (클릭)


PyPy 사용하기 (with uWSGI on CentOS 6)

in English (Google Translate)

왜 PyPy가 필요한가요?

최근에 voeasy을 업데이트를 했습니다. 나만의 투자 기준을 만들고, 투자 기준을 통과한 종목을 보여주는 허들이 개편의 핵심인데, 각각의 주식 종목을 설정된 투자 기준에 맞추어 허들을 계산하는 것은 시간이 많이 필요한 작업입니다.

대한민국 상장 종목에 현재 최대 13개까지 적용할 수 있는 허들 기준을 모두 적용하면, 전체 연산작업은 단순 계산해도 2,000 (종목) x 13 (허들) = 26,000 (허들 계산)을 수행해만 합니다. 사용자가 기준을 정하면 즉시 결과를 볼 수 있도록 만들려고 했지만, 현재는 번개같은 처리를 하지 못하기 때문에 분단위로 작업을 기다려야 합니다. 허들 계산을 번개같이 처리하는 것은 또다른 도전과제입니다.

도전과제는 생각과 시간이 필요하기 때문에, 도전을 하기 전에 생각없이 허들 계산을 빠르게 할 수 있는 PyPy를 적용을 고려하기로 하였습니다.1 허들 계산이 DB bound 작업이지만 개발환경2에서 테스트해보면 코드 변경 없이도 약 13% 정도 빨라졌기 때문에 조금이라도 더 빨라지기 위해서 한번 해볼만한 작업이라 간단히 생각했습니다.

CentOS! uWSGI!! libpypy-c.so!!!

개발환경2인 MacOS에서 PyPy를 설치하는 것은 너무나 쉬웠습니다. OSX에서는 별다른 어려움 없이 brew install을 사용하면 PyPy를 동작할 수 있는 환경으로 만들 수 있습니다. 너무도 쉬웠었기 때문에 실제 운영환경인 CentOS에서도 쉽게 설치할 수 있을 것이라고 착각하고 개발을 진행했습니다.

그러나 CentOS는 달랐습니다!

실제 운영환경에 적용할 시점이 되어 CentOS에 PyPy를 설치하려니 다음과 같은 장애물이 있었습니다.

  1. yum install pypy (X) – 이게 가능했으면 이 글을 쓰지도 않았겠지?
  2. PyPy Official Binary for CentOS (X)3Ubuntu만 지원하는 PyPy Binary Download
  3. uWSGI에서 PyPy를 사용하려면 shared library build 된 PyPy 필요. – Unfortunately you still need to build/translate libpypy-c by yourself

쉽게 하려면, portable linux binary3를 사용하고 libpypyb-c.so는 uWSGI에서 제공하는 20130524 버전을 사용하는 방법도 가능할 수 있습니다. 그러나 Python 2.74을 build 할 때 binary 불일치로 segmantation fault의 경험이 있기 때문에, 구성이 확실하지 않은 binary를 사용하는 것에 대한 부담이 있습니다. 위의 조합으로 가능한지는 한번 테스트를 해봐야 겠습니다.

결국, uWSGI 에서 필요한 libpypy-c.so 때문에 PyPy를 source build 하기로 했습니다. pypy.org 에서 PyPy official binary for CentOS 를 언젠가 지원한다고 해도, shared library build를 포함하지 않으면 uWSGI를 사용하기 위해서는 직접 빌드할 수 밖에 없을 것입니다.

PyPy 빌드하기

빌드 전 준비 – 5GB memory 필요 (4Core, CPU 비례 증가)

PyPy 소스 빌드는 정말 오래 걸립니다.5

CentOS 66에서 PyPy를 소스 빌드하기 위해서는 가장 중요한 것은 메모리입니다. pypy building from source 에서 설명하고 있지만, 64bit 환경에서 필요한 ram은 4GB 이상입니다. 그런데 메모리는 option5을 주지 않으면 CPU core에 비례해서 늘어납니다.7 cc 프로세스 하나가 1GB이상을 사용하기 때문에 core가 많은 환경이라면 램이 충분하다고 생각하더라도 옵션으로 job 갯수를 조정해야 합니다. 4Core 환경에서 5GB ram/1 GB swap으로 compilation 가능합니다.

빌드 전 준비 – PyPy pre-built binary

cd /tmp
wget https://bitbucket.org/squeaky/portable-pypy/downloads/pypy-2.2.1-linux_x86_64-portable.tar.bz2
tar xf pypy-2.2.1-linux_x86_64-portable.tar.bz2
mv pypy-2.2.1-linux_x64-portable pypy
  • pypy 빌드할 때, CentOS에 기본적으로 설치된 python 2.6을 사용하면 시간이 더 오래 걸리기 때문에, portable linux binary3 을 /tmp/pypy에 설치

빌드 전 준비 – library dependency

yum install gcc make pkgconfig libffi-devel expat-devel
zlib-devel bzip2-devel sqlite-devel ncurses-devel openssl-devel
  • CentOS 6.5 minimal install 상태6

빌드

wget https://bitbucket.org/pypy/pypy/downloads/pypy-2.2.1-src.tar.bz2
tar xf pypy-2.2.1-src.tar.bz2
cd pypy-2.2.1-src/pypy/goal
/tmp/pypy/bin/pypy ../../rpython/bin/rpython --translation-verbose
--shared --gcrootfinder=shadowstack
--opt=jit targetpypystandalone
  • /tmp/pypy 에 설치된 pre-built된 pypy를 사용하여 빌드
  • --shared: pypy shared library인 libpypy-c.so를 빌드하기 위한 옵션
  • --gcrootfinder=shadowstack: asmgcc대신 shadowstack을 사용한다는 옵션
  • --shared --gcrootfinder=shadowstack: uWSGI를 사용하기 위한 옵션. uWSGI를 사용하지 않을 것이라면 제외
  • --opt=jit targetpypystandalone: JIT를 사용한다는 일반적인 PyPy build 옵션
  • --translation-verbose: 이 옵션을 빼면 Enjoy Mandelbrot 🙂를 할 수 있을 텐데, 혹시 빌드 실패가 일어날 경우, 어떤 문제인지 확인하려면 필요

엔터치면 느긋하게 1시간 가량 놀다오면 됩니다~ 다만 중간에 에러가 나면 처음부터 다시 시작해야 하는데, 그러면 또 놀 수 있습니다. 🙂 (처음부터 시작하지말고, 실패한 이후부터 빌드하는 옵션은 없나요?)

패키징

mkdir -p /opt/pypy/bin
mv ./libpypy-c.so /opt/pypy/bin
ln -s /opt/pypy/bin/libpypy-c.so /usr/lib64/libpypy-c.so
cd ../../pypy/tool/release
../../goal/pypy-c package.py --without-tk ../../.. pypy-libpypy-c_centos65_x64
cp -r /tmp/usesession-release-2.2.x-2/build/ /opt/pypy
  • mv ./libpypy-c.so /opt/pypy/bin: 성공적으로 빌드된다면 pypy/goal/libpypy-c.so만들어지는데, libpypy-c.so를 /opt/pypy/bin으로 이동. libpypy-c.so는 패키지에 포함되지 않기때문에 따로 설치해야 함.
  • ln -s /opt/pypy/bin/libpypy-c.so /usr/lib64/libpypy-c.so: 뒤에서 직접 shared 빌드한 pypy-c가 동작하는지 확인하기 위해서 packaging을 빌드한 pypy로 진행하는데, shared build기 때문에 libpypy-c.so의 위치를 지정 (--shared 로 빌드한 경우에만 해당)
  • ../../goal/pypy-c package.py --without-tk: 직접 빌드한 pypy-c로 패키징을 하는데, tcl/tk 관련 사항이 필요없기 때문에 제외
  • /tmp/usesession-release-2.2.x-2/build/: 패키징이 완료되면, 어떤 곳에 패키징되어 있는지 알려주는데, x는 실행시마다 다름
  • /opt/pypy 에 PyPy를 설치한다고 가정

위의 과정을 거치면 패키징된 PyPy JIT를 빌드할 수 있을 것입니다.
필요한 dependency library가 많고, 개별 설치 환경마다 필요한 옵션이 다를 수 있는데 빌드옵션을 살펴보면서 진행하면 빌드할 수 있을 것입니다. (말은 쉽지. 아 힘들다…)

uWSGI 에서 PyPy 사용하기

uWSGI-PyPy plugin 빌드

cd /tmp
wget http://projects.unbit.it/downloads/uwsgi-2.0.tar.gz
tar xf uwsgi-2.0.tar.gz
cd uwsi-2.0
/opt/pypy/bin/pypy uwsgiconfig.py --build pypy
  • --build pypy: 일반적으로 --build만 사용해서 uWSGI를 인스톨 했는데, 이렇게하면 dependency가 많아서 직접 빌드하기 어려움 (CentOS 6.5 minimal install). 그래서 --build pypy 옵션으로 PyPy만 사용할 수 있는 uWSGI 빌드. uwsgi-2.0/buildconf를 참고

변경되는 .ini option

uWSGI PyPy-plugin 을 적용하면 uWSGI setup 을 변경해야 하는 사항이 있는데, voeasy는 다음 사항을 변경해야 했습니다. pypy-plugin option 참고
pypy-home: 빌드한 pypy binary 위치를 지정. 위의 설치 과정이라면 /opt/pypy가 되고, virtualenv를 적용한 경우, 해당 env 환경을 지정.
pypy-wsgi-file: 기존에는 module=django.core.handlers.wsgi:WSGIHandler()을 사용해서 wsgi.py를 별도로 만들지 않고 로딩했는데, pypy-plugin 에서는 기존의 module 로딩방법으로는 로딩되지 못함. pypy-wsgimodule과 동일한 역할이라 생각되는데, 단순히 변경만 해서는 동작하지 않음. (더 시도해보면 방법이 있을 수도 있는데, pypy-wsgi-file로 동작해서 더 이상 진행하지 않음)
The server will report “dynamic mode” on startup even if the app has been successfully loaded. uWSGI에서도 언급한 버그인데, app이 성공적으로 로딩되어도 로그에는 dynamic mode로 표시되니 log만 보고 겁먹지 말고 실제로 동작하는지 직접 확인해 볼 것. (제대로 동작하고 있었는데, 로그에서 dynamic mode로 표시되어 한참을 더 삽질…)

Tip: PyPy 적용 후 관찰해야 하는 사항

위의 과정을 거치면 CentOS/PyPy/uWSGI 에서 서비스를 동작시킬 수 있는데, PyPy compatibility 이슈는 계속 신경써서 살펴봐야 합니다. voeasy가 사용중인 라이브러리 중에서 아래의 널리 사용되는 것들은 역시나 별 문제 없었습니다.

django
mysql-python
python-memcached
Pillow

다만 lxml-3.3.0을 적용하면 segmentation fault8 가 발생했는데, uWSGI가 crash 할 때마다, 계속 reloading 해서 로그를 살펴보지 않으면 문제가 있는지 조차 파악할 수 없었습니다. 이런 점이 실제 운영 환경에서 uWSGI의 강점인데, 이와 같은 이유로 C를 사용하는 라이브러리의 python wrapper 를 사용하는 경우, PyPy 적용 후 segmentation fault 등의 변경으로 인한 문제가 발생하는지 계속 지켜볼 필요가 있습니다.

PyPy를 적용하면서 시행착오를 많이 했는데, 실제 PyPy 적용을 하고 싶은 분들에게 저희의 시행착오가 작은 도움이 되었으면 합니다.


PyPy 어디에 사용하냐고요?
여행의 시작 – Arrangy.com 에 사용합니다!
개발에 지친 몸 잠시 들러 쉬어가세요;;;

여행의 시작 – Arrangy.com | Santorini, Greece

 

 


Fez

모로코 Fez 여행 계획,  Arrangy

왜 Arrangy 를 사용해야 할까요?  ‘여행의 시작 – Arrangy’ 가 궁금하지 않으세요? (클릭)


  1. voeasy는 CentOS/Nginx/uWSGI/Python/MySQl 환경에서 운영되고 있습니다. 
  2. Intel i7/OSX Mavericks/PyPy 2.2.1 (BREW install) 
  3. PyPy binrary for portable linux는 있는데, shared library build 가 아님 (libpypy-c.so 없음) 
  4. CentOS, yum install Python 2.6 only. 
  5. i7-980x 3.33Ghz 4Core 사용/6GB Ram/SSD RAID 10, 60분 소요 – 동일 환경에서 램만 3GB로 조정하여 시도한 경우, 4시간이 지나도 완료되지 못함. 
  6. CentOS 5 에서도 시도했지만, dependecy를 맞추기 어려워서 결국 포기. yum 으로 설치되지 않는 라이브러리가 있고, dependency도 소스 빌드 시도하였으나 처리해야하는 것이 많음. 그래서 CentOS 5를 사용하던 일부 서버는 CentOS 6로 동반 업그레이드. 
  7. 5GB/4core 환경에서 몇 번의 시도 후, 더 빠르게 작업하기 위해서 8GB RAM의 6core 환경에서 build를 시도했습니다. 8GB/6core 환경에서 빌드과정에서 로그없이 crash 를 몇 번 경험하고 터득한 것은 후반 컴파일 과정에서 CPU core에 비례하여 cc를 돌리는데 이 과정에서 램/스왑을 모두 사용하면 크래쉬합니다. 
  8. lxml-3.3.1pre에서도 해결되지 않았는데, 글을 쓸 때 살펴보니 ‘lxml-3.3.1’이 2월12일 버전으로 변경. 해당 사항 변경되었는지는 테스트 필요. 

허브라이트 2호 서버 활동개시!

드디어 지난 일요일(2013년 7월 28일) 허브라이트 제 2호 서버가 본격적으로 활동을 개시했습니다.

이제는 이 화려한 서버 스펙에 걸맞는 서비스 운영만 남았네요.

분발해야겠어요!!!   ^_____^;;;

지난 몇 주 간은 서버 작업하느라 고생 좀 한 허브라이트 크루들입니다.

다들 수고 많았습니다! 🙂

사진 1

  • 나란히 위 아래로 놓여있는 허브라이트 서버 1호와 2호

사진

  • 서버 구동 확인 중인 허브라이트 크루들, 좌측부터 JM, BJ

사진 3

  • 서버 작업 끝난 후 들른 파주 프리미엄 아울렛 쟈니 로켓에서 저녁 회식

사진 5

  • 서버 작업 끝난 후 들른 파주 프리미엄 아울렛 쟈니 로켓에서 저녁 회식

쟈니 로켓의 케첩 서비스는 언제 봐도 기분이 참 좋아져요.

미국 쟈니 로켓 매장에선 직원들이 춤도 추고 그러길래, 여기서는 춤 안 춰주시냐고 여쭤보니 쑥스럽게 ‘여긴 안 춰요.’ 이러는 직원분. ^^

강남 쪽 2곳 정도의 매장에선 춤을 춘다는 추가 정보를 알려주시던데, 한 번 시간 되면 가서 보고 싶다는 생각이 들더군요.

서버 작업도 끝났으니 이제는 잠시 늦춰졌던 Voeasy 서비스 개편 작업에 박차를 가해야겠습니다.

조만간 [함께 만드는 투자 리포트, Voeasy] 개편 버전을 볼 수 있을 거에요!

많이 기대해 주세요~ 🙂

 

 


Fez

모로코 Fez 여행 계획,  Arrangy

왜 Arrangy 를 사용해야 할까요?  ‘여행의 시작 – Arrangy’ 가 궁금하지 않으세요? (클릭)


[마드리드 여행기] – 허브라이트

2013년 4월 25일.

산티아고 순례길을 마치고 마드리드로 돌아온 허브라이트 크루들은 이날은 마드리드 시내 구경을 하기로 했습니다.

한국에서 싸온 밥으로 든든하게 아점을 먹은 뒤, 배낭 없이 가벼운 몸으로 기분 좋게 시내로 나섰습니다.

8~10kg, 10~13kg 되는 배낭을 메고 다니다가 간단하게 들고 나가니 이렇게 가벼울 수가 없습니다.

일단은 알베르게에서 가까운 지하철 역(바리오 델 필라 역, Barrio del Pilar)으로 가서 아토차(Atocha) 역으로 갈 생각입니다.

아토차 역에서부터 발걸음 닿는대로 자유롭게 마드리드를 구경할 생각입니다.

IMG 2557

  • 사진: 2013. 4. 25 / 바리오 델 필라 역(Barrio Del Pilar)

지하철 타는 건 어렵지 않습니다.

자동 판매기에서 표 살 때 가려는 역 이름 선택하고, 티켓 수 선택하고 결제하면 끝입니다.

가고자 하는 역의 노선 종착역과 일치하는 방향으로 가서 지하철을 타면 됩니다.

문은 수동 개폐식이니까 내리는 사람이 없으면 직접 문을 열고 타면 되고, 내릴 때도 마찬가지로 직접 문을 열고 내리면 됩니다.

갈아타는 것도 마찬가지의 방법으로 갈아타면 됩니다.(우리 나라 지하철과 크게 다르지 않아요.)

아토차역 iframe

  • 사진: 2013. 4. 25 / 아토차 역(Atocha)

아토차 역에 도착했습니다.

여기가 예전에 폭탄 테러가 났던 곳이라고 알고 있는데, 그런 상처나 흔적 하나 없이 웅장하게 서 있었습니다.

아토차역내부 iframe

  • 사진: 2013. 4. 25 / 아토차 역 내부(Atocha)

아토차 역 내부입니다.

거대한 나무들이 마치 식물원 같은 느낌을 연상시켜 줍니다.

농업부 iframe

  • 사진: 2013. 4. 25 / 농업부 건물(Ministerio de Agricultura)

아토차 역 맞은 편에는 이렇게 멋진 농업부 건물이 있습니다.

IMG 1860

  • 사진: 2013. 4. 25 / 국립 소피아 왕비 예술 센터(Museo Nacional Centro de Arte Reina Sofia)

마드리드를 며칠에 걸쳐 둘러봤다면 반드시 가봤을 국립 소피와 왕비 예술 센터입니다.

2013년 4월 27일부터 9월 2일까지 Dali 특별전을 한다는데 봤더라면 재미있었을 것 같습니다.

여기에는 현대 미술관이 소장하고 있던 컬렉션을 바탕으로 스페인의 근대 및 현대 미술을 중심으로 전시하고 있고, 1만점 이상의 작품이 있는 곳으로 알고 있습니다.

피카소, 달리, 미로와 같은 유명 화가의 작품 뿐만이 아니라 루이스 브뉘엘, 라몬 카사스 등의 작품도 있습니다.

2층에 피카소의 ‘게르니카’라고 피카소가 나치 독일 공군이 게르니카를 무차별 폭격한 것에 격분하여 그린 대작이 있는데, 그걸 못 본게 아쉽기도 합니다.

IMG 2581

  • 사진: 2013. 4. 25 / 마드리드 시티투어 2층 버스

IMG 2583

  • 사진: 2013. 4. 25 / 마드리드 시티투어 2층 버스, 2층 내부

이번에는 2층 시티투어 버스를 타고 마드리드를 한 번 돌아보기로 합니다.

저희는 마드리드 시티투어 버스 2일 자유권을 구입했습니다.(1인당 25유로, 1일권보다 가격적으로 상대적으로 저렴)

이 2일 자유권이면 마드리드 시내를 투어하는 시티투어 버스를 2일 동안 자유롭게 이용할 수 있습니다.

마드리드 시티투어 버스는 2가지의 서로 다른 코스를 도는 버스로 구성되어 있습니다.

(저희는 하루만 알차게 이용했고, 다음 날엔 톨레도엘 가느라 못썼습니다. TT)

이 자유이용권을 끊고 버스를 타면 가이드 브로셔와 이어폰을 줍니다.

이어폰을 앞 좌석 등부분에 꽂고 언어 선택(영어, 한국어 없음)을 하면 특정한 spot에 다가갈 때마다 방송이 나옵니다.

좌석마다 잘 들리는 곳이 있고 잘 안 들리는 곳도 있고 하니 잘 안 들리면 자리를 바꿔 앉으면 됩니다.

어디서든 내리고 탈 수 있으며, 몇 번이고 횟수 제한없이 탈 수 있으니 승차권을 잘 간수해야 하고, 버스 탈 때 승차권을 버스 안의 안내원에게 보여주면 됩니다.

IMG 1864

  • 사진: 2013. 4. 25 / 프라도 미술관(Museo del Prado)

프라도 미술관(Museo del Prado) 역시 못 가봤네요.

버스 위에서 본 것으로 만족해야만 했는데, 엘 그레코, 고야, 벨라스케스와 같은 스페인 거장들의 작품을 못 봐서 아쉽네요.

아무래도 마드리드 역시 다시 한 번 방문해서 프라도, 소피아 예술 센터 등에 다시 가봐야 할 것 같습니다. 🙂

IMG 1867

  • 사진: 2013. 4. 25 / 알칼라 문(Puerta de Alcala)

버스에서 내려서 본 알칼라 문(Puerta de Alcala)입니다.

독립 광장(Plaza de la Independencia)에 있는 이 문은 시의 입구를 관리하기 위해 세워진 것입니다.

로마의 개선문처럼 만들라는 카를로스 3세의 지시에 의해 이탈리아 건축가 사바티니가 설계했답니다.

스페인 독립 전쟁(1808~1814)의 승리를 기념하여 이 일대가 독립 광장으로 명명되었다는군요.

레티로공원 iframe

  • 사진: 2013. 4. 25 / 레티로 공원(Jardines del Buen Retiro)

알칼라 문 맞은 편엔 레티로 공원(Jardines del Buen Retiro)이라는 큰 공원이 있습니다.

날씨 좋은 날, 여유롭게 산책하고 쉴 수 있는 근사한 공원이었습니다.

양쪽에 도열해 있는 석상들도 근사하고, 잘 꾸며진 정원과 호수, 분수까지 아름답지 않은 것이 없었습니다.

원래는 스페인의 황금 시대였던 펠리페 2세가 만든 부엔레티로 별궁의 정원이었다는군요.

나폴레옹 전쟁 때 거의 파괴된 곳으로, 왕실의 여름 별장이었던 곳이지만 지금은 일반인에게 공개되어 누구나 누릴 수 있게 되었습니다.

IMG 1888

  • 사진: 2013. 4. 25 / 레티로 공원(Jardines del Buen Retiro), 호수와 알폰소 12세 기마상

레티로 공원 re

  • 사진: 2013. 4. 25 / 레티로 공원(Jardines del Buen Retiro), 좌측부터 BJ, JM, AJ

레티로 공원을 나와 다시 2층 시티투어 버스에 올라탔습니다.

IMG 1900

  • 사진: 2013. 4. 25 / 메트로폴리스 건물(Metropolis)

산 프란시스코 엘 그란데 성당 iframe

  • 사진: 2013. 4. 25 / 산 프란시스코 엘 그란데 성당(Real Basilica de San Francisco el Grande)

버스타고 지나가면서 본 산 프란시스코 엘 그란데 성당(Real Basilica de San Francisco el Grande)의 모습입니다.

13세기 초, 아시시의 산 프란시스코가 순례 중에 세웠던 성당 자리에 1784년 프란시스코 카베사스 수도사의 설계로 지금과 같은 원형 성당의 건축되었다는군요.

전형적인 신고전주의 양식으로, 지름 33m의 거대한 원형 천장은 이탈리아의 건축가 사바티니의 작품이라고 합니다.

여기에 고야의 ‘산 베르나르디노 데 시에나’라는 작품이 있다던데, 역시 버스타고 지나치느라 못 봤네요.

IMG 1990

  • 사진: 2013. 4. 25 / 시청사(Ayuntamiento)

1617년 후안 고메스 데 모라의 설계로 건축된 시청사(Ayuntamiento) 건물입니다.

붉은 벽돌이 사용된 외관은 17세기 합스부르크 시대 건축의 특징이랍니다.

IMG 1949

  • 사진: 2013. 4. 25 / 솔 광장의 카를로스 3세 기마상(Puerta del Sol)

솔 광장(Puerta del Sol)은 ‘태양의 문’이라는 뜻이라는군요.

스페인 각지로 이어지는 9개의 도로가 시작되는 곳이랍니다.

IMG 1972

  • 사진: 2013. 4. 25 / 마요르 광장(Plaza Mayor)

마요르 광장(Plaza Mayor)은 122m * 94m 크기의 광장으로 4층짜리 건물들이 주위를 둘러싸고 있고, 한 가운데는 펠리페 3세의 기마상이 있습니다.

IMG 1978

  • 사진: 2013. 4. 25 / 마요르 광장(Plaza Mayor), 펠리페 3세 기마상

IMG 1985

  • 사진: 2013. 4. 25 / 산 미구엘 시장(Mercado de San Miguel)

마요르 광장에서 조금만 밖으로 나오면 산 미구엘 시장(Mercado de San Miguel)이 나옵니다.

우리 나라로 치면, ‘먹자 골목’ 쯤 되려나요?

다만, 그 ‘먹자 골목’이 노상에 위치해 있는 게 아닌 마트 같은 건물 안에 입주해 있는 형태입니다.

과일, 해산물, 맥주, 와인, 주스, 온갖 과자나 디저트, 빵, 분식 등 다양한 요기거리가 있습니다.

저희들은 여기서 만두 같이 생긴 것과 맥주를 주문해서 먹었는데, 기대했던 만두 맛이 아니었습니다.

만두피가 ‘빵’ 같았고 그 만두피가 두꺼워서 만두 느낌보다는 ‘빵’ 느낌이 났습니다.

겉이 아주 두꺼운 ‘고로케’ 같다고 설명하면 맞으려나요.

고민고민하다가 고른 메뉴였는데, 맛이 기대이하여서 실망스러웠지만 그래도 색다른 경험이어서 좋았습니다.

산미구엘시장 iframe

  • 사진: 2013. 4. 25 / 산 미구엘 시장 내부(Mercado de San Miguel)

IMG 1998

  • 사진: 2013. 4. 25 / 왕궁(Palacio Real)

산 미구엘 시장을 나와서 왕궁(Palacio Real)으로 갔습니다.

마침 저희가 갔을 때는 오후 6시였는데 6시 이후부터는 입장료가 무료였습니다.

이 왕궁은 1764년에 완공된 건물로, 고전주의 바로크 양식의 건물입니다.

원래는 1083년 카톨릭 교도가 마드리드를 탈환할 때까지 이슬람교도의 성채가 있던 자리라고 하는군요.

현재 스페인 국왕 일가가 사는 곳은 아니고 2800개나 되는 방이 있는데 그 중 50개의 방을 볼 수 있습니다.

프랑스의 베르사유 궁전의 ‘거울의 방’을 모방해서 만든 ‘옥좌의 방’을 비롯해 화려한 왕실 생활을 엿볼 수 있습니다.

IMG 1999

  • 사진: 2013. 4. 25 / 왕궁(Palacio Real)

알무데나 대성당 1

  • 사진: 2013. 4. 25 / 알무데나 대성당(Catedral Nuestra Senora de la Almudena)

왕궁을 나와서 조금만 걸으면 알무데나 대성당(Catedral Nuestra Senora de la Almudena)이 자리잡고 있습니다.

미완성인 상태로 100년을 있다가 1993년에 준공된 건물이라고 합니다.

711년 이슬람 교도가 이베리아 반도로 침입하여 마드리드가 점령당했을 때, 성모상이 파괴되는 것이 두려워 성벽에 숨겨 두었는데 그것이 370년 후에 기적적으로 발견되어서 그 자리에 성당을 만들게 되었다고 합니다.

‘알무데나’라는 이름은 성모상을 숨겨뒀던 성벽이 아라비아어로 ‘알무다이나’라고 하는데, 거기서 유래한 이름이라고 합니다.

‘대성당’ 이라는 이름에 걸맞게 규모도 크고 매우 웅장했습니다.

알무데나 대성당 2

  • 사진: 2013. 4. 25 / 알무데나 대성당(Catedral Nuestra Senora de la Almudena)

알무데나 대성당 3

  • 사진: 2013. 4. 25 / 알무데나 대성당(Catedral Nuestra Senora de la Almudena)

경건한 마음으로 알무데나 대성당을 관람한 뒤, 저녁 식사를 하러 한식당(고려정)으로 갔습니다.

한식당을 찾는데 제법 헤매긴 했지만, 결과적으로는 매우 만족스러운 식사였습니다.

그 동안 그리웠던 한국 음식, 김치찌개, 낙지철판구이, 김치삼겹구이를 먹었습니다.

‘이게 얼마만에 보는 한국 요리냐~’ 이러면서 배가 터질 정도로 포식했습니다.

소주 한 병이 만원도 넘는 금액이고, 대체적으로 음식들이 한국 대비 가격이 비싸긴 했지만, 유럽에서 좀처럼 맛보기 힘든 입에 맞는 음식이라 만족스러웠습니다.

저녁식사 iframe

  • 사진: 2013. 4. 25 / 어느 한식당에서의 저녁 식사, 소주, 두부, 김치찌개, 낙지철판구이

늦은 저녁 식사를 하고 알베르게로 돌아가 다음 날을 준비합니다.

내일은 로마의 성채 도시, ‘톨레도’에 갈 예정입니다.

중세의 분위기가 물씬 풍기는 ‘톨레도’는 어떤 모습으로 우릴 반길지 기대가 되는군요.

To be continued…

[톨레도 여행기] – 허브라이트 보러가기

 

 


Fez

모로코 Fez 여행 계획,  Arrangy

왜 Arrangy 를 사용해야 할까요?  ‘여행의 시작 – Arrangy’ 가 궁금하지 않으세요? (클릭)