( 정윤진, yjjeong@rsupport.com )


일을 하다 보면, 스토리지에 관련된 이슈가 참 많이 생긴다.  NT 계열이건 Unix 계열이건, 스토리지에 대해서는 뭐 일반적인 스토리지는 많이들 구성하니까 Raid 의 종류별 성능이라던가 이런거는 뭐 너무도 일반화 되어 있어서, 별로 기술이라는 생각도 잘 들지 않게 되고.

파일시스템도 마찬가지여서, 리눅스의 ext2 시절부터 골때렸던 여러가지 이슈들 부터 메인 개발자가 사고쳐서 감방간 ReiserFS, 요새의 Solaris 기반의 ZFS 등 운영체제에 따른 OS 선택 옵션도 참 많다.

또 요새는 글로벌하게 분산되는 파일 시스템도 많아서, 뭐 사실 안정성이 문제긴 하지만 일종의 Torrent 같은 구현을 파일 시스템 레벨에서 구현하는 것도 종종 있기도 하고.

문제는 어떤 서비스에 뭘 선택해서 사용하느냐인데, 단일 시스템에서 대량의 ( Peta 규모 ) 파일시스템을 Aceess 할 일은 거의 없다고 본다. SAN 이나 iSCSI 로 엮어 NetApp이나 EMC의 스토리지와 연결하고, 이 볼륨들은 서버에서 원하는 형태로 스케일링 하여 파일시스템으로 마운트 되면서, 필요에 따라 NFS 나 CIFS 로 동일 용도의 서버로 묶는다든지, 아니면 오라클이나 DB2 등의 데이터베이스 시스템에 맞게 튜닝하여 RAC 나 클러스터링 구성을 한다 든지.

VMWare 의 ESX 서버를 SAN 에 붙여 사용하면 요거는 활용 가능성이 더욱 넓어진다.
최근 대세인 Cloud Computing 을 어떻게 구성하느냐에 따른 방법론은 참 많고, Amazon 의 EC2 관련 서비스를 어떻게 구현할 수 있을까 라는 것도 많겠지만, 궁극적으로 성능 - 백업 - 배포 - 관리 등을 동시에 고려한다면 어지간한 대규모 프로젝트보다 많은 노력이 필요하겠지.

쓰다보니 두서도 없고, 주제도 별로 제목과 맞지는 않지만 뭘 어떻게 하자는 것도 아니고
사실 고민 스러운 일도 아니다.

이전에도 한번 소개 했었지만, 간단한 파일시스템의 가상화를 통한 대량의 파일 복구 또는 DB 복구를 위해서 종종 사용하는 방법인데,  시스템에서 즉석으로 원하는 파일 시스템을 만들고
이를 마운트해서 원하는 성능을 얻는 방법. 뭐, 리눅스 용이고 간단한 dd 커맨드로 가능하다.
물론 해당 파일 시스템을 사용하기 위한 커널 모듈 또는 툴 등이 필요한것은 지당하다.

dd if=/dev/zero of=test_hoho.img bs=1k count=10000  ( 원하는 블럭사이즈의 원하는 파일 시스템 크기 )
mkfs.reiserfs test_hoho.img
mount test_hoho.img /mnt/test

ext3 의 dir_index 를 붙이기전, ( 뭐 일종의 파일시스템에 대한 b-tree indexing 정도로 이해하고 있다 ) 현저하게 떨어지는 대량의 파일에 대한 컨트롤 능력에 필요할때의 응급조치 랄까.

어느 순간에 대한 백업으로서 써도 좋다. 아니면 이렇게 만든 파일 시스템에 OS 를 올려서 배포를 해도 좋겠지.  분산컴퓨팅에 많이 쓰기도 하고.  나중에 pxe boot 와 연계해서 올리는 방법에 대해 간단히 설명하게 되면 하기로 하고.

systemimager 와 같은 유틸리티로 Cloud computing 을 구성할 수도 있고 뭐, 널린게 방법이니까.


어쨌든, 이 주제없고 웬지 Storage Tab 이 썰렁해 보여 아무렇게나 써제끼는 글에 대한 결론아닌 결론이라면, 역시 돈있으면 NetApp, EMC, 돈없으면 HDFS GFS ZFS 라는 거다.
서버 - Filesystem 이 분리 될 수 있는 NFS 구조라면,  NFS 자체는 OpenSolaris 의 nexenta 같은 OS를 사용하고, 이를 윈도우에서 마운트 하던 유닉스에서 마운트하던 맘대로 사용하면 되시겠다.

