マイクロサービスアーキテクチャの設計 #jsug_sis

講演資料

www.slideshare.net

自己紹介

MSAの技術面

分散配置と統合

  • サービスをサービスで構成する

  • メッセージによる統合

  • サービスをマネージする

    • サービスは細かくなる
    • サービスをコントロールするのが難しいので、サービスをマネージメントすることも大事になる
    • サービスがダウンした時に復旧する仕組み
    • APIのVerUpについていけないことにならないように、互換性を持たせる

MSAの文化面

持続性と分権

  • サービス全体を持続的に動作させる

    • ITサービスをどうやって運営させていくのか
    • どうやって機能をVerUpしていくのか
    • パフォーマンスが気になる場合は
    • サービスとして運営できるのか
  • ドメイン固有の技術と運営

    • ドメインの自主性を認めた上で、標準化を否定する
    • フロントエンドは早く変化に対応できるように、バックエンドは安定性を持たせる
  • ドメイン固有のライフサイクル

    • 部分的な再構築を行う
    • 犠牲的アーキテクチャ
    • サービス全体を安定させるために

MSAの背景

WEBサービスのレガシー化

  • いまやエンタープライズよりも巨大で複雑
    • 例)Amazon
      • 特性はぜんぜん違う
      • 物流側は倉庫があるので変化しづらい
      • 自然にMSAになっていった

サービス共有の一般化

  • クラウド

    • サービスレベルがコードで管理できる
    • 仮想化技術
    • コードは機能だけ管理していたものからサービスまで管理できるようになった
  • 動作構成パターンの共有化

    • StrutsMVCモデルが流行ったが、あくまでも静的な構成の範囲だった
    • APIを使うことで、動的な構成の実現ができるようになった。

MSAとは新しい理想論ではなく現実解

  • 先鋭化して理想論のように見えてしまう

MSAを理解する

技術論よりは技術管理論

  • MSAは技術論ではなくいかに技術をマネジメントするかという方法論
    • どうやって優れた技術を管理するのか

粒度ではなく関係性に注目を

  • どの粒度でも良い(「マイクロ」に惑わされない)
    • アプリとコンポーネント
    • システムとサブシステム
    • システム全体と個別システム
  • 重要なのはサービス相互の関係性のあり方
    • 他のものとどういうかかわり合いをするのか
    • 複雑なものを如何に管理するのか

SOAとMSA

アーキテクチャは統治の手法

  • アーキテクチャはシステムを効率的に統治するための手法
  • 封建制君主制→民主制への変化と似ている
    • 乱立=封建制:孤立した統治
    • SOA君主制:偉大な王がいれば可能
    • MSA=民主制:有識な市民が必要な統治
      • 周りとの関係性を気にすることができる人が必要

MSAは銀の弾丸ではない

  • いかなる場合もMSAが最適ではない
    • エクセルが最適という人達の場所へ導入はしづらい
  • とはいえ関係性を重視するアプローチは必要

アーキテクチャの逆襲

MSAのデザイン

前提:企業システムにおける適用

  • ビジネス/業務には社会的責任がある
  • 遺産を保全しつつ変化を許容していく

ドメインの発見

  • どこを分割するのか、以下に統合するのか

プラットフォームのりよう

  • 何を共有していくのか

ドメイン=変化の境界線

  • 変化の境界線を見つける

    • ドメインも結果的に出てきただけ
    • 変化の境界線をどうやって見つけるのか
      • 車のタイヤはドメインが違う
      • 路面で削れるので、タイヤだけを交換できるようにした
      • 昔はホイールごと交換する必要があった
  • 変化の要因を品質特性から理解する

プラットフォーム=共有の動的資産

  • 複数のドメインを許容するための基盤
  • 今後はプライベートPaaSやハイブリットPaaSが存在する

プラットフォームの利用

  • SaaSはコーディングしない
  • PaaSは実行環境まで行う
  • IaaSは仮想化レイヤーまで

  • AWSのサービスはプラットフォームとして良く練られている

  • ただし、企業によってはもう一つ上のところまで必要なことがある

ドメインとプラットフォーム

  • バランスをいかに取るか

    • 孤立させすぎると無駄が増える
    • 共有し過ぎると対応できない
  • 現時点はプラットフォームを先に決めてしまったほうが楽

    • ただし、依存性をどうするのか考える必要はある

MSAの実例

  • システムとサブシステムのレイヤーでの話

  • 企業システムで言えばECサイト

    • 既存の社会的責任が維持されてしまう
      • ECサイトがダウンするとみんなが文句をいう
    • 多様な利害関係者
    • レガシー連携と最新トレンドの追随
    • 複雑性と柔軟性の課題が多い

ECサイトの特性

  • 流入→商品検索→購買
    • それぞれでの複雑性や利用者数の違い
    • 商品検索は人やものによって違う
    • カード番号入力はあまり変わらない
    • 在庫は現在の在庫数が必要なので、パフォーマンスが関わる
    • セキュリティの重要度やページビュー数が異なる

ECサイトの適正

プラットフォームの観点では、境界が明確なので、クラウドの部分適用も可能

  • 課金系があるサービスは同じような構成にできるかも

MSAの実践

  • 当然、正解はない
    • 手段の目的化はやめる
    • 良いデザインにすれば、勝手にそうなる

Springについて

Spring Bootだけじゃない

  • スクラムこそアジャイルですは胡散臭い
  • それと同じでSpring BootがMSAだと言うと胡散臭い
  • Springの良さはプラットフォームとしてのオープン化

まとめ

MSAについて

  • 2つの側面がある
  • 粒度ではなく関係性に注目を
  • 統治としてのMSA
  • ドメインとプラットフォーム
  • バランスをいかに取るか

企業システムで言えばECサイト

  • 無理にやる必要はない
  • 分けていく
  • 良識ある市民がたくさんいるかどうかも大切

Spring Bootだけじゃない

  • Springは好きです
  • アーキテクトに対して魅力的な選択肢

最後に

  • 「MSAにする」ではなく、「MSAになる」のが健全
  • 適切さを維持することを重視するべき
  • Spring Bootでも超絶的にレガシーになることはある

QA

  • Q.  SOAの場合、粒度の話が無かったが、MSAはちょうどいいぐらいのドメインになる
    • サービスを細かくすることで管理しやすくなった
    • APIのリストを管理したり
    • どのドメインがどの程度のパフォーマンスかが管理できる
  • ECは土地勘があると分けられるが…
  • ドメインをメトリクス的に分けられないのか?
  • A. うまく行かなかったら壊すという考え方が必要
  • ある程度切り離していくことが必要
  • 早く作って早く壊す