728x90
728x90
Aurora 개요 오로라는 AWS 에서 자체적으로 만든 기술이다. Aurora 데이터베이스에는 호환 드라이버가 존재하여 PostgreSQL 과 MySQL 과 호환된다. 오로라는 클라우드에 최적화되어 MySQL 이나 PostgreSQL 에 비해 각각 5배, 3배 성능이 더 좋다. 다른 방식으로도 오로라의 성능을 향상시킬 수 있다. 오로라의 스토리지는 10GB 로 시작하여 128TB 까지 자동으로 증가된다. 읽기 전용 복제본의 경우 최대 15개까지 가질 수 있으며 복제하는 속도도 MySQL 에 비해 훨씬 빠르다. MySQL 보다 장애 조치 속도가 훨씬 빠르다.(multi AZ 등..) 기본적으로 클라우드 네이티브라서 가용성이 높기 때문이다. 비용이 20% 정도 비싸지만 규모 면에서 더 효율적이어서 비용을 많..
RDS 암호화 및 보안 RDS 암호화 사용중이지 않은 데이터 암호화 AWS 키 매니지먼트 서비스인 AWS KMS로 마스터 데이터베이스와 읽기 전용 복제본을 암호화할 수 있다. 마스터 데이터베이스를 암호화하지 않으면 복제본도 암호활 수 없다. Oracle 과 SQL Server 에서 TDE 라고 부르는 투명 데이터 암호화를 활성화할 수 있다. 데이터 베이스 암호화의 대안이라고 할 수 있다. 데이터 전송 암호화 RDS 에서 데이터를 전송할 때 암호화하기 위해서는 SSL 인증서가 필요하다. 데이터베이스에 연결 시 신뢰할 수 있는 인증서를 제공하면 SSL 을 연결할 수 있다. 모든 클라이언트가 SSL을 사용하도록 하려면 PostgreSQL 에서는 rds.force_ssl=1 인 콘솔 매개변수 그룹을 설정해야 하..
RDS 읽기 전용 복제본 및 multi AZ RDS 읽기 전용 복제본 및 multi AZ 둘의 차이를 이해하고 각각의 사용 사례를 제대로 알아놔야 한다. RDS Read Replicas fos read scalabilty 이름 그대로 읽기에 특화된 데이터베이스 복제본을 만드는 것이다. 예를 들어 애플리케이션과 RDS 데이터베이스 인스턴스가 있다. 애플리케이션은 데이터베이스 인스턴스에 대해 읽기와 쓰기를 수행한다. 데이터베이스 인스턴스가 너무 많은 요청이 쏠려서 스케일링이 필요로 하다. 특히, 읽기에 해당하는 요청이 너무 많아 읽기만 전용으로 처리해주는 인스턴스가 필요로 한 경우에 읽기 전용 복제본을 만들면 된다. 읽기 전용 복제본은 최대 5개 까지 생성할 수 있으며 동일한 가용 영역 뿐만 아니라 다른 가..
RDS 개요 RDS 는 관계형 데이터베이스 서비스를 나타내며 SQL 문을 언어로 사용하는 Relational Database Service 의 약자이다. SQL 언어를 사용하여 클라우드에 데이터베이스를 생성할 수 있고, 해당 데이터베이스는 AWS 상에서 관리되는 이점을 갖는다. AWS 에서 관리하는 데이터베이스 엔진에는 PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server, Aurora 등이 있다. EC2 인스턴스에 데이터베이스 서비스를 배포하지 않고 독립된 서비스인 RDS 를 사용하는 이유는 뭘까? RDS 는 관리형 서비스로 AWS 가 데이터베이스 뿐만 아니라 여러 기타 서비스를 제공하기 때문이다! 데이터베이스의 프로비저닝이 완전 자동화되어 있고, 운영 ..
Auto Scaling Group - 솔루션 아키텍트용 ASG 기본 종료 정책 아래는 기본 종료 정책에 대한 우선 순위이다. 가장 많은 인스턴스가 있는 AZ을 찾는다. AZ에 여러개의 인스턴스가 존재할 경우 가장 오랫동안 실행된 인스턴스를 종료한다. 아래 그림을 보면 오토 스케일링 그룹이 있고 두개의 가용 영역이 있다. A 가용 영역에는 두 개의 v1 인스턴스와 두 개의 v2 인스턴스가 실행 구성으로 되어 있고 B 가용 영역에는 세 개의 v1 인스턴스가 있다. v1은 가장 오랫동안 실행된 인스턴스이다. 기본 종료 정책에 따라 우선 가장 많은 인스턴스가 있는 A 가용 영역에서 인스턴스를 삭제할 것이다. 또한 네 개의 인스턴스 중에서 가장 오랫동안 실행된 v1 인스턴스를 선택하여 종료시킨다. 기본 종료 정책..
Auto Scaling Group 조정 정책 오토 스케일링 그룹의 스케일링 정책에 대해 살펴보자 동적 스케일링 정책(Dynamic Scaling Policies) 동적 스케일링 정책은 세 가지 유형이 존재한다. 대상 추적 스케일링(Target Tracking Scaling) 가장 간단하고 설정하기도 쉽다. 예를 들어 오토 스케일링 그룹의 모든 EC2 인스턴스 평균 CPU 사용률을 추적하여 40% 대에 머무르게 하고 싶을 경우 사용한다. 즉, 기본이 되는 기준점을 세우고 상시 가용이 가능하도록 하는 것이다. Simple / Step Scaling 대상 추적 스케일링 보다 좀 더 복잡하다. 예시1) CloudWatch 에 전체 ASG 에서 CPU 사용률이 70%를 초과하는 경우, 두 개의 유닛을 추가할 수 ..