Devops

CDN往事录

Posted by Zeusro on September 17, 2020
👈🏻 Select language

2018年3月，我正式陆续接管阿米巴集团公司的所有数字资产，成为实际意义上的运维负责人。

由于领导很看重我（老板不舍得花钱），有很长的一段时间，都是我一个人在负责所有事情。

特别是在CDN这一领域，由于涉及到历史遗留项目，域名解析，TTL，国内傻逼互联网运营商（比如长城宽带），这块工作内容更要谨慎处理。

我们先回到根源问题，为什么需要 CDN ，CDN 到底解决了什么问题。

为什么需要CDN

image

要回答这个问题，得从历史的宏观角度思考这个问题。

远古时期的 web 请求，如果走A解析，那么请求链路基本如下：

1

computer --> local DNS  --> server IP

获取服务器IP之后，再由电子终端（电脑、手机、iPad）与服务器建立TCP连接，最后是浏览器渲染。

但这里面有个问题，server IP 只有一个，而 computer 通常有多个，如果用户过多（computer），就会出现网络拥堵。这就好比你去饭馆吃饭，但是老板很抠，服务员只有一个，随着顾客的增多，服务员越来越忙，最终根本顾不上你。

那么，怎么解决这个问题呢？

image

答案当然是砸钱啦！既然你觉得服务员太少，服务不周到。那么你就多出点钱去女仆店，让妹子合法地围绕在你身边。

CDN也是类似这种机制，通过持续投入妹子（CDN边缘加速节点）,更好地服务想要吃饭（使用互联网开车）的人。

使用CDN

后来，当我们摆脱了远古的web时代，来到近现代。随着用户的指数级增长，就需要一套新的架构来适应变化。

而软件设计一直以来有一个套路：如果一层不够，就再加多一层。

image

所以，到了近现代，web 后端架构通常都是一个椒盐千层饼：

1

$host --> cname --> CDN --> SLB ip --> server1,server2,server3,...

而用户的访问链路则是

1

computer --> local DNS  --> CDN

CDN 的本质是一种静态数据的缓冲与缓存。

CDN问题的诊断

大概2015年的时候，我兼职公司的技术支持。经常在QQ上给客户排除技术故障（拉网线）,逐步积累了一些网络诊断(吹牛逼)的经验。

如果我们分拆整个“近现代”web后端的请求链路，就会发现这里面每一层数据的流动都会产生问题。

computer 的问题

主要是垃圾配置，垃圾宽带的问题。对于垃圾宽带的问题，我一般建议用户去 工业和信息化部电信用户申诉受理中心 投诉运营商。

local DNS 的问题

local DNS 也叫本地DNS，如果不特别设置的话，就会走路由器，而路由器则跟运营商。 如果你遇到一个毫无节操的运营商，那么有可能你输入的网址是对的，但是你依旧上不了网。

出现这个问题的原因在于 DNS 服务本身是一个web服务供应商，如果我这边改了DNS IP，而运营商那边故意解析错（DNS污染）或者DNS跟不上（过了TTL依旧缓存旧的记录），整个解析就会有问题。

所以到了后来，我写了一份文档，让运营加入到我们公司的帮助文档里面——主要就是设置下 local DNS ，规避掉运营商弱鸡 DNS 的问题。

image

CDN 的问题

CDN 的问题出现得比较隐蔽，而且通常CDN运营商会甩锅。所以这个时候得详细收集用户数据，再反过来问候CDN父母。

假设出问题的是 stu.17zwd.com。我会让用户访问 https://ipip.net ,截图。然后根据不同的系统，输入不同的命令。

  • [window客户]
1
2
3
4

set host=stu.17zwd.com
ipconfig -all
ping %host%
tracert %host%
  • [mac客户]
1
2
3
4

export host=stu.17zwd.com
nslookup $host
ping $host
traceroute $host

之后再向上游反馈。

*.w.alikunlun.com 通常都是阿里云， *.wswebpic.com 基本是网宿。

权威DNS的问题

image

这个问题出现得很少，我只遇过一次。那一次是服务器在访问某个国内不能备案的域名时出现的。 当时经过与阿里云售后联系发现，是服务器的IP访问权威DNS受限。

因为权威DNS本质上也是一种web服务，它可以主动拒绝不合法连接。

争取议价权

公有云的盈利模式，本质上靠 网络效应 带来的流量费用。随着服务器规模的增多，我们会发现带宽费用会逐渐水涨船高。

经过我大致测算，平摊之后，费用会占到50%以上。所以，我上任之后，为了尽可能收缩这方面的支出，做了不少努力。

