대규모 서비스 개발을 위한 기본 지식 정리 - 기계의 장애에도 동작하는 서비스 만들기 - 규목 커지면서 생기는 문제 다루기 - 기능과 구조가 복잡해지면서 생기는 문제를 다루기 - 성능을 고려하기 - 비용을 고려하기

1. CLOUD SERVICE PLATFORM GROUP
대규모 서비스를 가능하게 하는 기술

2. 대규모 서비스를 가능하게 하는 기술
차례
▸ 1. 기계적 장애에도 동작하는 서비스 만들기
▸ 2. 규모가 커지면서 생기는 문제를 다루기
▸ 3. 기능과 구조가 복잡해지면서 생기는 문제를 다루기
▸ 4. 성능을 고려하기
▸ 5. 비용을 고려하기

3. 1. 기계적 장애에도 동작하는 서비스 만들기
서버 운영 환경의 특징 - 일상적인 기계 장애
▸ 서버환경은 다양한 이유로 장애 발생
▸ 하드웨어 장애 (디스크, 메모리, 전원)
▸ 소프트웨어 장애 (OS, Application)
▸ Infra 유지보수
▸ 장애 발생을 일상으로 간주한 상태에서
안정적인 서비스 제공을 위한 설계 필요

4. 1. 기계적 장애에도 동작하는 서비스 만들기
첫 서버 구성
▸ 서버를 어떻게 준비할까?
▸ 서버에 DB만 두면 안되나?
▸ 클라이언트가 서버를 어떻게 찾아가나?
▸ 클라이언트와 서버가 어떻게 메시지를 주고받을까?
▸ 이 그림에서 장애 Point는?
MOBILE
APP
API
SERVER DBMS

5. 1. 기계적 장애에도 동작하는 서비스 만들기
API 서버 이중화
▸ DBMS는 왜 분리해야 하나?
▸ LB가 없으면 어떻게 동작시킬 수 있을까?
▸ 이 그림에서 장애 Point 는? (SPOF)
▸ LB가 장애나면?
MOBILE
APP
API
SERVER
DBMS
API
SERVER
LB

6. 1. 기계적 장애에도 동작하는 서비스 만들기
DBMS 이중화
▸ DBMS 이중화와 API 서버 이중화의 방식이 왜 다를까?
▸ Availability vs Durability
▸ Main DBMS 장애 발생시 어떻게 동작하는가?
▸ 이 그림에서 장애 Point 는? (SPOF)
MOBILE
APP
API
SERVER
DBMS
(PRIMARY)
API
SERVER
LB
DBMS
(REPLICA)

7. 1. 기계적 장애에도 동작하는 서비스 만들기
FILE 저장소
▸ File 저장소를 직접 운영한다면?
▸ Object Storage
▸ AWS S3, Azure BlobStorage, Google Storage, SPC Manta/Gage
▸ 이 그림에서 장애 Point 는? (SPOF)
MOBILE
APP
API
SERVER
DBMS
(PRIMARY)
API
SERVER
LB
DBMS
(REPLICA)
OBJECT
STORAGE

8. 1. 기계적 장애에도 동작하는 서비스 만들기
요약
▸ Availability, Durability가 기본입니다
▸ Api 서버는 이중화 하세요
▸ DBMS는 Primary - Replica로 구성하세요
▸ Object Storage 를 쓰세요
▸ 가정하는 장애의 범위에 따라 준비가 달라집니다
▸ 개별 서버 장비, 네트워크의 장애 -> SPOF 없애기
▸ IDC (Availability Zone) 수준의 장애 -> Multi-AZ 활용
▸ Region 수준의 장애 -> Multi-Region 활용, Disaster Recovery 전략

9. 2. 규모가 커지면서 생기는 문제를 다루기
대규모 서비스란?
▸ Traf
fi
c이 높다, Data가 많다.
▸ Traf
fi
c이 높을 때 생기는 문제?
▸ LB / Api 서버 / DBMS /
Object Storage
▸ Data가 많을 때 생기는 문제?
▸ LB / Api 서버 / DBMS /
Object Storage

10. 2. 규모가 커지면서 생기는 문제를 다루기
STATELESS VS STATEFUL
▸ 의미
▸ 클라이언트의 상태를 서버가 유지하는가?
▸ Api 서버? DBMS? Object Storage?
▸ 확장 전략 (Traf
fi
c이 증가하거나, Data가 증가할때)
▸ Stateless 서버의 확장 전략은?
▸ Stateful 서버의 확장 전략은?

11. 2. 규모가 커지면서 생기는 문제를 다루기
SCALE UP/DOWN VS SCALE OUT/IN

12. 2. 규모가 커지면서 생기는 문제를 다루기
API SERVER의 SCALABILITY
▸ 어떤 이유로 확장을 하게 되나?
▸ Traf
fi
c vs Data
▸ Api 서버는 Stateless ? Stateful ?
▸ Scalability 확보 방법
▸ Scale up ? Scale out ?
▸ Auto Scaling

