Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

ACT Continuous Learning Day

150 visualizaciones

Publicado el

AWSomeDay 공유

Publicado en: Software
  • Check the source ⇒ www.HelpWriting.net ⇐ This site is really helped me out gave me relief from headaches. Good luck!
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Sé el primero en recomendar esto

ACT Continuous Learning Day

  1. 1. AWESome-cld 2017.03.31 ki
  2. 2. AWSome Day 3/17 참석 공유
  3. 3. tl;dr EC2: Linux/Windows S3: Object Storage EBS: Block Store. filesystem IAM: AWS User, Group, Role, Access, Policy... RDS: RDB 관리 dynamoDB: NoSQL DB ELB: load balancer CloudWatch: AWS Resource Monitoring Trusted Advisor: AWS 더 잘 쓰게 해줄게..(비용최적화, 보안, 내결함성, 성능)
  4. 4. Amazon Web Services (AWS) 비즈니스와 개발자가 웹 서비스를 사용하여 확장 가능하고 정교한 애플리케이션을 구축하도록 지원
  5. 5. AWS 클라우드 컴퓨팅의 장점 자본 비용을 가변 비용으로 대체 규모의 경제로 얻게 되는 이점 용량 추정 불필요 속도 및 민첩성 개선 데이터 센터 운영 및 유지 관리에 투자 불필요 몇 분 만에 전 세계에 배포
  6. 6. AWS 기초 서비스 https://aws.amazon.com/ko/products/
  7. 7. AWS 플랫폼 서비스
  8. 8. AWS 글로벌 인프라
  9. 9. 리전 & 가용 영역 리전 지리적 위치 최소 2개 이상의 가용 영역(AZ)으로 구성 가용영역(AZ) 데이터 센터의 클러스터 다른 가용 영역의 장애로 부터 격리 @아마존웹 서비스를다루는기술
  10. 10. Amazon Elastic Compute Cloud (EC2) 컴퓨팅 파워를 요구사항에 따라 조정 가능 실제로 사용한 용량만큼만 비용 지불 Linux or Window 안정성을 위해 여러 리전 및 가용 영역에 걸쳐 배포 사전 구성된 AMI로 EC2 인스턴스 시작
  11. 11. EC2 lifecycle
  12. 12. EC2 Instance type 범용(T2, M4, M3) 트래픽이 적은 웹 사이트, 어플리케이션, 중소형 데이터베이스 컴퓨팅 최적화(C4, C3) 고성능 프론트 엔드, 비디오 인코딩 메모리 최적화(R3) 고성능 데이터베이스, 분산 메모리 캐싱 스토리지 최적화(I2, D2) 데이터 웨어하윙, 로그 또는 데이터 처리 애플리케이션 GPU 인스턴스(G2) 3D 애플리케이션 스트리밍, 기계 학습 https://aws.amazon.com/ko/ec2/instance-types/
  13. 13. EC2 가격 정책 https://aws.amazon.com/ko/ec2/pricing/
  14. 14. Amazon Simple Storage Service (S3) 웹에서 언제 어디서든 원하는 양의 데이터를 저장하고 검색 99.999999999% 객체 내구성, 99.999% 객체 가용성 데이터를 버킷 내에 객체로 저장 객체 = 파일 + 메타데이터 버킷에 저장할 수 있는 객체 수 제한 없음 객체 크기는 최대 5TB 계정 당 최대 100개 버킷 보유
  15. 15. S3 특징 최소 요금 없음, 실제 사용한 만큼만 요금 지불 버킷을 통해 유일한 네임스페이스 제공 ACL, 정책, IAM 정책 등을 통해 액세스를 제어 버전 관리 기능 제공 수명 주기 관리 기능 제공
  16. 16. Amazon Glacier S3에 비해 저렴한 장기 보관 서비스 자주 액세스하지 않는 데이터에 적합 99.999999999% 내구성 3-5시간 검색 시간 소요 월별 GB당 0.01USD 미만
  17. 17. Amazon Elastic Block Store (EBS) 영구적 블록 레벨 저장 장치 단일 가용 영역 내에서 자동으로 복제됨 프로비저닝한 만큼 비용 지불
  18. 18. EBS vs S3 EBS 파일 시스템이 있는 블록 스토리지로 인터넷 액세스 불가능 단일 가용 영역의 여러 서버에 걸쳐 중복 저장 디스크 드라이브로 사용 됨 S3 객체 스토어로 인터넷 액세스 가능 리전 내 여러 시설에 걸쳐 중복 저장 온라인 스토리지로 사용 됨
  19. 19. EC2 인스턴스 스토리지 EC2에 직접 연결되어 있는 무료 로컬 블록 스토리지 인스턴스가 중지되거나, 장애가 발생하거나, 종료되면 모든 데이터가 자동 삭제 됨 따라서 EBS 를 연결해서 사용해야 됨
  20. 20. AWS 공동 보안 책임 모델 https://aws.amazon.com/ko/compliance/shared-responsibility-model/
  21. 21. AWS Identity and Access Management (IAM) AWS IAM 사용자 및 액세스 관리 AWS IAM 역할 및 권한 관리 자격 증명 연동 사용자 및 권한 관리 (애플리케이션 사용자 관리 X)
  22. 22. IAM Group, Role, Policy
  23. 23. IAM 모범 사례 AWS 루트 계정 액세스 키 삭제 개별 IAM 사용자 생성 그룹을 사용하여 IAM 사용자에게 권한을 지정 EC2인스턴스에서 실행 되는 애플리케이션에 역할 사용 자격 증명을 공유하기보다는 역할을 사용 불필요한 사용자와 자격 증명 제거
  24. 24. Amazon Relational Database Service (RDS) 데이터베이스 관리 작업을 지원 (백업, 패치…) Amazon Aurora, MySQL, MariaDB, MsSQL, Oracle, PostgreSQL 지원 다중 AZ RDS 배포로 가용성 보장 자동 백업 : 특정시점으로 복원 가능, 최대 35일 간 보존 수동 스냅샷 : 사용자 생성, 삭제, 구축 해야됨, S3에 저장 교차 리전 스냅샷: 다른 리전에 저장, 재해 복구를 위한 백업
  25. 25. Amazon DynamoDB NoSQL 데이터 베이스 서비스 어떤 양의 데이터든지 제한 없이 저장 가능 SSD를 사용해 빠르고 예측가능한 성능
  26. 26. Elastic Load Balancing 여러 인스턴스에 걸쳐 트래픽 분산 비정상 EC2 인스턴스를 탐지하기 위한 상태 확인 지원 EC2인스턴스에 대한 HTTP, HTTPS, TCP의 라우팅/로드 밸런싱 지원
  27. 27. Amazon CloudWatch 다른 AWS 리소스와 애플리케이션에 대한 모니터링 서비스 리소스 사용률, 운영 성능 및 전체 수요 패턴에 대한 통계 알림 설정 가능
  28. 28. Auto Scaling Amazon EC2 용량을 자동으로 조정 사용량의 변화가 많은 애플리케이션에 적합 사용시 추가 요금 없음 (조정되는 EC2 요금은 별도) 내결함성 향상, 가용성 향상, 비용관리 개선
  29. 29. Auto Scaling Group CloudWatch 알람을 사용하여 확장/축소 정책을 생성
  30. 30. AWS Trusted Advisor AWS 고객에게 4가지 범주에서 성능 및 보안 권장 사항을 제공 비용 최적화 : 사용률이 낮은 EC2, ELB, EBS, RDS. 미사용 탄력적 IP 주소 보안 : 보안그룹, IAM, S3 버킷권한, RDS 보안 그룹 액세스 위험.. 내결함성 : EBS 스냅샷, RDS 다중 AZ, Auto Scaling 그룹 리소스.. 성능향상 : 사용률이 높은 EC2, 과도한 보안그룹 정책, 서비스 한도 EC2에서 EBS로 처리량 최적화..
  31. 31. 근데 우리는 Cloud를 Cloud 답게 쓰고 있나 EC2 WEB WAS WAS DB
  32. 32. Cloud native application The Twelve Factor App https://12factor.net/ko/
  33. 33. Codebase 버전 관리되는 하나의 코드베이스와 다양한 배포
  34. 34. Dependencies 명시적으로 선언되고 분리된 종속성 특정 프로그램이나 라이브러리가 설치되어 있다고 가정하면 안됨 어떠한 시스템 도구에도 암시적으로 의존하지 않음 (ex: curl) package.json pom.xml build.gradle …..
  35. 35. Config 환경(environment)에 저장된 설정 코드에 상수로 저장 X 환경변수에 저장 O
  36. 36. Backing services 백엔드 서비스를 네트워크를 통해 연결된 리소스로 취급 애플리케이션 코드 수정 없이 MySQL을 Amazon RDS 로 변경할 수 있어야 함
  37. 37. Build, release, run 철저하게 분리된 빌드와 실행 단계 실행단계에서 코드를 변경할 수 없음
  38. 38. Processes 애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행 프로세스간 아무것도 공유하지 않음 유지될 필요가 있는 데이터는 데이터베이스 같은 안정된 백엔드 서비스에 저장 Session 데이터를 프로세스 메모리에 캐싱 하면 안됨 Memcached나 Redis 처럼 유효기간을 제공하는 데이터 저장소에 저장
  39. 39. Port binding 포트 바인딩을 사용해서 HTTP 서비스로 공개함 포트로 들어오는 요청을 기다림 완전히 독립적으로 실행 하나의 앱이 다른 앱을 위한 백엔드 서비스가 될 수 있다는 것을 의미
  40. 40. Concurrency 프로세스 모델을 사용한 확장 애플리케이션이 작업을 적절한 프로세스 타입에 할당 함으로써 다양한 작업 부하를 처리할 수 있도록 설계 아무것도 공유하지 않고 수평으로 분할할 수 있도록 만들어 동시성을 높일 수 있음
  41. 41. Disposability 빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화 프로세스는 바로 시작하거나 종료 될 수 있음 이를 통해 신축성 있는 확장과 코드, 설정 변경시 빠르게 배포 할 수 있음 프로세스는 갑작스러운 죽음에도 견고해야 됨 Graceful Shutdown : 서비스 포트의 수신을 중지하고, 현재 처리중인 요청이 끝나길 기다린 뒤에 프로세스가 종료
  42. 42. Dev/prod parity development, staging, production 환경을 최대한 비슷하게 유지 서로 다른 경우 지속적 배포에 방해 될 수 있음
  43. 43. Logs 로그는 실행 중인 앱의 동작을 확인 할 수 있는 수단 로그 파일을 작성하거나 관리하려고 해서는 안됨 고정된 시작과 끝이 있는 것이 아니라, 앱이 실행되는 동안 계속 흐르는 흐름 로그를 이벤트 스트림으로 취급
  44. 44. Admin processes admin/maintenance 작업을 일회성 프로세스로 실행
  45. 45. Reactive http://www.reactivemanifesto.org/ http://www.reactive-streams.org/
  46. 46. Responsive Message- Driven ResilientElastic Reactive System
  47. 47. Reactive Streams
  48. 48. Publisher Processor Subscriber data request data request data flow data flow 제어의 흐름을 제어하는 것보다 Data의 흐름을 제어하는 것이 중요
  49. 49. Event-Driven vs. Message-Driven
  50. 50. Reactive Programming vs. Reactive System Alex Blog => http://blog.lespinside.com/reactive-programming-versus-reactive-systems/ 리액티브 프로그래밍은 컴포넌트 수준에서 내부 로직과 데이터 플로우(flow) 관리를 위한 성능과 자원 효율성을 통해 개발자의 생산성을 높여준다. 리액티브 시스템은 시스템 수준에서 클라우드 네이티브 혹은 다른 대규모 분산 시스템을 구축하기 위한 복원성과 탄력성을 통해 아키텍트와 데브옵스의 생산성을 높여준다.
  51. 51. Reactive streams 에 대해 더 알고 싶으면.. 토비의 봄 TV https://www.youtube.com/c hannel/UCcqH2RV1-9ebR BhmN_uaSNg
  52. 52. CLOUD를 잘 쓰려면 애플리케이션 아키텍처도 중요하다
  53. 53. Thank you

×