들어가며

요즘 프로젝트에 치여서 인프라 환경과 친하게 지내지 않은것같아 복습삼아 AWS위주로 개념을 정리해보았습니다. 생활코딩님의 개념강의를 쭉 들으면서 자주 사용되는 기능들의 주요 개념위주로만 정리해보았습니다!

ec2

EC2는 AWS에서 제공하는 클라우드 컴퓨팅 서비스입니다.

이 서비스를 통해서 아마존이 각 세계에 구축한 데이터 센터의 서버용 컴퓨터들의 자원을 원격으로 사용할 수 있습니다. 즉, 아마존으로 부터 한 대의 컴퓨터를 임대하는 것입니다. AWS가 제공하는 URL(Public DNS)를 통해 이 컴퓨터에 접근할 수 있습니다.

EC2의 장점은 다음과 같습니다.

용량을 늘리거나 줄일 수 있다. (탄력성)
사용한만큼 지불하므로 저렴하다.
사용자가 인스턴스를 완전히 제어할 수 있다.
보안 및 네트워크 구성, 스토리지 관리 효과적이다.

비용을 고려하여 상황에따라 중지/종료를 할 수 있습니다. 또한 사용량에 따라 이메일 등으로 알림을 받는 등의 조치가 가능합니다. ec2를 종료하는 경우 저장된 데이터가 휘발되기에 조심해야합니다.

S3

Simple Storage Service의 약자로 파일 서버의 역할을 하는 서비스입니다. 일반적인 파일서버는 트래픽이 증가함에 따라서 장비를 증설하는 작업을 해야 하는데 S3는 이와 같은 것을 대행합니다. 트래픽에 따른 시스템적인 문제는 걱정할 필요가 없어집니다. 또 파일에 대한 접근 권한을 지정 할 수 있어서 서비스를 호스팅 용도로 사용하는 것을 방지 할 수 있습니다. 아래는 S3의 주요한 기능적인 특성들입니다.

특징들을 살펴보겠습니다.

많은 사용자가 접속을 해도 이를 감당하기 위해서 시스템적인 작업을 하지 않아도 된다.
저장할 수 있는 파일 수의 제한이 없다.
최소 1바이트에서 최대 5TB의 데이터를 저장하고 서비스 할 수 있다.
파일에 인증을 붙여서 무단으로 엑세스 하지 못하도록 할 수 있다.
HTTP와 BitTorrent 프로토콜을 지원한다.
REST, SOAP 인터페이스를 제공한다.
데이터를 여러 시설에서 중복으로 저장해 데이터의 손실이 발생할 경우 자동으로 복원한다.
버전관리 기능을 통해서 사용자에 의한 실수도 복원이 가능하다.
정보의 중요도에 따라서 보호 수준을 차등 할 수 있고, 이에 따라서 비용을 절감 할 수 있다. (RSS)

S3에서 사용되는 용어를 정리해봅니다.

객체 - object, AWS는 S3에 저장된 데이터 하나 하나를 객체라고 명명하는데, 하나 하나의 파일이라고 생각하면 된다.
버킷 - bucket, 객체가 파일이라면 버킷은 연관된 객체들을 그룹핑한 최상위 디렉토리라고 할 수 있다. 버킷 단위로 지역(region)을 지정 할 수 있고, 또 버킷에 포함된 모든 객체에 대해서 일괄적으로 인증과 접속 제한을 걸 수 있다.
버전관리 - S3에 저장된 객체들의 변화를 저장. 예를들어 A라는 객체를 사용자가 삭제하거나 변경해도 각각의 변화를 모두 기록하기 때문에 실수를 만회할 수 있다.
RSS - Reduced Redundancy Storage의 약자로 일반 S3 객체에 비해서 데이터가 손실될 확률이 높은 형태의 저장 방식. 대신에 가력이 저렴하기 때문에 복원이 가능한 데이터, 이를테면 섬네일 이미지와 같은 것을 저장하는데 적합하다. 그럼에도 불구하고 물리적인 하드 디스크 대비 400배 가량 안전하다는 것이 아마존의 주장
Glacier - 영어로는 빙하라는 뜻으로 매우 저렴한 가격으로 데이터를 저장 할 수 있는 아마존의 스토리지 서비스

