후하하핫
5k
2021-12-30 12:40:27 작성 2021-12-30 12:40:54 수정됨
4
1323

더 빡센 계산을 잘하는 방법: Scale-up과 Scale-out


엄청나게 빡센 계산을 해야 한다고 합시다. 암호의 해독일 수도, 구글에서 검색엔진이 응답을 해줘야 하는 문제일 수도 있고, 물리화학 시뮬레이션일 수도 있을 겁니다. 어떻게 빡센 계산을 수행할 수 있을까요?


오늘의 기술사 포스트에서는 빡센 계산을 하기 위한 방법론, Scale-up과 Scale-out에 대해 알아봅니다.


0. 컴퓨터의 발명은 빡센 계산을 위해


영화 이미테이션 게임으로 알려진, 앨런 튜링의 애니그마 해독을 위한 기계 장치, 즉 컴퓨터의 원형에 가까운 그 장치의 목표는 빡센 계산이었습니다. 조금 더 풀어서 설명하면, 2차 세계대전 당시 독일군의 전신은 애니그마 라는 암호화 기계를 통해 이루어 졌고, 하루에 한번 씩 seed를 바꾸면서 암호화를 했기 때문에 인간의 힘으로는 풀기 어려웠다고 합니다. 앨런 튜링은 컴퓨터의 원형 정도 되는 기계를 발명해, 더 빠른 계산으로 인간이 풀지 못하는 문제를 해결하기 위한 가능성을 보여줬죠.


1. Scale-up: 더 좋은 기계로 계산하자!


