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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

@aatarasoff @aatarasoff @aatarasoff 2 @aatarasoff [email protected]

Slide 3

Slide 3 text

Минздрав предупреждает Мнение докладчика может не совпадать с официальной позицией его работодателя, коллег или других специалистов. Все представленные в докладе сведения, примеры, выводы и другую информацию вы можете использовать на свой страх и риск. За все ваши действия ответственность несёте только вы сами. 3

Slide 4

Slide 4 text

Что такое ANNA? ANNA stands for Absolutely No Nonsense Admin. Because that’s what we do. 4

Slide 5

Slide 5 text

● Стартап в UK ● Банк для бизнеса ● Mobile-First ● AI Assistant 5

Slide 6

Slide 6 text

When We Were Young ● 10 сервисов ● 2 интеграции с партнерами ● 1 команда ● 4 тестовых среды 6

Slide 7

Slide 7 text

We Are Still Young, But... ● 10 -> 150+ сервисов ● 2 -> 10+ интеграций с партнерами ● 1 -> 7 независимых команд ● 4 -> 30+ тестовых сред 7

Slide 8

Slide 8 text

Пролог: Service Mesh 101 8

Slide 9

Slide 9 text

P2P-коммуникация между сервисами 9

Slide 10

Slide 10 text

Подход с shared-библиотеками 10

Slide 11

Slide 11 text

Слишком много библиотек... 11

Slide 12

Slide 12 text

Преимущества ● Platform-agnostic ● Простота реализации ● Нативно для разработчиков Подход с shared-библиотеками 12

Slide 13

Slide 13 text

Преимущества ● Platform-agnostic ● Простота реализации ● Нативно для разработчиков Недостатки ● Управление зависимостями ● Библиотека на каждый ЯП ● Требует пересборки сервисов Подход с shared-библиотеками 13

Slide 14

Slide 14 text

Sidecar Pattern 14

Slide 15

Slide 15 text

Service Mesh 15

Slide 16

Slide 16 text

Унификация нефункциональных требований 16

Slide 17

Slide 17 text

Преимущества ● Консистентность ● Ортогональное использование ● Централизация Подход с Service Mesh 17

Slide 18

Slide 18 text

Преимущества ● Консистентность ● Ортогональное использование ● Централизация Недостатки ● Сайдкар под платформу ● Возможная сложность сайдкара ● Имеет цену ○ производительность ○ ресурсы CPU/Mem/Network Подход с Service Mesh 18

Slide 19

Slide 19 text

Какие проблемы то решаем? 19

Slide 20

Slide 20 text

Типичная MSA 20

Slide 21

Slide 21 text

Microservices Architecture Problems ● Reliability ● Observability ● Security 21

Slide 22

Slide 22 text

Reliability 22

Slide 23

Slide 23 text

Observability 23

Slide 24

Slide 24 text

Security 24

Slide 25

Slide 25 text

18 месяцев назад 25

Slide 26

Slide 26 text

Количество сервисов резко возрастало и хотелось иметь возможность быстро понимать, где есть узкие места 26

Slide 27

Slide 27 text

А давайте внедрим Service Mesh! 27

Slide 28

Slide 28 text

А давайте внедрим Service Mesh! Сможем класть трейсы в Jaeger! 28

Slide 29

Slide 29 text

Кажется Istio нам подходит 29

Slide 30

Slide 30 text

Проблемы использования Istio ● High resource consumption ● Complicated and slow UI ● Distributed Tracing doesn’t work 30

Slide 31

Slide 31 text

Проблемы использования Istio ● High resource consumption ● Complicated and slow UI ● Distributed Tracing doesn’t work 31

Slide 32

Slide 32 text

Проблемы использования Istio ● High resource consumption ● Complicated and slow UI ● Distributed Tracing doesn’t work 32

Slide 33

Slide 33 text

Distributed Tracing Problem 33

Slide 34

Slide 34 text

А что именно нам надо? Трейсы! 34

Slide 35

Slide 35 text

Netramesh 35

Slide 36

Slide 36 text

Distributed Tracing with Netramesh 36

Slide 37

Slide 37 text

То, ради чего всё затевалось 37

Slide 38

Slide 38 text

Recap Нужны трейсы, а не Service Mesh 38

Slide 39

Slide 39 text

Recap Нужны трейсы, а не Service Mesh Лендинги и бренд могут вводить в заблуждение 39

Slide 40

Slide 40 text

Recap Нужны трейсы, а не Service Mesh Лендинги и бренд могут вводить в заблуждение Могли бы мы обойтись без Service Mesh? Да! 40

Slide 41

Slide 41 text

6 месяцев назад 41

Slide 42

Slide 42 text

Количество сервисов всё ещё возрастало... 42

Slide 43

Slide 43 text

А давайте всё-таки внедрим Service Mesh! 43

Slide 44

Slide 44 text

Load balancing А давайте всё-таки внедрим Service Mesh! Canary releases More observability mTLS Authorization policies 44

Slide 45

