読者です 読者をやめる 読者になる 読者になる

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

MSAの技術面

分散配置と統合

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

MSAの文化面

持続性と分権

サービス全体を持続的に動作させる
  • ITサービスをどうやって運営させていくのか
  • どうやって機能をVerUpしていくのか
  • パフォーマンスがきになる場合は
  • サービスとして運営できるのか
ドメイン固有の技術と運営
  • ドメインの自主性を認めた上で、標準化を否定する
  • フロントエンドは早く変化に対応できるように、バックエンドは安定性を持たせる
ドメイン固有のライフサイクル
  • 部分的な再構築を行う
  • 犠牲的アーキテクチャ
  • サービス全体を安定させるために

WEBサービスのレガシー化

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

クラウド

サービスレベルがコードで管理できる
  • 仮想化技術
  • コードは機能だけ管理していたものからサービスまで管理できるようになった
動作構成パターンの共有化
  • StrutsMVCモデルが流行ったが、あくまでも静的な構成の範囲だった
  • APIを使うことで、動的な構成の実現ができるようになった。

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

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

技術論よりは技術館理論

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

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

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

SOAとMSA

SOA
MSA
  • 部分最適の集合
  • 全体サービスを分割して統治(するしかない)

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

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

MSAは銀の弾丸ではない

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

アーキテクチャの逆襲

柔軟性をアーキテクチャが保証する
ドメインに適したプロセスを選択する

MSAのデザイン

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

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

ドメインの発見

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

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

  • 何を共有していくのか

ドメイン=変化の境界線

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

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

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

プラットフォームの利用

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

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

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

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

バランスをいかに取るか
  • 孤立させすぎると無駄が増える
  • 共有し過ぎると対応できない

  • 現時点はプラットフォームを先に決めてしまったほうが楽

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

MSAの実例

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

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

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

特性

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

ECサイトの適正

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

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

当然、正解はない

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

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.  うまく行かなかったら壊すという考え方が必要
  • ある程度切り離していくことが必要
  • 早く作って早く壊す