Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Monolith によるモダンアーキテクチャの再考 / Rethink modern arch...

polar3130
December 10, 2019

Monolith によるモダンアーキテクチャの再考 / Rethink modern architectures with Monolith

Cloud Native Meetup Tokyo #11
「Monolith によるモダンアーキテクチャの再考」のスライド資料です

polar3130

December 10, 2019
Tweet

More Decks by polar3130

Other Decks in Technology

Transcript

  1. 2 #cloudnativejp Whois Masahiko Utsunomiya Infrastructure Engineer / Relationship Builder

    NTT DATA Corporation ✓ 金融分野のお客様のクラウド導入支援 ✓ 興味:Observability(Prometheus, Fluentd, Loki, Jaeger, etc.) ✓ Grafana Loki コントリビュータ Helm Chart のメンテナンスなどしています polar3130
  2. 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 最新情報 • まとめ
  3. 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
  4. 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
  5. 11 #cloudnativejp プロダクトのはじまり 多くのプロジェクトが monorepo の Monolith から プロダクトを始める •

    例えば、シングルサーバの LAMP な Monolith を構築し、Nagios で監視 • 世の中に数多あるノウハウを活かせる • デプロイもアップデートも監視も簡単
  6. 15 #cloudnativejp Cortex の参照 成長したときに 大規模に展開できる プロダクトであって欲しい • Loki は

    “ like Prometheus, but for logs. ” のコンセプトにより、Prometheusと 多くの点で親和性がある • Prometheus で大規模展開といえば Cortex、設計の参考になるのでは • Cortex は Microservices + cloud storage が基本構成(一応 Cassandra も使える)
  7. 16 #cloudnativejp Cortex のユーザ体験 マイクロサービスゆえの、 開発や検証の難しさに直面 • ローカルとの環境差分をはじめ、 様々な要素が複雑に影響し、 障害原因がすぐに特定できない

    • 不具合を調べるためにトレーシング を導入して... • ログはデバッグレベルで集めて... • あれ?何がしたかったんだっけ?
  8. 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/
  9. 19 #cloudnativejp Monomicroliths Loki の設計にあたって 導入された設計手法 • Monolith としても、 Microservices

    としても利用可能な ソフトウェアアーキテクチャとして Grafana Labs が提唱 • セッションの登壇直前に商標登録が 完了したとのこと
  10. 20 #cloudnativejp Monomicroliths の特徴 下記 3 つの特徴と、それを 支える Modular Codebase

    で構成する • Mono repository • Single & unique binary • Airplane mode
  11. 22 #cloudnativejp Single & unique binary 単一のバイナリで Monolith としても Microservices

    としても 利用できるようにする • どのコンポーネントを使うときでも同じ バイナリを用いる • デプロイとデバッグを容易にしてくれる • デプロイが容易だと使ってくれる人が増える • コミュニティが育ちやすいプロダクト設計を 意識した
  12. 27 #cloudnativejp Loki のアーキテクチャ Cortex ベースの サービス構成を踏襲 Loki は多くのソースコードを Cortex

    から流用している コンポーネント間の依存関係 については Cortex のソース を参照するのがおすすめ 参考:https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
  13. 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: <component> target: <component> : すべて同一のシングルバイナリ Microservices mode
  14. 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
  15. 30 #cloudnativejp Loki を Microservices mode で利用する • 全コンポーネント共通の コンフィグファイルを準備

    • 実行時引数で target を指定し、 特定のコンポーネントとして のみ機能させる • すべてのコンポーネントが 同一のバイナリで稼働する
  16. 31 #cloudnativejp Microservices mode の展開方法 • 現状 Microservices mode に関するドキュメントはほとんどない

    • ソースコードや Configuration のドキュメントを読んでどうにかする • 現状の公式 Helm Chart は Microservices mode 非対応 • 今回の検証では Microservices mode の展開に Tanka (後述) を利用
  17. 32 #cloudnativejp Tanka とは 詳しくはこちらを参照 : https://tanka.dev/ Grafana Labs が開発している

    ksonnet 後継のマニフェスト管理ツール • ksonnet のワークフローとの互換性 • show / diff / apply は ksonnet と同じように利用可能 • 既存のOSSの有効活用 • jsonnet パッケージの管理には jsonnet-bundler を、Kubernetes クラスタへのアクセスには kubectl を利用 • Grafana Cloud の本番環境で Kubernetes クラスタ管理に Tanka を利用
  18. 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
  19. 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 を水平展開することで、 同時に複数のクエリを処理可能か
  20. 35 #cloudnativejp 検証① Loki(Microservices mode) の可用性 検証結果:概ねのコンポーネントは壊しても継続稼働できることを確認 • Distributor, Querier,

    Table-manager, Ingester のいずれを壊しても、全体としては稼働を継続できた • 当然ながらログコレクタやクエリ発行側の手当ては必要 • Ingester が破壊されるタイミングによってはログの欠損が発生する Loki (Microservices mode) Querier Ingester Distributor Table-manager kill container 稼働中に各コンポーネントが壊れてもサービスを継続可能か
  21. 36 #cloudnativejp 検証② Loki(Microservices mode) のクエリ並行処理 Querier を水平展開することで、同時に複数のクエリを処理可能か Loki (Microservices

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

    mode) Querier (2) Querier (1) Querier (3) 検証結果:複数のクエリを並行処理できることを確認 • 各クエリは単一の Querier で処理される LogQL {...} | “...”
  23. 38 #cloudnativejp より効率的なクエリ処理のために 分散処理による個々のクエリの高速化に対応予定 • Querier の流用元となっている Cortex の実装を参考にクエリ分散処理の設計が進められている •

    Cortex v0.4 で導入された、分割粒度が調整可能な split-query と同様のものが実装される見込み Cortex の PromQL 分散処理の仕組みについては下記セッションを参照 • split-query の仕組みの解説、v0.4 における機能改善のプレアナウンス、デモなど https://www.youtube.com/watch?v=yYgdZyeBOck
  24. 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: <component> target: <component> : すべて同一のシングルバイナリ Microservices mode
  25. 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
  26. 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
  27. 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
  28. 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 としても容易に展開可能 可用性やクエリの並列処理に関する基本的な機能の検証結果を共有