Let there be Light

☑️ Route53 - 라우팅 정책 종류 살펴보기 (3) #0 Failover(장애조치 기반 라우팅 정책) 아래 그림을 빌려 이 정책이 어떻게 동작하는지 알아보자 여기 중간에 Route 53이 있고 EC2 인스턴스가 있다. 하나는 기본 EC2 인스턴스이고 두 번째 보조 EC2 인스턴스 혹은 재해 복구 EC2 인스턴스인데, 이 경우에는 Health Check과 기본 레코드를 필수적으로 연결한다. Health Check가 비정상이면 자동으로 Route53은 두 번째의 EC2 인스턴스로 failover(장애조치)를 하고 결과를 보내기 시작한다! 그리고 보조 EC2 인스턴스도 Health Check를 연결할 수 있지만 기본이랑 보조 각각 하나씩만 있을 수 있다. 클라리언트의 DNS 요청은 정상으로 생각되는 리소..

Route 53 포스팅이 자꾸 길어지는데 앞의 내용을 쭉 따라오면 이해하기 쉬울 것이다😀👍 #0 라우팅 정책 종류 살펴보기 (2) 1. Latency-based(지연 시간 기반 라우팅 정책) : 지연 시간이 가장 짧은, 즉 가장 가까운 리소스로 리다이렉팅을 하는 정책 지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우에 아주 유용한 정책인데 지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS region에 연결하기까지 걸리는 시간을 기반으로 측정된다. 만약 두 개의 다른 region에 애플리케이션을 배포한다고 해보자. ap-southeast-1과 us-east-1에 각 하나씩 배포한다. 유저는 세계 각지에 있고 Route53에서 지연 시간을 측정한 뒤에 지연 시간이 가장 짧은 가까운 거리의 유저들..

#0 Route 53 - Records TTL (레코드 Time To Live) 아래 그림으로 먼저 설명해보겠다. 클라이언트가 DNS route53와 웹 서버에 접속한다고 가정해보자. myapp.example.com에서 DNS 요청을 보내면 DNS로부터 회신을 받는데 회신 내용으로는 A레코드와 IP주소, 그리고 TTL이 있고 TTL은 300초 정도 된다고 할 때, TTL은 클라이언트에게 300초의 TTL동안 이 결과를 캐시하도록 요청한다. => 클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우, 클라이언트는 DNS 시스템에게 쿼리를 보내지 않아도 된다는 의미 (이미 답변을 캐시에 저장했기 때문에 답을 알고 있다.) 하지만 캐시에도 시간이 소요되니 캐시 TTL이 발생한다. DNS 요청 쿼리를..

이것에 대한건 이전 글에 조금 정리해두었는데 그 부분에 대해서 조금 살펴보고 오면 더 도움이 될 것이다. https://670811.tistory.com/54 AWS Global 인프라에 사용되는 서비스와 기능에 관해 왜 글로벌 애플리케이션을 만들까?🌏 ... 글로벌 애플리케이션은 여러 지역에 배포되는 애플리케이션이다. AWS는 다양한 region과 Edge Location으로 애플리케이션이 배포된다는 의미이다. 글로벌 애 670811.tistory.com #0 들어가기 앞서 DNS란?🔡 DNS는 인터넷의 중추로서 Domain Name System으로 사람에게 친숙한 호스트 이름을 대상 서버 IP 주소로 번역해준다. => 다시 말해 URL과 호스트 이름을 IP로 변환하는 것 예를 들어 웹 브라우저에 ww..

먼저 짧게 정리해뒀던 ElastiCache 개념에 대해 잡아가고 싶으면 이 글을 먼저 읽고 오면 좋을 것이다. https://670811.tistory.com/50#3-elasti-cashe%EC%9D%BC%EB%9D%BC%EC%8A%A4%ED%8B%B0-%EC%BA%90%EC%8B%9C%EB%9E%80? AWS Database에 관해 데이터 구조에 따라 저장하고자 한다면 AWS 데이터베이스를 이용하게 될텐데 이때, 구조를 통해서 효과적인 쿼리와 데이터 검색을 위한 인덱스를 구축할 수 있다. 그리고 데이터셋 간의 관계도 670811.tistory.com #0 ElastiCache란? ElastiCache는 앞서 살펴본 RDS가 관계형 데이터베이스를 관리하는 것과 같은 방식인데 ElastiCache는 캐싱..