요금의 경우 업로드시에는 비용이 발생하지 않고 다운로드 시 비용이 발생합니다.
post, put 메소드가 통상 get, SELECT 메소드에 비해 10배정도 비용이 많이 청구됩니다.(미미할 수 있음)

요금제는 Standard, Standard-IA, One Zone-IA, Amazon Glacier등이 있으며, 각각 용도가 다릅니다. 다운로드가 잦은경우 횟수당 가격이 Standard가 압도적으로 저렴해 다운이 잦은 경우Standard가 유리합니다. Amazon Glacier의 경우 다운로드시 비용과 시간이 매우 크지만 용량당 가격이 저렴하다는 장점이 있어 중요해서 꼭 저장해야하지만 잘 꺼내보지 않는 데이터를 저장할 때 사용됩니다. 이처럼 상황에 맞게 버킷을 선택하여 관리해야 합니다.

CloudFront

캐싱과 CDN 기능을 지원한다.

캐싱

Web Server와 Client 사이에 놓여 있습니다.

Client측에서 요청을 날리면, 먼저 CloudFront가 응답을 받아서 Cloudfront에 해당 캐시 존재 여부를 확인합니다.

캐시가 없는 경우 : Web Server로 요청이 전송됩니다. Web Server는 Cloudfront에 캐시를 생성한 뒤 유저에게 응답을 반환합니다.

캐시가 있는 경우 : CloudFront가 캐시데이터를 이용해서 Web Server를 대신해서 반응해줍니다. 그렇기에 반응속도가 더 빨라지고 리소스도 적게 소모하게 됩니다. 하지만 Origin data가 변경되었는데 Distribution의 데이터가 변경되지 않아 데이터 무결성에 위배될 수 있습니다.

캐시를 컨트롤해서 데이터 무결성을 보완해주어야한다.

Web Server는 캐시의 신선도를 보장해주기 위해 가장 기본적인 방법으로 Cache Age를 적용해서 CloudFront에게 보냅니다. CloudFront는 캐시가 신선하지 않은 경우 Web Server에 요청하게 됩니다. 필요한 경우 캐시를 강제로 무효화할수도 있습니다.(유료이기에 주의)

CDN

넷플릭스, 왓챠를 비롯해 유튜브, 틱톡 등 우리는 지금 끊임없이 쏟아지는 콘텐츠 홍수 속에 살고 있습니다. OTT 서비스는 전례 없는 호황기를 맞았고, AI, 사물인터넷, 자율 주행 등 대용량의 데이터를 주고받는 신기술이 하루가 멀다고 등장하고 있습니다.

이렇게 폭발적으로 증가한 데이터를 지연 없이 처리하기 위해서는 데이터를 분산해서 전달하는 기술이 필수적입니다. 이에 지리적으로 먼 거리에 떨어져 있는 사용자에게 지연 없이 콘텐츠를 분산해 전달할 수 있는 CDN 서비스가 등장하게 됩니다.

Content Delivery Network의 약자인 CDN은 지리적 제약 없이 전 세계 사용자에게 빠르고 안전하게 콘텐츠를 전송할 수 있는 콘텐츠 전송 기술을 의미합니다.

CDN은 서버와 사용자 사이의 물리적인 거리를 줄여 콘텐츠 로딩에 소요되는 시간을 최소화합니다. CDN은 각 지역에 캐시 서버(PoP, Points of presence)를 분산 배치해, 근접한 사용자의 요청에 원본 서버가 아닌 캐시 서버가 콘텐츠를 전달합니다.

각 Region을 Edge Location이라 칭하며 각각 비용이 다릅니다.
기본요금은 따로 없으며 사용량에 따라서 요금이 책정됩니다.(On Demand 요금)
edge location에서 Client에게 데이터를 전송할 때와 Edge Location에서 Origin Server로 데이터를 요청할 때 모두 비용이 발생합니다.