고가의 Veritas Cluster 나 Suncluster, Oracle RAC 같은 구성이라면, 돈있으면 SAN 돈없으면 iSCSI 겠지.  이럴때도 iSCSI 를 사용하기로 했다면, nexenta 가 훌륭한 답이 될 수도 있다.

암튼, 이런저런 두서없는 끄적거림에 대한 나만의 결론은, 돈이 있건 없건 대량의 사이즈에 대한 백업 또는 스냅샷 정책이 있어야 하고, 파일시스템 레벨에서의 정합성 및 장애 극복에 대해 항상 염두해 두어야 회사에서 잘리는 일이 없지 않을까?


그냥 썼다.  비도 오고 기분도 그렇고 해서~

(정윤진, yjjeong@rsupport.com )


피곤한듯 왼손 엄지와 검지로
나른하게 핸들을 잡고
느슨하게 엑셀레이터를 밟아 헤드라이트 빛에
일정한 타이밍으로 스쳐가는 도로의 차선 표시를 보고 있노라면

분명 목적지는 알고 있는데
목적지로 가기 위한 길도 알고 있는데
이게 정말 맞는 길인가 하는 의구심이 생겨.

왜 이런 의구심이 생길까 하고 생각 해 보면
난 아직
목적지에 다 다르지 못했기 때문이 아닐까
라는 해답을 찾곤 해.

원하는 목적지에 당도하는 것이
그게 목표라면

불안한 마음에 엑셀을 깊게 밟는 것 보다
부산스럽게 룸미러와 백미러를 바라 보며 바쁘게 차선 변경을 하는 것 보다

안전하게 , 또는 여유롭게
시간을 투자해야 겠지.

언제 그럴만할 시간이 있었을까 하고 생각 하며 부러워 하기 보다는
내가 지금 적절한 속도로 맞는 방향으로 가고 있는지
한번 쯤은 의심해 보기.

대신 의심이 끝나면,
우직하게 때로는 바보스럽게
갈 수 있는 만큼 가 보도록 하기.

- YZ -


맥주를 한잔 했어.  친구는 연애사에 들떠 있더군.
그의 이야기를 들으며, 부럽다는 생각도 잠깐 들었지만
난 그냥 그 친구의 연애사로 생기는 그의 즐거움을 위해
내심 그냥
축하해 주기로 했어.

그 친구는  몇 안되는 친구 중의 친구라 생각 되고
나의 아픔을 깊숙히 알고  친구로서 접근 할 수 있는 만큼 접근해 준
고마운 녀석이니까.

모두들,
잘 되었으면 좋겠어.

( 정윤진, yjjeong@rsupport.com )

간혹 그런 생각이든다.
'과연 시스템적으로 단순한 웹 서비스 구조에서 글로벌을 감안 할때, 메인 시스템 인프라와 같은 규모의 시스템이 지역적으로 필요 할 것인가'

이에 대한 답은 서비스의 동작에 따라 다르겠지만, 단순 컨텐츠의 경우 CDN 등을 이용하는 숱하고 숱한 방법들은 이미 많다.
하지만, 정적 컨텐츠 이외의 동적 컨텐츠가 많은 지역별 거점을 중심으로 운용되는 서비스의 경우에 시장성이 불투명하지만 일부 고객을 위해 서비스를 지속해야 하는경우, 제일 고민 되는 부분은 역시 시스템 및 관리를 위한 비용, 소위 말하는 TCO 가 관건이 되지 않을까.

미국에 메인 센터가 있고, 유럽에 일부 고객이 발생되기 시작한 시점에 사업 규모로서는 유럽에 미국만큼 큰 센터를 두는게 맞겠지만, 아직 얼마만큼의 고객이 확보 될지 모르는 지역에 대규모의 인프라 비용을 투자하는건 아무래도 리스크가 따르기 마련이다.

이런 경우의 해법이 무엇일까 하는 부분은 서비스의 유형별로 많이 다르겠지만, 일반적 웹 서비스에서 이런 질문은 이렇게 치환 될 수 있을 것이다.
'네트웍 회선 품질이 현저한 지역에 고품질의 서비스가 필요한 경우, 어떻게 해결 할 수 있을까?'

파일 전송을 주로 하는 서비스라면 CDN 과 같은 글로벌 업체를 통하는 방법외에는 답을 찾기 쉽지 않다. 하지만 채팅이나, image 서버를 별도로 구성한 웹 서비스의 경우, css 나 js, html 등의 몇 kb 전송에도 수초가 걸리는 상황이라면,  답은 Proxy 에서 찾을 수 있지 않을까.

