Chae Seungmin

DevOps & carefree life [TMON] Channel Service Dev. Team

6 minute read

클라우드의 개요

Cloud_Procdess
Cloud 개요

Computing Resources 를 데이터 센터에 대량으로 구성하고 인터넷을 통해 사용자가 원하는 만큼 On-Demand 형태로 IT 서비스를 제공하는 방식.



클라우드의 유형

클라우드는 구축 형태에 따라 4가지로 구분된다.

  • Public Cloud
    • 인터넷을 통해 서비스 되는 Computing Resource
  • Private Cloud
    • 조직 내부에 구성되어 내부망을 통해 서비스 되는 Computing Resource
  • Hybrid Cloud
    • Public & Private Cloud를 연결하여 사용하는 형태
  • Multi Cloud
    • 다수의 클라우드 사업자의 클라우드 서비스로 구성된 환경



클라우드 서비스 모델

클라우드는 서비스 형태에 따라 IaaS, PaaS, SaaS 로 구분된다.

serviceModel_Procdess
Cloud Service Models

IaaS (Infrasturcture as a Service)

  • IaaS는 가장 기본적인 클라우드 서비스 모델로, 가상화된 컴퓨팅 리소스를 제공.
    • 이 모델에서는 가상 머신, 스토리지, 네트워킹 등의 인프라를 필요한 만큼 확장하거나 축소가 가능.
    • 사용자는 가상 머신에 운영체제와 애플리케이션을 설치하고, 데이터를 저장하며, 네트워크 설정을 구성하는 등의 관리 책임을 갖는다.
      • 예: Amazon Web Services (AWS)의 EC2, Microsoft Azure의 Virtual Machines 등



PaaS (Platform as a Service)

  • PaaS는 개발자들이 애플리케이션을 개발, 테스트, 배포하는 데 필요한 플랫폼 환경을 제공.
    • 사용자는 애플리케이션 코드 개발과 관리에만 집중할 수 있으며, 인프라 관리는 클라우드 제공자가 대신 담당.
    • 개발자는 주로 웹 애플리케이션을 빠르게 구축하고 배포하는 데 사용.
    • 예: Google App Engine, Microsoft Azure App Service 등



SaaS (Software as a Service)

  • SaaS는 최종 사용자에게 완전한 애플리케이션을 인터넷을 통해 제공하는 모델.
    • 사용자는 애플리케이션을 실행하기 위해 별도의 설치나 설정 없이 웹 브라우저를 통해 접근
    • 모든 인프라와 플랫폼 관리는 클라우드 제공자가 처리.
    • 예: Gmail, Microsoft 365 (예전의 Office 365), Salesforce 등



클라우드 외 컴퓨팅 리소스를 마련하는 방법

  1. On-Premise
    • 실제 데이터 센터 등을 구축
    • 실제 데이터 통신을 위한 모든 물리적인 장비를 설비
  2. Colocation
    • Colocation(코로케이션)은 기업이나 개인이 자체 서버, 네트워크 장비 등의 IT 인프라를 보관하고 운영하기 위해 전문 데이터 센터나 코로케이션 센터의 공간을 임대하는 방법.
    • 사용자는 자체적으로 데이터 센터를 구축하거나 운영하는 비용과 노력을 줄이면서 안정적이고 안전한 환경에서 자신의 IT 장비를 운영할 수 있다.
  3. Hosting
    • 호스팅(Hosting)은 웹사이트, 애플리케이션, 데이터 등을 인터넷에 접근 가능하게 만들기 위해 서버와 관련된 리소스를 제공하는 서비스.
    • 호스팅 서비스를 제공하는 업체는 서버, 스토리지, 네트워크, 보안 등을 관리하여 사용자가 웹사이트나 애플리케이션을 인터넷에서 접속하고 사용할 수 있다.



클라우드 특징

cloudCharater_Procdess
Cloud 특징

  • 규모의 경제에서 얻는 이점
    • 대규모로 서비스를 사용함으로서 클라우드 서비스 제공업체에게서 받는 여러 혜택
  • 빠른 Provisioning 및 유연한 확장
    • 온프레미스 환경보다 훨씬 빠르고 간편한 리소스의 생성 및 확장을 통한 시간 및 비용의 절감
  • 인프라 유지 및 관리에 대한 부담 해소
    • 안정적인 클라우드 사업자의 인프라를 사용
  • 지속적인 기술 혁신 및 적용
    • 지속적인 기술 혁신을 통해 새로운 서비스 상품 사용
  • 손쉬운 가용성 확보
    • 자체 시스템 구축보다 저렴한 가격으로 이용 (단기적)



[AWS] Regions & Availability Zone

[AWS] Regions

Regions : AWS Service가 제공되는 물리적인 위치

Localzone_Procdess
출처: AWSAWS Region / Available Zone

  • 전 세계 31개의 Region이 서로 분리되어 각 Region 단위로 운영.
  • Region 별 서비스 구분을 위한 고유 코드 존재.
    • Region Code Structure : (지역) + (지리적 위치) + (순번)
      • Region Code 예시) : ap-northeast-2
  • Region 별 제공되는 서비스가 다름.



