잇!(IT) 블로그

목차 1. ELB 2. 기본 구성 설정 2.1 VPC 생성 2.2 라우팅 테이블 생성 2.3 서브넷 생성 2.4 인터넷 게이트웨이 생성 및 연결 2.5 NAT 게이트웨이 생성 및 연결 2.6 인스턴스 생성 3. ELB 설정 3.1 대상 그룹 생성(Target Group) 3.2 로드밸런서(Load Balancer) 생성 3.3 로드 벨런서 확인 1. ELB - 네트워크를 통한 트래픽을 부하분산하고 여러 대의 EC2 인스턴스에 트래픽을 나눠주기 위한 로드 밸런싱 컴포넌트다. - AWS에서는 여러 곳의 데이터 센터에 EC2 인스턴스를 배치 할 수 있어 ELB로 여러 곳의 데이터 센터로 부하분산할 수 있다. - 또한 로드 밸런서 자체도 부하분산하도록 설계되어 트래픽에 따른 유연한 처리 능력을 향상 시킨다. 2..

- 기본 - RDS - Auto Scaling - 리뷰

■ (참고) 리소스 삭제 및 정리 순서 1. Auto Scaling Group 삭제 2. Launch Template 삭제 3. Application Load Balancer 삭제 4. Target Group 삭제 5. EC2 Instance 삭제(Terminate) 6. RDS 삭제 (원본, Read Replica) 7. DB Subnet Group 삭제 8. EFS 삭제 9. NAT Gateway 삭제 10. CloudFront Distribution 삭제 11. S3 Bucket 비우기 (※ Empty 메뉴 사용) 12. S3 Bucket 삭제 13. Elastic IP 삭제(Release) 14. VPC 삭제 (※ VPC 삭제 시 VPC, Subnet, Route table, Security gr..

- CPU 사용률이 줄어들어 desired capacity의 갯수가 4개에서 3개로 3개에서 2개로 줄었다는 내용이다. - 이전에 CPU 사용률이 높았을때 asg-ec2가 4개였다가 CPU 사용률이 줄어든 후에 다시 2개로 돌아온 것을 볼 수 있다. - 랜덤으로 인스턴스를 종료시키는 것이 아니라 termination policy를 통해 원하는 인스턴스를 종료 시킬 수 있다. - termination policy는 auto scaling group를 통해 ec2 인스턴스가 트래킹 policy 때문에 삭제가 될 때 어떤 것을 우선 삭제할 것인가에 대한 기준이다. 1. Default는 2개로 나뉘어 진다. 첫번째는 더 오래된 Launch instance를 선택한다. 두번째 동일한 Launch instance라..

- 멈춰놨던 public-ec2-a1을 다시 실행 시킨다. - 해당 URL에 총 request를 20만개 보낼 것인데 request마다 1000번을 호출하겠 다.라는 의미다. - cpu 사용률을 확인해본다. - 두 인스턴스 cpu 사용률이 traffic policy에서 설정한 7 이상으로 올라간 것을 확인 할 수 있다. - asg-ec2가 2개였는데 4개로 늘어난 것을 확인 할 수 있다. - 즉, Auto Scaling을 통해서 asg-ec2 2개가 늘어난 것임을 알 수 있다. - ctrl + c로 종료

- 로드 밸런서를 통해 확장성 안정성을 확보할 수 있다. - *** 중요 - 세부정보 확인 - 사용자가 desired capacity를 2로 하겠다는 의미가 나온다. - 인스턴스 확인 - Target 그룹에 별도의 인스턴스를 설정하지 않았지만 인스턴스의 asg를 통해 새롭게 인스턴스가 생성된 이후에 그 인스턴스가 이 ALB에 자동으로 타겟 그룹에 포함된 것을 볼 수 있다. - 웹 페이지에서 확인

1. Private subnet에 WEB Server에 대한 custom ami 2. ec2 인스턴스를 미리 설정한 값에 따라 생성 할 수 있게 해주는 launch template 3. auto scaling에서 사용할 ALB - Custom AMI 생성 - AMI를 이용한 Lanch Template 생성 - launch template 같은 경우는 변경사항도 적용되어 버전만 바뀐 동일한 템플릿을 사용할 수 있기 때문에 장점이 많다. - Application Load Balancer 생성 1. target group 설정 - 이번 target group는 인스턴스를 선택하지 않는다. - ALB 생성

- 이중화를 구성한 DB가 Failover시 정상적으로 동작하는지 테스트를 해 볼 것이다. - master DB의 IP 주소를 미리 알아놓는다. - master db 확인 - 기존에 생성했던 rds 2개와 read replica로 생성한 rds를 포함하여 총 3개가 만들어져 있다. - private IP 주소 비교를 통해 master rds를 찾을 수 있다. - 그렇다면 다른 2c rds는 read replica인 것을 알 수 있다. - 마지막으로 2a에 해당하는 rds는 stand by인 것을 알 수 있다. - failover 실험 - 장애 조치로 재부팅 후 master DB의 IP 주소를 확인 해본다. - 장애 조치 재부팅 이후 master DB가 2c에서 2a로 변경된 것을 확인 할 수 있다.

- 단일 영역에서만 사용할 것이기 때문에 multi a-z는 사용하지 않는다. - DB를 read replica로 변경 - private a1으로 접속하여 작업 - dbinfo.inc의 엔드 포인트를 read replica의 엔드 포인트로 변경한다. - 똑같은 작업을 private c1으로 접속해서 작업을 해본다. - private a1과 c1 둘다 read replica에 연결되어 있는 상태다. - 이번에는 원본 DB에 접속하여 내용을 변경해도 read replica에 적용되어 웹에 띄워지는지 확인 해 볼 것이다. - 원본 DB Server의 변경 내용이 read replica에 전달이 정상적으로 되었고 해당 read replica를 웹 페이지가 잘 불러오는 것을 볼 수 있다.

- DB에 접속이 불가능하다. - DB 정보가 없기 때문이다. - private a1에 ssh로 접속한다. - 엔드포인트 지정을 해주어야 한다. - private c1도 똑같이 해준다. - DB 속성 생성 - private a1에서 작업 -h 뒤에 엔드포인트를 작성하여 DB Server에 접속한다. - 다음으로 나머지 DB Server(private c1)에서 똑같은 작업을 해 볼 것이다.