아마존 웹 서비스를 이용한 글로벌 서비스 인프라 설계 : 효율적인 aws...

아마존 웹 서비스를 이용한

글로벌 서비스 인프라 설계

효율적인 AWS 운용을 위한

DevOps 환경 만들기

소프트웨어와 물리적인 인프라, 즉 컴퓨터 시스템과 네트워크에 관한 새로운 관점이 등장하고

있다. 바로 클라우드다. 클라우드 기술이 산업 전면에 등장하기 시작한 2010년 전까지만

해도 소프트웨어와 인프라는 완전히 분리된 자원이었다. 물리적인 실체가 있느냐 없느냐 하는

외견상의 차이뿐만 아니라 조직도 분리돼 있었으며, 조직 구성원의 경력, 기술 셋, 하는 일,

목표 등에도 차이가 있었다. 함께 일하기는 하지만 이들 둘 사이에는 한강이 흐르고 있고,

한강을 건너서 의사소통을 해야 하는 그런 관계였다고 보면 되겠다.

이 둘의 관계에 대한 새로운 관점이 만들어지게 된 계기는 인터넷 서비스의 폭발적인 성장

때문이었다. 제품의 판매뿐만 아니라 개인의 관심사와 정보까지 서비스화되면서 양적으로도

질적으로도 폭발적인 성장이 일어났다.

그러면서 인터넷 서비스에 ‘예측 불가능’이라는 새로운 특징이 추가됐다. 원래 인터넷

서비스가 거대한 규모와 상품의 복잡성 때문에 예측이 어려운 측면이 있었지만, 이 정도까지는

아니었다. 지금은 투자자, 서비스를 직접 기획한 기획자와 개발자, 시장 조사자 누구도

서비스의 성공과 실패 여부를 알 수 없게 됐다.

이렇게 인터넷의 상황이 바뀌자 소프트웨어와 인프라의 관계를 다시 설정해야 하는 요구가

생겨났다. 비교적 유연하게 환경 변화에 적응할 수 있는 소프트웨어와 달리, 인프라는

유연하게 대응하기가 쉽지 않다. 인프라는 서비스의 성장이 예상된다고 해서 마음대로

늘리거나 줄일 수 있는 성격의 것이 아니다. 그나마 서비스의 성장 곡선을 예측할 수 있다면

위험 부담 없이 인프라 계획을 세울 수 있겠지만 그렇지 않으면 엄청난 부담을 떠안아야 한다.

그래서 클라우드 서비스가 전면에 떠오르게 됐다. 클라우드는 (컴퓨터나 네트워크와 같은)

인프라를 서비스나 소프트웨어 형태로 제공함으로써 마치 프로세스를 늘였다 줄였다 하는

들어가며|IV

것처럼 유연하게 인프라를 운영할 수 있게 돕는다. 전기를 얻기 위해서 집집마다 자가발전을

할 필요 없이 이미 구축된 공공 전기망에 코드를 꼽는 것으로 전기를 사용할 수 있는 것처럼

이미 구축된 클라우드 서비스에 접속하는 것만으로 인프라를 사용할 수 있다.

게다가 클라우드 서비스에 접속하면 전 세계를 대상으로 인프라를 사용할 수 있다. 이는

서비스의 국경이 없는 인터넷에서 매우 중요한 특징이다.

클라우드의 이러한 성격은 특히 서비스의 성공을 예측하기 어렵고 인프라를 소유하기 어려운

스타트업에는 정말 유용하다. 실제 많은 스타트업이 클라우드를 기반으로 서비스를 확장하고

있으며 이제는 중견기업과 대기업까지 이용 영역이 확장되고 있다.

우리는 가상의 회사를 하나 만들 것이다. 이 가상의 회사는 프로토타이핑부터 시작해 전

세계를 대상으로 하는 서비스를 AWS를 이용해 개발할 것이다. 이 과정을 따라가면서 AWS 를

이해하고 글로벌 서비스를 위한 인프라 구축에 대한 아이디어를 얻을 수 있을 것이다.

이 책의 특징과 이 책에서 다루는 내용은 다음과 같다.

1. 이 책은 레퍼런스 가이드가 아니다. AWS에 인터넷 서비스를 위한 인프라를 구성하는 아이디어를 제공하는 것이

이 책의 목적이다. AWS의 기능에 대해서는 기본적인 사용법을 다루는 정도이며, 세부적인 사용법을 담고 있지는

않다.

2. 주로 어떤 식으로 인프라를 구성해야 하고 이를 위해 어떤 도구를 사용해야 하는지 등 인프라 구성 차원에서 좀

더 넓게 바라본다.

3. 구성한 인프라를 효율적으로 관리하기 위한 인프라 자동화, 모니터링, 업무 처리 시스템 구축 등을 살펴본다.

4. 클라우드 환경에서 소프트웨어와 인프라를 통합하는 방법을 찾는다.

들어가며 | V

목차|VI

들어가며 IV

AWS 소개 201 장

1.1 _ AWS의 특징 3

1.2 _ IaaS, SaaS, PaaS 5

1.3 _ AWS 글로벌 인프라 6

1.4 _ AWS 프리 티어 계정 생성 8

1.5 _ AWS 대시보드 9

1.6 _ AWS 주요 서비스 10

EC2 10

AMI 11

기본 네트워크 구성 요소 14

1.7 _ VPC 네트워크 17

인터넷 게이트웨이 17

IP 주소와 IP 서브넷 20

Routes 23

1.8 _ 확장성과 가용성에 대한 방향 설정 24

1.9 _ RDS(데이터베이스 서비스) 27

1.10 _ EBS와 Instance store 29

1.11 _ S3 31

1.12 _ 클라우드프런트 31

1.13 _ IAM 33

1.14 _ 마치며 34

목차 | VII

프로토타이핑 서비스 개발 3602 장

2.1 프로토타이핑을 위한 AWS 서비스 인프라 설계 38

2.2 VPC 네트워크 구성 38

VPC 생성 39

Route 설정 45

2.3 EC2 인스턴스 생성 46

인스턴스 생성 46

EIP 할당과 접속 55

User data 확인 59

EBS 볼륨 마운트 59

2.4 웹 서비스 실행 61

2.5 MySQL(RDS) 설치 및 설정 64

RDS 설정 65

RDS 인스턴스 만들기 68

2.6 마치며 72

지역 서비스를 위한 AWS 인프라 구축 7403 장

3.1 기본 인프라 정책 75

3.2 프로토타이핑 인프라의 개선 76

3.3 서비스 가용성을 확보하기 위한 인프라 구성 77

3.3 가용성 존을 포함한 VPC 구성 78

3.5 ELB를 이용한 로드 밸런싱 환경 구성 83

3.6 도메인 설정 - Route 53 90

3.7 SSL 오프로드 96

