programmer.cwchoiit

참고자료

IP 표현법

흔히 익숙한 표현 형태인 172.16.254.1 이라는 IP는 어떻게 이런 숫자로 표현되는걸까?

위 그림을 보면 각 숫자별로 8비트로 쪼개진 2진법 표기로 표현하면 저러한 숫자가 나오게된다.

예를 들어, 172는 10101100이고 이는 2^2, 2^3, 2^5, 2^7이 합해진 결과이다.

그리고 이러한 모든 숫자 조합의 개수는 2^32가 된다. 

그리고 이 모든 IP를 3개의 클래스로 구분지을 수 있다.

A 클래스는 맨 앞이 0인 클래스, B는 10, C는 110으로 구분짓는다.

각 클래스가 가지는 네트워크와 호스트(IP 주소)는 몇개가 될까?

A 클래스

A클래스는 앞이 0인 클래스를 의미하고 위 그림처럼 나머지를 Network bit와 Host bit로 나눈다.

그래서 총 네트워크 개수는 2^7개 만큼 존재하고 그 네트워크 각각에는 2^24개의 호스트(IP 주소)를 가진다.

B 클래스

B클래스는 앞이 10인 클래스를 의미하고 위 그림처럼 나머지를 Network bit와 Host bit로 나눈다.

그래서 총 네트워크 개수는 2^14개가 존재하고 그 네트워크 각각에는 2^16개의 호스트(IP 주소)를 가진다.

C 클래스

C클래스는 앞이 110인 클래스를 의미하고 위 그림처럼 나머지를 Network bit와 Host bit로 나눈다.

그래서 총 네트워크 개수는 2^21개가 존재하고 그 네트워크 각각에는 2^8개의 호스트(IP 주소)를 가진다. 

A에서 C 클래스로 갈수록 하나의 네트워크에 가질 수 있는 호스트 수가 줄어듬을 알수있다.

그렇다면 211.11.124.2라는 IP를 가지는 네트워크의 총 IP 개수는 몇개가 될까?

우선, 211이라는 의미는 C클래스를 가르킨다. 211(11010011).

C클래스의 Host bit는 마지막 4번째 자리의 8비트의 조합으로 이루어진 수이므로 255개의 IP를 가질 수 있다.

근데 생각해보자. 내가 집 공유기를 하나 샀는데 식구가 5명이면 한명당 2개씩 전자기기를 가진다고 해도 10개의 IP만 필요한데 255개를 다 가지는게 합리적일까? 너무 비효율적이다. 이러한 비효율적인 문제를 해결하기 위해 나타난게 '서브넷'이다.

서브넷

위 설명처럼 10개의 IP 주소만 필요한데 255개를 다 가지는 비효율적인 문제를 해결하기 위해 네트워크에서도 또 작은 네트워크로 나누자! 라는 취지로 만들어진 게 서브넷(서브 네트워크)이다. 그래서 위 예시를 두고 두개의 서브넷으로 네트워크 하나를 분리할 수 있다.

이렇게 0 - 127까지의 한 개의 서브넷과 128 - 255까지의 한 개의 서브넷. 총 두개의 서브넷으로 네트워크를 나눠쓴다면 아까보다는 훨씬 효율적으로 네트워크를 점유할 수 있다. 그러니까 한 집이 한 네트워크로 255개를 다 가져가고 10개만 사용할 것을 한 네트워크로 두 집이 나눠쓸 수 있게 된 것.

근데 이렇게 서브넷을 나누고 나니 아이피를 눈으로 외우고 저렇게 표현하는 방법이 여간 답답하다. 211.11.124.0 - 211.11.124.127 사이의 서브넷을 간단하게 표현하는 방법이 없을까? 'CIDR' 표기법이다. 

CIDR

CIDR(Classless Inter-Domain Routing)는 클래스 없는 도메인 간 라우팅 기법으로 인터넷상의 데이터 라우팅 효율성을 향상시키는 IP 주소 할당 방법이다. 표기법은 192.168.1.0/22 이런식으로 '/' 뒤에 숫자가 붙는 형태이다. 이 의미는 192.168.1.0을 22비트 네트워크 식별자를 사용한다고 해서 저렇게 표현한다. CIDR를 사용하면 기존 클래스 기반 주소를 사용하는 것에 다음과 같은 이점이 있다.

• IP 주소 낭비 감소
• 데이터를 빠르게 전송
• Virtual Private Cloud 생성
• 슈퍼넷을 유연하게 생성

위 그림을 보자. 211.11.124.0/25라고 표현하면 이는 211.11.124.0 - 211.11.124.127까지의 IP 범위를 말하는것이다. 이건 어떻게 표현한걸까? 우선 앞 211.11.124까지는 이해할 수 있다. 그 다음 0/25에서 0은 00000000을 2진법으로 나타낸 0을 의미하고 /25는 앞에서부터 8비트 + 8비트 + 8비트 + 0을 나타내는 1개의 비트를 합한것이다. 즉, /25라고 하면 8 + 8 + 8에 마지막 8개의 비트 중 하나를 뺀 7개의 비트의 시작(0000000)과 끝(1111111)으로 IP를 할당할 수 있게 된다.

그럼 211.11.124.128/25는 10000000을 2진법으로 나타낸 128부터 8비트 + 8비트 + 8비트 + 1개의 비트인 25를 표현한것이다.

또 다른 예시를 보자.

이것은 4개의 서브넷으로 구분한 것이고 0/26은 00000000을 의미하는 0부터 26은 마지막 앞에 2개의 비트까지 합한 26을 의미한다. 그럼 211.11.124.0/26은 마지막 8개의 비트 범위가 00000000 - 00111111인것을 의미한다.

그럼 한번 예시를 들어보자. 10.0.1.0/16은 IP 대역폭이 어떻게 될까?

10.0.0.0 - 10.0.255.255가 된다.

왜 그러냐면, /16이 의미하는건 고정 비트는 앞에 두개 8비트다. IP로 따지면 10.0까지가 고정 비트가 되고 그 이후 나머지 두 개의 8비트는 시작부터 끝까지를 의미하니까 10.0.0.0  - 10.0.255.255가 된다.

네트워크 트래픽과 대역폭

트래픽이란, 서버를 통해 최종 사용자에게 전달된 데이터의 총량이다. 일반적으로 바이트 단위를 사용한다.

트래픽 계산식: 용량 * 사용자 수 * 개수 
(ex: 4GB 영화 * 10명 * 10개 = 400GB)

네트워크 대역폭이란, 초당 처리할 수 있는 데이터의 양을 말한다. 예를 들면 1차선 도로보다 4차선 도로가 더 많은 차가 다닐 수 있는 것처럼 대역폭이 크면 클수록 초당 처리할 수 있는 데이터의 양이 늘어난다. 

대역폭 = (용량 * 사용자 수 * 8bit) / 처리 시간 = bps

참고자료

Well-Architecture를 위한 필수 요소

AWS 아키텍팅을 하기 전 필수 요소들에 대해 알아보자. 크게 다음 5가지가 있다.

• 운영 우수성
• 보안
• 안정성
• 성능 효율성
• 비용 최적화

운영 우수성

말 그대로 운영을 우수하게 해야한다는 것이다. 운영 시 변경 작업이 생기면 변경 작업을 최소 단위로 나누어 수행해야하고 변경 시 문제가 발생할 경우를 고려해서 롤백을 염두한 변경작업을 수행해야 한다. 운영 프로세스를 자주 개선해서 최적의 환경을 유지하는게 중요하며 장애 시나리오를 만들어서 장애를 통해 배우는 과정 역시 중요하다.

보안

보안이 빠진 시스템은 완전한 시스템이라 할 수 없다. 좋은 보안을 위해선 시스템의 모든 접근에 대한 추적 및 기록이 필요하고 모든 계층(OSI 7 Layer)에 대한 보안을 적용하고 보안을 위한 자동화 구현 설계가 되어야 하며 모든 데이터(전송 중인 데이터, 정적 데이터)를 보호하도록 설계해야 하고 보안 이벤트(침입탐지, DDOS)를 대비해야 한다.

각 계층별 보안 이라는 것은 다음 표처럼 각 구간에서 필요한 보안을 철저히 다루어야 한다는 것이다.

안정성

시스템의 안정성을 높이기 위해 장애에 대한 자동 복구 기능을 구축하고 장애 복구 훈련을 수행하며 가용성을 높이기 위한 수평 확장 설계가 필요하고 스펙 추측이 아닌 확장 가능하도록 설계하며 운영 자동화의 지속적 변경 및 관리가 필요하다.

성능 효율성

좋은 성능을 위해서 최신 기술에 대한 습득 노력과 적용이 필요하며 주기적인 프로토타입을 진행하고 빠른 글로벌 접근 가능한 설계(필요하다면)가 좋고 서버리스 아키텍쳐를 활용해서 성능의 최적화를 해야한다.