#0 RDS Backups 🗂️ RDS 서비스가 자동으로 매일 데이터베이스의 전체 백업을 수행한다. 백업에는 두 가지 옵션이 존재한다. 1. Automated backups(자동 백업) : 트랜잭션 로그의 가장 빠른 백업은 5분으로 설정되어있어서 자동 백업을 통해 언제라도 5분 전으로 복원할 수 있는데 자동 백업의 보존 기간은 1~35일 사이로 설정할 수 있고 이 기능을 만약 사용하고 싶지 않으면 0으로 설정해두면 된다. 2. Manual DB Snapshots(수동 데이터베이스 스냅샷) : 사용자가 수동으로 트리거하는데 이 방법의 장점은 한 백업을 원하는 기간 동안 유지할 수 있다는 점이다. 자동 백업은 위와 같이 만료 기간이 정해져있는데 이 옵션은 원하는 기간 동안 보관할 수 있다. +) 비용 절감 ..

Aurora에 대해 이전에 간단하게 정리해둔 글이 있는데 먼저 읽고 아래의 자세한 Aurora에 대해서 알아가면 훨씬 도움이 될 것이다.👍 ⬇️⬇️⬇️ https://670811.tistory.com/50#1-amazon-aurora AWS Database에 관해 데이터 구조에 따라 저장하고자 한다면 AWS 데이터베이스를 이용하게 될텐데 이때, 구조를 통해서 효과적인 쿼리와 데이터 검색을 위한 인덱스를 구축할 수 있다. 그리고 데이터셋 간의 관계도 670811.tistory.com #0 Amazon Aurora란?🌌 Aurora는 PsotgresSQL이나 MySQL과 호환되도록 만든 데이터베이스이다. (RDS의 MySQL보다 성능이 5배 높고 RDS의 PostgresSQL보다 성능이 3배가 높다.) 특징..

#0 Auto Scaling Group(ASG - 오토 스케일링 그룹)이란?🔎 웹사이트나 애플리케이션을 배포할 때, 웹사이트 방문자가 갈수록 많아지면서 로드가 바뀔 수 있는데 AWS에서 자동으로 증가한 로드에 맞춰 EC2 인스턴스를 추가(스케일 아웃 - Scale Out)하거나 감소한 로드에 맞춰 EC2 인스턴스를 제거(스케일 인 - Scale in)하는 것을 말한다. 또한 다른 특징은 아랫 글처럼 정리할 수 있다. 1. 매개변수값으로 ASG에서 실행되는 EC2 인스턴스의 최대/최소 개수를 보장한다. 2. 로드 밸런서와 페어링하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결된다. 3. 한 인스턴스가 비정상이면 종료하고 이 종료한 걸 대체할 새 EC2 인스턴스를 생성한다. 4. ASG는 ..

전 글에서 다 못 다뤘던 로드 밸런서에 대해 정리해보겠다. #0 Sticky Sesstions👥 Sticky Sesstions는 고정 세션을 실행하는 것으로 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것이다. (2개의 EC2 인스턴스와 3개의 클라이언트가 있는 ALB와 같은 것) 위의 그림으로 흐름을 설명하자면 1번 클라이어트가 요청을 생성해 첫 번째 EC2 인스턴스를 통과하면 로드 밸런서에서 두 번째 요청을 실행할 때 동일한 인스턴스로 이동함을 뜻하고 애플리케이션 밸런서가 모든 EC2 인스턴스 전반으로 모든 요청을 확산하는 것과는 다른 동작이다. 2번 클라이언트에서는 ALB가 두 번째 인스턴스와 통신하면 동일한 인스턴스로 이동하고 3번째 클라..

들어가기 앞서.. 로드 밸런싱이란?⚖️ Load Balancer는 서버로 트래픽을 백엔드 혹은 다운스트림 EC2 인스턴스 혹은 서버들로 고루 분산하여 전달하는 역할을 한다. => 한 가지 주요한 특징은 유저들은 로드밸런서에 연결되면 한 엔드포인트에 연결이 된다는 것만 알고 자신들이 백엔드 인스턴스 중 어떤 것에 연결되어 있는지 알 수 없다🤔💭 로드 밸런싱이 왜 필요할까🤷‍♀️ 1. 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서이다. 애플리케이션에 단일 액세스 지점(DNS)을 노출하게 되고 다운 스트림 인스턴스의 장애를 원활히 처리할수 있다. => 로드 밸런서가 상태 확인 매커니즘이라 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인해준다.(=인스턴스 상태 확인) 2. 우리의 웹사이트의 SSL 종료도 제..