Вам не нужен Service Mesh, но это не точно

📢 Service Mesh обещает нам много крутого, но так ли это на практике? Понимать всегда приятнее на конкретных примерах. Именно поэтому мы познакомимся с Service Mesh при помощи истории его внедрения в отдельно взятой компании.
Вам не нужен Service Mesh, но это не точно
👨‍💻 Казалось бы, Service Mesh — это и observability, и разные стратегии балансировки клиентских запросов, и улучшение внутренней безопасности, и много чего ещё. Вплоть до розовых единорогов, извергающих радугу.
💥 Полтора года назад в ANNA Money задумались над внедрением Service Mesh-решения, так как с увеличением количества сервисов, увеличивается и количество того, что может пойти не так. В свою очередь, понимания того, что происходит внутри системы, становится меньше. Service Mesh должен был стать серебряной пулей, но не стал.

Transcript

1. Вам не нужен Service Mesh, но это не точно
2. @aatarasoff @aatarasoff @aatarasoff 2 @aatarasoff tarasoff@anna.money
3. Минздрав предупреждает Мнение докладчика может не совпадать с официальной позицией его работодателя, коллег или других специалистов. Все представленные в докладе сведения, примеры, выводы и другую информацию вы можете использовать на свой страх и риск. За все ваши действия ответственность несёте только вы сами. 3
4. Что такое ANNA? ANNA stands for Absolutely No Nonsense Admin. Because that’s what we do. 4
5. • Стартап в UK • Банк для бизнеса • Mobile-First • AI Assistant 5
6. When We Were Young • 10 сервисов • 2 интеграции с партнерами • 1 команда • 4 тестовых среды 6
7. We Are Still Young, But... • 10 -> 150+ сервисов • 2 -> 10+ интеграций с партнерами • 1 -> 7 независимых команд • 4 -> 30+ тестовых сред 7
8. Пролог: Service Mesh 101 8
9. P2P-коммуникация между сервисами 9
10. Подход с shared-библиотеками 10
11. Слишком много библиотек... 11
12. Преимущества • Platform-agnostic • Простота реализации • Нативно для разработчиков Подход с shared-библиотеками 12
13. Преимущества • Platform-agnostic • Простота реализации • Нативно для разработчиков Недостатки • Управление зависимостями • Библиотека на каждый ЯП • Требует пересборки сервисов Подход с shared-библиотеками 13
14. Sidecar Pattern 14
15. Service Mesh 15
16. Унификация нефункциональных требований 16
17. Преимущества • Консистентность • Ортогональное использование • Централизация Подход с Service Mesh 17
18. Преимущества • Консистентность • Ортогональное использование • Централизация Недостатки • Сайдкар под платформу • Возможная сложность сайдкара • Имеет цену ◦ производительность ◦ ресурсы CPU/Mem/Network Подход с Service Mesh 18
19. Какие проблемы то решаем? 19
20. Типичная MSA 20
21. Microservices Architecture Problems • Reliability • Observability • Security 21
22. Reliability 22
23. Observability 23
24. Security 24
25. 18 месяцев назад 25
26. Количество сервисов резко возрастало и хотелось иметь возможность быстро понимать, где есть узкие места 26
27. А давайте внедрим Service Mesh! 27
28. А давайте внедрим Service Mesh! Сможем класть трейсы в Jaeger! 28
29. Кажется Istio нам подходит 29
30. Проблемы использования Istio • High resource consumption • Complicated and slow UI • Distributed Tracing doesn’t work 30
31. Проблемы использования Istio • High resource consumption • Complicated and slow UI • Distributed Tracing doesn’t work 31
32. Проблемы использования Istio • High resource consumption • Complicated and slow UI • Distributed Tracing doesn’t work 32
33. Distributed Tracing Problem 33
34. А что именно нам надо? Трейсы! 34
35. Netramesh 35
36. Distributed Tracing with Netramesh 36
37. То, ради чего всё затевалось 37
38. Recap Нужны трейсы, а не Service Mesh 38
39. Recap Нужны трейсы, а не Service Mesh Лендинги и бренд могут вводить в заблуждение 39
40. Recap Нужны трейсы, а не Service Mesh Лендинги и бренд могут вводить в заблуждение Могли бы мы обойтись без Service Mesh? Да! 40
41. 6 месяцев назад 41
42. Количество сервисов всё ещё возрастало... 42
43. А давайте всё-таки внедрим Service Mesh! 43
44. Load balancing А давайте всё-таки внедрим Service Mesh! Canary releases More observability mTLS Authorization policies 44
45. Хотелки • mTLS • Zero-Trust Security • Canary Releases • Robust Load Balancing • Observability • Low Resource Consumption • Pretty UI • Easy Configuration 45
46. Преимущества • Децентрализация • Хорошая масштабируемость • Возможность трассировки по кастомному заголовку Netramesh 46
47. Преимущества • Децентрализация • Хорошая масштабируемость • Возможность трассировки по кастомному заголовку Недостатки • Ограниченные возможности роутинга запросов • Отсутствие mTLS • Отсутствие политик авторизации Netramesh 47
48. Кандидаты на Proof-of-Concept 48
49. Kuma Istio Linkerd mTLS Authorization Policies Canary Releases Robust Load Balancing Load Balancing Options Observability Resource Consumption UI Configuration Красно-зеленая таблица сравнения 49
50. Resource Consumption Зачем? - Cost-Efficiency 50
51. CPU/Memory Kuma/Istio 51
52. CPU/Memory Linkerd 52
53. CPU/Memory Linkerd vs Istio https://linkerd.io/2021/05/27/linkerd-vs-istio-benchmarks/ 53
54. Kuma Istio Linkerd mTLS Authorization Policies Canary Releases Robust Load Balancing Load Balancing Options Observability Resource Consumption Very High High Low UI Configuration Сравнительное потребление ресурсов 54
55. Observability Зачем? - Понимание того, что происходит 55
56. Kuma Istio Linkerd mTLS Authorization Policies Canary Releases Robust Load Balancing Load Balancing Options Observability Tracing requires app modification Tracing requires app modification Tracing requires app modification Resource Consumption Very High High Low UI Configuration Без модификации сервисов не обойтись 56
57. Kuma Istio Linkerd mTLS Authorization Policies Canary Releases Robust Load Balancing Load Balancing Options Observability Tracing requires app modification Tracing requires app modification Tracing requires app modification Resource Consumption Very High High Low UI Configuration Без модификации сервисов не обойтись 57 А Netramesh то это умел :(
58. Client Load Balancing Зачем? Уменьшить латенси Увеличить стабильность 58
59. Client Load Balancing 59
60. Client Load Balancing GKE does not support IPVS 60
61. Load Balancing with Service Mesh 61
62. Kuma Istio Linkerd mTLS Authorization Policies Canary Releases Robust Load Balancing Least Requests Least Requests EWMA Load Balancing Options Rich Rich No circuit breaker Observability Tracing requires app modification Tracing requires app modification Tracing requires app modification Resource Consumption Very High High Low UI Configuration Load Balancing + Options 62
63. Canary Releases Зачем? - Чувствовать себя увереннее при деплое 63
64. Canary Releases 64
65. L4 Traffic Routing via Traffic Split SMI apiVersion: split.smi-spec.io/v1alpha4 kind: TrafficSplit metadata: name: banking-service-split namespace: banking spec: service: banking-service backends: - service: banking-service-primary weight: 900m - service: banking-service-canary weight: 100m 65
66. L7 Traffic Routing via Traffic Split SMI ... spec: service: banking-service matches: - kind: HTTPRouteGroup name: beta-users backends: - service: banking-service-primary weight: 0 - service: banking-service-canary weight: 100 --- kind: HTTPRouteGroup metadata: name: beta-users matches: - name: beta-users headers: - user-group: "Beta" 66
67. Kuma Istio Linkerd mTLS Authorization Policies Canary Releases L4/L7 Own specification L4/L7 Own specification L4 only Traffic Split SMI Robust Load Balancing Least Requests Least Requests EWMA Load Balancing Options Rich Rich No circuit breaker Observability Tracing requires app modification Tracing requires app modification Tracing requires app modification Resource Consumption Very High High Low UI Configuration Canary Releases 67
68. mTLS / Zero-Trust Policies Зачем? - Чувствовать себя защищеннее 68
69. Типичная MSA 69
70. Frontend Backend A Backend B Backend C Hacked Service Уровень защиты определяется самым слабым звеном 70
71. Frontend Backend A Backend B Backend C Hacked Service Без политик авторизации Get Data 71
72. Frontend Backend A Backend B Backend C Hacked Service Без шифрования трафика Listen traffic 72
73. Frontend Backend A Backend B Backend C Hacked Service Ограничение доступа по политикам авторизации Restrict access 73
74. Frontend Backend A Backend B Backend C Hacked Service Использование mTLS Prevent listening traffic because it is encrypted 74
75. Kuma Istio Linkerd mTLS Authorization Policies Disabled by default, Authorization policies are available Enabled by default, Authorization policies are available Enabled by default, Authorization policies are available Canary Releases L4/L7 Own specification L4/L7 Own specification L4 only Traffic Split SMI Robust Load Balancing Least Requests Least Requests EWMA Load Balancing Options Rich Rich No circuit breaker Observability Tracing requires app modification Tracing requires app modification Tracing requires app modification Resource Consumption Very High High Low UI Configuration Canary Releases 75
76. UI / Configuration Зачем? - Чтобы не шла кровь из глаз 76
77. Kuma Istio Linkerd mTLS Authorization Policies Disabled by default, Authorization policies are available Enabled by default, Authorization policies are available Enabled by default, Authorization policies are available Canary Releases L4/L7 Own specification L4/L7 Own specification L4 only Traffic Split SMI Robust Load Balancing Least Requests Least Requests EWMA Load Balancing Options Rich Rich No circuit breaker Observability Tracing requires app modification Tracing requires app modification Tracing requires app modification Resource Consumption Very High High Low UI Good External (Kiali) Good Configuration Easy Hard Easy Красивости и субъективное удобство 77
78. Kuma Istio Linkerd mTLS Authorization Policies Disabled by default, Authorization policies are available Enabled by default, Authorization policies are available Enabled by default, Authorization policies are available Canary Releases L4/L7 Own specification L4/L7 Own specification L4 only Traffic Split SMI Robust Load Balancing Least Requests Least Requests EWMA Load Balancing Options Rich Rich No circuit breaker Observability Tracing requires app modification Tracing requires app modification Tracing requires app modification Resource Consumption Very High High Low UI Good External (Kiali) Good Configuration Easy Hard Easy Выбери свои трейд-оффы 78
79. Linkerd потому что • Легковесность • Низкое потребление ресурсов • EWMA 79
80. Recap Каждое решение имеет свои трейд-оффы Service Mesh is not a free lunch 80
81. Recap Каждое решение имеет свои трейд-оффы Service Mesh is not a free lunch Мы выбрали более легкое решение с минимальным оверхедом 81
82. Recap Каждое решение имеет свои трейд-оффы Service Mesh is not a free lunch Мы выбрали более легкое решение с минимальным оверхедом 82 Ваш выбор может быть иной!
83. Могли бы мы обойтись без Service Mesh? 83
84. День доклада 84
85. Количество сервисов всё ещё возрастает... 85
86. А что мы получили от Linkerd? Время порефлексировать 86
87. Microservices Architecture Problems • Reliability • Observability • Security 87
88. Совмещенный подход 88
89. Совмещенный подход EWMA Retries, timeouts Deadline propagation 89
90. Совмещенный подход EWMA Retries, timeouts Deadline propagation Retries, timeouts (?) 90
91. Linkerd Routes Configuration apiVersion: linkerd.io/v1alpha2 kind: ServiceProfile metadata: name: banking-service.banking.svc.cluster.local namespace: banking spec: routes: - condition: method: GET pathRegex: "/.*" name: GET /* isRetryable: true timeout: 300ms retryBudget: retryRatio: 0.2 minRetriesPerSecond: 10 ttl: 10s 91
92. Linkerd Routes Configuration apiVersion: linkerd.io/v1alpha2 kind: ServiceProfile metadata: name: banking-service.banking.svc.cluster.local namespace: banking spec: routes: - condition: method: GET pathRegex: "/.*" name: GET /* isRetryable: true timeout: 300ms retryBudget: retryRatio: 0.2 minRetriesPerSecond: 10 ttl: 10s 92
93. Linkerd Routes Configuration apiVersion: linkerd.io/v1alpha2 kind: ServiceProfile metadata: name: banking-service.banking.svc.cluster.local namespace: banking spec: routes: - condition: method: GET pathRegex: "/.*" name: GET /* isRetryable: true timeout: 300ms retryBudget: retryRatio: 0.2 minRetriesPerSecond: 10 ttl: 10s 93
94. Linkerd Routes Configuration apiVersion: linkerd.io/v1alpha2 kind: ServiceProfile metadata: name: banking-service.banking.svc.cluster.local namespace: banking spec: routes: - condition: method: GET pathRegex: "/.*" name: GET /* isRetryable: true timeout: 300ms retryBudget: retryRatio: 0.2 minRetriesPerSecond: 10 ttl: 10s 94
95. Совмещенный подход EWMA Retries, timeouts Deadline propagation Retries, timeouts 95
96. Canary Releases Необходимо внешнее решение 96
97. Canary Releases Необходимо внешнее решение 97 Проблема принятия решения что нужно откатывать Database? Third-Party System
98. Canary Releases не взлетели • Continuous Delivery Pipeline как конкурент ◦ 5-10 минут на выкатку сервиса ◦ тестирование критичного функционала ◦ rolling update стратегия выкатки 98
99. Canary Releases не взлетели • Continuous Delivery Pipeline как конкурент ◦ 5-10 минут на выкатку сервиса ◦ тестирование критичного функционала ◦ rolling update стратегия выкатки • Автоматизированная процедура отката ◦ метрики и алерты ◦ разработчик принимает решение ◦ откат за 3-5 минут (с учетом миграций) 99
100. Canary Releases не взлетели • Continuous Delivery Pipeline как конкурент ◦ 5-10 минут на выкатку сервиса ◦ тестирование критичного функционала ◦ rolling update стратегия выкатки • Автоматизированная процедура отката ◦ метрики и алерты ◦ разработчик принимает решение ◦ откат за 3-5 минут (с учетом миграций) • Статистически необходим в 1 на 5 000 релизов 100
101. Microservices Architecture Problems • Reliability • Observability • Security 101
102. Microservices Architecture Problems • Reliability • Observability • Security 102
103. Linkerd Dashboard Метрики по неймспейсам Real-Time метрики для сервиса 103
104. Linkerd Dashboard Website не на питоне 104
105. Унифицированные метрики 105
106. Проблемы сбора трейсов 106
107. Схема сбора трейсов 107
108. Использование Open Telemetry 108
109. Stackdriver или Jaeger? 109
110. Jaeger - мёртв, Stackdriver - жив BigQuery as Long-Term storage and analytical tool 110
111. Stackdriver - репорты, отчёты 111
112. Microservices Architecture Problems • Reliability • Observability • Security 112
113. Microservices Architecture Problems • Reliability • Observability • Security 113
114. mTLS + Authorization. Default mTLS - permissive Authorization Policy - allow all 114
115. mTLS + Authorization. Strict mTLS mTLS - strict Authorization Policy - allow all 115
116. mTLS + Authorization. Strict mTLS Be careful. Nginx Ingress or Prometheus could be out of mesh 116
117. mTLS + Authorization. Deny mode mTLS - strict Authorization Policy - deny all 117
118. Реальный нереальный пример 118
119. Реальный нереальный пример 119 RTFM https://itnext.io/a-practical-guide-for-linkerd-authorization-policies-6cfdb50392e9
120. Организация политик авторизации У вас 150+ сервисов 120
121. Explicit Configuration #no one allowed allowedServiceAccounts: [] #only service #3 is allowed allowedServiceAccounts: - namespace: elephants name: service3 Легко понять Легко шаблонизировать Но! Нужно идентифицировать всех клиентов 121
122. Native Configuration #no dependencies dependencies: [] #service #3 depends on #1 and #2 dependencies: - namespace: elephants name: service1 - namespace: elephants name: service2 Более естественный способ описания Но! Нужно решить обратную задачу (обратный граф) 122
123. Наша конфигурация --- #service #1 depends on #2 and #3 dependencies: - namespace: elephants name: service2 - namespace: elephants name: service3 123 Разрешено, пока не запрещено
124. Наша конфигурация --- #service #1 depends on #2 and #3 dependencies: - namespace: elephants name: service2 - namespace: elephants name: service3 --- #service3 #only service #2 is allowed allowedServiceAccounts: - namespace: elephants name: service2 124 Разрешено, пока не запрещено
125. Microservices Architecture Problems • Reliability • Observability • Security 125
126. Могли бы мы обойтись без Service Mesh? 126
127. Могли бы мы обойтись без Service Mesh? Могли, но это было бы ещё больнее! 127
128. Выводы Service Mesh как концепция, и Service Mesh как решение Как концепция тем лучше, чем более разнородна и сложна архитектура 128
129. Выводы Service Mesh как решение не является серебряной пулей Выбор конкретного решения зависит от приемлемых вам трейд-оффов 129 Финальный результат требует напильника и может удивлять
130. Дьявол в деталях!
131. Ваши вопросы? tarasoff@anna.money @aatarasoff @aatarasoff @aatarasoff @aatarasoff 131