( 정윤진, bluebird_dba@naver.com )





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 )

( 정윤진, bluebird_dba@naver.com )




윈도우와  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 )

( 정윤진, bluebird_dba@naver.com )

닥샷





























허접 사진 닥샷


( 정윤진, bluebird_dba@naver.com )

( 정윤진, bluebird_dba@naver.com )


여자 친구가 있어본지가 언제일까.
까마득한 기억만큼 즐거웠던 여름휴가는 잘 기억나지는 않고,
매년 여름마다 서버실에 있거나, 아니면 친구와 정처없이 전국을 한바퀴 돌며 해수욕장을
벤치마킹 한다던가 하는 뻘짓만 근 몇 년.

올해는 회사의 준호형 덕분에 배스낚시를 시작하게 되었다.
별다른 계획없이 올해는 휴가에 완벽하게 일을  잊어보자라는 각오로 준호형과 함께 강화도로 쐈다.  오후 2시에 출발해서 국도를 타고 부천을 지나 강화도에 도착하니, 준호형은 이미 낚시를 시작하고 있었다.



처음 받아보는 루어대와 릴,  헤메기를 약 30분여.
모양새 기구한 캐스팅이 시작되었다.

아마도 택사스리그 채비였던것 같은데, 고무처럼 말랑 말랑하면서 물속에서는 꼬리의 갈퀴때문에 희한한 움직임을 하는 빨강색 지렁이 모양 미끼였다.

예약한 팬션 근처의 수로에서 이리 저리 던져보며 캐스팅 놀이를 두시간 정도 하다가, 장소를 옮겼다.  옮긴 장소에서 뉴스에서나 보던 배스라는 고기를 처음 낚게 되었다.

'이럴수가'  대낚시의 붕어나 잉어의 손맛보다 훨씬 강렬한 느낌.
그리고, 실제 고기가 먹을 수 있는 떡밥같은 미끼가 아닌, 고무모양의 가짜 미끼로 잡는 고기란 뭔가  복권 당첨된 듯한, 세금이 면제된 꽁똔 획득과 비슷한 기분.


몇마리 더 2~3수 정도의 배스 손맛을 맛본 후에, 팬션으로 복귀.
뭔가 빠져드는 느낌.



팬션에서 숯불에 삼겹살을 구워서, 맥주와  소콜을 마셔 줬다.
둘이서 자기엔, 너무 큰 방. ㅋㅋ


자고 일어나서 급하게 석모도 가는 배를 타려 했지만, 표파는 아주머니에게 낚여서 엄한곳에서 미끼 던지다가 입질도 한번 못받고 난 일이 생겨서 그냥 복귀 해야 했다.

준호형은 석모도에 들어가서 많이 잡은 듯.


배스 낚시가 뭔가 지루하지 않고 계속 바쁘게 이곳저곳 다니며 찔러서 낚이는 재미가 쏠쏠한 탓에, 결국 낚시대를 지르고야 말았다.  지르고 바로 다음날 해성이를 졸라서 근처 반월 저수지로 갔었지만,  지저분한 물이 도저히 계속, 오래 하고 싶은 맘을 없애더라는.

친구와 함께 일요일에 화성의 남양대교 쪽으로 출발!


어설픈 개북이의 운전을 탓하다 보니 어느새 도착.
하지만 너무 늦게 출발한 탓에, 좋은 자리는 이미 없고
땡볕에서 엄한 곳에서만 캐스팅 하다가 하드베이트 몇개 분실, 루어 몇개 분실. ㅋㅋ

초보 둘이 고생했다.

남양대교 북단 아랫쪽에 수초지대가 있는데, 여기서 오후 2시 정도인데 그날 첫 수를 봤다.
3자 초반이었던것 같은데, 아쉽게도 사진이 없으므로 패스.

초보 둘의 채비가  웜도 없고, 바늘도 없는 데다가 루어 몇개 잃어버리고 나니 뭐 없어서 낚시가게 찾아다니다 지쳐 그냥 집으로 복귀.


내가 낚시에 돈을 쓰게 되다니, 오래 살고 볼일인가 보다.



배스 낚시의 길로 인도한 장본인. ㅋ



09년 여름 휴가는 그렇게 끝이 나고,
그래도 휴가 중에 큰 돈 쓰지 않아서 다행이고
새로운 취미가 하나 더 생겨서

좀 살기 괜찮아 지고 있달까.

( 정윤진, bluebird_dba@naver.com )


일을 하면서 커피를 많이 마시는 편이 아니지만,
요새 유독 이런 저런 카페인을 많이 섭취 중.


이런 저런 건강상의 이유로 점점 지내는 것이 쉽지 않다.



새벽에 업데이트 작업이 예정되어 있어, 사무실에 남아있는 현희형과 다른 서비스 담당 대리님 용 커피를 사러 잠시 들린 곳.

EDIYA 를 보니, 지금은 없어진 인터파크 건물 뒷쪽에서 대한형에게 이런저런 커피를 얻어먹던게 생각난다.

참, 많이 얻어 먹었지...  ( 잠시 감사 ㅋ )


예나 지금이나 느끼는 거지만,  운영을 잘 하는 조직은 정말 찾기 힘든 것 같다.
개발이나 시스템에서, 체계화된 협업도구를 바탕으로 만들어진 제품을 어떻게 테스트 하고 이를 배포하는가에 대해서는 많은 방법론들이 있고 또 모두들 원하지만
그런 체계화 된 업무에 직원들이 익숙해 져 있지 않은 업장에서 이런 저런 운영의 기틀을 마련하기는 참 어렵다.  안그래도 어려운 일인데.. ㅋ


협업도구는 어떤게 좋다! 거나, 단계별 로 뭘 어떻게 하는 것이 좋다 라는 것들은 kldp 라던가 관련 커뮤니티들에서 많이 소개 하고 있으니,  경험이나 간략하게 쓰는게 나을 듯 하다.

윈도우와 리눅스 및 유닉스 등의 복합적 서비스 구성에 어떤 배포 솔루션을 사용하여 제품의 업데이트를 수행할 것인가에 대한 고민으로 여러가지 버저닝 툴을 생각 했었지만,
시일이 급해 rsync 를 사용해서 내부 배포 테스트를 진행 했었다.

rsync + windows batch 를 통한 허접한 배포 구성이었지만, 나름 동작은 잘 하길래 이쯤이면 됬다 싶었는데 막상 테스트 서버에서 서비스가 동작하지 않는 것이 아닌가.  ( 너무 오랜만이라.. )
문제는 권한이었는데, rsyncd.conf 에서 uid 나 gid 를 주지 않았던 것이 문제가 되었던 듯 싶다.  그럼 과연 이 권한을 administrator 의 계정이나 그룹으로 주면 괜찮을까?
아니면 rsync 클라이언트 옵션에서 -a (-p) 옵션을 제거 하면 될까.

윈도우에서의 chown 커맨드만 알아도 참 쉬워지는 문제인데, 이럴때마다 윈도우를 너무 모르는게 참 챙피해 진다는..


방법은 어떻게든 나오겠지만
유닉스에서 윈도우를 맞춰 주던지,
윈도우에서 유닉스를 맞춰 주던지,
아니면 간단한 ftp 비슷 한 바이너리를 커스터마이징 하던지

아니면 돈주고 사던지..

정합성을 위해 md5sum 과 같은 간단한 CLI 툴도 필요할텐데..

글이 아니라 어째 점점 주저리 대지만,
사실 답은 나와있는데 하기 싫어서 그런가 보다.


힘이 안나서 그런건가..  글도 맘대로고 기술도 맘대로고..

업데이트나 해이지. ㅋ