KubeCon + CloudNativeCon NA 2019 Recap: Monolith による モダンアーキテクチャの再考 Masahiko Utsunomiya 2019/12/10 Cloud Native Meetup Tokyo #11

1 #cloudnativejp 掲載内容は個人の見解であり、 所属する企業や組織の立場、戦略、意見を 代表するものではありません

2 #cloudnativejp Whois Masahiko Utsunomiya Infrastructure Engineer / Relationship Builder NTT DATA Corporation ✓ 金融分野のお客様のクラウド導入支援 ✓ 興味：Observability（Prometheus, Fluentd, Loki, Jaeger, etc.） ✓ Grafana Loki コントリビュータ Helm Chart のメンテナンスなどしています polar3130

3 #cloudnativejp 制作に参加した書籍がでました “Kubernetes ポケットリファレンス” ISBN : 978-4-297-10957-8 2019/11/16発売 技術評論社より 主にレビュアとして参加、 本編・コラムの一部執筆も担当させて頂きました

4 #cloudnativejp Agenda • Recap セッション紹介 • “ Cloud Native Architecture: Monoliths or Microservices? “ Goutham Veeramachaneni & Edward Welch, Grafana Labs • 検証と考察 • Grafana Loki の Microservices mode 機能検証 • Monolith でモダンなアーキテクチャについて考える • おわりに • KubeCon + CloudNativeCon NA 2019 最新情報 • まとめ

Recap セッション紹介

6 #cloudnativejp セッション概要 Grafana Labs が新規OSS開発にあたって採用したアーキテクチャの話 Observability に関連するプロダクトだが、セッションの内容はソフトウェア設計の話が中心 Logging Metrics Visualize CNCF hosted projects Thanos, Cortex を参考にしつつ、いずれとも異なる 新しいソフトウェアアーキテクチャを導入 Grafana Labs

7 #cloudnativejp 関連プロジェクト紹介（ Metrics ） https://www.youtube.com/watch?v=f8GmbH0U_kI https://www.youtube.com/watch?v=m0JgWlTc60Q https://www.youtube.com/watch?v=9GMWvFcQjYI CNCF graduated project CNCF sandbox project いずれも Prometheus にメトリクス永続化、マルチテナンシー、 高可用性などを提供するOSS 詳しくは比較資料*を参照 ・Pull型アーキテクチャ ・時系列データベース を持つメトリクス収集ツール * https://promcon.io/2019-munich/slides/two-households-both-alike-in-dignity-cortex-and-thanos.pdf prometheus.io thanos.io cortexmetrics.io

8 #cloudnativejp 関連プロジェクト紹介（ Visualization, Logs ） like Prometheus, but for logs. • Kubernetes のクラスタレベルロギングが可能な 軽量ロギングツール • Prometheus にインスパイアされた設計 • v1.2.0 (KubeCon + CloudNativeCon NA 2019 で GA ) • Prometheus、および Grafana Loki をネイティブ サポートしている時系列データ可視化ツール • Loki の利用には v6.0 以降が必要 • 最新は v6.5.1 grafana.com grafana.com/oss/loki Grafana Labs

9 #cloudnativejp ご紹介：Grafana Loki の初心者向け資料 CloudNative Days Kansai 2019 にて登壇、入門的な内容を解説しています https://speakerdeck.com/polar3130/lets-begin-cloud-native-logging-with-grafana-loki

10 #cloudnativejp Recap セッションタイトル https://www.youtube.com/watch?v=BmPnNmN9jtc 講演者は Grafana Labs 所属で 下記プロダクトに注力 しているエンジニア2名 ・Prometheus ・Cortex ・Loki

11 #cloudnativejp プロダクトのはじまり 多くのプロジェクトが monorepo の Monolith から プロダクトを始める • 例えば、シングルサーバの LAMP な Monolith を構築し、Nagios で監視 • 世の中に数多あるノウハウを活かせる • デプロイもアップデートも監視も簡単

12 #cloudnativejp プロダクトの成長とコードの複雑化 サービスが成長し、単一の DBを共用するようになると 維持コストが増大 • 単一のDBで複数のサービス、という 構成がそもそもアンチパターン （こちらも参考になります： オライリー「マイクロサービスアーキテクチャ」）