웹 - WAS - DB 의 경우에는, GeoIP 를 사용할 수 있는 DNS 또는 웹 서버를 사용하여 웹 서버 자체를 글로벌하게 운용하여 답을 찾을 수도 있다.  또는, 웹 서버 자체가 많이 무겁다면, 효율적으로 Cache 를 수행하는 NginX 나 Varnish 등을 통해 적절한 프락싱을 통해 비슷한 해답을 얻을 수도 있을 것이다.

앞에서의 예와 같이, 미국에 수억의 시스템이 있다.  이를 일본과 유럽에 서비스 하고 싶다면, 일본과 미국에 저렴한 서버 호스팅 또는 , 가능한 경우 Amazon 의 EC2 와 같은 서비스에 서버를 한대 둔다.  여기에 NginX 나 Varnish 를 올리고, 필요한 경우 memcached 등과 같은 로직에 녹여 낼 수 있는 캐슁 툴 및 opcode 레벨의 cache 를 지원하는 각종 자원을 사용하거나, 아니면 아주 단순하게 squid 등의 오래된 고전적인 proxy를 통하여, OS 또는 시스템의 자체 Cache 를 믿고 서비스 하는 방법- 


뭐, 이미 이러한 방법을 수행하고 있는 업체도 많겠지만 중요한건 저렴한 비용으로 어느정도 동적인 컨텐츠에 대한 지역별 분산을 노릴 수 있는 잇점이 있다. 

아직 테스트 해 보진 않았지만, 일본에서 네이버와 같은 ( 네이버는 URL 구조가 좀 복잡하지만 ) 웹 서비스에 대해 squid 만 돌려 보아도 그 효과는 순식간에 나타난다.
뭐, 일부 사람들은 CDN 과 같은거 아니냐  라고 할 수 도 있지만, 틀린말은 아니다.
다만 CDN 을 운용하면서 발생 하는 비용이  직접 서버를 간단하게 구성해서 운용하는 비용보다 저렴 하지는 않을 것으로 생각된다.

똑같은 요청을 반복해서 처리 ( 단순 Static 한 컨텐츠가 아닌, 일부 동적인 자원에 대해서도 장기적으로는 동일한 요청에 대한 응답이므로 ) 하는 정도로 시장성이 충분 해 질 때 까지 지역적 서비스를 선별적으로 빠르게 할 수 있다면, ( 물론 로그인과 같은 DB Connect 가 발생하는 액션은 여전히 느리겠지만 ) Comet 이나 간단한 채팅,  css 또는 html, php 와 같은 자원에 대해서는 환상적인 현지 고객의 만족을 얻어 낼 수 있을 것이다.


역시, 오픈소스는 조합하기 나름인가 보다.

( 정윤진,  yjjeong@rsupport.co.kr )

숨은 조력자 이야기.

'아마도 그건'  이라는  노래가 있다. 영화 '과속 스캔들' 에 삽입되기도 했던 그곡.
이 노래의 '사랑' 이라는 단어를 '청춘' 으로 치환한다면 어떨까.

'청춘 그것은~ 엇갈린 너와 나의 시간들,  스산한 바람 처럼 지나쳐 가네'
'청춘 그것은~ 알수없는 너와 나의 그리움,  남아있는 나의 깊은 미련들.'


은석이가 언젠가 '형 나 책내기로 했어, 도쿄에 관한 책이야' 라고 했을때 그냥 도쿄에 관한
짤막한 여행집 정도가 되지 않을까 했지만,  가을, 겨울이 지나 해가 바뀔때 쯤 만들어졌던
책에는, 우리들이 공감하며 농담처럼 진담인듯 밤늦게 네이트온에서 떠들었던 이야기들이
자연스레 녹아있었다.  '세 남자의 도쿄 산책' 이라던 제목은, 어느샌가 '잘 지내나요 청춘' 으로
변경되어, 표지사진을 골라달라며 던진 몇장의 jpg 속에서  현재 지금의 책 표지를 보며
낄낄 거렸던 기억이다.

사진하는 젊은 은석이는 말하자면 예술혼이 녹아있는  우리나이에 보기힘든 몇안되는
특수한 청춘이랄까.  삐딱한듯 하지만 사상이 있는 잣대로 살아가며  입김나오는 스튜디오 사무실에서 라꾸라꾸에 몸을 누이던, 꿈을 좆아 15년을 카메라와 살아온 어리지만 관록을 가진
희한한 서울예전의 희한한 사진과 졸업생.