DNS

AWS기능은 아니지만 하기 Route53의 기반이 되며 개발자라면 반드시 숙지해야할 개념입니다.

DNS를 사용하게 된 이유

IP주소를 처음 사용할 때는 주소창에 포트번호만을 사용해서 통신을 진행했습니다.
하지만 인간이 모든 IP주소를 기억하고 사용하기에는 어려움이 있었습니다.
전화번호부에 이름을 저장하듯 도메인에도 이름이 붙게 되었고 붙인 이름을 저장해주는 서버가 바로 DNS(Domane Name Server)입니다.

domain을 직접 구현하기는 까다롭습니다. 그래서 우리는 주로 Hosting이라는 개념을 사용하게 됩니다.

hosting

제공자 등의 사업자가 주로 개인 홈페이지의 서버 기능을 대행하는 것을 의미한다. 즉 서버의 일부 or 전체를 이용할 수 있도록 임대해주는 서비스을 일컫는다.
호스팅에는 웹 호스팅, 서버 호스팅, 클라우드 서버 호스팅이 있으며 이들은 웹, 서버 관리, 비용 부담을 줄일 수 있는 장점을 가지고 있다.

피싱(해킹)

hosting을 사용할 때 보안은 굉장히 중요합니다. 아무런 보안을 취해주지 않으면 '피싱'이 정말 쉬워집니다. 피싱방법은 다음과 같습니다.

ip주소를 피싱사이트로 우회시킨다.(커맨드 한줄로 가능)
우회시킨 사이트를 기존 ip주소를 가진 사이트와 똑같이 클론해둔다.
유저는 같은 사이트로 인식하고 개인정보 등을 작성한다.
작성된 개인정보를 해커가 획득하여 자유롭게 사용할 수 있게 된다.

따라서 '피싱'을 막기위해 꼭 보안설정을 해줄 필요가 있고, 가장 범용적이고 효과적인 방법은 백신 설치 또는 https입니다. 이제는 https가 매우 범용적이기에 https가 아닌 사이트가 있다면 꼭 의심해봐야 합니다.

DNS의 태동 및 원리

DNS가 없던 시절에는 Stanford Research Institide라는 단체에서 전세계의 host파일을 관리했다고 합니다. 하지만 웹이 커지면서 문제가 발생했습니다. 호스트 이름을 사용할 수 없었고, 기존에는 수작업으로 host파일을 갱신했기에 과정에서 많은 시간과 비용이 들었습니다. 점점 한계에 도달하게 되었죠.

1983년 Jon Postel과 Paul Mockapetris가 DNS를 발명하게 됩니다.
DNS 즉, 도메인 네임 시스템(Domain Name System, DNS)은 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었습니다.

DNS의 작동원리

1.웹 브라우저에 www.naver.com을 입력하면 먼저 Local DNS에게 "www.naver.com"이라는 hostname"에 대한 IP 주소를 질의하여 Local DNS에 없으면 다른 DNS name 서버 정보를 받습니다. Local DNS에 정보가 없는 경우 Root DNS에 요청합니다.

Root DNS란?

Root DNS (루트 네임서버) 는 인터넷의 도메인 네임 시스템의 루트 존이다. 루트 존의 레코드의 요청에 직접 응답하고 적절한 최상위 도메인에 대해 권한이 있는 네임 서버 목록을 반환함으로써 다른 요청에 응답한다. 전세계에 961개의 루트 DNS가 운영되고 있다.

2.Root DNS 서버에 "www.naver.com" 를 요청합니다.

3.Root DNS 서버로 부터 "com 도메인"을 관리하는 TLD (Top-Level Domain) 이름 서버 정보 전달 받습니다.

4.TLD에 "www.naver.com" 를 요청합니다.

5.TLD에서 "name.com" 관리하는 DNS 정보를 전달합니다

