SlideShare a Scribd company logo
1 of 40
Download to read offline
Japan Java User Group
マイクロサービスアーキテクチャ
アーキテクチャ設計と開発プロセスの歴史を背景に
2015/11/28
鈴木雄介
日本Javaユーザーグループ 会長
JJUG CCC 2015 Fall
#ccc_gh3
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
• プラットフォームの視点
• まとめ
2
Japan Java User Group
アーキテクチャの変遷
3
Japan Java User Group
アーキテクチャの変遷
4
メインフレーム
データ データ
ロジック
ロジック
クラサバ ウェブ
データ
ロジック
ロジック ロジック
Japan Java User Group
メインフレームの時代
• サーバにロジックやデータを集中、
クライアントは見るだけ
–サーバはハードウェアからソフトウェア
までを統合的に管理する
» AS400
–クライアントはダム端末と呼ばれ、単純
なビュワーであり、表現も貧弱
• ITの利用分野は経理や販売管理など
の事務作業が中心
5
データ
ロジック
Japan Java User Group
クラサバの時代
• 1か所にデータを集中し、クライアン
トにロジックを配布する
–PC+イントラネット(TCP/IP)
–サーバはバッチ処理に利用
–クライアントのファット化
» VisualBasic+ORACLE
• ITの利用分野が広まり、様々な社内
処理に使われてくる
6
データ
ロジック
ロジック
Japan Java User Group
ウェブの時代
• サーバとデータを集約し、クライア
ントはブラウザ化する
• インターネット!
–広域、オープン、ベストエフォート
–Java! Java! Java!
–ブラウザにどこまでのロジックを載せる
かは永遠のテーマ
• ITが”世界に拡がる”ようになる
7
データ
ロジック
ロジック
Japan Java User Group
処理能力の場所と管理
• どこに処理能力があるのか?
–PCやインターネットという技術要素がアーキテクチ
ャを変遷させてきた
• どのように処理能力を管理するのか?
–これまではサーバとクライアントに閉じてきた
8
Japan Java User Group
クラウドの時代
• ウェブ時代を引き継ぎつつも、サー
バの処理能力が超巨大化
–巨大なサービスの出現(Amazon.com)
–総体としてのサービスは連続的な変化せ
ざるをえない
• では、巨大なサービスを、どのよう
に管理していくのか?
9
クラウド
データ
ロジック
ロジック
ロジック
ロジック
ロジック
Japan Java User Group
サービス管理のトレンド
10
Japan Java User Group 11https://www.flickr.com/photos/willfolsom/5681274525/
Japan Java User Group
カナリアリリース
• 別名:ブルー・グリーンデプロイ、A/Bテスト
12
Japan Java User Group
ダークカナリアリリース
• 「本番環境でテストする」
–開発者にしか見えないリリースをする
13
Japan Java User Group
Chaos Monkey
• 平日日中にサーバをランダムにダ
ウンさせるためのOSS
• Netflixではインスタンスは毎週
、アベイラビリティゾーンあるい
はリージョン丸ごとは毎月障害
14
Japan Java User Group
サービス管理でやること
• コードからサービスまでを自動化:DevOps
–コードをレポジトリからチェックアウト
–ビルドして、テストして、アーカイブして
–デプロイ先のサーバを起動して
–そのサーバにリリースして
–サービスレポジトリにサービスを登録して
–ロードバランサの設定を段階的に変更して
–サービスの稼働状況を監視して
–何かあったら色々する
15
Japan Java User Group
必要な技術群
• デプロイ管理
– Jenkins、spinaker
• コンテナ、コンテナ管理
– Docker
– Kubernetes、Marathon+Mesos、spinaker
• ルーター
– Vamp、Zuul+Ribbon
• サービスレポジトリ
– ZooKeeper、Eureka
• 分散ログ集約
– Elasticsearch、Vector
16
Japan Java User Group
基本的な前提
• 「全体的にサービス品質を高めるために、部分
的な品質劣化を許容する」
–不運なユーザ(≒カナリア)は存在しうるが、サー
ビス全体がダウンするような事態にはならない
• 全てのサービスがこうなるべきではない
–不幸なユーザーは認められない:医療/金融/軍事
–とはいえ、検討可能な領域もあるはず
» 現在は技術的に難易度が高いけども
17
Japan Java User Group
そこで何が起きるのか?
• 巨大なサービスをいかに管理するか
–様々な自動化によってサービスの管理が楽になった
–であれば、アプリケーションの数が増えることは怖
くない
–そもそも、現代はアプリケーション同士が連携する
ことが前提になっている
• じゃ、もっと積極的に分割していいんじゃね?
–ということで「マイクロサービスアーキテクチャ」
18
Japan Java User Group
MSA
19
Japan Java User Group
Microservices Architecture (MSA)
• サービスによるコンポーネント化
• ビジネスケイパビリティに基づく組織化
• プロジェクトではなくプロダクト
• スマートなエンドポイントと単純なパイプ処理
• 分散ガバナンス
• 分散データマネジメント
• インフラの自動化
• フェイルを前提とした設計
• 進化的な設計
20
Japan Java User Group
MSAの2つの側面
• 技術面:分散配置と統合
– サービスによるコンポーネント化
– スマートなエンドポイントと単純なパイプ処理
– 分散データマネジメント
– インフラの自動化
– フェイルを前提とした設計
• 組織面:持続性と分権
– ビジネスケイパビリティに基づく組織化
– プロジェクトではなくプロダクト
– 分散ガバナンス
– 進化的な設計
21
Japan Java User Group
MSAの技術面:分散配置と統合
• サービスをサービスで構成する
–静的要素の組み合わせから動的要素の組み合わせへ
• メッセージによる統合
–個々の動的要素は標準プロトコルで協調動作する
• サービスをマネージする
–稼働監視、依存性管理、障害検知と復旧、ver管理
22
Japan Java User Group
MSAの組織面:持続性と分権
• サービス全体を持続的に動作させる
–ソフトウェア開発からITサービス運営へ
• ドメイン固有の技術と運営
–ドメインごとの自主性を認め、標準化を否定する
• ドメイン個別のライフサイクル
–個別再構築の許容、あるいは犠牲的アーキテクチャ
23
Japan Java User Group
MSAへの理解
• 広義には、粒度ではなく関係性に注目を
• どの粒度でもよい(マイクロに惑わされない)
–アプリとコンポーネント
–システムとサブシステム
–システム全体と個別システム
• 重要なのはサービス相互の関係性のあり方
–複雑なものを、いかに管理するのか
24
Japan Java User Group
MSAへの理解
• 技術論と組織論の両輪が重要
–技術面:分散配置と統合
–組織面:持続性と分権
• 巨大なサービスはトップダウンに管理できない
–サービスとチームを分割していく
–それをDevOpsが保証していく
25
Japan Java User Group
サービスの分割
• モジュール分割の基本は「時間軸の中で変化す
るスピードの違いの境目」で切る
–経年劣化するものは交換可能にする
–消費するものは充填可能にする
–可能な限りは標準化して交換や充填を容易にする
–外部要因と内部要因に注意
–機能だけではなく非機能にも気を遣う
26
Japan Java User Group
参考:ソフトウェア品質
• ソフトウェア品質メトリクス
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
Japan Java User Group
サービスの多様性を保証する
• サービスは多様である
–でも、完全に多様ではうまくいかない
–適切に全体を管理しつつ、ボトムアップを許容する
• あるルールの元で多様性を保証する
–それがプラットフォーム
28
Japan Java User Group
プラットフォームの視点
29
Japan Java User Group
クラウドとプラットフォーム
30
ネットワーク
仮想化
ストレージ
サーバ
OS
ミドルウェア
コード
設定
実行環境
データ
SaaS
PaaS
IaaS
仮想マシン
バッチ
リモート実行
モバイルアプリ
API管理
プッシュ通知
リアルタイム分析
RDB
NoSQL
キャッシュ
ストレージ
サーチ
Hadoopクラスタ
機械学習
ストリーム処理
データ変換
イベント処理
仮想ネットワーク
負荷分散
ロードバランサ
DNS
VPN
メディア変換
CDN
ハブ処理
バックアップ
リカバリ
認証認可
開発ツール
スケジューラー
インフラ自動化
Japan Java User Group
プラットフォームとは
• 巨大なサービスを管理するための基盤
–あるルールを定義し、それに則る限りにおいては、
多様性を認める
–AWSのサービスを利用したほうが便利
–Web企業の柔軟なプラットフォームは、チームのば
らつきも許容する
» チームを細かく指導するぐらいなら、多少のミスを受け入
れた方がよい
※すべてのITサービスが、それでいいわけではない
31
Japan Java User Group
プラットフォームを利用する
• パブリッククラウドのPaaS
–IaaSとしてだけ利用するのはもったいない
–クラウドデザインパターンを参考に
–積極的に”そのPaaS”に従うことで柔軟性が手に入る
» でも、ロックインも発生する!
» 様々なプラットフォームが存在するので、いろいろなもの
を経験することを推奨する
» 今後は業界特化のプラットフォームは増えていくはず
32
Japan Java User Group
プラットフォームを設計する
• アーキテクチャ設計の対象がアプリだけではな
く、プラットフォームになっていく
–より全体的な視点の上で判断が必要になる
–パブリッククラウドを利用することも重要だけど、
プライべートなプラットフォームも増える
• プライベートなPaaSの登場
–エンタープライズでは自社PaaSを作るための仕組み
が主流になっていくはず
–インフラの統合から、プラットフォームの統合へ
33
Japan Java User Group
まとめ
34
Japan Java User Group
アーキテクチャの変遷
• どこに処理能力があるのか?
–メインフレーム>クラサバ>ウェブ
» PCやインターネットが大きく変えた
–現在はクラウドという超巨大サーバ
• その処理能力をどう管理するか?
–サーバとクライアントという時代から、超巨大なサ
ービスを管理する時代に
35
Japan Java User Group
サービス管理のトレンド
• 全てを自動化する
–カナリアリリース
–ダークカナリアリリース
–Chaos Monkey
• 全体的にサービス品質を高めるために、部分的
な品質劣化を許容する
• 機能の分割が許容できるようになってきた
36
Japan Java User Group
マイクロサービス
• 技術面:分散配置と統合
• 組織面:持続性と分権
• 巨大なサービスはトップダウンに管理できない
–でも、ボトムアップだけではうまくいかない
–適切に全体を管理しつつ、ボトムアップを許容する
–「あるルールの元で多様性を保証する」
37
Japan Java User Group
プラットフォーム
• 巨大なサービスを管理するための基盤
–あるルールを定義し、それに則る限りにおいては、
多様性を保証する
• まだまだ技術的にも設計的にも未成熟な状況
–先端的な事例がでてきて、OSSなどを通じて広まり
つつある
–成熟すればプライベートなPaaSは増えていく
38
Japan Java User Group
最後に
• プラットフォームをデザインする、プラットフ
ォームを利用するという視点を持とう
–「アプリを作って、それを動かすサーバを作る」と
いう考え方は終わる
–プラットフォームに従うかぎりは柔軟性を保証する
–今後、プラットフォームの標準化が進めば、より柔
軟性が高まっていくと思われる
39