목차|VIII

3.8 RDS 관리 100

Multi-AZ와 읽기 전용 복제 100

Multi-AZ 설정 101

읽기 전용 복제 설정 103

데이터베이스 백업과 복원 105

3.9 마치며 107

DevOps 10804 장

4.1 애자일과 DevOps 110

4.2 DevOps와 클라우드 112

4.3 DevOps를 위해 필요한 요소(자동, 자동, 자동) 113

서버 설정 자동화와 자동 배치 114

모니터링 115

테스트, 빌드 및 배포의 자동화 116

4.4 AWS API를 이용한 인프라 관리 도구 개발 117

AWS API 118

AWS API를 사용하기 위한 조건 118

IAM의 관리 118

4.5 Boto 라이브러리 소개 122

Access key와 Secret Access Key 준비 123

파이썬과 Boto 라이브러리 설치 및 준비 123

EC2 인스턴스 생성 123

SQS 모니터링 126

4.6 AWS CLI 128

RDS의 생성 129

4. 7 마치며 130

목차 | IX

글로벌 인프라 구축 13105 장

5.1 네이밍을 이용한 인프라 구조 잡기 132

5.2 네이밍과 호스트 이름 138

5.3 VPC 네트워크 설계 139

5.4 VPC 유닛 확장 142

5.5 VPN을 이용한 VPC 네트워크 통합 146

5.6 Site-to-Site OpenVPN 설정 151

서버와 클라이언트에 대한 ip forward 설정 151

OpenVPN PKI 환경 설정 152

OpenVPN 서버 설정 155

OpenVPN 클라이언트 설정 158

VPC 라우팅 설정 162

시큐리티 그룹 설정 165

5.7 개발자와 운영자를 위한 VPN 연결 165

Host-To-Site OpenVPN 구성 167

OpenVPN 서버 설치 167

VPN 유저 관리 170

관리 네트워크 연결 설정 172

5.8 NAT서브넷 구축 178

NAT 178

NAT 인스턴스 설정 180

VPC 네트워크 설정 181

Managed NAT Gateway 설정 183

5.9 마치며 185

목차|X

셰프(Chef)를 이용한 클라우드 인프라 관리 18706 장

6.1 셰프 189

데이터와 로직의 분리 189

셰프의 구성 190

리소스 193

셰프 서버, 셰프 클라이언트,

셰프 워크스테이션의 배치 194

6.2 셰프 서버의 설치 195

준비 195

내려받기 및 설치 196

유저 추가 199

Organizations 추가 200

6.3 셰프 워크스테이션의 설치 201

내려받기 및 설치 201

나이프 환경 설정 203

6.4 쿡북 개발 205

셰프와 루비 205

Hello World 쿡북 만들기 205

6.5 셰프 노드에 쿡북 적용 209

셰프 노드 생성 210

셰프 클라이언트 내려받기 및 설치 211

6.6 좀 더 복잡하고 현실적인 예제 215

유저 관리 쿡북 만들기 215

데이터백 만들기 215

유저 생성 217

유저 ssh key 관리 220

목차 | XI

6.7 셰프를 이용한 AWS 인스턴스 배치 자동화 223

셰프 클라이언트를 포함한 AMI 개발 223

Cloud-init를 이용한 초기화 스크립트 실행 224

인스턴스 자동 설정 226

6.8 마치며 228

인프라 모니터링 시스템 구축 22907 장

7.1 장애 허용과 장애 내성 231

7.2 인프라 장애와 서비스 장애별 대응 정책 수립 231

7.3 모니터링 시스템 구성 234

클라우드워치 235

7.4 자빅스 모니터링 서버 설치 235

7.5 자빅스 에이전트 설치와 모니터링 243

자빅스 에이전트 설치 및 설정 243

네트워크 설정 변경 245

호스트 등록 246

사용자 정의 매트릭 추가 250

자빅스 서버에 유저 매트릭 추가 253

트리거 설정 255

그래프 만들기 257

알람 전송 259

미디어 타입 추가 262

7.6 서비스 모니터링 264

서비스 모니터링 환경 구성 264

웹 서비스 모니터링 도구의 개발과 적용 266

7.7 마치며 268

목차|XII

AWS 인프라 보안 26908 장

8.1 시큐리티 그룹 270

시큐리티 그룹의 기본 정책 271

8.2 네트워크 ACL 272

네트워크 ACL과 시큐리티 그룹의 조합 276

8.3 운영체제 보안 277

기본 유저 정책 278

루트로의 switch user 제한 280

sudo 명령을 이용해 애플리케이션 단위로

루트 권한을 제한 281

SSH를 통한 유저 접근 정책 282

8.4 IAM 283

IAM을 구성하는 유저, 그룹, 정책 283

효율적인 IAM 보안 정책 292

8.5 마치며 296

개발자, 운영자, 고객의 통합 29709 장

9.1 이슈 추적 시스템 298

9.2 이슈 추적 시스템 선택 300

9.3 지라 설치 300

9.4 지라를 이용한 서비스 품질 관리 302

프로젝트 생성 303

목차 | XIII

9.5 고객 및 테스터 요청 관리 시스템 개발 306

지라 API를 이용한 매시업 서비스 개발 307

커스텀(custom) 필드 추가 310

9.6 지라의 응용 314

9.7 마치며 314

AWS 인프라의효율적인 운용을 위한 팁 31510 장

10.1 EC2의 효율적인 사용 316

스팟 인스턴스 316

예약 인스턴스 318

10.2 태그를 이용한 리소스의 분류 319

태그 319

IAM과 태그를 사용한 리소스 권한 관리 321

비용 관리 322

태그 에디터 325

10.3 인스턴스 메타데이터 327

인스턴스 메타데이터 327

인스턴스 메타데이터의 구조 328

인스턴스 메타데이터 사용 예제 329

10.4 시큐리티 그룹의 효율적인 사용 330

EC2에 시큐리티 그룹 적용하기 330

10.5 Route 53을 이용한 효율적인 도메인 관리 333

라우팅 정책 333

목차|XIV

10.6 S3를 이용한 스태틱 웹 호스팅 341

S3 스태틱 웹 호스팅 설정 341

Route 53을 사용한 S3 스태틱 웹 호스팅 설정 343

10.7 클라우드프런트로 콘텐츠를 빠르게 제공 344

클라우드프런트 도입 344

클라우드프런트의 장점 344

클라우드프런트 설정 345

10.8 EC2 없이 AWS 람다를 이용해 서비스 작성 347

AWS 람다 347

API 게이트웨이를 사용한 람다 호출 347

이미지 미리보기 생성 358

10.9 마치며 363

CI 도구를 이용한 지속적인 통합 36411 장

11.1 젠킨스를 이용한 지속적인 통합 365

11.2 젠킨스의 시스템 구성 위치 366