企业盈利的关键在于垄断经营。打破垄断，则需要竞争对手。所以我引入了网宿，并督促他们做一个我相对满意的方案。这个方案就是“按带宽计费”。

经过我长期的「费米估算」，我总结出 流量 + 带宽 这一混合策略。 主要的流量放阿里云，用流量计费；国外和小流量的站点放网宿那边。

引入网宿之后，我们不再绝对地依赖阿里云，具备了随时伸缩的能力。之后，我再以此为筹码，在2020年这个财年里面，为公司阿里云账户的CDN产品申请了一个更高的折扣。

比较有缘的是，对接的阿里云商务经理以前在蓝汛上班。而我们以前用蓝汛CDN的时候，对接的也是她。我们算是久别重逢。

自动化运维程序

CDN 费用的本质是网络流量费用。

在阿里云内部，我追加了一个按带宽计费的共享带宽池。并用 common-bandwidth-auto-switch 这个我自己写的项目，动态规划共享带宽池里面的EIP列表，坚决不让阿里云多挣我司一分钱！！！

对于图片源站，我做了一个 nginx-brotli实验，把图片用 brotli 编码，进以压缩费用。

最后，我总结出 《多公有云CDN最佳实践》 ，偶尔 用「超装逼」排查CDN流量剧增问题。

大概在很早时候，我就隐约觉得“技术为业务价值服务”，所以我做的项目基本上能算清商业价值。 而之前的怠工，主要是觉得做的那些项目不是很挣钱吧。

云原生时代的网络诊断

进入云原生时代，排查网络问题变得更加复杂。 具体的可以看

  1. kubernetes的timeout问题
  2. 理解kubernetes的service流量转发链路

kt-connect 这个项目也不错。 如果喜欢原生态，建议直接用 tcpdump 🤣 。

结论

挖掘机是CDN最大的敌人。

参考链接

[1] Proxy-coonection和connection的使用，如何管理跨代理服务器的长短连接？ https://my.oschina.net/u/4266687/blog/3514919

[2] DNS基本概念 https://dudns.baidu.com/support/knowledge/Theory/

[3] HTML渲染过程详解 https://www.cnblogs.com/dojo-lzz/p/3983335.html

[4] CDN缓存那些事 https://bbs.qcloud.com/forum.php?mod=viewthread&tid=3775

[5] 使用ping命令丢包或不通时的链路测试方法 https://help.aliyun.com/knowledge_detail/40573.html

[6] 多维度分析CDN https://zhuanlan.zhihu.com/p/142787755

In March 2018, I officially took over all digital assets of the Amoeba Group company one by one, becoming the de facto operations manager.

Because the leadership valued me (the boss was reluctant to spend money), for a long time, I was the only one responsible for everything.

Especially in the CDN field, because it involves legacy projects, domain name resolution, TTL, and stupid domestic internet operators (like Great Wall Broadband), this work content needs to be handled more carefully.

Let’s go back to the root question: why do we need CDN, and what problem does CDN actually solve?

Why Do We Need CDN

image

To answer this question, we need to think about it from a macro historical perspective.

In ancient web requests, if going through A resolution, the request chain is basically as follows:

1

computer --> local DNS  --> server IP

After obtaining the server IP, the electronic terminal (computer, phone, iPad) establishes a TCP connection with the server, and finally the browser renders.

But there’s a problem here: server IP is only one, while computer is usually many. If there are too many users (computers), network congestion will occur. This is like going to a restaurant to eat, but the boss is stingy, there’s only one waiter. As customers increase, the waiter gets busier and busier, and eventually can’t take care of you at all.

So, how to solve this problem?

image

The answer is, of course, to throw money at it! Since you think there are too few waiters and the service isn’t good enough, then spend more money to go to a maid cafe, so the girls can legally surround you.

CDN is a similar mechanism—by continuously investing in girls (CDN edge acceleration nodes), better serving people who want to eat (use the internet to drive).

Using CDN

Later, when we left the ancient web era and came to modern times. With users growing exponentially, we needed a new architecture to adapt to changes.

Software design has always had a pattern: if one layer isn’t enough, add another layer.

image

So, in modern times, web backend architecture is usually a layered pastry:

1

$host --> cname --> CDN --> SLB ip --> server1,server2,server3,...

And the user access chain is:

1

computer --> local DNS  --> CDN

CDN’s essence is buffering and caching of static data.

CDN Problem Diagnosis

Around 2015, I was doing part-time technical support for the company. I often helped customers troubleshoot technical issues on QQ (pulling network cables), gradually accumulating some network diagnosis (bragging) experience.

If we break down the entire “modern” web backend request chain, we’ll find that data flow at each layer can cause problems.

