マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に

Japan Java User Group
マイクロサービスアーキテクチャ
アーキテクチャ設計と開発プロセスの歴史を背景に
2015/11/28
鈴木雄介
日本Javaユーザーグループ会長
JJUG CCC 2015 Fall
#ccc_gh3

自己紹介
鈴木雄介
– グロースエクスパートナーズ（株）
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
– 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
– SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1

Agenda
• アーキテクチャの変遷
• サービス管理のトレンド
• MSA
• プラットフォームの視点
• まとめ
2

アーキテクチャの変遷
3

4
メインフレーム
データデータ
ロジック
ロジック
クラサバウェブ
データ
ロジック
ロジックロジック

メインフレームの時代
• サーバにロジックやデータを集中、
クライアントは見るだけ
–サーバはハードウェアからソフトウェア
までを統合的に管理する
» AS400
–クライアントはダム端末と呼ばれ、単純
なビュワーであり、表現も貧弱
• ITの利用分野は経理や販売管理など
の事務作業が中心
5
データ
ロジック

クラサバの時代
• 1か所にデータを集中し、クライアン
トにロジックを配布する
–PC＋イントラネット（TCP/IP）
–サーバはバッチ処理に利用
–クライアントのファット化
» VisualBasic＋ORACLE
• ITの利用分野が広まり、様々な社内
処理に使われてくる
6
データ
ロジック
ロジック

ウェブの時代
• サーバとデータを集約し、クライア
ントはブラウザ化する
• インターネット！
–広域、オープン、ベストエフォート
–Java! Java! Java!
–ブラウザにどこまでのロジックを載せる
かは永遠のテーマ
• ITが”世界に拡がる”ようになる
7
データ
ロジック
ロジック

処理能力の場所と管理
• どこに処理能力があるのか？
–PCやインターネットという技術要素がアーキテクチ
ャを変遷させてきた
• どのように処理能力を管理するのか？
–これまではサーバとクライアントに閉じてきた
8

クラウドの時代
• ウェブ時代を引き継ぎつつも、サー
バの処理能力が超巨大化
–巨大なサービスの出現（Amazon.com）
–総体としてのサービスは連続的な変化せ
ざるをえない
• では、巨大なサービスを、どのよう
に管理していくのか？
9
クラウド
データ
ロジック
ロジック
ロジック
ロジック
ロジック

サービス管理のトレンド
10

Japan Java User Group 11https://www.flickr.com/photos/willfolsom/5681274525/

カナリアリリース
• 別名：ブルー・グリーンデプロイ、A/Bテスト
12

ダークカナリアリリース
• 「本番環境でテストする」
–開発者にしか見えないリリースをする
13

Chaos Monkey
• 平日日中にサーバをランダムにダ
ウンさせるためのOSS
• Netflixではインスタンスは毎週
、アベイラビリティゾーンあるい
はリージョン丸ごとは毎月障害
14

サービス管理でやること
• コードからサービスまでを自動化：DevOps
–コードをレポジトリからチェックアウト
–ビルドして、テストして、アーカイブして
–デプロイ先のサーバを起動して
–そのサーバにリリースして
–サービスレポジトリにサービスを登録して
–ロードバランサの設定を段階的に変更して
–サービスの稼働状況を監視して
–何かあったら色々する
15

必要な技術群
• デプロイ管理
– Jenkins、spinaker
• コンテナ、コンテナ管理
– Docker
– Kubernetes、Marathon+Mesos、spinaker
• ルーター
– Vamp、Zuul+Ribbon
• サービスレポジトリ
– ZooKeeper、Eureka
• 分散ログ集約
– Elasticsearch、Vector
16

基本的な前提
• 「全体的にサービス品質を高めるために、部分
的な品質劣化を許容する」
–不運なユーザ（≒カナリア）は存在しうるが、サー
ビス全体がダウンするような事態にはならない
• 全てのサービスがこうなるべきではない
–不幸なユーザーは認められない：医療/金融/軍事
–とはいえ、検討可能な領域もあるはず
» 現在は技術的に難易度が高いけども
17

そこで何が起きるのか？
• 巨大なサービスをいかに管理するか
–様々な自動化によってサービスの管理が楽になった
–であれば、アプリケーションの数が増えることは怖
くない
–そもそも、現代はアプリケーション同士が連携する
ことが前提になっている
• じゃ、もっと積極的に分割していいんじゃね？
–ということで「マイクロサービスアーキテクチャ」
18

Microservices Architecture (MSA)
• サービスによるコンポーネント化
• ビジネスケイパビリティに基づく組織化
• プロジェクトではなくプロダクト
• スマートなエンドポイントと単純なパイプ処理
• 分散ガバナンス
• 分散データマネジメント
• インフラの自動化
• フェイルを前提とした設計
• 進化的な設計
20

MSAの2つの側面
• 技術面：分散配置と統合
– サービスによるコンポーネント化
– スマートなエンドポイントと単純なパイプ処理
– 分散データマネジメント
– インフラの自動化
– フェイルを前提とした設計
• 組織面：持続性と分権
– ビジネスケイパビリティに基づく組織化
– プロジェクトではなくプロダクト
– 分散ガバナンス
– 進化的な設計
21

MSAの技術面：分散配置と統合
• サービスをサービスで構成する
–静的要素の組み合わせから動的要素の組み合わせへ
• メッセージによる統合
–個々の動的要素は標準プロトコルで協調動作する
• サービスをマネージする
–稼働監視、依存性管理、障害検知と復旧、ver管理
22

