새소식

인기 검색어

TL

21/01/06 TL. Introduction to Cloud Computing 3주차, 백준 1929

  • -

오늘 할 일

Introduction to Cloud Computing 3주차 수강 & 정리

인프라 엔지니어 교과서 6 ~ 8장

개발자를 위한 윈도우 셋업 #0 ~ #1

 

내일 할 일

Introduction to Cloud Computing 4주차 수강 & 정리

인프라 엔지니어 교과서 9 ~ 11장

개발자를 위한 윈도우 셋업 #2

 

매일 할 일

1일 1스픽

백준 알고리즘 풀이, 검토


Introduction to Cloud Computing 3주차

 

데이터 센터들은 지역이 격리돼있어서, 하나의 지역에 자연 재해와 같이 영향을 받았다면, 다른 지역에선 클라우드 작업이 계속 실행될 수 있다.
또, 영역을 격리하면서 클라우드의 전반적인 내결함성(운영중이던 시스템의 데이터가 손실되거나 진행중인 작업이 손상되지 않도록 돌발 사태(전원 부족, HW 장애)에 대비할 수 있는 기능)이 향상되고 대기 시간이 줄어들며 단일 공유 실패 지점((공유가) 동작하지 않으면 전체 시스템이 중단되는 요소)이 생성되지 않는다.
클라우드 데이터 센터는 클라우드 인프라가 포함된 창고이다. 이러한 데이터 센터에는 포드, 랙 또는 서버, 스토리지, 네트워킹 장비와 같은 컴퓨팅 리소스들 (물리적 IT 환경의 거의 모든 것)이 포함되어 있다.

컴퓨팅 리소스
클라우드 공급자는 가성 서버, 베어 메탈 서버 및 서버리스 컴퓨팅 리소스 등 여러 컴퓨팅 옵션을 제공한다.
1. 클라우드 데이터 센터의 대부분 서버는 가상 서버 또는 가상 컴퓨터(VM)를 만들기 위해 하이퍼바이저를 실행한다.
2. 베어 메탈 서버는 가상화 되지 않은 물리적 서버이다.
3. 서버리스는 VM의 추상화 계층 컴퓨팅 리소스이다.

저장소
정보 및 데이터는 파일, 코드, 문서, 이미지, 비디오, 백업, 스냅샷, DB로 구성될 수 있고, 클라우드의 다양한 저장소 옵션에 저장할 수 있다.
베어 메탈 서버 및 가상 서버는 기본 스토리지로 로컬 드라이브에 프로비저닝된다.
추가 저장소 옵션이라고 있는데, 이를 이용하면 데이터가 얼마나 중요한지, 데이터에 얼마나 빨리 액세스할 수 있는지, 얼마나 자주 액세스 하는지, 얼마나 안전한지 등과 같은 요소에 따라 다른 저장소를 선택할 수 있다.
이러한 추가 저장소 옵션에는 블록 저장소, 파일 저장소 및 개체 저장소가 포함된다.
1, 2. 블록과 파일 스토리지 모드는 기존 데이터 센터에서 일반적으로 사용되지만, 클라우드의 규모, 성능, 분산 특성에 어려움을 겪는 경우가 많다.
3. 개체, 기타 스토리지는 고도로 분산되고 복원력이 높아 클라우드에서 가장 일반적인 스토리지 모드이다.

네트워킹
클라우드 데이터 센터의 네트워킹 인프라에는 전통적인 네트워크 HW(라우터, 스위치)와 특정 네트워킹 리소스가 가상화 되는 소프트웨어 정의 네트워킹(SDN) 옵션이 포함된다. 또는 API를 통해 프로그래밍 방식으로 사용할 수도 있다.
클라우드의 서버가 프로비저닝 되면 public, private 네트워크 인터페이스를 설정해야 한다. public은 서버를 공용 인터넷에 연결하고, private 인터페이스는 다른 클라우드 인터페이스에 대한 연결을 제공하고, 보안을 유지하는 데 도움을 준다.
물리적 IT 환경에서 처럼, 클라우드 네트워크 인터페이스에는 IP 주소와 서브넷이 자동으로 할당되거나 구성되어야 한다.
클라우드 환경에서는 보안 그룹 및 액세스 제어 목록(ACL)을 설정하여 네트워크 트래픽과 사용자가 리소스에 액세스할 수 있도록 구성하는 것이 중요하다.
클라우드에서 리소스를 더 안전하게 격리하기 위해 대부분의 클라우드 공급자는 VLAN(가상 근거리 통신망), VPC(가상 사설 클라우드망) 및 VPN(가상 사설 네트워크망)을 제공한다.
방화벽, 로드 밸런서, 게이트웨이, 트래픽 분석기 같은 기존 HW 어플라이언스 중 일부는 가상화하고 클라우드에서 서비스로 사용할 수 있다.
클라우드 공급자는 콘텐츠 전송 네트워크(CDN) 이다. 이 것은 콘텐츠를 액세스 하는 사용자가 가장 가까운 지점에서 콘텐츠를 가져와 더 빠르게 액세스 할 수 있도록 콘텐츠를 전 세계 여러 지점에 배포하는 기능이다.

