Airbnbはマイクロサービスの「次」として何を考えているのか

unknown protocol

ツイートで流れてきて「Post-Microservices（マイクロサービスの次）」というキーワードに興味があったので、原文を読んでみることにした。

原文のタイトルは「マイクロサービスの道」となっていて、Post-Microservicesという雰囲気はしない。Twitterでは盛って書いたのかな。

Driven by their architecture mantra “we cannot impact business growth”, engineering teams step back to find sustainable solutions to these recurring problems.

「step backすることにした」と書いてあるが、要するに創業当時にmonolithだったものを2017年に一念発起してmicroservicesにしたが、ここにきて再びmonolithを考えるということのようだ。

With experience in the Microservices architecture, Airbnb had invested in automation and tooling. But faster cycles were required in an evolving set of technologies. The pragmatic solution is to invest in infrastructure-as-code in a single repository, enabling to gradually increase the adoption of services in parallel.

Airbnbは自動化とツール化に投資してきたが、これらを速いサイクルで回すにはマイクロサービスよりモノリスがよいとのこと。

There were so many Microservices tied together; even small changes led to interdependent changes and impacts, complex to master. Airbnb invest in productivity improvements focusing on supporting the new architecture on 3 areas:
- Ownership
- Observability
- Tooling.

多くのマイクロサービスが相互に接続すると小さな変更ですら相互関係が複雑になるので所有権と可観測性とツールの３つを強化することとした。

Airbnb embraces a new architecture style Micro+macroservices: In such architecture, each type of complexity is distributed is a clear layer:
- Unified APIs are Microservices supporting quick product iterations
- Central data aggregator are stable monolith’s glue with tight coupling
- Service block facade APIs abstract Microservices providing entity blocks.

そこでMicro+macroservicesという新しいアーキテクチャ。要素としてはUnified APIとCentral data aggregatorとService block facade APIの３つで交際されていて、Central data aggeregatorがglue(糊)の役割を果たし、Unified APIとService block facade APIがマイクロサービスにイテレーションや抽象化をもたらす存在となっている。

ここが話のキモだと思うのだが説明が少なすぎて頭に入ってこない。想像も交えると、step backと言ってるもののマイクロサービスからモノリスに戻そうというわけではなく、Post-Microservicesと言ってるもののMicroserviceそのものを一定のルールの下で推進して所有権とか可観測性を損ねないようにしようといった感じか。

Conwayの法則だとは書いてないが、こういったアーキテクチャにするため組織も似たような構造にしたというので、まさにConwayの法則だ。

- Mobile app deprecation > 12 months for results
- Elevate & track monolith debt for visibility
- Sunset low usage endpoints to accelerate removal
- Long-term ownership of the migration
- Recognize depreciation as impactful for valorization.

さらにMicro+macroservicesを推進させるチームを発足し「モバイルアプリのdeprecation(償却)を12か月にする」「モノリスの負債を可視化する」「頻度の低いエンドポイントはsunset(衰退)させる」「移行を長期的に保有する」「depreciation(償却)をインパクトがあるものと認識する」といった5点をリードしているという。

こちらも、読んでてよくわからなかったのだが、いざアーキテクチャを移行する段階になって読めば、納得できるものもあるかもしれない。


この記事が気に入ったらサポートをしてみませんか？