13 #cloudnativejp なぜうまくいかなくなるか？ Conway の法則 • 組織がビジネスユニットを追加する たびにコンポーネント間の境界線が 曖昧になっていく • 成長に応じて design payoff line を 超えるときがくる • アーキテクチャを見直すタイミング

14 #cloudnativejp では Microservices にするのが良いのか 個々のサービスに合わせた スケールを選択できる • プロダクトの大規模な展開を視野に 入れるのなら、Microservicesはきっと 一度は検討するべきアーキテクチャ • セッションでは monzo の事例を引用

15 #cloudnativejp Cortex の参照 成長したときに 大規模に展開できる プロダクトであって欲しい • Loki は “ like Prometheus, but for logs. ” のコンセプトにより、Prometheusと 多くの点で親和性がある • Prometheus で大規模展開といえば Cortex、設計の参考になるのでは • Cortex は Microservices + cloud storage が基本構成（一応 Cassandra も使える）

16 #cloudnativejp Cortex のユーザ体験 マイクロサービスゆえの、 開発や検証の難しさに直面 • ローカルとの環境差分をはじめ、 様々な要素が複雑に影響し、 障害原因がすぐに特定できない • 不具合を調べるためにトレーシング を導入して... • ログはデバッグレベルで集めて... • あれ？何がしたかったんだっけ？

17 #cloudnativejp Thanos の参照 最小限のコンポーネントから 利用開始でき、必要に応じて 機能を追加できる設計 • 小さく始めて、大規模利用も視野に入 れられる良いアプローチと考えた • ローカル環境でも簡単に起動できる • 各コンポーネントはシングルバイナリ

18 #cloudnativejp Loki の設計方針 Thanos の 開発者フレンドリーな体験と、 Cortex のスケーラビリティを 両立させたい • 「一つのコンフィグで、依存関係を気 にする必要がなく展開できる Cortex 」 のようなものがロギングのために開発 できたなら... （このあたりの背景は Grafana Labs のブログ でも紹介されています*） * https://grafana.com/blog/2019/04/15/how-we-designed-loki-to-work-easily-both-as-Microservices-and-as-Monoliths/

19 #cloudnativejp Monomicroliths Loki の設計にあたって 導入された設計手法 • Monolith としても、 Microservices としても利用可能な ソフトウェアアーキテクチャとして Grafana Labs が提唱 • セッションの登壇直前に商標登録が 完了したとのこと

20 #cloudnativejp Monomicroliths の特徴 下記 3 つの特徴と、それを 支える Modular Codebase で構成する • Mono repository • Single & unique binary • Airplane mode

21 #cloudnativejp Mono repository すべてのコードを 単一のリポジトリで 管理する • 一つのパイプライン、統合された テストでプロダクトを管理できる • コードの一貫性を維持し、 リファクタリングを容易にする

22 #cloudnativejp Single & unique binary 単一のバイナリで Monolith としても Microservices としても 利用できるようにする • どのコンポーネントを使うときでも同じ バイナリを用いる • デプロイとデバッグを容易にしてくれる • デプロイが容易だと使ってくれる人が増える • コミュニティが育ちやすいプロダクト設計を 意識した

23 #cloudnativejp Airplane mode インターネットアクセスが なくてもプロダクトを利用 できる手段を備える • ローカルでの開発/テスト容易性 • 環境制約を少なく抑えることで利用 ハードルを下げる

24 #cloudnativejp セッション紹介はここまで

25 #cloudnativejp おや？Grafana Labs 公式ブログのようすが... https://grafana.com/blog/2019/12/03/kubecon-recap-cloud-native-architecture-Monoliths-or-Microservices/

検証と考察

27 #cloudnativejp Loki のアーキテクチャ Cortex ベースの サービス構成を踏襲 Loki は多くのソースコードを Cortex から流用している コンポーネント間の依存関係 については Cortex のソース を参照するのがおすすめ 参考：https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