비용 최적화

알맞는 가격 약정을 채택해서 비용 누수가 발생하지 않도록 하며 리소스에 대한 Right Size 분석과 클라우드로 마이그레이션을 통해 온프레미스 운영비용을 최소화하고 관리형 서비스를 사용해서 운영비용을 최소화하고 지속적인 월 비용 분석을 통해 비용 최적화를 수행해야 한다.

AWS Well Architecture Infra 

9단계의 AWS 서버 인프라 확장 과정을 통해 본인에게 맞는 인프라를 구축해서 효율적인 서비스를 해야한다.

첫번째 단계

AWS EC2에 Elastic IP를 사용해서 외부에서 접근 가능하도록 설계하고 Route53 서비스를 통해 리소스로 라우팅 해주는 구조이다. 가장 간단한 구조라고 보면 된다.

두번째 단계

이번엔 가용성을 늘리기 위해 EC2 인스턴스를 하나 더 연결하고 다른 AZ를 활용해서 트래픽 관리를 효율적으로 하게끔 설계했다. 두 개의 가용영역 중 한 곳에 단일 RDS 서비스를 사용해서 데이터베이스로 각 EC2가 접근할 수 있도록 설계했다. 이 설계의 단점이라고 할 것 같으면 하나의 데이터베이스만 사용하기 때문에 트래픽이 과도하게 몰릴 때 성능 저하나 복구 대비가 부족하다.

세번째 단계

두번째 단계에 확장해서 RDS 서비스를 하나 더 만들고 Master - Slave 관계를 구축해서 Master에서 장애가 발생하는 경우 Slave쪽으로 Failover할 수 있도록 구현했다. 위 두번째 단계의 단점인 장애복구를 다룬 단계이다.

네번째 단계

위 단계에서 로드밸런서를 도입하여 적절한 부하분산과 트래픽 처리에 용이하게 설계됐다.

다섯번째 단계

위 단계에서 AutoScaling 기술을 통해 EC2의 성능 고려를 추가로 보완했다.

여섯번째 단계

위 단계에서 S3 서비스를 도입하여 정적 컨텐츠를 따로 관리하여 EC2의 리소스 할당에 무리가 가지 않도록 설계했다.

일곱번째 단계

위 단계에 CloudFront 서비스를 도입해서 캐싱을 통해 요청을 처리할 수 있는 가장 빠른 엣지 로케이션으로부터 정적 컨텐츠를 받아올 수 있도록 성능 개선을 했다. 

여덟번째 단계

위 단계에서 정적 컨텐츠 뿐 아니라 동적 컨텐츠까지 CloudFront를 통해 응답받게 설계했다. 로드밸런서를 통해 특정 EC2에 접근할 때 장애가 발생하는 경우 다른 EC2로부터 요청을 처리할 수 있고 캐싱 기술을 통해 더 빠른 응답을 할 수 있게 했다.

아홉번째 단계

위 여덟번째 구조에서 더 나아가 글로벌하게 구조를 변경했다. 

결론

현재 주어진 상황과 프로젝트 규모에 맞게 인프라를 설계하면 된다는 것과 설계 시 필요한 핵심 요소들에 대해 정리해보았다.

참고자료

AWS를 DevOps 개념과 엮어 사용하기 위해서 DevOps 개념에 대해 좀 자세히 이해해 보자.

DevOps란?

Develop + Operation의 합성어로 개발과 운영의 경계를 허물고 통합하고자 하는 문화 또는 철학을 의미한다. 기술이 아니다.

소프트웨어 개발 프로세스와 운영의 모든 단계의 통합과 자동화를 목표로 한다. 즉, 개발 - 빌드 - 테스트 - 배포 - 운영 - 모니터링의 이 영원히 반복되는 사이클을 통합하고 자동화하여 하나의 문화로 만드는 것을 목표로 삼는다고 보면 되겠다.

이 DevOps라는 개념이 도입되기 전엔 배포 방식은 개발과 운영의 철저한 분리 상태를 유지하고 개발자는 운영에 대해 생각하지 않고 운영자는 개발에 대해 생각하지 않는 그런 흐름이 진행됐다. 그러다 애자일(Agile)이 등장하고 기존 소프트웨어 개발 방식인 Waterfall 방식과 힘겨루기를 하다 마침내 DevOps라는 개념이 탄생했다.

애자일이란, 기존 Waterfall 방식과 달리(Waterfall 방식은 순차적으로 하나씩 진행하는 방식이다. 계획 - 요구사항 분석 및 정리 - 개발 - 테스트 - 빌드 - 배포... 이러한 일련의 과정을 물이 아래로 흘러내려가는 폭포수같이 단계가 있다고 해서 Waterfall이라는 이름을 채택한 것으로 널리 알려져 있다) 기간을 아주 짧게 설정하고 그 짧은 기간 동안 수행할 Task들을 하나씩 처리하여 기간 동안의 처리된 개발 변동 사항에 대해 작은 사이즈로 릴리스하는 방식을 말한다. 

이러다 DevOps에 하나가 더 추가되는데 이는 DevSecOps이다.

DevSecOps는 Security가 추가된 합성어로 보안까지 포함하도록 확장된 개념이다. 소프트웨어 배포에 관여하는 모든 사람들이 보안을 최우선으로 하는 문화.

DevOps 핵심

DevOps 업무의 주 대상은 개발자이다. 그래서 개발자가 운영에 참여할 수 있는 환경과 문화를 제공하고 개발자가 비즈니스 로직에 집중할 수 있도록 지원하는 것이 DevOps의 핵심이라고 본다. 개발과 운영 사이에 놓인 커다란 벽을 허무는 것.

DevOps 업무 도메인

DevOps 팀 핵심 지표

Mutable Infra / Immutable Infra 

가변 인프라(Mutable Infra)와 불변 인프라(Immutable Infra)에 대해 알아보자.

가변 인프라(Mutable Infra)

어떤 웹 서버 구축을 예로 들어보자. 웹 서버를 구축하기 위해 물리 서버를 한 대 구입하고 그 안에 웹 서버가 실행가능한 상태를 만들어 웹 서버를 실행한다. 그러다 시간이 흘러 버전 업그레이드 또는 기술의 변경 같은 변경사항이 있을 때 서버는 업데이트 및 수정이 일어난다. 즉, 서버가 이전 환경과 달리 변경된 환경이다. 최초 배포 상태와 다른 상태, 환경으로 배포가 된다. 

이렇게 인프라가 변하는 환경을 가변 인프라라고 한다. 

불변 인프라(Immutable Infra)

위 예시 그대로 웹 서버 구축을 한다고 했을 때 웹 서버를 구축하기 위해 필요한 모든 환경을 구성한 뒤 웹 서버를 실행한다. 그러다 시간이 흘러 버전의 변경 또는 기술의 변경점이 생길 때 기존에 구축된 서버에 변경 사항이 가해지는 게 아니라 아예 새로운 서버를 만들어 기존 서버를 대체한다. 즉, 최초 서버가 배포된 이후 절대 변경되지 않는 형태의 인프라를 불변 인프라라고 한다.

가변 인프라에서 불변 인프라 추세로

가상화 및 클라우드 컴퓨팅이 널리 사용되기 이전 환경은 물리 서버를 중심으로 구성되었다. 물리 서버는 비용도 많이 발생하고 이 물리 서버 위에 서버를 실행하기까지 시간도 많이 소요되는데 이러한 점이 가변 인프라의 시작점이다. 즉, 새로운 서버를 또 구입하는 비용과 구입한 후 설정을 처음부터 다시 하기 부담스러우니 기존 서버를 가지고 변경지점이 생기면 점차 변경해 나가는 것이 더 효율적인 인프라 구축 방식이었다. 

그러나, 이 방식은 어떤 문제를 발생시키냐? 점점 변경이 가해지면 가해질수록 최초 서버의 환경에서 설정의 변화가 많이 생겨난다. 이러한 것을 '스노우 플레이크'라고 표현한다. 그리고 서비스의 다운 타임이 최소화되도록 하니 서버의 문서화보다 변경 - 적용 - 배포가 먼저가 되고 그 결과 문서화가 잘 이루어지지 않고 그러다 보니 최초 배포 환경과 점점 다른 설정 환경으로 변하는 지점 파악이 어려워진다. 이러한 것을 '컨피그레이션 드리프트'라고 한다. 이에 더해서 시스템의 변경은 리스크가 따른다. 변경이 원활히 수행된다면 더할 나위 없이 좋겠지만 어디 그랬던 적이 있는가? 항상 문제는 발생하기 마련이기 때문에 변경하다가 문제가 생기면 이 지점에서 또 병목 현상이 생길 수 있다. 그리고 또 하나의 문제는 이렇게 계속 변경사항이 생기면 생길수록 프로덕션 환경과 동일한 스테이지 환경을 만들기도 어려워진다는 것이다. 그 결과 디버깅 및 테스트하기도 어려워진다는 것.

