Cloud Composer是否为多区域架构？元数据库灾备设计疑问

Cloud Composer 2的这种架构是在成本、性能、可用性之间做的务实平衡，具体原因可以拆成这几点：

• 省成本，资源不浪费
  跨区域复制数据库（比如Cloud SQL跨区域实例）的开销比单可用区高太多，包括额外的存储冗余费、跨区域数据传输成本，还有备用实例的资源费用。对大部分不需要跨区域灾备的用户来说，可用区级元数据库完全能满足日常需求，没必要平白多掏钱。

• 更快的交互速度
  Airflow的调度器、工作节点这些核心组件跑在区域内的多个可用区里，元数据库放在其中一个可用区，同区域跨可用区的网络延迟基本都是毫秒级，比跨区域访问数据库快得多。这样不管是任务调度、Web UI加载，还是节点拉取元数据，速度都能上去，不会拖慢Airflow的运行效率。

• 给用户留足选择空间
  区域性执行层已经保证了Airflow核心组件的跨可用区高可用——哪怕某个可用区挂了，执行层能自动切到区域内其他可用区继续干活。而元数据库用可用区级部署，不是强制用户用跨区域复制，要是真有跨区域灾备需求，用户可以自己配Cloud SQL的跨区域复制，或者用Composer的灾备方案搭跨区域环境，不想花这个钱的话就用默认配置，灵活度很高。

• 适配Airflow元数据的特性
  Airflow元数据库存的是任务状态、调度日志、DAG配置这些数据，比起“跨区域随时能用”，它更需要“数据一致”。单可用区部署加上Cloud SQL默认的自动备份（备份存在区域级存储里），应付大部分故障场景完全够——就算元数据库所在的可用区挂了，用备份就能快速恢复到同区域的其他可用区，而且执行层的区域性架构在恢复期间还能保持基本运行，只是部分依赖元数据的操作会受影响，整体不会完全瘫掉。

多说一句：你提到的灾备失效场景，是指那种依赖跨区域元数据库复制的灾备方案。如果用户用的是“同区域内备份恢复”的灾备策略，这种架构反而能兼顾可用性和成本，不至于过度设计。

内容的提问来源于stack exchange，提问作者gtango