28 #cloudnativejp Loki のデプロイ形態 Loki はユニークなシングルバイナリのまま、複数の実行モードを持つ Monolithic mode (gRPC) target: all Single process mode Cluster mode クラウドストレージ (or Cassandra) read / write read / write read / write write read NG ローカルストレージ target: all target: all target: target: : すべて同一のシングルバイナリ Microservices mode

29 #cloudnativejp Loki を Monolithic mode で利用する • Easy to use • Kubernetes 環境であれば、 Helm Chart を使って簡単に デプロイ可能 • Loki-Stack : • Loki, Promtail, Grafana, Prometheus または Loki, Fluentd, Grafana, Prometheus を まとめてデプロイする Helm Chart ( “git clone” from https://github.com/grafana/loki ) $ make loki $ ./loki -config.file=loki.yaml

30 #cloudnativejp Loki を Microservices mode で利用する • 全コンポーネント共通の コンフィグファイルを準備 • 実行時引数で target を指定し、 特定のコンポーネントとして のみ機能させる • すべてのコンポーネントが 同一のバイナリで稼働する

31 #cloudnativejp Microservices mode の展開方法 • 現状 Microservices mode に関するドキュメントはほとんどない • ソースコードや Configuration のドキュメントを読んでどうにかする • 現状の公式 Helm Chart は Microservices mode 非対応 • 今回の検証では Microservices mode の展開に Tanka (後述) を利用

32 #cloudnativejp Tanka とは 詳しくはこちらを参照 : https://tanka.dev/ Grafana Labs が開発している ksonnet 後継のマニフェスト管理ツール • ksonnet のワークフローとの互換性 • show / diff / apply は ksonnet と同じように利用可能 • 既存のOSSの有効活用 • jsonnet パッケージの管理には jsonnet-bundler を、Kubernetes クラスタへのアクセスには kubectl を利用 • Grafana Cloud の本番環境で Kubernetes クラスタ管理に Tanka を利用

33 #cloudnativejp 今回準備した検証環境 • Loki, Promtail • ともに v1.2.0 を利用 • Microservices mode 詳細 • Storage • Index: Bigtable • Chunk: GCS • Cache • Memcached v1.5.17 • Kubernetes クラスタ • GKE v1.14.8-gke.12 • ノード数 3 • Fault Injection • 可用性調査のため • Pumba v0.6.5 • マニフェスト管理 • Tanka v0.6.0 Loki v1.2.0 (Microservices mode) Loki v1.2.0 (Monolithic mode) Promtail v1.2.0 sample app (Istio Bookinfo) Grafana Loki-canary fault injection client_config 以外は すべて同一設定 Promtail v1.2.0

34 #cloudnativejp Microservices mode の検証の概要 水平スケーリングを活かした可用性や並列処理といった基本機能を検証 検証①：可用性 簡単にスケールアウトでき、 稼働中に一部のコンテナが落ちても サービスを継続できるか https://grafana.com/blog/2019/09/19/how-to-get-blazin-fast-promql/ https://grafana.com/blog/2019/04/15/how-we-designed-loki-to-work-easily-both-as-Microservices-and-as-Monoliths/ 検証②：クエリの並行処理 Querier を水平展開することで、 同時に複数のクエリを処理可能か

35 #cloudnativejp 検証① Loki（Microservices mode） の可用性 検証結果：概ねのコンポーネントは壊しても継続稼働できることを確認 • Distributor, Querier, Table-manager, Ingester のいずれを壊しても、全体としては稼働を継続できた • 当然ながらログコレクタやクエリ発行側の手当ては必要 • Ingester が破壊されるタイミングによってはログの欠損が発生する Loki (Microservices mode) Querier Ingester Distributor Table-manager kill container 稼働中に各コンポーネントが壊れてもサービスを継続可能か

36 #cloudnativejp 検証② Loki（Microservices mode） のクエリ並行処理 Querier を水平展開することで、同時に複数のクエリを処理可能か Loki (Microservices mode) Querier (2) Querier (1) Querier (3) 検証結果：複数のクエリを並行処理できることを確認 • 各クエリは単一の Querier で処理される LogQL {...} | “...”

