System Compleat.

'Techs'에 해당되는 글 113건

  1. httpcfg.exe, forfiles.exe
  2. Crossover Web Service.
  3. repcached on Ubuntu 9.0.4-server
  4. Extend your L2 Cache with Memcached! 4
  5. Microsoft Cloud, Azure Service

httpcfg.exe, forfiles.exe

Techs
( 정윤진, bluebird_dba@naver.com )


TOOL

A tool




Windows 기반의 서비스를 운용하면서 발생되는 일반적인 이슈중에 하나는,  IIS를 구동하면
여러개의 IP를 Aliasing 해서 사용하더라도 절대 80포트를 다른 어플리케이션의 용도로 바인딩 할 수 없다. 
이는, IIS 동작 특성상 커널의 http.sys 에서 OS에 할당된 모든 IP를 IIS의 80포트로 바인딩 해 버리기 때문인데 이러한 경우를 대비하여 Support Tool 에서 httpcfg.exe 라는 툴을 제공한다.

뭐 그딴거를 tool 로 지정해? 그냥 유닉스처럼 .cfg 파일에 IP를 지정하면 그걸로 되는거 아니야?
윈도우 못쓰겠구만 하시는 분들은 그냥 계속 유닉스/리눅스 쓰시면 되겠다.

1.1.1.1:80 에는 IIS 를,  2.2.2.2:80 에는 apache 를 바인딩 하고 싶다면,
필수적으로 사용해 주어야 한다. 
일단 IIS 가 기동된 상태에서 한번 실행 해 본다.


httpcfg.exe query iplisten -i

결과 값이 어떻게 나타나는지 잘 살펴 본 후에,
이제 IIS 에서 Binding 하여 사용할 IP 를 지정해 준다.

httpcfg.exe set iplisten -i 1.1.1.1

리턴값 0 과 함께 잘 세팅 되었다는 메세지가 나오면, 확인한다.

httpcfg.exe query iplisten -i

만약 잘못 넣었거나, 지우고 싶다면

httpcfg.exe delete iplisten -i  1.1.1.1

설정이 끝나면 IIS 를 재시작 한다.

net stop http /y  && net start w3svc

이거 몰라서 한참 헤멘적이 있다.  윈도우에서 제공하는 기본 적인 툴 중에는, 유닉스에서 상식으로 동작하는 것들이 윈도우에서는 수동 설정해 주어야 하는 것들이 많으므로 잘 살펴 보도록 한다. 

httpcfg.exe 에 대해서는 다음의 링크를 참조 하도록 한다.
http://technet.microsoft.com/en-us/library/cc787508%28WS.10%29.aspx


비슷한 맥락에서,  리눅스나 유닉스에서 다음과 같은 커맨드를 많이들 사용하실 것이다.

find . -ctime +3  -exec rm -f {}+

이 커맨드는 윈도우에서 다음과 같이 사용 되어 질 수 있다.

forfiles /P C:\Windows\system32\Logfiles\ /M *.log /D -3 /S /C "cmd /c del @file"

아주 기본적인 것들이지만, 이게 안되서 서비스 중지한 경험은 누구나 가지고 있을 것이다.
조금만 더 응용한다면 압축이나 특정 위치로의 Moving 등이 가능하지만.

forfiles 참조
http://technet.microsoft.com/en-us/library/cc753551%28WS.10%29.aspx


굳이 perl 이나 python 을 사용하지 않고도 수행 할 수 있는 시스템 툴들은 알아두는 것이 재산이다.  아주 긴급할때에 요긴하게 사용 할 수 있는 때가 있다.

일례를 들면,  요런거?
root@test$ pwd
/var/log/httpd/

root@test$ du -sh
access.log    4G

root@test$ > access.log

난 참 멍청해서 이런 커맨드 자주 잊어버린다.

( bluebird_dba@naver.com )




Crossover Web Service.

Techs
( 정윤진, bluebird_dba@naver.com )