------------

가상화 : 컴퓨팅, 스토리지, 네트워킹, 서버, 애플리케이션 등을 SW 기반 혹은 가상으로 만드는 프로세스. 가상화를 하는 것을 하이퍼바이저라고 한다.
하이퍼바이저는 물리적 서버(유형 1) 또는 호스트 위(유형 2)에서 실행되는 SW이다. 기본적으로 물리적 서버에서 리소스를 가져와 가상 환경에 할당한다.
1. 베어 메탈 하이퍼바이저. 실제 서버 위에 직접 설치 한다. 가장 자주 사용되고 안전하며 지연 시간도 적다. 시장에서 가장 많이 보이는 형태이다. (ex. VMware의 ESCi, MS의 Hyper-V, 오픈소스인 KVM)
2. Hosted 하이퍼바이저. 물리적 서버와 하이퍼바이저 사이에 호스트 OS 계층이 존재한다. 자주는 사용되지 않고, 최종 사용자 가상화에 사용된다. (ex. 오라클, 버추얼박스, VMWare 워크스테이션)

VM은 단순한 SW 기반 컴퓨터이다. 따라서 물리적 컴퓨터처럼 독자적으로 (여러개가)실행된다. OS와 응용 프로그램들이 완전히 독립적이다. 하이퍼바이저는 물리적 서버에서 이러한 가상 환경에 할당되는 리소스를 관리한다.
가상 서버를 한 하이퍼바이저에서 다른 컴퓨터의 다른 하이퍼바이저로 즉시 이동하는 등, 유연성과 이동성이 뛰어나다.

가상화의 이점
1. 비용 절감 : 물리적 인프라 공간을 크게 줄일 수 있고, 유지 관리할 서버의 수를 줄여 비용을 줄일 수 있다.
2. 민첩성과 속도 : 개발자가 테스트 시나리오를 실행할 수 있도록 새 환경을 스핀업하려는 경우 개발자를 위해 완전히 새로운 환경을 프로비저닝 하는 것 보다 훨씬 간단하다. 가상화는 무엇이든간에 프로세스를 훨씬 간단하고 빠르게 만든다.
3. 가동 중지 시간이 줄어든다 : 호스트가 예기치 않게 꺼진다고 해도, 가상 컴퓨터를 다른 물리적 서버에 존재하는 하이퍼바이저로 이동해서 빠르게 백업할 수 있다.
이 이점들로 가상화와 VM은 클라우드 컴퓨팅에 많은 이점들을 제공한다.

------

멀티 테넌트 : 기본 물리적 서버가 가상화되고 다른 테넌트 또는 사용자와 공유됨.

VM은 클라우드 공급자에 따라 가상 서버 또는 가상 인스턴스 또는 인스턴스라고 불린다. 클라우드 공급자들은 VM을 다양한 옵션을 통해 제공한다.
클라우드에서 가상 서버를 생성할 때, 서버를 프로비저닝할 지역 및 영억 또는 데이터 센터와 해당 서버에서 원하는 OS를 지정한다. 공유(멀티 테넌트) VM 혹은 전용(단일 테넌트) VM 중에서 선택할 수 있다.
공유 또는 공용 클라우드 VM은 사전 정의된 크기로 온디맨드 프로비저닝할 수 있는 공급자 관리형 멀티 테넌트 배포이다.
다양한 워크로드를 충족하기 위해 클라우드 공급자는 사전 정의된 크기와 형태의 단일 가상 코어와 다중 가상화 코어들을 위한 소량의 RAM에서부터 대량의 RAM에 이르기 까지 다양한 형태를 제공한다.
예를 들어, 계산 집약적 워크로드, 메모리 집약적 워크로드 또는 고성능 I/O에 대한 구성이 있을 수 있고, 일부 공급자는 사용자가 코어와 RAM 및 로컬 스토리지 수를 정의할 수 있게도 한다.
공용 VM은 일반적으로 1시간당으로 가격이 책정된다. 일부 공급자는 달마다 청구하기도 한다.