More Related Content

What's hot

ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話
Tsuyoshi Ushio
 
マイクロサービスアーキテクチャ とは何か
マイクロサービスアーキテクチャとは何かマイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャ とは何か
Yusuke Suzuki
 

What's hot (20)

それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
 
ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話
 
ウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_wsウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_ws
 
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったことドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
 
マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜マルチテナントのアプリケーション実装〜実践編〜
マルチテナントのアプリケーション実装〜実践編〜
 
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
J-3:アジャイルな経営(組織運営)のために 必要な3つのこと(ともう少し深いところの話)
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
Spring Cloud Data Flow の紹介 #streamctjp
Spring Cloud Data Flow の紹介  #streamctjpSpring Cloud Data Flow の紹介  #streamctjp
Spring Cloud Data Flow の紹介 #streamctjp
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチアーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
 
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
 
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
 
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
 
アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成
 
PHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったことPHPからgoへの移行で分かったこと
PHPからgoへの移行で分かったこと
 
マイクロサービスアーキテクチャ とは何か
マイクロサービスアーキテクチャとは何かマイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャ とは何か
 

Viewers also liked

プログラム初心者がWebサービスをリリースして運営するまで
プログラム初心者がWebサービスをリリースして運営するまでプログラム初心者がWebサービスをリリースして運営するまで
プログラム初心者がWebサービスをリリースして運営するまで
Tomoaki Iwasaki
 
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Toshiaki Maki
 