사용자 삽입 이미지

* 이미지 출처 : http://www.atbshop.co.uk/images/neversummer/ns_swift_iso.jpg


윈도우와  xNix 계열의 서비스를 구현 하면서, 가장 쉬운 것 같으면서 어려운 부분이
웹 서버 간 파일 공유 문제이다.
유닉스 계열의 서버에서는, 보안 및 마운트 관련 이슈만 몇가지 주의하면 큰 어려움 없이
NFS 와 같은 툴을 사용하여 얼마든지 많은 ( 충분한 규모의 ) 웹 서버군을 구성 할 수 있다.

하지만 윈도우에서는 (내가 지식이 짧은 탓도 있지만)  DFS 나 윈도우 2003 부터 지원하기 시작하는 NFS의 클라이언트를 사용하여 동일한 파일들의 서비스 처리가 가능하지만, 통상 윈도우 서버에서는 각 서버별로 소스를 서버 로컬에 위치시키고 사용하는 것이 일반적이다.

여기에는 여러가지 이유가 있는데, ASP.NET 이나 .NET Framwork 의 동작 구조 상 이렇게 처리하게 되는 경우 상대적으로 I/O에 소비되는 비용이 많아지게 되면서, IIS에서 보다 좋은 퍼포먼스를 위해 각 서버 로컬에 소스를 두는 형태로 운용 되어지곤 한다.

세련된 네트웍 장치인 L4 또는 Persistance 세팅을 한 LVS 등이 있다면 역시 별 문제가 되지 않지만, 윈도우 서버만으로 세션 공유를 처리하려면 문제가 되는 부분이 경험적으로 많았다.
( IIS7은 아직 잘 모르니까 패스 )  기본적으로 윈도우에서 지원하는 세션 공유의 타입은 두가지 정도 였던걸로 기억하는데, 하나는 DB를 사용( -ㅁ-;; ) 하는 방법 (out-process) 과 다른 하나는 ASP.NET 의 프로세스 레벨에서의 공유 (in-process) 의 두가지 지만, 이 중에도 in-process 공유 방법의 경우 그 이름에서 알 수 있듯이 프로세스 내부간 공유기 때문에 당연히 서버간 공유가 되지 않는다.

유닉스 계열의 서버의 경우, 최악의 경우지만 세션을 파일로 저장하도록 하고 세션이 끊기면 삭제하며 이 파일이 저장되는 디렉토리를 적절한 퍼미션으로 보호하고 NFS 내부 서버간 공유를 걸어주면 해결 할 수도 있다.  하지만 조금 더 좋은 방법을 사용하자면, repcached 와 같은 툴을 사용하여 세션을 아예 복제 가능한 메모리에 박아버려 서버간 공유 처리가 가능 해 질 수도 있다.  (물론 윈도우에서도 닷넷을 사용하여 가능하다. )

물론, NFS가 만능은 아니다.  NFS는 locking 에 대한 문제가 발생하곤 하는데, 이는 통상 동일한 파일에 대해 서로 다른 서버가 write 요청을 할 때 발생한다.  동일한 파일로의 read 요청은 얼마든지 많아도 ( 물론 충분히 바쁜 서버들의 규모에서 ) 웹 서버쪽에서는 한번만 읽으면 되고, read 의 경우 어느 서버가 언제 가져가도 큰 문제가 되지 않지만 서비스를 동일한 파일에 서로 다른 서버가 쓰기위해 접근하도록 설계 했다면, NFS 안쓰는게 낫다.
하지만 조금만 돌려서 이야기 하면, 결국 동일한 파일을 쓰지 않게만 설계 하면 NFS 서버의 Net I/O 및  Disk I/O 가 허용하는 범위 내에서는 아주 좋은 동작 성능을 확보 할 수 있겠다.
( 웹 서버가 웹 클라이언트 만큼 많지 않은 이상에야 -ㅁ-;; )


