정규현 wrote..
: Director에 웹서버 다수를 물리는 현재방식의 웹클러스터링에
: 대신 베오울프 클러스터링을 도입하면 어떨가 하는 생각을
: 해봤습니다. 비용대 효율측면에서 오히려 지금의 웹클러스터링보다
: 낫지 않을까 싶은데요...
:
: 클러스터링에 관심이 있으신 분들 의견 주시기 바랍니다.
아래 분들 글 잘 읽었습니다.
여기서 부하분산뿐만이 아니라 fail over 기능도 중요하지요.
어떤 서버에 문제가 생긴다고 하더라도 전체 서비스에는 지장이 없는.
다른 분들 말대로 서비스의 특성에 따라 그것을 구현하는 기법이 달라지겠지요. 웹서비스는 동시에 작고 짧은 요청이 대부분이고 CPU보다는 네트웍에 더 큰 영향을 미칠 듯. 또한 I/O 작업을 줄여주는 것이 중요하구요.
그래서 가능한한 DB연결도 줄이는 방향으로 사이트를 설계하구요.
정규현 wrote..
: Director에 웹서버 다수를 물리는 현재방식의 웹클러스터링에
: 대신 베오울프 클러스터링을 도입하면 어떨가 하는 생각을
: 해봤습니다. 비용대 효율측면에서 오히려 지금의 웹클러스터링보다
: 낫지 않을까 싶은데요...
:
: 클러스터링에 관심이 있으신 분들 의견 주시기 바랍니다.
위의 두분의 답글이 매우 유용하다고 생각합니다.
거기다 덧붙인다면
지금까지는 베어울프 클러스터링이 새로운 컴퓨터들의 등장으로 졸지에
으로 구식컴퓨터가 되어버린 컴퓨터들를 이용하는 대안으로 각광받고 있는 것 같습니다(예:IBM 486/낮은 사양의 웍스테이션).
다시 말해서 베어울프 클러스터링 방식을 채용하기 위해 신규컴퓨터의
추가 구매를 하는 것 아니라 말이죠 .(대학이이나 연구소에는 철지난
구형컴퓨터들이 많거든요)
정규현 wrote..
: Director에 웹서버 다수를 물리는 현재방식의 웹클러스터링에
: 대신 베오울프 클러스터링을 도입하면 어떨가 하는 생각을
: 해봤습니다. 비용대 효율측면에서 오히려 지금의 웹클러스터링보다
: 낫지 않을까 싶은데요...
:
: 클러스터링에 관심이 있으신 분들 의견 주시기 바랍니다.
전산학을 전공한 입장에서 답변해보겠습니다.
학부때 배운 지식에 의하면 컴퓨터가 수행하는 일은 크게
computing bound, I/O bound 두 가지로 나뉘어집니다.
computing bound는 데이터 입출력 작업 없이 계산 위주로 이루어
지는 작업이며 I/O bound는 데이터 입출력을 주로 하는 작업입니다.
시스템의 측면에서 보면 computing bound는 CPU를 많이 혹사(?)
시키는 작업이고 I/O bound의 경우 CPU의 사용률이 매우 낮다는
교과서적인 얘기가 나옵니다.
제가 beowulf를 사용해보지는 않았지만 computing bound 작업을
여러대의 컴퓨터로 병렬, 분산처리하는 것이 주 목적인 것으로
알고 있습니다.
웹 서비스의 경우 성격을 구분하자면 I/O bound쪽에 가깝습니다.
얼핏 생각하면 beowulf의 적용 대상으로 생각하기는 힘들죠.
하지만 실제 웹 서버의 경우 CGI 등의 동적 문서의 처리를
제외한 정적 문서의 서비스를 위해서도 상당히 많은 CPU를
사용합니다. 이런 측면에서 보면 beowulf가 매력적으로 보일 수도
있겠죠.
하지만, beowulf를 사용했을때 가장 큰 이득을 볼 수 있는 분야는
계산을 주로하는 작업이 아닐까 싶습니다. 웹서버 클러스터링에
사용을 해서 얻을 수 있는 이득이 얼마나 클지는 의심스럽군요.
데이터의 입출력이 주된 작업인 웹 서비스에 많은 CPU를 사용하는
것이 눈에 보이는 현상일지라도 이는 OS나 웹 서버의 구조적 문제에
기인하는 것이지 궁극적으로 계산의 문제는 아닐 것이라는 것이
개인적인 생각입니다.
정규현 wrote..
: Director에 웹서버 다수를 물리는 현재방식의 웹클러스터링에
: 대신 베오울프 클러스터링을 도입하면 어떨가 하는 생각을
: 해봤습니다. 비용대 효율측면에서 오히려 지금의 웹클러스터링보다
: 낫지 않을까 싶은데요...
:
: 클러스터링에 관심이 있으신 분들 의견 주시기 바랍니다.
일단 현재와 같은 Director(혹은 로드밸런스, L4스위치)를 사용하는 방식에 비해서 비용 측면에서는 크게 달라질 것이 없다는 생각이 듭니다.
그 이유로 베어울프 클러스터라고 말하는 방식의 클러스터나 웹서버 클러스터나 결국 비용이라는 것은 들어가는 하드웨어에 비례하기 때문이죠.
예를 들어 dual cpu 머신 8대로 베어울프 클러스터를 구성하는 비용이나 8대로 웹서버클러스터를 만드는 비용은 같다고 보시면 되지요.
기술적인 문제는 베어울프클러스터와 같은 방식(즉, CPU 로드를 각각에 분산하는 방법)이라는 것이 웹서버에 적용하기 위해서는 parallel apache와 같은 웹서버의 병렬버전이 필요하게 됩니다. 그런데 문제가 현재의 대부분의 인터넷서비스의 경우 장시간을 요하는 큰 사이즈의 프로세서가 도는 것이 아니라 순간 사용자가 들어올경우 httpd를 하나씩 띄워주는 방식이라는 것이 문제가 되지요.
다음과 같은 일을 할 경우에는 beowulf형태의 웹서버가 더 유리할 수는 있읍니다. 하나의 request에 대해서 엄청나게 시간이 오래걸리는 작업(perl로 루프를 많이 돌면서 script를 실행한다...)과 같은 경우는 그 로드를 각 CPU에 균등하게 짤라서 할당하는 것이 필요하겠지요.
또는 하나의 홈페이지가 무지무지 커서 한 CPU에서 보여주는데 엄청로드가 많이 걸리는 경우 등등. 그런데 이와 같은 형태의 작업을 위해서는
다음과 같은 작업이 필수적입니다.
1. APACHE의 MPI버전
2. 각각의 페이지를 각 노드에 균등하게 분산시켜서 하나의 request에 대해서 합치거나 하는 과정
등등이 필요하며 이에 대해 작년부터 미국에 있는 한국인 교수인 Andrew Shon 이라는 분이 일본과의 공동연구로 진행하고 있읍니다.
그러나 현재의 대부분의 작업은 다량의 사용자가 동시에 접속하여 아주 작은 작업이 무수히 많이 뜨게 된다는 것이지요. 즉, 위와 같은 구조에는 적합하지 않을 수도 있읍니다.
검색엔진의 경우도 parallel search 엔진이 아이디어로 등장한 것도 있었으나....
생각을 하면 다음과 같이 단순화시킬 수 있겠지요.
1. 현재의 방식
10000명이 동시에 검색을 할 경우 director가 각 유저의 request를 적절히 분배한 다음에 동시에 request가 떠서 각각 검색을 진행한다. 빨리 결과를 돌려줘서 로드가 적게 걸리는 CPU에 그다음의 작업이 들어온다.
2. Beowulf 방식
10000명이 10000개의 검색을 요구할 경우 순서대로 하나씩 들어와서 검색부분을 CPU갯수만큼씩 균등하게 분할하여 1/CPU갯수의 시간에 끝내고 그다음 작업을 처리한다.
어느 방식이 적합할 것인가는 곰곰히 생각하면 될 것입니다.
똑같은 문제는 graphic rendering같은 경우에도 적용이 됩니다.
하나의 프레임에 대해서 병렬rendering엔진을 사용하여 전체 CPU가 렌더링을 분할하여 빨리 끝내는 방식이 있을 수도 있고, 동시에 각각의 CPU가 서로다른 프레임을 나눠서 작업을 진행하는 방식이 있읍니다.
즉, 만화영화 1초를 만들기 위해 30프레임을 렌더링한다고 할때, 첫번째 방식은 30개의 CPU가 1개의 프레임을 1/30시간안에 렌더링을 하고 그다음 프레임으로 진행하는 것이고 두번째 프레임은 각각의 CPU가 각 프레임을 1시간에 렌더링을 하고 30개의 CPU가 동시에 작업을 끝내는 것이지요.
계산도 마찬가지입니다. 엄청나게 오래걸리는 작업을 CPU가 나눠서 계산을 하는 경우도 있고 각각의 CPU가 n개의 서로다른 작업을 동시에 진행하는 것이 필요할 수도 있지요.
정규현 wrote.. : Director에 웹서버 다수를 물리
정규현 wrote..
: Director에 웹서버 다수를 물리는 현재방식의 웹클러스터링에
: 대신 베오울프 클러스터링을 도입하면 어떨가 하는 생각을
: 해봤습니다. 비용대 효율측면에서 오히려 지금의 웹클러스터링보다
: 낫지 않을까 싶은데요...
:
: 클러스터링에 관심이 있으신 분들 의견 주시기 바랍니다.
아래 분들 글 잘 읽었습니다.
여기서 부하분산뿐만이 아니라 fail over 기능도 중요하지요.
어떤 서버에 문제가 생긴다고 하더라도 전체 서비스에는 지장이 없는.
다른 분들 말대로 서비스의 특성에 따라 그것을 구현하는 기법이 달라지겠지요. 웹서비스는 동시에 작고 짧은 요청이 대부분이고 CPU보다는 네트웍에 더 큰 영향을 미칠 듯. 또한 I/O 작업을 줄여주는 것이 중요하구요.
그래서 가능한한 DB연결도 줄이는 방향으로 사이트를 설계하구요.
정규현 wrote.. : Director에 웹서버 다수를 물리
정규현 wrote..
: Director에 웹서버 다수를 물리는 현재방식의 웹클러스터링에
: 대신 베오울프 클러스터링을 도입하면 어떨가 하는 생각을
: 해봤습니다. 비용대 효율측면에서 오히려 지금의 웹클러스터링보다
: 낫지 않을까 싶은데요...
:
: 클러스터링에 관심이 있으신 분들 의견 주시기 바랍니다.
위의 두분의 답글이 매우 유용하다고 생각합니다.
거기다 덧붙인다면
지금까지는 베어울프 클러스터링이 새로운 컴퓨터들의 등장으로 졸지에
으로 구식컴퓨터가 되어버린 컴퓨터들를 이용하는 대안으로 각광받고 있는 것 같습니다(예:IBM 486/낮은 사양의 웍스테이션).
다시 말해서 베어울프 클러스터링 방식을 채용하기 위해 신규컴퓨터의
추가 구매를 하는 것 아니라 말이죠 .(대학이이나 연구소에는 철지난
구형컴퓨터들이 많거든요)
금전적인 측면에서도 조금은 구형이된 컴퓨터를 썩혀두느니 낫고
리소스의 협력과 추가효과 측면에서도 나으니까 말이죠
정규현 wrote.. : Director에 웹서버 다수를 물리는 현재
정규현 wrote..
: Director에 웹서버 다수를 물리는 현재방식의 웹클러스터링에
: 대신 베오울프 클러스터링을 도입하면 어떨가 하는 생각을
: 해봤습니다. 비용대 효율측면에서 오히려 지금의 웹클러스터링보다
: 낫지 않을까 싶은데요...
:
: 클러스터링에 관심이 있으신 분들 의견 주시기 바랍니다.
전산학을 전공한 입장에서 답변해보겠습니다.
학부때 배운 지식에 의하면 컴퓨터가 수행하는 일은 크게
computing bound, I/O bound 두 가지로 나뉘어집니다.
computing bound는 데이터 입출력 작업 없이 계산 위주로 이루어
지는 작업이며 I/O bound는 데이터 입출력을 주로 하는 작업입니다.
시스템의 측면에서 보면 computing bound는 CPU를 많이 혹사(?)
시키는 작업이고 I/O bound의 경우 CPU의 사용률이 매우 낮다는
교과서적인 얘기가 나옵니다.
제가 beowulf를 사용해보지는 않았지만 computing bound 작업을
여러대의 컴퓨터로 병렬, 분산처리하는 것이 주 목적인 것으로
알고 있습니다.
웹 서비스의 경우 성격을 구분하자면 I/O bound쪽에 가깝습니다.
얼핏 생각하면 beowulf의 적용 대상으로 생각하기는 힘들죠.
하지만 실제 웹 서버의 경우 CGI 등의 동적 문서의 처리를
제외한 정적 문서의 서비스를 위해서도 상당히 많은 CPU를
사용합니다. 이런 측면에서 보면 beowulf가 매력적으로 보일 수도
있겠죠.
하지만, beowulf를 사용했을때 가장 큰 이득을 볼 수 있는 분야는
계산을 주로하는 작업이 아닐까 싶습니다. 웹서버 클러스터링에
사용을 해서 얻을 수 있는 이득이 얼마나 클지는 의심스럽군요.
데이터의 입출력이 주된 작업인 웹 서비스에 많은 CPU를 사용하는
것이 눈에 보이는 현상일지라도 이는 OS나 웹 서버의 구조적 문제에
기인하는 것이지 궁극적으로 계산의 문제는 아닐 것이라는 것이
개인적인 생각입니다.
정규현 wrote.. : Director에 웹서버 다수를 물리
정규현 wrote..
: Director에 웹서버 다수를 물리는 현재방식의 웹클러스터링에
: 대신 베오울프 클러스터링을 도입하면 어떨가 하는 생각을
: 해봤습니다. 비용대 효율측면에서 오히려 지금의 웹클러스터링보다
: 낫지 않을까 싶은데요...
:
: 클러스터링에 관심이 있으신 분들 의견 주시기 바랍니다.
일단 현재와 같은 Director(혹은 로드밸런스, L4스위치)를 사용하는 방식에 비해서 비용 측면에서는 크게 달라질 것이 없다는 생각이 듭니다.
그 이유로 베어울프 클러스터라고 말하는 방식의 클러스터나 웹서버 클러스터나 결국 비용이라는 것은 들어가는 하드웨어에 비례하기 때문이죠.
예를 들어 dual cpu 머신 8대로 베어울프 클러스터를 구성하는 비용이나 8대로 웹서버클러스터를 만드는 비용은 같다고 보시면 되지요.
기술적인 문제는 베어울프클러스터와 같은 방식(즉, CPU 로드를 각각에 분산하는 방법)이라는 것이 웹서버에 적용하기 위해서는 parallel apache와 같은 웹서버의 병렬버전이 필요하게 됩니다. 그런데 문제가 현재의 대부분의 인터넷서비스의 경우 장시간을 요하는 큰 사이즈의 프로세서가 도는 것이 아니라 순간 사용자가 들어올경우 httpd를 하나씩 띄워주는 방식이라는 것이 문제가 되지요.
다음과 같은 일을 할 경우에는 beowulf형태의 웹서버가 더 유리할 수는 있읍니다. 하나의 request에 대해서 엄청나게 시간이 오래걸리는 작업(perl로 루프를 많이 돌면서 script를 실행한다...)과 같은 경우는 그 로드를 각 CPU에 균등하게 짤라서 할당하는 것이 필요하겠지요.
또는 하나의 홈페이지가 무지무지 커서 한 CPU에서 보여주는데 엄청로드가 많이 걸리는 경우 등등. 그런데 이와 같은 형태의 작업을 위해서는
다음과 같은 작업이 필수적입니다.
1. APACHE의 MPI버전
2. 각각의 페이지를 각 노드에 균등하게 분산시켜서 하나의 request에 대해서 합치거나 하는 과정
등등이 필요하며 이에 대해 작년부터 미국에 있는 한국인 교수인 Andrew Shon 이라는 분이 일본과의 공동연구로 진행하고 있읍니다.
그러나 현재의 대부분의 작업은 다량의 사용자가 동시에 접속하여 아주 작은 작업이 무수히 많이 뜨게 된다는 것이지요. 즉, 위와 같은 구조에는 적합하지 않을 수도 있읍니다.
검색엔진의 경우도 parallel search 엔진이 아이디어로 등장한 것도 있었으나....
생각을 하면 다음과 같이 단순화시킬 수 있겠지요.
1. 현재의 방식
10000명이 동시에 검색을 할 경우 director가 각 유저의 request를 적절히 분배한 다음에 동시에 request가 떠서 각각 검색을 진행한다. 빨리 결과를 돌려줘서 로드가 적게 걸리는 CPU에 그다음의 작업이 들어온다.
2. Beowulf 방식
10000명이 10000개의 검색을 요구할 경우 순서대로 하나씩 들어와서 검색부분을 CPU갯수만큼씩 균등하게 분할하여 1/CPU갯수의 시간에 끝내고 그다음 작업을 처리한다.
어느 방식이 적합할 것인가는 곰곰히 생각하면 될 것입니다.
똑같은 문제는 graphic rendering같은 경우에도 적용이 됩니다.
하나의 프레임에 대해서 병렬rendering엔진을 사용하여 전체 CPU가 렌더링을 분할하여 빨리 끝내는 방식이 있을 수도 있고, 동시에 각각의 CPU가 서로다른 프레임을 나눠서 작업을 진행하는 방식이 있읍니다.
즉, 만화영화 1초를 만들기 위해 30프레임을 렌더링한다고 할때, 첫번째 방식은 30개의 CPU가 1개의 프레임을 1/30시간안에 렌더링을 하고 그다음 프레임으로 진행하는 것이고 두번째 프레임은 각각의 CPU가 각 프레임을 1시간에 렌더링을 하고 30개의 CPU가 동시에 작업을 끝내는 것이지요.
계산도 마찬가지입니다. 엄청나게 오래걸리는 작업을 CPU가 나눠서 계산을 하는 경우도 있고 각각의 CPU가 n개의 서로다른 작업을 동시에 진행하는 것이 필요할 수도 있지요.