37 #cloudnativejp 検証② Loki（Microservices mode） のクエリ並行処理 Querier を水平展開することで、同時に複数のクエリを処理可能か Loki (Microservices mode) Querier (2) Querier (1) Querier (3) 検証結果：複数のクエリを並行処理できることを確認 • 各クエリは単一の Querier で処理される LogQL {...} | “...”

38 #cloudnativejp より効率的なクエリ処理のために 分散処理による個々のクエリの高速化に対応予定 • Querier の流用元となっている Cortex の実装を参考にクエリ分散処理の設計が進められている • Cortex v0.4 で導入された、分割粒度が調整可能な split-query と同様のものが実装される見込み Cortex の PromQL 分散処理の仕組みについては下記セッションを参照 • split-query の仕組みの解説、v0.4 における機能改善のプレアナウンス、デモなど https://www.youtube.com/watch?v=yYgdZyeBOck

39 #cloudnativejp Loki のデプロイ形態（再掲） Loki はユニークなシングルバイナリのまま、複数の実行モードを持つ Monolithic mode (gRPC) target: all single process mode cluster mode クラウドストレージ (or Cassandra) read / write read / write read / write write read NG ローカルストレージ target: all target: all target: target: : すべて同一のシングルバイナリ Microservices mode

40 #cloudnativejp Monomicrolith は全く新しい考え方なのか？ Monomicroliths は Modular Monolith Architecture の一種といえる Airplane mode の搭載や、Microservices としても稼働可能といった点を独自要素と主張している * https://engineering.shopify.com/blogs/engineering/deconstructing-Monolith-designing-software-maximizes-developer-productivity Modular Monolithとは 単一リポジトリの Monolith を維持したまま、 ドメインベースのモジュールの集合によって サービスを構成するアーキテクチャ 直近ではカナダの大手ECプラットフォーム Shopify などで採用されている* Modular Monolith の概要理解には下記も有用 https://medium.com/design-and-tech-co/modular-monoliths-a-gateway-to- microservices-946f2cbdf382

41 #cloudnativejp Microservices だけが正解ではない 個々のサービスを個別にバージョン管理、リリース、スケーリングできること、 多言語プログラミングが可能になることが、必ずしも必要とは限らない セッションでは Segment が Microservices から Monolith に移行した事例を紹介* • 疎結合なモジュール • 明確に定義されたインターフェイス • カプセル化されたデータアクセス • インターフェイスの一貫性の維持 これらは Microservices でなくとも実現できるの では？ というのが Modular Monolith のモチベーション** * https://segment.com/blog/goodbye-Microservices/ ** https://engineering.shopify.com/blogs/engineering/deconstructing-Monolith-designing-software-maximizes-developer-productivity

おわりに

43 #cloudnativejp Loki と Grafana のこれから KubeCon + CloudNativeCon NA 2019 にてコミッタ達にヒアリングしてきました （公式にアナウンスされたものではありませんのでその点ご留意ください） ・Alerting (Loki) 現状は Promtail からメトリクスを発行する方式だが、 将来は Loki でネイティブにサポートしたい ・Storage (Loki) 現状、Cluster mode でローカルストレージは非サポートだが、 できるだけ早期にこれをサポートしたいと考えている ・Tracing (Loki, Grafana) ログのトレースIDからスパン詳細を可視化*（Grafana v7, may/2020 予定） まず Jaeger から、追って他のトレースツールもサポート予定 * https://www.youtube.com/watch?v=ocKZKQ_o5t8

44 #cloudnativejp まとめ “Cloud Native Architecture: Monoliths or Microservices?” のセッション紹介 Modular Monolith Architecture の一種として Grafana Labs は Monomicroliths を提唱 シングルかつユニークなバイナリで Monolith としても Microservices としても扱える設計 ただし、これもまた、銀の弾丸ではない Monolith は必ずしも悪ではない Monolith であれば必ず Cloud Native にならない、は間違い Microservices にすれば必ず Cloud Native になる、も間違い Grafana Loki の Microservices mode を検証 Microservices としても容易に展開可能 可用性やクエリの並列処理に関する基本的な機能の検証結果を共有

Thank you for your attention!