Pensieve: 2007

2020-07-20 19:11

所观所读所听

等build期间抽空重看了两个老电影, 一个是冯小刚的大腕, 一个是三个白痴. 重看大腕觉得当年的剧本真是英气逼人, 摄像也很棒. 不知道后面的冯小刚电影为什么每况愈下. 三个白痴仍算是类型片, 不太明白为什么那样火, 也就拿来当个不动脑子的电影看看可以.

看完了Harry Potter 3, 正在看第四本了. 第三本的结尾转折我极不喜欢, Snape明明已经看见Peter, 仍然执意要处死Sirius, 这个时候怎么就不想想要给Lily报仇了呢? 另外学校里大多数老师对Ministry的态度是Ministry能死多远就死多远, 不要干涉学校的事情就好, 凭什么Snape就是一个例外? 第四本一开头读到killer whale和rabbit food后就像遇到老朋友一样, 莞尔一笑. 进度不太快, 还等着读到Mad eye第一次上课时讲Avada Kedavra时的场景. 我第一本Harry Potter是5, 看的时候极恨Umbridge, 后来找来前几本补课, 读到四的Avada Kedavra的时候是第一次被镇住了, 看来我果然是个drama queen.

这个月在朋友圈看到同学家长收集的当年中考我所在的高中录取名单, 看完后找来67373的一群歌, 做成aac后放进了Apple Music. 另外, 还加了Aysedeniz Gokcin的一张专辑.

所玩

上个月在玩的Homescapes被我删除了. 实话实话, 有点创意, 不过策划有点太坑人. 作为一个有点编程能力的人, 我愿意去玩那些我如果写出来愿意卖给其他人玩的游戏, 这个游戏不太满足这个条件.

这个月主要在玩暗黑三, 这赛季自然是赛季之子猎魔人. 运气不佳, 护符/主武器/箭袋一直没刷到好用的, 本来想刷到大秘境120层后收工, 但是想想, 120又如何, 现在的117又如何, 都是虚妄, 就放下了.

集中存储WAF和Cloudfront日志

我们现在有不少AWS账号, 各个账号有自己的服务在跑, 现在我们希望把所有WAF的日志和Cloudfront的日志都归集到一个账号里面去, 方便做审计之用, 怎么做更合理?

WAF的日志只能写到Kinesis Firehose, Firehose也支持跨账号保存, 但是不太好用的地方在于跨账号保存时不能写ACL, 所以默认所有者仍是源账号, 这对于后期的处理是很不方便的, 我们可以有几个办法来解决这个问题:

  1. Firehose支持用一个lambda来转格式, 我们可以在这个lambda里面把这一条日志写到Cloudwatch, 后面就比较方便搞了. 缺点是这算是一个明显的abuse, 而且lambda被调用的次数会比较多, 费用是一个问题.
  2. 审计账户里面写一个lambda, 每次有s3写入的时候调用然后覆盖acl, 或者定时调用函数来改acl, 缺点是审计账户不应该运行逻辑.
  3. 设置Firehose写到源账户里面的一个S3, 这个S3设置当有写入的时候将新文件复制到审计账户的对应S3里面去, 我们后来选的是这个方案, 好处在于架构比较清晰明确, 缺点是额外存了一份S3, 不过这年头存储不贵, 而且源账户有一份在很多时候还方便查询.

和AWS的同学讨论过以后, 我们做了一点点优化, 在审计账户的S3 bucket policy里面我们做了隔断. 每个源账户只能在自己的目录下去写内容, 没有权限写其他账户的目录, 这样我们可以把多个源账号的WAF日志全部存放到一个S3里面去, 方便后续处理.

Cloudfront的日志更纠结一点. 如果从源账户直接开权限写到审计账户里面去, 那么我们不好做隔断, 也不太放心权限. 所以我们借用了在WAF日志中的做法, 设置Cloudfront写到同账户的一个S3里面去, 这个S3设置好新文件上传后触发复制到审计账户里面去.

不过话说这也算是比较大路化的需求, AWS也没有比较良好的开箱即用的解决方案, 让人觉得有点不太满意.

AWS小坑

这个月又踩了一个AWS的小坑. 回想起来, 这个问题之前遇到过, 不过这次是作为第一处理人直接面对这个问题. 我们要对一个应用跑自动压力测试, 这个在AWS里实现起来不难, 我们之前一直是用一些种子数据来跑, 数据库不大, 没出什么问题, 后面我们发现有些代码在数据量比较大的时候会有严重性能问题, 为此, 我们把生产环境中的数据库脱敏后复制了一份到dev环境中, 每次要跑压力测试的时候从头搭一个环境出来, 数据库从快照中恢复.

问题是, 刚从快照中恢复过来的RDS速度极慢, 因为实际上绝大部分数据都还在EBS里面, 所以RDS要先去EBS同步数据后才能正常工作. 对于快照比较小的场景, 这个时间比较短, 没大问题. 但是我们来自生产环境的快照有一百多G, 所以这个过程就需要45分钟左右了. 于是乎, 我们每次的build都需要等这45分钟的数据传输, 而大部分时间我们的压力测试只需要20分钟左右, 之后这个数据库就被删除了.

这个问题比较难解, 我所能想到的办法有:

  1. 跑一个小的RDS实例, 保证里面的数据是热的. 每次部署RDS的时候, 不是从新部署而是给这个实例加一个replica, 同步完数据后把这个replica升级成一个正常rw节点, 提供服务. 问题是不知道这个过程要多长时间.
  2. 跑一个小的RDS实例, 保证里面的数据是热的. 每次部署RDS的时候, 做一个point-in-time恢复, 选择copy-on-write作为恢复方式, 希望这样能够快点.
  3. 除此之外, 可以测试一下停掉这个小的RDS实例, 看看数据会不会变冷.

顺便说下, 这个问题尚未解决. 上面的这几个方案还有待测试.