这篇文章是ZOZO Technologies 2019 #1 Advent Calendar的第23篇文章。
昨天的文章是我们团队通过使用inductor来构建”使用GKE内部负载均衡功能构建内部负载均衡器”。由于麻烦而感到困扰，希望GCP能够给予一些帮助。

现在在本文中，虽然遗憾的是没有达到正式运营阶段，但我打算写下一些关于我在最近一段时间内在MLOps行业背后进行的“在涉及写入工作负载的ZOZOTOWN多云构想”的调研结果，以作纪念。

另外，今年我们公司共发布了五个圣诞日历。

ZOZO技术公司2019年圣诞月历
ZOZO技术公司2019年圣诞月历
ZOZO技术公司2019年圣诞月历
ZOZO技术公司2019年圣诞月历
ZOZO技术公司2019年圣诞月历

如果您方便的话，请看一下。

略读

• ZOZOTOWNではマルチクラウドアーキテクチャ(*1)をすすめている。 Ref: CNDT2019 ZOZOTOWN CloudNative Journey

今までは参照のみだったが、今回書き込みがあるワークロードでマルチクラウド設計をしてみた
良いDBaaS がなかったので辞めた。今後に期待。

(*1) 在这里所说的多云并不是指使用不同云平台的混合云架构，而是指为了提高可用性而在多个云平台上运行同一功能的架构。

多云设计的动机及背景

在ZOZOTOWN，我们正在推进多云架构，并且实际上已经有一些系统在多云环境中运行。

作为追求多云设计的动机之一，可以提到的一个重要原因是，在2019年上半年，云服务供应商XXXX在全区域发生了故障。由于ZOZOTOWN停止运行几个小时将带来巨大的损失，因此当我们意识到通过我们自己可控的技术来应对这种情况时，多云架构方案应运而生。

由于我们公司岡在Cloud Native Days Tokyo 2019上发表的演讲（CNDT2019 ZOZOTOWN云原生之旅），您可以引用此幻灯片来了解最新情况。

目前正在运行的这个系统是一个只执行读取操作的参考系统，在面临首次包含写入负载的情况下，我也参与了如何实现多云架构的讨论和研究。（在这个阶段我也加入了研究）

多云架构设计策略

总方针：以最小成本进行实施和运营。使用托管服务为前提。

不将云依赖的实施嵌入应用程序中。

虽然说要在多云平台上运行，但不会在应用程序中添加每个云平台的分支处理来吸收云服务提供商的差异。

避免在GCP使用Spanner，在AWS使用DynamoDB这样的设计。为了使相同的应用代码在多个云端环境中运行，只使用提供了开放规范或实现的中间件。例如MySQL等。

此外，我们将使用开放性规范的环境而非依赖于云端的环境，例如Google App Engine（GAE）或AWS Lambda等，来运行应用程序。例如，我们可以使用Kubernetes等环境。

使用托管服务

如果我们自己在IaaS上设置开源中间件，那么可以创建出在AWS、GCP和Azure上都可以运行的环境，但由于运维工作繁琐，我们不想这样做。

考虑使用SaaS（DBaaS），以使用托管服务为前提进行设计。

在具有写入负载的工作负载中的多云构想。

多云/多光构想

如果可能的话，这将是一个理想的架构方案。

例如，虽然 Fastly 是一个例子，但需要一种能够将请求分发到多个云上的负载均衡器。如果 Fastly（以此为例）出现故障，可以通过临时的 DNS 切换将用户请求直接发送到 AWS（以此为例）的负载均衡器，以避免整个服务的中断。

使用 k8s 框架来实现应用程序，并在各个云供应商的 k8s 托管服务中运行。虽然图中没有 Azure，但由于 Azure 也有 Azure Kubernetes Service (AKS)，因此也可以在 Azure 上实现该功能。