[AWS] Availability Zones

Availability Zones : AWS Region에 배치된 데이터 센터의 그룹.

AZ_Procdess
AWS Availability Zone

  • 1개의 Regiond에는 최소 2개 이상의 AZ(Available Zone : 가용영역)로 구성.
  • 1개의 AZ에는 1개 이상의 데이터 센터로 구성.
  • 각 AZ은 상호 100KM 내외의 거리를 이격하여 구성 : 재난 재해로 인한 동시 다발적 장애 방지
    • AZ 간의 Network는 전용선으로 빠르게 구성
  • AZ 구분을 위한 고유 코드 존재
    • Region Code 구조 (AZ 추가) : (지역) + (지리적 위치) + (순번) + (AZ 코드)
    • Region Code 예시 (AZ 추가) : ap-northeast-2a



[AWS] Cloud Main Services

AwsServices_Procdess
출처: 나라의 IT 잡아먹기AWS Services



[AWS] Services Structure

awsLocating_Procdess
AWS Global Service, Region Service, VPC Service 배치 영역

AWS를 처음 배워 사용하는 입장에서 가장 어려웠던건 위와 같은 각 리소스들의 배치 구조인 것 같다.
시각적 이미지와 함께 머릿속에 그림을 그려가며 공부하면 더 쉽고 빠르게 이해가 될 수 있을 것이라 생각합니다.



ARN(Amazon Resource Name)

  • AWS의 서비스(리소스)를 고유하게 식별하는 이름.



ARN 부여 방식 arn_Procdess
Amazon Resource Name의 부여 방식



[AWS] AWS Well-Architectured Framework

wellArchi_Procdess
출처 : AWS DocAWS가 제시하는 모범 구축 사례

“시스템 설계, 구축, 운영 과정에 활용하기 위한 AWS가 제시하는 모범 사례로서 아키텍쳐 설계, 구축 과정에서 결정이 필요할 때 활용하는 6가지 요소”

  1. 운영 효율성
    • IaC(Infrastructure as Code) 활용
    • 프로세스 개선
    • 롤백 준비
  2. 보안
    • 시스템 접근 기록
    • 데이터 보안
    • 전 계층 (L7) 보안
  3. 안정성
    • 장애 자동 복구 준비(대안)
    • 확장 가능하고 유연한 설계
  4. 성능 효율성
    • 신기술 Prototype
      • EC2 등 계속 버젼이 업된다. (성능이 좋아지거나, 가격이 낮아지거나)
    • 수요 변화에 대응 가능한 설계
  5. 비용 최적화
    • 적합한 리소스 선정
      • 낭비되는 리소스 줄이기
    • 주기적인 비용 분석
  6. 지속 가능성
    • 활용도 극대화
      • 데이터센터를 건축하면 탄소 배출량 증가.
      • AWS에서 관련 방안을 세워 운용하므로 부담 감소
    • 관리형 서비스 활용



[System Architect] 시스템의 확장 과정

