2. 발표자 소개
● 오픈 프론티어 5기 파트타임(현)
● Data Engineer at Udemy(현)
● Software Engineer at Kakao(카카오 스토리)
● Software Engineer at Naver(네이버 메일)
● Software Engineer at Finaldata
26. 자체 관리하면 서버가 여러대일때...
Image 2는 어디서 찾아야 할까?
Web Browser
Mobile Apps
API Server 1
API Server 2 File Server
Image 2
Image 9
Image 3
File Server
Image 1
Image 10
Image 4
27. 자체 관리 방식의 문제점
● 디스크 등의 증설 시기를 맞추기가 어렵다.
● 데이터 유실 확률이 높다.
● Object Store 형태로 갈려면, 구현하기가 어려움.
○ 큰 회사들은 대부분 자체 구현해서 씀.
58. 코디네이터
API Server
API Server
API Server
Cordinator
Auth Server
Auth Server
Auth Server
2. Auth Server 추가
3. Auth Server 가 추가
되었음, 다시 목록을 가
져가시오.
1. Auth Server 의 변동
을 알려줘!!!
61. Circuit Breaker 의 필요성
● 현재의 서비스는 다 수의 많은 외부 서비스의 API(자기 팀 이외에, 또는
자기 팀에서 관리하더라도 다른 서버의)를 사용하게 됨.
● 보통은 장애를 대비해서 Timeout을 설정하게 되는데…
○ Timeout 이 길면... 전체적인 서비스가 계속 느려지게 됨.
○ 해당 스레드/프로세스가 Timeout 동안 다른 작업을 못함.
● API 중에 중요하지 않은 서비스들도 있음(광고를 보여준다거나…)
79. Blue/Green 야매 버전 배포의 문제점
● 결국 둘 다 리소스를 많이 사용하는 경우, 시스템에 장애가 발생할 수
있다.
● 피크 타임은 피해서 배포해야 한다.
● Graceful Shutdown 잘 되어 있어야 한다. (Router 의 역할도 중요함.)
80. Blue/Green 배포와 데이터베이스 스키마 변경
● DB 스키마 변경은 지옥으로 가는 지름길…
○ 최대한 추가만 하고, 삭제와 변경은 하지 않는다.
○ 몇번의 배포이후 확실히 사용하지 않는다는 것이 확인될 때
삭제가능.
● 롤백보다는 빨리 고치는 걸 추천
● Feature Flag를 활용해보자.
88. Feature Flag(Switch) 의 장점
● 특정 기능에 문제가 생겼을 때, 해당 기능을 꺼버리면 된다.
○ 롤백 배포도 필요 없음.
● 다만 특정 기능이 동작하지 않는다면, UI에서는 어떻게 보여질지, 협의
가 필요.
○ 클라이언트 작업이 필요할 수 있음.
■ 클라이언트는 특정값이 오는 걸로 가정해버리면... 다 함께
Crash!!!
89. 요약
● 대용량 서비스 설계는
○ SPOF를 줄이고 가능한 장비추가로 인한 선형적인 성능 증대가 필
요하다.
● 여러가지 상황에 맞추기 위해 자동화가 필수(배포/테스트)
○ 몇 백대 이상의 서버를 관리해야 한다.
● 항상. 이러면 수백만명이 동시에 써도 괜찮을까를 물어보자.