감회가 새롭다.  나이를 먹어가는 청춘속에 돈과 꿈 사이에서 방황하며 사랑에 상처받고
그리움에 쩌들기도 하지만, 그런 스스로를 위로하듯 도쿄의 화려한 네온사인을 피해 그 바로
뒷골목의 구석구석에 숨어있는 사람 또 삶의 냄새를 쫒아 생각하는 우리들, 또
책 잘되면 시원하게 곱창에 오리 풀코스 가자던 농담이 실현되려는 것을 보니.

우리같은 청춘들이 많은가 보다 싶다.

그 많은 청춘들에게 우리 이야기를 들어 줘  라기 보다는,
같이 소주잔 기울이며  약간은 혀 꼬부라진 대화를 나누며
그날 하루를 서로 위로 할 수 있는,  그런 책이 된것 같아 기분 좋다.


많은 사람들을 알아가며 친해지기도 하고, 또 반목하기도 하며 살아가지만
이렇게 마음맞는 사람들과 되지도 않는 농담 따먹기 하며 미래에 대해 함께 고민하고
힘든 시절에 눈물의 소주잔 기울이던 모든 시간들이
의미 있었던 청춘이 되길 바라며,

'숨은 조력자' 로 소개 해 준 은석이에게
또 나에대한 뿌듯함을 느끼게 해 주었다는 점에서 '고맙다' 라는 말 보다는
'앞으로 서로 더 잘되자'  라 하고 싶다.



한 살  한 살
뱃살에 나이테가 늘어난다.

늘어난 나이테 만큼
성공에 한발 더 다가가고 있는 것 일까.

주변의 석세스 스토리는
스튜어디스의 안전띠 착용 설명 만큼의 감흥 일 뿐

그래서 나는 언젠데
하는 질문만 커져 가는 나이.

얻는 것 만큼 잃는 것이 생겨나 슬퍼 하는 걸 보면
아직은 젊은가 보다.

그래, 까짓거
내년에 한번 더 뛰면 되지 않겠어?

- YZ -

( 정윤진  yjjeong@rsupport.co.kr )

서비스를 운영하다 보면, 심심치 않게 종종 발생하는 DDoS 공격을 볼 수 있다.
이 DDoS 공격은, 정말 아무리 좋은 회사의 L7 방화벽 장비를 이용해도 결국 Edge 레벨에서의 방어이기 때문에 IDC에서 너네 골치아프니 나가라 하면 눈물을 머금고 다른 데이터 센터를 향해 떠돌이 신세로 전락하는 경우가 많다.

내 생각에 가장 최선의 DDoS 방어 기법은, 회선 속도 자체가 서버 Down 을 발생 시키지 않을 만큼의 낮은 대역폭이거나,  아니면 정말 화끈하게 분산 구조를 충분히 적용하여 100Gbps 이상의 트래픽을 견디어 낼 수 있는 인프라를 가지는 방법밖에 없다.  전자의 경우 적당히 저렴한 사양의 장비와 잘 구성된 서버만 있다면 Edge 레벨에서의 방어를 통해 어느정도 서비스 Down은 막아 낼 수 있으며 얼마 되지 않는 트래픽 때문에 IDC에서 쫒겨 나지도 않는다. , 후자의 경우는 100Gbps 이상의 트래픽을 공격자가 유발시키기 이전에는 절대 서비스가 정지하지 않는다.

하지만, 대체 누가 100Gbps 이상의, 아니면 충분히 타협해서 50Gbps 이상의 공격을 잘 견디어 낼 수 있겠는가.

이에 대한 방책은 DNS 의 우회를 통한 Proxy Farm 의 구성이 아닌가 싶다.  다만 이러한 방법으로도 역시 서비스가 정지할 가능성은 있어서, 내 생각에 최선의 해법은 공격자로 의심되는 좀비PC 의 트래픽을 선별해서 Proxy 로 가도록 우회 시키는 것이 좋다고 본다.

자, 그럼 대체 어떻게 Proxy Farm 을 구성해야 하며, 어떻게 공격 클라이언트를 구분지을 것인가.

답은, iptables + varnish 의 조합으로 가능하지 않을까 싶다.

