클라우드/AWS (16) 썸네일형 리스트형 Architecting on AWS (5일) 2 13. RTO/RPO 및 백업 복구 설정 13.1. 재해 복구 계획 - RPO : 복구 시점 목표 : 복구 시점을 통해 얼마나 자주 백업을 해야하는지 측정 -> 짧아야 데이터 손실이 적다. ( 백업을 자주 한다 ) - RTO : 복구 시간 목표 : 복구 시간이 얼마나 걸리는지 측정 - 리전이 다운될 수도 있기 때문에 재해 복구 사이트 동안 적합한 위치를 선택할 수 있다. - 재해복구 프로세스 : 백업 및 복원 -> 파일럿 라이트 -> 완전 동작 저용량 스탠바이 -> 다중 사이트 액티브 액티브 --------------------------------------------------------------------------------------------------------> 더 낮은 RTO RPO *.. Architecting on AWS (5일) 10. 캐싱 10.1. 세션관리 - 사용자 세션을 관리하는 특정 서버로 요청을 라우팅할 수 있습니다. - 쿠키토큰을 사용하여 세션을 유지 - ELB 사용 시, 트래픽이 분산되기 때문에, 한 서버에만 쿠키+사용자 정보가 저장되기 때문에 로드밸런스로 인해 다른 서 버로 향하게 되면 로그인이 풀리는 문제가 있다. - 따라서 ELB의 고정 세션기능 사용하거나 세션생태를 저장하기 위한 캐싱 DB를 생성하여 사용한다. 10.2. DB 캐싱 - Amazon DynamoDB Accerlerator : 탁월한 성능 , 높은 확장성, 완전 관리형, 보안 / 인 메모리 캐쉬(Dynamo 전용) - Amazon Elastcache : 인 메모리 캐쉬, 클라우드에서 인 메모리 캐시를 배포, 운영, 조정하는데 사용하는 웹 서비스.. Architecting on AWS (4일) 8. 탄력성과 고가용성 및 모니터링 - 내결함성 : 애플리케이션 구성 요소 내장된 중복성 - 복구성 : 재해 발생 후 서비스 복구와 관련된 프로세스 - 확장성 : 애플리케이션의 설계 변경 없이 성장 수용 - 탄력적인 인프라는 용량 요구사항이 변화함에 따라 지능적으로 확장 및 축소 될 수 있습니다. - 탄력성 : 시간 기반 : 리소스가 사용되지 않을 때 리소스 끄기 볼륨 기반 : 수요 강도에 맞게 규모 조정 일일 및 주간 추세를 기반으로 향후 트래픽 예측 8.1. 모니터링 - 탄력성 뿐만 아니라 운영 상태, 리소스 활용, 애플리케이션 성능, 보안감사 등에도 사용 - CloudWatch : 인프라 모니터링 시스템 : 리소스에 대한 지표를 수집, 추적 : 경보를 생성하고 알림을 전송 : 규칙에 따라 리소스의 .. Architecting on AWS (3일) 5.3. 보안 그룹 - aws 리소스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 - L3(ex.ipv4)/L4(TCP) 스위치에 프로토콜에서 제한한다. - 규칙은 상태 저장 ( Stateful ) : 방화벽이 세션을 이해하여 같은 세션은 인바운드를 허용하면 자동으로 아웃바운드 허용 - 보안 그룹은 각 사용용도에 따라 따로 생성하는 것이 좋다. : 바로 앞 부분의 서버에서 시작되는 신호를 통과 허용. : 체인 다이어그램 : 한계점 -> 특정 패킷을 거부할 수 없다. - 네트워크 ACL : 서브넷 경계의 방화벽, 기본적으로 모든 트래픽 허용, 특정 네트워크 IP 대역에 관한 보안 요구사항에 권장 : 특정 네트워크를 막을 수 있다. : 상태 비저장이므로 인 아웃바운드 모두 명시적인 명시가 중.. Architecting on AWS (2일) 2. 컴퓨팅 계층 추가 2.1. EC2 - 인스턴스 메타데이터를 사용하여 EC2 인스턴스에 대한 정보를 가져올 수 있다. ** public-hostname을 이용한다. ex) #hostname = $ ( curl -s http://169.254.169.254/latest/meta-data/public-hostname(ec2 고유) 2.2. EC2 요금 유형 - 온디맨드 인스턴스 : 사용한 만큼 지불 ( 1년 이상 비효율 ) - 예약 인스턴스 : 용량에 대한 비용을 미리 지불, 장기 사용 시 - Savings plans : 리전 등을 자유롭게 변경, 장기 사용 시 - 스팟 인스턴스 : 비용변동, 비용이 변하면 종료 2분전 중단 공지 2.3. EBS : Elastic Block Storage - Instan.. Architecting on AWS (1일) 0. 개요 - 온프레미스 : It 자원을 직접 소유 - 퍼블릭 클라우드 : It 자원을 서비스처럼 수행 => CSP : aws => MSP : megazon - 초기 투자 비용 없이 인터넷을 통해 리소스와 애플리케이션을 언제든 사용한 만큼 비용을 지불하고 사용하는 서비스 ( API 의 사용 ) - 클라우드 컴퓨팅의 장점 1) 자본 비용을 가변 비용으로 대체 : IT 자원 준비 x 2) 규모의 경제( 투입 규모를 up => 장기 이익 )로 얻게 되는 이점 3) 용량 추정 불필요 ( 자원 할당의 낭비나 부족을 방지 ) 4) 속도 및 민첩성 개선 5) 중요한 문제에 집중 6) 전 세계로 신속한 배포 - AWS Well-Architected 프레임워크 : 시스템을 잘 구성하였는지 확인하는 툴 ( 질문 답변 후 .. 10. AWS ( EFS, ROUTE 53 ) 0. 사전 구성 - web 인스턴스로 가용영역 a에 생성 - 해당 인스턴스에 웹 서비스 설치 1. EFS - efs 서비스를 들어간 뒤 파일 시스템 생성 - efs 파일 시스템 생성 완료 - web 인스턴스에 nfs 설치 or 아마존 efs 툴 설치 - 보안그룹 인바운드 규칙에 nfs 추가 - 파일 시스템의 연결부분을 눌러 명령어를 확인 - nfs 클라이언트로 마운트한 모습 - 아마존 efs 툴로 마운트한 모습 2. Route53 - 호스트 영역 생성 - 레코드 생성 - 호스팅케이알에 도메인에 네임서버를 아마존 네임서버로 등록 - nslookup으로 확인 - 웹 접속 TEST 2.1. ROUTE53 : ftp - 레코드 추가 - 인스턴스에 ftp 설치 및 설정 - 방화벽 열기 - 도메인으로 ftp 접속 .. 9. AWS ( 오토스케일링 ) 0. 구성 설정 - bastion 생성 - WEB-A 가용영역 A : PUB 서브넷에 생성 후 worppress 설치 - RDS : mysql 5.7 생성 후 연결 - wordpress 정상동작 - 구성 완료 1. 오토 스케일링 - 생성해놓은 wordpress가 설치된 인스턴스로 이미지(ami) 생성 - 시작 템플릿 생성 - 오토스케일링 그룹 생성 - 인스턴스를 확인하면 새로 생성됨을 보인다. - 해당 인스턴스에 공인 ip 부여 - 진행 한 후 접속하여 보면 wordpress가 동일하게 생성되어 있음을 확인 - 스트레스 부하를 위해 stress 서비스 설치 - 스트레스 부하를 준다. - cloudwatch로 확인하여 보면 정상적으로 부하가 적용됨을 볼 수 있다. - 부하가 계속되면 새로운 인스턴스가 생성.. 이전 1 2 다음