通过建立虚拟私有云(VPC)对等连接，可以消除DBaaS在云环境中的延迟问题。但问题在于，当前是否有支持多云、多光缆以及VPC对等连接的DB。

单灯多云/多读构想（妥协方案）

我在初步调查时怀疑了多云/多读的数据库的存在，因此作为一个现实的方案，我提出了一种写入仅限于单云，并且可以通过多云进行负载平衡的读取架构方案。

在Fastly（例）的层级中，将写入请求转发给AWS（例），而将读取请求分散到多个云中。

通过本地化部署使用专用线进行复制，或者使用DBaaS的专有功能。

如果主数据库出现故障，希望能够实现云上故障切换，但从实际角度考虑，即使不能实现也可以接受。如果主数据库的云服务发生故障，只能进行读取功能退化。

考虑满足要求的DBaaS服务

我們已定義以下需求，並調查了是否有符合這些需求且能夠建立符合構想的系統的DBaaS。以下是調查結果的總結。

蒙戈DB (Atlas)

複数の云提供商都支持的MongoDB开发元提供的SaaS。

然而，它没有支持云内复制。

CockroachDB 可以被简述为: 替代性数据库。

一种基于Google Spanner设计的数据库正在作为开源软件进行开发，并且正在努力将其转化为DBaaS。该项目由前Google员工开发。

该实例本身在主要的云供应商之一的实例中运行，旨在实现像蟑螂一样的高可用性为目标。

我认为，从设计思想的角度来看，这与我们的多云策略最为匹配，但印象上它还处于发展初期过于不成熟。

• まだまだ発展途上で実用段階ではなさそう

• 他社事例もほぼない。日本では一切ない(あったら教えてください)

DBインスタンスへの接続もインターネット越し

我觉得如果是一年后的话，可能还有机会，但现在很难雇用。

卡桑德拉（DataStax）

Cassandra 是一种能够进行分散写入的列式数据库。

然而，GCP目前还没有支持（以前当然是支持的！），所以无法进行云内复制。

弹性搜索（弹性云）

由于是搜索引擎，所以用途不同。

PostgreSQL（ElephantSQL）

PostgreSQL作为服务（SaaS）。

据说，
云内复制和云内故障转移功能得到了支持。由于PostgreSQL本身是单主数据库，因此无法像理所当然地实现多写功能。

如果选择PostgreSQL，因为它在Amazon RDS和Cloud SQL等平台上得到支持，所以选择是一个令人困扰的问题。

MySQL和Vitess（PlanetScale)

有名的Youtube工程师创造了一个名为Vitess的DBaaS。使用Vitess可以实现MySQL主数据库的写入和分布式操作。

最近才刚发布，并且没有支持东京地区，目前还不能使用。

卡夫卡（Confluent）

如果你想在多云环境中使用消息队列，尽管用途不同, 你可以使用Kafka的开发商Confluent提供的SaaS服务来实现。

Amazon Aurora数据库实例复制到CloudSQL中的MySQL。

我們確認了這並不是一個獨立的DBaaS服務，但我們調查了是否可以使用AWS和GCP的各自托管服務來滿足需求。

请参考我们团队成员hkame所写的这篇文章，获取有关调查结果的详细信息。Aurora是否可以进行MySQL复制到CloudSQL的操作。

当在Cloud SQL中指定主节点时，只能指定IPv4而不是FQDN。因此，当在Aurora中发生故障转移时，IP地址变化导致复制停止，结果不令人满意。看来需要进行一些自动转换的设计。

DBaaS 概括考虑

调查结果表明，作为备选方案的是适用于单点云/多读的PostgreSQL（ElephantSQL）等选项。

考虑满足要求的云内负载均衡器。

在这项研究中，我们在云计算的前端进行了一项调查，研究了用于分配访问云计算服务的服务。

迅速地 de)

在Fastly上，由于可以自己编写VCL并控制行为，因此具有相当高的灵活性。与CDN不同，它可以作为高功能的负载均衡器使用。

