IT 위키 - 사용자 기여 [ko]

클라우드 NAS 제품군

2023-08-28T02:24:33Z

클라우더: 새 문서: 상용 '''클라우드 서비스 제공자(CSP)'''들에서 제공하는 NAS 역할을 하는 스토리지에 대해 다룬다. 정확히 NAS라고 판매하는 경우는 많지 않기 때문에 NAS로 사용 가능한 모든 스토리지에 대해 다루며, 일반적인 NAS와 가장 유사한 기능이 있는 제품을 상위에 위치시킨다. 기본적으로 '''NFS'''가 제공이 되어야 포함될 수 있다. == Am...

상용 [[클라우드 서비스 제공자|'''클라우드 서비스 제공자(CSP)''']]들에서 제공하는 NAS 역할을 하는 스토리지에 대해 다룬다. 정확히 NAS라고 판매하는 경우는 많지 않기 때문에 NAS로 사용 가능한 모든 스토리지에 대해 다루며, 일반적인 NAS와 가장 유사한 기능이 있는 제품을 상위에 위치시킨다. 기본적으로 [[리눅스 NFS|'''NFS''']]가 제공이 되어야 포함될 수 있다.

== Amazon Web Service ==
AWS에서 제공하는 NAS용 스토리지

=== EFS ===

* Azure Files에 대응되는 기본 NAS 제품
* NFS가 기본적으로 제공되며 SMB를 사용하고자 하는 경우 DataSync라는 추가 서비스 사용 필요

=== S3 ===

* Object Storage이다. 일반적으로 NAS 용도는 아니지만 NFS가 지원되므로 NAS로 사용 가능하다.

== MS Azure ==
애저에서 제공하는 NAS용 스토리지

=== Azure Files ===

* AWS EFS에 대응되는 기본 NAS 제품
* SMB가 기본적으로 제공되며 프리미엄 제품군부터 NFS가 제공된다.

=== Blob Storage ===

* Object Storage이다. 일반적으로 NAS 용도는 아니지만 NFS가 지원되므로 NAS로 사용 가능하다.

=== Data Lake Storage ===

* Blob을 기반으로 한 Object Storage이다. 일반적으로 NAS 용도는 아니지만 NFS가 지원되므로 NAS로 사용 가능하다.

== Google Cloud Platform ==
GCP에서 제공하는 NAS용 스토리지

AWS CPU 버스트

2023-02-04T09:52:01Z

클라우더:

AWS CPU 버스트란 AWS의 서버 자원에서 CPU 사용률이 일정 수준 이상 올라가지 못하도록 제한하는 정책이 있는데, CPU 사용률이 기준치 이상을 초과하는 것을 CPU 버스트라고 한다.

* CPU 버스트가 지속되면 서비스 성능에 제약이 가해지거나 초과 비용이 부과될 수 있다.

== 예시 ==
'''기준치가 10%로 제한된 서버는 CPU 사용률이 10% 이상 넘어가면 CPU 버스트 상태'''인 것인데, 일반적으로 CPU 사용률이 10%를 넘어간다고 해서 서버에 문제가 생기는 것은 아니나 이를 허용하지 않는다. 일정 시간 이상 CPU 버스트 상태가 지속되면 제약이 가해진다. 대략 아래와 같은 규칙이다.

* CPU가 기준치 보다 낮게 유지되면 낮은 만큼 크레딧이 쌓인다.
* 크레딧은 누적 한도가 있다. 한도만큼 쌓고 나면 CPU가 낮게 유지되어도 더이상 쌓이지 않는다.
* CPU가 기준치를 초과하면 초과한만큼 크레딧이 사용된다.
* CPU가 기준치를 잠깐씩 초과한다면 크레딧이 조금 사용됐다가 금방 다시 복구된다.
* 하지만 CPU가 기준치를 오랫동안 초과하거나 자주 초과한다면 크레딧이 쌓이지 않고 계속 소모만 되거나, 크레딧이 쌓이는 속도보다 소모되는 속도가 더 빨라진다.
* 크레딧이 0이 되면 CPU 성능이 제한되거나 초과 비용이 발생하기 시작한다.
<gallery perrow="2">
파일:AWS CPU Burst Chart Example.png|며칠동안 기준치(점선)가 초과된 모습
파일:AWS CPU Burst Capacity Run-out Example.png|기준치가 초과한 날 부터 점점 소진되는 허용량
</gallery>

== 이유 및 한계 ==
가상화 공유 자원을 운용하는 클라우드 특성상 CPU가 1% ~ 100%를 넘나들며 사용량이 예측불가능한 서버들이 많아지게 되면 해당 가상서버가 아닌 물리적 자원을 공유하는 다른 서버에도 영향을 줄 수 있다. 그래서 CPU 사용률이 5~20% 이내로 유지되는 수준으로 서비스를 운영하고, 이를 넘어설 정도로 서비스가 커진다면 그에 걸맞는 높은 용량의 서버를 사용하도록 하는 것이다. 그래도 피크 시간대나 특정 작업에서 CPU가 많이 사용될 수 있으므로, 어느정도의 CPU 초과는 허용해주되, 많이는 초과하지 말라는 것이다.

정석대로라면 평균 CPU 사용률이 20%를 넘어가는 것은 바람직하지 않으므로, 바람직한 서버 운영을 도모한다고 볼 수도 있으나. 기존에 서버를 직접 운영하거나 가상서버 호스팅을 사용했을 떄에 비하면 사용자 입장에서 상당히 큰 제약이다. 기존엔 비수기엔 CPU가 1~2%대로 유지되다가 성수기나 이벤트 시기엔 20~30%정도로 몰릴 수도 있는데 그렇다고 서버거 과부화로 죽는 상황까진 이르지 않는다. 하지만 AWS의 이런 제약 아래선 성수기에 CPU가 높은 수준으로 며칠 이상 유지될 경우 CPU 버스트 크레딧이 모두 소진되어 갑자기 CPU 성능이 급감하고, 특정 서버의 성능이 급감을 하게 되면 연쇄적인 시스템 장애로 번질 수 있다. 실제로 이런 사고를 한번 겪고 나서 CPU 버스트에 대해 알게 되는 경우도 많다.

사용자는 당연히 CPU의 100%를 사용할 수 있을 것이라 생각하고 서비스를 신청했는데 실제로는 CPU의 10~20%밖에 못쓰도록 제한이 있는 것이니 과대포장 같은 느낌이기도 하다.

== 비판 ==
'''불가피한 조치인가 상술인가'''