Slide 45 text

Хотелки ● mTLS ● Zero-Trust Security ● Canary Releases ● Robust Load Balancing ● Observability ● Low Resource Consumption ● Pretty UI ● Easy Conﬁguration 45

Slide 46

Slide 46 text

Преимущества ● Децентрализация ● Хорошая масштабируемость ● Возможность трассировки по кастомному заголовку Netramesh 46

Slide 47

Slide 47 text

Преимущества ● Децентрализация ● Хорошая масштабируемость ● Возможность трассировки по кастомному заголовку Недостатки ● Ограниченные возможности роутинга запросов ● Отсутствие mTLS ● Отсутствие политик авторизации Netramesh 47

Slide 48

Slide 48 text

Кандидаты на Proof-of-Concept 48

Slide 49

Slide 49 text

Kuma Istio Linkerd mTLS Authorization Policies Canary Releases Robust Load Balancing Load Balancing Options Observability Resource Consumption UI Conﬁguration Красно-зеленая таблица сравнения 49

Slide 50

Slide 50 text

Resource Consumption Зачем? - Cost-Eﬃciency 50

Slide 51

Slide 51 text

CPU/Memory Kuma/Istio 51

Slide 52

Slide 52 text

CPU/Memory Linkerd 52

Slide 53

Slide 53 text

CPU/Memory Linkerd vs Istio https://linkerd.io/2021/05/27/linkerd-vs-istio-benchmarks/ 53

Slide 54

Slide 54 text

Kuma Istio Linkerd mTLS Authorization Policies Canary Releases Robust Load Balancing Load Balancing Options Observability Resource Consumption Very High High Low UI Conﬁguration Сравнительное потребление ресурсов 54

Slide 55

Slide 55 text

Observability Зачем? - Понимание того, что происходит 55

Slide 56

Slide 56 text

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 Conﬁguration Без модификации сервисов не обойтись 56

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Client Load Balancing Зачем? Уменьшить латенси Увеличить стабильность 58

Slide 59

Slide 59 text

Client Load Balancing 59

Slide 60

Slide 60 text

Client Load Balancing GKE does not support IPVS 60

Slide 61

Slide 61 text

Load Balancing with Service Mesh 61

Slide 62

Slide 62 text

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 Conﬁguration Load Balancing + Options 62

Slide 63

Slide 63 text

Canary Releases Зачем? - Чувствовать себя увереннее при деплое 63

Slide 64

Slide 64 text

Canary Releases 64

Slide 65

Slide 65 text

L4 Traﬃc Routing via Traﬃc 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

Slide 66

Slide 66 text

L7 Traﬃc Routing via Traﬃc 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

Slide 67

Slide 67 text

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 Conﬁguration Canary Releases 67

Slide 68

Slide 68 text

mTLS / Zero-Trust Policies Зачем? - Чувствовать себя защищеннее 68

Slide 69

Slide 69 text

Типичная MSA 69

Slide 70

Slide 70 text

Frontend Backend A Backend B Backend C Hacked Service Уровень защиты определяется самым слабым звеном 70

Slide 71

Slide 71 text

Frontend Backend A Backend B Backend C Hacked Service Без политик авторизации Get Data 71

Slide 72

Slide 72 text

Frontend Backend A Backend B Backend C Hacked Service Без шифрования трафика Listen traffic 72

Slide 73

Slide 73 text

Frontend Backend A Backend B Backend C Hacked Service Ограничение доступа по политикам авторизации Restrict access 73

Slide 74

Slide 74 text

Frontend Backend A Backend B Backend C Hacked Service Использование mTLS Prevent listening traffic because it is encrypted 74

Slide 75

Slide 75 text

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 Conﬁguration Canary Releases 75

Slide 76

Slide 76 text

UI / Conﬁguration Зачем? - Чтобы не шла кровь из глаз 76

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Linkerd потому что ● Легковесность ● Низкое потребление ресурсов ● EWMA 79

Slide 80

Slide 80 text

Recap Каждое решение имеет свои трейд-оффы Service Mesh is not a free lunch 80

Slide 81

Slide 81 text

Recap Каждое решение имеет свои трейд-оффы Service Mesh is not a free lunch Мы выбрали более легкое решение с минимальным оверхедом 81

Slide 82

Slide 82 text

Recap Каждое решение имеет свои трейд-оффы Service Mesh is not a free lunch Мы выбрали более легкое решение с минимальным оверхедом 82 Ваш выбор может быть иной!

Slide 83

Slide 83 text

Могли бы мы обойтись без Service Mesh? 83

Slide 84

Slide 84 text

День доклада 84

Slide 85

Slide 85 text

Количество сервисов всё ещё возрастает... 85

Slide 86

Slide 86 text

А что мы получили от Linkerd? Время порефлексировать 86

Slide 87

Slide 87 text

Microservices Architecture Problems ● Reliability ● Observability ● Security 87

Slide 88

Slide 88 text

Совмещенный подход 88

Slide 89

Slide 89 text