transient 또는 spot vm
 클라우드 데이터센터에서 사용되지 않는 용량을 활용한다. 클라우드 공급자는 이런 비활용 용량을 비슷한 크기의 일반 vm보다 훨씬 저렴한 비용으로 내놓는다. 클라우드 공급자는 언제든지 VM을 프로비저닝 해제하고 리소스 회수할 수 있다.
데이터 센터의 용량이 줄어들면 이러한 VM이 손실될 위험이 있어 이러한 VM은 애플리케이션 테스트 또는 개발과 같은 프로덕션이 아닌 워크로드에 적합하다.
상태 비저장 워크로드를 실행하거나, 확장성을 테스트하거나, 저렴한 비용으로 빅데이터 및 고성능(HPC) 워크로드를 실행하는 데 유용하다.

예약된 가상 서버 인스턴스
용량을 예약하고, 향후 배포를 위한 리소스를 보장할 수 있다. 원하는 가상 서버 용량을 예약하고, 필요할 때 해당 용량에서 인스턴스를 프로비저닝하고, 예약 용량에 대해 기간을 선택한다. 장기적으로 커밋하면 시간별 월별 인스턴스에 비해 비용을 절감할 수 있다.
특정 기간 동안 특정 양의 클라우드 용량이 필요한 경우 유용하다. 예약 용량을 초과할 경우 시간별 또는 월별 VM으로 보완하도록 선택할 수 있다.(모든 미리 정의된 제품들을 예약된 대로 사용할 수 있는 것은 아니다.)

전용 호스트
단일 테넌트 격리를 제공. 즉, VM만 지정된 호스트에서 실행되므로 기본 HW 전체 용량과 리소스를 독점적으로 사용할 수 있다.
전용 호스트를 프로비저닝할 때 호스트를 배치할 데이터 센터 및 POD를 지정한 후, 인스턴스 또는 가상 시스템을 특정 호스트에 할당한다. 이를 통해 워크로드 배치를 최대화할 수 있다.
일반적으로 규칙 준수 및 규정 요구 사항을 충족하거나 특정 라이센스 조건을 충족하는 데 사용된다.

-------------------

베어메탈 서버
단일 테넌트 전용 물리적 서버이다. 즉, 단일 고객에게 전념한다는 말이다. 클라우드 공급자는 실제로 물리적 서버를 가져와 고객과 데이터 센터의 랙에 연결한다.
클라우드 공급자는 서버에서 OS까지 관리하는데, HW 또는 랙 연결에 문제가 발생하면 이를 수정하고나 교체한 다음 서버를 재부팅한다.
워크로드를 충족하기 위해 미리 정의된 옵션에 따라 사용자 정의될 수 있다. 여기에는 프로세서, RAM, 하드 드라이브, 특수 구성 요소, OS가 포함된다.
또한 고객은 자체 OS를 설치할 수도 있고, 클라우드 공급자에서 사용할 수 없는 특정 하이퍼바이저를 설치하여 자체 가상 머신 및 팜을 만들 수 있다. GPU를 추가할 수도 있다.
물리적 시스템이라 가상 서버보다 프로비저닝 시간이 오래 걸린다. 미리 구성된 베어 메탈 빌드는 20~40분 정도가 소요되고, 사용자 지정 빌드는 약 3~4시간이 걸릴 수 있다. (클라우드 공급자 마다 다름).
비슷한 크기의 가상 시스템보다 비용이 많이 드는 경향이 있다.
모든 클라우드 공급자가 제공하는 건 아니다.
완벽하게 사용자가 커스터마이즈 할 수 있고, 고도로 안전하고 장기적으로 고성능 사용을 할 수 있는 전용 서버이다. 하이퍼바이저가 필요 없어, 고객은 베어 메탈 서버에 대한 모든 액세스 및 제어 권한을 얻는다.
다른 고객과 기본 서버 HW를 공유하지 않기 떄문에 고성능 컴퓨팅(HPC)와 데이터 집약적 애플리케이션의 까다로운 요구사항을 만족한다.
ERP, CRM, AI, 딥 러닝, 가상화 등에 사용된다.
높은 수준의 보안을 필요로 하는 애플리케이션이나 온프레미스 환경에서 실행한 앱을 사용하는 경우가 좋은 대안이다.
관리 운영과 운영 오버헤드가 추가된다.(비용이 더 든다는 소리)