Viewers also liked (20)

Spring Bootハンズオン ~Spring Bootで作る マイクロサービスアーキテクチャ! #jjug_ccc #ccc_r53
Spring Bootハンズオン ~Spring Bootで作る マイクロサービスアーキテクチャ! #jjug_ccc #ccc_r53Spring Bootハンズオン ~Spring Bootで作る マイクロサービスアーキテクチャ! #jjug_ccc #ccc_r53
Spring Bootハンズオン ~Spring Bootで作る マイクロサービスアーキテクチャ! #jjug_ccc #ccc_r53
 
マイクロサービスアーキテクチャの設計 - JUG2015
マイクロサービスアーキテクチャの設計 - JUG2015マイクロサービスアーキテクチャの設計 - JUG2015
マイクロサービスアーキテクチャの設計 - JUG2015
 
マイクロサービス運用の所感 #m3dev
マイクロサービス運用の所感 #m3devマイクロサービス運用の所感 #m3dev
マイクロサービス運用の所感 #m3dev
 
プログラム初心者がWebサービスをリリースして運営するまで
プログラム初心者がWebサービスをリリースして運営するまでプログラム初心者がWebサービスをリリースして運営するまで
プログラム初心者がWebサービスをリリースして運営するまで
 
Real world machine learning with Java for Fumankaitori.com
Real world machine learning with Java for Fumankaitori.comReal world machine learning with Java for Fumankaitori.com
Real world machine learning with Java for Fumankaitori.com
 
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
 
