Scale Fail - 1 부

Josh Berkus 라고, PostgreSQL expert 라는 회사의 CEO 이자 PostgreSQL 코어개발자가 있는데,

이 아저씨가 LWN 에 Scale Fail 이라고 확장(용량재산정)에 실패하는 것들에 대한 기고가 있다.
( http://lwn.net/Articles/441790/ : 현재 무료기사로 풀림 )

그가 비밀이라면서 꺼낸 첫 말은, 자신은 데이타베이스를 수정하기보단,

어플리케이션을 수정한다고 말하며 기사는 시작된다.

즉, 대부분 기업들은 데이타베이스가 성능과 다운타임에 직결되는 문제라고 보고,

Josh 를 고용해서 데이타베이스위주로 수정을 요구하는데,

Josh 는 확장실패는 거의 대부분 운영적 판단이 형편없어서고,

오히려 이런 형편없는 판단이 다운타임과 퍼포먼스 저하들을 불러일으킨다고 했다.

즉, 안티패턴의 잦은 반복으로 안티스케일링이 된다는얘기..

그는, 지난 MySQL 컨퍼런스 및 Expo  에서 이런 안티-패턴들에 대해서 아주 조금 언급했고,

다른 CTO들은 각자 가서 자신의 상품들을 다시 보고, 그에게 돌아왔단다..

그는 여기서 안티패턴을 인식하고 제거하는 비법들을 살짝 공개했다.

1. 최신유행을 따라하는 것.

A: "자, 왜 넌 데이타베이스를 마이그레이션하는거야? 니가 석달동안 다운타임이 전혀 없었고,
   향후 2년 동안 지속적인 성장이 계획되어 있는데, 니가 마이그레이션을 하면
   오히려 중단과 혼란이 야기될것이라고"

B: "음.. 우리 CTO 가 주마다 있는 CTO 끼리의 점심모임을 하는데,
PostgreSQL 을 사용하는 유일한사람이라는거지.. 다른 CTO 들이 그거가지고
    자꾸 뭐라고 쫀대나봐." - 실재 조쉬가 경험했단다.

무슨얘기일까? 이건 '구글이나 페이스북등이 뭐 어쩧게 했다더라' 카면,

아주 그게 곧 진리인양, 안바꾸면 큰일이라도 날듯한 호들갑과 함께,

그것을 최신 경향으로 판단하고 따라하려고 한다는 점을 꼬집는다.

최신 트렌드 기술들은 오히려 형편없는 문서화와, 버그투성이, 불안정, 컴포넌트간 통합불가등

큰 이슈들을 불러일으킨단다. ( 맞는것같다. 박수치고싶다 ㅋㅋ )

그는 오히려 회의중에 기술적인 중역 (CTO 및 뭐 고위기술자등) 들이 무슨 잡지따위나

업계동향 페이지같은걸 보고선 "hip", "hot", "cutting-edge(첨단기술)" 등을 얘기하면

백프로 야근하게 될거라는 얘기이며 이런 중역들을 경고하고있다. ㅋㅋ

그는 오히려 신뢰가 입증되고 충분히 테스트된 기술들을 사용하는 것을 권장하고, 

따끈따끈한 새 기능들 보단 별 모니터링들이 없어도 지속적인 운영이 가능한게

더 중요한 일이라고 설명하고 있다.

구글이나 페이스북을 무작정 따라하지 않아야 하는 이유로 첫번째 그는,

그네들과 플랫폼이나 어플리케이션이 유사하지도 않는데 따라하려고 해선 안된다는거고,

다시 그들이 새로 구축하게 되도 그 기술들을 사용할 것인지 먼저 그쪽 직원들에게 질문후,

따라하려면 따라하라는 것인데..그들이 항상 옳은건 아니라는 얘기이겠지..

2. 수치(정확성?)들이 없다.

A: "우리 네트워크 지연은 확인 해봤나?"

B: "내생각엔 문제는 HBase 야"

A: "응, 그런데 우리 측정해봤어?"

B: "내가 말했잖아, 우린 측정할 필요가 없어, 문제는 항상 HBase 야."

A: "어디 한번 해보라고"

B: "도대체 무슨소릴.....흠.......아, 내생각엔 네트워크가 뭔가 잘못된것같아"

응용프로그램의 확장은 곧 연산훈련이란다.

한명의 고객이 웹서버에서 소요하는 CPU time 이 X 라면 100,000 명의 동시접속자를 위해

몇대의 서버가 필요한지? 라던가, 하루에 Y 만큼 증가하고, 데이타의 Z% 만큼 활성화 되는

DB의 RAM 을 얼마나 증가시켜야 할까라든지 등 확장을 계획할 경우엔,

Javascript 에서부터 하드웨어 스토리지까지,

또한 모든 응용프로그램의 스택조각들 마져 instrumenting 해야 한다고 얘기한다.

3. 뒷북질 ( Barn Door Decision making 이라는데 의역하면 이럴껄? ㅡ.,ㅡ:: )

Dan: "내가 아마존에 있었을땐말야 , 스퀴드 리버스프록시를 이용해 구축했어."

Smith: "댄, 자넨 아마존에서 영업관리담당이였잖아."

골때리지 않나? 

니가 직접 해본거나 경험한거 아니면 닥치고 그냥 있으라는 얘기인데 대충..

그가 뽑는 짜증나는 문구는 다음과 같다.

1. "내가 전에 근무했던 회사에선~"

2. "우리가 전에 '전혀다른문제를 얘기하면서' 가 발생됬었을때,
    '대충 아무소프트웨어나 기술을 갖다붙히면서' 을 이용해 해결을 했었오~."

3. "'엉뚱한프로젝트' 는 '아무 기술이나 소프트웨어를 언급하며' 에서 사용되고 있어,
    그러니 우리도 그걸로 가야함둥!"

그냥 닥치고 어플리케이션 설계나 하란다. ㅎㅎ

4. Single-threaded Programing

A: "내가 레일즈에서 monkey-patch 를 했다면, 수행중인 프로세스에
   적용되는건 언제지?"

B: "즉시! 마치 마법처럼"

조쉬는 '병렬처리' 야 말로 대부분 개발자들이 도전해야 할 마음가짐이라고 한다.

실 예로, 그는 한 소프트웨어가 240 개의 클라우드 서버들에 배포된 데이타를 처리하려고 했는데,
 
단일 프로세스로 개발되고, 단일 서버에 dispatch 하는 프로그램으로 인해,
 
분당 4000 개의 작업이 제한되었고 75퍼센트의 Idle 을 갖고 있었다고 한다.

대부분 단일 프로세서와 단일 스레드로 된 개발자의 노트북등에서 작성된 코드들과,

단일 프로세서와 단일 스레드로 된 환경에서의 테스트들이 문제라고 설명한다.

그래서 그는 프로그래머라면 어플리케이션 확장에 대한 제안이 있을때면, 항상 그 프로그램이

동시접속해서 처리하던 유저수가 몇인지 확인하고, function Language 를 배우거나,

map/reduce 를 사용하는것이 병렬적 사고에 매우 도움이 되는 훈련이라고 조언하고 있다.

멋진 아저씨이다... 사실 댓글들 보면 멀티쓰레드와 씽글쓰레드 프로그래밍에대한

견해차이들이 좀 있긴 한데, 그래도 안하면 쓰나! 있는건 활용하면서 개발해야지..

다음엔 Scale Fail - 2 부가 정리될 것이다. ( 요녀석은 아직 유료기사다. )

PS : Monkey-Patch 라는건 바로 적용될 수 있도록 하는 패치로, 동적언어등에서

사용되는 용어읻.. 즉 이미 저 말 자체로 즉시적용이라는 의미가 있는거임둥. ;P