11.3 젠킨스 설치 367

11.4 테스트 주도 개발 368

유닛 테스트 369

테스트 커버리지 370

유닛 테스트 예제 370

젠킨스를 이용한 자동 빌드 및 테스트 수행 372

11.5 마치며 378

목차 | XV

AWS의 빅데이터와 IoT 서비스들 38012 장

12.1 AWS를 이용한 IoT 인프라 구축 381

12.2 IoT 서비스를 위한 인프라스트럭쳐 382

IoT 인프라의 구성 382

MQTT 384

12.3 AWS IoT 서비스 사용하기 385

AWS IoT 서비스 개요 386

AWS IoT 서비스 개발 개요 388

응용 393

12.4 AWS 키네시스를 이용한 대용량 데이터 처리 395

키네시스의 사용 예 395

키네시스를 이용한 웹 트래픽 분석 395

클라우드포메이션으로 샘플 애플리케이션 구축하기 396

키네시스와 SQS의 차이점 402

12.5 마치며 402

AWS 소개

01

1. AWS의특징

2. IaaS, SaaS, PaaS

3. AWS글로벌인프라

4. AWS프리티어계정생성

5. AWS대시보드

6. AWS주요서비스

7. VPC네트워크

8. 확장성과가용성에대한방향설정

9. RDS(데이터베이스서비스)

10.EBS와Instancestore

11. S3

12.클라우드프런트

13. IAM

14.마치며

01 _ AWS 소개 3

우리는 개발자이면서 경영자이며, 서비스를 운영하는 5명의 직원으로 이뤄진 조그마한 스타트업을

운영하고 있다. 오랜 시간 고민한 끝에 훌륭한 인터넷 서비스 아이템을 발굴했다. 기술적인 검토도

어느 정도 끝낸 상태로 서비스의 특징을 잘 설명하는 사업 소개서도 만들었다. 이제 투자자를 설득하기

위해서 프로토타입 서비스를 개발할 차례다.

다음과 같은 이유로 아마존에서 제공하는 AWS를 이용해 프로토타입 서비스를 개발하기로 했다.

1. 우리는 서비스에 대해 자신감이 있다. 처음부터 글로벌 시장을 대상으로 서비스 계획을 수립했다.

2. 우리는 자신감은 있지만, 경험이 부족하다는 것도 알고 있다. 실패했을 때 위험을 최소화해야 한다. 빠르게 서비스를 전개

할 수 있어야 하고, 빠르게 회수할 수 있어야 한다.

3. 서비스가 성공하면 유연하게 서비스를 확장할 수 있어야 한다.

4. 이 모든 것을 제한된 인원, 제한된 시간, 제한된 기술력으로 이룰 수 있어야 한다.

우리는 여러 경로로 AWS에서 제공하는 클라우드 서비스가 위의 요구 사항을 만족한다는 것을 알고

있었기 때문에 별다른 이견 없이 AWS를 이용하기로 했다. 하지만 팀원 중 누구도 직접 AWS를 경험해

본 사람은 없어서 팀원들과 함께 AWS에 대한 조사를 진행하기로 했다. 우리가 조사한 내용이 이번

장에 담겨있다.

이번 장에는 AWS에서 제공하는 각 서비스에 대한 세부적인 기능과 사용법보다는 AWS가 인터넷

서비스의 인프라로 사용하기에 적당한 특징을 제공하는지 확인하는 정도로 살펴볼 것이다. 세부적인

기능과 사용법은 2장에서 직접 구축하면서 배워가겠다.

1.1 _ AWS의 특징

AWS 클라우드를 이용하는 가장 큰 이유는 아마존이 전 세계적으로 구축해 놓은 시스템과 네트워크

자원을 대여해서 사용하기 위해서다. 단순히 컴퓨팅 자원을 대여한다는 점에서만 보면 기존

IDC(Internet Data Center)에서 호스팅을 받는 것과 별 차이가 없다고 생각할 수 있겠지만,

클라우드는 소프트웨어 방식으로 자원을 정의해서 사용할 수 있다는 큰 차이가 있다.

아파치 웹 서버 소프트웨어를 보자. 우리는 단지 아파치 웹 서버 프로그램을 실행하는 것으로 웹

서비스를 할 수 있다. 접속하는 사용자의 수가 더 많다면 프로세스의 개수를 늘리기만 하면 된다.

서비스가 더는 필요 없다면 서버 프로그램을 중단하면 된다. 실행과 중단, 확장에 거의 비용이 들지

않을뿐더러 단지 몇 개의 실행 명령과 설정 파일로 복잡한 일을 처리할 수 있다.

4 AWS를 이용한 글로벌 서비스 인프라 설계

AWS를 이용하면 마치 소프트웨어를 다루는 것처럼 CPU, 메모리, 디스크, 네트워크 자원을 자유롭게

사용할 수 있다. 다음은 AWS가 자원을 운용하는 방식을 설명한 그림이다.

[그림 1-1] AWS를 이용한 인프라 자원의 소프트웨어화

AWS가 서비스하는 모든 클라우드 자원은 AWS API(Application Programming Interface)를

이용해서 소프트웨어를 다루듯이 간단하게 관리(create(생성), remove(삭제), update(변경),

monitoring(모니터링))할 수 있다. 탄력적으로 자원을 운용할 수 있는 점이 AWS의 가장 큰

장점이라고 할 수 있다.

대신 소프트웨어처럼 다뤄야 하므로 제대로 운영하려면 어느 정도의 개발 능력이 필요하다. AWS에서

제공하는 웹 기반의 관리 도구인 AWS 콘솔(console)에서 제공하는 Web UI로 운용할 수 있기는

하지만, AWS 콘솔만으로는 제대로 운영하기가 어렵다. 결국, AWS를 이용해서 서비스하려면

소프트웨어 개발과 인프라 모두에 대한 통합된 지식이 있어야 한다.

AWS가 물리적인 인프라를 압축하고 숨겨버린 덕분에 인프라와 소프트웨어 개발의 역할도 바뀜으로써

개발자와 관리자 그리고 운영자가 압축되는 DevOps 조직이 탄생한다. DevOps에 대해서는 4장에서

자세히 다루겠다.

인프라가 소프트웨어화 되고 탄력적으로 운용할 수 있게 되면서 “사용한 만큼만 비용을 지급할 수

있다”는 장점도 누릴 수 있게 됐다. 물리적인 하드웨어는 사용한 만큼이 아닌 구매한 만큼 비용을

지급해야 한다. 10만큼의 성능이 필요한데 수요를 100으로 잘못 예측해서 100만큼의 성능을 가진

하드웨어를 구매했다면 100만큼의 비용을 지급해야 한다. 나머지 90의 비용은 낭비하는 게 될 것이다.

01 _ AWS 소개 5

