More Related Content
Similar to マイクロサービス入門(Spring fest 2017) (20)
More from Yuichi Hasegawa (16)
マイクロサービス入門(Spring fest 2017)
- 3. 3
長谷川 裕一
• 合同会社Starlight&Storm 代表
• 日本Springユーザ会 会長
• Springやオブジェクト指向を中心にしたコンサルティ
ングや教育で活動中
https://www.facebook.com/
starlightandstorm/
https://twitter.com/StarlightFuku
3
- 9. 参考:これはマイクロサービスではない
• 「オブジェクト指向開発超入門」2003年頃の資料から抜粋
• オブジェクト指向の必要性
– 製品やサービスの開発サイクル、ソフトのバージョンアップ間隔が短くなっている
• 段階的仕様追加に柔軟に対応した開発体制
• 仕様変更、機能追加、システム保守への柔軟な対応
• 信頼性の高い堅牢なシステムを短期開発で
• インタフェース重視で、部品化と並行開発の現実化
• 高い拡張性/保守性
– 保守の容易性
• カプセル化により、変更の影響が広がらない
– 交換、拡張が容易
• 部品となるオブジェクトを取り替えるだけ
• 再利用の仕組み
– オブジェクトを単位として、様々なレベルでのソフトウェアの部品化が可能
• 関連するデータと手続きをパッケージ
– 使い方が明確に決まっているため、クライアント側からの利用が容易
• カプセル化により内部はブラックボックス
• 明確な利用インターフェース
• オブジェクトモデルなら反復型開発
9
- 13. マイクロサービスの粒度
• まとめ方
– 固有のサービスをデータとそれを扱う処理の単位でまとめる
– 不自然な複数のサービスをまとめてはいけない
– 単一責任原則
• 変更の理由が同じものは集め、違うものは分ける
• 規模
– 2週間で書き直せる程度(Jon Evans)
– 概ね、「郵便番号検索」よりは大きく、基幹システムに含まれる「販売」
や「物流」「会計」などよりは小さい
– サービスがチーム構造と一致する程度の大きさ(コンウェイの法則)
– 経験的には、マイクロではなくミニがいい
13
- 18. モノリシック→マイクロサービス(1)
• 最初に理解しておきたいこと
– 複雑なもの(難しいもの)は簡単にならない
• 「マンガでわかる量子力学」→マンガで描いても量子
力学の難しさは無くならない(導入には役立つけど、先
に進めば難しさにぶつかる)
• そして、複雑なものは容易に(マイクロサービスに)分
割できない
• 間違った理解(新技術に対してよくある)
– マイクロサービスやDDDなどの新技術を使うと、複雑な
(難しい)既存システムが簡単になる
• 1つ1つのオブジェクト(コンポーネントやマイクロサービ
スを含む)のテストなどは簡単になるが、全体が複雑
なものは、やっぱり複雑で難しい
18
- 21. 参考:Cloud Native Maturity Model
21
レベル 概要
Cloud Native ・最適化されたMicroservices アーキテクチャが適用されている
・APIファーストな設計が行なわれている
Cloud Resillient ・Microserviceは、依存するサービスの障害に影響を受けない
・障害やパフォーマンスも含めたMicroserviceの測定とモニタリングが
できている
・作成するMicroserviceはクラウド環境に影響されないようになっている
Cloud Friendry ・アプリケーション(Microservice)では、Twelve Factorが実現されてい
る
・システムは、水平方向にスケーラブルとなっている
・システムは高可用性となっている
Cloud Ready ・アプリケーションは独立している
・インフラはコードで管理されている
・クラウド環境を利用している
- 22. 参考:Cloud Native Application Maturity Model
22
レベル 概要
Adaptive
(適応)
GOAL: 運用や管理が自動化された状態
・アプリケーションは、サービスの中断なしで、動的にインフラ間を移動できる
・アプリケーションは適切にスケールイン/アウトを行うことができる
Abstracted
(抽象化)
GOAL: マイクロサービスの構築
・サービスはステートレスである
・アプリケーションは依存しているサービスを知らない。また失敗による影響も受けな
い
・アプリケーションは、インフラストラクチャにとらわれないで、どこでも実行することがで
きる
Loosely Coupled
(疎結合)
GOAL: 主要なコンポーネント(もしくはレイヤ)が独立している
・アプリケーションは、疎結合なサービスで構成されている
・アプリケーション(サービス)は、名前によって発見される
・アプリケーションの処理とストレージが分離している
・アプリケーションは1つ以上のサービスを利用している
Virtualized
(仮想化)
GOAL: 迅速なインストール
・アプリケーションは仮想化されたインフラ上で実行される
・システムはイメージとして保存され、インスタンス化できる
- 28. 現在のシステム
• 現在のシステムをSoR(System of Record)とSoE(System of
Engagement)で俯瞰してみる
– SoRはメインフレームの基幹システムに代表されるデータを記録するような、定
型的なシステム
– SoEはクラウドやモバイル、センサーデバイスを積極的に利用するような、非定
型的なシステム
28
SoE
SoR
オンプレ
+
モノリシック
勘定系 販売系 B2B IoT
• Cloud
• 分散
• 可用性
• Legacy
• 集中
• 一貫性
- 30. 結論!?
• 適材適所でマイクロサービスとレガシシステ
ムのハイブリッド
マイ ク ロ
サービス
マイ ク ロ
サービス
マイ ク ロ
サービス
メ ッ セージ
メ ッ セージ
マイ ク ロ
サービス
マイ ク ロ
サービス
マイ ク ロ
サービス
XXX
システム
OOO
システム
Legacy、一貫性
勘定系…
Cloud、分散
B2C…
コンシューマ
無理にマイクロサー
ビスにしないところ
マイクロサービスを積
極的に取り入れると
ころ
30