13. 2. 규모가 커지면서 생기는 문제를 다루기
DBMS의 SCALABILITY
▸ 어떤 이유로 확장을 하게 되나?
▸ Traf
fi
c vs Data
▸ DBMS는 Stateless ? Stateful ?
▸ Scalability 확보 방법
▸ Scale up ? Scale out ?

14. 2. 규모가 커지면서 생기는 문제를 다루기
DBMS SHARDING
▸ Data가 어느 서버에 있는지 (Or 어느 서버에 넣을지) 판단하는 방법
▸ Lookup Table
▸ Algorithmic (Redis, Memcached)
▸ Consistent Hashing (DynamoDB, Cassandra)
▸ Range (HBase)
API
SERVER
DBMS
1
DBMS
2
DBMS
3

15. 2. 규모가 커지면서 생기는 문제를 다루기
DBMS REPLICATION VS SHARDING
▸ Replication이 필요한 경우와 장 단점
▸ Sharding이 필요한 경우와 장 단점
API
SERVER
DBMS
1
DBMS
2
DBMS
3
API
SERVER
DBMS
(PRIMARY)
DBMS
(REPLICA)

16. 2. 규모가 커지면서 생기는 문제를 다루기
OBJECT STORAGE의 SCALABILITY
▸ 뜻 밖의 문제 - Throttling
▸ 왜 Throttling이 발생할까?
▸ Throttling을 피하는 설계
▸ Use case 분석
▸ Partition key를 잘 설계하기

17. 2. 규모가 커지면서 생기는 문제를 다루기
요약
▸ 사용자가 늘어나면 대규모 Traf
fi
c 과 Data를 처리해야 합니다.
▸ Stateless vs Stateful 서버
▸ Api 서버 - right size 결정, Auto-scaling
▸ DBMS - Scale-up 대응 > Sharding
▸ Object Storage - Throttling을 피할 수 있는 설계

18. 3. 기능과 구조가 복잡해 지면서 생기는 문제를 다루기
복잡해지는 서비스
▸ 단일 API 서버 - DBMS 구조에서 새로운 기능을 계속 추가하면 어떤 어려움이 생길까?
▸ 하나의 개발팀(4~8명)이 책임지기 어려운 수준의 많은 기능을 개발해야 함
▸ 여러 팀이 한 서버의 다른 부분을 개발
▸ 서로 다른 기능의 변경 동시 요청, 동시 개발, 충돌
▸ 여러 기능 수정 동시 배포, 다른 기능의 버그로 인한 Roll back
▸ DB 구조가 복잡해지고, 다른 기능 개발팀이 하나의 Data 에 접근, 수정하여 불일치 발생

19. 3. 기능과 구조가 복잡해 지면서 생기는 문제를 다루기
서비스의 분리
▸ 좋아지는 점
▸ 생각해야 하는 범위
▸ 독립적인 개발과 배포
▸ 빌드, 배포, 서버 기동/종료 빠르게
▸ 언어 선택의 자율성, DB 선택의 자율성
▸ 나빠지는 점
▸ 느려짐
▸ 디버깅이 어려워짐
▸ 전체를 이해하는 사람이 줄어듬

20. 3. 기능과 구조가 복잡해 지면서 생기는 문제를 다루기
API GATEWAY
▸ 핵심 기능
▸ Authentication
▸ Authorization
▸ Reverse proxy

21. 3. 기능과 구조가 복잡해 지면서 생기는 문제를 다루기
CIRCUIT BREAKER
▸ 전기의 회로차단기에서 차용한 개념
▸ A 서비스가 B 서비스에 의존할 때 B 서비스의 장애가 A 서비스로 전파됨
▸ 서비스간 관계가 복잡해 질수록 한 서비스의 장애가 전체 시스템으로 확산
▸ 최선의 결과가 아니라도 의미 있는 미리 정해둔 값 사용 (사용자별 추천 > 인기순 추천)
▸ 미리 정해둔 값이 의미없는 경우 빠르게 오류 리턴 (적어도 상황을 악화시키지 않음)

22. 3. 기능과 구조가 복잡해 지면서 생기는 문제를 다루기
CONTEXT MAP 과 서비스간 의존성 다루기
▸ Context map : Bounded context 간의 관계를 표현한 그림
▸ 의존성의 방향과 Api 호출의 방향이 다른 경우 무슨일이 생길까?
▸ 어떻게 해결할까?
▸ 의존성 자체를 줄이는 방법은 없을까?

23. 3. 기능과 구조가 복잡해 지면서 생기는 문제를 다루기
요약
▸ 시간이 지남에 따라 시스템은 필연적으로 복잡해 집니다.
▸ 복잡함을 다루기 위해 Monolithic -> SOA -> Microservice 형태로 진화할 수
있습니다.
▸ 서비스가 나뉘면 그 전에는 없던 또 다른 문제들이 생깁니다.
▸ API Gateway, Circuit Breaker, Context map 등은 서비스가 나뉘어 복잡해
지는 상황을 통제하기 위한 노력의 일환입니다.
▸ 의존성 역전은 객체간의 관계뿐 아니라 서비스간의 관계에도 적용할 수 있습니다.
▸ Circuit breaker 패턴을 적용하여 장애의 범위를 줄일 수 있습니다.