이 쉽게 보면 아주 기본적일것 같은 기능인 서버간 파일의 공유 라는 이슈는, 나에게 윈도우에서 큰 어려움으로 직면 했었다.  세상 어디의 어느 문서를 참조해도, IIS 6 이전에 이러한 문제들을 명쾌하게 해결 해 주는 건 없었다.

이러한 부분은 플랫폼에 따른 서비스 구성의 난점으로서, 최근에 윈도우 스토리지 서버를 사용하여 윈도우에서 NFS를 구성해 주고, 이를 리눅스 서버의 계정과 매핑하여 줌으로서 윈도우-리눅스 간 크로스 플랫폼 파일 공유도 지원 해 주긴 하지만,  이는 윈도우 스토리지 - 이기종 플랫폼 의 지원 형태이지  유닉스 또는 일반 스토리지 서버 - 윈도우 서버 간의 공유에 대한 해법은 아니다.

혹자는 물론 삼바나 CIFS 를 말 할 수도 있겠지만, 이 IIS 라는 녀석은 나름 심오해서 웹 사이트의 가상 디렉토리가 응용 프로그램의 속성이 해제 되어야만 원활한 공유가 가능하겠다.
또한, AD 없이 각각 Standalone 의 웹 서버간에 이 동일한 디렉토리를 접근하도록 해 주려면, IIS가 설치되면 기본적으로 설정되는 계정들에 대한 서버 로그인 정보를 메타데이터 수정이라는 다소 복잡한 방법을 통해 ( 물론 MS Resource Kit 에 제공된다 ) 적용 해 주어야 한다.


이러한 다소 복잡 다단한 설정들에도 불구하고, IIS 에서의 가상 디렉토리 공유는 모든 웹서버에서 동일한 디렉토리로의 ( 다른 서버의 ) File Write 를 제공 함으로서 비교적 NFS와 유사한 기능 구현이 가능하다.  하지만 역시, 웹 소스는 서버별 로컬에 주는게 좋다.  ( 향후 Deploy 에서 다시 설명 )  이러한 기능을 구현 할 수 있다는 것 만으로도 웬지 뿌듯함을 느꼈다면 유닉스 엔지니어들이 비웃을까.


DFS 도 어느정도 답이 될 수 있을것 같기는 하다.  다만, 내가 아직 DFS의 기능에 대해 확실히 꿰고 있는 것은 아니니까 이거는 나중에 따로 공부가 완료되면 정리를 하도록 하고.

NTFS에 대해서 더 잘 알았다면 뭔가 멋지게 쓸 수 있을 테지만, 나와 같은 통상의 유닉스 계열에서 시작한 사람들은 왜 윈도우에서는 Hadoop 과 같은 FS를 지원 하지 않는 거지 하는 불만만 날이 갈 수록 심해지게 된다.  그러지 말자.  안되는건 안되고 되는건 되니까.

멋진 Reverse-Proxy 와 함께라면,  IIS 서버를 일종의 WAS 서버로 사용하는것도 가능해 진다.  예전부터 꿈꿔 왔던 거지만,  기존의 웹 서버와 고전적인 WAS 만을 생각한다면 절대 불가능한 이야기지만, uri 별 분리 구성을 취한다면 ( 예전에 썼던거 다시 우려먹는 느낌 ) 완전 멋진  크로스플랫폼 서비스가 가능해 지는 거다.

lighttpd + memcached + eAccelerator 의 심플한 이미지 또는 light weight 웹 서버와 함께, 백단의 .NET 기반의 훌륭한 ( 비지니스 로직의 구현 및 일반적인 백엔드 레벨에서의 jsp 와는 다른, php 보다 복잡 해 질 수 있는) WAS 가 동작 해 준다면, ( DB의 선택 폭은 잘 나가는 모든 DBMS가 되는 것이다! )   서비스 처리량 및 응답성에서 타의 추종을 불허하는
완죵 멋진 구성이 가능 해 질 것이다.