Computer Problems

Mainly garbage configuration and garbage broadband issues. For garbage broadband problems, I generally recommend users to complain to operators at the Ministry of Industry and Information Technology Telecom User Complaint Center.

Local DNS Problems

local DNS is also called local DNS. If not specifically set, it goes through the router, and the router goes through the operator. If you encounter an operator with no bottom line, it’s possible that the website you entered is correct, but you still can’t access the internet.

The reason for this problem is that DNS service itself is a web service provider. If I change the DNS IP here, but the operator deliberately resolves incorrectly (DNS pollution) or the DNS can’t keep up (still caching old records after TTL expires), the entire resolution will have problems.

So later, I wrote a document and had operations add it to our company’s help documentation—mainly just setting local DNS to avoid the operator’s weak DNS problem.

image

CDN Problems

CDN problems appear more hidden, and usually CDN operators will pass the buck. So at this time, you need to collect user data in detail, then go back and greet the CDNparents.

Assuming the problem is with stu.17zwd.com. I would have users visit https://ipip.net and take a screenshot. Then according to different systems, enter different commands.

  • [Windows clients]
1
2
3
4

set host=stu.17zwd.com
ipconfig -all
ping %host%
tracert %host%
  • [Mac clients]
1
2
3
4

export host=stu.17zwd.com
nslookup $host
ping $host
traceroute $host

Then report upstream.

*.w.alikunlun.com is usually Alibaba Cloud, *.wswebpic.com is basically Wangsu.

Authoritative DNS Problems

image

This problem appears very rarely. I’ve only encountered it once. That time was when the server was accessing a domain name that couldn’t be filed in China. After contacting Alibaba Cloud after-sales, we found that the server’s IP was restricted from accessing authoritative DNS.

Because authoritative DNS is essentially also a web service, it can actively reject illegal connections.

Fighting for Bargaining Power

Public clouds’ profit model essentially relies on traffic fees brought by network effects. As server scale increases, we’ll find that bandwidth costs gradually rise.

After my rough calculation, after averaging, costs account for more than 50%. So, after I took office, to minimize spending in this area, I made a lot of efforts.

The key to enterprise profit lies in monopoly operations. To break monopolies, you need competitors. So I introduced Wangsu and urged them to make a plan I was relatively satisfied with. This plan is “billing by bandwidth”.

After my long-term “Fermi estimation”, I summarized the hybrid strategy of traffic + bandwidth. Main traffic goes to Alibaba Cloud, using traffic billing; foreign and small traffic sites go to Wangsu.

After introducing Wangsu, we no longer absolutely depend on Alibaba Cloud and have the ability to scale at any time. After that, I used this as leverage to apply for a higher discount for the company’s Alibaba Cloud account CDN product in the 2020 fiscal year.

Quite coincidentally, the Alibaba Cloud business manager I was working with used to work at ChinaCache. And when we used ChinaCache CDN before, we were also working with her. We were reunited after a long separation.

Automated Operations Programs

The essence of CDN costs is network traffic costs.

Within Alibaba Cloud, I added a shared bandwidth pool billed by bandwidth. And used common-bandwidth-auto-switch, a project I wrote myself, to dynamically plan the EIP list in the shared bandwidth pool, absolutely not letting Alibaba Cloud make one more cent from our company!!!

For image origin servers, I did an nginx-brotli experiment, encoding images with brotli to compress costs.

Finally, I summarized “Multi-Public Cloud CDN Best Practices”, occasionally using “super pretentious” methods to troubleshoot CDN traffic surge problems.

Very early on, I vaguely felt that “technology serves business value”, so the projects I did could basically calculate commercial value. The previous slacking off was mainly because I felt those projects weren’t very profitable.

Network Diagnosis in the Cloud Native Era

Entering the cloud native era, troubleshooting network problems has become more complex. Specifically, you can see:

  1. kubernetes timeout problems
  2. Understanding kubernetes service traffic forwarding chain

kt-connect is also a good project. If you like native tools, I recommend using tcpdump directly 🤣.

Conclusion

Excavators are CDN’s biggest enemy.

References

[1] Use of Proxy-connection and connection, how to manage long and short connections across proxy servers? https://my.oschina.net/u/4266687/blog/3514919

[2] DNS Basic Concepts https://dudns.baidu.com/support/knowledge/Theory/

[3] HTML Rendering Process Explained https://www.cnblogs.com/dojo-lzz/p/3983335.html

[4] CDN Caching Matters https://bbs.qcloud.com/forum.php?mod=viewthread&tid=3775

[5] Link Testing Methods When Using ping Command Packet Loss or No Connection https://help.aliyun.com/knowledge_detail/40573.html