24. 4. 성능을 고려하기
성능의 두가지 측면
▸ 응답시간과 처리량의 관계는 어떨까?
▸ 응답시간과 처리량이 양의 상관관계를 갖는 경우
▸ 응답시간과 처리량이 음의 상관관계를 갖는 경우
▸ 성능을 높이려면 응답시간을 낮춰야 하나? 처리량을 높여야 하나?

25. 4. 성능을 고려하기
성능 개선의 시작
▸ 어디에서부터 시작해야 할까?
▸ 그 다음은 무엇을 해야 할까?
▸ 응답시간을 단축 vs 처리량 높이기

26. 4. 성능을 고려하기
응답시간 단축을 위한 방안들
▸ 네트워크 구간
▸ 가깝게 (리전, CDN)
▸ 프로토콜
▸ Caching
▸ 서버 자체
▸ Scale up / out
▸ 튜닝
MOBILE
APP
API
SERVER
DBMS
(PRIMARY)
API
SERVER
LB
DBMS
(REPLICA)
OBJECT
STORAGE
▸ 인터페이스
▸ 여러 호출을 한번으로
▸ 한 호출을 여러번으로
▸ 자주 쓰는 기능을 가볍게
▸ 비동기 처리

27. 4. 성능을 고려하기
처리량 개선을 위한 방안들
▸ 병렬 처리와 동시성 처리
▸ Partition key를 고려한 실행 설계
▸ Key randomizing
▸ 응답시간 단축을 위한 기법들

28. 4. 성능을 고려하기
요약
▸ 성능에는 응답시간과 처리량 이라는 두가지 측면이 있어요
▸ 응답시간 개선인지 처리량 개선인지 명확하게 하고 시작하면 좋아요
▸ 측정하기 전에 머리로 성능개선 하지 마세요
▸ 분명한 목적과 목표를 정해두면 판단의 순간에 도움이 됩니다
▸ 동시성과 병렬처리는 다릅니다
▸ 성능이 필요한 경우 캐싱은 항상 고려해볼 방안입니다

29. 5. 비용을 고려하기
CLOUD 서비스 비용의 구성
▸ Compute
▸ Network
▸ Object Storage
▸ Database

30. 5. 비용을 고려하기
비용 최적화의 시작
▸ 어디에서부터 시작해야 할까?
▸ 품질 요구 수준과 비용
▸ 품질수준 우선 결정 방법 : 가용성, 내구성, 성능
▸ 비용 우선 결정 방법 : 연간 사용 가능 비용
▸ 측정
▸ 현재 품질수준 파악, 목표 품질수준 결정
▸ 현재 비용을 여러 측면에서 측정

31. 5. 비용을 고려하기
COMPUTE 비용
▸ 적절한 type을 선정하기
▸ Auto-scaling 및 scaling 규칙
▸ Spot instance, Reserved Instance
▸ Scheduling
▸ Binary traf
fi
c 경로에 대한 고려
▸ Attached EBS size

32. 5. 비용을 고려하기
OBJECT STORAGE 비용
▸ Data의 Lifecycle 정의가 기본
▸ 삭제하는 경우를 명확히 정의
▸ 장기 미사용자 처리 등
▸ Access 빈도, Durability 요구수준
▸ Infrequent Access, One-zone IA…
▸ 보관 비용과 다운로드 비용

33. 5. 비용을 고려하기
DATABASE 비용
▸ Data의 Lifecycle정의가 기본
▸ RDS
▸ Right-sizing
▸ Binary를 저장하지 않기
▸ Multi-AZ + replication별도 설정하는 경우
▸ 백업 여부 및 저장 기간 결정
▸ NoSQL
▸ Throughput 비용에 대해 정확히 이해
▸ Key 길이도 아끼자
▸ 백업 여부 및 저장 기간 결정
▸ Autoscaling vs On-demand

34. 5. 비용을 고려하기
NETWORK 비용
▸ 네트워크 비용은 대체로 out-bound 비용
▸ 이미 있는 파일은 전송하지 않도록 구현
▸ IDC 또는 Infra간 Binary traf
fi
c이 덜 흐르게
▸ HTTP response gzip compression
▸ Cloud-front 적절히 사용

35. 5. 비용을 고려하기
MULTI CLOUD 활용
▸ 생각보다 많이 다름. 쉽지 않아요.
▸ 클라우드 업체별로 경쟁력 있는 기능
▸ BATNA (Best Altenative To a Negotiated Agreement)
▸ 상당한 규모의 할인 가능

36. 5. 비용을 고려하기
요약
▸ 품질수준을 지키는게 우선인지 비용을 맞추는게 우선인지 정하세요.
▸ 측정하기 전에 머리로 비용절감 하지 마세요
▸ 측정을 잘하는 첫걸음은 태깅입니다
▸ 목표를 분명히 하고, 정기적으로 리뷰하세요
▸ 시나리오를 이해하고, 인프라를 공부하세요
▸ 대안은 우리에게 예상보다 많은 힘을 줍니다

37. Q & A