Download - マイクロサービスアーキテクチャの設計 - JUG2015
Japan Java User Group
マイクロサービスアーキテクチャの設計
2015/8/28
鈴木雄介日本Javaユーザーグループ 会長
R1-2
#jsug_sis
Spring in Summer ~ 夏なのにSpring
Japan Java User Group
自己紹介
鈴木雄介– グロースエクスパートナーズ(株)
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
– 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
– SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1
Japan Java User Group
Agenda
• MSAについて
• MSAを理解する
• MSAの設計
• MSAの実例
• Springについて
• まとめ
2
Japan Java User Group
MSAについて
3
Japan Java User Group
MSAとは?
Microservices Architecture (MSA)• サービスによるコンポーネント化• ビジネスケイパビリティに基づく組織化• プロジェクトではなくプロダクト• スマートなエンドポイントと単純なパイプ処理• 分散ガバナンス• 分散データマネジメント• インフラの自動化• フェイルを前提とした設計• 進化的な設計
4
Japan Java User Group
MSAの2つの側面
技術面:分散配置と統合–サービスによるコンポーネント化–スマートなエンドポイントと単純なパイプ処理–分散データマネジメント–インフラの自動化–フェイルを前提とした設計
文化面:持続性と分権–ビジネスケイパビリティに基づく組織化–プロジェクトではなくプロダクト–分散ガバナンス–進化的な設計
5
Japan Java User Group
MSAの技術面
分散配置と統合• サービスをサービスで構成する
–静的要素の組み合わせから動的要素の組み合わせへ
• メッセージによる統合
–個々の動的要素は標準プロトコルで協調動作する
• サービスをマネージする
–稼働監視、依存性管理、障害検知と復旧、ver管理
6
Japan Java User Group
MSAの文化面
持続性と分権• サービス全体を持続的に動作させる
–ソフトウェア開発からITサービス運営へ
• ドメイン固有の技術と運営
–ドメインごとの自主性を認め、標準化を否定する
• ドメイン個別のライフサイクル
–個別再構築の許容、あるいは犠牲的アーキテクチャ
7
Japan Java User Group
MSAの背景 1/2
ウェブサービスのレガシー化• いまやエンタープライズよりも巨大で複雑
• サービスの各要素ごとに特性や変化速度が大きく異なるため、標準化ができない
–ビッグバンではなく、個別サービスの再構築
• 巨大なウェブサービスをマネージするための必然的な選択がMSA
8
Japan Java User Group
MSAの背景 2/2
サービス共有の一般化• サービスレベルがコードで管理できる
–SDxの流れ。様々な仮想化技術
–サービス=非機能要件的なもの。性能や可用性など
–コードが機能だけではなく、サービスを管理できる
• 動作構成パターンの共有化
–OSSは静的な構成の共有化を実現し、APIは動的な構成の共有化を実現した
–代表例がパブリッククラウドサービス
9
Japan Java User Group
MSAとは
新しい理想論ではなく現実解• Amazon.comなどの先端的なクラウドサービスの観測結果であり、理想論というより現実解
–適切な手法を模索していたら、自然にそうなった
• ではあるが、それを先鋭化して理想論的になりつつある状況
10
Japan Java User Group
MSAを理解する
11
Japan Java User Group
MSAを理解する
技術論よりは技術管理論• MSAは「優れた技術」というより「いかに技術をマネジメントするかという方法論」
–優れた技術は出現し続ける
–いかに優れた技術を活用するのか≒いかに優れたエンジニアを活用するのか
–この15年は”アジャイル”で解決しようした領域
• もちろん、MSAは優れた技術に支えられている
12
Japan Java User Group
MSAを理解する
粒度ではなく関係性に注目を• どの粒度でもよい(マイクロに惑わされない)
–アプリとコンポーネント
–システムとサブシステム
–システム全体と個別システム
• 重要なのはサービス相互の関係性のあり方
–複雑なものを、いかに管理するのか
–粒度を無視して、SOAとMSAを比較する
13
Japan Java User Group
SOAとMSA
SOA:トップダウン• 理想の世界、全体最適、変更対応
• 個別システムの集合を統治(すべき)
MSA:ボトムアップ• 現実解、部分最適の集合、変化対応
• 全体サービスを分割して統治(するしかない)
14
Japan Java User Group
システム統治としてのMSA
アーキテクチャは統治の手法• アーキテクチャはシステムを効率的に統治するための手法
• 封建制→君主制→民主制への変化と似ている
–乱立=封建制:孤立した統治
–SOA=君主制:偉大な王がいれば可能な統治
–MSA=民主制:有識な市民が必要な統治
15
Japan Java User Group
MSAの適用
MSAは銀の弾丸ではない• いかなる場合でもMSAが最適なわけではない
–アジャイルと同じで適切な状況は存在する
»辺境の独立国家はないか?
»暴君はいないか?
»有識な市民がいるのか?
–SOAは必ずしも悪ではない
• とはいえ、関係性を重視するアプローチは重要
16
Japan Java User Group
MSAと開発プロセス
アーキテクチャの逆襲• 柔軟性をアーキテクチャが保証する–技術的な選択に柔軟性がないから、プロセスを柔軟にしていた
–しかし、技術的な柔軟性が出てきたため、WFであっても技術的な選択を遅らせられるようになった
• ドメインに適したプロセスを選択する–「すべてのプロジェクトをアジャイルで」もトップダウンなアプローチ
–予測可能な領域はWFのほうが効率的
17
Japan Java User Group
MSAのデザイン
18
Japan Java User Group
MSAのデザイン
前提:企業システムにおける適用• ビジネス/業務には社会的責任がある
• 多様な利害関係者/ルール/システムがいる
• 遺産の保全と変化の許容を両立する
• 複雑性と柔軟性についての解決する
19
Japan Java User Group
MSAのデザイン
ドメインの発見• どこを分割し、いかに統合するのか?
• どういった技術とプロセスを適用するか?
プラットフォームの利用• 何を共有するのか?
• どういった技術とプロセスを提供するのか?
20
Japan Java User Group
ドメインの発見
ドメイン=変化の境界線• 変化の境界線を見つける
–モジュール化は変化の境界線によって起きる
• 変化の要因を品質特性から理解する
–機能だけではなく、非機能も重視する
• 変化の濃淡に線を引く
–変化の境界は不明瞭だが、線を引くしかない
• ドメインは境界を維持したがる
–パッケージ問題、あるいは再構築問題
21
Japan Java User Group
参考:品質特性
22
品質特性 品質副特性
機能適合性 完全性、正確性、適切性
性能効率性 時間効率性、資源利用性、キャパシティ
互換性 共存性、相互運用性
使用性適切度認識性、習得性、運用性、ユーザエラー防止性ユーザインタフェースの快美性、アクセシビリティ
信頼性 成熟性、可用性、障害許容性、回復性
セキュリティ機密保持性、インテグリティ、否認防止性、責任追跡性、真正性
保守性 モジュール性、再利用性、解析性、変更性、試験性
移植性 順応性、設置性、置換性
「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクトhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdfhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf
Japan Java User Group 23
品質特性 特性の概要 副品質特性 概要
機能適合性実装された機能がニーズを満たす度合
完全性 ニーズを機能がユーザの目的やタスクを包含している度合
正確性 必要な精度で正確な結果を与える度合
適切性 機能が定められたタスクや目的を円滑に遂行する度合
性能効率性システムの実行時の性能や資源効率の度合
時間効率性 実行時のシステムの応答時間、処理時間などの処理能力の度合
資源利用性 実行時に使用する資源量や種類
キャパシティ 要求を満たすための製品やシステムのパラメータの最大許容値
互換性他製品やシステムと機能や情報を共有、変換できる度合
共存性 他製品へ負の影響を与えず、共通の環境や資源を共有して効果的に実行する度合
相互運用性 2つ以上の製品やコンポーネント間で情報を交換、利用できる度合
使用性効果的、効率的に利用できる度合
適切度認識性 ニーズに適した利用かどうか認識できる度合
習得性 システムの使い方の学習ができる度合
運用性 運用や管理のしやすさの度合
ユーザエラー防止性 誤操作しないように保護する度合
ユーザインタフェースの快美性
ユーザインタフェースが親しみがあり満足感のある応答ができる度合
アクセシビリティ 幅広い層の特徴や能力を持つ人々が利用できる度合
信頼性必要時に実行することができる度合
成熟性 通常時に信頼性のニーズを満たす度合
可用性 必要時に運用、接続できる度合
障害許容性 障害時に運用できる度合
回復性 障害時にデータやシステムが回復したり再構築できる度合
セキュリティ
不正にアクセスがされることなく、情報やデータが保護される度合
機密保持性 許可された者のみがアクセスできるようデータを保証する度合
インテグリティ プログラムやデータへの変更において未許可なアクセスを防止する度合
否認防止性 イベントやアクションの発生を証明する度合
責任追跡性 エンティティの実行が唯一であることを証明する度合
真正性 リソースや物事の身元が要求されたものであることを証明できる度合
保守性効果的、効率的に保守や修正ができる度合
モジュール性変更による他コンポーネントへの影響が最少で済むよう、独立したコンポーネントで構成される度合い
再利用性 他のシステムや資産を構築する際に利用できる度合
解析性変更部分や障害原因の特定のために診断したり、変更による影響を評価する際の効果性、効率性の度合
変更性 欠陥や品質の低下なく変更が効果的、効率的にできる度合
試験性 テスト基準を確立し、評価するために実行する際の効果性、効率性の度合
移植性効果的、効率的に他のハードウェアや実行環境に移植できる度合
順応性別のもしくは進化したハードウェアやソフトウェアや他の運用環境に効果的、効率的に順応できる度合
設置性 正しくインストール、もしくはアンインストールする際の効果性、効率性の度合
置換性 同一の目的、環境下で他のソフトウェア製品に置換(リプレース)できる度合
「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクトhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdfhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf
Japan Java User Group
プラットフォームの利用
プラットフォーム=共有の動的資産• 複数のドメインを許容するための基盤
–ドメインを跨がっても共有されるものは何か?
–分かりやすい例はパブリッククラウドにおけるミドルウェア層たち
• 今後はプライベートPaaSやハイブリッドPaaSの登場が予想される
–CloudFoundryはプライベートPaaS
24
Japan Java User Group
プラットフォームの利用
25
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
仮想マシンバッチリモート実行モバイルアプリAPI管理プッシュ通知リアルタイム分析RDBNoSQLキャッシュストレージサーチHadoopクラスタ機械学習ストリーム処理データ変換
イベント処理仮想ネットワーク負荷分散ロードバランサDNSVPNメディア変換CDNハブ処理バックアップリカバリ認証認可開発ツールスケジューラーインフラ自動化
Japan Java User Group
ドメインとプラットフォーム
バランスをいかに取るか• 独立させすぎると無駄が増える
• 共有しすぎると対応できない
• 現時点はプラットフォームを決めたほうが楽だが、すべてを単一プラットフォームに移行するのは容易ではない
26
Japan Java User Group
MSAの実例
27
Japan Java User Group
MSAの実例
企業システムで言えばECサイト• 既存の社会的責任が維持されてしまう
• 多様な利害関係者/ルール/システム
• レガシー連携と最新トレンドへの追随
• 複雑性と柔軟性の課題が多い
28
Japan Java User Group
ECサイトのドメイン設計
特性• 流入→商品検索→購買
–それぞれでの複雑性や利用者数の違い
–買わせるための属性と売るための属性の違い
• 個人情報やカード番号
• 基幹(請求/在庫など)との連携
–データの整合性と鮮度のコントロール
29
Japan Java User Group
サービス配置例
30
商品 商品登録商品検索
購買
受注 受注管理
記事 記事登録
商品担当者
請求担当者
コンテンツ担当者
消費者
記事表示
CMS
検索エンジン
商品管理
受注フロント
配送担当者
配送/請求ワークフロー
アジャイル的がよい
WF的がよい
アジャイル的がよい
WF的がよい
Japan Java User Group
ECサイトの構成
• 商品管理
– 分かりやすい商品登録。商品とマスタの紐付け、撮影
• コンテンツ管理
– 的確なコンテンツ配信。タイミング、キャンペーン
• 商品検索エンジン
– 高速で探しやすい検索
• 商品受注
– 分かりやすく間違えない購買プロセス
• 受注管理
– 確実で抜け漏れがない受注処理や配送処理
31
Japan Java User Group
ECサイトの構成
• プラットフォームの観点では、境界が明確なのでクラウドの部分適用も可能
–コンテンツ関連のスパイク対策
–データの整合性と鮮度の設計
• 最新のトレンド取り込みはSaaSもあり
• サービスと運営主体の近さ
32
Japan Java User Group
実例から実践へ
当然、「正解はない」• まずは対象システムの特性を理解する
• 「MSAにする」よりも「自然にMSAになった」というが健全
–手段を目的にしない!
–手段を目的にしない!
–手段を目的にしない!
33
Japan Java User Group
Springについて
34
Japan Java User Group
Springについて
Spring Bootだけじゃない• あらゆる粒度で関係性の管理が行える
–Framework:アプリ内の関係性管理
– Integration:アプリ間の関係性管理
• Springは何かを規定しないからこそ、アーキテクトにとって魅力的であり続ける
–プラットフォームとしてのオープンさが魅力
–どのドメインでも活用できることが価値
35
Japan Java User Group
まとめ
36
Japan Java User Group
MSAについて
2つの側面がある• 技術面:分散配置と統合
• 文化面:持続性と分権
理想論ではなく現実解• ウェブサービスのレガシー化
• サービス共有の一般化
37
Japan Java User Group
MSAを理解する
粒度ではなく関係性に注目を• マイクロという言葉に惑わされない
統治としてのMSA• 企業システムアーキテクチャは統治の歴史
• トップダウンからボトムアップへ
38
Japan Java User Group
MSAのデザイン
ドメインとプラットフォーム• ドメイン=変化の境界線
• プラットフォーム=共有の動的資産
バランスをいかに取るか• 独立させすぎると無駄が増える
• 共有しすぎると対応できない
39
Japan Java User Group
MSAの事例
企業システムで言えばECサイト• 多様なドメインが包含される
• ドメインの境界線が明確
• 様々なプラットフォームの組み合せが可能
40
Japan Java User Group
Springについて
Spring Bootだけじゃない• アーキテクトにとって魅力的な選択肢
41
Japan Java User Group
最後に
「MSAにする」のではなく
「MSAになる」のが健全
• MSAはITサービスを持続するためのアーキテクチャデザインコンセプト
• 個別の技術に惑わされることなく「適切さ」を維持することを重視すべき
42