-------------------

클라우드 네트워크 구축은 온프레미스 데이터 센터에 네트워크를 배포하는 것과 거의 같다. 주요 차이점이라고 한다면 클라우드에서는 물리적 장치가 아닌 네트워킹 요소의 논리적 인스턴스를 사용한다는 것이다.
예를 들어 NIC(Network Interface Controller)는 클라우드 환경에선 vNIC로 표시된다. 클라우드에선 네트워킹 기능이 랙 장착 장치 형태가 아니라 서비스로 제공된다.

클라우드에 네트워크를 만드려면 먼저 네트워크 크기 또는 클라우드 네트워크를 설정하는 IP 주소 범위를 정의한다. 클라우드 네트워크는 VPC를 비롯한 옵션을 사용해 논리적으로 분리된 네트워크 세그먼트인 네트워킹 공간에 배포되며 서브넷이라는 작은 세그먼트로 나뉘어진다.
논리적으로 분할된 클라우드 네트워크는 고객에게 사설 클라우드의 보안과 공용 클라우드의 확장성을 제공한다.
VM 또는 VSI(가상 서버 인스턴스), 스토리지, 네트워크 연결, 로드 밸런서와 같은 클라우드 리소스가 서브넷에 배포된다.
서브넷을 사용하면 온프레미스 환경에서 사용되는 것과 동일한 다중 계층 개념을 사용하여 엔터프라이즈 응용 프로그램을 배포할 수 있다. 서브넷은 클라우드에 보안이 구현되는 주요 영역이기도 하다.
모든 서브넷은 서브넷 수준 방화벽으로 사용되는 ACLS(액세스 제어 목록)로 보호된다. 서브넷 내에서 VSI와 같은 인스턴스 수준에서 보안을 제공하는 보안 그룹을 생성할 수 있다. 서브넷을 구축한 후에는 애플리케이션을 실행할 수 있도록 일부 VSI 및 스토리지를 추가해야 한다.
웹 액세스 VSI, 애플리케이션 계층 VSI, 백엔드 DB VSI가 필요한 3계층 애플리케이션이 있다고 가정해보자. 이 경우 웹에 연결된 VSI를 1번째 보안 그룹, 응용 프로그램 VSI는 2번째 보안 그룹, DB VSI는 3번째 보안 그룹에 배치한다.

퍼블릭 게이트웨이 인스턴스가 네트워크에 추가되어 사용자가 인터넷 계층의 애플리케이션에 액세스할 수 있도록 한다. 퍼블릭 게이트웨이는 클라우드에 대한 인터넷 액세스에 적합하지만 기업은 가상 사설망(VPN)을 사용하여 안전하게 사내 리소스를 클라우드로 확장하는 걸 더 선호한다.
여러 서브넷을 구축하고 여러 워크로드로 배포할 때는 응용 프로그램이 계속 응답할 수 있게 해야 한다. 이는 다양한 애플리케이션에 대한 대역폭의 가용성을 보장하는 로드 밸런서를 통해 달성된다.
하이브리드 클라우드를 사용하는 기업은 클라우드와 온프레미스 리소스 간 전용 고속 연결을 사용하면 공용 연결보다 안전하고 효율적으로 사용할 수 있다.
온프레미스 리소스를 클라우드로 확장할 수 있는 IBM Cloud, Direct Link도 있다. 클라우드 네트워크를 구축하려면 모든 IT 전문가가 환경을 보호하고 고성능 비즈니스 애플리케이션을 보장하기 위해 의존해야 하는 데이터 센터 네트워크와 유사한 네트워킹 기능을 제공하는 일련의 논리적 구조를 생성해야 한다.

---------