单一光云/多光线构想的分配也能够顺利满足要求。

如果Fastly出现故障，可以通过在DNS中进行切换，直接将请求发送到AWS（例如）的负载均衡器上，以避免所有服务中断。

易微網络

鉴于 VMware 收购了多云负载均衡的 Avi Networks 的新闻传出，我们邀请了 VMware 先生来到我们公司并听取了他们的讲解。

對於 Avi Networks，我們將在我們的 IaaS 環境中部署 Avi Networks 的負載平衡器，這不太像是一個托管服務。此外，由於根據核心數量收取授權費用，所以如果想在特定時候提高性能，我們必須從購買年度授權開始（沒有月或秒鐘的授權可用）。

据说实现单灯多云/多灯架构负载均衡可以采取以下策略。

• 読み込みリクエストの場合: DNSラウンドロビンでどちらかのクラウドに振り分ける

書き込みリクエストの場合: DNSラウンドロビンで一旦どちらかのクラウドに振り分ける。GCP(仮)に書き込みリクエストが来た場合は、AWS(仮)にプロキシーしてリクエストし、レスポンスを返す。

综述云内负载均衡器的研究

如果我想做，结果表明Fastly和Avi Networks都可以实现。个人而言，我觉得Fastly更灵活，不需要部署到我们的IaaS上并自己管理，所以我感到Fastly更胜一筹。

转变方针，并停止考虑。

尽管如上所述计划进行设计，但由于某种深层原因，最初设定的微服务API特性作为目标的写入工作负载发生了变化。

在这个时点上，由于无法实现仅读取的分散式单光云/多读取方案的设计已失去意义，并且由于不存在支持多光云/多读取的数据库，我们决定停止考虑并达成一致。

如果将来发布多云/多区块的 DBaaS 服务，可以再次考虑多云架构。我对CockroachDB有很高期望。

通过进行多云设计获得的见解

最后，我将记录并祭奠我个人对多云架构的体验感受。

说将多云化的系统提高可用性是不容易确定的。

因为设计的难度和复杂性激增，我甚至觉得多云化反而降低了容错性。

首先在单个云单个区域上投入时间提高应用程序的可靠性，确保能够达到云供应商目录规格所述的99.99％的可用性，然后再进行多云迁移以进一步提高容错性，这是一个我得出的好办法。

设计成本是原来的3到4倍。

在考虑云服务和SaaS的连接以及云之间的协同作用时，我感觉增加了3到4倍。

运用成本是XXX倍

由于这次没有进行实际运用，所以无法获得这方面的经验教训。

简单来看，考虑到与设计成本相同，运营成本可能增加3~4倍，因此设计（难度较高）和自动化变得非常重要，以将运营成本控制在大约1倍左右。运营自动化意味着为自动化付出成本，而学习成本仍然需要支付3~4倍，所以即使努力进行改进，我认为最多只能将其控制在1.5倍~2倍左右。

对敏捷性的不良影响

当需要使用Job Queue和内存数据库时，在多云环境下如何实现需要考虑，我感到需要花费一些时间来做好准备。

如果需要使用特定的新SaaS软件，就必须进行与SaaS的合约签订，这就需要花时间进行工程以外的调整，从而导致响应灵活性下降。

我感到如果敏捷性受到影响，就有可能错过商机，从而损害销售额。我不想因基础设施问题而被认为错失了销售机会。

消除供应商锁定，方便提供开发环境。

作为多云架构的主要方针，提出了只使用具有开放规范或实现的中间件来实现应用程序，以便无需根据不同的云进行更改。

由于这一点，除了消除了供应商锁定之外，还获得了可以在本地计算机上使用OSS构建完整开发环境的好处。

结束

对于即将尝试多云架构的人来说，

由於設計的難度和複雜性提升，我甚至覺得多雲化反而會降低系統的容錯性。

考虑到这一点，我建议你挑战一下。