하이버파이저 가상화를 잘만 운영하면 특정 가상환경에서 발생하는 부하가 다른 환경에 번지지 않도록 차단하는 것이 불가능한 것도 아니다. 그런데도 그런 운영능력 부족으로 이렇게 사용자에게 사고를 유발하고 필요보다 더 큰 용량의 서버 인스턴스를 구매하여 사용하도록 하는 것은, 안정성 유지라는 허울 좋은 핑계로 사용료를 더 받겠다는 상술에 불가능하다는 견해가 있다.

'''미리 제대로 공지하였는가'''

CPU 버스트에 대해선 조금만 검색하면 나오긴 하지만 CPU 버스트라는 이름만으로 이런 제한 정책을 미리 예측하긴 어렵다. 분명히 CPU 버스트에 대한 매뉴얼이 있긴 할지라도 서버 인스턴스를 신정하는 과정에서 이에 대한 경고나 안내가 명확하게 나오는 것은 아니다. 클라우드에 익숙한 많은 사용자는 기존에 안정적으로 운영해왔던 성능으로 인스턴스를 구성할 것이나 AWS의 이런 제약으로 전혀 예상치 못한 사고를 겪에 된다.

== 핵심 개념 및 정의 ==

; CPU 사용률
: CPU 사용률은 인스턴스에서 현재 사용 중인 할당된 EC2 컴퓨팅 유닛의 비율(%)입니다. 이 지표는 인스턴스에서 사용되고 있는 할당된 CPU 사이클의 비율을 측정합니다. CPU 사용률 CloudWatch 지표는 코어당 CPU 사용량이 아니라 인스턴스당 CPU 사용량을 나타냅니다. 인스턴스의 기준 CPU 사양도 인스턴스당 CPU 사용량을 기준으로 합니다. AWS Management Console 또는 AWS CLI를 사용하여 CPU 사용률을 측정하려면 특정 인스턴스에 대한 통계 가져오기 섹션을 참조하세요.
; CPU 크레딧
: vCPU 시간의 단위입니다. 예: CPU 크레딧 1개 = vCPU 1개 * 100% 사용률 * 1분 CPU 크레딧 1개 = vCPU 1개 * 50% 사용률 * 2분 CPU 크레딧 1개 = vCPU 2개 * 25% 사용률 * 2분
; 기준 사용률
: 기준 사용률은 획득하는 CPU 크레딧 수가 사용 중인 CPU 크레딧 수와 일치할 때 순 크레딧 밸런스 0에서 CPU를 사용할 수 있는 수준입니다. 기준 사용률을 기준이라고도 합니다. 기준 사용률은 vCPU 사용률의 백분율로 표시되며 기준 사용률(%) = (획득한 크레딧 수/vCPU 수)/60분으로 계산됩니다. 각 버스트 가능한 성능 인스턴스 유형의 기준 사용률은 크레딧 표를 참조하세요.
; 획득 크레딧
: 인스턴스가 실행 중일 때 지속적으로 적립되는 크레딧입니다. 시간당 적립되는 크레딧 수 = 기준 사용률(%) * vCPU 수 * 60분 예: vCPU가 2개인 t3.nano는 기본 사용률이 5%로, 시간당 6 크레딧을 획득하며, 다음과 같이 계산됩니다. vCPU 2개 * 5% 기준 * 60분 = 시간당 6 크레딧
; 소비 또는 사용되는 크레딧
: 인스턴스가 실행 중일 때 지속적으로 소비되는 크레딧입니다. 분당 소비되는 CPU 크레딧 = vCPU 수 * CPU 사용률 * 1분
; 획득한 크레딧
: 인스턴스가 기준 사용률에 필요한 것보다 적은 크레딧을 사용하는 경우 사용되지 않은 CPU 크레딧입니다. 즉, 획득한 크레딧 = (적립되는 크레딧 - 기준 미만으로 사용되는 크레딧)입니다. 예: t3.nano가 한 시간 동안 5% 기준보다 적은 2% CPU 사용률로 실행될 경우 획득한 크레딧은 다음과 같이 계산됩니다. 획득한 CPU 크레딧 = (시간당 적립되는 크레딧 - 시간당 소비되는 크레딧) = 6 - 2 vCPU * 2% CPU 사용률 * 60분 = 6 - 2.4 = 시간당 획득한 크레딧 3.6입니다.
; 크레딧 누적 한도
: 인스턴스 크기에 따라 다르지만 일반적으로 24시간 동안 적립되는 최대 크레딧 수와 같습니다. 예: t3.nano의 경우 크레딧 누적 한도 = 24 * 6 = 144 크레딧입니다.
; 시작 크레딧
: 표준 모드로 구성된 T2 인스턴스에만 적용됩니다. 시작 크레딧은 새 T2 인스턴스에 할당되는 제한된 수의 CPU 크레딧으로, 표준 모드로 시작할 때 기준 이상으로 버스트할 수 있습니다.
; 잉여 크레딧
: 획득한 크레딧 잔액이 소진된 후 인스턴스가 소비하는 크레딧입니다. 잉여 크레딧은 버스트 가능 인스턴스가 오랜 기간 동안 고성능을 유지할 수 있도록 고안되었으며 무제한 모드에서만 사용됩니다. 잉여 크레딧 잔액은 인스턴스가 무제한 모드에서 버스트하기 위해 소비한 크레딧 수를 확인하는 데 사용됩니다.
; 스탠다드 모드
: 크레딧 구성 모드로, 크레딧 잔액에 적립된 크레딧을 사용하여 인스턴스를 기준 이상으로 버스트할 수 있습니다.
; 무제한 모드
: 크레딧 구성 모드로, 필요할 때마다 원하는 기간 동안 높은 CPU 사용률을 유지하여 인스턴스를 기준 이상으로 버스트할 수 있습니다. 24시간 동안 또는 인스턴스 수명(더 짧음) 동안 인스턴스의 평균 CPU 사용률이 기준 이하인 경우에 모든 CPU 사용량 급증에 대해 시간당 CPU 인스턴스 요금이 적용됩니다. 인스턴스 실행에 장기간 높은 CPU 사용률이 필요한 경우, vCPU-시간당 추가 고정 요금으로 인스턴스를 실행할 수 있습니다.

