사용자는 언제든지 필요할 때 마다 네트워크를 통해 CPU와 Disk에 접근 가능.
언제 어디서든 필요한만큼 사용 가능.
그것이 어디에 있는지 어떻게 생겼는지 알 필요가 없음.
InfraStructure - Compute(CPU), Block Storage (HDD, SSD, RAM 등), 네트워크
-> 물리적인 요소들
PlatForm - 데이터베이스, 깃헙, 0과1의 조합이 아닌 오브젝트 스토리지 등 ( 주로 개발자가 사용하는 미들웨어, 데이터베이스, 툴, 프레임 워크 등 )
Application - 일반인들이 사용하는 소프트웨어 (지메일, 유튜브, 넷플릭스 , 학교 웹 메일 등 )
Reference: https://upload.wikimedia.org/wikipedia/commons/b/b5/Cloud_computing.svg
어딘가에 있지만 눈에 보이지 않음 -> " Ubiquitous "
개발자 혹은 서스 운영자는 본인의 랩탑이나 컴퓨터로 쉽게 접속 가능 -> " Convenient "
필요한 CPU, 디스크, 네트워크에 대한 용량을 필요할 때 즉각 요청 가능 -> " On Demand "
필요할 때 쓰고 쓰지 않을 때에는 다른 사람들이 사용 -> " Shared Pool "
중요한건, 내가 직접 구매해서 소유하는 개념이 아니라 빌려쓴다는 개념임.
클라우드 컴퓨팅에서 빌려쓰는건 크게 2가지.
1) 일반인들이 사용하는 구글 캘린더 , 지메일과 같은 소프트웨어 서비스.
2) 개발자 관점에서의 내가 필요한 하드웨어, 소프트웨어.
필요할 때 필요한 서비스나 하드웨어, 기타 자원을 필요한 만큼 빌려 쓰는 것이고, 데이터 센터는 이러한 서비스가 가능하도록 하기 위하여 하드웨어 인프라나 소프트웨어를 의미한다.
< 장점 >
Public Clouds
구글이나 아마존과 같은 대형 CPU, 디스크를 보유한 곳으로부터 사용자가 필요할 때 필요한만큼 빌려쓰는걸 뜻함.
< 장점 >
1) 무한한 만큼 빌려쓸 수 있는점
2) 초기에 사용하지 않더라도 지불해야 할 최소 금액이 없다는 점.
3) 필요할 때 필요한 만큼 사용하고 지불하면 된다는 점.
4) Pooling Effect -> 각각 컴퓨터가 흩어져 있으면 사용할 때 / 사용하지 않을 때가 각각 달라서 효율이 떨어지지만 한군데 모아놓으면 더 적은 수의 컴퓨터로도 운용이 가능해지고 즉 효율 상승, 비용 감소.
5) 개발하고자 하는 소프트웨어에 요구시되는 환경이 다르더라도 이미 가지고 있는 컴퓨터 안에서 지원가능.
(운영, 장비 관리, 효율성 측면에서 좋음)
1) 필요할 때 필요한 만큼 사용 가능 -> "On Demand"
2) 언제 어디서든 접근 가능해야 하므로 네트워크 연결 필요 -> "Broad network access"
3) 한정된 자원 내 효율적 사용 -> "Resouce Pooling "
4) 요구에 대한 빠른 반응 속도 -> "Rapidly Elasicity"
5) 정확한 비용 청구 -> "Measured Servcie"
특정 부분만큼 소프트웨어가 클라우드 컴퓨터에게 요청 시 사람의 개입없이 해당 요구만큼 자원을 할당해주는 것. (자동화 인터페이스)
빠른 네트워크.
데이터 센터 안/밖의 연결의 네트워크 연결은 초고속으로 이루어짐.
데이터센서 안에 있는 컴퓨터들은 고성능, 대용량 컴퓨터임.
내가 정확하게 필요로 하는 만큼의 리소스(CPU, 디스크) 만 사용 가능함.
하지만, 그만큼 내가 어느정도로 필요로 하는지 스스로 알고 있어야함.
서비스가 끊어지지 않도록 공급받을 수 있는 빠른 속도.
Source: Mell P, Grance T. The NIST definition of cloud computing.
위와 같은 경우에는 절반은 시스템이 사용되지만 절반은 사용되지 않는 경우가 있는 상황.
Source: Mell P, Grance T. The NIST definition of cloud computing
처음의 예측을 넘어서 시스템 이상의 요청이 있는 상황 ( = Underprovisioning )
서비스 불능 상태.
Source: Mell P, Grance T. The NIST definition of cloud computing.
3일차에는 문제가 없으나 1,2일차에는 요구량이 기존의 수용량을 넘어서는 상황 (수강신청, 마스크 구매 사이트 방문 상황 )
같은 회사 안에서라도 누가 얼마만큼 썻는지 측정가능 해야함.
자등으로 얼마만큼 리소스를 사용했는지 모니터링 가능해야함.
특정 리소스에 대한 요구가 있을 시 공급받을 수 있어야함.
1) Software as a Service (Saas)
-> 고객을 대신하여 소프트웨어,데이터베이스 제공/관리 서비스 즉, 특정 기능/서비스를 제공하는 소프트웨어 ( MS365, Gmail, google Docs )
2) Platform as a Service (Paas)
-> 응용프로그램을 개발할 때 필요한 플렛폼 제공 서비스 (OS, 미들웨어, 런타임)
3) Infrastructrue as a Service (Iaas)
-> 컴퓨팅 파워 운영체제 (CPU, Disk, Network)를 제공해주는 서비스(AWS EC2, Windows Azure )
Private cloud : 회사 자체적으로 클라우드 컴퓨팅 후 구성원들끼리 나눠 사용
-> 보완 확실
-> 자신들의 회사 서비스에 최적화된 컴퓨터 인프라이므로 성능을 최대화 가능.
-> 높은 신뢰성
-> 하지만, IT기업이 아니라면 장점이 단점이 될 수 있는 양날의 검 존재.
Public cloud : 제3자의 리소스를 빌려쓰는 것.
-> 높은 확장성
-> 사용한 만큼만 지불 가능
Community cloud : Private Cloud + 다른 회사의 클라우드 (신뢰 관계 형성이 된 기관)
-> 서로 대가를 지불 하지 않음
-> 주로 관공서 끼리 형성
Hybrid cloud : Private 와 Public의 중간 단계.
-> 임시적인 순간에만 보안의 문제 없이 외부 리소스 활용
1) Availability / Business Continuity
-> 특정 회사에 대한 지속적인 신뢰성에 대한 여부
2) Data Lock-In
-> 이미 특정 회사의 서비스에 너무 많이 엮여 변경 시 많은 지출 발생
3) Data Confidentiality and Auditability
-> 회사의 보안 문제
4) Data Transfer Bottlenecks
-> 데이터의 원할한 송/수신 문제
5) Performance Unpredictability
-> 성능의 예측 가능성
6) Scalable Storage
-> 저장 공간의 확장성에 대한 여부
7) Bugs in Large Distributed System
-> 버그 문제로 인한 완성도 문제
8) Scaling Quickly
-> 용량 확장 시 많은 시간 소요
9) Reputation Fate Sharing
-> 특정 문제 발생 시 연쇄 반응
10) Software Licensing
-> 라이센스 법적 문제, 비용
Cloud computing app development is transforming the way software solutions are designed and deployed, offering flexibility, scalability, and efficient resource management. It enables businesses to innovate faster and adapt to changing demands seamlessly. For more detailed information on this topic, visit https://www.cleveroad.com/blog/cloud-application-development/