[SAA] 네 번째 Pillar : 성능 효율성

4) Performance Efficiency

• 성능 효율성은 컴퓨팅 리소스를 사용해 시스템 요구 사항을 충족하고 수요가 바뀌고 기술이 발전함에 따라
  효율성을 유지하는 기능을 포함하여 최고의 성능을 도입하고 제공하는 것
• 성능 효율성을 위한 설계 원칙이 존재
  
  
  • 고급 기술을 대중화해서 사용할 수 있도록 하여 제품 개발에 도움이 되도록 함
  • 몇 분 안에 전 세계의 여러 리전에 배포하도록 해야 하며 이를 위해 CloudFormation을 사용할 수 있음
  • 어떤 서버도 관리하지 않고 모두 스케일링 될 수 있도록 서버리스 아키텍처를 사용하도록 함
  • 실험 횟수를 늘려 제대로 작동하는지 확인해야 함
  • 기계적 동조를 통해 모든 AWS 서비스에 주의하도록 해야 하며 변경 사항이 발생하면 극적으로 변경될 수 있게 해야 함

Performance Efficiency AWS Services

• AWS 서비스의 측면에서의 성능 효율성
• 선택
  오토 스케일링, Lambda, EBS, S3, RDS 등 약간 다른 패턴으로 확장하는 많은 기술이 있으므로 적합한 것을 선택
  Lambda는 서버리스에 필요하고, 더 많은 EC2에는 오토스케일링을 위해 사용,
  EBS는 디스크가 필요하지만 성능 관리를 위해 사용, 전세계 확장에는 S3 사용, RDS는 데이터베이스를 프로비저닝하고,
  Aurora는 마이그레이션할 때 사용
• 검토
  성능을 검토하기 위해 CloudFormation으로 생성하기 전에 필요한 것을 정확히 얻는지 확인
  모든 성능 개선 사항에 대한 업데이트는 AWS 뉴스 블로그에서 확인 가능
• 모니터링
  성능이 좋은지 확인하기 위해 CloudWatch Alarms과 CloudWatch metrics의 CloudWatch를 사용하며
  모든 CloudWatch 대시보드로 어떻게 실행되는지 이해할 수 있음
  Lambda도 마찬가지로 규제되지 않고 애플리케이션의 람다 함수가 최소 시간 내에 실행되도록 함
• 절충
  RDS와 Aurora를 사용하거나 실제 성능을 개선하려면 ElastiCache를 사용하고 Snowball도 사용할 수 있음
  Snowball은 대규모의 데이터를 빠르게 옮길 수 있지만 데이터 도착까지 일주일 정도가 걸리므로
  데이터를 클라우드에서 확인하고 모든 네트워크 용량을 사용하거나 데이터를 트럭으로 옮기고 일주일 안에 받을지 절충 필요
  ElastiCache의 경우 캐시에 오래된 데이터가 있지만 성능을 개선할지, ElastiCache 사용 없이 최선 버전을 얻을지 절충 필요
  CloudFront의 경우 엣지 주변의 것을 캐시하며 하루 동안 캐시할 수 있지만,
  웹사이트 업데이트를 릴리스할 때 사람들이 새 버전을 얻는데 사긴이 걸릴 수 있으므로 절충 필요