kaonmir
시리즈
SAA
DOP
System Design Interview
Linux
ETC
Share
Sign In
Home
Kaonmir (손성훈)
Copy & Translate
시리즈
SAA
후기
시험 소개 & 꿀팁
Terminology
Region & Availability Zone
Budget
IAM
EC2 - Fundamentals
EC2 - SAA Level
EC2 Storage
ELB & ASG
RDS / Aurora / ElastiCache
S3
CloudFront & Global Accelerator
Route 53
Storage Extras
Decoupling
Container
Serverless
Database
Monitoring, Troubleshooting & Audit
IAM Advanced
Security & Encryption
VPC
Disaster Recovery & Migrations
Ohter Services
기술 백서 총 모음
기술 백서(White paper)
DOP
CodeCommit, CodeBuild, CodeDeploy
CodePipeline, CodeStar, Jenkins
CloudFormation - Fundamentals
CloudFormation - DOP Level
Elastic Beanstalk
Lambda & Step Function & API Gateway
ECS & ECR & OpsWorks
Kinesis
CloudWatch
CloudTrail & X-Ray & ElasticSearch & Tagging
SSM & Config & Service Catalog & Inspector
Other Services
Auto Scaling Group (ASG)
DynamoDB & S3
Multi AZ & Multi Region & Multi Account
AWS Organizations & On-Premise Strategy
Disaster Recovery (DR)
서비스별 기본 배포 전략 비교
CodeDeploy appspec hook
System Design Interview
사용자 수에 따른 규모 확장성
개략적인 규모 추정
시스템 설계 면접 공략법
처리율 제한 장치
안정 해시
키-값 저장소
분산 시스템을 위한 유일 ID 생성기
URL 단축기
웹 크롤러
알림 시스템
뉴스 피드 시스템
채팅 시스템
검색어 자동완성 시스템
유튜브
구글 드라이브
Linux
ETC
AI를 더 잘 쓰기 위한 IT 용어
Subscribe
사용자 수에 따른 규모 확장성
데이터베이스
RDBMS
: 자료를 테이블과
행
(레코드)과 열로 표현. Join이 가능하다.
NoSQL
: RDBMS가 아닌 데이터베이스. Key-value, graph, column, document로 나눈다.
Scale up & scale out
Scale up
: 성능을 좋게. 다만 성능 향상에는 한계가 있고, SPOF가 된다.
Scale out
: 쪽수를 많게. 다만 트래픽을 여러 서버에 분산해줘야 한다.
로드밸런서(LB)
Load Balancing
: 트래픽을 서버로 적절히 분산한다.
Forward proxy
: 서버의 IP를 숨기고 LB의 IP만 노출한다. 반대 개념은 reversed porxy
데이터베이스 다중화
성능(performance)
: 읽기 연산을 분산해서 처리하기 때문에 성능 증가
가용성(availability)
: 장애가 생겨도 다른 DB로 대체 가능
안정성(reliability)
: DB 하나가 훼손되어도 원본 유지 가능
캐시
서버가 DB에서 같은 값을 두 번 읽으면 낭비기 때문에 중간에 캐시를 둬서 DB 질의의 결과를 임시 저장한다. 서버는 질의할 때 캐시를 먼저 살피고 값이 없으면(miss) DB에서 가져온다. 이
캐시 전략
을
읽기 주도형 캐시
라고 부른다.
쓰기보다 읽기 연산이 많을 때 유리하다.
오래 저장되지 않을 자료에 유리하다.
적절한 시간이 지나면 값을 지워야 한다. 성능 문제(↓) vs 일관성 문제(↑)
캐시와 DB의 값이 동일하다는 것을 보장해야 한다. 일관성 문제
캐시를 한 대만 두면 SPOF가 되기 때문에 다중화해야 한다.
캐시 크기를 정해야 한다. 너무 작으면 값이 자주 방출돼서 성능이 떨어진다.
데이터 방출 정책을 정해야 한다. 주로
LRU
를 쓰고 LFU, FIFO를 쓰기도 한다.
콘텐츠 전송 네트워크(CDN)
정적 콘텐츠를 지리적으로 분산된 서버에 저장해놓고 가장 가까운 서버에서 값을 가져오는 방식이다.
탱커랄까
돈 걱정
: 트래픽에 따라 돈을 내기 때문에 꼭 필요한 것만
장애 대처
: CDN이 죽으면…?
만료 시한 설정
: 캐시랑 똑같이 적절할 때 갱신해야 한다.
무효화
: 아직 만료 안되었는데 강제로 만료시키기
CDN 서비스 사업자가 제공하는 API
같은 콘텐츠라도 버전을 바꾼다.
무상태 웹 계층
로드밸런싱이 만든 작은 문제, 서버는 A,B가 있다.
1.
A 서버에서 장바구니에 물건을 하나 담았다.
2.
그런 다음 B 서버에서 다른 상품도 담았는데
3.
A 서버에서 담은 물건이 장바구니에 없다…!
4.
왜냐하면 A 서버와 B 서버는 서로 소통을 안하기 때문
이에 대한 해결책은 크게 두 가지가 있다.
Sticky session
: A, B 서버 왔다갔다 하지 말고 유저 한 명은 한 서버가 전담하도록 한다. LB에 무리간다.
공유 저장소
: A, B 서버가 모두 참조할 수 있는 아주 가벼운 데이터베이스를 둔다. 여기다가 장바구니 물건을 담아둔다.
공유 저장소는 빨라야 하기 때문에 NoSQL로 주로 만든다.
데이터 센터
내 서버가 있는 서울에 지진이 나면?? 서비스가 안된다. 이 문제를 해결하기 위해서 도쿄에도 같은 서비스를 운영한다. 그러면 한 쪽이 멈춰도(failover) 다른 한 군데에서 서비스를 하면 되기 때문에 안전하다.
트래픽 우회
: 적절하게 트래픽을 보내야 한다. (GeoDNS)
데이터 동기화
: 서울에 있는 DB가 멈추면 데이터 복구가 안된다.
배포
: 배포를 할 때 서울과 도쿄가 동일한 어플리케이션을 설치하도록 해야 한다.
메시지 큐
메시지 큐는 메시지의 무손실을 보장하는 비동기 통신 컴포넌트이다. 생산자와 소비자를 분리해서 확장하기도 좋고 안정적이게 된다.
로그, 메트릭 그리고 자동화
로그
: 여러 서버의 에러 로그를 한군데 모으면 검색, 조회가 좋다.
메트릭
: 사업에 대한 인사이트를 얻고, 시스템의 현재 상태를 파악한다.
호스트 단위 메트릭
: CPU, 메모리, 디스크 I/O
종합 메트릭
: DB 계층의 성능, 캐시 계층의 성능
핵심 비즈니스 메트릭
: 일일 능동 사용자(DAU), 수익, 재방문
자동화
: 빌드, 테스트 배포 등의 절차를 자동화한다. CI/CD
데이터베이스의 규모 확장
수직적 확장
서버 성능을 키운다. 서버 하드웨어에는 한계가 있고 SPOF의 위험이 있다. 또 비싸다.
수평적 확장
서버를 늘린다. 대규모 데이터베이스를 샤드(shard)로 나누고 데이터를 여러 대의 서버에 분산해서 저장한다. 어느 서버에 넣을지는 각 데이터의 샤딩 키(혹은 파티션 키)를 통해 결정한다.
재샤딩
: 한 샤드가 다른 샤드들에 비해 빨리 소진되면서 감당하기 어려울 때, 샤딩 키를 다시 분배해서 저장해야 하는 문제가 발생한다.
셀럽 문제
: 특정 샤드에 질의가 집중돼서 과부화가 걸리는 문제
조인과 비정규화
: 조인이 힘들기 때문에 비정규화를 수행할 수 밖에 없다.
Made with SlashPage