== 인스턴스별 기준 ==
{| class="wikitable"
!인스턴스 유형
!시간당 지급되는 CPU 크레딧
!누적 가능한 최대 지급된 크레딧*
!vCPU***
!vCPU당 기준 사용률
|-
|T2
|
|
|
|
|-
|<code>t2.nano</code>
|3
|72
|1
|5%
|-
|<code>t2.micro</code>
|6
|144
|1
|10%
|-
|<code>t2.small</code>
|12
|288
|1
|20%
|-
|<code>t2.medium</code>
|24
|576
|2
|20%**
|-
|<code>t2.large</code>
|36
|864
|2
|30%**
|-
|<code>t2.xlarge</code>
|54
|1296
|4
|22.5%**
|-
|<code>t2.2xlarge</code>
|81.6
|1958.4
|8
|17%**
|-
|T3
|
|
|
|
|-
|<code>t3.nano</code>
|6
|144
|2
|5%**
|-
|<code>t3.micro</code>
|12
|288
|2
|10%**
|-
|<code>t3.small</code>
|24
|576
|2
|20%**
|-
|<code>t3.medium</code>
|24
|576
|2
|20%**
|-
|<code>t3.large</code>
|36
|864
|2
|30%**
|-
|<code>t3.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t3.2xlarge</code>
|192
|4608
|8
|40%**
|-
|T3a
|
|
|
|
|-
|<code>t3a.nano</code>
|6
|144
|2
|5%**
|-
|<code>t3a.micro</code>
|12
|288
|2
|10%**
|-
|<code>t3a.small</code>
|24
|576
|2
|20%**
|-
|<code>t3a.medium</code>
|24
|576
|2
|20%**
|-
|<code>t3a.large</code>
|36
|864
|2
|30%**
|-
|<code>t3a.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t3a.2xlarge</code>
|192
|4608
|8
|40%**
|-
|T4g
|
|
|
|
|-
|<code>t4g.nano</code>
|6
|144
|2
|5%**
|-
|<code>t4g.micro</code>
|12
|288
|2
|10%**
|-
|<code>t4g.small</code>
|24
|576
|2
|20%**
|-
|<code>t4g.medium</code>
|24
|576
|2
|20%**
|-
|<code>t4g.large</code>
|36
|864
|2
|30%**
|-
|<code>t4g.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t4g.2xlarge</code>
|192
|4608
|8
|40%**
|}

파일:AWS CPU Burst Capacity Run-out Example.png

2023-02-04T09:49:32Z

클라우더:

CPU 버스트 가능 용량 소진한 예시

파일:AWS CPU Burst Chart Example.png

2023-02-04T09:49:00Z

클라우더:

CPU 버스트 기준치 초과한 모습

AWS CPU 버스트

2023-02-04T09:44:46Z

클라우더: 새 문서: AWS CPU 버스트란 AWS의 서버 자원에서 CPU 사용률이 일정 수준 이상 올라가지 못하도록 제한하는 정책이 있는데, CPU 사용률이 기준치 이상을 초과하는 것을 CPU 버스트라고 한다. * CPU 버스트가 지속되면 서비스 성능에 제약이 가해지거나 초과 비용이 부과될 수 있다. == 예시 == '''기준치가 10%로 제한된 서버는 CPU 사용률이 10% 이상 넘어가면 CPU 버스트 상태'''인 것인...

AWS CPU 버스트란 AWS의 서버 자원에서 CPU 사용률이 일정 수준 이상 올라가지 못하도록 제한하는 정책이 있는데, CPU 사용률이 기준치 이상을 초과하는 것을 CPU 버스트라고 한다.

* CPU 버스트가 지속되면 서비스 성능에 제약이 가해지거나 초과 비용이 부과될 수 있다.

== 예시 ==
'''기준치가 10%로 제한된 서버는 CPU 사용률이 10% 이상 넘어가면 CPU 버스트 상태'''인 것인데, 일반적으로 CPU 사용률이 10%를 넘어간다고 해서 서버에 문제가 생기는 것은 아니나 이를 허용하지 않는다. 일정 시간 이상 CPU 버스트 상태가 지속되면 제약이 가해진다. 대략 아래와 같은 규칙이다.

* CPU가 기준치 보다 낮게 유지되면 낮은 만큼 크레딧이 쌓인다.
* 크레딧은 누적 한도가 있다. 한도만큼 쌓고 나면 CPU가 낮게 유지되어도 더이상 쌓이지 않는다.
* CPU가 기준치를 초과하면 초과한만큼 크레딧이 사용된다.
* CPU가 기준치를 잠깐씩 초과한다면 크레딧이 조금 사용됐다가 금방 다시 복구된다.
* 하지만 CPU가 기준치를 오랫동안 초과하거나 자주 초과한다면 크레딧이 쌓이지 않고 계속 소모만 되거나, 크레딧이 쌓이는 속도보다 소모되는 속도가 더 빨라진다.
* 크레딧이 0이 되면 CPU 성능이 제한되거나 초과 비용이 발생하기 시작한다.

== 이유 및 한계 ==
가상화 공유 자원을 운용하는 클라우드 특성상 CPU가 1% ~ 100%를 넘나들며 사용량이 예측불가능한 서버들이 많아지게 되면 해당 가상서버가 아닌 물리적 자원을 공유하는 다른 서버에도 영향을 줄 수 있다. 그래서 CPU 사용률이 5~20% 이내로 유지되는 수준으로 서비스를 운영하고, 이를 넘어설 정도로 서비스가 커진다면 그에 걸맞는 높은 용량의 서버를 사용하도록 하는 것이다. 그래도 피크 시간대나 특정 작업에서 CPU가 많이 사용될 수 있으므로, 어느정도의 CPU 초과는 허용해주되, 많이는 초과하지 말라는 것이다.

정석대로라면 평균 CPU 사용률이 20%를 넘어가는 것은 바람직하지 않으므로, 바람직한 서버 운영을 도모한다고 볼 수도 있으나. 기존에 서버를 직접 운영하거나 가상서버 호스팅을 사용했을 떄에 비하면 사용자 입장에서 상당히 큰 제약이다. 기존엔 비수기엔 CPU가 1~2%대로 유지되다가 성수기나 이벤트 시기엔 20~30%정도로 몰릴 수도 있는데 그렇다고 서버거 과부화로 죽는 상황까진 이르지 않는다. 하지만 AWS의 이런 제약 아래선 성수기에 CPU가 높은 수준으로 며칠 이상 유지될 경우 CPU 버스트 크레딧이 모두 소진되어 갑자기 CPU 성능이 급감하고, 특정 서버의 성능이 급감을 하게 되면 연쇄적인 시스템 장애로 번질 수 있다. 실제로 이런 사고를 한번 겪고 나서 CPU 버스트에 대해 알게 되는 경우도 많다.

사용자는 당연히 CPU의 100%를 사용할 수 있을 것이라 생각하고 서비스를 신청했는데 실제로는 CPU의 10~20%밖에 못쓰도록 제한이 있는 것이니 과대포장 같은 느낌이기도 하다.

== 비판 ==
'''불가피한 조치인가 상술인가'''

하이버파이저 가상화를 잘만 운영하면 특정 가상환경에서 발생하는 부하가 다른 환경에 번지지 않도록 차단하는 것이 불가능한 것도 아니다. 그런데도 그런 운영능력 부족으로 이렇게 사용자에게 사고를 유발하고 필요보다 더 큰 용량의 서버 인스턴스를 구매하여 사용하도록 하는 것은, 안정성 유지라는 허울 좋은 핑계로 사용료를 더 받겠다는 상술에 불가능하다는 견해가 있다.

