How to build massive service for advance
156 likes14,493 views
Remove SPOF, Using coordinator, Using object storage, circuit breaker, blue/green, canary, feature flag
How to build massive service for advance
- 1. 대규모 서비스를 설계하는 기술 - 중급(일반편) 강대명([email protected])
- 2. 발표자 소개 ● 오픈 프론티어 5기 파트타임(현) ● Data Engineer at Udemy(현) ● Software Engineer at Kakao(카카오 스토리) ● Software Engineer at Naver(네이버 메일) ● Software Engineer at Finaldata
- 4. 배틀그라운드
- 6. Facebook
- 8. 대용량 서비스 설계 방법 ● SPOF 제거 ● 오브젝트 스토어 ● 데이터 샤딩 ● 코디네이터 ● Circuit Breaker ● 블루/그린 배포, 카나리 배포 ● Feature Flag(Switch)
- 9. SPOF
- 12. 이런 구조라면!!! Web Browser Mobile Apps API Server DB
- 13. 이런 구조라면!!! Web Browser Mobile Apps API Server DB
- 14. API Server 가 죽으면? Web Browser Mobile Apps API Server DB
- 15. DB 가 죽으면? Web Browser Mobile Apps API Server DB
- 16. 그래서 보통 이런 구조 Web Browser Mobile Apps API Server 1 API Server 2 DB Primary DB Secondary
- 17. API Server 가 죽어도? Web Browser Mobile Apps API Server 1 API Server 2 DB Primary DB Secondary
- 18. DB 가 죽어도? Web Browser Mobile Apps API Server 1 API Server 2 DB Primary DB Secondary
- 19. DB 가 죽어도? Web Browser Mobile Apps API Server 1 API Server 2 DB Primary DB Primary
- 21. 그래도 서버가 물리 서버 한대면 DB Primary API Server 1 Web Browser Mobile Apps API Server 2 DB Secondary
- 22. 그래도 서버가 물리 서버 한대면 DB Primary API Server 1 Web Browser Mobile Apps API Server 2 DB Secondary
- 23. Object Storage
- 24. Object Storage 이미지나 동영상을 어떻게 관리해야 할까요?
- 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 형태로 갈려면, 구현하기가 어려움. ○ 큰 회사들은 대부분 자체 구현해서 씀.
- 28. 3개의 복제본
- 29. Data Loss : 보통 3개의 복제본을 두면 99.999% 보 장 보장율 복제 개수 99.99% 2 99.999% 3
- 30. Object Store 의 역할 ● 이미지 등의 파일(오브젝트)를 저장함. ● 내부적으로 복제본이 생겨서 유실의 가능성이 적음 ○ 사람이 실수로 지울때는…(S3는 Versioning을 지원) ● 스토리지의 사이징, 장애등에 대한 고민이 적어짐.
- 31. Object Store 잘 동작하는 오브젝트 스토어를 만들기는 쉽지 않습니다. 있는 걸 잘 씁시다.(AWS S3)
- 32. 외부 서비스 형태로 이용이 편하다. Web Browser Mobile Apps API Server 1 API Server 2 Object Storage
- 33. 데이터 샤딩
- 34. 데이터 샤딩 필요한 메타 정보들이 엄청나게 거대하다면?
- 35. 데이터 샤딩
- 36. 데이터 샤딩 데이터를 어떻게 나누고 찾을것인가?
- 37. 다음 데이터를 두 개로 나누면 어떻게 해야 할까요? 1 2 3 4 5
- 39. 아무렇게나? 1 2 3 4 5
- 40. 이러면 각 숫자가 어디에 있는지 알 수가 없습니다.
- 41. 어디에 있는지를 모르면 전체를 찾아야 합니다.
- 42. 전체를 찾게 되면 모든 노드에 매번 부하를 주게됩니다.
- 43. 데이터를 나누는 기준, 규칙이 필요합니다.
- 45. 순서대로 1 2 3 4 5
- 46. 2로 나눠서 나머지가 1이면 앞에, 0이면 뒤에 1 2 3 4 5
- 47. 여기서 서버 수가 변하면 어떻게 될까요?
- 48. 2로 나누는게 아니라 3으로 나눠야 하면? 1 2 3 4 5 6 7 8
- 49. 2로 나누는게 아니라 3으로 나눠야 하면? 5 1 2 3 4 6 7 8
- 50. 많은 수의 데이터가 이동을 해야 합니다. 그런데 어디로 이동할지 모릅니다.
- 51. 모듈러는 2^N 으로 증가하는게 좋습니다. 1 2 3 4 5 6 7 8
- 52. 2^N으로 증가하면 이동하는 서버가 고정됩니다. 1 2 3 4 5 6 7 8
- 53. 확장에 데이터가 적게 움직이는 방법을 연구해야 합니다.
- 54. 코디네이터
- 55. 코디네이터 추가되고 삭제되는 서버 목록을 어떻게 관리할 것인가?
- 56. 코디네이터 서버의 추가 삭제시, 이를 이용하는 서비스에 알려준다.
- 57. 코디네이터 API Server API Server API Server Cordinator Auth Server Auth Server
- 58. 코디네이터 API Server API Server API Server Cordinator Auth Server Auth Server Auth Server 2. Auth Server 추가 3. Auth Server 가 추가 되었음, 다시 목록을 가 져가시오. 1. Auth Server 의 변동 을 알려줘!!!
- 60. Circuit Breaker
- 61. Circuit Breaker 의 필요성 ● 현재의 서비스는 다 수의 많은 외부 서비스의 API(자기 팀 이외에, 또는 자기 팀에서 관리하더라도 다른 서버의)를 사용하게 됨. ● 보통은 장애를 대비해서 Timeout을 설정하게 되는데… ○ Timeout 이 길면... 전체적인 서비스가 계속 느려지게 됨. ○ 해당 스레드/프로세스가 Timeout 동안 다른 작업을 못함. ● API 중에 중요하지 않은 서비스들도 있음(광고를 보여준다거나…)
- 62. Circuit Breaker Timeout 이 3초면 해당 스레드는 중요 하지 않은 API를 기다린다고 3초를 허비
- 63. Circuit Breaker 요청이 쌓이면... 해당 서비스도 응답이 느려지기 시작함.
- 64. Circuit Breaker 차라리 빨리 실패하고, 다른 값을 주자 !!! Fast Fail Back!!! Return (미리 정의된 값)
- 65. Circuit Breaker 광고를 못가져오면, 그냥 다른 이미지로 대체 광고 API가 죽더라도 서비스는 느려지지 않는다.
- 66. 블루/그린 배포, Canary 배포
- 67. 배포 기존의 배포가 힘든 이유
- 68. 기존의 배포가 힘든 이유 ● 버그의 존재 ○ 문제가 발생했을 때, 해당 범위가 클 수 있다. ● 배포에 시간이 너무 많이 걸린다. ○ 롤백 시간도 배포시간 만큼 오래걸린다.
- 69. 배포 이런 문제를 해결하기 위한 방법
- 70. 배포 쉬운 배포 방법(자동화된 배포) 버튼 하나, 명령 하나로... 수많은 자동화된 테스트가 필요 (CI/CD) 커밋될 때마다...
- 71. 배포 롤백 시간을 줄일려면?
- 72. Blue/Green 배포 새로운 한벌을 구성해서 배포, 그리고 라우터의 변경으로 서버군을 변경
- 73. Blue/Green 배포 롤백은 다시 라우터 변경으로 순식간!!!
- 74. Blue/Green 배포 그런데 항상 두벌씩 유지하라굽쇼!!!! 클라우드 아니면 힘듭니다.
- 75. Blue/Green 야매 버전 배포
- 76. Blue/Green 야매 버전 배포
- 77. Blue/Green 야매 버전 배포
- 78. Blue/Green 야매 버전 배포
- 79. Blue/Green 야매 버전 배포의 문제점 ● 결국 둘 다 리소스를 많이 사용하는 경우, 시스템에 장애가 발생할 수 있다. ● 피크 타임은 피해서 배포해야 한다. ● Graceful Shutdown 잘 되어 있어야 한다. (Router 의 역할도 중요함.)
- 80. Blue/Green 배포와 데이터베이스 스키마 변경 ● DB 스키마 변경은 지옥으로 가는 지름길… ○ 최대한 추가만 하고, 삭제와 변경은 하지 않는다. ○ 몇번의 배포이후 확실히 사용하지 않는다는 것이 확인될 때 삭제가능. ● 롤백보다는 빨리 고치는 걸 추천 ● Feature Flag를 활용해보자.
- 81. Canary 배포 블루/그린을 하더라도 장애가 발생하면 대상의 범위가 넓다
- 82. Canary 배포 데이터가 지워지는 심각한 문제라면?
- 83. Canary 배포 일부 유저에게만 적용해보자. 서버가 100대면 유저의 1%만… 잘되면 10%... 더 잘되면 전체 배포
- 84. Canary 배포 : 한대만 배포해서 제대로 동작할까? User #1이 다음번에 요청을 하게 되는 서버는? 항상 4번으로 간다는 보장이 없다.
- 85. Canary 배포 유저의 격리가 선행될 수 있어야 함. 서버군이 아예 다르거나… A/B Test 형태로 적용이 가능하거나...
- 87. Feature Switch 새로 나갈 기능을 배포없이 옵션으로 실시간으로 끄고 켤 수 있도록 준비
- 88. Feature Flag(Switch) 의 장점 ● 특정 기능에 문제가 생겼을 때, 해당 기능을 꺼버리면 된다. ○ 롤백 배포도 필요 없음. ● 다만 특정 기능이 동작하지 않는다면, UI에서는 어떻게 보여질지, 협의 가 필요. ○ 클라이언트 작업이 필요할 수 있음. ■ 클라이언트는 특정값이 오는 걸로 가정해버리면... 다 함께 Crash!!!
- 89. 요약 ● 대용량 서비스 설계는 ○ SPOF를 줄이고 가능한 장비추가로 인한 선형적인 성능 증대가 필 요하다. ● 여러가지 상황에 맞추기 위해 자동화가 필수(배포/테스트) ○ 몇 백대 이상의 서버를 관리해야 한다. ● 항상. 이러면 수백만명이 동시에 써도 괜찮을까를 물어보자.
- 90. 감사합니다.