반면 AWS에서는 인프라를 사용한 만큼 비용을 지급할 수 있다. 수요를 100으로 예측했는데

10이었다면? 애초에 수요를 신경 쓸 필요 없이 처음부터 최소한의 자원인 10만큼만 대여하면 된다.

갑자기 사용자가 늘어나서 100만큼 필요하다면 그때 90을 추가로 생성하면 된다.

사용한 만큼 비용을 지급하며 수요에 따라서 탄력적으로 운용할 수 있어서 빠른 전개가 가능하다.

물리적 장비는 정확한 수요 예측이 필요하다. 20억원어치 장비를 구매했는데, 1억 정도의 장비로도

충분한 상황이라고 가정해 보자. 반대로 1억 정도의 장비를 구매했는데, 서비스가 성공해서 장비를

늘려야 할 경우도 있다. 어느 경우에도 빠르게 대응하기가 어렵다. 요즘처럼 서비스가 빠르게 진화하는

상황에서 탄력적인 운용으로 오는 장점은 안정적인 서비스 운영에 매우 중요한 요소다.

1.2 _ IaaS, SaaS, PaaS

AWS는 클라우드 관점에서 3가지 분류의 서비스를 제공한다.

■ �IaaS(Infrastructure�as�a�Service):�시스템과 네트워크와 같은 물리적인 인프라를 서비스 형태로 제공한다. 서버 컴퓨터

를 서비스 형태로 제공하는 것으로 가장 기본이 되는 서비스다. AWS의 EC2, ELB, VPC 등이 대표적인 IaaS 서비스다.

■ �SaaS(Software�as�a�Service): 일반 사용자가 IaaS를 사용하는 이유는 “운영체제를 직접 제어하고 그 위에 소프트웨어를

올려서 서비스하기 위해서”다. 소프트웨어와 운영체제를 일일이 설치하고 설정하는 대신 미리 설치와 설정을 끝낸 상태로

제공하면 더 쉽게 서비스를 만들 수 있지 않을까? 라는 생각에서 IaaS에 소프트웨어까지 패키지로 묶어서 제공하는 서비스

가 SaaS다. RDS(데이터베이스), SQS(메시지 큐), 엘라스틱 캐시(캐시 서비스) 등이 여기에 해당한다. 이 경우 서비스 사용

자는 운영체제와 소프트웨어 설치와 같은 부분을 신경 쓸 필요가 없다. 소프트웨어의 사용에만 신경 쓰면 된다.

어차피 IaaS에 소프트웨어만 설치하면 SaaS가 되는 것이므로(관리 도구도 함께 만들어서 제공해야 하므로 실제로는 그렇

게 간단하지 않다) 사용자가 직접 SaaS를 만들 수도 있다. 간단하게는 APM(Apache, PHP, Mysql)부터 워드프레스나 레

드마인(Redmine)과 같은 이슈 추적 시스템, 데이터베이스까지 모든 것을 만들 수 있다. 실제 AWS는 사용자끼리 SaaS를

거래할 수 있는 마켓플레이스(market place)를 제공하고 있다.

■ �PaaS(Platform�as�a�Service): SaaS를 플랫폼 개념으로 확대한 서비스다. 개발하려면 플랫폼이 필요한데 아예 플랫폼 자

체를 서비스 형태로 제공한다. 예를 들어 웹 서비스를 개발하려면 장고, 루비 온 레일즈(Ruby on Rails)와 같은 소프트웨어

를 설치하고, 코드를 개발한 뒤 깃(git) 등으로 코드 형상을 관리하며 테스트하고 배포하는 등의 모든 과정을 관리해야 한다.

이는 경험 있는 개발자의 손길이 필요한 난이도가 높은 작업이다. PaaS는 이러한 일을 대신 해준다. AWS는 엘라스틱 빈스

톡(Elastic Beanstalk)과 같은 PaaS 서비스를 제공한다.

AWS는 이런 모든 형태의 클라우드를 서비스한다. 이 책에서는 주로 IaaS와 SaaS를 다룰 것이다.


1.3 _ AWS 글로벌 인프라

AWS의 선택을 검토하는 또 다른 결정적인 이유는 “글로벌한 인프라의 제공”에 있다. 우리는 한국과

일본을 포함한 동남아시아, 북미와 남미, 유럽, 전 세계를 대상으로 하는 서비스를 구성하려고 한다.

서비스의 품질을 위해서 지역별로 사용할 수 있는 인프라가 있어야 한다. 일본의 도쿄에 있는 인프라로

미국과 유럽 모두에 서비스할 수도 있겠지만, 네트워크 지연 때문에 서비스의 품질을 보장할 수 없을

것이다.

AWS의 인프라는 크게 리전(region)과 엣지(Edge)로 구분되는 지역 서비스를 제공한다.

■ 리전: AWS는 전 세계에 10개의 리전이 있다. 리전은 인터넷 기반 애플리케이션을 서비스하기 위한 모든 IaaS, SaaS, PaaS

서비스를 제공한다. 완전한 컴퓨팅 파워와 네트워크를 제공하는 IDC(Internet Data Center)라고 보면 된다.

■ 엣지: 이론적으로 리전을 전 세계에 촘촘하게 구성하면 완벽한 서비스 품질을 제공할 수 있을 것이다. 하지만 이렇게 하려면

지나치게 큰 비용이 들어가므로 인터넷 사용자가 많은 10개 지역에 우선 리전을 구축하고 수요에 따라서 리전을 늘려가는

인프라 전략을 사용하고 있다. 이렇게 하면 비용은 절약할 수 있겠지만, 서비스 품질이 떨어지는 지역도 생길 것이다.

이런 지역에서 품질을 확보하기 위해서 “엣지”를 도입했다. 엣지는 AWS의 CDN 서비스인 클라우드프론트(CloudFront)를

제공한다. 이미지와 동영상 혹은 고정된 웹 페이지 등을 엣지에 배포함으로써, 데이터에 대한 접근 속도를 높이는 것으로 품

질을 높일 수 있다. 전 세계 51개의 엣지가 있다.

2016년 1월, 드디어 AWS에서 서울 리전이 추가됐다. 따라서 국내 AWS 사용자가 더는 일본 리전을

사용하지 않아도 된다. 그림 1-2는 서울 리전이 추가된 최신 상태의 리전과 엣지 현황이다.

01 _ AWS 소개 7

[그림 1-2] AWS의 글로벌 인프라(작은 원은 엣지, 큰 원은 리전을 나타낸다.)

인도에 있는 사용자를 대상으로 웹 서비스를 개발해야 한다고 가정해보자. 웹 서버와 데이터베이스

같은 컴퓨팅 자원과 웹 서버가 동적으로 만드는 HTML 문서는 싱가포르에 있는 리전에 배치한다. 반면

