카오스랩

[AWS] Aurora RDS 무중단 스케일-업 Aurora는 MySQL 및 PostgreSQL과 호환되는 완전관리형 RDBMS 엔진입니다. 디비 클러스터링이 기본 제공되며 오토스케일을 위한 복제를 자동화할 수 있습니다. Aurora RDS를 운영하다가 Primary 노드를 무중단으로 스케일-업 해야 하는 상황이 발생할 수 있습니다. RDS 중지가 허용된다면 간단히 클러스터에서 인스턴스 클래스를 변경하고 즉시적용을 통해 진행하면 됩니다. 무중단으로 스케일-업을 하기 위해서는 읽기 복제본을 목표 사양으로 생성한 뒤, fail-over를 통해 이 노드를 Primary로 승격하면 됩니다. 기존의 쓰기노드는 자동으로 읽기노드로 변경됩니다. 이 때 장애조치 우선순위 tier가 primary로 수동 승격된 노드가 기존 primary 보다 더 낮을 때는 다시 자동으로 원래의 primary노드로 primary가 복귀되니 주의해야 합니다. 안정적인 작업을 위해서는 승격할 노드의 tier를 교체할 노드의 tier보다 높게 지정해 놓으면 됩니다. tier는 숫자가 낮을수록 우선순위가 높습니다.