日本 Java ユーザーグループ JJUG CCC 2015 Fall by ソラコム 片山
日本 Java ユーザーグループ JJUG CCC 2015 Fall  by ソラコム 片山 日本 Java ユーザーグループ JJUG CCC 2015 Fall  by ソラコム 片山
日本 Java ユーザーグループ JJUG CCC 2015 Fall by ソラコム 片山
 
Javaにおけるネイティブコード連携の各種手法の紹介
Javaにおけるネイティブコード連携の各種手法の紹介Javaにおけるネイティブコード連携の各種手法の紹介
Javaにおけるネイティブコード連携の各種手法の紹介
 
Java8 Stream APIとApache SparkとAsakusa Frameworkの類似点・相違点
Java8 Stream APIとApache SparkとAsakusa Frameworkの類似点・相違点Java8 Stream APIとApache SparkとAsakusa Frameworkの類似点・相違点
Java8 Stream APIとApache SparkとAsakusa Frameworkの類似点・相違点
 
【こっそり始める】Javaプログラマコーディングマイグレーション
【こっそり始める】Javaプログラマコーディングマイグレーション【こっそり始める】Javaプログラマコーディングマイグレーション
【こっそり始める】Javaプログラマコーディングマイグレーション
 
Java8移行から始めた技術的負債との戦い(jjug ccc 2015 fall)
Java8移行から始めた技術的負債との戦い(jjug ccc 2015 fall)Java8移行から始めた技術的負債との戦い(jjug ccc 2015 fall)
Java8移行から始めた技術的負債との戦い(jjug ccc 2015 fall)
 
デバッガのしくみ(JDI)を学んでみよう
デバッガのしくみ(JDI)を学んでみようデバッガのしくみ(JDI)を学んでみよう
デバッガのしくみ(JDI)を学んでみよう
 
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
 
Java EEハンズオン資料 JJUG CCC 2015 Fall
Java EEハンズオン資料 JJUG CCC 2015 FallJava EEハンズオン資料 JJUG CCC 2015 Fall
Java EEハンズオン資料 JJUG CCC 2015 Fall
 
タイムマシン採用:明日のエンタープライズJavaの世界を予想する -Java EE7/クラウド/Docker/etc.-
タイムマシン採用:明日のエンタープライズJavaの世界を予想する -Java EE7/クラウド/Docker/etc.-タイムマシン採用:明日のエンタープライズJavaの世界を予想する -Java EE7/クラウド/Docker/etc.-
タイムマシン採用:明日のエンタープライズJavaの世界を予想する -Java EE7/クラウド/Docker/etc.-
 