[6] Multi-dimensional CDN Analysis https://zhuanlan.zhihu.com/p/142787755

В марте 2018 года я официально по очереди взял на себя все цифровые активы компании Amoeba Group, став фактическим менеджером по эксплуатации.

Поскольку руководство ценило меня (босс не хотел тратить деньги), долгое время я один отвечал за всё.

Особенно в области CDN, поскольку это касается унаследованных проектов, разрешения доменных имён, TTL и тупых внутренних интернет-операторов (например, Great Wall Broadband), эта работа требует более осторожного подхода.

Давайте вернёмся к корневому вопросу: зачем нужен CDN, какую проблему CDN на самом деле решает?

Зачем нужен CDN

image

Чтобы ответить на этот вопрос, нужно подумать о нём с макроисторической точки зрения.

В древних веб-запросах, если идти через разрешение A, цепочка запросов в основном следующая:

1

computer --> local DNS  --> server IP

После получения IP-адреса сервера электронный терминал (компьютер, телефон, iPad) устанавливает TCP-соединение с сервером, и наконец браузер рендерит.

Но здесь есть проблема: server IP только один, а computer обычно много. Если пользователей (компьютеров) слишком много, возникнет перегрузка сети. Это как пойти в ресторан поесть, но босс скупой, официант только один. По мере увеличения клиентов официант становится всё занятее и занятее, и в конце концов вообще не может позаботиться о вас.

Итак, как решить эту проблему?

image

Ответ, конечно, в том, чтобы вложить деньги! Раз вы думаете, что официантов слишком мало и обслуживание недостаточно хорошее, тогда потратьте больше денег, чтобы пойти в кафе с горничными, чтобы девушки могли законно окружить вас.

CDN — это похожий механизм — путём постоянных инвестиций в девушек (CDN-узлы ускорения на краю), лучше обслуживая людей, которые хотят поесть (использовать интернет для вождения).

Использование CDN

Позже, когда мы покинули древнюю веб-эру и пришли в современность. С экспоненциальным ростом пользователей нам понадобилась новая архитектура, чтобы адаптироваться к изменениям.

Проектирование программного обеспечения всегда имело паттерн: если одного слоя недостаточно, добавьте ещё один слой.

image

Итак, в современности веб-бэкенд архитектура обычно представляет собой слоёный пирог:

1

$host --> cname --> CDN --> SLB ip --> server1,server2,server3,...

А цепочка доступа пользователя:

1

computer --> local DNS  --> CDN

Суть CDN — это буферизация и кэширование статических данных.

Диагностика проблем CDN

Примерно в 2015 году я подрабатывал технической поддержкой компании. Я часто помогал клиентам устранять технические проблемы в QQ (тянул сетевые кабели), постепенно накапливая опыт диагностики сети (хвастовства).

Если мы разберём всю цепочку запросов веб-бэкенда “современности”, мы обнаружим, что поток данных на каждом уровне может вызывать проблемы.

Проблемы компьютера

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

Проблемы локального DNS

local DNS также называется локальным DNS. Если не установлено специально, он идёт через маршрутизатор, а маршрутизатор — через оператора. Если вы столкнётесь с оператором без принципов, возможно, что введённый вами веб-сайт правильный, но вы всё равно не можете получить доступ в интернет.

Причина этой проблемы в том, что сама служба DNS является поставщиком веб-услуг. Если я изменю IP DNS здесь, но оператор намеренно разрешает неправильно (загрязнение DNS) или DNS не успевает (всё ещё кэширует старые записи после истечения TTL), вся резолюция будет иметь проблемы.

Поэтому позже я написал документ и попросил операций добавить его в документацию помощи нашей компании — в основном просто установка local DNS, чтобы избежать проблемы слабого DNS оператора.

image

Проблемы CDN

Проблемы CDN появляются более скрыто, и обычно операторы CDN перекладывают вину. Поэтому в это время нужно подробно собрать пользовательские данные, а затем вернуться и поздороваться с CDNродителями.

Предполагая, что проблема с stu.17zwd.com. Я бы попросил пользователей посетить https://ipip.net и сделать снимок экрана. Затем в соответствии с разными системами ввести разные команды.

  • [Клиенты Windows]
1
2
3
4

set host=stu.17zwd.com
ipconfig -all
ping %host%
tracert %host%
  • [Клиенты Mac]
1
2
3
4

export host=stu.17zwd.com
nslookup $host
ping $host
traceroute $host

Затем сообщить вышестоящим.

*.w.alikunlun.com обычно Alibaba Cloud, *.wswebpic.com в основном Wangsu.