[AWS] CloudFront 배포에서 서명된 URL로 접근 제어 설정하는 법 서명된 URL 만들기  - cloudfront에서 프라이빗 컨텐츠에 대한 엑세스 제한을 하기 위해  1단계: CloudFront 키 페어 생성 루트 계정으로 콘솔에 로그인 후, 상단 우측에서 "내 보안 자격 증명>(Continue to Security Credentials)>CloudFront의 키 페어" 에서 생성하여 피시/서버에 다운 받아 둡니다.   IAM 사용자는 CloudFront 키 페어를 만들 수 없습니다. 웹페이지 소스에서 위에서 서버에 저장한 개인키를 읽어서 URL을 서명하고 서명된 URL을 리턴하는 함수를 작성하여 클라이언트에 제공한다.  참조링크: https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/PrivateCFSignatureCodeAndExamples.html  2단계:  CloudFront Distributions -> [해당 CF 배포] -> Behaviors -> Create Behavior -> Cache Behavior Settings:  1. Path Pattern: (예: images/*.jpg 입력하면 images 디렉토리 이하 모든 jpg 확장자 대상 접속 제한 걸림) 2. Restrict Viewer Access(Use Signed URLs or Signed Cookies): Yes 체크  3. Trusted Signers: Self 체크  설정확인: Behaviors 목록에서 필드 값 중, Trusted Signers: 활성  이제 클라이언트가 제한된 경로에 있는 특정 파일을 요청 시 리퀘스트 파라미터에 서명을 스트링을 전달하여 요청받을 수 있도록 구성합니다. 참고: CloudFront용 키페어를 ...

VPC/Subnet 복제시 수정사항 문제: 원본 시스템의 구성요소에 NATGateway가 있다면, CloudFormer로 수집이 안되므로, 생성된 템플릿으로 스택 실행 시 NatGateway가 관련된 라우팅 테이블 생성 단계에서 에러가 발생한다. 해결: 템플릿 내용 중, 에러가 발생한 라우팅넘버 항목에 가서 GatewayId를 InterGateway의 Id로 일단 지정해서 템플릿 에러를 해결한 후, 수동으로 NatGate 생성 및 연결을 해 준다. Security Group 복제시 수정사항 여기서는 VPC/Subnet 생성을 위한 템플릿과 Security Group 생성을 위한 템플릿을 나누어서 생성한 경우에 해당하는 문제입니다. Security Group은 특정 VPC에 종속적이므로 템플릿의 첫 부분에는 VPC 생성을 위한 항목이 존재하고, 이후 보안그룹 생성은 처음 정의된 VPC의 Id를 모두 참조하도록 되어 있어 실행 시 에러가 발생합니다. 해결: 보안그룹 생성 구문에서 참조할 VPC Id를 템플릿 실행 시 파라미터로 입력 받도록 템플릿을 수정합니다. 수정 전 {   "AWSTemplateFormatVersion": "2010-09-09",   "Resources": {     " vpc07134a125a927833a ": {       "Type": "AWS::EC2::VPC",       "Properties": {         "CidrBlock": "10.1.0.0/16",         "InstanceTenancy": "default",         "EnableDnsSupport": "true",         "EnableDnsHostnames...

Amazon은 AWS Certificate Manager(이하 ACM) 서비스를 통해 무료 SSL/TLS 인증서를 발급해 주고 있습니다. ACM에서 발급 받은 인증서는 ELB나 CloudFront에 편리하게 적용하여 사용할 수 있습니다. Amazon 무료 인증서를 사용할 때 몇가지 주의사항에 대해서 살펴봅니다. 인증서 사용 범위 ACM에서 발급 받은 인증서는 외부로 Export가 안되기 때문에 인증서 파일이 필요한 EC2 내부의 웹서버 등에는 사용할 수 없습니다. 반드시 웹서버에 인증서를 설치해야 하는 경우는 현재로서는 ACM 인증서를 사용할 수 없고 구매한 인증서를 사용해야 합니다. 구매한 외부 인증서는 ACM에 가져오기를 하여 ACM에서 발급한 인증서와 동일한 방법으로 ELB, CloudFront에 사용할 수 있습니다. CloudFront용 인증서 CloudFront에 사용할 수 있는 인증서는 반드시 버지니아 리전의 ACM에서 발급받아야 합니다. 동일한 도메인이라도 여러 인증서를 발급 받을 수 있기 때문에 ACM 인증서를 ELB, CloudFront 두 곳에 사용하려면 각 리전에서 동일한 도메인의 ACM 인증서를 발급받아야 합니다. Route53 사용 시 DNS 서비스를 Amazon Route53에서 받을 거라면 인증서 검증방법을 이메일 인증이 아닌 CNAME 인증을 선택하는 것이 편리합니다. 검증방법은 인증서 발급 신청시 선택하게 되고 나중에 변경이 안되므로 처음부터 고려해야 합니다. CNAME 검증방법은 인증서를 갱신할 때 자동으로 갱신해 주므로 갱신 주기마다 검증을 해야 하는 이메일보다 편리합니다.

AWS는 beta 서비스였다는 사유로 슬그머니 CloudFormer를 없애버렸습니다. 대체방법으로 써드파티 솔루션인  Former2  를 권장합니다. CloudFormation은 AWS 리소스를 자동생성할 수 있는 템플릿을 만들고 실행해주는 서비스입니다. 이 CloudFormation의 템플릿 자동 생성기능으로 현재 운영중인 시스템의 리소스 구성도를 만들어 볼 수 있습니다. CloudFormation>스택>스택생성에서, 템플릿을 도구:CloudFormer로 선택하여 생성합니다.  생성 2단계에서 옵션 항목들은 특별한 경우가 아니면 비워둔 채로 진행합니다. t2.small(1vCPU 2GiB) 타입으로 EC2인스턴스가 자동 생성되고 비용은 $21/month정도 발생할 예정이지만, 잠시 사용하고 삭제하는 용도라면 큰 부담이 없습니다. 잠시 후 생성이 완료되면 생성된 스택의 하단 탭:출력에  CustomVPCWebsiteURL를 따라 생성시 지정한 계정정보로 웹페이지를 접속할 수 있습니다. DNS, VPC 등 현재 사용 중인 주요 리소스 항목들을 보여주고 CloudFormer로 수집할 대상을 선택할 수 있습니다. 사실 모든 수집된 항목을 깔끔하게  CloudFormer가  핸들링해 주지는 않습니다. 나중에 복제 생성할 때 에러가 발생하여 진행이 중단될 경우 템플릿을 디버깅하여 에러가 발생하는 부분을 수정해 주거나 리소스 항목 범위를 좁혀서 CloudFormer를 사용할 필요가 있습니다. 수집이 완료되면 S3의 원하는 버킷에 JSON 포맷의 템플릿을 저장할 수 있습니다. 이제 CloudFormation>스택의 템플릿디자인에서, S3 버킷에 저장한 템플릿을 열면  위와 같이 현재 운영중인 시스템의 수집된 리소스 구성도를 보여줍니다. 각 항목별로 세부정보를 볼 수도 있습니다. 현재는 이 다이어그램을 이미지 파일 형태로...

컨테이너 관리 서비스들의 출시 이력 컨테이너 OS 특히 Linux 안에 서로 격리된 여러개의 환경을 제공하여 애플리케이션과 서비스를 가볍게 유지하고 빠른 속도로 실행할 수 있게 해주는 기술입니다. 도커 가장 잘 알려진, Linux 컨테이너 배포 및 관리를 위한 프로젝트 혹은 방법입니다. Kubernetes 구글이 설계하고 리눅스재단이 관리하고 있는 도커를 포함한 컨테이너들에서 어플리케이션 컨테이너의 배치, 스케일링, 운영을 자동화하기 위한 플랫폼을 제공하기 위한 오픈소스 툴입니다. Amazon ECS  컨테이너 관리 서비스이며, 확장성, 성능이 좋으며, 도커 컨테이너를 지원합니다. Amazon ECS 서울리전 출시 2017.10.5 AWS Fargate 출시 2017.12.12 Amazon EKS 출시 2018.6.8 Amazon SageMaker 서울리전 출시 2018.6.28

프라이빗 서브넷의 인스턴스가 외부망 혹은 인터넷에 연결이 필요할 때, NAT 게이트웨이를 사용하여 구성할 수가 있는데요, 그렇다면 NAT 게이트웨이는 AZ 마다 필요할까요? 정답은, "필요할 수도 있고 아닐 수도 있다" 입니다. NAT 게이트웨이는 하나의 AZ에서만 있어도 다른 AZ의 인스턴스가 속한 서브넷을 통해 라우팅이 가능합니다. 그런데, 서로 다른 AZ끼리 통신에는 비용이 발생하기 때문에 이 점을 고려해야 합니다. 결론은, NAT 게이트웨이를 통한 트래픽양이 많을 때는 각각 AZ에 NAT 게이트웨이를 구성하고, 적을 때는 하나의 AZ에만 구성하는 것이 경제적입니다. 주로, 디비서버 등의 yum update 정도 용도라면 하나의 NAT 게이트웨이만 운영하는 것이 좋겠네요~