Download as PDF, PPTX
Uploaded byDaeMyung Kang
How to build massive service for advance
Remove SPOF, Using coordinator, Using object storage, circuit breaker, blue/green, canary, feature flag
More Related Content
![[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유](https://cdn.slidesharecdn.com/ss_thumbnails/ndc2018-1-180430181759-thumbnail.jpg?width=640&height=640&fit=bounds)
![[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버](https://cdn.slidesharecdn.com/ss_thumbnails/public-140529222503-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)](https://cdn.slidesharecdn.com/ss_thumbnails/vol2-160427160825-thumbnail.jpg?width=640&height=640&fit=bounds)
![[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)](https://cdn.slidesharecdn.com/ss_thumbnails/ndc2018-2-180430180517-thumbnail.jpg?width=640&height=640&fit=bounds)
![[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장](https://cdn.slidesharecdn.com/ss_thumbnails/5-160415084345-thumbnail.jpg?width=640&height=640&fit=bounds)
![오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...](https://cdn.slidesharecdn.com/ss_thumbnails/t3s1-221108101729-c6b32f4f-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to How to build massive service for advance
![[웨비나] Follow me! 클라우드 인프라 구축 기본편 - 강지나 테크 에반젤리스트](https://cdn.slidesharecdn.com/ss_thumbnails/follow-mecloudinfra-210723044820-thumbnail.jpg?width=640&height=640&fit=bounds)
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.
- 8. 대용량 서비스 설계방법 ● SPOF 제거 ● 오브젝트 스토어 ● 데이터 샤딩 ● 코디네이터 ● Circuit Breaker ● 블루/그린 배포, 카나리 배포 ● Feature Flag(Switch)
- 9.
- 10.
- 11.
- 12. 이런 구조라면!!! Web Browser MobileApps API Server DB
- 13. 이런 구조라면!!! Web Browser MobileApps API Server DB
- 14. API Server 가죽으면? Web Browser Mobile Apps API Server DB
- 15. DB 가 죽으면? WebBrowser 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 가 죽어도? WebBrowser Mobile Apps API Server 1 API Server 2 DB Primary DB Secondary
- 19. DB 가 죽어도? WebBrowser Mobile Apps API Server 1 API Server 2 DB Primary DB Primary
- 20.
- 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.
- 24. Object Storage 이미지나 동영상을 어떻게관리해야 할까요?
- 25.
- 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.
- 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
- 38.
- 39.
- 40. 이러면 각 숫자가어디에 있는지 알 수가 없습니다.
- 41. 어디에 있는지를 모르면 전체를찾아야 합니다.
- 42. 전체를 찾게 되면 모든노드에 매번 부하를 주게됩니다.
- 43. 데이터를 나누는 기준, 규칙이필요합니다.
- 44.
- 45.
- 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 APIServer Cordinator Auth Server Auth Server
- 58. 코디네이터 API Server API Server APIServer Cordinator Auth Server Auth Server Auth Server 2. Auth Server 추가 3. Auth Server 가 추가 되었음, 다시 목록을 가 져가시오. 1. Auth Server 의 변동 을 알려줘!!!
- 59.
- 60.
- 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.
- 67.
- 68. 기존의 배포가 힘든이유 ● 버그의 존재 ○ 문제가 발생했을 때, 해당 범위가 클 수 있다. ● 배포에 시간이 너무 많이 걸린다. ○ 롤백 시간도 배포시간 만큼 오래걸린다.
- 69. 배포 이런 문제를 해결하기위한 방법
- 70. 배포 쉬운 배포 방법(자동화된배포) 버튼 하나, 명령 하나로... 수많은 자동화된 테스트가 필요 (CI/CD) 커밋될 때마다...
- 71.
- 72. Blue/Green 배포 새로운 한벌을구성해서 배포, 그리고 라우터의 변경으로 서버군을 변경
- 73. Blue/Green 배포 롤백은 다시라우터 변경으로 순식간!!!
- 74. Blue/Green 배포 그런데 항상두벌씩 유지하라굽쇼!!!! 클라우드 아니면 힘듭니다.
- 75.
- 76.
- 77.
- 78.
- 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 형태로 적용이 가능하거나...
- 86.
- 87. Feature Switch 새로 나갈기능을 배포없이 옵션으로 실시간으로 끄고 켤 수 있도록 준비
- 88. Feature Flag(Switch) 의장점 ● 특정 기능에 문제가 생겼을 때, 해당 기능을 꺼버리면 된다. ○ 롤백 배포도 필요 없음. ● 다만 특정 기능이 동작하지 않는다면, UI에서는 어떻게 보여질지, 협의 가 필요. ○ 클라이언트 작업이 필요할 수 있음. ■ 클라이언트는 특정값이 오는 걸로 가정해버리면... 다 함께 Crash!!!
- 89. 요약 ● 대용량 서비스설계는 ○ SPOF를 줄이고 가능한 장비추가로 인한 선형적인 성능 증대가 필 요하다. ● 여러가지 상황에 맞추기 위해 자동화가 필수(배포/테스트) ○ 몇 백대 이상의 서버를 관리해야 한다. ● 항상. 이러면 수백만명이 동시에 써도 괜찮을까를 물어보자.
- 90.