Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Internet Scale Service Arichitecture

2,242 views

Published on

Internet Scale Service Arichitecture

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Internet Scale Service Arichitecture

  1. 1. Internet Scale Service 강대명 (CHARSYAM@NAVER.COM)
  2. 2. WHO AM I? Udemy Data Engineer Kakao Story-Senior Backend Engineer Naver Mail-Senior Backend Engineer
  3. 3. Internet Scale Service
  4. 4. Internet Scale Service Massive Trafific Huge Users/Data Many IDC(or Regions)
  5. 5. Origin James Hamilton - AWS Vice President Paper On Designing and Deploying Internet-Scale Services https://www.usenix.org/legacy/event/lisa 07/tech/full_papers/hamilton/hamilton_h tml/
  6. 6. Internet Scale Service 실제적으로는 하드웨어/소프트웨어 인프라 전반에 관한 이야기 Check List https://gist.github.com/acolyer/95ef238 02803cb8b4eb5
  7. 7. 질문 #1!!! 우리의 서비스는 어떻게 구성되었나요?
  8. 8. 질문 #2!!! 우리의 서비스는 Elastic 한가요? Elastic Scaling Resiliency
  9. 9. SPOF Single Point Of Failure
  10. 10. SPOF API Server DB Server 한대의 물리 서버
  11. 11. SPOF API Server DB Server 한대의 물리 서버
  12. 12. SPOF API Server DB ServerClientClientClient
  13. 13. SPOF API Server DB ServerClientClientClient
  14. 14. SPOF API Server DB ServerClientClientClient
  15. 15. SPOF ClientClientClient API Server API Server API Server Master DB Slave DB
  16. 16. Name Service - DNS ClientClientClient API Server API Server API Server Master DB Slave DB
  17. 17. DNS Query Result Domain IP www.naver.com 125.209.222.142 202.179.177.21 www.google.com 203.233.96.58 203.233.96.57 203.233.96.56
  18. 18. DNS로만 한다면 서버가 죽었을땐? (DNS TTL?)
  19. 19. Name Service - LB ClientClientClient API Server API Server API Server L B Master DB Slave DB
  20. 20. Stateless Shared Nothing
  21. 21. Stateless
  22. 22. Stateless 하지 않다면? ClientClientClient API Server API Server API Server L B Master DB Slave DB
  23. 23. Stateless 하지 않으면? 부하가 많아서 서버를 늘렸는데… 기존 사용자가 새 서버를 이용할 수 있을까? 부하가 없어서 서버를 줄였는데… 기존 사용자가 없는 서버를 찾는다면?
  24. 24. Sticky Session?
  25. 25. Stateless 의 장단점 장점 추가/제거가 쉽다 단점 결국 Stateful 한 서비스에 의존하게 된다.(조삼모사) 크고 안정적인 Stateful 서비스가 필요하다. 관리를 여기에 집중한다.(DB/Cache)
  26. 26. API 서버 -> Stateless 그럼 DB 단은?
  27. 27. Shared Nothing
  28. 28. 일반적인 DB 서버의 부하 200 writes/s 800 reads/s Read > Write
  29. 29. 읽기 분배 - Query Off WEB/AS Master Slave ONLY WRITE Slave Slave Only READ REPLICATION
  30. 30. 읽기 분배 - 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
  31. 31. Slave 장비를 추가하면 계속 성능이 증가할까?
  32. 32. 읽기 분산의 한계 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
  33. 33. Database Partitioning
  34. 34. Vertical Partitioning
  35. 35. Horizontal Partitioning
  36. 36. Sharding Horizontal Partitioning
  37. 37. 특정 Key 를 어디에 저장할 것인가?
  38. 38. 특정 Key 를 저장하는 방법 특정 Key 를 찾는 방법
  39. 39. 특정 Key를 찾는 방법 특정 유저의 데이터는 어디에 있을까? 특정 모텔 정보는 어디에 있을까?
  40. 40. Range 특정 범위대역으로 나누기 젤 쉬움 Server #1 Server #2 Server #3 User #1 ~ 100 User #101 ~ 200 User #201 ~ 300
  41. 41. Range 특정 서버가 놀거나 부하가 몰릴 가능성이 가장 큼 가입 이벤트, 1~2주후 유저 잔존률이 얼마나 될까?
  42. 42. Modular 서버 대수로 나누기 Server #1 Server #2 User #0 User #1 User #2 User #3
  43. 43. Modular 여기서 서버가 한대가 추가되면 무슨 난리가… 데이터가 모두 섞여야 한다. Server #1 Server #2 User #0 User #1 User #3 User #4 Server #2 User #2 User #5
  44. 44. Modular 두배로 늘리기 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
  45. 45. Modular 이미 서버가 한 16대쯤 있다면? 다음에 늘려야 할 서버 대수는
  46. 46. Indexed 특정 데이터의 위치를 가리키는 서버가 존재 Server #1 Server #2 Server #3 User #1 Index User #1 -> 3 User #100 -> 1 User #102 -> 1 User #100 User #102
  47. 47. Indexed Index 서버에 부하가 몰아치면? Index 서버가 장애나면?
  48. 48. Complexed 위의 방식들을 잘~~~알 조합해보자.
  49. 49. 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
  50. 50. KEY 설계를 어떻게 할 것인가?
  51. 51. 키만 보고 어떤 서버에서 찾아야 할지 알 수 있지않을까?
  52. 52. Pinterest 의 ID
  53. 53. Twitter의 ID
  54. 54. Instagram 의 ID
  55. 55. MongoDB 의 ID
  56. 56. 보통 Shard ID 가 들어감
  57. 57. 시간 정보가 들어가면 ID 만으로 시간 정렬이 가능
  58. 58. 뭔가 변화하지 않을 특별 한 정보가 있다면 ID에 들어가 있으면 좋음.
  59. 59. Load Balancing Client Side VS Server Side
  60. 60. Client Side ClientClient예약 Server 결제 Server 결제 Server 결제 Server 예약 서버가 결제 서버를 호출한다고 하면? 1 2 3
  61. 61. Server Side ClientClient예약 Server 결제 Server 결제 Server 결제 Server 예약 서버가 결제 서버를 호출한다고 하면? Proxy LB
  62. 62. Coordinator Zookeeper Etcd Consul Eureka
  63. 63. Zookeeper Data Model 그냥 디렉토리
  64. 64. Zookeeper 의 특징  절대로 죽지않는다.(거짓말) 잘 안죽는다.(몇대 죽어도 상관은 없다.) 그러나 다 죽을때도 종종 있음.  임시 노드의 경우, Health Check를 통해서 자동적으로 접 속된 노드가 사라지면 데이터가 사라진다.(30초가 기본…) Cluster Membership  노드의 순서를 보장해준다. Leader Election
  65. 65. Leader Election Naming Service Cluster Membership
  66. 66. Cluster Membership Cases API Server 가 추가/변경 되었다. Database Master 장비가 추가/변경되었다. Cache 장비가 추가/변경 되었다. 우리의 대응은? 목록을 추가하고, 배포해야 합니다. 목록만 추가하면 알아서 동작합니다. 장비만 추가하면 알아서 동작합니다.
  67. 67. Zookeeper Ephemeral Node
  68. 68. 서버와의 연결이 끊어지면 노드 정보도 사라짐
  69. 69. 해당 노드의 Child 정보만 읽어와서 접속하면 목록관리 가능
  70. 70. Name Service 도 유사하게 구현 가능
  71. 71. Configuration Feature Flag 새로 나간 기능을 어떻게 제어할 수 있을까요? 대응 방법 기능 설정 후 재배포? 클라이언트는? 그냥 설정을 동적으로 바꾸는 방법은?
  72. 72. Watch 기능을 이용!!!
  73. 73. Leader Election
  74. 74. 여러 대의 서버 중에서 한대만 그 일을 하게 하고 싶을 때 (or 분산 Lock)
  75. 75. Hell of Health Check ClientClient예약 Server Health Check가 죽으면? Health Check
  76. 76. Hell of Health Check ClientClient예약 Server 무한 Health Check Health Check Health Check2 Health Check3 Health Check N
  77. 77. 그런데 여러 개를 띄우면… 알람이 동시에 여러 개가…
  78. 78. Leader 만 일해라. ClientClient예약 Server Leader 만 동작한다. Health Check Health Check Health Check
  79. 79. Leader Election 클라이언트들 간의 약속으로 정해둠.
  80. 80. Circuit Breaker
  81. 81. 한 화면을 구성하는데 몇 개의 API가 필요할까요?
  82. 82. 그 중에 하나라도 실패하면?
  83. 83. 필수적인 API VS 필수적이지 않은 API
  84. 84. Circuit Breaker 필수적이지 않은 API가 장애 중 매번 호출할 때마다, 시간이 많이 걸림 장애 난 API 응답을 그냥 디폴트로 처리하면 안될 까? 매번 찌르는 것도 손해…
  85. 85. Fast Fail Back and Background Check
  86. 86. Netflix Hystrix
  87. 87. Deployment
  88. 88. Blue-Green Deployment
  89. 89. Netflix
  90. 90. Blue-Green
  91. 91. Blue-Green Deployment  Blue Set 과 Green Set이 존재.  현재 Blue Set으로 서비스 중이라면, 같은 양의 Green을 준비해서 Green Set에 새로운 버전을 배포…  일부 트래픽을 Green Set에 투입해서 테스트…  정상적이면, Blue Set을 바라보는 설정을 모두 Green을 바라보도록 수정  문제가 있다면, Blue Set으로 롤백  문제가 없다면, Blue Set 제거
  92. 92. Blue-Green 는 쉬운가? 같은 수의 장비를 쉽게 준비할 수 있을까? Cloud 라면 손쉬움(두 벌을 유지하는 시간이 음.) IDC 라면 어떻게? 예전에 모 B사의 W모 게임이 그렇게 했다고 합 니다.(거기는 부자니…)
  93. 93. Blue-Green 싸게 도입하기 점검 기간 두기 4대 보검중에 하나, 정기정검(게임쪽) 무정지 서비스가 안됨 Rolling Update 한대씩 로드밸런서나 설정에서 제거 후 배포 백업이나 배포 자체가 느릴 수 밖에 없음.
  94. 94. Blue-Green 싸게 도입하기 리소스를 제한해서 한 서버에서 두 개의 프로 세스 실행 Port 10000, 20000 번으로 배포. Nginx 나 Proxy 단에서 설정 변경으로 새로운 서버로 전환 리소스를 적절하게 나누지 못하면 리소스 부족으로 서 버 장애 발생 가능
  95. 95. Blue-Green 야매 버전 ClientClientClientClient LB Proxy API : 10000 API : 20000 DB
  96. 96. Blue-Green 야매 버전 ClientClientClientClient LB Proxy API : 10000 API : 20000 DB
  97. 97. Blue-Green 야매 버전 ClientClientClientClient LB Proxy API : 10000 API : 20000 DB
  98. 98. Blue-Green 야매 버전 ClientClientClientClient LB Proxy API : 10000 API : 20000 DB
  99. 99. Location Latency?
  100. 100. 서울 부산 IDC의 Latency Seoul Busan API Server DB Server Latency 3 ~ 7ms
  101. 101. 같은 지역의 DB를 사용할 때는 20~30ms 정도
  102. 102. API Server의 호출은 최저 300ms
  103. 103. What Happen?
  104. 104. Location Latency #1 Seoul Busan DB Server Select * from posts where id=123; results Select member from members where id=poster.group; results API Server Logic Server
  105. 105. Location Latency #2 Seoul Busan API Server DB Server getMembersList() results Logic Server
  106. 106. 그런데…
  107. 107. 서비스가 잘 돌아가는 건 어떻게 알 수 있을까요?
  108. 108. 모니터링/로그
  109. 109. 결론 Internet Scale의 서비스를 만들기 위한 방법을 이해한다. Kubernetes 나 Mesos 등등을 적용하면 직접 하는 것 보다 더 손쉽게 가능하기도(이건 저도 잘 모름) Rolling Update, 자동재시작 이런것들을 처리해주는… 모니터링/로그는 더더욱 중요합니다.
  110. 110. Thank you.

×