'''미리 제대로 공지하였는가'''

CPU 버스트에 대해선 조금만 검색하면 나오긴 하지만 CPU 버스트라는 이름만으로 이런 제한 정책을 미리 예측하긴 어렵다. 분명히 CPU 버스트에 대한 매뉴얼이 있긴 할지라도 서버 인스턴스를 신정하는 과정에서 이에 대한 경고나 안내가 명확하게 나오는 것은 아니다. 클라우드에 익숙한 많은 사용자는 기존에 안정적으로 운영해왔던 성능으로 인스턴스를 구성할 것이나 AWS의 이런 제약으로 전혀 예상치 못한 사고를 겪에 된다.

== 핵심 개념 및 정의 ==

; CPU 사용률
: CPU 사용률은 인스턴스에서 현재 사용 중인 할당된 EC2 컴퓨팅 유닛의 비율(%)입니다. 이 지표는 인스턴스에서 사용되고 있는 할당된 CPU 사이클의 비율을 측정합니다. CPU 사용률 CloudWatch 지표는 코어당 CPU 사용량이 아니라 인스턴스당 CPU 사용량을 나타냅니다. 인스턴스의 기준 CPU 사양도 인스턴스당 CPU 사용량을 기준으로 합니다. AWS Management Console 또는 AWS CLI를 사용하여 CPU 사용률을 측정하려면 특정 인스턴스에 대한 통계 가져오기 섹션을 참조하세요.
; CPU 크레딧
: vCPU 시간의 단위입니다. 예: CPU 크레딧 1개 = vCPU 1개 * 100% 사용률 * 1분 CPU 크레딧 1개 = vCPU 1개 * 50% 사용률 * 2분 CPU 크레딧 1개 = vCPU 2개 * 25% 사용률 * 2분
; 기준 사용률
: 기준 사용률은 획득하는 CPU 크레딧 수가 사용 중인 CPU 크레딧 수와 일치할 때 순 크레딧 밸런스 0에서 CPU를 사용할 수 있는 수준입니다. 기준 사용률을 기준이라고도 합니다. 기준 사용률은 vCPU 사용률의 백분율로 표시되며 기준 사용률(%) = (획득한 크레딧 수/vCPU 수)/60분으로 계산됩니다. 각 버스트 가능한 성능 인스턴스 유형의 기준 사용률은 크레딧 표를 참조하세요.
; 획득 크레딧
: 인스턴스가 실행 중일 때 지속적으로 적립되는 크레딧입니다. 시간당 적립되는 크레딧 수 = 기준 사용률(%) * vCPU 수 * 60분 예: vCPU가 2개인 t3.nano는 기본 사용률이 5%로, 시간당 6 크레딧을 획득하며, 다음과 같이 계산됩니다. vCPU 2개 * 5% 기준 * 60분 = 시간당 6 크레딧
; 소비 또는 사용되는 크레딧
: 인스턴스가 실행 중일 때 지속적으로 소비되는 크레딧입니다. 분당 소비되는 CPU 크레딧 = vCPU 수 * CPU 사용률 * 1분
; 획득한 크레딧
: 인스턴스가 기준 사용률에 필요한 것보다 적은 크레딧을 사용하는 경우 사용되지 않은 CPU 크레딧입니다. 즉, 획득한 크레딧 = (적립되는 크레딧 - 기준 미만으로 사용되는 크레딧)입니다. 예: t3.nano가 한 시간 동안 5% 기준보다 적은 2% CPU 사용률로 실행될 경우 획득한 크레딧은 다음과 같이 계산됩니다. 획득한 CPU 크레딧 = (시간당 적립되는 크레딧 - 시간당 소비되는 크레딧) = 6 - 2 vCPU * 2% CPU 사용률 * 60분 = 6 - 2.4 = 시간당 획득한 크레딧 3.6입니다.
; 크레딧 누적 한도
: 인스턴스 크기에 따라 다르지만 일반적으로 24시간 동안 적립되는 최대 크레딧 수와 같습니다. 예: t3.nano의 경우 크레딧 누적 한도 = 24 * 6 = 144 크레딧입니다.
; 시작 크레딧
: 표준 모드로 구성된 T2 인스턴스에만 적용됩니다. 시작 크레딧은 새 T2 인스턴스에 할당되는 제한된 수의 CPU 크레딧으로, 표준 모드로 시작할 때 기준 이상으로 버스트할 수 있습니다.
; 잉여 크레딧
: 획득한 크레딧 잔액이 소진된 후 인스턴스가 소비하는 크레딧입니다. 잉여 크레딧은 버스트 가능 인스턴스가 오랜 기간 동안 고성능을 유지할 수 있도록 고안되었으며 무제한 모드에서만 사용됩니다. 잉여 크레딧 잔액은 인스턴스가 무제한 모드에서 버스트하기 위해 소비한 크레딧 수를 확인하는 데 사용됩니다.
; 스탠다드 모드
: 크레딧 구성 모드로, 크레딧 잔액에 적립된 크레딧을 사용하여 인스턴스를 기준 이상으로 버스트할 수 있습니다.
; 무제한 모드
: 크레딧 구성 모드로, 필요할 때마다 원하는 기간 동안 높은 CPU 사용률을 유지하여 인스턴스를 기준 이상으로 버스트할 수 있습니다. 24시간 동안 또는 인스턴스 수명(더 짧음) 동안 인스턴스의 평균 CPU 사용률이 기준 이하인 경우에 모든 CPU 사용량 급증에 대해 시간당 CPU 인스턴스 요금이 적용됩니다. 인스턴스 실행에 장기간 높은 CPU 사용률이 필요한 경우, vCPU-시간당 추가 고정 요금으로 인스턴스를 실행할 수 있습니다.