컨테이너
데스크톱, 기존IT, 클라우드 등 어디에서나 실행 가능하도록 애플리케이션 코드가 라이브러리와 의존성으로 패키징되는 SW의 실행 가능한 단위이다. 컨테이너는 작고 빠르며 가상 시스템과 달리 모든 인스턴스에 게스트 OS를 포함할 필요가 없으며 호스트 OS의 기능과 리소스를 간단히 활용할 수 있다.

VM 환경
일련의 작업을 스케일아웃한다면, 매번 별도의 게스트 OS와 라이브러리를 사용하고 배포해야 한다. 만약 응용프로그램이 vm과 다른 환경에서 개발되어 프로덕션 환경으로 미렁넣을 때 비호환성이 발생한다면, 로컬에서와 달리 상황이 달라진다.
이러한 상황은 민첩한 DevOps가 CD&CI를 수행하며 해결할 수 있다.

컨테이너 환경
컨테이너 관련된 모든 작업을 수행 후, 푸시하거나 만들 때 3단계 프로세스가 있다.
1. 컨테이너 자체를 설명하는 무언가 (Docker file, manifest channel)
2. 이미지 만들기 (Docker image, ACI, 컨테이너 이미지) - 서로 다른 컨테이너화 기술에 관계 없이 이 프로세스는 동일하게 유지된다.
3. 컨테이너 자체 : 응용 프로그램을 실행하는 데 필요한 모든 런타임, 라이브러리, 바이너리가 포함돼있다. VMS와 매우 유사한 설정에서 실행되지만, 하이퍼바이저 대신 (Docker라면)Docker engine을 가질 것이다. 다른 컨테이너화 기술이라며 다른 (런타임) 엔진
이 과정을 거쳐 컨테이너로 만들면 훨씬 가벼워진다. 따라서 여러 컨테이너를 배포하면, 게스트 OS에 대해 걱정할 필요가 없고, OS 종속성을 모두 복제하고 부풀은 VM을 만들 필요가 없어 리소스를 적게 사용한다.

만약 node.js와 파이썬 응용 프로그램을 사용한다 치고(각각 게스트에서), 그 서비스에 액세스 할 API 역할 서비스를 만든다면 VM에서 이 작업을 수행할 땐 .js 애플리케이션과 python 애플리케이션 모두에서 vm을 만드려고 한다. 내가 사용하고 있는 vm을 계속 사용할 수 있기 때문이다.
그렇지만 이것은 동일한 vm에서 실행 중이라면 수행할 수 없으므로 클라우드 네이티브는 아니다.
클라우드 네이티브라면 이러한 vm 중 하나를 제거하고 python 애플리케이션을 대신 배포해서 해결할 수 있다.
컨테이너 기술은 실행중인 모든 프로세스 간 실제로 공유되는 점이 위대하다. 즉, HW 내에서 실행되는 다른 컨테이너에서 모든 공유 리소스에 액세스할 수 있다.

-------------

클라우드 스토리지
클라우드에 데이터와 파일을 저장하는 곳. 스토리지에 액세스할 땐 컴퓨팅 노드에 연결하거나, 어떤 것은 인터넷 혹은 사설넷을 통해 직접 액세스할 수도 있다.
클라우드 공급자는 클라우드 스토리지 및 관련 인프라를 호스팅, 보호, 관리 및 유지하여 필요할 때 데이터에 액세스할 수 있게 해야 한다.
일반적으로 GB당 기준으로 프로비저닝한 만큼 비용을 지불할 수 있다. 읽기/쓰기 속도에 따라 비용이 달라진다.

1. 직접 연결 스토리지 (DAS)
로컬 스토리지. 클라우드 기반 서버에 직접 제공된다. 호스트 서버 뼈대 내에서 혹은 랙 내에서 효과적으로 제공된다. 빠르고, 일반적으론 OS를 저장하는 데 사용된다. 
임시적이라 연결된 컴퓨팅 리소스에서만 지속된다. 따라서 다른 노드와 공유할 수 없는데다 (RAID를 사용할 순 있지만) 오류 복원 능력이 없어서 다른 용도로는 잘 사용되지 않는다.