물론 발생하는 로직의 구조상 유닉스 계열의 웹 서버간 특정 부분의 구현에 대해서는, 글쎄 고민하기 나름이랄까.


뭔가 또 이상한 글을 써 버렸지만, 골자는 그거다.
하나의 플랫폼만 고집 할 수는 없다.  필요하다면, 또는 돈으로 떡칠해도 감당 안되는 규모로 가게 되면, 대응 할 수 있는 유연성을 높이기 위한 플랫폼 선택은 시작에 불과하다는 것.

맨날 뜬구름만 잡는 것 같아서, 담번에는 윈도 서버들이 가지고 있는 쓸만한 툴들에 대해서 사례를 통해 좀 구체적으로 적어보아야 겠다.



( 정윤진, bluebird_dba@naver.com )

repcached on Ubuntu 9.0.4-server

Techs
( 정윤진, yjjeong@rsupport.com )

사용자 삽입 이미지

이름에서 쉽게 알 수 있듯이, memcached 를 복제하여 안정성을 높여주는 도구이다.
최근 이런 저런 이유에서 memcached 에 대해서 관심이 좀 생겨서 알아보다가 의외로 쉽게 얻어 걸린 괜찮은 툴인듯 해서 정리해 본다.

용도는, memcached 의 multi-master 로서의 사용이다.
항상 그렇지만, 뭔가 단일화된 자원을 분산하여 처리할때는 여러가지의 경우를 생각해야 하는데
Multi-Master 구조가 Multi-Slave 구조보다 훨씬 힘든 이유는 각각의 분산된 자원이 서로 동일한 정보를 가지고 있어야 하고, 이 정보는 장애 극복이 가능하여야 하며 가능한한 최단 시간내의 sync 를 통해 동기화 되어야 하는 등, 비교적 그 구현이 쉽지 않아 제대로 지원하는 툴 또는 3rd-party 의 무언가를 찾기 쉽지 않은게 사실이다.

일단, 이 repcached 의 성능도 어떨지는 잘 모르겠지만, memcached 의 동작 자체가 DBMS 의 그것과 같지 않게 매우 단순하여 구조적 취약점이 크게 발생할 일이 없으므로, 로컬에서는 일단 잘 동작할 것이라 믿어 의심치 않는다. ( 웹 서버간 세션 공유를 위한 memcached 의 사용 등 )

다만, 일종의 글로벌 서비스를 계획함에 따라 일부 웹 어플리케이션에서 가공되고, 사용되어지는 캐싱 가능한 모든 데이터에 대한 캐쉬 클라우드를 memcached 로 구현함에 있어서,
repcached 가 글로벌한 환경에서 multi-master 로서 동작 할 수 있는가 하는 테스트는 나름 의미가 있지 않을까 한다.

뭐, 남의 프로젝트 페이지에서 이런 설명까지 긁어오는건 별로 좋아라 하지 않지만,
특별히 장애 대응 부분과 replication 동작 부분만 이미지를 가져다 붙이도록 한다.

사용자 삽입 이미지

memcached replication


보면, 클라이언트는 각 memcached 서버에서 적절히 데이터를 받아온다.
적절히 분산해서 받아 오다가, 장애가 발생하면 요렇게 된다.

사용자 삽입 이미지

memcached Crash!


장애가 발생하면, 살아있는 캐쉬 서버로 부터만 데이터를 가져온다.

요러다가 장애난 서버가 되살아 나면~
사용자 삽입 이미지

recover memcached data set


클라이언트로의 접근을 막는 동시에, 동기화를 수행한다.
아... 똑똑하기도 하여라.

각설하고 직접 설치하고 써보는게 장땡이다.


일단 뭐 설치 방법은 간단하다.
최신 버전의 memcached 를 받고, repcached 의 patch 파일을 받은 후에 패치 적용하고
컴파일 하면 된다.

뭐, 실제 구현을 위한 잡다한건 잘 안쓰는 편이지만, 나도 점점 멍청해져 가고 있다는게 최근 확실해 졌으므로 큰맘 먹고 적어본다.