일단 저렴한 가격의 FTTH 또는 10M 미만의 회선을 받도록 하고, 여기에 LVS 등과 같은
로드밸런서를 붙인다.  이 로드밸런서 아래의 Real Server 들은 모두 Varnish 로 구성하도록 하고 이 아래에 서비스 서버와 동일한 웹서버를 두던지, 아니면 Varnish 자체가 Proxy 동작하므로 실제 서비스하고 있는 서버의 IP 를 박아준다.

이렇게 서버들의 구성이 끝나게 되면, 다음은 Redirect 처리다.

네임서버를 직접 운영하고 있다면, 네임 서버를 한대 더 증설하고 환경을 사설망으로 바꿔서 DNAT 처리를 하던, 공인 망에서 SLB 를 하던, 앞단에 iptables 를 올릴 서버를 한대 더 구성한다.  이쯤에서 이미 눈치 챘겠지만,  새로 만든 BIND 서버는 우리가 서비스하는 a.com 이라는 도메인에 대한 A 레코드를 새로 구성한 Proxy Farm 의 공인 IP 로 지정한다.

자, 그럼 iptables 의 조건에 걸리도록 하려면 어떻게 해야 하는가.
답은, 실 서비스 도메인인 a.com 에 대한 TTL 값을 굉장히 짧게 주는 것이다.
이후, 네임 서버 앞쪽의 iptables 에서 udp 53을 dest로 하는 패킷에 대해 특정 시간안에 많은 요청이 있게 되면 지정해 둔 내부의 네임서버로 포워딩 되도록 룰을 설정한다. 
충분한 테스트를 수행하고, 적절한 count 로 설정해야 훗날 방비가 됨은 물론이겠다.
또한, 좀비 PC 들의 공격이 우리나라에서 발생되는지, 아니면 중국등 외국에서 발생되는지를 파악해서 만약 한국 전용 서비스인데 중국등지에서 공격이 온다면, geoip 를 사용한 iptables 정책으로도 수용 가능 하겠다.

이와 함께 조정해야 할 것은, 웹 서버의 Keep alive timeout 에 대한 지정이다.  정상적인 사용자의 경우 브라우저를 통해 서비스 받을 것이기 때문에 별 문제가 없으리라 생각된다.

자, 그럼 이제 끝났는가?  아니다.
DDoS 공격을 위한 좀비들의 공격에서 보다 더 자유로워 지려면 실 서비스 구간에도 준비해야 한다.  앞서 적용한 iptables 를 동일하게 서비스 구간에도 준비하여 준다.


사실, 이 방법은 내가 만든 카더라 아이디어다.  이 아이디어의 요지는, 다음과 같다.

1.  공격자의 IP를 솎아 내고, 지정한 패턴으로 공격이 발생하는 경우 해당 클라이언트IP를
     Proxy Farm 으로 보낼 수 있어야 한다.

2. Proxy Farm 은 비교적 성능이 출중한 Varnish 를 사용하도록 한다.

3. 애초에 DNS 레벨에서 응답을 Proxy 쪽으로 줄 수 있어야 한다.
    실 서비스 망에서 처리하려 하는경우, 대역폭 문제로 IDC에서 쫒겨 날 가능성이 있다.

4. L7 레벨로 처리하지 않아도 된다.  단순 IP 레벨에서 요청에 대한 횟수 제한 조건만으로
   처리하여 장비 비용에 대한 부담을 줄인다.

5. 모든 DDoS 공격은 평생 지속되지 않는다.  공격 발생시 바로 신고하여 향후 피해를 줄인다.

6. 대역폭이 100M 미만이라면, 그냥 DDoS 전용 방어 장비를 구입하는것도 방법이다.


이런 방법을 수행하기 위해 iptables 와 proxy 서버를 예로 들었지만, 보다 좋은 방법이 있을 수도 있다.  애초에 L7 방화벽등이 있다면, 사용 가능한 많은 방법이 존재 할 것이다.
또는 이미 nginx 나 varnish 등을 실 서비스에 이용하고 있다면 보다 유연한 방어를 수행 할 수 있다.

한번 쯤은 이런 대책없는 공격에 대해 고민해 보고, 테스트를 통해 나만의 계획을 가질 수 있지 않을까 한다.

훗, 정작 Varnish 자체에 대한 이야기는 없어서, 다음에 다시 소개해야겠다.
내가 이래.. ㅎ


기타 구체적인 각 서버의 설정 등은, 다음의 링크를 참조 한다.

참고자료.
http://varnish.projects.linpro.no/

http://www.netfilter.org/

http://www.techsupportforum.com/networking-forum/security-firewalls/284749-iptables-conditional-redirect.html