Distributed System

 

국민대학교에서 "클라우드 컴퓨팅" 교과목을 진행하시는
이경용 교수님의 강의 교안을 이용하여 수업 내용을 정리하였습니다

 

 

 

클라우드 컴퓨팅 서비스의 대중화

 

우선 클라우드 컴퓨팅에 대해 알아야 하는데

 

대표적인 클라우드 서비스 제공 업체들

 

 

클라우드 컴퓨팅은 컴퓨팅을 하드웨어 관점이 아닌 소프트웨어 관점에서 활용하게 해주는 것이다!

 

클라우드 컴퓨팅 서비스의 특징

 

• 컴퓨터 자원의 초기 구매 없이 필요 할때 마다 대여 후 사용하는 서비스
  
  
• 인터넷을 통한 서비스 제공업체 컴퓨터로 연결
  
  
• 과금은 시간당 이루어 짐 (ex. CPU 4코어, 16기가 메모리는 시간당 20센트 : 전기세와 비교)
  
  
• 컴퓨팅 자원의 유지보수, 관리 부담을 덜어 줌
  
  
• 컴퓨팅 자원 뿐 아니라 다양한 형태의 사용자 친화형 서비스가 제공되고 있음

 

이렇게 클라우드 서비스 제공 업체는 자원 및 필요 소프트웨어를 제공해주기 때문에

 

컴퓨팅 자원의 유지보수, 관리 부담을 덜어주며 사용자는 핵심 응용 서비스 개발에 집중할 수 있게됨!

 

=> 컴퓨팅 자원의 소유와 사용의 분리를 통해 대중화 되었다!

 

 

기존의 컴퓨팅 모델과 클라우드 모델

 

on-premises 모델 VS 클라우드 모델

 

 

쉽게 생각하면 on-premise 환경은 자체적으로 구축을 해야하고 클라우드 모델은 서비스로 제공 받을 수 있음

 

 

조금 더 구체적으로 살펴보면

 

 

기존의 컴퓨팅 모델 (Infrastructure and computing as hardware)

 

• On-premise 데이터 센터, private cloud로 불리기도 함
  (서버실을 생각)
  
  
• 하드웨어 설치를 위한 공간, 직원, 물리적 보안, 예산 및 계획이 필요함
  
  
• 하드웨어 구입에 오랜 시간이 걸릴 수 도 있음
  
  
• 최대로 필요한 컴퓨팅 연산 능력을 추측하여 환경을 구축해야함

 

클라우드 컴퓨팅 모델 (Infrastructure and computinga as software)

 

• 서버실처럼 하드웨어가 아니라 소프트웨어로 봄
  
  
• 탄력적으로 운영 가능함
  
  
• 빠르고, 손쉽고 경제적으로 변경이 가능함

 

하이브리드 클라우드 컴퓨팅 모델

 

• On-premise 컴퓨팅과 퍼블릭 클라우드 컴퓨팅 모델을 혼용해서 사용

 

클라우드 사용의 장점

 

1. 하드웨어 구축 예산의 다양한 활용 가능

 

=> 서버 구매 비용 절감 때문인데 빌리는 것이기에 실물로 관리하지는 못함

 

2. 대량 사용에 따른 규모의 경제 혜택 

 

=> 클라우드 플랫폼은 서버를 대규모로 운용하기 때문에 대량 구매하면 가격 경쟁력이 올라감

(클라우드는 가격 변동이 잘 X)

 

3. 자원 사용 예측이 필요 없음

 

=> 자원의 필요에 따라 선택해서 사용할 수 있음

 

4. 탄력적이고 빠른 서비스 구축

 

=> 서비스 사용자 많아지면 유연하게 변경이 가능함

 

5. 데이터센터 운용에 따른 경비 제거

 

=> 서버 말고도 하드웨어 관리에 필요한 다른 자원들을 추가로 구매할 필요 X

 

6. 전세계 어디든 빠른 서비스 배포 가능

 

 

분산 시스템의 중요 고려사항에 따른 클라우드의 필요성

 

Reliability (안정성, 고가용성)

사용자의 요청을 처리 중 예상치 못한 이벤트가 발생하더라도 올바르게 동작해야 함

