云兴维智科技 王亚雷-Twitter 千万 QPS 分布式系统的架构设计和高效运维

2020-02-27 59浏览

  • 1.GOPS 全球运维大会2017·北京站
  • 2.千万QPS分布式系统架构设计和高效运维 王亚雷 CEO， 云兴维智科技 前Twitter技术主管 GOPS 全球运维大会2017·北京站
  • 3.目录 1 设计大规模、高性能数据系统的点点滴滴 2 半夜pager叫：高效运维大系统实战 3 挑战和机会：精准、智能和自动运维的道路 GOPS 全球运维大会2017·北京站
  • 4.CAP和行行色色的数据库 1. 关系型（RMDBS） • 强一致性（Strong Consistency，Transactional） • 交易类 • CP 2. NoSql • 最终一致性（Evental Consistency） • High Throughput • AP GOPS 全球运维大会2017·北京站 Eric Brewer
  • 5.CAP和行行色色的数据库 3. NewSQL 4. 特殊用途 • 时序型 • 文档型（mongoDB) • Graph DB (Neo4j) GOPS 全球运维大会2017·北京站
  • 6.Manhattan – 历史和Focus Twitter 自主研发的Key-Value No-Sql分布式实时海量数据库 • 最终一致性（Eventual Consistency) • 3万＋节点 • 上万QPS／节点 • P99延时10ms 1. Cassandra at Early Time • 缺乏 vNode：扩容困难 • GossipProtocol:Inconsistency at scale, 难管理 GOPS 全球运维大会2017·北京站
  • 7.Manhattan – 历史和Focus 2. Manhattan Focus • 可靠（reliability): Known Failure Mode • 可用性（Availability）: Prefer AP over CP • 可操作性（Operability) • 低延时（Low Latency) • 高效 (Developer Productivity) GOPS 全球运维大会2017·北京站
  • 8.Manhattan 存储引擎 One Size Fit All – No!!! •SeaDB:只读，批量更新（batch update） •SSTable:LSM tree, append-only, optimized for write •BTree:RMDBS engine, optimized for read • 专门用途: • 强一致性（Strong Consistency） • Time Serial Counter Service • Secondary Index GOPS 全球运维大会2017·北京站
  • 9.目录 1 设计大规模、高性能数据系统的点点滴滴 2 半夜pager叫：高效运维大系统实战 3 挑战和机会：精准、智能和自动运维的道路 GOPS 全球运维大会2017·北京站
  • 10.原则和目标 工具 ＋ 流程 ＋ 组织架构 GOPS 全球运维大会2017·北京站
  • 11.自助服务 － Self Service 降低管理、沟通成本和时间 • 存储类型: 读写, 只读, 强一致性 … • 容量规划（Capacity Planning): 并发（Throughput）, 存储空间 • 管理: Owner/DRI, 联系方式，是否需要设计指导 • 调试工具（Debug Console） GOPS 全球运维大会2017·北京站
  • 12.部署 1. 研发／测试环境, staging环境, 生产环境 2. Canary：随机挑选节点，一定限制条件（两个节点不能在同一 个replication set) 3. 回滚能力: 数据格式的向后兼容性 => two stage 部署 4. 模式: state driven pull vs push 5. 无明显的性能和可用性影响：重启机器的batch size GOPS 全球运维大会2017·北京站
  • 13.Topology Transition 1. Whatfor:扩容, 移除故障节点 2. 要求: 在线，无明显的性能和可用性影响 3. 方法: 状态机驱动 • 老方法: time consuming, all or none • 新方法：stateful sharding, an incremental, progressive topology migration GOPS 全球运维大会2017·北京站
  • 14.数据复制和负载均衡 1. Mirrorset • RDF = RF • 设计和管理简单 • 永久性的数据丢失的几率低 • 单个数据节点损坏后数据恢复慢, Network Bound instead of IO Bound 2. Pod Balancer • RDF > RF • 单个数据节点损坏后数据恢复快 • 设计和管理简单复杂 • 永久性的数据丢失的几率稍高 GOPS 全球运维大会2017·北京站
  • 15.Hot Shard and Detection • 原因：不合理的Pk选择、计划外的traffic等 • 后果：Tail Latency 增加，违反了SLA，大量的Pager • 应对： • Hot Shard Detection 脚本，发现有问题的Key和应用 • Work with Owning Team, 优化PK的设计 • 对读操作，Owning Team 考虑使用cache • 所有traffic 都必须经过self-service 和capacity 审批 GOPS 全球运维大会2017·北京站
  • 16.DevOps 和运维驱动的研发 1. 研发参与运维, 2. 运维人员研发工具 3. On-call 上岗流程: • 培训 • Shadow Others • Shadow by Others • 独立上岗 GOPS 全球运维大会2017·北京站
  • 17.DevOps 和运维驱动的研发 4. 项目研发交付流程 • 运维早期参与研发设计（会议、签收／signoff) • 研发必要的WorkItems:运维指标，告警 • 我真想在半夜把我或者我的同事叫醒吗？ • 叫醒后他知道怎么做吗？ • 操作手册（Oncall Book) • 预上线（preproduction）会议和签收（signoff) •Babysitting:项目研发团队运维一个月 • 培训和交割（Training and Handover) GOPS 全球运维大会2017·北京站
  • 18.目录 1 设计大规模、高性能数据系统的点点滴滴 2 半夜pager叫：高效运维大系统实战 3 挑战和机会：精准、智能和自动运维的道路 GOPS 全球运维大会2017·北京站
  • 19.智能发现问题 • 分析数据的时 域频域，找出 历史规律，自 动发现异常。 全面覆盖所有 数据，无需设 定固定阈值 实时分析诊断 • 对报警及异常事件，主动利用模式识别 找出关联指标和事件，快速定位问题 • 整合日志分析进行诊断。日志聚类，对 比和规律挖掘，突出有问题的日志 • 提供专业运维知识库。自反馈学习进行 故障根源定位 长期分析诊断 • 预测分析所有指标。比如预测容量 消耗趋势，规划资源，提供采购计 划 • 指标聚类分析，帮助运维人员熟悉 系统特性。 专家解决方案 • 故障排除方案推荐 专家报告 • 提供专家报告，优 化系统、配置、架 构，提升性能 GOPS 全球运维大会2017·北京站
  • 20.异常自动发现预测 问题发现：业务文件上传出现堵塞 这个点比平时这个时刻的值高出很多， 表示这个时刻的文件上传数比平时高 这两个点比规律值低出很多，表示这个 时刻的文件上传数比平时低 GOPS 全球运维大会2017·北京站
  • 21.智能关联分析查找故障根源 服务器上CPU使用率被自动探测出有异常升高，如红点所示，cpu.usr在22：00 - 00：00和9：00左右25%，而平时一般在8%。需要找出原因。 GOPS 全球运维大会2017·北京站
  • 22.智能关联分析查找故障根源 Cloudwiz 系统自动查找和匹配出相关联的指标，提供故障根源推断 GOPS 全球运维大会2017·北京站
  • 23.智能关联分析查找故障根源 选择hbase.regionserver.server.writeRequestCount对比cpu.usr。两条曲线非常 吻合。说明cpu的升高是由于hbase的write数量增加引起的。客户马上意识 到最近一个修改导致写操作会增加。经过修改以后，cpu正常下来。 GOPS 全球运维大会2017·北京站
  • 24.智能关联分析查找故障根源 下面的报警显示了Ngnix机器的内存和IO 有时 飙升得很高。几乎是用尽了整个 机器的内存和IO。我们把这俩个指标关联在一起。如下图显示。我们发现这两 个事件总是一起发生的，而且是有规律地发生的，总是在北京时间凌晨1 点。 这说明它们是有关联的。可能是由同一个事件引起的 GOPS 全球运维大会2017·北京站
  • 25.智能关联分析查找故障根源 我们想发现具体是什么引起的IO。我们把每个时刻消耗内存最多的线程进行比 较。如下图所示。我们发现内存的飙升是由于某一个python 的线程引起的。不 同的时刻的python 线程都不一样，但是只是一个python 线程的内存消耗特别的 高。这写python 线程看起来像是临时起来的短线程。根据这个分析，运维人员 发现并迁移了影响性能，不应该放在Ngnix 上的定时任务 GOPS 全球运维大会2017·北京站
  • 26.日志整合分析、聚类、对比 GOPS 全球运维大会2017·北京站
  • 27.日志整合分析、聚类、对比 GOPS 全球运维大会2017·北京站
  • 28.资源容量规划 上图是可用磁盘空间的实时数据。下图是统计的趋势线。根据趋势，目前可用磁盘 空间49GB在62天后用完。用户可以及时安排应急方案和设备采购计划 GOPS 全球运维大会2017·北京站
  • 29.总体健康评判 根据报警及异常点的比例和权重计算 GOPS 全球运维大会2017·北京站
  • 30.智能管理 1. CMDB：自动发现 2. 变化管理：自动发现 3. 故障排除流程 4. 智能知识库 5. 专家报告 GOPS 全球运维大会2017·北京站
  • 31.会议 培训 咨询 • 8月18日 DevOpsDays 上海 • 全年 DevOps China 巡回沙龙 • 11月17日 DevOps金融上海 GOPS 全球运维大会2017·北京站 • EXIN DevOps Master 认证培训 • DevOps 企业内训 • DevOps 公开课 • 互联网运维培训 • 企业DevOps 实践咨询 • 企业运维咨询 商务经理：刘静女士 电话 / 微信：13021082989 邮箱：liujing@greatops.com