이러한 단점을 가상화/클라우드 컴퓨팅 기술이 활성화되면서 극복하게 됐다. 클라우드 서비스는 비용이 저렴하고 (사용한 만큼만 지불하면 된다. 이 말은 물리서버를 구비하는 물릴 수 없는 자본지출을 운영지출로 대체할 수 있다는 것이고 그 결과 비용의 효율적인 사용이 가능해진다.) 확장이 수월하고 생성 및 폐기까지 몇 초에서 몇 분밖에 걸리지 않는다.  

불변 인프라의 모든 배포는 검증되고 버전 관리가 된 이미지를 바탕으로 새 서버를 프로비저닝 하여 실행된다. 그 결과 이러한 배포는 서버의 이전 상태에 의존하지 않게 된다. 불변 인프라의 모든 설정 변경은 문서화와 함께 버전 컨트롤에 변경된 이미지를 저장하고 그 이미지를 교체 서버에 배포하는 자동화되고 통일된 배포 프로세스(클라우드 API나 프로그래밍 친화적으로 자동으로 새 서버에 프로비저닝)를 사용하면서 구현된다. 배포된 후 변경 지점이 전혀 없으니 Configuration Drift가 발생하지 않게 된다.

Terraform

불변 인프라를 프로그래밍 친화적으로 새 서버를 프로비저닝 하는 기술 중 하나인 Terraform을 사용해서 AWS에 인스턴스를 새로 프로비저닝해보자. 'Terraform'은 클라우드에 프로비저닝, 리소스 관리를 자동으로 할 수 있게 해주는 인프라스트럭쳐 자동화 도구이다.

여기선 약간의 가정이 필요한데, 기존 배포된 서버가 있고 새 배포를 하는 것이라고 가정하자. 그렇다는 것은 기존 배포된 서버에서 사용하는 데이터가 있었을 것이고 그 데이터는 AWS S3, DynamoDB에서 관리하고 있었다고 가정해 보자. 그렇기에 S3, DynamoDB를 만드는 작업부터 해보자.

AWS DynamoDB 생성

S3 버킷을 만드는 작업은 이전 포스팅에서 해봤으니 생략하고 DynamoDB를 만들어보자.

검색창에 'DynamoDB'를 검색하면 서비스가 나온다. 클릭해 보자.

우측 상단 'Create table' 버튼을 클릭하자.

상단부터 Table name, Partition key를 입력하자.

그 외 설정은 기본 설정으로 한 뒤 생성하면 된다.

Terraform install

이제 Terraform CLI를 이용해야 하니까 먼저 설치를 해야 한다. 아래 링크에 설치 가이드가 있다.

본인은 macOS를 사용하므로 다음 명령어로 설치할 것.

brew update
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

잘 설치가 됐는지 확인하기 위해 다음 명령어를 입력한다.

terraform -help

Usage 관련 내용이 나오면 성공.

Terraform 소스코드

소스에 대한 깊은 내용은 매뉴얼을 참고하자. 지금 여기서 핵심은 코드로 프로비저닝을 할 수 있는 도구를 사용해 보는 것에 의의를 두는 것.

backend.tf

terraform {
  backend "s3" {
    bucket         = "terraform-s3-cwchoi"
    dynamodb_table = "terraform-db-cwchoi"
    encrypt        = true
    key            = "remote"
    region         = "ap-northeast-2"
  }
}

 여기서는 S3, DynamoDB를 설정하는 파일이다. bucket, dynamodb_table에 방금 생성한 버킷과 DB명을 적었다. 

data.tf

data "aws_ami" "amazon_linux2" {
  most_recent = true

  owners = ["amazon"]

  filter {
    name = "name"

    values = [
      "amzn-ami-hvm-*-x86_64-gp2",
    ]
  }

  filter {
    name = "owner-alias"

    values = [
      "amazon",
    ]
  }
}

main.tf

locals {
  common_tags = {
    Environment = "dev"
    Application = "myapp"
    Terraform   = "true"
  }
}

resource "aws_instance" "ec2_example" {
  ami           = data.aws_ami.amazon_linux2.id
  instance_type = "t2.micro"
  tags = {
    Name = "cwchoi-tf-ec2-example"
  }
  subnet_id = "subnet-00a3643ae0bf65523"
}

provider.tf

provider "aws" {

  region  = "ap-northeast-2"

  access_key = "XX"
  secret_key = "XX"

  default_tags {
    tags = local.common_tags
  }
}

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider는 AWS이고 IAM 유저의 access_key와 secret_key를 입력해 주자.

variables.tf

variable "region" {
  default = "ap-northeast-2"
}

이 파일들이 위치한 경로에서 다음 명령어를 입력한다.

terraform init

입력하고 나면 해당 경로에 .terraform.lock.hcl 파일이 자동으로 생성되는 것을 확인하면 된다.

plan 명령어로 어떤 리소스가 생성될지 확인할 수 있다.

terraform plan -lock=false

output:

