这篇比较偏心得分享，没有太多的技术细节。 Medium好读版: https://tinyurl.com/yy8auqdy PressPlay好读版: https://www.pressplay.cc/link/82A2CAD5C4?oid=829D3F275F PressPlay平台服务在2016年问世，一直放在AWS上，直到2018年中才搬迁至GCP上。 至今也一年了，让我们回顾一下这几年PressPlay的主机的成长过程吧。 # AWS时期 PressPlay草创初期资源有限人力有限，只有一台伺服器运行所有的服务，一台资料库， 主机在东京AWS，CDN是用Cloudflare的CDN，服务也挺单纯的，伺服器上只有网站服务， 然後用户上传图片也放在这台主机上，里还有一个跑定期扣款的Cron服务， S3的用途是暂时放上传的影片，为什麽是暂时呢？因为我们的影片是使用Vimeo服务， 所以我们上传到S3只有一个功用，就是让Vimeo可以抓影片，过了三天影片就会被删掉。 配置图大概是长这样子： 最早期的AWS主机配置: https://tinyurl.com/yyfmglex 那时候每天大概几千人造访而已，机器都应付得来。 然後到了2017年3月情况就开始不一样了。囧星人专案上线带来一波流量， 然後我们在3月下旬作了第一次的改版，流量开始多起来了， 高峰期甚至到了一天两万多人进站。 2017–01–2017–03 GA数据: https://tinyurl.com/y6jnd5ym 我们在2018–01到2018–06搬家之前，平均每天进站人数大约在25,000至30,000人左右， 一台Server还蛮紧蹦的，最後决定搬家，搬到Google Cloud Platform(GCP)。 这是搬家前最终的伺服器配置。 AWS後期的主机配置: https://tinyurl.com/yx9tl8yl # 为什麽要搬到GCP 或许有人会问「AWS用得好端端的干嘛搬家呢？」我们选择GCP的原因有几个原因： * 价格比AWS便宜 * 地点在台湾，速度快 * AWS介面很丑（我承认我是外貌协会） 公司草创时期资金没有那麽多，选择机器都是以省钱、高C/P值为目标。 PP的机器建在AWS的时候，CDN是Cloudflare，虽然我们买的是Pro方案(USD 20/月) 但连线的节点是在洛杉机。也就是说用户要连线PressPlay的网站， 用户的连线会先台湾出发，到达洛杉机Cloudflare的机房， 然後连线到东京AWS机房取资料，然後再经过洛杉机才回到台湾。 开个网站就要跑遍大半个地球，再加上PressPlay一开始网站还没有优化连线数或 图片size，所以以一个从来没进入过PressPlay的人，从连线到完全跑出网站， 要90秒左右... GCP的费用大约是AWS的六折左右，而且在AWS都没有作HA(High Availability)， 就算有也是人品HA。因此我们常常一爆量主机摊痪了，光2018上半年就平均1–2月 就一起摊痪事件。GCP的设定简单，就连我对配置伺服器没有很熟都可以轻松入门， 开启CDN也是一个键就完成了，在人力和相关知识都缺乏的情况下，选择GCP还蛮不错的。 於是我们在2018年4月的时候，决定搬迁到GCP。 # 搬迁的困难 就是人！因为公司内部缺乏熟悉伺服器管理的人，於是我们就想找一个人来管理伺服器、 调整效能、管理办公室网路和设备，然後进公司来的第一件事就是协助我们搬伺服器。 我们找到一位从业很久的资深工程师，他一进来看到我们公司的网路架构、伺服器架构 跟本是初学者等级，来了五天就跑了，说是不想从那麽基础的东西做起。 那麽怎麽办呢？只好我硬上了。虽然GCP操作简单，但是有关Server调校、 资料库调校这些我没有什麽经验，而且这一次要大调架构，我的要求： * 让我们可以撑住爆量的时刻，机器不要挂。 * 并加速网站的运行速度。 * 伺服器状态的监控机制。 * 备援机制，不要伺服器倒一台就服务全死。 因为GCP比AWS便宜多了，所以机器比较能放心的开，为了未来PressPlay发展， 我们是以3年内不需要再次优化架构的前提之下去做规划，原本一台网站主机 就可以打天下的配置，扩充成APP、Web各两台，另外再把负责金流的服务独立出来， 也是做成两台，然後由Load Balancer来分配流量，就算APP死一台机器还有一台会 继续服务，就算WEB全死，但APP还是可以用。 还好有在6月有一位资深的後端工程师加入，我和他经过一整个月的试验、调整、搬迁， 上线前一天我召集了几位工程师一起协助搬资料和测试，老板还以来办公室拿东西为藉口 送宵夜来，揪甘心～ 终於在2018–06–29 正式上线了！！这是搬到GCP时的配置图： https://tinyurl.com/y6z53rxu # 搬到GCP之後…? 2018–06–29上线早上八点，网站就炸了!! 原因是主机挂载Google Storage时的参数错误，让所有资料夹和档案清单必须读完 才能正常服务，半夜搬家在测试时也是小猫两三只在测试所以没什麽问题， 早上八点的尖峰时间一到，大量的人潮涌入PressPlay，I/O卡住，导致服务停摆。 那两天我的睡眠时间只有三个小时，不过当一切都搞定且正常运行时，疲惫的感觉 全部冒出来了，於是我就伴随着成就感一起入睡。 换到GCP後，PressPlay有变得比较好吗？有的，当时我们还做个记录： 1. 台湾地区网页读取速度之影响 6/30日(六) 比较6/2(六) 网页读取 时间从3.9秒，提昇至2.78 (台湾地区) ，提昇28.58% https://tinyurl.com/y3lbuzbr 2. Ping值之影响从平均100ms提昇至10ms https://tinyurl.com/y6spu8z6 3. 完成网站浏览取样报告比较 6/29–6/30 对比上周 6/22–6/23 各式的载入、连线时间、回应时间都大大地的减少。 https://tinyurl.com/y5mnpfvx 搬完GCP後从此就高枕无忧了吗？错了，挑战开始来了。 2018–08–23攻击事件 当天晚上我们受到DDOS攻击，我们抓到大约200多个国外IP向我们进行攻击， 这些IP应该都是跳板。之後我们在两个小时之内，把主机关掉、换IP， 然後建置fail2ban和nginx的防DDOS机制止血，隔天我们进行了检讨， 我们需要更明确的自动监测回报机制。 被攻击的隔天PressPlay粉丝团所发的声明: https://tinyurl.com/y3wmyojk 於是我们就建置了监控主机的功能，只要CPU使用量超标，或是一段时间主机没有回应， 都会跳出通知 PressPlay内部监控Channel: https://tinyurl.com/yxtnnqaa 後续还有几次攻击事件，不过因为前一此的事件我们作了防护措施，所以只是跳跳通知， 然後隔天去看Log而已，用户、工程师和老板都睡了好觉。 2019–03–31阿滴英文愚人节活动爆冲 PressPlay的GA在2019年有个显着的peak，就是阿滴英文愚人节活动，在我们没有准备好 的情况之下，当天冲进快十万人，大约是平常日的4倍量。我记得当天我还在家里一面 吃咸酥鸡一面看动物朋友，然後就看到「救救PressPlay」频道一直叫，然後老板一直 在戳我，才发现这起事件。 还好架构有规划好，整个活动顺利的结束，Server没有爆炸，可喜可贺。 https://tinyurl.com/y52eekx2 因为这次的虚惊，所以我们就立刻进行一个我很想要玩的东西：Auto Scaling。 10天後，也就是4月9日，Auto Scaling正式上线。之後我们更能高枕无忧地渡过 每一个动画夜。 这个架构运行至今都没什麽问题，下面这个是目前PressPlay的主机架构。 现今PressPlay主机架构: https://tinyurl.com/y3nqcpdj # PressPlay功能现在与未来 PressPlay目前产品功能是着重在数据开发和应用，今年招募两位数据背景的RD， 开始着手进行订阅者的行为，为创作者带来新的收益和减少流失。 或许大家会注意到我们网站开始有推荐的版位了，首页的订阅专案排名也不是像以前 一样单纯用金额去排名，而是透过演算法算出综合性的指标。 我相信创作者们想知道算法是怎麽算的，在这边只能透露创作者越投入在经营专案、 订阅者的互动越深就能得到更好的排名。 目前我们也在密谋一个对创作者更有实质帮助的功能，预计在八月会问世， 还有秘密策划第三条产品线，也即将在九月和大家见面。 未来PressPlay工程部会持续地深化你所见到的一切，和我们在麦块中的世界。 最後，欢迎按赞追踪我们的FB粉专：https://www.facebook.com/PressPlayTech/ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.34.49.142 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1562948175.A.FB1.html ※ 编辑: UniFish (1.34.49.142 台湾), 07/13/2019 00:23:26 真的！很好设定。 我们有用stackdriver，我们的自动监控的通知是利用stackdriver去作的 logging server我们是用来收集nginx的accesslog，还有类mixpanel的服务 不客气 帮QQ 有点不太懂你的描述XD GCP load balancer是指定连线进到哪一个VM群组，我们有专门服务APP的机器 iOS/Android用户使用PressPlay APP会连到APP Server 就连里头的webview开网页也都是由APP Server服务，完全地和Web切开 你没看到文章封面的Logo吗？XDD 是我们部门的员工福利(?) GCP有一年300美金的试用金额，只要有Gmail都可以使用， 任何人都可以开来玩玩 现行Web & App Server是用2VCPU + 8G Ram + SSD 一台一个月大概40-50美金吧，同等级AWS要70-80美金 不过我有绑合约，一台合约价在30美金左右 我们没有使用Docker，我们走的是效能置上路线。 不过GCP的Auto scaling需要一个范本，才能用这个范本去增开机器。 所以我们会开一台范本的主机，然後把Web & APP服务建在上面，作成范本映像档，用它 来开机器。 这样的概念也和Docker很像呢，只是没有再包一层，这样费用也比较便宜，效能也比较好 等到未来PressPlay成长到这种架构维护成本大到比使用Docker大之後， 我们再考虑使用Docker 是的，GCP比较便宜，而且重点是在台湾。 我们的服务目前是以台湾为主，它在台湾这个优点就很吸引人了 有用ab打一下，不过最近在想clone一组架构来测试， 但还没有决定哪个时辰要来做 哈哈哈～我可以确定他不是菜鸟啦。 但在知道架构的前提之前答应了offer但又不想做，我也不知道究竟发生什麽事XD GCP也有喔，超级便宜，不过目前还没试过。 目前我们的web & app server突然被关掉重启也不会影响服务， 看来蛮适合的，找个良辰吉时来试试看好了 是的，所以我们S3有挑便宜的地区，我进公司前就是放在AWS东京了 要搬乾脆索性搬到台湾，为了速度 & $$ 真的，一生难有的机会 clodflare的proxy CDN是小型服务首选，而且CDN流量是吃到饱，而且防DDOS， 一个月20米金很佛！！哪家CDN可以如此的省钱啊！！ 估算下来我们用aws CDN，都会超过100米金。对於草创初期，都是能省则省。 当时GCP的Cloud Armor还在beta，怕怕的不敢用，fail2ban挡着先 是GCE喔，GAE贵贵，而且不想绑在不好转移的架构上。 万一哪天有更棒的服务商出现了，绑太死移不走 偷说，20米金的方案节点在LA，然後我以为商务方案(200米金)会可以用台湾节点 直到我写信去cloudflare问说台湾节点要用哪个方案。 他们回覆要用企业方案，一个月5,000米金！！夭寿啊！！！！ 哈哈哈，细节我记不太得了。 基本上是我们另外一个後端工程师处理的。 来唷（招手 Ya~网上众说纷云，我就直接写信给Cloudflare问个清楚， 答案的确让我倒抽口气。不过十万出头也很夭寿。 现在我们每月主机全部加一加支出连一半都不到啊 XD 我们公司加班费和补休都是照实报照时给～ 有时候工程师不好意思报太多还会被我退件说报太少。 伺服器搬家前天我们分成两组：搬家组和维护组。 搬家组不用来上班，当晚九点集合。办完後就早上五六点，然後回家睡觉，白天换维护组 接手。 搬家组就在家睡觉。因为我很讨厌操劳的生活，所以我自然地会要求组员们不能操劳，该 休就休，改报加班就报加班。 哈哈哈，这个也很重要，我也很感谢公司能不畏惧财务的压力，能让我们找正常且符合人 性的方式工作。 也因为我们有好好的休息，许多创意或是复杂的东西，我们都有足够精神来实现。 是啊 XD ※ 编辑: UniFish (59.127.82.251 台湾), 04/24/2020 14:20:19