AWS 에 대한 이해

AWS

본 내용은 위 링크를 읽고 학습한 내용을 정리한 글 입니다.
틀리다고 생각하시는 부분을 지적해주세요! 피드백을 환영합니다!

AWS는 인프라 서비스이다.

개개인이 시도하는 서비스는 99% 망한다.
인프라는 비싸고 시작부터 체계적으로 준비를 하기에는 소요되는 시간과 자원이 비싸며 리스크 또한 크다. AWS는 이것을 보다 단계적으로 시도하여 초기 Scale Up이 과한 상태를 막는다.

스케일 업과 스케일 아웃이란?

대부분 scale out 하다가 적절히 scale up도 같이 한다.

AWS의 핵심은 비지니스 로직에 집중 할 수 있다는 것이 가장 큰 장점이다.

ec2

메뉴얼적인 서버 한 개 이다.
가장 기본이 되는 시작

• AMI(머신 이미지) : EC2에 올라간 값들에 대한 정보를 카피 하고 새로운 EC2를 생성 할 때 기존에 이미 올라와 있는 EC2에 대한 정보를 그대로 사용하여 생성한다.

• 한 서버에 너무 많은 기능을 추가하면 부하가 너무 크다 ( DJango, redis, postgres 등등..)

  • 해법은 기능에 따라 인스턴스를 나누는 것 (웹 서버용 인스턴스, 디비용 인스턴스)

ELB

ELB를 어떤 존에 넣을 것이냐 -- 대부분 다 넣는다.

웹서버는 무한정 늘릴 수 있다.
하지만 write하는 마스터 디비는 한개까지만, read 하는 디비는 5~7개까지밖에 늘릴 수 없다.
마스터 디비에 대해서 스케일 업 하는 순간이 서버점검을 할 수 밖에 없는 순간이다.
마스터 디비가 상태가 안좋을 경우 바로 다른. read replica 디비가 새로운 마스터가 되어야 한ㄷ.

write의 자원 소요가 read보다 훨씬 더하다

--> SSL을 쓰기 위해서는 로드 벨런서를 써야 한다.

P38

Master DB 는 전체 DB의 20%의 write에 대한 자원을 처리하며

Read DB는 80%에 대한 작업을 처리합니다.

• 데이터를 디스크에 써야 하기 떄문에, 인덱스를 만드는 과정이 헤비한 과정입니다.

  • Master DB가 헤비한 이유.

• Stanby DB는 메

P42: s3 주의사항

• 한 폴더 안에 넣을 수 있는 파일에 대한 관리가 필요하다( 한 폴더 안에들어가는 한계도 있고, 한 폴더안 너무 많은 파일이 관리되면 성능측에서 좋지 않기 때문입니다.)

• 단점: AWS 리전이 약 11개 인데, S3는 한 지역에 의존성이 있기 때문에 타 리전에서는 내 s3에 대한 접근을 하기 위해서는 내 오리진 서버에 들어가야 하기 때문에 느리다.

  • 해결 방법: 근처 엣지서버에서 원하는 데이터를 찾고 없으면 오리진 서버에서 가져 온 뒤 엣지 서버에 넣는다. TTL 도 줄 수 있으며 스태틱 파일들은 TTL을 길게 준다. (aws cloud front 라는 서비스 이다. CDN (캐시 서버), 동적 데이터도 캐시)

• collect static :s3에 스태틱 파일 업로드

• whitenose라는 라이브러리를 사용하면 관리자페이지 만큼은 gunicon에서 작업을 하도록 한다.

P44

• 세션 : session time out // 영속적이지 않은 삭제가 되어도 ttl 의 단위가 낮아도 되는 데이터들 >> redis기반의 메모리 안에 저장이 되는 것이 좋다. read가 엄청 많다. (토큰이 유효한지 확인하기 위해서)

• session, cache, ttl등을 사용을 할 것이면 ElasticCache(redis, memcache)를 사용한다.

• DynamoDB가 밖에 있는 이유 : 리전이 없다. 글로벌 리전이며 전세계 어디에서 접근하여도 비슷한 레이턴시를 제공한다.

• 다음 날 수요가 확 늘더라도 동적으로 빠른 대응을 할 수 있다.

• AWS가 비쌈에도 사용하는 이유는 서버라는건 끊임없이 관리를 해 주어야 하는 주체인데, 관리에 대한 자원을 줄이면서 비즈니스에 집중을 할 수 있다는것이 큰 장점이다.

P48

• 오토스케일링은 클라우드 환경의 가장 기본적인 요소들 중에 하나로, 갑작스러운 트래픽 집중에 서버, 스토리지 등의 자원이 자동으로 확장하면서, 안정적인 서비스를 유지하는 것입니다.
• ELB, Ec2, condition을 설정한다.
• condition 은 cpu 가 80%가 넘는 클럭이 3번 이상 발생하면 2대 증설
• 기준점이 되는 대상을 cpu, diskIO, networkIO, 등에 있어서 여러 조건에서 걸 수 있다.
• 반대로 특정 조건 속에서 서버를 줄일 수 있다. (cpu가 30% 5분동안 2번 유지 되면 서버 하나 감소 등)

오토스케일링으로 대비를 하여도 서버가 터지는 이유

• 오토스케일링을 하는 것도 시간이 걸리는데 그 시간조차도 버틸 수 없기 때문에
• 인력이 미리 수동으로 미니멈 갯수를 올려버리는 등의 대응 방법이 있다.

P51 : 모니터링과 로깅

• 찰나의 실수에 대한 원인을 찾기 위해 모니터링 툴과, 로깅을 찍어야 한다.
• 모니터링을 할 수단은 많을수록 좋습니다.

59P

• 워커 인스턴스는 로드벨런서와 연결이 되어있지 않습니다. 이 워커 인스턴스는 웹 인스턴스에서 SQS에 보낸 큐 안에서 일을 가져옵니다.

• async 작업의 힘든 점은 디버깅이 힘들다는 것이며 sentry, logDNA 가 필요한 이유입니다.

P63 DB 부하

• 마스터 디비는 하나만 존재하며, 마스터에 부하가 많이 가게 되면 결국 과부하로 서버가 터집니다.
• 데이터베이스를 분리해야 한다. (sharding)
• 데이터베이스 FK가 되지 않아서 쿼리가 어려워진다.
• 제대로 하기 굉장히 어렵습니다.

추가 개념: 병목은 항상 디비에서 발생한다.

• 이유는 Network, Disk IO에 의해 발생한다. 그 이후에 신경을 써야 하는것이 캐시
• 리스폰스 자체를 캐시하는 방법도 있다. (json 자체로 )