서버는 제목과 같이 우분투 9.0.4 서버 버전을 사용하였다.

# 다운로드
wget http://memcached.googlecode.com/files/memcached-1.2.8.tar.gz
wget http://jaist.dl.sourceforge.net/sourceforge/repcached/repcached-2.2-1.2.8.patch.gz

# 패치가 적용된 다운로드
wget http://jaist.dl.sourceforge.net/sourceforge/repcached/memcached-1.2.8-repcached-2.2.tar.gz

# 뭐 굳이 쓸 필요는 없지만, 문제 추적의 과정을 설명하자는 취지에서,
# 다운 받은 패치를 memcached 의 압축을 풀어놓은 디렉토리로 이동시키고,  적용한다.

gzip -d repcached-2.2-1.2.8.patch.gz | patch -p1

./configure --prefix=/opt/memcached --enable-replication

# i686 어쩌고 찡얼댄다.  알고보면 build-essential 을 설치해 달라는 말이다.

apt-get install build-essential

# 설치가 완료되면, 걸렸던 부분이 넘어간다.
# 잘 넘어가다가,
# libevent 라이브러리가 설치되어있지 않다면, 설치하고 있다면 path 를 알려달라고 또 징징댄다. 귀찮은 녀석.

wget http://www.monkey.org/~provos/libevent-1.4.11-stable.tar.gz

# ./configure , make, make install 한다.

# 다시 memcached 를 configure 한다.
# 잘 된다.

make && make install

# 설치를 완료하고, memcached 를 굴려보면,

# 또 징징댄다. 또 libevent 관련 메세지다. 
# libevent* 를 찾아봤더니, /usr/lib 에 있단다.
# ldd 해보면, libevent 부분만 빵꾸다.
# 훗, ln -s 해준다.  Cent 64bit 짬밥.

ln -s /usr/lib/libevent-1.3e.so.1.0.3 /lib/libevent-1.4.so.2

# 자 이제 사용하면 된다.

물론 잘 동작 하는지는 좀더 봐야겠지만, Amazon EC2 의 EU-west 에서 한국의 서버와 동기화 해 테스트를 해 볼 예정.

많은 Unix 또는 Linux 의 바이너리들 처럼, memcached는 간단, 심플하게 원하는 기능을 수행하는데 군더더기 없이 충실하다.  그 안정성 역시 전세계의 많은  웹서버에 들러붙어서 동작하고 있으므로, 충분히 검증 되었다 싶고.

단순 웹서버의 url contents 캐슁만을 위해 memcached 를 사용하는건, 웬지 아깝고
작게는 세션부터 MySQL 의 result caching 의 엄한 영역 까지 사용 될 수 있으니 만큼,
클라이언트 라이브러리를 조금만 연구 하면 많은 소득을 얻을 수 있지 않나 싶다.

사용 방법은, 뭐 많이 나와있으니깐. 
아, 여기 나와있는 모든 이지미는 repcached 의 wiki 에서 퍼온것임을 강조한다.

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

Extend your L2 Cache with Memcached!

Techs
( 정윤진, yjjeong@rsupport.com )

사용자 삽입 이미지A Waffle Image from Waffle Grid Project.



데이트도 없고 약속도 없는 토요일 네티즌 수사대로서 이런 저런 떡밥을 덥썩 무는 것보다 오늘은 맘먹고 구글링이나 해 봐야지 하는 생각에 이런저런 그리드 관련 문서들을 보다가, 희한한 프로젝트가 있어서 소개한다.

본 프로젝트는, 궁극적으로 컴퓨팅 성능을 memcached 를 사용해 프로세서에 들러붙어있는 L2 Cache를 뻥튀기 함으로서 확장하려는 야심찬, 어떻게 보면 약간의 또라이적( 좋은 의미다 ) 발상으로 시작된 '놀라운 그 무언가' 이다.