2, 파일 스토리지 (NFS)
컴퓨팅 노드에 'NFS스토리지'(Network File System = 스토리지가 표준 이더넷 네트워크를 통해 컴퓨팅 노드와 연결돼있다.)로 제공된다.
NFS 마운트 스토리지는 일반적이지만, 이더넷이라 DAS, 블록 스토리지보다 느리다. 그러나 둘 보다 저렴하다.
한 번에 여러 서버에 마운트하거나 사용할 수 있는 것이 장점이다. 데스크톱 사용자에게 익숙한 계층적 폴더 구조로 데이터를 구성하는 데 적합하기도 하다.

3. 블록 스토리지
고속 섬유 연결을 사용하여 파일 스토리지보다 읽기/쓰기 속도가 훨씬 빠르고 안정적이다. 디스크 속도가 중요한 DB, 기타 애플리케이션에 적합하다.
일반적으로 블록 스토리지를 볼륨에 프로비저닝한 다음 다른 컴퓨팅 노드에 마운트하면 다른 하드 드라이브로 인식된다. 볼륨은 한 번에 하나의 컴퓨팅 노드에만 마운트할 수 있다.

IOPS
초당 입력/출력

지속성
파일 또는 블록 스토리지를 프로비저닝할 떄 사용하는 용어. 연결된 컴퓨팅 노드가 종료되면 스토리지가 지속 설정돼있는 경우 컴퓨팅 노드와 함께 삭제되지 않는다. 즉, 스토리지와 해당 데이터가 보존되어 다른 컴퓨터에 마운트할 수 있지만, 비용이 계속 지불된다.
임시의 경우에는 컴퓨팅 노드와 함께 삭제되도록 한다.

스냅샷
블록 스토리지를 모두 백업하는 방법. 생성 속도가 빠르고 다운타임이 필요하지 않으며, 후속 스냅샷은 데이터에 대한 변경 사항만 기록한다. 개별 파일은 복구할 수 없지만, 특정 스냅샷에 있는 스토리지를 반환하는 방식으로 사용된다.

4. 객체 스토리지
컴퓨팅 노드에 연결되지 않고, API를 통해 액세스된다. 속도가 느리지만, 가장 저렴하고 최종 사용자에겐 크기가 무한하다. 사용한 만큼만 지불하면 된다.
문서, 비디오, 로그, 백업, IoT 데이터, 애플리케이션, 바이너리, 가상 머신 이미지 등 모든 종류의 비정형 데이터 저장소로 사용된다.

-----------------------

파일 스토리지(NFS)
컴퓨팅 노드에 연결되어야 액세스가 가능하다. 비용이 저렴하고, 오류 복원력을 가지며, 전송 중 암호화 및 유휴 상태의 암호화 등 데이터 안정성이 높고, DAS에 비해 사용자의 유지 관리 비용 부담이 적다. 많은 양의 파일 저장소를 프로비저닝하여 서버에 디스크로 제공할 수도 있다.
물리적 디스크는 다른 곳에 존재하는데, 데이터 센터의 기본 인프라를 통해 컴퓨팅 노드에 연결된다. 이더넷을 통해 마운트된다.(Network File Storage)
이더넷의 문제는 클라우드 제공업체에서 많은 양의 트래픽을 처리할 수 있도록 스토리지 네트워크를 구축하더라도 속도가 다를 수 있다는 것이다. 따라서 지속적으로 높은 네트워크 속도가 필요하지 않는 워크로드에 사용된다.
일반적으로 한 번에 둘 이상의 컴퓨팅 노드에 마운트될 수 있는데, 마운트된 디스크 또는 볼륨은 컴퓨팅 노드의 다른 드라이브처럼 보인다. 따라서, 부서별 파일 공유 등에 사용된다.
파일 스토리지를 프로비저닝할 때는 스토리지의 IOPS(디스크의 읽고 쓰기 속도. 스토리지와 컴퓨팅 노드 간의 네트워크 속도가 아니다.) 용량을 고려해야 한다.

