講演資料
www.slideshare.net
自己紹介
MSAの技術面
分散配置と統合
サービスをサービスで構成する
メッセージによる統合
サービスをマネージする
MSAの文化面
持続性と分権
サービス全体を持続的に動作させる
- ITサービスをどうやって運営させていくのか
- どうやって機能をVerUpしていくのか
- パフォーマンスが気になる場合は
- サービスとして運営できるのか
ドメイン固有の技術と運営
ドメイン固有のライフサイクル
- 部分的な再構築を行う
- 犠牲的アーキテクチャ
- サービス全体を安定させるために
MSAの背景
WEBサービスのレガシー化
サービス共有の一般化
-
- サービスレベルがコードで管理できる
- 仮想化技術
- コードは機能だけ管理していたものからサービスまで管理できるようになった
動作構成パターンの共有化
MSAとは新しい理想論ではなく現実解
- 先鋭化して理想論のように見えてしまう
MSAを理解する
技術論よりは技術管理論
- MSAは技術論ではなくいかに技術をマネジメントするかという方法論
- どうやって優れた技術を管理するのか
粒度ではなく関係性に注目を
- どの粒度でも良い（「マイクロ」に惑わされない）
- アプリとコンポーネント
- システムとサブシステム
- システム全体と個別システム
- 重要なのはサービス相互の関係性のあり方
- 他のものとどういうかかわり合いをするのか
- 複雑なものを如何に管理するのか
SOAとMSA
アーキテクチャは統治の手法
MSAは銀の弾丸ではない
- いかなる場合もMSAが最適ではない
- エクセルが最適という人達の場所へ導入はしづらい
- とはいえ関係性を重視するアプローチは必要
アーキテクチャの逆襲
MSAのデザイン
前提：企業システムにおける適用
- ビジネス/業務には社会的責任がある
- 遺産を保全しつつ変化を許容していく
ドメインの発見
- どこを分割するのか、以下に統合するのか
プラットフォームのりよう
- 何を共有していくのか
ドメイン＝変化の境界線
変化の境界線を見つける
変化の要因を品質特性から理解する
プラットフォーム＝共有の動的資産
- 複数のドメインを許容するための基盤
- 今後はプライベートPaaSやハイブリットPaaSが存在する
プラットフォームの利用
- SaaSはコーディングしない
- PaaSは実行環境まで行う
IaaSは仮想化レイヤーまで
AWSのサービスはプラットフォームとして良く練られている
- ただし、企業によってはもう一つ上のところまで必要なことがある
ドメインとプラットフォーム
バランスをいかに取るか
- 孤立させすぎると無駄が増える
- 共有し過ぎると対応できない
現時点はプラットフォームを先に決めてしまったほうが楽
- ただし、依存性をどうするのか考える必要はある
MSAの実例
システムとサブシステムのレイヤーでの話
企業システムで言えばECサイト
- 既存の社会的責任が維持されてしまう
- ECサイトがダウンするとみんなが文句をいう
- 多様な利害関係者
- レガシー連携と最新トレンドの追随
- 複雑性と柔軟性の課題が多い
- 既存の社会的責任が維持されてしまう
ECサイトの特性
- 流入→商品検索→購買
- それぞれでの複雑性や利用者数の違い
- 商品検索は人やものによって違う
- カード番号入力はあまり変わらない
- 在庫は現在の在庫数が必要なので、パフォーマンスが関わる
- セキュリティの重要度やページビュー数が異なる
ECサイトの適正
プラットフォームの観点では、境界が明確なので、クラウドの部分適用も可能
- 課金系があるサービスは同じような構成にできるかも
MSAの実践
- 当然、正解はない
- 手段の目的化はやめる
- 良いデザインにすれば、勝手にそうなる
Springについて
Spring Bootだけじゃない
まとめ
MSAについて
- 2つの側面がある
- 粒度ではなく関係性に注目を
- 統治としてのMSA
- ドメインとプラットフォーム
- バランスをいかに取るか
企業システムで言えばECサイト
- 無理にやる必要はない
- 分けていく
- 良識ある市民がたくさんいるかどうかも大切
Spring Bootだけじゃない
- Springは好きです
- アーキテクトに対して魅力的な選択肢
最後に
- 「MSAにする」ではなく、「MSAになる」のが健全
- 適切さを維持することを重視するべき
- Spring Bootでも超絶的にレガシーになることはある