요지는, LRU에 무언가의 데이터가 쓰여지기 전에 이 데이터를 memcached 에 먼저 쓰고, 읽기 작업을 할떄도 먼저 읽어서 구현하자는 내용이다.

실제 전체 운영체제에 반영하기에는 매우 힘든 부분이 없지 않으며, 이를 위해서는 리눅스 커널을 만져야 할 필요가 있지만 중요한건 커스터마이징 가능한 어떠한 오픈소스라도 이런 형태의 확장이 가능하지 않겠나 하는것이다.

이 와플그리드 프로젝트는 어떤 DBA의 저녁식사에서 시작되었으며, 개발자가 와플을 좋아해서, 또 본인이 그려놓은 다이어그램이 와플같아서 그렇게 이름 지었다 한다. DBA가 시작한 프로젝트라 그런지 MySQL 의 InnoDB 성능 확장을 프로젝트에서 구현하고 있다.
MySQL 에 InnoDB를 사용하는 분들은 봐 두시면 매우 많은 도움이 되지 않을까 싶다.

이후의 내용은  http://www.bigdbahead.com/?p=73 의 내용을 번역한 것 임을 미리 알려둔다. 번역이 맘에 들지 않더라도 알아서 보시면 되겠고, 못알아 보겠으면 링크의 원문을 보셔도 좋다.

이 프로젝트가 어떤 부분에서는 참 기가막힌 성능을 나타낼 것이고, 다른 부분에 반영하기에 위험이 따르는 것도 사실이므로, 아직은 테스트 정도로 또는 다른 어떤 솔루션을 구현할때의 아이디어 정도로 쓰면 되겠다.  사실 뭐 memcached 의 확장적 사용영역에서 엄청 크게 벗어난 것은 아니니까.



--- Memcached as a L2 Cache for InnoDB - The Waffle Grid Project  ---

번역 ( 정윤진, yjjeong@rsupport.com )

몇 달전 힘든 일과 뒤에 목요일 Yves와의  저녁식사에서 어떻게 하면 성능과 확장성을 증가 시킬 수 있을까 하는 논의를 했다. 이 논의에서 나는 그에게 InnoDB를 위한 L2캐쉬로서 memcached 를 사용하면 어떻겠냐는 아이디어를 주었는데, 이 간단한 아이디어는, 뭔가가 LRU 를 참조 할 때마다 memcached 에 데이터셋을 박는 것에서 출발한다.

버퍼에 저장되지 않은 데이터를 디스크에서 읽기전에, memcached 에서 긁어오는 것.

해서 Yves는 메일로 질문질을 하더니, 기어이 골때리게도 실제 0.1 버전의 동작 가능한 프로그램을 보내왔다.  아이디어의 실제 프로젝트화 된 시발점이었달까.

해서 우리는 Waffle Gird 프로젝트라 명명하기로 했다.  왜? 아래의 다이어그램을 보면 와플같이 생기지 않았는가.  게다가 난 와플을 좋아하니까 ( 주: 니가 좋아하니까 그렇게 보이는게 아니냐? ) 또 디게 맛나니까.  뭐 암튼 몇일 밤낮을 홀라당 샌 뒤에, 테스트 가능한 패치코드를 생성 해 냈고, 벤치마크를 시작했다.  동작 했을까?  당근.  게다가 꽤 괜찮았다.  아래의 벤치마크 결과를 참조하시라.

기본적으로, 이 패치를 Central Node 에 적용하고 몇몇의 서버를 remote L cache 로 롤 분배 한다.  예로, 128G 의 메모리를 가진 MySQL 서버 한대와, 각각 64GB 를 가진 4대의 remote 서버를 둔다.  이러한 구성은 전체 256G의 L2 Cache 를 가지게 되겠다.  ( 주: 번역을 끝낸뒤에 재검토 해 보니, 이 글에서 말하는 L2 캐쉬는 Remote 노드의 메모리 총합을 말하는 듯 하다. -ㅁ-;  L1 캐쉬를 128G 라 하는 것을 보니, Central Node 의 Localhost 의 memcached 영역의 128G 로 잡은 모양인가 보다.  쳇, 내가 구현해서 테스트해봐야지. )