당연하게도 초기의 컴퓨터 역사에서 가장 노력했던 것은 컴퓨터 하나의 속도를 빠르게 하는 것이었습니다. 진공관, 트랜지스터, 집적회로, 초고밀도 집적회로로 이어지는 전자공학의 발전에 힘입어 2년에 두 배씩 트랜지스터의 개수를 늘려가며 (이것을 인텔의 공동창업자 Moore의 성을 따 Moore's law, 혹은 무어의 법칙이라고 부르죠) 빠른 발전을 이어 나갔습니다. CPU 클럭 속도가 빨라지면서 이전에 풀지 못했던 문제들을 계속 풀어냈고, 미래에도 그렇게 되리라 기대했죠.


하지만, 결국 어느 순간에는 클럭 속도를 올리는 것이 정체 되기 시작했습니다. 게다가 서버 및 사용자들의 사용 환경이 하나의 일을 잘 처리하는 것보다 다양한 일을 시분할로 잘 처리하는 것으로 요구가 바뀌게 되면서, 아무리 CPU 하나가 빨라도 모든 일을 해내기 어려운 상황이 되었습니다.


그리고 멀티프로세서 & 멀티코어의 시대가 시작됩니다. (물론 예전부터 있던 아이디어이긴 했지만) 하나의 보드에 여러개의 CPU를 놓거나 CPU 코어를 여러개를 둠으로써, 각 코어의 클럭 속도가 예전보다 느리더라도 병렬적으로 문제를 해결함으로서 전체적인 성능을 올릴 수 있게 됩니다. 이전에는 학술적으로만 논의되던 병렬 프로그래밍이 이 시대를 맞아 프로그래머들에게 전달되어 꽃을 피우게 되죠.


특히 성능 요구가 큰 서버 환경에서는 기존의 배치 기반의 메인프레임들을 점점 멀티 프로세서 및 멀티 코어 기반의 성능이 좋은 컴퓨터들로 교체해 가면서 성능을 올립니다. 이렇게, 개별 컴퓨터의 성능을 올리는 방식으로 더 많은 일을 처리할 수 있게 하는 전략을 Scale-up 이라고 부릅니다.


2. Scale-out: 여럿이서 머리를 맞대보자!


바야흐로 모두가 컴퓨터를 가진 시대가 되었습니다. 스마트폰도 들고 다니고, 노트북도 들고 다니고, 트래픽이 점점 많아집니다. Scale-up을 하기에는 개별 컴퓨터가 계속 비싸지고, 관리 비용이 커지고, 그 컴퓨터 하나가 죽어버리면 서비스가 죽어버리는 문제가 발생하네요.


이러한 문제를 해결하기 위해 분산 시스템을 구축합니다. 여러 개의 컴퓨터가 서로 연결 되어 협업을 하는 방식이죠. 하지만, 분산 시스템의 문제는 IQ 100인 사람을 두명 붙여 놓는다고 IQ 200이 되지 않는 것처럼, 그렇게 간단하지 않았습니다.


첫 번째로, 가격이 문제입니다. 계속 성능 좋은 컴퓨터를 붙여가면 서비스의 질이 나아질 수 있겠지만, 유지보수 비용이 너무 커집니다.

두 번째로, 생각보다 성능이 좋은 컴퓨터를 붙인다고 해서 성능이 그렇게 좋아지지 않습니다. DB의 내용을 sharding을 해놓아도, 멍청하게 sharding을 하면 새로운 insert가 들어올 때 쿼리가 느려지거나 인덱스를 다시 만들어야 하는 뻘짓이 필요해집니다.

세 번째로, 오히려 성능이 떨어지는 경우가 발생합니다. 원래 하나의 컴퓨터에서 처리할 땐 그 컴퓨터 안의 하드디스크와 메모리만 통신하면 됐는데, 컴퓨터가 더 붙으면서 네트워크를 통해 통신해야 합니다. 네트워크는 하드디스크 접근보다 느리고, (100 Mbps 를 풀로 땡겨도 하드디스크보다 느리죠) 서로 동기화를 해야하고, deadlock이 발생하고... 머리가 아픕니다.


즉, 분산 시스템의 문제는 하드웨어의 문제이기도 하지만 다분히 소프트웨어적인 문제를 통해 성능이 왔다갔다 한다는 것입니다. 기존 대기업 전산실에서 "느리면 컴퓨터 바꿔!" 가 어느 순간 작동하지 않게 된 것이죠.


Google은 이러한 문제를 재밌는 해결책들로 풀어냅니다.


첫 번째로, 기존의 고성능 컴퓨터를 연결하는 Scale-up 방식과 반대로, 그냥 굴러다니는 데스크탑 정도 성능의 컴퓨터를 훨씬 더 많이 연결하기로 합니다. 이렇게 개별 컴퓨터의 성능은 유지한 채 컴퓨터의 대수를 늘리는 방식을 Scale-out 이라고 합니다. 지금 클라우드 환경을 쓰는 사람들에겐 너무나도 익숙한 개념이죠.

이 방식이 작동하는 이유는 두 가지입니다.

첫 번째로 "대부분의 요청들은 짧고 금방 치고 나갈 요청" 이라는 전제 때문입니다. 즉, 어차피 대부분의 요청들은 고성능을 필요로 하는게 아니기 때문에, 낮은 성능의 컴퓨터로도 금방 금방 해결해 사용자가 원하는 퀄리티를 보장해 줄 수 있다는 것이죠.

아주 큰 두 번째 이유는, 경제적입니다. 단순히 컴퓨터 하나가 싸서 그런 것이 아니라, 싼 컴퓨터일수록 부품도 저렴하고 그 부품의 시장도 큽니다. 즉, 관리 비용이 전통적인 서버 관리 비용에 비해 큰 규모로 감축됩니다.

두 번째로, 분산 시스템을 컨트롤하기 위한 프로그래밍 모델과 시스템 소프트웨어들을 직접 만듭니다. MapReduce 라는 프로그래밍 모델, Google File System이라는 분산 파일 시스템, Bigtable 분산 데이터베이스 (흔히들 NoSQL 이라고 부르는 DB 중에 이런 니즈로 만들어진 DB들이 많습니다) 를 만들고 운영합니다. 즉, 똑똑하게 분산 컴퓨팅을 작성할 수 있도록 인프라를 만들어서 scale-out을 견디는 것이죠. 지금은 이런 scale-out이 대부분의 대규모 분산 시스템에 기본적으로 적용되고 있습니다.


3. 무엇이 Scalability를 결정하는가: 열, 에너지, 그리고 돈


Scale-out의 핵심적인 지표는 "과연 몇 대의 컴퓨터를 붙였을 때까지 선형적으로 성능이 증가하는가", 다른 말로 Scalability를 가지는가 입니다. 아무리 분산 시스템을 잘 만들어도 무한대의 컴퓨터를 붙일 수는 없고, 한계는 존재합니다.


정말 재밌게도, 수퍼컴퓨터를 만들거나 구글 급의 데이터 센터를 위한 분산 시스템을 만드는 사람들이 마주친 Scalability의 장애는, 소프트웨어가 아닌 열, 에너지, 그리고 비용이라는, 물리의 문제와 자본주의의 문제였습니다.


첫 번째로, 열이 발생합니다. CPU 뿐만 아니라, 계속 읽고 쓰기가 반복되는 하드디스크에서도 열이 발생합니다. 이 열이 커지면 전체적으로 시스템들이 throttling에 걸리게 되고, 성능이 낮아지거나 시스템이 파손되겠죠.


이러한 문제를 해결하기 위해 Google, Microsoft 등의 회사들은 많은 시도를 하고 있습니다. 기계공학을 하는 사람들을 뽑아다 데이터 센터를 위한 쿨러를 만들고, 데이터센터를 바다 밑에 짓기도 하고, 시베리아 같이 추운 곳에 짓기도 하는 등, 말그대로 별 생쇼를 다 해가며 열을 줄이려 노력하고 있습니다.


두 번째로, 전력 소모가 엄청납니다. 데이터 센터 1 exabyte (1 exabyte == 1024 petabyte, 1 petabyte == 1024 TB, 1 TB == 1024 GB) 를 유지하려면 중형 핵발전소 급의 전력 소모가 들어간다는 분석이 있을 정도입니다. 어떻게든 전력을 줄이지 않으면 안되는 것이죠.


여기에는 여러 답이 있습니다. 쿨러를 잘 만들어서 전력을 적게 쓸 수도 있을 것입니다. 다른 방법 중엔, 언더클락킹 같은 방법도 있습니다. 흔히 게임 잘 돌릴려고 클락을 올리는 오버 클락킹을 하지만, 데이터센터에서는 클락 수를 낮춰서 성능을 낮추더라도, 열과 에너지를 덜 쓰게 하는 방법을 채택하기도 합니다. 산술적으로 20%의 클락을 줄이면 20%의 컴퓨터를 더 놓을 수 있게 되어 전체적인 성능은 높아지지만 전력 소모는 같게 유지할 수 있죠.


세 번째로, 비용 문제가 큽니다. 이 비용을 줄이기 위해서 역시 별 생쇼를 다 하는데, 전력을 줄이는 것도 큰 부분이고, 특정 하드웨어 부품 같은 경우에는 아예 회사를 인수해서 사용하기도 합니다. 관리 비용을 줄이기 위해 하드디스크의 나사를 조이지 않고 하드디스크가 고장 나면 그대로 쓱 빼서 다시 하드를 교체하기도 합니다.


인간의 욕심엔 끝이 없기 때문에, Scalability는 아직도 큰 문제고 저 세가지 문제를 해결하기 위해 많은 산업계와 학계가 머리를 맞대고 고민하고 있습니다. 이쪽 학회 논문을 읽으면 CS 학회에서 왜 열전달 줄이는 얘길 하고 있지... 하는 생각이 들기도 합니다.


4. 극과 극은 통한다더니: 모바일 기기에서의 적용


극과 극은 통한다고 했던가요. 아주 재밌는 포인트는, 저 열, 에너지, 비용은 데이터 센터 스케일의 서버 뿐만 아니라, 사실 우리가 사용하고 있는 모바일 기기에서도 아주 중요하게 여겨지는 요소들입니다. 데이터센터는 scalability를 최대화 하기 위해 열, 에너지, 비용을 줄이려고 노력한다면, 모바일 기기를 설계할 때는 사용자의 편의성을 높이기 위해 역시 덜 열이 나게 하고, 배터리 시간을 길게 하기 위해 에너지를 줄이며, 소비자 부담을 줄이기 위해 비용을 최소화 하기 위해 많은 노력을 하고 있습니다.


이 과정에서 데이터센터 급에 적용되던 언더클락킹을 잘 하는 방법론 같은 것들이 모바일 쪽으로 넘어오기도 하고, 아예 데이터센터의 컴퓨팅 노드들을 모바일과 같은 ARM 기반의 서버로 바꾸는 시도들이 생기기도 하는 등, 알게 모르게 서로의 상호작용이 활발하게 일어나고 있습니다.


5. 마치며


결론적으로, 오늘도 비슷한 얘기입니다. 기존의 기업 중심의 메인 프레임 구조에서는 scale-out를 고려할 필요가 없지만, 일반 사용자가 컴퓨터를 사용하기 시작하면서 scale-out을 해야만 했습니다.

항상 기술은 사용자에 의해 발전되고 바뀝니다. 앞으로 얘기해 볼 blockchain이나 IoT 같은 기술들이 아직 일상에 덜 침투한 이유도 어쩌면 사용자가 그것들과 어떻게 상호작용 할 지에 대한 최소한의 답이 나오지 않았기 때문이라고 생각이 들기도 하고요.


저는 쓰면서 즐겁게 썼는데, 읽으시는 분들이 어떠실지 궁금합니다. 댓글로 질문 주시면 답변도 드리고 반영도 하도록 하겠습니다.

16
7
  • 댓글 4

  • OKKY
    3k
    2021-12-31 15:33:37

    안녕하세요 후하하핫님, OKKY 운영진입니다. 지속적으로 OKKY에 유익한 글을 올려주셔서 매번 감사드립니다. 혹시 '칼럼' 게시판으로 글을 옮겨드려도 괜찮을까요? 앞으로 OKKY 에디터가 선별한 글을 '칼럼' 게시판으로 모아두려고 하는데, 후하하핫님 글 중에 좋은 글들이 많아서 앞으로도 해당 게시판에 글 작성 부탁드려도 될 지 여쭤봅니다! 감사합니다. 새해 복 많이 받으세요.

  • 후하하핫
    5k
    2021-12-31 15:54:41 작성 2021-12-31 16:15:14 수정됨

    아하, 제가 글을 잘못 이해했었네요. 넵넵, 이번엔 부탁 드리고, 다음부터 작성 시에 칼럼 게시판에 작성하겠습니다.

  • OKKY
    3k
    2022-01-01 02:35:42

    앗 넵! 감사합니다

    건강하고 행복한 2022년 되세요~! :D

  • OKKY
    3k
    2022-01-01 02:36:46
    해당 게시물은 관리자에 의해 사는얘기에서 칼럼로 이동 되었습니다.
  • 로그인을 하시면 댓글을 등록할 수 있습니다.