data.aws_ami.amazon_linux2: Reading...
data.aws_ami.amazon_linux2: Read complete after 1s [id=ami-0007d44f4d00c13b1]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.ec2_example will be created
  + resource "aws_instance" "ec2_example" {
      + ami                                  = "ami-0007d44f4d00c13b1"
      + arn                                  = (known after apply)
      + associate_public_ip_address          = (known after apply)
      + availability_zone                    = (known after apply)
      + cpu_core_count                       = (known after apply)
      + cpu_threads_per_core                 = (known after apply)
      + disable_api_stop                     = (known after apply)
      + disable_api_termination              = (known after apply)
      + ebs_optimized                        = (known after apply)
      + get_password_data                    = false
      + host_id                              = (known after apply)
      + host_resource_group_arn              = (known after apply)
      + iam_instance_profile                 = (known after apply)
      + id                                   = (known after apply)
      + instance_initiated_shutdown_behavior = (known after apply)
      + instance_state                       = (known after apply)
      + instance_type                        = "t2.micro"
      + ipv6_address_count                   = (known after apply)
      + ipv6_addresses                       = (known after apply)
      + key_name                             = (known after apply)
      + monitoring                           = (known after apply)
      + outpost_arn                          = (known after apply)
      + password_data                        = (known after apply)
      + placement_group                      = (known after apply)
      + placement_partition_number           = (known after apply)
      + primary_network_interface_id         = (known after apply)
      + private_dns                          = (known after apply)
      + private_ip                           = (known after apply)
      + public_dns                           = (known after apply)
      + public_ip                            = (known after apply)
      + secondary_private_ips                = (known after apply)
      + security_groups                      = (known after apply)
      + source_dest_check                    = true
      + subnet_id                            = (known after apply)
      + tags                                 = {
          + "Name" = "cwchoi-tf-ec2-example"
        }
      + tags_all                             = {
          + "Application" = "myapp"
          + "Environment" = "dev"
          + "Name"        = "cwchoi-tf-ec2-example"
          + "Terraform"   = "true"
        }
      + tenancy                              = (known after apply)
      + user_data                            = (known after apply)
      + user_data_base64                     = (known after apply)
      + user_data_replace_on_change          = false
      + vpc_security_group_ids               = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

EC2 인스턴스가 생성된다는 결론이 나온다. 왜냐하면 main.tf 파일에서 resource에 aws_instance를 생성하게 설정했기 때문이다.

이제 새 프로비저닝을 하면 된다. 다음 명령어를 수행하자.

terraform apply -lock=false

다음 확인 메시지가 나오는데 'yes'를 입력하면 된다.

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

생성이 완료되면 다음과 같은 결과가 나온다.

aws_instance.ec2_example: Creating...
aws_instance.ec2_example: Still creating... [10s elapsed]
aws_instance.ec2_example: Still creating... [20s elapsed]
aws_instance.ec2_example: Still creating... [30s elapsed]
aws_instance.ec2_example: Creation complete after 33s [id=i-01e423c5447a7a27f]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

살제로 생성이 됐는지 확인해 보려면 AWS Console로 가보자.

잘 생성된 것을 볼 수 있다.

이렇게 생성된 리소스를 이제 삭제해 보자.

terraform destroy -lock=false

아래처럼 물어보는데 'yes'를 입력하면 된다. 당연히 여기서 삭제하는 건 init을 했을 때의 관리되고 있는 리소스들을 삭제하는 것.

...


Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value:

output:

aws_instance.ec2_example: Destroying... [id=i-01e423c5447a7a27f]
aws_instance.ec2_example: Still destroying... [id=i-01e423c5447a7a27f, 11s elapsed]
aws_instance.ec2_example: Still destroying... [id=i-01e423c5447a7a27f, 21s elapsed]
aws_instance.ec2_example: Still destroying... [id=i-01e423c5447a7a27f, 31s elapsed]
aws_instance.ec2_example: Still destroying... [id=i-01e423c5447a7a27f, 41s elapsed]
aws_instance.ec2_example: Destruction complete after 41s

Destroy complete! Resources: 1 destroyed.

실제로 삭제가 됐는지 확인하기 위해 또 AWS Console에서 확인해 보자.

정상적으로 'Terminated' 됐다.

결론

이런 식으로 코드친화적으로 불변 인프라 방식의 프로비저닝을 할 때 'Terraform'을 이용할 수 있다.

변경될 부분에 대해서 기존 인스턴스에서 수정하는 방식이 아니라 아예 'Destroy' 후 변경사항을 적용 후 새로운 버전으로 프로비저닝을 하는 것.

참고자료

이번엔 데이터를 보관하고 읽어들일 수 있는 스토리지인 S3 서비스를 생성해보자.

S3 버킷 만들기

Amazon S3에서 데이터들을 담고 보관하는 장소를 버킷이라고 표현한다. 버킷을 만들어보자.

AWS Console에서 'S3'를 검색한다. 

메인화면 우측 상단에 'Create bucket' 버튼을 클릭한다.

상단부터 버킷 이름과 지역을 선택한다.

'Object ownership'은 기본 설정인 'ACLs disabled'를 선택한다. 이건 모든 오브젝트들은 현재 버킷을 만들고 있는 유저가 전부 Owner인 케이스를 말한다.

Block Public Access settings for this bucket 설정은 'Block all public access'를 선택 해제하고 진행한다. 외부에서 바로 이 Object에 접근해보는걸 테스트해보기 위함이다.

그 외 나머지 세팅 역시 전부 기본으로 설정된 채로 진행하고 하단 'Create bucket' 버튼을 클릭한다. 그러면 다음처럼 버킷이 생성된다.

버킷안으로 들어가보면 여러 탭이 존재하는데 'Objects' 라는 탭이 실제 업로드 되는 데이터들이 모여져 있는 곳이다. 그니까 파일이 3개면 3개 하나하나가 각각 오브젝트 하나하나가 되는 것이다. 여기에 우측 상단 'Upload' 버튼을 눌러 아무 이미지나 업로드해보자.

본인은 이미 이미지 하나를 업로드 한 상태이다.

업로드하고 'Permissions' 탭을 눌러 버킷 정책을 설정할 수 있다. 해당 탭을 눌러 화면을 살짝 내려가보면 'Bucket policy' 부분이 있다. 여기서 버킷 정책을 설정할 수 있다. 'Edit' 버튼을 눌러 버킷 정책을 만들어보자.

다음과 같이 설정한다.

• Version: '2012-10-17'이 의미하는 건 policy language의 현재 버전을 의미한다. 그래서 반드시 이 값을 사용해야 한다. 이 값 말고 하나 더 유효한 게 2008-10-17이 있다. 이건 이전 버전이다. 이 버전은 사용하지 말고 지금처럼 2012-10-17 버전으로 사용하면 된다. 
• Statement: 이 요소는 정책에 대해서 주 요소이다. 필수 값이고 하나 이상의 개별적인 statement가 포함된다. 그러니까 쉽게 말해 정책에 대한 실질적인 적용을 하는 부분으로 생각하면 되겠다.
• Sid: Statement ID의 약자이다. 그냥 policy statement의 identifier라고 생각하면 된다. 없어도 무방하다.
• Effect: 필수값이며 유효한 값은 "Allow", "Deny"가 있고 Resource에 대한 Action을 허가 또는 제어하는 키워드이다. 
• Principal: resource-based JSON policy에서 사용되며 resource 기반의 정책에서는 이 값은 필수이다. 쉽게 말해 Resource에 대한 Action을 행하는 대상을 지정하는 것이다. 예를 들면 AWS account가 '123456789012' '555555555555' 인 두명의 유저에 대해서 적용하겠다하면 다음처럼 작성한다.  

"Principal" : { 
"AWS": [ 
  "123456789012",
  "555555555555" 
  ]
}

더 많은 내용은 공식 홈페이지 참조해서 정책에서 사용되는 JSON elements를 공부해보자.

참고로 이 Principal과 같이 알아야할 게 NotPrincipal이 있는데 이건 부정이다. 즉, Effect가 Allow일 때 NotPrincipal은 제외시키는 것이고 Effect가 Deny일 때 NotPrincipal은 허가하는 것.

• Action: 구체적인 행위를 서술한다. 이 값은 필수값이고 "s3:GetObject"라고 작성하면 S3 서비스의 버킷 오브젝트를 Get하는것에 대한 행위를 말한다.
• Resource: 말 그대로 리소스를 말한다. arn:aws:s3:::my-first-s3-bucket-cwchoi/* 이렇게 적으면 S3 서비스의 my-first-s3-bucket-cwchoi 이름으로 된 버킷의 모든 오브젝트 리소스를 뜻한다.

이렇게 버킷 정책을 만들고 하단 'Save changes' 버튼을 클릭한다. 적용된 화면은 다음과 같다.

이제 방금 올린 Object의 리소스를 HTTPS 프로토콜을 통해 접근해보자. 특정 Object에 들어가면 하단 사진처럼 Object URL이 있다.

들어가보면 이미지가 정상 노출되어야 한다. 버킷 정책에서 모든 유저에게 읽기 권한을 부여했으므로. 

S3 버킷 삭제하기

버킷을 만들었으니 삭제도 해보자. EC2 인스턴스 삭제하는 것과 유사해서 간단하다.

우선 버킷을 삭제하기 전 Object가 있으면 안된다. 그래서 오브젝트를 전체 지우고 버킷을 지워야한다. 

Objects 탭에서 전체 선택해서 'Delete' 버튼 클릭해서 지우자.

다 지웠으면 버킷 페이지로 돌아와서 버킷 선택 후 'Delete' 클릭

참고자료

이제 EC2 인스턴스를 생성하고 해당 인스턴스에 접근해보자. 참고로 EC2에 대한 설명은 다음 포스팅에 있다. 

EC2 인스턴스 생성

우선, AWS Console로 들어가서 'EC2'를 검색해보자. 

결과에 'EC2'가 나온다 선택해보자. 선택하면 EC2 메인 화면이 나오는데 좌측 사이드바에 'Instances'를 클릭하자.

그러면 우측 상단 'Launch Instances'가 나온다. 이 버튼을 클릭하자.

상단부터 인스턴스의 이름을 입력하면 된다. 원하는 이름을 입력하자.

그 다음은 OS 이미지를 선택하면 된다. 나는 Amazon Linux를 선택했다.

인스턴스 타입은 기본으로 설정된 t2.micro를 그대로 사용한다.

Key pair는 외부에서 원격으로 접속하기 위해 만들어주자. 우측에 'Create new key pair'를 클릭하자.

Key pair name을 입력하고 type은 'RSA' format은 .pem으로 선택 후 'Create'

네트워크 세팅은 기본으로 설정된 값 그대로 사용하고 보안 그룹같은 경우 있으면 기존에 있는것을 그대로 사용하던지 새로 만들면 된다.

새로 만들 땐 이건 단순 테스트니까 'Allow SSH traffic from'은 'My IP'로 선택하고 'Allow HTTP traffic from the internet'은 체크하자.

Configure Storage는 기본 설정값 그대로 사용하면 된다.

근데, 한가지 확인할 게 있는데 'Advanced'를 클릭해서 EBS 설정이 Delete on termination이 'Yes'인지 확인해야 한다. 이 옵션은 인스턴스가 종료되면 EBS도 같이 삭제되는 옵션이다.

이렇게 설정을 하고 우측 'Launch Instance' 클릭하면 인스턴스가 생성된다.

이 인스턴스를 SSH를 이용해서 접속해보고 Nginx를 설치해서 기동시켜보자.

SSH로 EC2 인스턴스 접속하기

인스턴스를 생성하면서 .pem키를 생성했었다. 해당 경로에 가서 그 키 파일의 권한을 변경한 다음 키를 이용해서 ssh 접속을 해보자.

chmod 600 yourkeyname.pem

이렇게 파일 권한을 변경한 후 해당 키를 가지고 EC2 인스턴스에 들어가보자.

ssh -i yourkeyname.pem ec2-user@ec2publicipaddress

정상적으로 접속된다면 아래처럼 보일것이다.

[ec2-user@ip-XXXX]$

안으로 들어왔으니 이제 nginx를 설치해보자.

우선 첫번째로, 패키지들을 업데이트 한 후 ngnix를 설치해야 한다.

sudo yum update -y #패키지들을 업데이트
sudo yum install nginx #nginx를 설치

nginx를 설치한 후 활성화 시켜준 다음 실행한다.

sudo systemctl enable nginx #nginx 활성화
sudo systemctl start nginx #nginx 실행

nginx 실행 상태를 확인한다.

sudo systemctl status nginx

위 사진처럼 Active 상태가 active(running)이면 된다. 이렇게 nginx를 실행해 놓으면 된다. 

위에 EC2 인스턴스를 만들면서 HTTP 연결을 가능하게 했었다. EC2의 퍼블릭 IP로 접속하면 Nginx 화면이 노출되어야 한다.

http://ec2-public-ip 접속해보자.

이처럼 화면이 노출되면 성공이다. 

정리

EC2 인스턴스를 직접 만들어서 SSH를 이용해 외부에서 원격으로 접속한 후 Nginx를 설치하고 설치한 Nginx가 정상적으로 실행되는지를 EC2 인스턴스의 퍼블릭 IP로 접속하여 확인해보았다. 이제 만든 EC2 인스턴스를 삭제해보자. 

EC2 인스턴스 삭제하기

삭제하고자 하는 인스턴스를 선택한 후 우측 상단 Instance state 버튼을 클릭하면 'Terminate instance'가 있다.

이 버튼을 클릭하면 인스턴스가 종료된다. 이러면 인스턴스는 삭제된 것. 그리고 인스턴스를 Terminate하면 EBS도 삭제되는 옵션을 체크했으니 이 옵션이 정상적으로 동작하는지 좌측 사이드바 Elastic Block Store의 Volumes을 클릭해보자.

위 사진처럼 아무것도 없으면 된다.

참고자료

AWS IAM이란?

Identity and Access Management의 약자로 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 서비스이다. 

IAM User/User Group/Role/Policy로 구성되어 있다. Policy는 리소스에 접근할 수 있는 접근 권한 정책을 말한다.

Policy는 단일 유저에게, 유저 그룹에게, 역할(Role)에 부여할 수 있다.

정책을 다루는 방식은 크게 두 가지로 분류가 가능하다. 

• RBAC(Role Base Access Control): 역할 기반 접근제어 정책
• ABAC(Attribute Base Access Control): 속성기반 접근제어 정책

RBAC

역할 기반 접근제어 정책은 역할에 정책을 부여해서 해당 역할이 접근할 수 있는 리소스(EC2, RDS,...)에 접근 가능하도록 하는 방식이다.

예를 들어 Role DEV라는 역할을 만들고 해당 역할에 DEV 관련 리소스에만 접근 가능하도록 정책을 설정하면 해당 역할을 부여받은 사용자들은 DEV 관련 리소스에만 접근할 수 있는 방식이다.

다음 그림을 보자. 

역할 A가 할 수 있는 정책을 부여하고 그 역할A에 단일 유저 또는 그룹을 할당하면 해당 단일 유저나 그룹은 그 역할이 할 수 있는 정책에 따라서 리소스에 접근이 가능한 방식이다. 간단하다. 그러나 이런 방식은 역할이 늘어날 때마다 또는 리소스가 추가될 때마다 역할과 정책을 수정하거나 새로 만들어 할당해야 하는 번거로움을 가지고 있다. 이를 해결하기 위해 ABAC이 있다.

ABAC

속성 기반 접근제어 정책은 속성을 기반으로 권한을 정의하는 권한 부여 전략이다. AWS에서는 이러한 속성을 태그라고 한다. IAM User 또는 그룹 또는 역할과 AWS 리소스에 태그를 연결할 수 있다. IAM User/Group/Role에 대해 단일 ABAC 정책 또는 정책 세트를 만들 수 있고 이 정책 세트나 단일 ABAC 정책은 IAM User/Group/Role가 가진 태그와 리소스의 태그가 일치할 때 작업을 허용하도록 설계하는 방식이다. 

위 그림이 가장 가시화가 잘 되는 ABAC을 나타낸 그림이다. 하트 태그가 있는 역할은 하트 태그가 있는 인스턴스 또는 컨테이너(이러한 것들을 전부 리소스라고 한다)에만 접근이 가능하도록 설계하는 방식이다.

RBAC Vs. ABAC

기존 RBAC과 ABAC을 비교해보면 RBAC이 ABAC에 비해 가장 큰 단점은 새 리소스를 추가할 때 해당 리소스에 액세스할 수 있도록 정책을 업데이트해야 한다는 단점이 있다는 것이다. 

예를 들어, 세 개의 프로젝트가 있을 때 각 프로젝트에 대한 IAM Role을 생성한다. 그 다음 각 IAM Role에 정책을 연결해서 역할을 맡을 수 있는 모든 사람이 액세스할 수 있는 리소스를 정의한다. 그러다가 세 개의 프로젝트 중 한 개의 프로젝트에서 새로운 EC2 리소스가 필요하여 EC2를 생성했지만 해당 리소스에 접근할 수 있도록 정책을 업데이트해야 하는데 까먹어서 하지 않은 경우 해당 프로젝트에 참여하는 인원이고 역할을 부여받았어도 해당 리소스에 접근하지 못한다. 즉, 리소스가 변경될 때 업데이트의 빈번함이 단점이 된다.

ABAC은 RBAC에 비해 다음과 같은 이점을 제공한다.

• ABAC은 새 리소스에 액세스할 수 있도록 기존 정책을 업데이트할 필요가 없다. 위 RBAC의 단점에 대한 예시처럼 특정 프로젝트에 새 EC2 리소스가 추가될 경우 해당 프로젝트가 가지는 태그를 새 EC2 리소스를 만들 때 태그로 넣어주면 태그값이 일치하므로 접근이 가능하다.
• ABAC을 사용하면 정책 수가 적어진다. 각 Role에 대해 서로 다른 정책을 생성할 필요가 없기 때문에 생성해야 하는 정책이 더 적어진다. 그에 따라 관리하기도 더 쉬워진다.

AWS Organization

여러 AWS 계정을 조직에 통합하고 중앙에서 관리할 수 있는 계정 관리 서비스이다. 계정 및 리소스 접근제어 관리와 통합 결제 기능을 활용할 수 있고 통합 결제 기능을 활용해서 기업의 예산 관리, 보안 및 규정 준수 요구 사항에 충족할 수 있다. 예를 들어 특정 규제 요구 사항을 충족하는 AWS 서비스에만 접근해야 하는 계정이 있는 경우 이러한 계정을 하나의 조직으로 만들어 넣고 관리할 수 있다.

그림에서 OU는 Organization Unit의 약자로 조직 단위를 의미한다. 이 조직 또한 리소스에 접근하기 위한 정책을 가질 수 있음을 확인할 수 있다.

AWS IAM 계정 생성

루트 계정은 있다고 가정하고 시작한다. 없으면 그냥 만들면 된다. AWS 콘솔에서 'IAM'을 검색하면 다음 사진처럼 'IAM' 서비스가 나온다.

들어가면 좌측 Access management 섹션에서 'Users'를 클릭한다.

메인 화면 우측 상단에 'Create user'를 클릭한다.

다음 화면에서 유저네임을 작성한다.

다음 화면에서는 권한을 설정하는데 우선 어드민 유저로 만들어보자. 그 이후 Policy는 직접 설정하거나 AWS가 만들어 놓은 기존에 있는 Policy를 선택할 수도 있다. 

'Attach policies directly'를 클릭하고 하단에 'AdministratorAccess'를 선택하면 어드민 유저 권한이 생긴다.

다음 화면에서 계정 생성 전 최종 확인화면인데 이 부분에서 태그를 입력할 수 있다. 태그는 위에서 말한 ABAC과 관련된 그 태그다.

Create user 버튼을 클릭하면 유저가 최종 생성된다. 다시 IAM Users 화면으로 넘어가고 방금 만든 유저가 나온다. 이 유저를 클릭해보자. 

들어오면 'Security credentials' 탭에 Console sign-in 이라는 부분이 있는데 이것을 Enable하면 이 유저로 Console에 로그인을 할 수 있는 기능을 부여하는 것이다. Enable한 후 이 유저로 로그인해보자.

우선 'Set password' 부분에 원하는 패스워드를 입력한 후 Apply해보자. 

다 적용을 하면 이 IAM User로 로그인할 수 있다. 그 전에 Account Alias라는 것을 설정해야 하는데 이는 IAM Dashboard로 가보자.

이 Alias를 설정하면 로그인할 때 저 외우기 어려운 Account ID 대신 입력할 수 있다. 설정한 후 로그아웃해서 방금 만든 IAM 유저로 로그인해보자.

Account ID는 위에서 만든 Alias로 입력하고 IAM 유저네임은 방금 만든 유저로 입력해서 로그인하면 정상 로그인이 되어야 한다.

이렇게 IAM 유저를 만들어서 IAM 유저별로 콘솔 로그인이 가능하고 유저마다 역할과 책임을 구분지을 수 있다.

AWS-CLI로 현재 사용자 정보 출력해보기

사용자를 만들었으니까 CLI를 이용해서 AWS와 통신해보자. Part 2에서 AWS-CLI 설치는 했으니 바로 사용해보자.

우선 사용자 별 Access key를 받아야 하는데 그건 Access key를 받고자하는 사용자를 클릭해서 'Security credentials' 탭으로 들어가면 된다.

만들었으면 Access Key ID와 Secret Access Key를 받는데 이것을 잘 저장해서 AWS-CLI에 사용자 설정 시 사용해야 한다.

다음 명령어를 입력하자.

aws configure

그럼 총 4가지를 입력해야 한다. 

• AWS Access Key ID
• AWS Secret Access Key
• Default region name
• Default output format

위에서 만든 Access Key ID와 Secret Access Key를 차례대로 입력하고 지역과 포맷 설정을 해주면 된다. 그럼 현재 로컬에서 AWS-CLI를 사용하는 유저를 지정하게 된다. 잘 지정이 됐는지 현재 유저를 확인해보는 명령어는 다음과 같다. 

aws sts get-caller-identity

다음 결과로 나온다. 내가 설정한 유저 정보가 간략하게 출력된다.

{
    "UserId": "AIDAR654DYS6EIQH7G5C6",
    "Account": "135149110460",
    "Arn": "arn:aws:iam::135149110460:user/chyoni"
}

참고자료

공동 책임 모델은 장애가 발생했을 때 책임이 누구에게 있는지를 규정한 것을 말한다. 

AWS Shared Responsibility Model

위 그림이 AWS가 책임지는 부분과 AWS를 사용하는 고객이 책임지는 부분을 나뉘어 놓은 공동 책임 모델이다. 

AWS가 책임져야 하는 부분으로는 AWS에서 제공하는 모든 하드웨어 관련 인프라에 대한 책임을 지고 관리형으로 제공하는 소프트웨어 중에 모든 책임을 가지고 있다. 

예를 들어, EC2 인스턴스 자체에 문제가 생기는 경우 AWS가 책임을 진다. 그러나 EC2 인스턴스 위에 올라가 있는 애플리케이션에 문제가 생기면 그것은 고객의 책임이다. EC2 인스턴스 위에 올라가있는 구성 시스템에 대한 모든 보안 작업은 고객의 책임이다. OS 업데이트, 보안 패치도 직접 관리해야 하고 인스턴스에 설치한 모든 소프트웨어, 유틸리티 관리는 모두 고객에게 책임이 있다. 

AWS Compliance Programs

AWS 규정 준수 프로그램이다. AWS위에 구축하고자 하는 서비스가 특정 규정을 반드시 준수해야 할 때 그것이 AWS 규정 준수 프로그램에 포함되어 있는지 반드시 확인해야 한다. 

AWS 규정 준수 프로그램은 다음 사진처럼 있다.

마무리

AWS를 사용하기 전 이러한 정보를 알고 서비스를 그 위에 올려야 한다. 

참고자료

AWS에서 제공하는 주요 서비스들을 알아보자. 

AWS에는 무수히 많은 서비스가 있고 위 그림만 봐도 각 카테고리 별 주요 서비스들이 있다. 차근차근 알아보자.

EC2 (Compute)

Elastic Compute Cloud의 약자이다. AWS에서 가장 대표적인 IaaS로 가상 머신 서비스이다. 

다양한 OS를 지원하며 (Linux(CentOS, Ubuntu, RedHat, SUSE), Windows,...) Auto Scaling을 통한 탄력적 확장/축소가 가능하다. 

성능에 따라 다양한 인스턴스의 타입이 있는데 다음 표를 보자.

이러한 목적에 따라 종류(family)가 나뉘어져 있고 예를 들어 다음 그림을 보자.

이처럼 여러 종류가 있는데 이 각 인스턴스 타입이 뭘 의미하는지는 다음과 같다.

• t4g.xlarge: t(인스턴스 패밀리)4(인스턴스 세대)g(추가 기능).xlarge(인스턴스 사이즈)

Lambda (Compute)

서버리스 컴퓨팅 서비스이다. FaaS(Function as a Service)이며 단순히 Function을 생성해서 애플리케이션을 개발하고 실행할 수 있도록 해주는 서비스. 다양한 언어를 지원한다(Go, Java, Python, NodeJS, C#,...)

실제로 서버가 없는 서버리스 서비스이기 때문에 함수가 동작하지 않을 땐 과금되지 않는다. 이에 따라 배치성 작업에 자주 사용된다.

Amazon S3 (Storage)

Simple Storage Service의 약자 S3이다. 객체 스토리지 서비스이며 OS상에서 마운트하여 사용하는 블록 스토리지와는 다르게 Restful API를 사용하여 객체에 엑세스한다. 그렇기 때문에 HTTP/HTTPS 프로토콜을 사용하며 이미지, 동영상과 같은 정적 컨텐츠를 다루는데 자주 사용된다. 저장 가능한 파일 개수 제한은 없지만 단일 파일 크기가 5TB 까지 가능하다.

높은 내구성(99.999999999%)을 가지는 것으로 유명하다. 

S3는 버킷(Bucket)이라는 개념이 있는데 이 버킷이 말 그대로 파일을 저장하는 스토리지라고 생각하면 되고 이 버킷에 들어가는 파일 하나하나를 Object라고 한다. 그래서 사용자는 Object를 REST API를 통해 접근하게 되고 당연히 접근 권한을 제어할 수 있다.

Amazon EBS (Storage)

Elastic Block Storage Service의 약자로 블록 스토리지 서비스이다. OS 내부에서 마운트하여 사용하는 블록 스토리지다. EC2에 붙이거나 뗄 수 있고 SSD/HDD 볼륨 타입을 가지고 있다. EBS는 용량이 부족한 경우 확장이 가능하나 축소는 불가한 점이 있다.

Amazon EFS (Storage)

Elastic File System의 약자로 파일 스토리지 서비스이다. Network File System(NFS) 버전4를 지원하고 그에 따라 여러 곳에서 동시에 같은 파일(공유 스토리지)에 접근하는 경우가 빈번할 때 주로 사용한다. EFS는 EBS와는 다르게 처음에 스토리지를 미리 확보해두지는 않고 사용한 만큼 용량을 차지하고 그만큼만 비용을 지불한다. 

이 EFS 역시 기본적으로 버스팅 기능을 제공하기 때문에 잦은 읽기/쓰기가 발생하는 경우 성능 저하가 발생할 수 있다.

Amazon VPC (Network)

Virtual Private Network Computing의 약자로 IP 대역(CIDR)을 할당하여 가상 사설 네트워크를 구성한다.

가상의 사설망으로 구성하기 때문에 On-Premise에서 사설 네트워크망을 구축하는 것과 동일하게 구축이 가능하다.

서브넷과 라우팅테이블을 이용해서 외부에서 접근 가능한 Public 네트워크 Subnet과 외부에서 접근 불가한 Private 네트워크 Subnet을 구성할 수 있다. 특정 대역을 구분해서 여러 서브넷을 구분할 수 있다.

VPC Flow Log라는 기능을 사용해서 내부에서 일어나는 트래픽을 분석할 수 있다. 

또한, VPC는 사설망으로 구성되기 때문에 서로 다른 VPC끼리 통신이 불가능한게 원칙이지만 여러개의 VPC를 하나의 사설 네트워크망으로 사용할 수 있도록 하려면 VPC Peering/Transit Gateway를 사용하면 된다.

VPC Peering

위 그림처럼 여러 VPC를 연결하여 같은 Region이든 다른 Region이든 서로 통신이 가능하도록 설정하는 것이 가능하다.

Transit Gateway

 Transit Gateway는 여러 VPC간 연결 정책을 중앙에서 관리해주는 서비스이다. 이 Transit Gateway를 사용하면 VPC연결뿐 아니라 VPN Connection을 통해 On-Premise와의 연결 또한 중앙에서 관리가 가능하다. 연결을 해야하는 VPC가 많으면 많을수록 관리적인 측면에서 중앙에서 관리해주는 Transit Gateway가 VPC Peering보다 더 효율적일 것으로 생각된다.

VPC Peering과 Transit Gateway의 차이점을 살펴보자면 다음과 같다.

AWS Cloudfront (Network)

CDN(Contents Delivery Network) 서비스이다. CDN은 클라이언트가 인터넷에 접속하는 곳(지역)과 가까운 곳에서 원본 데이터 서버(Origin)로부터 컨텐츠를 캐싱해둔 서버(Edge Location)에서 빠르게 응답하는 기술(캐싱)이다.

또한, 로드밸런싱과 장애 발생 시 다른 인스턴스로부터 데이터를 가져오는 장애처리 기술도 가지고 있다.

위 설명에서 이 CloudFront를 사용할 때 캐싱의 도움을 받을 수 있다는 것은 새로운 컨텐츠가 원본 서버에 업데이트 되면 그 캐시에 대한 무효화도 일어나야 한다는 것을 암시한다. 이 CloudFront에서는 이 캐시를 무효화하는 것을 Invalidation이라고 하는데 다음 그림과 같다.

Amazon Route53 (Network)

AWS DNS 서비스로 도메인을 구매 또는 등록할 수 있는 서비스이다. 인터넷 트래픽을 리소스로 라우팅을 해주며 여러 라우팅 정책이 있다. (simple, weighted, latency, failover, geolocation,...)

한 블로그에서 아주 잘 만든 라우팅 정책 그림이 있길래 가져왔다. 

Amazon RDS (Database)

Relational Database Service의 약자로 관계형 데이터베이스 서비스이다. 다양한 DB 엔진(Oracle, MariaDB, MySQL, PostgreSQL,...)을 제공하며  즉각적인 DB 컴퓨팅 사이즈 조정이 가능하다. 자동 백업을 통해 가용성과 내구성을 향상시킬 수 있다. 관리 부담 감소와 사용성 편의도 장점으로 볼 수 있다.

Multi AZ 구성을 이용해 장애처리 기술을 보유하고 있다.

RDS Read Replica 구성도 취할 수 있는데 이는 무엇이냐면 Master DB에 부하분산처리를 위해 읽기 전용 Replication을 여럿 만들어 두고 Master DB에 부하 발생 시 읽기 트랜잭션을 Replication에게 위임하는 것이다. 

Amazon DynamoDB (Database)

완전관리형 NoSQL 데이터베이스이다. SSD기반의 무제한 스토리지로 Key/Value 형태로 데이터를 저장한다.

10m/s 미만의 빠른 응답 시간을 가지고 있으며 확장이 단순하고 신속하다. 자동 이중화 백업을 해준다. 

Elasticache (Database)

완전관리형 In-Memory Cache 서비스이다. 인 메모리 캐시에서는 가장 대표적인 기술로 Redis, Memcached가 있는데 그것들의 기술 엔진을 이용한다. Elasticache for Redis는 3가지 클러스터 형태가 존재하는데 다음과 같다.

Amazon WAF (Security)

관리형 웹 방화벽 서비스로 HTTP/HTTPS의 트래픽을 관리하고 부정 접근을 차단하여 고객의 애플리케이션을 보호하는 서비스이다. 방어하는 웹 공격의 종류에는 OWASP TOP 10(SQL injection, XSS,...)을 대응하며 이에 대응할 수 있는 보안 규칙을 설정할 수 있다. WAF는 CloudFront, Application LB에서 기본적으로 사용할 수 있도록 내재되어 있는 서비스이다. AWS 관리형 규칙과 사용자 지정 규칙을 지정할 수 있고 사용자 지정 규칙이라함은 IP, 국가, 헤더 등 차단 규칙을 설정하는 것을 말한다. 

Cloudwatch를 통해 실시간으로 웹 보안 모니터링이 가능하고 AWS 서비스를 활용한 로그 통합(Kinesis Data Firehose, S3)을 하여 분석도 가능하다.

AWS WAF Architecture

1. CloudFront가 웹 애플리케이션 앞 단에서 요청들을 받고, 요청에 대한 구체적인 정보들을 담아서 S3 버킷으로 access log를 보낸다.

2. S3 버킷에 신규 액세스 로그들이 저장될 때 마다 람다 펑션이 동작한다.

3. 람다 펑션은 어떤 IP로부터 기준치 이상의 요청이 들어 왔는지 분석하고, AWS WAF 블랙리스트에 추가한다. AWS WAF는 지정된 기간동안 해당 IP를 블락한다. 이 지정된 기간이 끝나면 AWS WAF는 다시 해당 IP로부터의 요청을 수락한다. 단, 해당 IP로부터의 트래픽 모니터링은 계속된다.

4. 람다 펑션은 분석된 요청들의 갯수나 블락된 IP 주소의 갯수같은 CloudWatch 매트릭들을 퍼블리시한다.

AWS WAF는 수정 가능한 웹 보안 규칙을 정의하고 이것을 통해 웹 애플리케이션으로의 트래픽을 허용하거나 차단하는 기능을 제공한다. 이 서비스에서는 아래와 같이 3가지 규칙을 사용하게 된다.

• 자동 블락킹 - 이 규칙은 악성 요청으로 식별된 IP주소를 추가한다. 이 규칙을 설정함과 동시에 블랙리스트된 IP주소들로부터 들어오는 모든 신규 요청을 드랍하고 람다가 지정한 폐기 기간이 지나 해당 IP를 블랙리스트에서 제거하기 전까지 유효하게 동작한다.
• 수동 블락킹 - 이 규칙은 수작업으로 특정 IP 주소를 블랙리스트에 추가하는데 사용된다. 해당 IP주소는 관리자가 수작업으로 리스트에서 제거하기 전까지 계속 블락된다.
• 자동 카운트 - 지정된 IP로부터의 요청이 바로 블락킹되지는 않고, 준 실시간성으로 요청 갯수가 트랙킹됩니다. 이를 통해 자동 블락 리스트에서 제거된 이후 해당 IP의 행동에 대한 가시성을 제공해 줄 수 있습니다.

Amazon Shield (Security)

관리형 DDOS 차단 솔루션이다. DDOS 공격은 네트워크 트래픽을 의도적으로 과다하게 키워 컴퓨터 자원에 과부하를 거는 공격인데 이 DDOS 공격을 받으면 서비스 성능 저하나 다운 현상이 일어나게 되는데 이를 막기 위해 이 서비스가 있다. 이 서비스는 Standard 형태로 무료로도 사용할 수 있다. 그렇다는 것은 Advanced 형태로 유상 서비스도 있다.

Amazon KMS (Security)

Key Management Service의 약자로 AWS 키 관리 서비스이다. 리소스 데이터 암호화/복호화 기능과 디지털 서명 및 확인 기능이 있다.

Amazon Cloudwatch (Administration/Monitoring)

AWS 사용하면서 가장 많이 보게 되는 서비스 중 하나가 이 CloudWatch 서비스이다. 관리형 AWS 리소스 모니터링 서비스로 AWS 리소스의 상태에 대한 다양한 Metrics 제공을 한다. 이 다양한 리소스 상태에 대한 메트릭을 대시보드로 구성할 수 있고 SNS 서비스를 통한 알람 기능도 있다. 

그러니까 AWS 리소스가 사용되고 모니터링 지표 수집이 되면 CloudWatch가 그 데이터를 받아서 대시보드로 보여주고 특정 Event가 발생하는 경우 SNS 기능을 통해 정해진 유저로부터 알람 기능도 제공할 수 있다. 

Amazon SNS (Administration/Monitoring)

관리형 메시지 서비스. SMS 문자, 푸시 알림, 이메일 등을 통해 고객에게 알림(A2P, Application To Person)을 배포할 수 있으며 A2A(Application To Application)알림을 제공하여 분산 애플리케이션을 통합하고 분리할 수 있다.

Amazon Cloudtrail (Administration/Monitoring)

관리형 이벤트 추적/감사 도구. AWS 서비스가 수행하는 모든 작업들을 이벤트 로그로 기록을 한다. 이 때 이벤트는 AWS CLI, AWS SDK, Console등 API로 수행하는 모든 작업을 말하며 이 CloudTrail을 통해 AWS 인프라 전반에 걸친 계정 활동을 관리 콘솔 UI를 통해 쉽게 검색하여 확인이 가능하다. 로그 양이 굉장히 많기 때문에 로그 분석 지원 서비스인 Athena를 같이 이용하기도 한다.

참고자료

AWS에 대해 이제 하나씩 공부해보자. AWS에는 Region이라는 개념이 있다. 

AWS Region

AWS Region은 서비스가 제공되는 리소스의 지리적 위치를 말한다.

각 Region에는 고유의 코드가 부여되는데 서울의 경우 'ap-northeast-2'이다.

리전 코드를 해석해보면 다음과 같다.

지역(ap)-지리적위치(northeast)-순번(2)

• 지역(ap) - Asia Pacific
• 지리적 위치(northeast) - 북동쪽
• 순번(2) - 2번째로 출시한 지역

참고로 도쿄에 경우 ap-northeast-1이다. 이 코드는 API 사용시에 필요하기 때문에 반드시 알아야 한다.

그리고 또 이 코드를 알아야 하는 이유 중 하나가 Region 별 서비스 제공 유무가 달라지기 때문이다. 그리고 이것을 AWS-CLI를 이용해서 확인할 수 있다. 

AWS-CLI를 이용해서 Region 관련 조회하기

우선, AWS-CLI를 설치부터 해야한다. 이를 설치하기 위해 다음 링크로 들어가보자. https://aws.amazon.com/ko/cli/

해당 링크로 들어가면 OS별 설치 가능한 패키지가 있는데 본인의 OS에 맞게 설치하고 터미널에서 다음 명령어를 입력해보자.

aws

이런 결과가 나오면 AWS-CLI가 잘 설치된 것.

다음 명령어를 입력하면 전체 region을 확인해 볼 수 있으나, 최초로 aws-cli를 설치했으면 사용자 설정부터 해줘야 한다. 이를 하지 않으면 현재 유저를 알 수 없기 때문에 결과를 출력할 수 없는데 사용자 설정은 이후에 해볼 예정이니 지금은 그것을 다 했을 때 이러한 결과가 나온다는 것만 보면 좋을 것 같다.

Region lists

aws ssm get-parameters-by-path --path /aws/service/global-infrastructure/regions --output json

Available Service via specific region

다음 명령어는 서울 Region에서 사용 가능한 서비스들의 목록을 조회하는 명령어이다. 

aws ssm get-parameters-by-path --path /aws/service/global-infrastructure/regions/ap-northeast-2/services --output json

Region 별 서비스 가격

이 Region 개념이 중요한 이유 중 하나가 서비스 별 가격이 상이하다는 점이다. 다음을 보자. 

아래 사진은 다음 링크를 참고하자. https://aws.amazon.com/ko/ec2/pricing/on-demand/

서울의 EC2 가격

미국 동부(버지니아 북부) EC2 가격

AWS Availability Zone

가용영역이라고 하고 'AZ'라고 줄여 부르기도 한다. 이 가용영역은 하나의 Region에서 최소 2개 이상의 AZ로 구성이 된다. 

그러니까 하나의 리전에 최소 2개 이상의 가용영역이 존재한다는 뜻이고, 서울의 경우 현재 4개의 AZ를 운영하고 있다.

가용영역 코드는 Region Code와 문자 식별자를 조합해서 사용한다. 예) us-east-1a, us-east-1b

가용영역이 여러개이기 때문에 다음과 같은 구성을 할 수 있다.

• 가용영역에 따른 서버 다중화
• 가용영역에 따른 DB 이중화

즉, 복수의 가용 영역에 걸쳐 인스턴스를 배포했을 때 하나의 인스턴스에 장애가 발생한 경우에 대비하여, 다른 가용 영역의 인스턴스가 장애가 발생한 인스턴스 관련 요청을 처리할 수 있도록 애플리케이션을 설계할 수 있다. 또한 탄력적 IP 주소를 사용하여 한 가용 영역에서 인스턴스의 장애가 발생한 경우 다른 가용 영역의 인스턴스로 주소를 신속하게 매핑함으로써 인스턴스의 장애를 마스킹할 수 있다.

AWS Edge Location

엣지 로케이션은 Amazon CloudFront, Route53을 위한 캐시 서버들의 모음이다. 무슨 말이냐면 실제 아마존 서버는 미국 Region에서 돌아가지만 한국에서도 빠르게 아마존 사이트를 접속할 수 있는 이유는 이 Edge Location 덕분이다. AWS 전세계 Region에서 빠른 접근성을 위한 글로벌 네트워크 인프라가 Edge Location이고 콘텐츠(HTML, 이미지, 동영상, 기타파일)를 사용자들이 빠르게 받을 수 있도록 전세계에 곳곳에 위치한 캐시서버에 복제해주는 서비스이다.

참고자료

AWS를 공부하기 전 클라우드 서비스에 대해 먼저 이해해보자.

클라우드 서비스란?

인터넷을 통해 IT 리소스와 애플리케이션을 사용자가 원할 때 언제든지 사용한 만큼 (On-demand) 요금을 내는 서비스

클라우드 컴퓨팅의 유형은 크게 보면 2가지가 있다.

• 퍼블릭(Public) 클라우드
  • 사용자가 컴퓨팅 리소스를 소유하지 않는 방식
  • 인터넷을 통해 제공
  • 가상화 기술로 만든 서비스를 그대로 사용
• 프라이빗(Private) 클라우드
  • 특정 조직내에서 컴퓨팅 리소스를 '소유'
  • 사설(Private) 네트워크를 통해 제공
  • 가상 컴퓨팅 기술을 직접 구축

이 두가지 경우로부터 파생되는 경우가 있는데 이는 '하이브리드 클라우드'와 '멀티 클라우드'이다. 하이브리드 클라우드는 퍼블릭 클라우드와 프라이빗 클라우드 또는 데이터센터 간 네트워크를 연결해서 사용하는 방식이다. 데이터 및 애플리케이션을 각 클라우드가 공유한다. 멀티 클라우드는 다수의 퍼블릭 클라우드를 합쳐 사용하는 방식으로 예를 들면 AWS + GCP + Azure를 합친 클라우드 방식을 말한다. 내가 공부할 AWS는 대표적인 퍼블릭 클라우드이다.

클라우드 서비스의 특징

• 탄력성/민첩성: 리소스에 대해 필요할 때 언제든 늘리고, 줄일 수 있고 이를 클릭 몇번으로 가능하게 한다.
• 확장성: 물리 서버를 확장하려면 시간이 오래 걸리며 고정 비용이 발생하는 반면 클라우드는 즉시 확장이 가능하고 역시 사용한 만큼의 비용이 발생한다. 이러한 특징 때문에 서비스에 사용자가 많아져 급증하는 서비스 트래픽에 빠르게 대비가 가능하다.
• 사용한 만큼만 비용을 지불: 전기 요금처럼 사용한 만큼 과금되며, 비용 예측이 가능하다.
• 내결함성 및 재해복구: 클라우드 백업 및 클라우드 DR 구성으로 데이터 손상 등 긴급 상황에 대처가 가능하다.
• 고 가용성: 손쉬운 다중 가용영역 설정에 따라 고 가용성을 보장
• 유지 관리 간소화: 물리적인 리소스를 유지할 필요가 없고, 부분적으로 클라우드 CSP(Cloud Service Provider) 벤더에 위임한다.

사용한 만큼만 비용을 지불하기 때문에 무리한 자본지출(CAPEX)없이 빠른 시도와 회수가 가능해진다. 좀 더 자세히 말하자면 클라우드 서비스를 이용하지 않고 초장부터 서비스의 흥행을 기대해 무리한 물리 서버 구축으로 인해 회수 불가능한 자본지출이 투자됐는데 서비스가 생각보다 성과를 이루지 못하는 경우 회수할 수 있는 비용이 없어지는 반면 클라우드 서비스를 이용해서 사용자가 늘어나면 확장하며 사용한 만큼만 지불하게 하면 운영 지출(OPEX)만으로 서비스 운영이 가능해진다. 

클라우드 서비스 모델(IaaS/PaaS/SaaS)

클라우드 서비스 모델은 크게 3가지가 있다. 

• IaaS (Infrastructure as a Service): 서비스로 제공되는 인프라 스트럭쳐. 즉, 개발사에게 제공하는 물리적 자원을 가상화한다.
• PaaS (Platform as a Service): 서비스로 제공되는 플랫폼. 즉, 개발사에게 제공하는 플랫폼을 가상화한다.
• SaaS (Software as a Service): 서비스로 제공되는 소프트웨어. 고객에게 제공되는 서비스를 가상화한다.

즉, 이 세 가지의 차이는 어디까지 가상화로 제공해 주는가에 있다. 이를 그림으로 좀 더 쉽게 이해해보자.

IaaS는 개발사에게 인프라(물리적 자원)을 가상화하여 제공한다고 했다. 그렇기 때문에 가상의 서버, 스토리지, 네트워크를 제공자가 관리하는 영역으로 구분한다.

PaaS는 개발사에게 플랫폼을 가상화하여 제공한다고 했다. 그렇기 때문에 가상의 서버, 스토리지, 네트워크를 포함하며 OS와 개발 환경까지 제공자가 관리하는 영역으로 구분한다. 따라서 개발사는 그 위에 본인의 애플리케이션과 데이터를 올려두면 된다.

SaaS는 고객에게 제공하는 서비스를 가상화한다고 했다. 그렇기 때문에 서비스가 돌아가기 위해 필요한 모든 것들(서비스 포함) 제공자가 관리한다. 

그에 반면 클라우드를 사용하지 않는 경우 모든 것을 사용자가 관리해야 하는 On-Premise가 있다.

기존 방식인 On-Premise와 클라우드의 차이점은 위 그림으로만 봐도 눈에 띄게 알 수 있지만 비교를 좀 더 깊게 해보자.

(이 외 유사한 명칭인 FaaS(Function as a Service), BaaS(Backend as a Service)가 있다.)