한 명의 사용자를 지원하는 시스템에서 수백만의 사용자를 위한 시스템까지 확장하는 과정
  1. DNS Service arc1_Procdess
    DNS Service
    • 소규모 고객 시스템인 경우 최소한의 리소스를 사용하여 구축
    • DNS와 같은 기본 편의 서비스 사용
  2. Service 규모 확장에 따른 DB 분리 arc2_Procdess
    Service 규모 확장에 따른 DB 분리
    • 서비스 규모 확장에 따른 데이터 베이스 분리
      • 사용자가 늘고, 다루는 데이터가 많아질 경우 DB를 분리하여 구성
    • 보안의 추가 / 분리
      • 공인 IP로 접근이 불가능한 사설망으로 분리
    • 서버의 스펙(Resource) 관리
      • DB의 리소스 사용량을 Manage.
  3. 수직적 / 수평적 규모 확장 (Scale up/down & Scale in/out) arc3_Procdess
    수직적 / 수평적 규모 확장 (Scale up/down & Scale in/out)
    1. [Scale up / down] 수직적 규모 확장
      • 서버가 가지고 있는 스펙이 물리적으로 상승
      • 물리적 장비의 스펙업
    2. [Scale in / out] 수평적 규모 확장 (최소 2대 이상)
      • 서버 자체가 여러 대로 증가
      • 어느 정도 이상의 서버가 확보된 후로는 수직적 규모 확장을 하게 된다.
        • 예) 서버 사용자가 1000명이라고 서버를 1000대 생성하지는 않는다.
      • 로드 밸런서의 활용
        • 서버의 확장을 간단하고 빠르게 실행
          • 이전에는 미들웨어에서 일일히 설정값을 지정하여 부하 분산하였음.
    3. 데이터베이스의 확장 / 이중화
      • Replica를 이용, 복제를 통한 확장
      • 복제된 데이터베이스는 Only Read 상태로 복제.
      • Active 상태인 DB가 수시로 Replica들에게 업데이트 된 값을 복사해준다.
        • (K8s의 etcd와 비슷한 맥락)
      • Active 상태인 DB가 동시에 두 개 이상 존재할 수 없는 이유
        • 데이터의 무결성 보장 불가.
          • DB1에서 값을 입력 받았으나 해당 상태가 DB2에게 동기화 되기 전 DB2에서 누군가 값을 읽어 들이면 무결성이 깨지게 됨.
  4. 데이터베이스의 성능 향상을 위한 Cache 전략 arc4_Procdess
    데이터베이스의 성능 향상을 위한 Cache 전략
    • MSA 구조에서 각 서비스 마다의 데이터베이스를 Redis를 통해 연동하여 사용
  5. [Cloud Front(CDN)] 애플리케이션 성능 향상을 위한 캐시 전략 arc5_Procdess
    [Cloud Front] 애플리케이션 성능 향상을 위한 캐시 전략
    • Loadbalancer
    • S3에 존재하는 캐시 데이터를 사용하여 보다 신속한 서비스를 제공
      • 캐시데이터: 변하지 않는 정적인 데이터 (웹 사이트 이미지 등)
  6. [AWS RDB] Stateless Web Layer 구성을 통한 확장성 확보 arc6_Procdess
    Stateless Web Layer 구성을 통한 확장성 확보
    • 세션 관리
    • Stateful : 서버가 세션 데이터(캐시)를 가지고 있는 것
    • Stateless : 서버가 세션 데이터(캐시)를 가지고 있지 않은 것
      • 서버가 세션 데이터에 관여하지 않고 다른 곳에 세션 데이터를 저장해 둔 후 해당 세션 데이터를 가지고 온 객체에게서 적절한 세션 데이터를 가져왔는지 확인 하는 것
    • 세션 데이터(상태 정보) 저장 위치 : EDB, Cache, NoSQL..
  7. [AWS Route53 / Disaster Recovery] 데이터 센터 이중화를 통한 가용성 & 접근성의 확장 arc7_Procdess
    [Disaster Recovery / POP] 데이터 센터 이중화를 통한 가용성, 접근성의 확장
    • 전 세계 사용자 대상 서비스로 확장 시 데이터 센터 이중화
    • [AWS Route53] 근접 지역으로 트래픽이 전달되며 접근성 및 성능의 향상 (Geolocation)
    • [DR / POP] 데이터 센터 장애 시 다른 데이터 센터를 통해 가용성 향상
    • AZ(Availability Zone) 을 통해 지역별 시스템 가용성 확보
  8. 서비스 결합도(응집도)를 낮추기 위한 Message Queue 활용 arc8_Procdess
    서비스 결합도(응집도)를 낮추기 위한 Message Queue 활용
    • 리소스 소모가 큰 프로세스를 비동기 방식으로 처리
    • 메시지 생산자, 소비자 장애 발생에도 이어서 작업 가능
     1. 메시지 발행
 2. 메시지 소비
 3. 처리 결과 입력
 4. 결과 조회
    • FIFO 방식 사용
    • 리소스 소모가 큰 프로세스를 비동기 방식으로 처리
  9. 로그 수집, 모니터링, 자동화 도구 도입 arc9_Procdess
    로그 수집, 모니터링, 자동화 도구 도입
    • 로그 수집, 모니터링 및 자동화 도구 도입
      • 운영 관리 효율, 장애 대응 자동화를 위한 도구 도입
    • DevOps 희망자 필수 관심 요소



[System Architecture] 시스템 개발 환경의 분류

SDEproc_Procdess
시스템 개발 환경의 분류 및 절차

  • Local : 개발자(사용자)의 노트북 / 데스크탑
  • Dev 환경 : 기능 구현을 테스팅 하는 용도
  • Staging 환경 : 서버 및 EKS 등을 Production의 환경과 100% 동일하게 구성.
    • 비용에 구애받지 않고 Test용 Domain을 제외한 모든 환경을 동일하게 구성하여 테스트.
  • QA 환경 : 서비스 기능 동작만 어느정도 비슷하게 할 수 있도록 구성하여 테스트.
    • 실무에서 QA까지 구성하는 경우는 극소수라고 한다.



[AWS] Resource Naming 방식 - kebab

resourcenaming_Procdess
Resource Naming 방식 - Kebab

참고:[가상 면접 사례로 배우는 대규모 시스템 설계 기초 (알렉스 쉬 지음, 이병준 옮김)]

혹시 이해가 안가거나 추가적인 설명이 필요한 부분, 오류 등의 피드백은 언제든지 환영합니다!

긴 글 읽어주셔서 감사합니다. 포스팅을 마칩니다.



처음으로~

Task Lists

  • 클라우드의 개요
  • 클라우드의 유형
  • 클라우드 서비스 모델
  • 클라우드 특징
  • [AWS] Regions & Availability Zone
  • [AWS] Cloud Main Services
  • [AWS] Services Structure
  • [AWS] AWS Well-Architectured Framework
  • [System Architect] 시스템의 확장 과정
  • [System Architecture] 시스템 개발 환경의 분류
  • [AWS] Resource Naming 방식 - kebab

Comments

You May Also Enjoy