美文网首页AWSDevOps系统运维专家
一场DNS引发的性能惨案

一场DNS引发的性能惨案

作者: iambowen | 来源:发表于2016-11-15 19:39 被阅读309次

最近在客户现场出差,见证了不少有趣的线上事故,下面要讲的就是其中之一。
一段时间以来,某个微服务在生产环境的response的延迟陡然增加了几百毫秒,而部署的代码并不是造成延迟原因。从Newrelic的监控可以发现,该API的延迟增大的主要原因是它依赖的一个服务响应时间增大了。

我们暂且把这个外部的服务称为service.mycompany.com,这个服务分别部署在澳洲和欧洲的两个数据中心,入口处是Akamai,做负载均衡,尽可能的按照访问来源去分发请求。

该微服务部署在AWS悉尼的数据中心,所以理论上来讲,当它请求service.mycompany.com时,Akamai应该返回的是位于悉尼的edge节点的IP,同时其访问的origin服务器也应该位于悉尼。但是通过在该微服务的服务器debug,发现ping值以及traceroute的值都比较高,办公室访问却都一切正常。当时怀疑是Akamai的GEOIP判断出了问题,把来自亚马逊悉尼的请求当成了来自美国的IP的请求,于是用部署于欧洲的数据中心的服务处理请求。和基础设施部门管理网络的人讨论,再次调查后结论类似。

问题出在这个AWS账户下的VPC的DHCP options的配置。因为是比较早期使用的share的AWS账户,所以下面的网络配置比较复杂,配置有Direct Connect 连往其他数据中心,以及很多VPC Peering。不知道因为什么原因,这个微服务部署的Cloudformation template里面选择了包含google DNS 8.8.8.88.8.8.4的DHCP Options。我们都知道对于在Akamai上注册的服务service.mycompany.com来说,如:

 ~> host service.mycompany.com
service.mycompany.com is an alias for mycompany.generic.edgekey.net.
mycompany.generic.edgekey.net is an alias for e8888.g.akamaiedge.net.
e8888.g.akamaiedge.net has address 104.116.190.24

第一次DNS请求返回的记录是CName,之后进一步返回Akamai动态DNS的CName,也就是edge server的CName,之后再根据DNS服务器返回对应的edge服务器的IP地址,如果查询的是Google的DNS,那么它会返回美国的edge服务器地址……。我们可以测试下:

 ~> dig @8.8.8.8 service.mycompany.com

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 service.mycompany.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44304
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;service.mycompany.com. IN  A

;; ANSWER SECTION:
service.mycompany.com. 86399 IN CNAME   mycompany.generic.edgekey.net.
mycompany.generic.edgekey.net. 263  IN  CNAME   e8888.g.akamaiedge.net.
e8888.g.akamaiedge.net. 19  IN  A   23.53.156.156

;; Query time: 603 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Nov 15 22:15:52 2016
;; MSG SIZE  rcvd: 130

查询下IP地址信息,

 ~> whois 23.53.156.156 | grep Country
Country:        US

所以,这个微服务的请求先到Akamai美国的edge服务器,之后很有可能请求被发送到了欧洲的origin服务器,这个延迟不增加才👻了……。

解决的办法很简单,更新配置,DHCP Options选择Amazon提供的DNS就可以了,响应时间就降下去了。

这个事情给我们的教训就是,不管怎么样都不能崇洋媚外,虽然澳洲一直follow美国,但是DNS还是得用自己的。

相关文章

  • 一场DNS引发的性能惨案

    最近在客户现场出差,见证了不少有趣的线上事故,下面要讲的就是其中之一。一段时间以来,某个微服务在生产环境的resp...

  • 一次dns缓存引发的惨案

    时间2015年的某个周六凌晨5点,公司官方的QQ群有用户反馈官网打不开了,但有的用户反馈可以打开,客服爬起来自己用...

  • 2017-10-17

    这是一场因无能和愚蠢引发的惨案,为了不让这个惨案再次发生,我寒假一定要闭关修炼。不能再让这个使我变得如此愚蠢

  • 复盘:俄罗斯世界杯引发的系列惨案(三)

    复盘:俄罗斯世界杯引发的系列惨案(三) 作者:财深道长 一、格子军团:一场依靠轮盘赌上位、终又被镇压的篡权惨案 来...

  • 惨!因为朋友圈的信息他丢了工作,我们该如何避免这样的职场惨剧

    01 因为社交媒体引发的“职场惨案” 这段时间,社交媒体俨然成了引发“职场惨案”的高危地带,不断有人因为在微博或朋...

  • 一辆东方罗密欧引发的惨案

    一辆东方罗密欧引发的惨案 一辆东方罗密欧引发的惨案ufo大大雄 2017.1.21 这是一个很有趣的故事,也算是一...

  • 一场由外卖引发的惨案

    1 我是在一座山里见到她的,第一次。 那是一座熊猫森林公园,里边只有一只无论什么时候过去都在背对着游客睡觉的熊猫,...

  • 一场由情书引发的“惨案”

    文|慕伊 01 前一段时间,日本一所学校的屋顶告白视频在微博上火的一塌糊涂,被各路人马疯狂转载。 那些可爱的未成年...

  • 流浪猫引发的一场“惨案”

    文/李一漠 01 想跟大家讲一件真实地发生在我身边的事情。 事情发生在上周。 我所在的办公室在整栋公司大楼的一楼,...

  • 一场知网引发的惨案

    转载侵删 一句“不知道知网是什么”引发的惨案……→被扒到皮都不剩!数学19分的翟天临,别再舔着脸说自己是博士了呵 ...

网友评论

    本文标题:一场DNS引发的性能惨案

    本文链接:https://www.haomeiwen.com/subject/bhjlpttx.html