== 인스턴스별 기준 ==
{| class="wikitable"
!인스턴스 유형
!시간당 지급되는 CPU 크레딧
!누적 가능한 최대 지급된 크레딧*
!vCPU***
!vCPU당 기준 사용률
|-
|T2
|
|
|
|
|-
|<code>t2.nano</code>
|3
|72
|1
|5%
|-
|<code>t2.micro</code>
|6
|144
|1
|10%
|-
|<code>t2.small</code>
|12
|288
|1
|20%
|-
|<code>t2.medium</code>
|24
|576
|2
|20%**
|-
|<code>t2.large</code>
|36
|864
|2
|30%**
|-
|<code>t2.xlarge</code>
|54
|1296
|4
|22.5%**
|-
|<code>t2.2xlarge</code>
|81.6
|1958.4
|8
|17%**
|-
|T3
|
|
|
|
|-
|<code>t3.nano</code>
|6
|144
|2
|5%**
|-
|<code>t3.micro</code>
|12
|288
|2
|10%**
|-
|<code>t3.small</code>
|24
|576
|2
|20%**
|-
|<code>t3.medium</code>
|24
|576
|2
|20%**
|-
|<code>t3.large</code>
|36
|864
|2
|30%**
|-
|<code>t3.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t3.2xlarge</code>
|192
|4608
|8
|40%**
|-
|T3a
|
|
|
|
|-
|<code>t3a.nano</code>
|6
|144
|2
|5%**
|-
|<code>t3a.micro</code>
|12
|288
|2
|10%**
|-
|<code>t3a.small</code>
|24
|576
|2
|20%**
|-
|<code>t3a.medium</code>
|24
|576
|2
|20%**
|-
|<code>t3a.large</code>
|36
|864
|2
|30%**
|-
|<code>t3a.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t3a.2xlarge</code>
|192
|4608
|8
|40%**
|-
|T4g
|
|
|
|
|-
|<code>t4g.nano</code>
|6
|144
|2
|5%**
|-
|<code>t4g.micro</code>
|12
|288
|2
|10%**
|-
|<code>t4g.small</code>
|24
|576
|2
|20%**
|-
|<code>t4g.medium</code>
|24
|576
|2
|20%**
|-
|<code>t4g.large</code>
|36
|864
|2
|30%**
|-
|<code>t4g.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t4g.2xlarge</code>
|192
|4608
|8
|40%**
|}

셸 스크립트

2022-10-25T14:06:56Z

클라우더:

Shell Script

셸 명령어를 기초로 만드는 간단한 스크립트 프로그램

* 쉘 스크립트라고 부르는 경우가 많은데 shell의 올바른 표기법은 '셸'이므로 '''<nowiki/>'셸 스크립트'가 맞는 말이다.'''
* 이론적으로 모든 셸로 셸 스크립트를 만들 수 있지만 가장 많이하는 bash를 기준으로 설명한다.

== 최상단 필수 구문 ==
셸 스크립트 최상단엔 아래와 같은 셸 지정 구문이 들어가있어야 한다. 다른 셸을 사용하는 경우 다른 셸을 명시할 수도 있다.<syntaxhighlight lang="bash">
#!/bin/bash
</syntaxhighlight>

* #! 구분은 실무적으로 shebang(시뱅 또는 쉬뱅)이라고 부른다. #의 hash, !의 bang(영미권 표현)을 합친 말이다.

== 기본 문법 ==

=== 주석 ===
주석은 # 을 사용한다. #!와 같이 #뒤에 붙여서 사용하는 명령들이 있으므로 띄어쓴다. <syntaxhighlight lang="bash">
#!/bin/sh

# 여기 있는 내용은 실행되지 않는다.
# echo "Hi, World!"

echo "Hello, World!"
</syntaxhighlight>

=== 출력 ===
출력은 echo, printf 를 사용할 수 있다. printf는 C언어의 printf와 같이 포맷팅을 지원하는 출력이다.<syntaxhighlight lang="bash">
#!/bin/bash

echo "hello, world"
printf "hello, world"
printf "%s, %s" hello, world
</syntaxhighlight>

=== 입력 ===
read 명령을 통해 입력을 받을 수 있다.<syntaxhighlight lang="bash">
#!/bin/sh

read NAME
echo "Hello, $NAME!"
</syntaxhighlight>'''실행결과'''<blockquote>$ ./test.sh

ITWiki

Hello, ITWiki!</blockquote>

=== 변수 ===

* 변수의 이름은 영문자, 숫자, 언더바만 사용 가능하다.
* 변수에 값을 전달할 때는 = 의 앞뒤 공백 없이 작성한다. 문자열인 경우 "(쌍따옴표)로 감싼다.
** VAR = aaa (X)
** VAR="aaa" (O)
* 변수에 액세스할 때 변수명의 앞에 $를 넣는다. 중괄호로 감싸서 사용하는 표현도 흔히 사용된다.
** $VAR, ${VAR} 모두 사용 가능
* 변수의 값이 덮어 쓰기되는 것을 방지하기 위해서는 readonly를 사용한다.
<syntaxhighlight lang="bash">
#!/bin/bash

h="hello"
w="world"
echo "${h}, ${w}"
</syntaxhighlight>미리 정의된 특수변수들이 있어서 바로 사용 가능하다.

'''특수 변수'''
{| class="wikitable"
!'''변수'''
!'''기능'''
|-
|'''$0'''
|스크립트명
|-
|'''$1 ~ $9'''
|인수, 첫 번째의 인수는 $1, 2번째 인수는 $2로 액세스
|-
|'''$#'''
|스크립트에 전달된 인수의 수
|-
|'''$*'''
|모든 인수를 모아 하나로 처리
|-
|'''$@'''
|모든 인수를 각각 처리
|-
|'''$?'''
|직전에 실행한 커맨드의 종료 값(0은 성공, 1은 실패)
|-
|'''$$'''
|이 쉘 스크립트의 프로세스 ID
|-
|'''$!'''
|마지막으로 실행한 백그라운드 프로세스 ID
|}

== 기존 명령어 사용 ==
셸 스크립트에선 셸에서 사용하는 모든 명령어(ls, chmod, rm, mkdir 등등)를 다 사용할 수 있다.

결과가 반환되는 명령어의 결과를 활용하고 싶을 경우 변수에 할당하여 사용할 수 있다.