뭐 당연하지만, 보다 빠른 네트워크를 구성하는 경우에  더 빠른 응답을 기대 할 수 있다. 디스크에서 데이터를 가져오는 것보다 훨씬 더-

그림을 까보면 ( 와플같이 생겼다는 ) 이렇다.

사용자 삽입 이미지Example Waffle Grid Setup

왜 이런 짓거리를 할까? 몇몇 이유는 다음과 같다.

- 우리는 맨날 어떤 클라이언트가 낮은 디스크 성능으로 인해 충분한 역할을 해 내지 못하는지 확인하여야 하며, 이애대한 해결책은 보다 빠른 디스크를 넣거나 또는 메모리를 추가하는 것이다. 하지만 자금상의 문제에 봉착한다거나  서버 한대에 박을 수 있는 메모리 공간이 쫑난다면 어떻게 할 것인가?

- 32비트 제약으로 인한 성능향상. ( 64bit 로의 마이그레이션을 위한 법률 서비스를 제공하는 회사가 있기도 하다 )

- DBRD를 Active/Passive 로 구현하는 경우, Passive 서버에 뭔가 더 역할을 주고 싶어서.

- 친구들이 말하곤 한다. "난 10대의 와플 그리드로 5TB의 메모리 굴린다~"

전술 하였듯이, 동작한다.  근데 니들은 물어보겠지?  "쫌 만들었냐? 이거 퍼지는거 아냐?"
벤치마크 결과를 보자.

사용자 삽입 이미지Waffle Bench

로컬 메모리 ( Central Node 의 ) 를 추가한다면, 더 좋은 성능을 기대 할 수 있다. 하지만 로컬에 더 많은 메모리를 추가 할 수 없는 경우, remote 의 buffer pool 이 답이다. 아무것도 하지 않은 것 보다, Remote Buffer 를 추가 했을 때 38%의 성능 향상이 발생했다. 또 계속 최적화 할 것이므로, 성능은 더 나아질 것으로 기대한다.

해서, Waffle Grid 가 세계의 기아에 대한 솔루션이 될 수 있을 것인가?  아니다. 

모든 어플리케이션에 적용 가능 할까?  역시 아니다.  

우리는 데이터를 network 에서 읽어오기 때문에, cache miss 나  데이터를 리모트에 넣는데 시간이 걸린다. 근데 만약, 디스크에서 반드시 읽어와야만 하는 데이터가 있는경우, 이에 따른 오버헤드가 매우 커지게 된다.  로컬 캐쉬에서 번저 찾아야 하고 ( OS 로직상 ), 이후 로컬의 memcached 에서 찾고, 다시 remote 의 memcached 에서 찾은 이후에 비로소 디스크를 보게 된다.  이러한 불가결한 로직은 우리가 모르는 동작에 의해 더 늘어 날 수도 있다.  역설하면,  이런 마법같은 상황 ( read-ahead, data accessed from disk sequentially, 아마 빠르겠지 ) 도 발생하지만, 우리는 아직 구현하지 못하고 있다. 

추가적인 지연시간은, full table scan 또는 대량의 데이터가 바로 즉시 읽어져야 하는 경우에 발생할 수도 있다.  사실 결과는 일부 커다란 양의 데이터셋에 대한 쿼리의 실행 속도가 5~6배 느려지기도 했다.  이러한 부분의 개선을 위해 계속 작업하고 있으며, 원하는 데이터를 보다 빨리 찾아내기 위해 cache miss 를 줄이는 알고리즘을 개선중이다. 뭐 말하자면, 아직은 개발중인 실험적 코드임에 분명하고, 무결점으로 동작하지 않는다. 이 부분을 피력하려 노력중이며, 이러한 노력이 약속의 반증이라 생각한다. ( 이러지 말자)