Проблемы авторитетного DNS

image

Эта проблема появляется очень редко. Я столкнулся с ней только один раз. В тот раз это произошло, когда сервер обращался к доменному имени, которое не может быть зарегистрировано в Китае. После связи с послепродажным обслуживанием Alibaba Cloud мы обнаружили, что IP-адрес сервера был ограничен в доступе к авторитетному DNS.

Поскольку авторитетный DNS по сути также является веб-службой, он может активно отклонять незаконные соединения.

Борьба за право торговаться

Модель прибыли публичных облаков по сути зависит от платы за трафик, приносимой сетевыми эффектами. По мере увеличения масштаба серверов мы обнаружим, что затраты на пропускную способность постепенно растут.

После моих грубых расчётов, после усреднения, затраты составляют более 50%. Поэтому после вступления в должность, чтобы максимально сократить расходы в этой области, я приложил много усилий.

Ключ к прибыли предприятия заключается в монопольных операциях. Чтобы сломать монополии, нужны конкуренты. Поэтому я ввёл Wangsu и побудил их составить план, которым я был относительно доволен. Этот план — “расчёт по пропускной способности”.

После моей долгосрочной “оценки Ферми” я обобщил гибридную стратегию трафик + пропускная способность. Основной трафик идёт в Alibaba Cloud, используя расчёт по трафику; зарубежные и малотрафиковые сайты идут в Wangsu.

После введения Wangsu мы больше не абсолютно зависим от Alibaba Cloud и имеем возможность масштабироваться в любое время. После этого я использовал это как рычаг, чтобы подать заявку на более высокую скидку для продукта CDN учётной записи Alibaba Cloud компании в 2020 финансовом году.

Довольно совпадение, что менеджер по бизнесу Alibaba Cloud, с которым я работал, раньше работал в ChinaCache. И когда мы использовали CDN ChinaCache раньше, мы также работали с ней. Мы воссоединились после долгой разлуки.

Программы автоматизированной эксплуатации

Суть затрат на CDN — это затраты на сетевой трафик.

В Alibaba Cloud я добавил общий пул пропускной способности с расчётом по пропускной способности. И использовал common-bandwidth-auto-switch, проект, который я написал сам, чтобы динамически планировать список EIP в общем пуле пропускной способности, абсолютно не позволяя Alibaba Cloud заработать ни цента больше от нашей компании!!!

Для серверов-источников изображений я провёл эксперимент nginx-brotli, кодируя изображения с помощью brotli для сжатия затрат.

Наконец, я обобщил “Лучшие практики CDN для нескольких публичных облаков”, время от времени используя “супер претенциозные” методы для устранения неполадок с резким увеличением трафика CDN.

Очень рано я смутно почувствовал, что “технология служит бизнес-ценности”, поэтому проекты, которые я делал, могли в основном рассчитать коммерческую ценность. Предыдущее безделье было в основном потому, что я чувствовал, что те проекты не очень прибыльны.

Диагностика сети в эру облачных вычислений

Входя в эру облачных вычислений, устранение неполадок с сетью стало более сложным. Конкретно, вы можете посмотреть:

  1. Проблемы таймаута kubernetes
  2. Понимание цепочки пересылки трафика сервиса kubernetes

kt-connect также является хорошим проектом. Если вам нравятся нативные инструменты, я рекомендую использовать tcpdump напрямую 🤣.

Заключение

Экскаваторы — самый большой враг CDN.

Ссылки

[1] Использование Proxy-connection и connection, как управлять длинными и короткими соединениями через прокси-серверы? https://my.oschina.net/u/4266687/blog/3514919

[2] Основные концепции DNS https://dudns.baidu.com/support/knowledge/Theory/

[3] Подробное объяснение процесса рендеринга HTML https://www.cnblogs.com/dojo-lzz/p/3983335.html

[4] Вопросы кэширования CDN https://bbs.qcloud.com/forum.php?mod=viewthread&tid=3775

[5] Методы тестирования ссылок при потере пакетов или отсутствии соединения при использовании команды ping https://help.aliyun.com/knowledge_detail/40573.html

[6] Многомерный анализ CDN https://zhuanlan.zhihu.com/p/142787755

💬 讨论 / Discussion

对这篇文章有想法？欢迎在 GitHub 上发起讨论。
Have thoughts on this post? Start a discussion on GitHub.

在 GitHub 参与讨论 / Discuss on GitHub
CATALOG
你已经读了 0%
    FEATURED TAGS
    C# Kubernetes Java P n DevOps go code give up time cloud native Elasticsearch AI Devops GitHub Linux mysql
    FRIENDS