Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Scalable webservice

How to build scalable webservice

  • Inicia sesión para ver los comentarios

Scalable webservice

  1. 1. Scalable Web Service 강대명 (CHARSYAM@NAVER.COM)
  2. 2. 발표자 소개 (현)Udemy 데이터 엔지니어 (전)카카오 스토리 백엔드 엔지니어 (전)네이버 메일 백엔드 엔지니어
  3. 3. 주제 Scalable Web Service
  4. 4. 대규모 서비스 Massive Traffic, Data Huge User(수천만에서, 수억까지…) Many IDC or Region(Cloud)
  5. 5. 질문 #1 이벤트가 내일입니다. 장비는 배달되었는데? 해당 장비가 서비스에 추가되어서 돌아가는데 시간이 얼마나 걸리나요? API 서버일수도 있고, 캐시서버일 수도 있고, DB 서버 일수도 있습니다.
  6. 6. 질문 #2 디비 서버가 갑자기 장애가 났습니다. 우리는 무엇 을 해야 할까요? 누군가 실수로 캐시 서버를 kill 해버렸습니다. 우리 는 무엇을 해야 할까요? API 서버가 몇대 장애가 났습니다. 우리는 무엇을 해야 할까요?
  7. 7. 아무 것도 안해도 됩니다. 원하는 대답:
  8. 8. 그래도 잘 돌아갑니다. 원하는 대답:
  9. 9. 이상적인 대답 BUT 생각의 시작
  10. 10. SPOF Single Point Of Failure
  11. 11. SPOF API Server DB Server 한대의 물리 서버
  12. 12. SPOF API Server DB Server 한대의 물리 서버
  13. 13. SPOF API Server DB ServerClientClientClient
  14. 14. SPOF API Server DB ServerClientClientClient
  15. 15. SPOF API Server DB ServerClientClientClient
  16. 16. SPOF ClientClientClient API Server API Server API Server Master DB Slave DB
  17. 17. SPOF를 제거하는 것이 첫 번째
  18. 18. Elastic 확장성(Scalability) 장애회복성(Resiliency)
  19. 19. 확장성 어떻게 구성해야 서버의 추가/제거가 자유로울까?
  20. 20. Stateless VS Stateful 확장성
  21. 21. API 서버 VS DB 서버 확장성
  22. 22. 확장성 ClientClientClient API Server API Server API Server Master DB Slave DB API Server
  23. 23. 확장성 ClientClientClient API Server API Server Master DB Slave DB
  24. 24. StateLess 는 정말로 추가 확장이 쉬울까?
  25. 25. Service Discovery
  26. 26. Server Side ClientClient예약 Server 결제 Server 결제 Server 결제 Server 예약 서버가 결제 서버를 호출한다고 하면? Proxy LB
  27. 27. Server-Side Service Discovery L B API #3 Servers L B API #2 Servers L B API #1 Servers
  28. 28. Client Side ClientClient예약 Server 결제 Server 결제 Server 결제 Server 예약 서버가 결제 서버를 호출한다고 하면? 1 2 3
  29. 29. Clinet-Side Service Discovery API #3 Servers API #2 Servers API #1 Servers List #2 List #3 List #1 List #2 List #1 List #3
  30. 30. 목록 관리가 이슈 Service Discovery - DNS RR
  31. 31. Stateful 은 어떻게? (DB, Cache)
  32. 32. 일반적인 DB 서버의 부하 200 writes/s 800 reads/s Read > Write
  33. 33. 읽기 분배 - Query Off WEB/AS Master Slave ONLY WRITE Slave Slave Only READ REPLICATION
  34. 34. 읽기 분배 - Query Off 200 writes/s 800 reads/s 200 writes/s 400 reads/s 200 writes/s 400 reads/s Read/1 Server Read/2 Server
  35. 35. Slave 장비를 추가하면 계속 성능이 증가할까?
  36. 36. 읽기 분산의 한계 700 writes/s 50 reads/s 700 writes/s 50 reads/s 700 writes/s 50 reads/s 700 writes/s 50 reads/s 700 writes/s 50 reads/s Write Heavy Situation
  37. 37. 결국은 쓰기를 나누어야 한다.
  38. 38. Database Partitioning
  39. 39. Vertical Partitioning
  40. 40. Horizontal Partitioning
  41. 41. Shared Nothing (Sharding) (Horizontal Partioning)
  42. 42. 특정 Key 를 어디에 저장할 것인가?
  43. 43. 특정 Key 를 저장하는 방법 특정 Key 를 찾는 방법
  44. 44. 특정 Key를 찾는 방법 특정 유저의 데이터는 어디에 있을까? 특정 모텔 정보는 어디에 있을까?
  45. 45. Range 특정 범위대역으로 나누기 젤 쉬움 Server #1 Server #2 Server #3 User #1 ~ 100 User #101 ~ 200 User #201 ~ 300
  46. 46. Range 특정 서버가 놀거나 부하가 몰릴 가능성이 가장 큼 가입 이벤트, 1~2주후 유저 잔존률이 얼마나 될까?
  47. 47. Modular 서버 대수로 나누기 Server #1 Server #2 User #0 User #1 User #2 User #3
  48. 48. Modular 여기서 서버가 한대가 추가되면 무슨 난리가… 데이터가 모두 섞이게 된다. Server #1 Server #2 User #0 User #1 User #3 User #4 Server #2 User #2 User #5
  49. 49. Modular 두배로 늘리기(2 𝑁 ∶ 2 → 4 → 8 → … ) 1에서는 3으로 절반이, 2에서는 4로 절반이 이동 Server #1 Server #2 User #0 User #1 Server #3 Server #4 User #2 User #3 User #4 User #5 User #6 User #7
  50. 50. Modular 이미 서버가 한 16대쯤 있다면? 다음에 늘려야 할 서버 대수는?
  51. 51. Indexed 특정 데이터의 위치를 가리키는 서버가 존재 Server #1 Server #2 Server #3 User #1 Index User #1 -> 3 User #100 -> 1 User #102 -> 1 User #100 User #102
  52. 52. Indexed Index 서버에 부하가 몰아치면? Index 서버가 장애가 나면?
  53. 53. Complexed 위의 방식들을 자~~~알 조합해보자.
  54. 54. Complexed Master Index User RANGE #1 -> 1 Slave Slave Master Slave Slave Master Slave Slave ONLY WRITE ONLY READ User RANGE #10 -> 1 User RANGE #20 -> 3
  55. 55. MongoDB HBase Cassandra 이런 걸 알아서 하는 DB들
  56. 56. MongoDB HBase Cassandra 이런 걸 알아서 하는 DB들 NVMe 와 함께 하세요.
  57. 57. 모든 API 서버들의 설정을 바꾸고 재배포? 그럼 디비가 추가되면?
  58. 58. 모든 API 서버들의 설정을 바꾸고 재배포? 그럼 디비가 추가되면? 디비 추가나 제거는 뭐 그럴만 합니다. ☺
  59. 59. 모든 API 서버들의 설정을 바꾸고 재배포? 그런데 DB가 장애라면?
  60. 60. 모든 API 서버들의 설정을 바꾸고 재배포? 그런데 DB가 장애라면? 우리가 항상 지켜보지 못합니다.
  61. 61. 예상된 작업 VS 예상되지 않은 작업
  62. 62. Coordinator
  63. 63. Zookeeper 의 특징  절대로 죽지않는다.(거짓말) 잘 안죽는다.(몇대 죽어도 상관은 없다.) 그러나 다 죽을때도 종종 있음.  임시 노드의 경우, Health Check를 통해서 자동적으로 접 속된 노드가 사라지면 데이터가 사라진다.(30초가 기본…) Cluster Membership  노드의 작업 순서를 보장해준다. Leader Election
  64. 64. Leader Election Naming Service Cluster Membership
  65. 65. Cluster Membership Cases API Server 가 추가/변경 되었다. Database Master 장비가 추가/변경되었다. Cache 장비가 추가/변경 되었다. 우리의 대응은? 목록을 추가하고, 배포해야 합니다. 목록만 추가하면 알아서 동작합니다. 장비만 추가하면 알아서 동작합니다.
  66. 66. Etcd Consul Zookeeper
  67. 67. Configuration 서버의 설정을 바꿔야 할 때마다? 서버 재 배포? 서버의 설정을 동적으로 바꾸고 싶다면? DB or Cache 에 저장해 둘 수도 있습니다. Polling 이냐 Interrupt 이냐의 차이
  68. 68. Feature Flag(Switch) 새로 나간 기능을 설정으로 제어 영화 탭을 보여줄 것인가? 신규 기능에 장애가 있을 경우, 바로 끌 수 있다. 클라이언트와 함께 작업이 필요함.
  69. 69. Leader Election
  70. 70. 여러 대의 서버 중에서 한대만 그 일을 하게 하고 싶을 때 (or 분산 Lock)
  71. 71. Hell of Health Check ClientClient예약 Server Health Check가 죽으면? Health Check
  72. 72. Hell of Health Check ClientClient예약 Server 무한 Health Check Health Check Health Check2 Health Check3 Health Check N
  73. 73. 그런데 여러 개를 띄우면… 알람이 동시에 여러 개가…
  74. 74. Leader 만 일해라. ClientClient예약 Server Leader 만 동작한다. Health Check Health Check Health Check
  75. 75. Leader Election 클라이언트들 간의 약속으로 정해둠.
  76. 76. Circuit Breaker
  77. 77. 한 화면을 구성하는데 몇 개의 API가 필요할까요?
  78. 78. 그 중에 하나라도 실패하면?
  79. 79. Amazon 2006년에 이미 Amazon 페이지 하나를 만들기 위해서 100개의 API Call이 발생
  80. 80. 필수적인 API VS 필수적이지 않은 API
  81. 81. Fast Fail Back return (Predefined Value)
  82. 82. Timeout 이 300ms 일때 계속 실패하면 300ms 씩 대기
  83. 83. Netflix Hystrix
  84. 84. Blue-Green Deployment
  85. 85. Blue-Green
  86. 86. Blue-Green 는 쉬운가? 같은 수의 장비를 쉽게 준비할 수 있을까? Cloud 라면 손쉬움(두 벌을 유지하는 시간이 짧음 IDC 라면 어떻게? 예전에 모 B사의 W모 게임이 그렇게 했다고 합니 다.(거기는 부자니…)
  87. 87. Blue-Green 야매 버전 ClientClientClientClient LB Proxy API : 10000 API : 20000 DB
  88. 88. Blue-Green 야매 버전 ClientClientClientClient LB Proxy API : 10000 API : 20000 DB
  89. 89. Blue-Green 야매 버전 ClientClientClientClient LB Proxy API : 10000 API : 20000 DB
  90. 90. Blue-Green 야매 버전 ClientClientClientClient LB Proxy API : 10000 API : 20000 DB
  91. 91. 그런데 데이터베이스 Schema 변경이 출동한다면?
  92. 92. 스키마는 최대한 추가만 (삭제나 변경은 피하자)
  93. 93. 스키마는 최대한 추가만 (삭제나 변경은 피하자) 그럼에도 마음대로 안되는게 스키마 변경
  94. 94. 롤백 보다는 빨리 고치는게…
  95. 95. 롤백 보다는 빨리 고치는게… Open the HellGate!!!
  96. 96. Canary Deployment
  97. 97. 몇 대만 나가보자. 일부만 적용해보자.
  98. 98. Canary Deployment ClientClientClientClient LB Proxy API #1 DB API #2 API #3 API #4
  99. 99. 단순히 몇 대만 배포할 수 있을까?
  100. 100. Canary Deployment 시 고려할 점 ClientClientClientClient LB Proxy API #1 DB API #2 API #3 API #4 User #1 고려할 점 1. User #1 은 어디에서 서비스를 받게 될까? 2. User #1 의 요청은 다음번에도 API #4로 가게 될까? 3. 안가면 무슨 일이 벌어질까?)
  101. 101. A/B 테스트 처럼 유저를 격리할 수 있어야 함.
  102. 102. 그런데 새로운 세상이 오고 있습니다.
  103. 103. Mesos(Marathon/Aurora) Kubernetes 새로운 세상
  104. 104. 새로운 세상 서버가 죽으면 자동으로 살려줌 다만 어느 서버에 뜰지는 모름 자동으로 Service Discovery 와 연결됨 DNS, Software LB 시작시에 설정으로 자신의 Role을 가지고 뜨면 자동으 로 추가됨.
  105. 105. 이미 충분히 성숙된 기술들
  106. 106. SideCar Pattern Service Mesh
  107. 107. 솔직히 못 써봤어요
  108. 108. Sidecar 패턴 https://docs.microsoft.com/ko-kr/azure/architecture/patterns/sidecar
  109. 109. Sidecar 패턴
  110. 110. envoy C++ L7 Proxy And Communication Bus
  111. 111. 코드 수정 X - SideCar Circuit Breaker의 구현 코드 수정 - Hystrix
  112. 112. 코드의 변경? 인프라의 변경?
  113. 113. 같은 문제를 다양한 시각에서 다르게 풀 수 있다.
  114. 114. 서버가 죽지 않아야 한다
  115. 115. 서버가 죽지 않아야 한다
  116. 116. 서버는 죽는다. 다시 살아나게 하자.
  117. 117. Manual Work is BUG
  118. 118. Thank you.

×