(ex. 하드웨어 고장, 소프트웨어, 버그, 운용 중 사람의 실수 등)

 

 

소프트웨어 시스템에 대한 안정성 예제들

 

• 서비스는 사용자가 예상하는 (약속한) 방향으로 동작해야 함
  
  
• 사용자가 소프트웨어를 약속하지 않은 방법으로 잘못 활용하더라도 이를 견뎌야 함
  
  
• 지원해주는 기능에 한해서는 예상된 사용 요청 및 데이터처리량 등에 대해서는 충분히 좋은 성능을 제공해줘야 함
  
  
• 허가되지 않은 사용을 막을 수 있어야 함
  
  
• 잘못된 일이 발생하더라도 올바르게 동작해야 함 (fault-tolerant)
  
  => fault는 언제든 발생 가능하지만 이게 failure가 되지 않게 하는게 point!

 

Fault : 컴퍼넌트가 처음 약속된 스펙에서 벗어나게 동작하는 것 (하드웨어, 소프트웨어, 사람 등)

Failure : 시스템이 정상동작을 멈추고 서비스를 제공해 줄 수 없는 상황

=> Fault가 Failure가 되지 않게끔 하는 것이 중요함

 

 

fault의 종류는 크게 하드웨어 fault와 소프트웨어 fault, 사람에 의한 fault로 나눌 수 있음

 

하드웨어 faults

 

하드웨어로 부터 발생할 수 있는 fault들에는 하드디스크 crash, RAM 고장, 정전, 네트워크 카드 고장 등이 있음

 

하드디스크의 MTTF (Mean Time to Failure)는 10년 ~ 50년 (평균적으로 30년) 으로 알려져 있음

 

=> 10,000대의 서버를 보유한 클러스터에서는 매일 하나의 하드 디스크가 고장 날 것으로 예상 가능

(10,000일은 대략 27년)

 

• 하드웨어 중복 설치를 통한 fault 발생 방지
  
  RAID를 활용한 디스크 셋업 (복제) , 서버가 2개의 파워 입력을 갖게 함 (정전이 일어나도 서버가 구동될 수 있게), 클러스터 내의 보조 배터리를 항상 구동해놓음 (비용이 많이 듬) 등의 방법을 사용 
• 소프트웨어 디자인으로 부터 하드웨어 fault 방지
  
  처리할 데이터 용량이 증가하면서 많은 시스템들이 많은 서버를 활용하여 분산 환경에서 구축되기 때문에 Fault가 발생할 확률이 증가됨
  
  => 클라우드를 맹신하면 안되고 소프트웨어 차원에서 Hadoop 작업 재실행 및 HDFS 블록 복제, Spark lineage (빅데이터 분석에서) 이나 TensorFlow 체크 포인팅 (DNN 학습에서) 등의 방법을 사용

 

소프트웨어 faults

 

 

소프트웨어 fault는 소프트웨어에 내재된 버그에 의해서 발생하는데

 

• 버그가 있는 프로세스 (프로그램)이 자원 (CPU, RAM, disk, network) 을 잠식
  
  
• Cascading failures : 한 컴포넌트의 실패가 다른 컴포넌트의 실패를 연속적으로 초래할 때
  (전체 시스템이 down 됨)
  
  
• 분산 서비스 운용시 (AWS)
  
  

위 경우들에 대해서 많이 발생함

 

발생되기 전까지는 눈에 띄지 않는 특성을 가지고 있고  특히 동작 환경을 가정해서 개발하고, 이 가정이 깨질 경우에 많이 발생함

 

• 시스템에서 가정하고 있는 상황의 면밀한 검토
  
  
• 프로세스 간의 실패를 분리 (cascading failures 방지 - circuit breaker)
  
  
• 테스트 (유닛 테스트 - 함수, 인테그레이션 테스트 - 모든 모듈) 로 이상징후를 지속적으로 탐지

를 통해 방지할 수 있음

 

 

사람에 의한 faults

 

사람은 기계/소프트웨어 만큼 안정적이지 못하고 실제로 시스템 운용의 configuration 실수에 의한 시스템 failure가 가장 높은 비중을 차지함 
(하드웨어 fault에 의한 실패는 아주 낮은 비율)

 

