본문 바로가기
728x90

전체 글

 (166)
컴퓨터 용량을 자동으로 조정하는 방법 : Amazon EC2 Auto Scaling 조정(scaling)은 어떤 컴퓨터의 용량을 줄이거나 늘리는 기능 어떤 특정 시간에 가장 높은 수요를 충족하도록 컴퓨터 용량을 프로비저닝 한다고 하자. 그러면 대부분의 다른 시간에 활용도가 낮은 상태로 리소스를 실행하게 된다 -> 이러면 비용이 최적화되지 않는다 혹은 더 적은 용량을 할당하여 비용을 줄이는 것인데, 이러면 특정 시간에는 용량이 부족하게 된다 이를 막기 위한게 자동 용량 조정 위 그림처럼 유동적인 서비스 수요를 지원하는데 필요하다 조정 기능이 없다면 애플리케이션의 성능이 저하되거나 사용자가 전혀 사용할 수 없을지도 모른다 클라우드에서 컴퓨팅 파워는 프로그래밍 방식의 리소스이다 -> 유연한 방식으로 조정할 수 있다는 소리 Amazon EC2 Auto Scaling : 애플리케이션의 가용성을 ..
AWS에서 지표를 알아보는 법 : Amazon CloudWatch AWS를 효율적으로 사용하려면 AWS 리소스에 대한 통찰력이 필요하다 -> 이럴 때 쓸 수 있는 Amazon CloudWatch! Amazon CloudWatch : DevOps, 엔지니어, 개발자, 사이트 안정성 엔지니어, IT 관리자를 위해 구축된 모니터링 및 관찰 기능 서비스 : AWS 리소스와 AWS에서 실행되는 애플리케이션을 실시간으로 모니터링 - 리소스나 애플리케이션에 대해 측정할 수 있는 변수인 지표를 수집하고 추적 가능 - 계정의 모든 Amazon CloudWatch 지표를 모니터링하는 경보를 생성하고, 해당 경보를 사용하여 자동으로 Amazon Simple Notification Service나 Amazon SNS 주제로 알림을 보내거나 EC2 Auto Scaling 작업이나 EC2 작업..
AWS의 로드 밸런싱 : Elastic Load Balancing 현대의 트래픽이 많은 웹사이트는 사용자의 동시 요청이 수십만건~수백만건으로 제공되어야 하며 올바른 텍스트, 이미지, 동영상, 애플리케이션 데이터를 빠르고 안정적으로 반환해야 한다 >> 이때 필요한 게 로드 밸런싱 로드 밸런싱? 서버가 처리해야 할 업무나 요청(load)을 여러 대의 서버로 나누어(balancing) 처리하는 것을 의미! 이런 대용량 볼륨 요구사항을 지원하려면 추가 서버가 필요하다 -> Elastic Load Balancing은 수신되는 애플리케이션이나 네트워크 트래픽을 단일 가용 영역이나 여러 가용 영역의 EC2 인스턴스, 컨테이너, IP 주소, Lambda 함수와 같은 여러 대상에 분산하는 AWS 서비스이다 시간이 지나면서 애플리케이션의 트래픽이 변경됨에 따라 로드 밸런서를 조정한다 대..
AWS : Trusted Advisor 지금까지 AWS Well-Architected 프레임워크를 사용하여 아키텍처의 잠재적 위험을 파악하고 개선이 필요한 영역을 식별하며 아키텍처 결정을 내릴 수 있음 이번에는 AWS에서 아키텍처를 설계하고 검토하는 데 사용할 수 있는 Trusted Advisor 도구에 대해 알아보자! Trusted Advisor : 전체 AWS 환경을 분석하여 5가지 범주별로 권장 사항을 제시 1. 비용 최적화(Cost Optimization) Trusted Advisor는 리소스 사용량 분석, 사용하지 않은 유휴 리소스 제거나 예약 용량을 약정하여 비용을 최적화할 수 있도록 권장 사항 제시 2. 성능(Performance) Trusted Advisor는 서비스 제한을 점검, 프로비저닝 된 처리량 을 확인 초과 사용되는 인..
AWS : 안정성, 가용성, 고가용성, 내결함성, 확장성 의미 Amazon CTO인 Werner Vogels 왈 "모든 것은 고장나기 마련(Everything fails, all the time)" AWS Well-Architected 프레임워크에서 제시하는 모범 사례 중 하나는 장애(애플리케이션/워크로드 중지)에 대한 계획을 수립하는 것 -> 장애를 견디도록 애플리케이션과 워크로드를 설계해야함! 클라우드 아키텍트가 장애를 견디도록 아키텍처를 설계할 때 고려하는 두 가지 중요한 요소 1. 안정성 사용자가 원할 때 기능을 제공할 수 있는 시스템의 능력을 측정하는 척도 모든 것에서 항상 장애가 발생할 수 밖에 없으므로 통계적 방식으로 안정성을 생각해야함 안정성은 일정 기간 동안 전체 시스템이 정상적으로 작동할 확률을 의미 시스템에는 펌웨어 및 소프트웨어와 같은 여러 시..
AWS Well-Architected 프레임워크 다섯번째 : 비용 최적화 원칙 비용 최적화 원칙 : 최소한의 시스템 실행 비용으로 비즈니스 가치를 실현하는 역량에 중점을 둠 - 지출 파악, 제어 - 가장 적절/적합한 수의 리소스 유형 선택 - 시간대별 지출 분석 - 초과 지출 없이 비즈니스 요구 사항에 맞춘 크기 조정 비용을 최적화 할 수 있는 5가지 설계 원칙 1. 소비 모델 도입 - 필요한 컴퓨팅 리소스에 대해서만 비용 지불 - 정교한 예측 대신 비즈니스 요구 사항에 따라 사용량을 늘리거나 줄임 2. 전체 효율성 측정 - 워크로드의 비즈니스 결과 측정 - 이 결과를 실현하는 것과 관련된 비용 측정 -> 결과를 늘리고 비용을 줄여 얻을 수 있는 이점 파악 3. 데이터 센터 운영 비용의 지출 중단 - AWS는 서버를 렉에 설치, 스태킹, 전원 공급 등의 작업 부담을 덜어줌 -> I..
AWS Well-Architected 프레임워크 네번째 : 성능 효율성 원칙 성능 효율성 원칙 : IT, 컴퓨팅 리소스를 효율적으로 사용하여 시스템 요구 사항을 충족하고, 수요 변화나 기술 개선에 따라 이러한 효율성을 유지하는 역량에 중점을 둠 - 워크로드 요구 사항에 적합한 리소스 유형, 크기를 선택하는 방법 - 성능을 모니터링하는 방법 - 정보 기반 의사 결정을 통해 변화하는 비즈니스 환경에서 효율성을 유지하는 방법 성능 효율성 설계 원칙 1. 고급 기술 대중화 - 기술을 서비스로 소비한다 ex. SQL 데이터베이스, 미디어 트랜스코딩, 기계학습 같은 기술은 기술 커뮤니티에서 쉽게 찾을 수 없는 전문성이 요구되는 기술이다. 클라우드에서는 이러한 기술을 서비스로 사용 가능 - 기술을 소비함 -> 리소스 프로비저닝, 관리 대신 제품 개발에 집중할 수 있음 2. 신속하게 전세계에 ..
AWS Well-Architected 프레임워크의 세번째 : 안정성 원칙 AWS Well-Architected 프레임워크의 세번째 : 안정성 원칙 안정성 원칙 : 인프라나 서비스 장애로부터 복구하고, 수요에 맞춰 컴퓨팅 리소스를 동적으로 확보하며 잘못된 구성이나 일시적인 네트워크 문제와 같은 중단을 완화하는 시스템의 기능에 중점을 둠 - 설정 - 교차 프로젝트 요구 사항 - 복구 계획 - 변경 처리 안정성을 높일 수 있는 5가지 설계 원칙 1. 복구 절차 테스트 - 시스템 장애를 테스트, 복구 절차를 검증 -> 장애 경로를 파악하여 실제 장애 시나리오가 발생하기 전에 테스트하고 교정할 수 있음 2. 장애 발생 시 자동으로 복구하는 기능 마련하기 - 시스템의 주요 성능 지표를 모니터링, 임계값 위반 시 자동 복구를 트리거하도록 시스템 구성 -> 자동 알림, 장애 추적 기능을 활..
728x90

티스토리툴바