Spring boot劇的ビフォーアフター
Spring boot劇的ビフォーアフターSpring boot劇的ビフォーアフター
Spring boot劇的ビフォーアフター
 
JavaOne感想&技術トレンド紹介 - JavaOne2015報告会
JavaOne感想&技術トレンド紹介 - JavaOne2015報告会JavaOne感想&技術トレンド紹介 - JavaOne2015報告会
JavaOne感想&技術トレンド紹介 - JavaOne2015報告会
 
モブプログラミングを体験しよう at Agile Japan 2017 愛媛サテライト
モブプログラミングを体験しよう at Agile Japan 2017 愛媛サテライトモブプログラミングを体験しよう at Agile Japan 2017 愛媛サテライト
モブプログラミングを体験しよう at Agile Japan 2017 愛媛サテライト
 
MicroServices at Netflix - challenges of scale
MicroServices at Netflix - challenges of scaleMicroServices at Netflix - challenges of scale
MicroServices at Netflix - challenges of scale
 
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
「JJUG運営の戦略と戦術」 JJUG CCC 2016 Spring 基調講演
 

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

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

要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ要求の変化とマイクロサービスアーキテクチャ
要求の変化とマイクロサービスアーキテクチャ
 
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
 
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについてITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて
 
Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018Javaのカルチャーとグロース - MANABIYA 2018
Javaのカルチャーとグロース - MANABIYA 2018
 
アジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とはアジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とは
 
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~
 
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 FallJavaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
 
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...
 
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
 
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
プロダクトオーナーは育成できるのか? - プロダクトオーナー祭り2016
 
JJUC CCC 2013 Fall 基調講演「Javaと未来のこととCCC]
JJUC CCC 2013 Fall 基調講演「Javaと未来のこととCCC]JJUC CCC 2013 Fall 基調講演「Javaと未来のこととCCC]
JJUC CCC 2013 Fall 基調講演「Javaと未来のこととCCC]
 
クラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukuiクラウド時代のエンジニアについて #sesfukui
クラウド時代のエンジニアについて #sesfukui
 
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJPMicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
 
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
Javaエンジニアのための"クラウド時代の過ごし方" Java Day Tokyo 2016
 
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
 
開発現場から考える プロジェクトで活躍する 新入社員の育て方とは?
開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?開発現場から考えるプロジェクトで活躍する新入社員の育て方とは?
開発現場から考える プロジェクトで活躍する 新入社員の育て方とは?
 
JavaOne 2016総括 #jjug
JavaOne 2016総括 #jjugJavaOne 2016総括 #jjug
JavaOne 2016総括 #jjug
 
20130511 jjug ccc講演 さらばjsp JAXBとmixer2
20130511 jjug ccc講演 さらばjsp JAXBとmixer220130511 jjug ccc講演 さらばjsp JAXBとmixer2
20130511 jjug ccc講演 さらばjsp JAXBとmixer2
 
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
 
Azure IaaS update (2018年6月~8月 発表版)
Azure IaaS update (2018年6月~8月 発表版) Azure IaaS update (2018年6月~8月 発表版)
Azure IaaS update (2018年6月~8月 発表版)
 

More from Yusuke Suzuki

More from Yusuke Suzuki (16)

見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」 - デブサミ夏2023
 
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
 
マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
 
Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020Javaとコミュニティの歩み 2020
Javaとコミュニティの歩み 2020
 
エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020エンタプライズ領域のアジャイル開発の課題 - FIT2020
エンタプライズ領域のアジャイル開発の課題 - FIT2020
 
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのかなぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
 
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
DX時代に目指すべき品質向上とテスト - @IT ソフトウェア品質向上セミナー 2019夏
 
エンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれからエンタープライズ、アーキテクチャ、アジャイルのこれから
エンタープライズ、アーキテクチャ、アジャイルのこれから
 
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナーエンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
エンタープライズアジャイルでチームが超えるべきこと - エンタープライズアジャイル勉強会 2018年10月セミナー
 
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
エンタープライズアジャイルにおける要求探索の勘所 要求開発アライアンス2018年7月定例会
 
Javaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのかJavaはコミュニティの力で再び偉大になれるのか
Javaはコミュニティの力で再び偉大になれるのか
 
JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座JJUG初心者のためのJava/JJUG講座
JJUG初心者のためのJava/JJUG講座
 
エナジャイル設立によせて
エナジャイル設立によせてエナジャイル設立によせて
エナジャイル設立によせて
 
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナーユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
 
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考えるJavaとOSSとAndroid - JavaAPI訴訟問題を考える
JavaとOSSとAndroid - JavaAPI訴訟問題を考える
 
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
アジャイルと言わないエンタープライズアジャイル導入 - Agile Japan 2016
 

Recently uploaded

Recently uploaded (11)

新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半        2024/04/26の勉強会で発表されたものです。新人研修 後半        2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
 
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
 
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
 
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
 
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsUtilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
 
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
 
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
 
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
 
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアルLoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
 
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
 
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイスLoRaWANスマート距離検出センサー  DS20L  カタログ  LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
 

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

  • 1. Japan Java User Group マイクロサービスアーキテクチャ アーキテクチャ設計と開発プロセスの歴史を背景に 2015/11/28 鈴木雄介 日本Javaユーザーグループ 会長 JJUG CCC 2015 Fall #ccc_gh3
  • 2. Japan Java User Group 自己紹介 鈴木雄介 – グロースエクスパートナーズ(株) » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ – 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ – SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
  • 3. Japan Java User Group Agenda • アーキテクチャの変遷 • サービス管理のトレンド • MSA • プラットフォームの視点 • まとめ 2
  • 4. Japan Java User Group アーキテクチャの変遷 3
  • 5. Japan Java User Group アーキテクチャの変遷 4 メインフレーム データ データ ロジック ロジック クラサバ ウェブ データ ロジック ロジック ロジック
  • 6. Japan Java User Group メインフレームの時代 • サーバにロジックやデータを集中、 クライアントは見るだけ –サーバはハードウェアからソフトウェア までを統合的に管理する » AS400 –クライアントはダム端末と呼ばれ、単純 なビュワーであり、表現も貧弱 • ITの利用分野は経理や販売管理など の事務作業が中心 5 データ ロジック
  • 7. Japan Java User Group クラサバの時代 • 1か所にデータを集中し、クライアン トにロジックを配布する –PC+イントラネット(TCP/IP) –サーバはバッチ処理に利用 –クライアントのファット化 » VisualBasic+ORACLE • ITの利用分野が広まり、様々な社内 処理に使われてくる 6 データ ロジック ロジック
  • 8. Japan Java User Group ウェブの時代 • サーバとデータを集約し、クライア ントはブラウザ化する • インターネット! –広域、オープン、ベストエフォート –Java! Java! Java! –ブラウザにどこまでのロジックを載せる かは永遠のテーマ • ITが”世界に拡がる”ようになる 7 データ ロジック ロジック
  • 9. Japan Java User Group 処理能力の場所と管理 • どこに処理能力があるのか? –PCやインターネットという技術要素がアーキテクチ ャを変遷させてきた • どのように処理能力を管理するのか? –これまではサーバとクライアントに閉じてきた 8
  • 10. Japan Java User Group クラウドの時代 • ウェブ時代を引き継ぎつつも、サー バの処理能力が超巨大化 –巨大なサービスの出現(Amazon.com) –総体としてのサービスは連続的な変化せ ざるをえない • では、巨大なサービスを、どのよう に管理していくのか? 9 クラウド データ ロジック ロジック ロジック ロジック ロジック
  • 11. Japan Java User Group サービス管理のトレンド 10
  • 12. Japan Java User Group 11https://www.flickr.com/photos/willfolsom/5681274525/
  • 13. Japan Java User Group カナリアリリース • 別名:ブルー・グリーンデプロイ、A/Bテスト 12
  • 14. Japan Java User Group ダークカナリアリリース • 「本番環境でテストする」 –開発者にしか見えないリリースをする 13
  • 15. Japan Java User Group Chaos Monkey • 平日日中にサーバをランダムにダ ウンさせるためのOSS • Netflixではインスタンスは毎週 、アベイラビリティゾーンあるい はリージョン丸ごとは毎月障害 14
  • 16. Japan Java User Group サービス管理でやること • コードからサービスまでを自動化:DevOps –コードをレポジトリからチェックアウト –ビルドして、テストして、アーカイブして –デプロイ先のサーバを起動して –そのサーバにリリースして –サービスレポジトリにサービスを登録して –ロードバランサの設定を段階的に変更して –サービスの稼働状況を監視して –何かあったら色々する 15
  • 17. Japan Java User Group 必要な技術群 • デプロイ管理 – Jenkins、spinaker • コンテナ、コンテナ管理 – Docker – Kubernetes、Marathon+Mesos、spinaker • ルーター – Vamp、Zuul+Ribbon • サービスレポジトリ – ZooKeeper、Eureka • 分散ログ集約 – Elasticsearch、Vector 16
  • 18. Japan Java User Group 基本的な前提 • 「全体的にサービス品質を高めるために、部分 的な品質劣化を許容する」 –不運なユーザ(≒カナリア)は存在しうるが、サー ビス全体がダウンするような事態にはならない • 全てのサービスがこうなるべきではない –不幸なユーザーは認められない:医療/金融/軍事 –とはいえ、検討可能な領域もあるはず » 現在は技術的に難易度が高いけども 17
  • 19. Japan Java User Group そこで何が起きるのか? • 巨大なサービスをいかに管理するか –様々な自動化によってサービスの管理が楽になった –であれば、アプリケーションの数が増えることは怖 くない –そもそも、現代はアプリケーション同士が連携する ことが前提になっている • じゃ、もっと積極的に分割していいんじゃね? –ということで「マイクロサービスアーキテクチャ」 18
  • 20. Japan Java User Group MSA 19
  • 21. Japan Java User Group Microservices Architecture (MSA) • サービスによるコンポーネント化 • ビジネスケイパビリティに基づく組織化 • プロジェクトではなくプロダクト • スマートなエンドポイントと単純なパイプ処理 • 分散ガバナンス • 分散データマネジメント • インフラの自動化 • フェイルを前提とした設計 • 進化的な設計 20
  • 22. Japan Java User Group MSAの2つの側面 • 技術面:分散配置と統合 – サービスによるコンポーネント化 – スマートなエンドポイントと単純なパイプ処理 – 分散データマネジメント – インフラの自動化 – フェイルを前提とした設計 • 組織面:持続性と分権 – ビジネスケイパビリティに基づく組織化 – プロジェクトではなくプロダクト – 分散ガバナンス – 進化的な設計 21
  • 23. Japan Java User Group MSAの技術面:分散配置と統合 • サービスをサービスで構成する –静的要素の組み合わせから動的要素の組み合わせへ • メッセージによる統合 –個々の動的要素は標準プロトコルで協調動作する • サービスをマネージする –稼働監視、依存性管理、障害検知と復旧、ver管理 22
  • 24. Japan Java User Group MSAの組織面:持続性と分権 • サービス全体を持続的に動作させる –ソフトウェア開発からITサービス運営へ • ドメイン固有の技術と運営 –ドメインごとの自主性を認め、標準化を否定する • ドメイン個別のライフサイクル –個別再構築の許容、あるいは犠牲的アーキテクチャ 23
  • 25. Japan Java User Group MSAへの理解 • 広義には、粒度ではなく関係性に注目を • どの粒度でもよい(マイクロに惑わされない) –アプリとコンポーネント –システムとサブシステム –システム全体と個別システム • 重要なのはサービス相互の関係性のあり方 –複雑なものを、いかに管理するのか 24
  • 26. Japan Java User Group MSAへの理解 • 技術論と組織論の両輪が重要 –技術面:分散配置と統合 –組織面:持続性と分権 • 巨大なサービスはトップダウンに管理できない –サービスとチームを分割していく –それをDevOpsが保証していく 25
  • 27. Japan Java User Group サービスの分割 • モジュール分割の基本は「時間軸の中で変化す るスピードの違いの境目」で切る –経年劣化するものは交換可能にする –消費するものは充填可能にする –可能な限りは標準化して交換や充填を容易にする –外部要因と内部要因に注意 –機能だけではなく非機能にも気を遣う 26
  • 28. Japan Java User Group 参考:ソフトウェア品質 • ソフトウェア品質メトリクス 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
  • 29. Japan Java User Group サービスの多様性を保証する • サービスは多様である –でも、完全に多様ではうまくいかない –適切に全体を管理しつつ、ボトムアップを許容する • あるルールの元で多様性を保証する –それがプラットフォーム 28
  • 30. Japan Java User Group プラットフォームの視点 29
  • 31. Japan Java User Group クラウドとプラットフォーム 30 ネットワーク 仮想化 ストレージ サーバ OS ミドルウェア コード 設定 実行環境 データ SaaS PaaS IaaS 仮想マシン バッチ リモート実行 モバイルアプリ API管理 プッシュ通知 リアルタイム分析 RDB NoSQL キャッシュ ストレージ サーチ Hadoopクラスタ 機械学習 ストリーム処理 データ変換 イベント処理 仮想ネットワーク 負荷分散 ロードバランサ DNS VPN メディア変換 CDN ハブ処理 バックアップ リカバリ 認証認可 開発ツール スケジューラー インフラ自動化
  • 32. Japan Java User Group プラットフォームとは • 巨大なサービスを管理するための基盤 –あるルールを定義し、それに則る限りにおいては、 多様性を認める –AWSのサービスを利用したほうが便利 –Web企業の柔軟なプラットフォームは、チームのば らつきも許容する » チームを細かく指導するぐらいなら、多少のミスを受け入 れた方がよい ※すべてのITサービスが、それでいいわけではない 31
  • 33. Japan Java User Group プラットフォームを利用する • パブリッククラウドのPaaS –IaaSとしてだけ利用するのはもったいない –クラウドデザインパターンを参考に –積極的に”そのPaaS”に従うことで柔軟性が手に入る » でも、ロックインも発生する! » 様々なプラットフォームが存在するので、いろいろなもの を経験することを推奨する » 今後は業界特化のプラットフォームは増えていくはず 32
  • 34. Japan Java User Group プラットフォームを設計する • アーキテクチャ設計の対象がアプリだけではな く、プラットフォームになっていく –より全体的な視点の上で判断が必要になる –パブリッククラウドを利用することも重要だけど、 プライべートなプラットフォームも増える • プライベートなPaaSの登場 –エンタープライズでは自社PaaSを作るための仕組み が主流になっていくはず –インフラの統合から、プラットフォームの統合へ 33
  • 35. Japan Java User Group まとめ 34
  • 36. Japan Java User Group アーキテクチャの変遷 • どこに処理能力があるのか? –メインフレーム>クラサバ>ウェブ » PCやインターネットが大きく変えた –現在はクラウドという超巨大サーバ • その処理能力をどう管理するか? –サーバとクライアントという時代から、超巨大なサ ービスを管理する時代に 35
  • 37. Japan Java User Group サービス管理のトレンド • 全てを自動化する –カナリアリリース –ダークカナリアリリース –Chaos Monkey • 全体的にサービス品質を高めるために、部分的 な品質劣化を許容する • 機能の分割が許容できるようになってきた 36
  • 38. Japan Java User Group マイクロサービス • 技術面:分散配置と統合 • 組織面:持続性と分権 • 巨大なサービスはトップダウンに管理できない –でも、ボトムアップだけではうまくいかない –適切に全体を管理しつつ、ボトムアップを許容する –「あるルールの元で多様性を保証する」 37
  • 39. Japan Java User Group プラットフォーム • 巨大なサービスを管理するための基盤 –あるルールを定義し、それに則る限りにおいては、 多様性を保証する • まだまだ技術的にも設計的にも未成熟な状況 –先端的な事例がでてきて、OSSなどを通じて広まり つつある –成熟すればプライベートなPaaSは増えていく 38
  • 40. Japan Java User Group 最後に • プラットフォームをデザインする、プラットフ ォームを利用するという視点を持とう –「アプリを作って、それを動かすサーバを作る」と いう考え方は終わる –プラットフォームに従うかぎりは柔軟性を保証する –今後、プラットフォームの標準化が進めば、より柔 軟性が高まっていくと思われる 39