PDF, 음악, 이미지 파일, CSS와 자바스크립트 같은 정적이면서 용량이 큰 데이터는 봄베이에 있는

엣지에 둔다. 내려받는 시간이 오래 걸리는 데이터를 사용자와 가까운 지역에 배치함으로써 서비스

품질을 올릴 수 있을 것이다.


[그림 1-3] 리전과 엣지를 이용한 글로벌 서비스 구성 방안

우리 서비스는 대한민국과 일본, 북미 그리고 향후 유럽과 호주 지역을 대상으로 한다. AWS는 이들

지역에 서비스를 전개하기에 충분한 인프라를 제공하고 있다.

1.4 _ AWS 프리 티어 계정 생성

AWS는 ‘가입’해야 사용할 수 있는 인터넷 서비스다. 이 책에 있는 대부분 내용은 AWS에 가입한

상태에서 제대로 활용할 수 있다. AWS는 처음 서비스를 사용하는 사용자를 위해서 일정 기간 무료로

사용할 수 있는 프리 티어 계정을 제공한다. 물론 정해진 사용량 한도에서 무료로 사용할 수 있으며,

사용량을 초과하면 비용을 지급해야 하지만 학습 용도로는 문제없이 사용할 수 있다. 아마존 웹 서비스

공식 홈페이지(http://aws.amazon.com/ko/free/)에서 무료 계정을 만들 수 있다.

사용량을 초과하면 비용을 지급해야 하므로 정식 서비스용으로 사용하면 안 된다. 또한, 무료 사용

기간이 지나면 비용을 내야 하니 주의해서 관리해야 한다. 사용하지 않을 때는 항상 꺼서 만약에

있을지 모를 비용 초과에 대비하도록 한다.

01 _ AWS 소개 9

1.5 _ AWS 대시보드

AWS에 회원 가입하고 로그인하면 다음과 같은 대시보드를 볼 수 있다.

이는 AWS의 많은 서비스를 관리할 수 있게 AWS에서 제공하는 웹 기반의 UI로, 이를 AWS

Management Console이라 부른다. 사용자는 많은 작업을 이 화면에서 처리할 수 있다.

메인 대시보드에는 현재 AWS 서비스 목록이 모두 펼쳐진다. AWS의 서비스가 추가되면 이

대시보드에 계속 추가되며 현재 Preview 중인 서비스는 작은 글씨로 Preview라고 표시돼 있다.

서비스는 총 12개의 카테고리로 분류돼 있으므로 원하는 서비스를 찾을 때 참고할 수 있다.

최상단에는 드롭다운 메뉴가 배치돼 있는데, 제일 왼쪽부터 하나씩 살펴보면 다음과 같다.

■ 오렌지색�육면체�아이콘: 메인 대시보드로 이동한다.

■ AWS: 태그 에디터, 리소스 그룹 메뉴를 선택한다.


■ Services: 최근 사용한 서비스, 카테고리로 나뉜 서비스를 선택할 수 있다.

■ Edit: 자주 사용하는 서비스를 상단 바에 배치할 수 있다.

■ 이름: 계정 관리와 비용, 보안 상태등을 확인할 수 있다.

■ 지역: AWS 리전을 선택한다.

■ Support: 포럼이나 문서, Support center로 이동할 수 있다.

1.6 _ AWS 주요 서비스

AWS의 주요 서비스를 살펴보자. 가장 많이 사용하는 일반적인 서비스는 바로 EC2가 될 것이며

이외에 RDS, VPC 등이 주요 서비스에 포함된다. 주요 서비스에 대해 간략히 살펴보자.

EC2

EC2(Elastic Compute Cloud)는 가장 널리 사용하는 AWS의 서비스다. 물리 환경의 서버 컴퓨터와

일대일로 대응되는 개념이므로 이해하기도 쉽다. CPU, 메모리(Memory), 디스크(Disk)를 포함한

서버 컴퓨터로 이해하면 된다.

EC2는 사용 목적에 따라 6개의 타입으로 분류된다.

[표 1-1] EC2 인스턴스 타입

유형 설명 사용�사례

T 범용 인스턴스 개발 목적으로 사용하는 소규모 서버

M 컴퓨팅, 메모리, 네트워크에 균형 잡힌 인스턴스 다양한 범용 애플리케이션을 운용하는 서버

C 컴퓨팅(CPU) 최적화 이미지, 동영상 처리 등 CPU를 주로 사용하는 서버

R 메모리 최적화 인메모리 디비, 하둡 등 메모리를 주로 사용하는 서버

I 스토리지 최적화 파일 기반의 데이터베이스, 클러스터 파일 시스템 등

G 그래픽 최적화 동영상 및 이미지 처리에 최적화

타입별로 다시 스펙(CPU 타입, 메모리, 디스크 크기 등)이 정해진다. 스펙은 small, medium, large,

xlarge, 2xlarge, 4xlarge, 8xlarge로 분류한다(오른쪽으로 갈수록 높은 스펙이다). 이들 타입과

스펙을 조합해서 인스턴스 유형이 만들어진다. 다음은 컴퓨팅에 최적화된 인스턴스의 유형을 설명하고

01 _ AWS 소개 11

있다. 모두 설명하고 있지는 않지만, 대략적인 EC2 유형의 분류 방식은 이해할 수 있을 것이다.

당연하지만 높은 성능의 유형은 그만큼의 비용을 지불해야 한다.

[표 1-2] 인스턴스 유형별 스펙

모델 vCPU 메모리 스토리지 EBS�처리량�(Mbps)

c4.large 2 3.75 EBS 전용 500

c4.xlarge 4 7.5 EBS 전용 750

c4.2xlarge 8 15 EBS 전용 1,000



AWS 사용자는 서비스 특징에 맞는 인스턴스를 선택해서 사용하면 된다. 예를 들어 이미지나 동영상을

처리한다면 컴퓨팅에 최적화된 c 계열의 인스턴스를 선택하고, 레디스(redis)와 같은 인메모리 데이터

베이스는 메모리에 최적화된 r 계열의 인스턴스를 선택하면 된다.

AMI

AWS는 다양한 종류의 리눅스와 윈도 운영체제를 지원한다. 여기에는 아마존에서 직접 유지/관리하는

표준 운영체제와 사용자가 커스터마이징한 운영체제까지 포함한다. 커스터마이징한 운영체제란

사용자가 애플리케이션과 설정까지 끝낸 상태의 운영체제를 의미한다. APM, Git 서버, 워드프레스,

장고(Django), 레디스 등 다양한 애플리케이션이 탑재된 운영체제를 마켓플레이스에서 찾을 수 있다.

이들 운영체제는 AWS의 독자적인 포맷인 AMI(Amazon Machine Image) 형태로 제공된다.

사용자는 적당한 AMI를 선택해서 실행하는 것으로 EC2 인스턴스를 생성할 수 있다. 반대로 자신의

EC2 인스턴스를 AMI 형태로 만들 수 있다. 이들 AMI는 EC2 인스턴스의 복구나 복제를 위해서

개인적으로 사용하거나 다른 사용자가 사용할 수 있게 마켓플레이스에 공개할 수도 있다.


[그림 1-5] AMI로부터 인스턴스 실행

EC2 인스턴스를 만들기 위해서 Launch Instance를 실행하면 AMI를 선택하는 화면으로 넘어간다.

여기에는 AWS에서 지원하는 표준 AMI를 사용할 수 있으며, AWS 마켓플레이스에서 다른 사용자가

공개한 AMI(추가로 비용을 내야 하는 AMI도 있다)를 사용할 수 있다.

[그림 1-6] AWS에서 제공하는 표준 AMI

01 _ AWS 소개 13

이 AMI로부터 작동하는 운영체제가 뜨는데, 이를 인스턴스(Instance)라고 한다.

[그림 1-7] AMI와 인스턴스들

하나의 프로그램에서 여러 개의 프로세스가 실행되는 것과 유사한 개념으로 인스턴스도 이렇게 운용할

수 있다.

웹 서비스를 만드는 경우를 예로 들어보자. 일반적으로 웹 서비스는 웹 서버 앞 단에 로드 밸런서를

배치해서 두 개 이상의 웹 서버를 로드 밸런싱하는 방법으로 분산 처리와 높은 가용성을 확보한다.

이때 웹 서버들은 같은 운영체제, 애플리케이션, 설정을 가지는데, 웹 서버를 하나 만든 다음에 이를

AMI로 만들어 놓으면 서비스 인프라를 쉽게 관리할 수 있을 것이다. 다음 그림을 보자.

[그림 1-8] AMI를 이용한 서비스 관리

1. AWS 표준 AMI로 인스턴스를 실행한다.

2. 인스턴스에 애플리케이션을 설치하고 설정을 완료한다.


3. 인스턴스로 커스텀 AMI를 만든다.

4. 커스텀 AMI로 서비스 인스턴스를 실행한다.

5. 사용자 요청이 늘어나서 더 많은 인스턴스가 필요하면 4번을 수행하기만 하면 된다.

기본 네트워크 구성 요소

인프라 관리의 절반은 네트워크를 이해하고 이를 바탕으로 한 네트워크의 구성과 네트워크를 구성하기

위한 도구의 유기적인 운용에 있다고 해도 과언이 아니다. AWS 네트워크의 기본적인 구성 요소를

살펴보자. 이들 구성 요소는 책 전체에 걸쳐 계속 등장하므로 용어를 정리하는 차원에서라도 꼭

알아두기 바란다.

Public IP와 Elastic IP

EC2 인스턴스를 만들면 기본적으로 AWS 내부에서만 사용할 수 있는 사설 IP(Private IP)가 할당

된다. 그리고 옵션으로 공인 IP(Public IP) 할당을 요청할 수 있다. Public IP는 인터넷에서 인식할

수 있는 공인 인터넷 주소로 Public IP가 있어야 인터넷과 연결된다.

Elastic IP(EIP)는 Public IP의 다른 형태다. 외부와 통신하기 위해 Public IP를 할당받는 것은

같지만, EIP는 사용자의 소유로 고정된다. AWS 콘솔에서 EIP를 요청하면 Public IP 주소가

할당되는데, 이 IP는 어느 EC2에도 Elastic하게(유연하게) 붙이거나 뗄 수 있다. EIP는 사용자가

소유한 자원이므로 한번 할당된 IP는 변경되지 않는다.

Public IP는 고정된 자원이 아니므로 인스턴스가 종료(shutdown)되면 할당된 Public IP가

사라지고, 인스턴스를 시작할 때 임의의 Public IP가 할당된다. IP가 수시로 바뀔 수 있으므로 일반

사용자를 대상으로 하는 인터넷 서비스에는 사용할 수 없다. 따라서 인터넷 서비스를 목적으로

인스턴스를 사용한다면 반드시 EIP를 할당받아서 사용해야 한다. 인터넷 서비스가 목적이 아닌 관리를

위한 용도로 사용한다면, Public IP를 사용해도 상관없다.

ELB

인터넷 서비스는 높은 가용성과 확장성을 위해서 로드 밸런서(Load balancer)를 이용해 인프라를

구성한다. 보통 하드웨어를 기반으로 한 네트워크 장비를 로드 밸런서로 사용하는데, 네트워크

전문가가 아니라면 사용하기가 어렵다.

01 _ AWS 소개 15

ELB(Elastic Load Balancing)는 AWS에서 제공하는 로드 밸런서 서비스로 관리자는 아마존 콘솔을

이용해 간단하게 로드 밸런서를 설정할 수 있다. ELB의 장점은 사용하기 편하고 탄력적인 대응이

가능하다는 데 있다. 오토 스케일링(Auto scaling) 기능이 있어서 트래픽에 따라 적절한 자원을

할당한다. 서비스 관리자는 트래픽에 대한 걱정 없이 “사용한 만큼만 비용을 내면” 된다.

오토 스케일링(Auto scaling)

소프트웨어에서 오토 스케일링은 일반적인 기능이다. 예를 들어 아파치 웹 서버는 평소에는 적은 수의 프로세스를 유지하다가

사용자의 요청이 늘어나면 프로세스의 개수를 늘려서 늘어난 요청을 처리한다. 반대로 사용자의 요청이 줄어들면 프로세스의

개수도 따라서 줄어들며, 이 과정이 자동으로 이뤄진다.

하드웨어는 물리적인 실체가 필요하고 사용량이 줄어들 때 회수하기가 어렵다는 점 때문에 소프트웨어처럼 오토 스케일링을

적용하기가 쉽지 않다.

AWS는 기존에 하드웨어로 관리하던 로드 밸런서를 소프트웨어 형식으로 제공하므로 쉽게 오토 스케일링을 적용할 수 있다.

ELB도 오토 스케일링이 적용돼 있다. 요청이 늘어나면 자동으로 ELB 인스턴스를 늘려서 늘어난 요청을 처리하고, 줄어들면

ELB 인스턴스를 회수한다. 이 과정은 사용자가 관여할 필요가 없이 자동으로 진행된다.

ELB와 인스턴스는 다음과 같은 구성으로 연결된다. 우리의 서비스도 이 구성에서 크게 벗어나지 않을

것이다.

[그림 1-9] ELB를 이용한 부하 분산

웹 서버군 앞에 ELB를 두고 사용자의 요청을 분산하는 구조다. 이 구조는 분산이 필요한 모든 영역에

적용할 수 있다. 이 구조를 선호하는 이유는 인스턴스의 개수를 늘리고 줄이는 것만으로 사용자의

요청에 대응할 수 있기 때문이다.

팁


VPC

VPC(Virtual Private Cloud)를 이용하면 인터넷(공유 네트워크 - Public Network)상에

인터넷과 격리된 프라이빗(private) 네트워크를 구축할 수 있다. 개인 네트워크처럼 자유롭게

서브넷(subnet)을 나누고, 네트워크 정책을 만들고 여기에 인스턴스와 데이터베이스를 배치할 수

있다. 인터넷으로부터 격리된 상태이므로 보안도 확보할 수 있다. VPC는 따로 자세히 설명하겠다.

시큐리티 그룹

시큐리티 그룹(Security group)은 인터넷으로부터 네트워크의 접근을 제어하는 데 사용한다.

방화벽(Firewall)과 매우 유사하게 동작하는데, 포트(port)와 IP 주소를 기반으로 inbound/

outbound 트래픽에 대한 접근을 허용하거나 차단할 수 있다. 리눅스 운영체제의 방화벽 소프트웨어

인 iptables와 유사하게 작동한다. inbound는 바깥에서 인스턴스로 들어오는 트래픽을 의미하고,

outbound는 인스턴스에서 바깥으로 나가는 트래픽을 의미한다.

관리자는 시큐리티 그룹을 이용해 애플리케이션 그룹별로 방화벽 규칙을 만들어 보안 정책을 관리할

수 있다. 웹 서비스를 예로 들어보자.

[그림 1-10] 시큐리티 그룹을 이용한 네트워크 트래픽 보안

01 _ AWS 소개 17

웹 서버(Web server)의 경우 80 포트와 443 포트는 모든 IP(0.0.0.0/0)에 대해서 허용해야 한다.

반면 22번 포트는 특정 IP(개발자의 IP 등)에 대해서만 허용해야 할 것이다. 이 외의 모든 포트는

막는(DENY : ALL) 방식으로 외부로부터의 침입에 대응할 수 있다. WAS(Web Application

Server)는 웹 서버로부터의 연결만 허용하고, 다른 모든 연결을 차단해야 한다. 웹 서버와 WAS는 각

경우에 동일하게 적용되므로 웹 서버와 WAS에 대한 규칙을 따로 설정해서 저장할 수 있다. 나중에 웹

서버가 추가되면 새로운 시큐리티 그룹을 생성할 필요 없이 기존에 생성한 웹 서버 시큐리티 그룹에

연결하기만 하면 된다.

1.7 _ VPC 네트워크

EC2 인스턴스는 AWS에서 제공하는 VPC에 만들 수 있다. VPC(Virtual Private Cloud)는 각

사용자에게 제공되는 격리된 네트워크 공간으로 인터넷 공간에 나만의 개인 네트워크를 만들 수 있는

기능이다.

VPC를 이용해 최대 /16 범위의 네트워크를 구성할 수 있다. 총 65,531개의 IP를 관리할 수 있는

거대한 네트워크 대역으로 이 네트워크를 /16 ~ /28 범위로 나눠 여러 개의 서브넷을 생성할 수 있다.

VPC 네트워크를 관리하려면 인터넷 게이트웨이(Internet Gateway)를 비롯한 CIDR block과 IP

서브넷 등 구성 요소에 관한 지식이 필요하다. 이들 구성요소를 간단히 살펴본 다음에 VPC에 EC2를

배치하는 방법을 살펴보겠다.

인터넷 게이트웨이

VPC는 인터넷으로부터 격리된 네트워크 공간이다. 따라서 인터넷과 통신하려면 인터넷과

VPC 네트워크를 중계하는 네트워크 구성 요소가 필요하다. 이 네트워크 구성 요소를 인터넷

게이트웨이(Internet Gateway, IGW)라고 한다. 가정이나 회사에 있는 인터넷 공유기라고 보면

된다. 다음은 인터넷 게이트웨이를 설명한 그림이다.


[그림 1-11] 인터넷 게이트웨이를 이용한 인터넷 통신

IGW는 관리할 수 있는 자원이다. 즉 VPC를 만들고 나서 인터넷 게이트웨이를 추가하거나 삭제할 수

있으며, 필요하다면 하나 이상의 IGW를 만들 수도 있다. 예를 들어 다음과 같이 구성할 수도 있다.

[그림 1-12] 두 개의 인터넷 게이트웨이를 배치해 트래픽 분리

01 _ AWS 소개 19

VPC에 두 개의 인터넷 게이트웨이를 만들었다. 하나는 일반 서비스 사용자와 통신하는 데 사용하고,

다른 하나는 개발자 및 관리자와 연결하는 데 사용했다. 그리고 개발자와의 연결은 VPN을

이용함으로써 안전한 통신을 확보한다. 이렇게 트래픽을 분리하면 좀 더 견고한 보안 정책을 수립할 수

있을 것이다.

VPN

VPN(Virtual Private Network, 가상 사설망)은 멀리 떨어진 독립된 네트워크를 하나의 네트워크로 묶기 위해서 사용한다.

VPN을 사용하지 않은 상태에서 다른 네트워크에 있는 컴퓨터에 접근하려면 각 컴퓨터 단위로 포트 포워딩을 설정해야 한다.

상당히 불편할 수밖에 없다. VPN으로 묶인 두 개의 네트워크에서는 각 컴퓨터로 직접 연결할 수 있어서 관리의 효율성을 높

일 수 있다. 또한, 데이터를 암호화하므로 안전한 데이터 통신이 가능하다.

다음은 VPN의 일반적인 구성을 설명한 그림이다.

회사 지역 네트워크 A

회사 지역 네트워크 B

회사 주 네트워크

홈 네트워크

인터넷

[그림 1-13] VPN의 일반적인 구성

이 회사는 글로벌한 사업장을 가지고 있다. 이 사업장들 사이에서 안전하고 효율적으로 데이터를 교환하기 위해 VPN 망을 만

들었다. 또한, 개인의 홈 네트워크와 VPN을 연결함으로써 개인이 어디에 있든지 마치 회사 네트워크에 연결한 것처럼 자유롭

게 작업을(예컨대 스마트 워킹을 실현할 수 있다) 할 수 있다. VPN 구성은 5장에서 자세히 다루겠다.

팁


IP 주소와 IP 서브넷

여러 사람이 참여하는 네트워크에서 정보를 주고받으려면 서로를 유일하게 식별할 수 있는 어떠한

값이 있어야 한다. 사람이라면 주민등록번호가 되겠고, 건물이라면 주소가 되겠다. 인터넷에 연결된

노드(컴퓨터) 역시 통신하려면 각 노드를 구별할 수 있는 유일한 식별 값이 있어야 한다. 이때

사용하는 값이 인터넷 주소(IP Address)다. 인터넷에서는 32bit의 인터넷 주소를 이용해서 노드를

식별한다. 232개의 노드를 식별할 수 있으므로 대략 40억 개의 노드가 참여하는 컴퓨터 네트워크를

구성할 수 있을 것이다.

인터넷 주소(IP 주소)는 단순한 숫자로 표현할 수 있는데, 이렇게 해서는 대규모의 노드를 효과적으로

관리할 수 없다. 상대편 노드를 찾기 위해서 213491011을 기억하고 입력해야 한다고 생각해 보자.

대량의 데이터를 구조화하는 가장 일반적이고 가장 쉬운 방법은 “계층화”하는 것이다. IP 주소 역시

클래스(class)라고 부르는 계층으로 나눠서 관리한다. 클래스는 A부터 D까지 4단계로 구성된다.

인터넷 주소를 클래스로 나눠서 관리하려면 어딘가에 클래스 정보를 저장하고 있어야 한다. 인터넷

주소는 주소 공간의 일부를 이용해서 클래스를 구분한다.

인터넷 주소는 8bit씩 나눠서 xxx.xxx.xxx.xxx와 같이 관리하는데, 이 중 가장 앞에 있는 비트를

이용해서 클래스 A부터 클래스 D까지 구분한다. 다음 그림을 보면 쉽게 이해할 수 있을 것이다.

[그림 1-14] IP 클래스

첫 8bit 중에서 4개 비트를 이용해 클래스를 계산한다. 0이면 A, 10이면 B, 110이면 C, 1110이면

D 클래스다. 클래스가 정해지면 네트워크(Network)와 호스트(Host)영역이 결정된다. 네트워크는

조직(회사, 국가 등)에 할당할 수 있는 네트워크의 개수이고, 호스트는 각 네트워크에서 관리할 수

있는 호스트(네트워크에 연결할 수 있는 컴퓨터) 개수를 나타낸다.

01 _ AWS 소개 21

즉 클래스 A의 인터넷 주소는 7bit 크기(128개)의 네트워크를 할당할 수 있으며, 각 네트워크에서

관리할 수 있는 호스트의 개수는 224(약 1,600만)개다. 1,600만이면 국가나 대규모 인터넷

서비스업체에서 사용할 수 있는 크기로 128개의 국가나 서비스 업체에 할당할 수 있다. B, C 클래스도

같은 방법으로 할당할 수 있는 네트워크와 관리할 수 있는 호스트의 개수를 계산할 수 있다. D

클래스는 멀티클래스 주소로 따로 예약돼 있어서 표에서 제외했다.

[표 1-3] 클래스별로 관리할 수 있는 네트워크 개수와 호스트 개수

클래스 네트워크�갯수 호스트�갯수 IP�범위

A 클래스 127개 약 16,000,000 개 1.0.0.1 ~ 126.255.255.254

B 클래스 16,000개 약 65,000개 128.1.0.1 ~ 191.255.255.254

C 클래스 약 2,000,000개 254개 192.0.1.1 ~ 223.255.255.254

기업이나 가정에서는 주로 보안이나 관리상의 이유로 인터넷에서 격리된 사설 네트워크를 구축해서

사용하기도 한다. 이들 사설 네트워크는 인터넷으로부터 격리되므로 내부에서만 사용하는 별도의

인터넷 주소를 따로 할당해서 사용한다. 이를 사설 IP라고 한다.

인터넷 주소체계는 클래스별로 사설 네트워크 구축을 위한 인터넷 주소를 따로 떼어 놓고 있다. 다음

표에 사설 인터넷 주소 범위를 정리했다. 네트워크 규모에 따라서 적당한 주소 범위를 사용하면 된다.

[표 1-4] 사설 인터넷 주소의 호스트 크기와 인터넷 주소 개수

인터넷�주소�범위 호스트�크기 인터넷�주소�개수 CIDR

10.0.0.0 ~ 10.255.255.255 24bit 16,777,216개 10.0.0.0/8

172.16.0.0 ~ 172.31.255.255 20bit 1,048,576개 172.16.0.0/12

192.168.0.0 ~ 192.168.255.255 16bit 65,356개 192.168.0.0/16

CIDR은 인터넷 주소로 구성되는 네트워크를 나눠서 관리하기 위한 표기법이다. CIDR을 완전히

이해하려면 약간의 부연 설명이 필요한데, 여기에서는 간단히 언급하고 넘어가겠다.

CIDR은 10.0.0.0/8과 같은 형식으로 표기한다. 슬래시(/) 뒤에 있는 숫자는 고정된 네트워크의 비트

크기를 의미한다. 예를 들어 10.0.0.0/8이라면 앞의 8bit인 10은 고정되는 네트워크 아이디로, 나머지

24bit는 호스트 영역으로 사용할 수 있다. 10.0.0.1부터 10.255.255.254 영역에 있는 1,600만개의

아이피 주소를 사용할 수 있는 네트워크라는 의미다.


10.1.0.0/16 이라면 10.1이 고정되고 나머지 16bit를 호스트 영역으로 사용할 수 있다. 10.1.0.0부터

10.1.255.254까지 약 65,000개의 사이트를 관리할 수 있다. 우선은 이 정도로도 VPC 네트워크를

구성하는 데 문제는 없을 것이다.

VPC 네트워크도 인터넷으로부터 격리된 독립적인 네트워크이므로 사설 IP를 이용해서 구성해야

한다. AWS는 VPC 네트워크를 위해서 10.0.0.0/16 네트워크를 할당한다. 65,000개의 노드를 관리할

수 있는 크기인데, 하나의 네트워크에서 모든 인스턴스를 관리할 수 없는 노릇이니 이를 더 작은

네트워크로 나누어서 관리한다. 이 작은 네트워크를 서브넷이라고 한다. 관리자는 VPC의 관리 기능을

이용해서 하나 이상의 서브넷을 만들어서 네트워크를 관리하면 된다.

우리는 VPC를 조사하면서 향후 다음과 같은 방식으로 VPC 네트워크를 운용하기로 계획을 세웠다.

[그림 1-15] VPC를 이용한 서비스 네트워크 서브넷 운용

예를 들어 10.1.0.0/16 네트워크를 할당받았다고 가정해보자(관리자는 AWS 콘솔에서 자신이

할당받을 주소의 범위를 설정할 수 있다). 이 네트워크는 다시 10.1.0.0/24, 10.1.1.0/24,

10.1.2.0/24와 같이 나눈 다음에 웹서버, WAS, 분석 서버 등의 용도에 따라서 24bit로 구성된

서브넷에 배치하면 된다. 총 254개의 서브넷을 만들 수 있고, 각 서브넷은 254개의 노드를 수용할 수

있으니 웬만한 규모의 서비스를 운영하는 데 부족함이 없을 것이다.

아마존 웹 서비스를 이용한 글로벌 서비스 인프라 설계 : 효율적인 aws...

Documents