大規模なモノリシック・サービスを 分割する理由と方針 PLAID, Inc. Yoshiyuki Komazaki

Yoshiyuki Komazaki Tech Lead @ PLAID, Inc.

背景・目的

Customer Experience Platform ユーザーを理解する アクションする サイトに訪れたユーザーの体験を向上させるためのプラットフォーム

No content

Region #ECEFF1 Batch Layer Track Cloud Load Balancing Track Compute Engine Autoscaling Distributed Queue Cloud Pub/Sub End User Devices Redis Analyze Analyze Compute Engine Autoscaling Batch Cloud Bigtable Cloud Bigtable BigQuery Stride Compute Engine Cloud Storage Admin Admin Compute Engine Autoscaling Client Tracker.js Cloud CDN Realtime Layer or Cloud Front AWS JS/ SDK/ API Redislabs ... Stackdriver Stride 全体構成

Region #ECEFF1 Batch Layer Track Cloud Load Balancing Track Compute Engine Autoscaling Distributed Queue Cloud Pub/Sub End User Devices Redis Analyze Analyze Compute Engine Autoscaling Batch Cloud Bigtable Cloud Bigtable BigQuery Stride Compute Engine Cloud Storage Admin Admin Compute Engine Autoscaling Client Tracker.js Cloud CDN Realtime Layer or Cloud Front AWS JS/ SDK/ API Redislabs ... Stackdriver Stride 行数 + Ops用リポジトリ + ライブラリ等 ： 1 ： 1 ： ??? リポジトリ数 エントリーポイント + 起動オプション

ビジネスを加速させたい 開発速度を落としてはいけない スケールする構成にしたい

方針

現状の問題点を把握する - 機能を把握するのが難しい - 依存関係、影響範囲が見づらい - 変更がしづらい - 問題の切り分けが難しい - 起動が遅い

- 機能を把握するのが難しい - 依存関係、影響範囲が見づらい - 変更がしづらい - 問題の切り分けが難しい - 起動が遅い 現状の問題点を把握する 適切な大きさに分ける 明確な境界を設ける プロセスを分離する

適切な粒度に分割していく

方針（イメージ）

考えるべきこと ● 何を共有するか ● どう分割するか ● 移行方法 (→ 今回は話しません) 共通の基盤 分割・粒度 移行

何を共有するか ● 統一したほうが都合がいいもの ● 機能ごとに変える必要がないもの ● 機能と分離できるもの 共通の基盤

どう分割するか ● 把握しやすい大きさ ○ 全体も ○ そのサービス自体も ● 変更しやすい大きさ 分割・粒度 目安： ● 開発単位 ● チーム単位（≒ 機能・ビジネス単位）

具体的に ● リポジトリ ● コードベースの構成

マイクロサービス化あるある（？） 分割の境界を間違える ● 複数サービスにまたがる開発が面倒 ● 通信コスト ○ Latency ○ API定義だらけ

マイクロサービス化あるある（？） 分割の境界を間違える ● 複数サービスにまたがる開発が面倒 ● 通信コスト ○ Latency ○ API定義だらけ 元々がモノリス。うまく分割できることを期待しない。 まずはモノレポ。その下で大きくディレクトリを分けつつ進める。

コードベースの構成 karte services ops lib service-a service-b service-c nodejs frontend manifests service-a Dockerイメージを作成 Service内の実装も通信も自由 大体Teamに紐づいている単位 同期すべき共有Library 同期しなくていいものは別 repo k8sのmanifests service-client Service間通信用Client API Specから自動生成する

悩みポイント ● DBの共有 ● 開発環境

DBの共有 まずは「他のServiceからどうDBが使われているか」が把握できる状態ならOK 理想： ● DBはServiceが所有 ● 他ServiceとはAPIで連携 現実： ● 元々がモノリス ● １テーブルに詰め込まれすぎ ● 全て分割 & API化はきつい

開発環境 理想： ● 開発環境は本番環境に近づけたい ● できればk8s 現実： ● k8sの場合はイメージのbuildが必要 ● 既存の開発より遅くなる ● skaffoldのfilesyncはalpha機能 ローカルではdocker-compose。nginxでLBを代替 namespaceを分けて動作確認できる検証用クラスタも作っておく

まとめ ● 分割の目的と方針の話 ● 問題を把握し、目的を見失わないようにしつつ方針を決めていく ● こだわりはじめると終わらないので、ある程度の許容が必要

No content

Self-Contained Systems https://scs-architecture.org/

認証サービス 理想： ● 認証Serviceを用意 ● Serviceにリクエスト 現実： ● 移行中は既存システムと共存 まずは既存システムと同様のライブラリ（Node.js）を用意 認証部分がNode.js縛りになるが、機能開発と分離可能なので最初は許容