블록 스토리지
파일을 데이터 청크(블록)으로 나누고 각 블록을 고유한 주소로 별도 저장한다. 컴퓨팅 노드에 연결해야 한다. 원격 스토리지 어플라이언스에서 마운트할 수 있어 장애에 대한 복원력이 매우 뛰어나고, 암호화 서비스를 통해 데이터를 안전하게 유지할 수 있다.
전용 광섬유 네트워크를 사용하여 노드를 계산하는 볼륨이 장착되어 있다. 광섬유라서 가격대가 높다. 그러나 트래픽이 더 빠르고 속도 일관성을 유지하므로 짧은 지연시간을 요구하는 워크로드에 적합하다. (DB, 메일 서버)
일반적으로 한 번에 하나의 컴퓨팅 노드에만 마운트된다. 따라서 컴퓨팅 노드 간 일정한 디스크 공유가 필요한 워크로드엔 적합하지 않다.
IOPS 용량을 고려해야 한다. 대부분의 클라우드 공급자는 스토리지를 프로비저닝할 때 IOPS 특성을 지정할 수 있다.

개체 스토리지
특정 컴퓨팅 노드에 연결하지 않고, API를 통해 데이터를 관리한다. 즉, API를 호출할 수 있는 모든 항목에 개체 저장소를 직접 사용할 수 있다. 비용이 저렴하다. 사실상 무한하다.
대량의 구조화되지 않은 데이터를 저장하는 데 적합하다. 디렉토리 구조에 저장되지 않는다는 의미이다. '버킷'이라는 폴더 비슷한 걸 사용하는데, 이름을 지정할 수 있고, 버킷 내에 버킷을 배치할 수는 없다.
객체가 버킷에 배치되면 객체 ID와 같은 일부 메타데이터(데이터에 대한 데이터)가 추가된다. 이 메타데이터를 사용해 응용프로그램이 개체를 찾고 액세스하고, 데이터가 저장되거나 마지막으로 액세스된 시간에 대한 정보를 얻을 수 있다. 버킷을 만들 땐 크기를 정할 필요가 없다. 
서비스 공급자는 복원력과 개체 저장소의 가용성이 높은지 확인해야 한다. 일부 클라우드 공급자는 다양한 수준의 복원력을 갖춘 여러 유형의 버킷을 제공한다. (ex. 탄력적이고 1개의 데이터 센터에 저장되는 버킷, 여러 데이터 센터에 (여러번) 저장되는 버킷 ...)
편평한 구조를 가지며, 모든 데이터 타입을 저장할 수 있다. 정적이며 빠른 읽기/쓰기 속도가 필요하지 않은 데이터에 적합하다. 그러나 OS를 실행하거나 DB와 같은 애플리케이션이나 파일 내용이 변경되는 곳엔 적합하지 않다.
공급자에 따라 버킷에 대해 요금이 다르다. 일부는 복원력과 가용성을 기반으로 책정하는데 반해, 다른 일부는 내부 개체에 액세스하는 빈도를 기반으로 한다.

객체 스토리지 버킷에는 스토리지 계층 또는 클래스가 연결돼있고, 이러한 계층은 데이터에 액세스 하는 빈도에 따라 결정된다.
데이터에 대한 자동 보관 규칙을 설정해, 특정 기간 동안 객체에 액세스 하지 않으면 자동으로 저렴한 스토리지 계층으로 이동하도록 설정할 수 있다. 메타데이터를 이용한다.
개체 스토리지에는 IOPS 옵션이 제공되지 않는다. 데이터 검색과 관련된 비용이 있기도 한다. 저렴한 스토리지의 경우 검색 비용이 더 높을 수 있다.

표준 계층 버킷
자주 액세스하는 객체를 저장하는 곳. 비용이 가장 많이 든다.

아카이브 계층(Vault)
한 달에 1~2번 이하에만 액세스되는 문서를 저장. 비용이 상대적으로 적게 든다.

콜드 볼트 계층(cold vault)
일년에 1~2번만 액세스된다. 가격이 매우 적게 든다.

가장 일반적인 API는 AWS에서 제공하는 S3 API이다. 따라서 많은 공급자들이 S3와 호환되는 객체 스토리지에 API를 제공한다. API 자체는 HTTP 기반의 RESTful API 또는 RESTful웹서비스이다. API 호출을 통해 애플리케이션이 객체 스토리지와 버킷을 관리하고, 가져오거나 업로드/다운로드 할 수 있다.
백업 솔루션으로 오프사이트 테이프 기반 솔루션을 적용하여 데이터 회복 시간을 단축할 수 있다. 많은 백업 패키지에 개체 스토리지를 사용하여 클라우드로 데이터를 백업하는 기능이 포함되어 있다.
개체 스토리지는 테이프 백업 솔루션보다 효율적이다.