Совмещенный подход EWMA Retries, timeouts Deadline propagation 89

Slide 90

Slide 90 text

Совмещенный подход EWMA Retries, timeouts Deadline propagation Retries, timeouts (?) 90

Slide 91

Slide 91 text

Linkerd Routes Conﬁguration 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

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

Совмещенный подход EWMA Retries, timeouts Deadline propagation Retries, timeouts 95

Slide 96

Slide 96 text

Canary Releases Необходимо внешнее решение 96

Slide 97

Slide 97 text

Canary Releases Необходимо внешнее решение 97 Проблема принятия решения что нужно откатывать Database? Third-Party System

Slide 98

Slide 98 text

Slide 99

Slide 99 text

Canary Releases не взлетели ● Continuous Delivery Pipeline как конкурент ○ 5-10 минут на выкатку сервиса ○ тестирование критичного функционала ○ rolling update стратегия выкатки ● Автоматизированная процедура отката ○ метрики и алерты ○ разработчик принимает решение ○ откат за 3-5 минут (с учетом миграций) 99

Slide 100

Slide 100 text

Slide 101

Slide 101 text

Microservices Architecture Problems ● Reliability ● Observability ● Security 101

Slide 102

Slide 102 text

Microservices Architecture Problems ● Reliability ● Observability ● Security 102

Slide 103

Slide 103 text

Linkerd Dashboard Метрики по неймспейсам Real-Time метрики для сервиса 103

Slide 104

Slide 104 text

Linkerd Dashboard Website не на питоне 104

Slide 105

Slide 105 text

Унифицированные метрики 105

Slide 106

Slide 106 text

Проблемы сбора трейсов 106

Slide 107

Slide 107 text

Схема сбора трейсов 107

Slide 108

Slide 108 text

Использование Open Telemetry 108

Slide 109

Slide 109 text

Stackdriver или Jaeger? 109

Slide 110

Slide 110 text

Jaeger - мёртв, Stackdriver - жив BigQuery as Long-Term storage and analytical tool 110

Slide 111

Slide 111 text

Stackdriver - репорты, отчёты 111

Slide 112

Slide 112 text

Microservices Architecture Problems ● Reliability ● Observability ● Security 112

Slide 113

Slide 113 text

Microservices Architecture Problems ● Reliability ● Observability ● Security 113

Slide 114

Slide 114 text

mTLS + Authorization. Default mTLS - permissive Authorization Policy - allow all 114

Slide 115

Slide 115 text

mTLS + Authorization. Strict mTLS mTLS - strict Authorization Policy - allow all 115

Slide 116

Slide 116 text

mTLS + Authorization. Strict mTLS Be careful. Nginx Ingress or Prometheus could be out of mesh 116

Slide 117

Slide 117 text

mTLS + Authorization. Deny mode mTLS - strict Authorization Policy - deny all 117

Slide 118

Slide 118 text

Реальный нереальный пример 118

Slide 119

Slide 119 text

Реальный нереальный пример 119 RTFM https://itnext.io/a-practical-guide-for-linkerd-authorization-policies-6cfdb50392e9

Slide 120

Slide 120 text

Организация политик авторизации У вас 150+ сервисов 120

Slide 121

Slide 121 text

Explicit Conﬁguration #no one allowed allowedServiceAccounts: [] #only service #3 is allowed allowedServiceAccounts: - namespace: elephants name: service3 Легко понять Легко шаблонизировать Но! Нужно идентифицировать всех клиентов 121

Slide 122

Slide 122 text

Native Conﬁguration #no dependencies dependencies: [] #service #3 depends on #1 and #2 dependencies: - namespace: elephants name: service1 - namespace: elephants name: service2 Более естественный способ описания Но! Нужно решить обратную задачу (обратный граф) 122

Slide 123

Slide 123 text

Наша конфигурация --- #service #1 depends on #2 and #3 dependencies: - namespace: elephants name: service2 - namespace: elephants name: service3 123 Разрешено, пока не запрещено

Slide 124

Slide 124 text

Наша конфигурация --- #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 Разрешено, пока не запрещено

Slide 125

Slide 125 text

Microservices Architecture Problems ● Reliability ● Observability ● Security 125

Slide 126

Slide 126 text

Могли бы мы обойтись без Service Mesh? 126

Slide 127

Slide 127 text

Могли бы мы обойтись без Service Mesh? Могли, но это было бы ещё больнее! 127

Slide 128

Slide 128 text

Выводы Service Mesh как концепция, и Service Mesh как решение Как концепция тем лучше, чем более разнородна и сложна архитектура 128

Slide 129

Slide 129 text

Выводы Service Mesh как решение не является серебряной пулей Выбор конкретного решения зависит от приемлемых вам трейд-оффов 129 Финальный результат требует напильника и может удивлять

Slide 130

Slide 130 text

Дьявол в деталях!

Slide 131

Slide 131 text

Ваши вопросы? [email protected] @aatarasoff @aatarasoff @aatarasoff @aatarasoff 131