• 시스템을 디자인할 때 사람의 관여 여지를 최소화
  
  
• 수동작업을 자동화 하는 API 정의
  
  
• 복잡한 업데이트 단계의 추상화 (코드 리뷰 필수)
  
  
• 테스트 환경과 production 환경의 분리
  
  
• Failure 발생시에 roll-back 할 수 있는 환경 구축
  
  
• 업데이트를 순차적으로 실시

를 통해 방지할 수 있음

 

Scalability (확장성)

 

시스템이 커지더라도 이를 잘 처리하여 사용자에게 합리적인 성능을 제공해 줘야 함

(ex. 처리하는 데이터 총량, 요청 수, 시스템 복잡도 등)

 

즉, 시스템이 처리해야 할 작업(load) 가 증가하더라도 이를 잘 처리해내는 능력을 뜻하는데

 

Load에 대한 정의는 응용 서비스에 따라 다를 수 있음

 

• 웹서버 : 초당 처리 가능 요청수
  
  
• 데이터베이스 : 초당 처리하는 요청수, 저장 가능한 데이터 용량
  
  
• 캐쉬 서비스 : hit ratio
  
  

웹-스케일(web-scale) 에서 응용 서비스가 개발 됨에 따라서 중요도가 매우 높아짐

 

=> 웹은 전세계에서 접근 가능하므로 사용자가 갑자기 많아질 수 있음

 

예를 들어 살펴보면

디스패치의 경우 특정 사건이 발생하면 트래픽이 급등함

 

=> 확장성을 잘 고려하여 설계해야함

 

수강신청 힘들다고 다른 학교로 옮길까?

 

=> 확장성을 많이 고려하지 않을 수 있음

 

 

BlackFriday 때만 급등하는 사용자 때문에 서버 용량을 BlackFriday 기준으로 잡고 1년동안 사용한다면 굉장한 낭비임

 

=> 이것이 AWS의 출시 계기라고 볼 수 있음

 

 

시스템을 scalable 하게 하는 방법은?

 

 

Scale-up

 

• 하나의 서버를 업그레이드 (CPU, 메모리, 디스크 등)
  
  
• 구현이 직관적
  
  
• 소용되는 비용과 성능의 개선 정도가 비례하진 않음

 

Scale-out 

• 새로운 서버를 지속적으로 추가하여 컴퓨팅 연산 능력 확보
  
  
• shared-nothing architecture라고도 부름
  
  => 기존 구동 서버와 새로 추가된 서버가 공유 X
  
  (Stateless 응용에 적합)
  
  
• 관리 및 구현이 어려울 수 있음
  
  
• 최근 클라우드 환경에서 더 선호되는 방안

AI에서는 GPU가 중요하므로 Scale-up이 더 적합함 (딥러닝은 state를 주고 받아야 함)

하지만, web 환경은 web- application - DB 의 3-tier 환경이므로 Scale-out이 더 적합하며
(application에서는 요청이 독립적으로 처리되고 이전 요청의 상태를 기억하지 않는 stateless임)

빅데이터 분산처리의 경우도 매우 큰 데이터 셋을 다루기 때문에 여러 서버에 데이터를 분산시키는 방식인 Scale-out 이 더 적합 함!

 

Maintainability (유지보수성)

 

소프트웨어 개발의 대부분의 비용은 개발 단계가 아닌 소프트웨어 운용 및 버그 수정에 소요됨!!

 

기존 코드의 기능 개선, 새로운 기능의 구현등에 대한 요구가 지속적으로 발생하더라도 이를 효율적으로 처리할 수 있어야 함

 

유지보수성을 높여주기 위한 시스템 디자인 고려 사항에는

 

• 시스템 상태 모니터링
  
  
• 문제 원인 규명 (root cause analysis)
  
  
• 시스템을 최신으로 유지 (특히 보안 관련 패치)
  
  
• 시스템의 다른 요소들이 어떻게 동작하는지 지속적으로 확인
  
  
• 시스템 배포에 대한 best practice 정의 및 툴 구현 (수동 배포 지양)
  
  
• 시스템 configuration 의 version control
  
  
• 문서화를 통한 팀원 내부, 외부간의 지식 공유

 

가 있음