MSAの組織面：持続性と分権
• サービス全体を持続的に動作させる
–ソフトウェア開発からITサービス運営へ
• ドメイン固有の技術と運営
–ドメインごとの自主性を認め、標準化を否定する
• ドメイン個別のライフサイクル
–個別再構築の許容、あるいは犠牲的アーキテクチャ
23

MSAへの理解
• 広義には、粒度ではなく関係性に注目を
• どの粒度でもよい（マイクロに惑わされない）
–アプリとコンポーネント
–システムとサブシステム
–システム全体と個別システム
• 重要なのはサービス相互の関係性のあり方
–複雑なものを、いかに管理するのか
24

MSAへの理解
• 技術論と組織論の両輪が重要
–技術面：分散配置と統合
–組織面：持続性と分権
• 巨大なサービスはトップダウンに管理できない
–サービスとチームを分割していく
–それをDevOpsが保証していく
25

サービスの分割
• モジュール分割の基本は「時間軸の中で変化す
るスピードの違いの境目」で切る
–経年劣化するものは交換可能にする
–消費するものは充填可能にする
–可能な限りは標準化して交換や充填を容易にする
–外部要因と内部要因に注意
–機能だけではなく非機能にも気を遣う
26

参考：ソフトウェア品質
• ソフトウェア品質メトリクス
27
品質特性品質副特性
機能適合性完全性、正確性、適切性
性能効率性時間効率性、資源利用性、キャパシティ
互換性共存性、相互運用性
使用性
適切度認識性、習得性、運用性、ユーザエラー防止性
ユーザインタフェースの快美性、アクセシビリティ
信頼性成熟性、可用性、障害許容性、回復性
セキュリティ
機密保持性、インテグリティ、否認防止性、責任追跡性、真
正性
保守性モジュール性、再利用性、解析性、変更性、試験性
移植性順応性、設置性、置換性
「情報システム/ソフトウェアの品質メトリクスセット」経済産業省ソフトウェアメトリクス高度化プロジェクト
http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdf
http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf

サービスの多様性を保証する
• サービスは多様である
–でも、完全に多様ではうまくいかない
–適切に全体を管理しつつ、ボトムアップを許容する
• あるルールの元で多様性を保証する
–それがプラットフォーム
28

プラットフォームの視点
29

クラウドとプラットフォーム
30
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
仮想マシン
バッチ
リモート実行
モバイルアプリ
API管理
プッシュ通知
リアルタイム分析
RDB
NoSQL
キャッシュ
ストレージ
サーチ
Hadoopクラスタ
機械学習
ストリーム処理
データ変換
イベント処理
仮想ネットワーク
負荷分散
ロードバランサ
DNS
VPN
メディア変換
CDN
ハブ処理
バックアップ
リカバリ
認証認可
開発ツール
スケジューラー
インフラ自動化

プラットフォームとは
• 巨大なサービスを管理するための基盤
–あるルールを定義し、それに則る限りにおいては、
多様性を認める
–AWSのサービスを利用したほうが便利
–Web企業の柔軟なプラットフォームは、チームのば
らつきも許容する
» チームを細かく指導するぐらいなら、多少のミスを受け入
れた方がよい
※すべてのITサービスが、それでいいわけではない
31

プラットフォームを利用する
• パブリッククラウドのPaaS
–IaaSとしてだけ利用するのはもったいない
–クラウドデザインパターンを参考に
–積極的に”そのPaaS”に従うことで柔軟性が手に入る
» でも、ロックインも発生する！
» 様々なプラットフォームが存在するので、いろいろなもの
を経験することを推奨する
» 今後は業界特化のプラットフォームは増えていくはず
32

プラットフォームを設計する
• アーキテクチャ設計の対象がアプリだけではな
く、プラットフォームになっていく
–より全体的な視点の上で判断が必要になる
–パブリッククラウドを利用することも重要だけど、
プライべートなプラットフォームも増える
• プライベートなPaaSの登場
–エンタープライズでは自社PaaSを作るための仕組み
が主流になっていくはず
–インフラの統合から、プラットフォームの統合へ
33

まとめ
34

• どこに処理能力があるのか？
–メインフレーム＞クラサバ＞ウェブ
» PCやインターネットが大きく変えた
–現在はクラウドという超巨大サーバ
• その処理能力をどう管理するか？
–サーバとクライアントという時代から、超巨大なサ
ービスを管理する時代に
35

サービス管理のトレンド
• 全てを自動化する
–カナリアリリース
–ダークカナリアリリース
–Chaos Monkey
• 全体的にサービス品質を高めるために、部分的
な品質劣化を許容する
• 機能の分割が許容できるようになってきた
36

マイクロサービス
• 技術面：分散配置と統合
• 組織面：持続性と分権
• 巨大なサービスはトップダウンに管理できない
–でも、ボトムアップだけではうまくいかない
–適切に全体を管理しつつ、ボトムアップを許容する
–「あるルールの元で多様性を保証する」
37

プラットフォーム
• 巨大なサービスを管理するための基盤
–あるルールを定義し、それに則る限りにおいては、
多様性を保証する
• まだまだ技術的にも設計的にも未成熟な状況
–先端的な事例がでてきて、OSSなどを通じて広まり
つつある
–成熟すればプライベートなPaaSは増えていく
38

最後に
• プラットフォームをデザインする、プラットフ
ォームを利用するという視点を持とう
–「アプリを作って、それを動かすサーバを作る」と
いう考え方は終わる
–プラットフォームに従うかぎりは柔軟性を保証する
–今後、プラットフォームの標準化が進めば、より柔
軟性が高まっていくと思われる
39

マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に

Similar to マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に (20)

More from Yusuke Suzuki

More from Yusuke Suzuki (15)

Recently uploaded

Recently uploaded (7)

マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に