SSD는 어떠냐고 물어보시겠지들.  SSD로 맛나는 와플을 더 빠르게 할 수 없냐?  대답은, NO 다.  뭐 사실은 나도 SSD로 이런 저런 테스트 해 보았지만, 기대만큼 커다란 향상은 없다. 일반 디스크에 비하면, 약 20% 정도의 향상은 있었다.

더 알고 싶으면, wiki 를 참조하셍. ( http://www.wafflegrid.com/wiki/index.php?title=Main_Page )
---


30분 동안 날림 번역했더니 담배를 피워야 겠다는 사실을 잊고 있었다.  아! 억울해 ㅠ

어떠한 버전의 MySQL 에서 동작하는지는 wiki 에서 찾아보기도 하고 그러시라.
나만 뺑이 칠 순 없잖아.

아, 라이센스는 GNU로 보인다.


Microsoft Cloud, Azure Service

Techs
( 정윤진, yjjeong@rsupport.com )

사용자 삽입 이미지



드디어 라고 말하기엔 내가 M$에서 뭔가를 기다린 적은 없지만, 이거는 필이 째끔 오는 물건으로 보여서 또 한번 끄작거린다.

M$의 용어에 익숙치 않아서 문제긴 하지만, Web Role 과 Worker Role 을 지원 한다고 한다.

.NET 의 C#과 VB를 지원하고 Storage 는 ADO.NET 을 사용한다 하지만, 참 내가 뭘 어떻게 설명 할 수 있는 부분들은 아닌 듯 싶으니 이런 부분은 MS의 Evangelist분의 링크를 아래에서 참고 하시도록 하는게 좋겠다.

문제는 서비스에로의 반영인데, 아래의 링크에서 소개하듯 기존의 각 회사가 가지고 있는 인프라에서 Azure에 클라우드로 구현된 .NET Application 을 사용 하게 될 수 있거나, 또는 그반대의 경우가 가능하다면 이 Azure 가 가지고 있는 M$의 플랫폼의 실제 네트워크적 접근성에 따라 글로벌 서비스가 매우 여유로워 질 수 있다고 생각한다.

시스템 적인 입장에서 쉽게 생각 해 보면, 글로벌 서비스를 구현하게 될 때 지역에 따른 접근성에 따라 네임 서버를 조작하여 응답한다거나 리다이렉션과 같이 내부적으로 복잡한 로직을 사용 할 것이 아니라,  클라우드의 잇점 중 하나인 접근성이 좋은 Azure 로 모든 요청을 받도록 하고, 받은 클라이언트 요청, 이를 테면 브라우저 타입이라던가 언어, 연동 가능한지 모르겠지만 클라이언트 IP에 따라  지역에서 운용 되고 있는 서버로의 Redirection 또는, 대부분의 로직을 클라우드에서 처리, 주요한 데이터만 회사의 DB 또는 서버에 저장 가능 한 형태가 될 수도 있을 듯 하다. 

아니면 모든 서비스를 클라우드에서 구현해 버리는 방법도 있겠지만, 이는 여러가지 이유로 쉽지는 않을 것 같다.

어쨌든 잘 모르기 때문에, 그 실질적 용도는 좀 더 파헤쳐 봐야겠지만 웬지 서비스 효용성이 매우 높은 또 하나의 자원이라는 생각이 들고,  일반 ASP 서비스나 .NET 서비스를 하는 기업의 경우 매우 높은 안정성의 서비스를 구현 할 수 있지 않겠나 싶다.

역시 가격이 문제인 듯 한데, 가격 정책이 어떻게 결정 났는지는 Azure 홈페이지에서 확인하시라.


Microsoft APAC Infrastructure Architect Evangelist  신현석 님의 블로그.
http://www.cooolguy.net/139

Microsoft Azure 홈페이지
http://www.microsoft.com/azure/default.mspx