콘텐츠 전송 네트워크 (CDN)
사용자의 위치에 따라 웹 사이트 콘텐츠의 임시 저장되거나 캐시된 복사본을 사용자에게 전달하는 분산 서버 네트워크. 주요 이점은 웹사이트를 빠르게 만든다는 것이다.
CDN을 호스팅된 서버에서 거리가 먼 사용자들 바로 인접하게 설치해서, 멀리 있는 사용자가 콘텐츠에 액세스를 요청하면 가까운 지리적 위치에서 직접 콘텐츠를 검색하여 검색 시간을 크게 줄일 수 있다.
이러한 방법은 사용자들의 서비스 속도를 줄일 뿐만 아니라, 호스팅하는 서버의 트래픽 양이 줄기 때문에 부하가 감소한다는 것이다. 또한, 직접 통신하지 않기 때문에 보안도 강화된다.


백준 1929번

 

내 풀이

import sys


def run():
    line = sys.stdin.readline().split()
    M, N = [int(x) for x in line]
    eratos, result = list(), list()

    for i in range(2, N + 1):
        eratos.append(i)

    for i in eratos:
        if i >= M:
            result.append(i)
        tmp = N // i
        tmp2 = i
        for j in range(1, tmp):
            tmp2 += i
            if tmp2 in eratos:
                eratos.remove(tmp2)

    for i in result:
        print(i)


if __name__ == '__main__':
    run()

ko.wikipedia.org/wiki/%EC%97%90%EB%9D%BC%ED%86%A0%EC%8A%A4%ED%85%8C%EB%84%A4%EC%8A%A4%EC%9D%98_%EC%B2%B4

 

에라토스테네스의 체 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 수학에서 에라토스테네스의 체는 소수를 찾는 방법이다. 고대 그리스 수학자 에라토스테네스가 발견하였다. 알고리즘[편집] 2

ko.wikipedia.org

를 참고해서 그림에서 보여주는 대로 작업하려고 했다. M에서 N까지 모두 채워준 다음, 소수가 아닌 것들을 지워주려고 했다. 그런데 이 방법은 시간 초과가 발생했다. 아무래도 append와 탐색한 후 remove를 반복하고 조건을 따지는 이 부분들에서 연산을 많이 하는 듯 싶다.

 

수정한 코드

import sys


def run():
    M, N = sys.stdin.readline().split()
    M, N = int(M), int(N) + 1

    # 에라토스테네스의 체 초기화: n개 요소에 True 설정(소수로 간주)
    eratos = [True] * N
    eratos[0], eratos[1] = False, False

    # n의 최대 약수가 sqrt(n) 이하이므로 i=sqrt(n)까지 검사
    m = int(N ** 0.5)
    for i in range(2, m + 1):
        if eratos[i] == True:           # i가 소수인 경우
            for j in range(i+i, N, i): # i이후 i의 배수들을 False 판정
                eratos[j] = False

    # 소수 목록 산출
    result = [i for i in range(M, N) if eratos[i] == True]

    for i in result:
        print(i)


if __name__ == '__main__':
    run()

여기서 배운건 list * int로 어떠한 배열을 복사해서 넣을 수 있다는 것과, list[a:b] = c 이런 문법이 안 된다는 것,

range(a, b, c)일 땐 a부터 b까지 c 간격마다 라는 것이다. 또, [for]를 사용할 때, if문을 넣어서 거를 수 있다는 것도 배웠다. 나는 값들을 넣어서 해결하려고 했는데, 여기선 어차피 index와 값이 같다는 걸 이용해서 t/f로 해결할 수 있게 했다. 이러면 append 혹은 remove할 필요도 없고, 탐색할 필요도 없다. 또, 선언할 때 일일이 append할 게 아니라, [for]를 사용해서 간결하고 효과적으로 할당할 수도 있다는 걸 배웠다.

'TL' 카테고리의 다른 글

21/01/09 TL. 백준 4948  (0) 2021.01.09
21/01/08 TL.  (0) 2021.01.08
21/01/05 TL. Introduction to Cloud Computing 2주차  (0) 2021.01.05
20/12/30 TL.  (0) 2020.12.30
20/12/29 TL. 백준 16507, Introduction to Cloud Computing 1주차  (0) 2020.12.29
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.