* 변수에 할당하는 방법으론 <code>$()</code>를 이용하는 방법과 `로 명령어를 감싸주는 방법 두가지가 있다.
<syntaxhighlight lang="bash">
$ A=$(date)
$ echo $A
Tue Oct 25 23:12:15 UTC 2022

$ B=`date`
$ echo $B
Tue Oct 25 23:12:16 UTC 2022
</syntaxhighlight>

== 참고 문헌 ==

* [https://engineer-mole.tistory.com/200 <nowiki>[Linux] 쉘 스크립트(Shell script) 기초</nowiki>]
* [https://reakwon.tistory.com/136 <nowiki>[리눅스] 쉘 스크립트(SHELL SCRIPT) 기본 문법, 작성방법(변수,반복문,비교문,종료상태 등)</nowiki>]

셸 스크립트

2022-10-25T13:37:48Z

클라우더: 새 문서: Shell Script 셸 명령어를 기초로 만드는 간단한 스크립트 프로그램 * 쉘 스크립트라고 부르는 경우가 많은데 shell의 올바른 표기법은 '셸'이므로 '''<nowiki/>'셸 스크립트'가 맞는 말이다.''' * 이론적으로 모든 셸로 셸 스크립트를 만들 수 있지만 가장 많이하는 bash를 기준으로 설명한다. == 최상단 필수 구문 == 셸 스크립트 최상단엔 아래와 같은 셸 지정 구문이 들어가...

Shell Script

셸 명령어를 기초로 만드는 간단한 스크립트 프로그램

* 쉘 스크립트라고 부르는 경우가 많은데 shell의 올바른 표기법은 '셸'이므로 '''<nowiki/>'셸 스크립트'가 맞는 말이다.'''
* 이론적으로 모든 셸로 셸 스크립트를 만들 수 있지만 가장 많이하는 bash를 기준으로 설명한다.

== 최상단 필수 구문 ==
셸 스크립트 최상단엔 아래와 같은 셸 지정 구문이 들어가있어야 한다. 다른 셸을 사용하는 경우 다른 셸을 명시할 수도 있다.<syntaxhighlight lang="bash">
#!/bin/bash
</syntaxhighlight>

* #! 구분은 실무적으로 shebang(시뱅 또는 쉬뱅)이라고 부른다. #의 hash, !의 bang(영미권 표현)을 합친 말이다.

== 기본 문법 ==

=== 주석 ===
주석은 # 을 사용한다. #!와 같이 #뒤에 붙여서 사용하는 명령들이 있으므로 띄어쓴다. <syntaxhighlight lang="bash">
#!/bin/sh

# 여기 있는 내용은 실행되지 않는다.
# echo "Hi, World!"

echo "Hello, World!"
</syntaxhighlight>

=== 출력 ===
출력은 echo, printf 를 사용할 수 있다. printf는 C언어의 printf와 같이 포맷팅을 지원하는 출력이다.<syntaxhighlight lang="bash">
#!/bin/bash

echo "hello, world"
printf "hello, world"
printf "%s, %s" hello, world
</syntaxhighlight>

=== 입력 ===
read 명령을 통해 입력을 받을 수 있다.<syntaxhighlight lang="bash">
#!/bin/sh

read NAME
echo "Hello, $NAME!"
</syntaxhighlight>'''실행결과'''<blockquote>$ ./test.sh

ITWiki

Hello, ITWiki!</blockquote>

=== 변수 ===

* 변수의 이름은 영문자, 숫자, 언더바만 사용 가능하다.
* 변수에 값을 전달할 때는 = 의 앞뒤 공백 없이 작성한다. 문자열인 경우 "(쌍따옴표)로 감싼다.
** VAR = aaa (X)
** VAR="aaa" (O)
* 변수에 액세스할 때 변수명의 앞에 $를 넣는다. 중괄호로 감싸서 사용하는 표현도 흔히 사용된다.
** $VAR, ${VAR} 모두 사용 가능
* 변수의 값이 덮어 쓰기되는 것을 방지하기 위해서는 readonly를 사용한다.
<syntaxhighlight lang="bash">
#!/bin/bash

h="hello"
w="world"
echo "${h}, ${w}"
</syntaxhighlight>미리 정의된 특수변수들이 있어서 바로 사용 가능하다.

'''특수 변수'''
{| class="wikitable"
!'''변수'''
!'''기능'''
|-
|'''$0'''
|스크립트명
|-
|'''$1 ~ $9'''
|인수, 첫 번째의 인수는 $1, 2번째 인수는 $2로 액세스
|-
|'''$#'''
|스크립트에 전달된 인수의 수
|-
|'''$*'''
|모든 인수를 모아 하나로 처리
|-
|'''$@'''
|모든 인수를 각각 처리
|-
|'''$?'''
|직전에 실행한 커맨드의 종료 값(0은 성공, 1은 실패)
|-
|'''$$'''
|이 쉘 스크립트의 프로세스 ID
|-
|'''$!'''
|마지막으로 실행한 백그라운드 프로세스 ID
|}

== 참고 문헌 ==

* [https://engineer-mole.tistory.com/200 <nowiki>[Linux] 쉘 스크립트(Shell script) 기초</nowiki>]
* [https://reakwon.tistory.com/136 <nowiki>[리눅스] 쉘 스크립트(SHELL SCRIPT) 기본 문법, 작성방법(변수,반복문,비교문,종료상태 등)</nowiki>]

AWS Elastic Beanstalk

2022-10-23T04:19:32Z

클라우더:

AWS Elastic Beanstalk는 Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker를 사용하여 Apache, Nginx, Passenger, IIS와 같은 친숙한 서버에서 개발된 웹 애플리케이션 및 서비스를 간편하게 배포하고 조정할 수 있는 서비스이다.

* [https://aws.amazon.com/ko/elasticbeanstalk/ 공식 서비스 페이지]

== 설명 ==
코드를 업로드하기만 하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, Auto Scaling부터 시작하여 애플리케이션 상태 모니터링에 이르기까지 배포를 자동으로 처리한다. 이뿐만 아니라 애플리케이션을 실행하는 데 필요한 AWS 리소스를 제어할 수 있으며 언제든지 기본 리소스에 액세스할 수 있다.

== 비용 ==
Elastic Beanstalk는 추가 비용 없이 애플리케이션을 저장 및 실행하는 데 필요한 AWS 리소스에 대해서만 요금을 지불하면 된다.

== 이점 ==

== 이점 ==
'''빠르고 간편한 시작'''

Elastic Beanstalk는 AWS에 애플리케이션을 배포하는 가장 빠르면서 간편한 방법이다. AWS Management Console, Git 리포지토리 또는 Eclipse나 Visual Studio와 같은 IDE(통합 개발 환경)를 통해 애플리케이션을 업로드하기만 하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, Auto Scaling, 애플리케이션 상태 모니터링에 대한 배포 정보를 자동으로 처리한다. 몇 분 후면 애플리케이션을 사용할 수 있다. 인프라나 리소스를 구성할 필요가 전혀 없다.

'''개발자 생산성'''

Elastic Beanstalk는 사용자 대신 인프라를 프로비저닝하고 운영할 뿐만 아니라 애플리케이션 스택(플랫폼)을 관리해주므로, 사용자는 시간을 따로 들이거나 익숙해지기 위해 애쓸 필요가 없다. 또한, 애플리케이션이 실행되는 기본 플랫폼을 최신 패치와 업데이트를 통해 최신 상태로 유지한다. 서버, 데이터베이스, 로드 밸런서, 방화벽, 네트워크 등을 관리하고 구성하는 데 시간을 들이는 대신 코드 작성에 집중할 수 있다.

'''적절한 규모 유지'''

Elastic Beanstalk는 손쉽게 조정할 수 있는 Auto Scaling 설정을 사용하여 애플리케이션의 특정 요건에 따라 자동으로 애플리케이션을 확장하거나 축소합니다. 예를 들어, CPU 사용률 지표를 참조하여 Auto Scaling 작업을 트리거할 수 있습니다. Elastic Beanstalk를 사용하면 애플리케이션에서 비용을 최소화하면서 높은 워크로드나 트래픽을 처리할 수 있습니다.

'''완벽한 리소스 제어'''

Amazon EC2 인스턴스 유형 및 워크로드를 실행할 프로세서 유형과 같이 애플리케이션에 가장 적합한 AWS 리소스를 자유롭게 선택할 수 있다. 애플리케이션을 실행하는 AWS 리소스를 완벽하게 제어할 수도 있다. 인프라 요소 중 일부(또는 전체)를 손쉽게 제어하려면 Elastic Beanstalk의 관리 기능을 사용하면 된다.

== 배포 방식 ==
'''All at once'''

새 버전을 모든 인스턴스에 동시에 배포합니다. 배포가 수행되는 동안 환경에 있는 모든 인스턴스가 잠시 서비스 중지됩니다.

'''Rolling'''

새 버전을 배치로 배포합니다. 각 배치는 배포 단계 동안 서비스에서 제외되므로 배치에 있는 인스턴스의 수만큼 환경의 용량이 감소합니다.

'''Rolling with additional batch'''

새 버전을 배치로 배포하지만, 먼저 새로운 배치의 인스턴스를 시작하여 배포 프로세스 중에 모든 용량이 유지되도록 합니다.

'''Immutable'''

새로운 auto scaling 그룹을 만들어 단일 인스턴스를 배치합니다. 원래 있던 auto scaling 그룹과 같이 트래픽을 처리하며 새로 배치된 인스턴스의 상태가 양호하면 원래 있던 인스턴스의 수만큼 추가하여 배포합니다.

'''Traffic splitting'''

카나리 배포 방식입니다. 새로운 auto scaling 그룹을 만들고 로드밸런서에서 트래픽의 일정 부분을 보내 상태가 양호하다면 모든 트래픽을 새로 업로드한 인스턴스로 처리합니다.

AWS Elastic Beanstalk

2022-10-23T04:15:01Z

클라우더: 새 문서: AWS Elastic Beanstalk는 Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker를 사용하여 Apache, Nginx, Passenger, IIS와 같은 친숙한 서버에서 개발된 웹 애플리케이션 및 서비스를 간편하게 배포하고 조정할 수 있는 서비스이다. * [https://aws.amazon.com/ko/elasticbeanstalk/ 공식 서비스 페이지] == 설명 == 코드를 업로드하기만 하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, Auto Scaling부터 시작...

IOPS

2022-10-22T09:05:53Z

클라우더: 새 문서: '''Input/Output Operations Per Secon''' IOPS는 HDD, SDD 또는 NVMe등 저장장치의 속도를 나타내는데 사용도는 측정 단위로, MB/s, MiB/s 또는 GB/s, GiB/s 등과 같이 초당 전송량과 함께 많이 최근 들어 많이 사용되고 있는 단위이다. == 측정 방법 == IOPS 측정값은 세부적으로 초당 전송량과 같이 임의 접근(Random Acess)과 순차접근(Sequential Acess)에 따라 다르고, 읽기 및 쓰기 동작에 따라 다...

'''Input/Output Operations Per Secon'''

IOPS는 HDD, SDD 또는 NVMe등 저장장치의 속도를 나타내는데 사용도는 측정 단위로, MB/s, MiB/s 또는 GB/s, GiB/s 등과 같이 초당 전송량과 함께 많이 최근 들어 많이 사용되고 있는 단위이다.

== 측정 방법 ==
IOPS 측정값은 세부적으로 초당 전송량과 같이 임의 접근(Random Acess)과 순차접근(Sequential Acess)에 따라 다르고, 읽기 및 쓰기 동작에 따라 다르다. 이외의 성능 측정 프로그램과 CPU 와 메모리에 상화에 따라 차이가 나게 측정되기도 한다.

순차 접근의 경우 데이터를 쓰거나 읽기 위해서 순차저적으로 접근하기 때문에 데이터 및 위치 검색 등의 오버헤드가 없기 속도가 빠르다. 하지만 임의 접근위의 경우 데이터에 접근하기 위해서 추가적으로 접근, 검색하기 때문에 순차 접근과 비교했을 경우 속도가 많이 느린 것이 일반적이다.

== IOPS 계산 방법 ==
주어진 IOPS 값에서 초당 데이터 전송량을 계산하는 방법은 아래와 같다.<blockquote>'''초당 데이터 전송량 = IOPS * 블럭크기(단위 데이터 용량)'''</blockquote>만약 블럭 크기 등 단위 데이터 용량에서 IOPS 를 계산하기 위해서는 아래의 공식을 이용한다.<blockquote>'''IOPS = 초당 데이터 전송량 / 블럭크기(단위 데이터 용량)'''</blockquote>블럭 크기인 단위 데이터 용량과 초당 데이터 전송량의 단위가 차이가 날 경우 추가 계산이 필요할 수 있다. 아래의 예제를 통해서 실제 계산 방법에 대해 알아보자.

=== 계산 예제 ===
AWS에서 호스팅되고 있는 EBS 볼륨 유형의 IOPS 값을 이용하여, 이해하기 쉬운 초당 전송량을 계산해 보도록 하겠다.

'''Amazon EBS 볼륨 유형'''

[[파일:Aws-ebs-types.png|500x500픽셀]]

위에서 나타나 있는 최대 IOPS 값에서 범용 SSD(gp2) 값의 16,000 IOPS 가 초당 얼마만큼의 데이터를 전송 할 수 있는지 계산해 보도록 하겠다. IOPS 값에서 초당 전송량을 계산하기 위해서는, IOPS 수치가 나타내는 단위 크기의 값을 알아야 한다.

같은 페이지에서 찾아보면 IOPS 블럭 크기를 확인할 수 있다. 블럭 크기를 알려주지 않으면 계산이 불가능하므로, 보통은 IOPS에 곱할 수 있는 기준값을 같이 보여주는게 일반적이다. 아마존에서 안내한 블럭 사이즈는 아래와 같이 되어 있다.<blockquote>** 16KiB I/O 크기 기준 gp/io1, 1MiB I/O 크기 기준 st1/sc1</blockquote>SSD(gp2) 가 16KiB 이기 때문 이 값을 이용하여 계산해 보도면 다음과 같이 최대 처리량(초당 데이터 전송률)250MiB/s (256,000 KiB/s) 으로 계산된다.<blockquote>'''16,000 IOPS * 16KiB = 256000 KiB/s = 256000 / 1024 = 250MiB/s'''</blockquote>

== 참고 문헌 ==

* 원문 출처: https://hiseon.me/server/iops-calculator/

파일:Aws-ebs-types.png

2022-10-22T09:01:13Z

클라우더:

AWS

마이크로소프트 애저

2022-10-22T08:33:10Z

클라우더:

'''Microsoft Azure'''

윈도우즈로 유명한 마이크로 소프트에서 운영하는, 현재 기준 전세계 2위 규모의 [[클라우드 서비스 제공자]]

== 주요 용어 ==
아직 한글화가 깔끔하게 진행되지 않아 영문 표현을 우선적으로 사용

=== 관리 범위 ===
'''Subscription (구독)'''

비용 지불 단위이다. 가장 상위 단위로, 각 서버마다 구독을 달리하긴 어렵다. 한 계정에서 큰 단위의 리소스 그룹이 여러개 존재하는 경우, 리소스 그룹별로 구독을 달리하여 비용관리를 할 수 있다.

'''Resource Group (리소스 그룹)'''

각종 서버, DNS, 로드 밸런서, 디스크 등이 위치하는 그룹이다. 하나의 서비스를 구분하는 그룹이라고 생각하면 된다. 한 리소스 그룹 안에 존재하는 경우만 연결이 가능하게 제한된 경우가 많으므로 일반적으로 하나의 서비스는 하나의 리소스 그룹으로 관리된다. 규모가 크지 않은 경우 편의상 여러 서비스를 하나의 리소스 그룹에 넣어도 무방하다.

=== 리소스 ===
'''가상 머신 (Virtual Machine)'''

일반적인 형태의 서버 자원이다. [[AWS]]의 EC2와 유사하게 사용되는 개념이다. 윈도우, 리눅스와 같은 OS를 선택할 수 있고 CPU, 메모리, 디스크 등의 용량도 자유롭게 조정할 수 있다.

'''애플리케이션 게이트웨이(Application Gateway)'''

일종의 L7([[OSI 7계층]]의 애플리케이션 레이어) 스위치라고 보면 된다. 단순한 [[부하 분산]](Load Balancing)외에 [[TLS(SSL)]] 통신을 지원한다.

'''부하 분산 장치(Load Balancer)'''

일종의 부하 분산 전용 L4 스위치라고 보면 된다.

마이크로소프트 애저

2022-10-22T08:27:28Z

클라우더:

'''Microsoft Azure'''

윈도우즈로 유명한 마이크로 소프트에서 운영하는, 현재 기준 전세계 2위 규모의 [[클라우드 서비스 제공자]]

== 주요 용어 ==
아직 한글화가 깔끔하게 진행되지 않아 영문 표현을 우선적으로 사용

'''Subscription (구독)'''

비용 지불 단위이다. 가장 상위 단위로, 각 서버마다 구독을 달리하긴 어렵다. 한 계정에서 큰 단위의 리소스 그룹이 여러개 존재하는 경우, 리소스 그룹별로 구독을 달리하여 비용관리를 할 수 있다.

'''Resource Group (리소스 그룹)'''

각종 서버, DNS, 로드 밸런서, 디스크 등이 위치하는 그룹이다. 하나의 서비스를 구분하는 그룹이라고 생각하면 된다. 한 리소스 그룹 안에 존재하는 경우만 연결이 가능하게 제한된 경우가 많으므로 일반적으로 하나의 서비스는 하나의 리소스 그룹으로 관리된다. 규모가 크지 않은 경우 편의상 여러 서비스를 하나의 리소스 그룹에 넣어도 무방하다.

마이크로소프트 애저

2022-10-22T08:26:27Z

클라우더: 새 문서: '''Microsoft Azure''' == 주요 용어 == 아직 한글화가 깔끔하게 진행되지 않아 영문 표현을 우선적으로 사용 ==== Subscription (구독) ==== 비용 지불 단위이다. 가장 상위 단위로, 각 서버마다 구독을 달리하긴 어렵다. 한 계정에서 큰 단위의 리소스 그룹이 여러개 존재하는 경우, 리소스 그룹별로 구독을 달리하여 비용관리를 할 수 있다. ==== Resource Group (리소스 그룹) ==== 각...

'''Microsoft Azure'''

== 주요 용어 ==
아직 한글화가 깔끔하게 진행되지 않아 영문 표현을 우선적으로 사용

==== Subscription (구독) ====
비용 지불 단위이다. 가장 상위 단위로, 각 서버마다 구독을 달리하긴 어렵다. 한 계정에서 큰 단위의 리소스 그룹이 여러개 존재하는 경우, 리소스 그룹별로 구독을 달리하여 비용관리를 할 수 있다.

==== Resource Group (리소스 그룹) ====
각종 서버, DNS, 로드 밸런서, 디스크 등이 위치하는 그룹이다. 하나의 서비스를 구분하는 그룹이라고 생각하면 된다. 한 리소스 그룹 안에 존재하는 경우만 연결이 가능하게 제한된 경우가 많으므로 일반적으로 하나의 서비스는 하나의 리소스 그룹으로 관리된다. 규모가 크지 않은 경우 편의상 여러 서비스를 하나의 리소스 그룹에 넣어도 무방하다.

클라우드 서비스 제공자

2022-10-20T12:50:41Z

클라우더: 새 문서: '''CSP; Cloud Service Provider''' 클라우드 서비스를 제공하는 사업자를 지칭하는 말로, 흔히 줄여서 CSP라고 부른다. 일반적으로 SaaS 단독 제공 사업자보단 IaaS, PaaS, SaaS를 종합적으로 제공하는 사업자를 지칭한다. == 주요 사업자 목록 == '사업자'라는 측면에서 보면 아마존, 마이크로소프트 등이 CSP라고 할 수 있지만, 주요한 CSP들은 광범위한 사업 영역을 가진 글로벌 플...

'''CSP; Cloud Service Provider'''

클라우드 서비스를 제공하는 사업자를 지칭하는 말로, 흔히 줄여서 CSP라고 부른다. 일반적으로 SaaS 단독 제공 사업자보단 IaaS, PaaS, SaaS를 종합적으로 제공하는 사업자를 지칭한다.

== 주요 사업자 목록 ==
'사업자'라는 측면에서 보면 아마존, 마이크로소프트 등이 CSP라고 할 수 있지만, 주요한 CSP들은 광범위한 사업 영역을 가진 글로벌 플랫폼 사업자인 경우가 많아 일반적으론 클라우드 브랜드 자체(AWS, Azure)를 CSP라고 부르는 경우가 많다.

=== 해외 ===

* [[아마존 웹서비스|아마존 웹서비스(AWS)]]
* [[마이크로소프트 애저|마이크로소프트 애저(Azure)]]
* [[구글 클라우드 플랫폼|구글 클라우드 플랫폼(GCP)]]
* [[알리바바 클라우드]]

=== 국내 ===

* 네이버 클라우드 플랫폼(NCP)
* KT클라우드
* NHN클라우드
* 가비아 클라우드