6."naver.com" 도메인을 관리하는 DNS 서버에 "www.naver.com" 호스트 네임에 대한 IP 주소를 요청합니다.

7.Local DNS 서버에게 www.naver.com에 대한 IP 주소는 222.122.195.6라 응답합니다.

8.Local DNS는 www.naver.com에 대한 IP 주소를 캐싱을 하고 IP 주소 정보 전달합니다.

Public DNS

내 ip를 Public DNS로 변경할 수도 있습니다.

장점 : 빠른 성능을 보장한다. 지원하는 회사를 신뢰한다는 가정하에 보안성이 높다.
단점 : 지원하는 회사가 악용하는 경우 IP경로가 누출될 수 있다.

컴퓨터의 속도를 십분 활용하지 못하고 있었던건 아닐까 궁금해서 찾아보니 국내에서는 이통사 3사에서 제공하는 DNS가 Region이 가까운 등의 이유로 조금 더 빠른것 같습니다.

도메인 분석

blog.naver.com을 기준으로 생각해보면,

blog.naver.com 마지막에 점이 생략되어있으며 그 점을 Root Domain이라 합니다.
.com은 Top Level Domain입니다.
.naver은 Second Level Domain입니다.
blog는 sub Domain입니다.

4개 도매인 각각의 위치에 DNS 서버가 위치하고 있습니다. 한 단계 상위 레벨의 DNS서버는 바로 하위 레벨의 domain name을 보유하고 있습니다.

Route53

Route53은 DNS를 서비스화 한 것입니다. S3, EC2, ELB 등과 연동이 쉽게 가능하다는 장점이 있습니다. 이런것을 가용성과 확장성이 우수하다고 이야기합니다.

특징

가용성과 확장성이 뛰어난 클라우드 기반 DNS 웹 서비스
동적으로 사용자에게 노출될 DNS 레코드 타입과 값 조정
각종 다양한 로드밸런싱 기능 지원
사용자의 요청을 EC2, ELB, S3 버킷 등 인프라로 직접 연결 가능
외부의 인프라로 라우팅하는데 사용 가능
Route 53 트래픽 흐름을 사용하면 지연시간기반 라우팅 가능
Route 53에서는 도메인 이름 등록도 지원 가능

주요 기능

연결 체크 및 Failover기능

Route53의 헬스 체크 기능을 사용하면 상태확인 에이전트가 Route53에 연결된 응용프로그램의 각 엔드포인트를 모니터링하여 서비스의 사용가능 여부를 확인하고 “정상” 또는 “비정상” 상태를 반환합니다.

이를 사용하여 외부 사용자가 직접 접속한 것과 유사한 상황을 시뮬레이션할 수 있습니다.

또한 리소스의 연결 상태가 좋지 않을 때 알람 메일을 수신하도록 각 상태 검사에 대해 CloudWatch 알람을 구성할 수 있습니다.

또한 장애 조치(DNS Failover)가 구성되어 있고 에이전트가 정상이 아닌것으로 판단되면 Route53은 외부 사용자를 정상적으로 연결 가능한 사전 정의된 서버나 지정된 엔드포인트로 연결을 전환시킬 수 있습니다.

고가용성 서비스

연결 상태가 비정상 상태가 반환되면 Route53에서 정상 상태가 아닌 엔드포인트 값을 반환하지 않고 오류 복구 레코드 값에 대해 응답하기 시작합니다.

DNS Failover Record를 활용하면 외부 사용자를 응용프로그램의 오류나 시스템 장애 상황에서 미리 정의된 응용프로그램이나 정상적으로 도달 가능한 외부 리소스로 연결을 전환합니다.

이렇게 응용프로그램이나 시스템의 장애 상황에서 정상적인 엔드포인트(End-Point)로 장애 조치(Failover)를 수행하면 웹 사이트 또는 애플리케이션의 다운 타임을 최소화할 수 있습니다.

지연시간 기반 라우팅 / 가중치 기반 라우팅 / 지역 기반 라우팅 등의 라우팅 옵션이 있습니다.