SlideShare a Scribd company logo
Japan Java User Group 
アーキテクチャトレンド 
鈴木雄介 
日本Javaユーザーグループ 
グロースエクスパートナーズ株式会社 
JavaOne報告会 
#JJUG#j1jp
Japan Java User Group 
はじめに 
•JavaOneで感じたアーキテクチャのトレンドを 紹介 
–Javaに閉じる話ではありません 
•バズワード多めでお送りします 
–バスワードはトレンドを表現するキーワード 
–「だいたい」で使います 
•具体的な実装系の話は出てきません 
1
Japan Java User Group 
世の中の流れ 
•IoT(Internet of Things) 
–あらゆるモノがインターネットに接続し、あらゆる コトがインターネットを通じて発生する 
–デバイスの多様化と大量化 
»PC、タブレット、スマホ、ウェラブル 
»Kiosk、自動車、家電、テレビ 
»タグ、カード、センサー 
–経験の一体化 
»多様な入り口から同じデータにアクセスする 
»流通で言うとオムニチャネル 
2
Japan Java User Group 
サービスへ 
•アプリケーション開発からサービス運営へ 
–アプリケーション開発 
»仕様(静的)を定義する 
»開発者が作るもの 
»基本的には閉じた世界 
–サービス運営 
»利用(動的)からフィードバックを受ける 
»様々な人が関わりながら動かすもの 
»外的要因に大きく影響を受ける 
3
Japan Java User Group 
サービスへ 
•サービス運営のためのプロセス 
4 
企画 
開発 
運用 
Agile 
DevOps 
Lean 
Measure 
Lean 
Build 
tools & culture 
Individuals and interactions 
Working software 
Customer collaboration 
Responding to change
Japan Java User Group 
サービスへ 
•サービス運営のためのレイヤー 
5 
Networking 
Virtualization 
Storage 
Servers 
OS 
Middleware 
Code 
Configuration 
Runtime 
Data 
SaaS 
PaaS 
IaaS 
ロードバランサー 
ストレージアーカイブ 
CDN 
データ転送 
RDB・NoSQL 
データウェアハウス 
メモリキャッシュ 
データストリーム 
分散処理 
オーケストレーション 
サーチ 
ストリーミング 
メール配信 
メッセージキュー 
プッシュ通知 
ワークフロー 
課金 
メディア変換 
コンテナ 
デプロイ 
ユーザー活動分析 
モニタリング 
認証認可
Japan Java User Group 
アーキテクチャ 
•MicroservicesArchitecture 
–考え方 
»固有のドメインに固有のサービスがある 
▸サービスの境界はビジネスに従う 
▸データもドメインの内側にいれる 
»サービス同士はAPIとメッセージを介して連携する 
–SOAとの違い 
»SOA:モノリシックなアプリケーションをサービス化する 
▸トップダウンな設計 
»MSA:サービスを小さなサービスによって構成する 
▸ボトムアップな設計 
6
Japan Java User Group 
アーキテクチャ 
•Microservicesの9つの特徴 
–Componentization via Services/サービスによるコンポーネ ント化 
–Organized around Business Capabilities/ビジネスケイパビ リティに基づく組織化 
–Products not Projects/プロジェクトではなくプロダクト) 
–Smart endpoints and dumb pipes/スマートなエンドポイ ントと単純なパイプ処理 
–Decentralized Governance/分散ガバナンス 
–Decentralized Data Management/分散データマネジメント 
–Infrastructure Automation/インフラの自動化 
–Design for failure/フェイルを前提とした設計 
–Evolutionary Design/進化的な設計 
7 
Microservices 
http://martinfowler.com/articles/microservices.html
Japan Java User Group 
アーキテクチャ 
•Reactive 
–日本語でいうと「反応的な」 
–特徴は、 
»Event-driven/イベント駆動 
»Scalable/容易な拡張 
»Resilient/障害耐性が高い 
»Responsive/応答性が高い 
–技術的には、 
»非同期、ノンブロッキングなメッセージング 
»パターン:フェイル対応、疎結合化 
8 
The Reactive Manifesto 日本語訳 
http://kimitok.hateblo.jp/entry/2014/01/20/220438
Japan Java User Group 
アーキテクチャ 
•JavaOneの講演で紹介された製品 
–OSGi 
»Microservicesかというと微妙だけどモジュールは大事 
–Play+Akka 
»既存のEJBの手前にReactiveなレイヤーを作って性能改善し た話が面白かった 
–Spring Boot・Dropwizard 
»EoDだけではない監視や障害対応機能 
–RabbitMQ 
»メッセージといえば 
–Closureは、これから 
9
Japan Java User Group 
アーキテクチャ 
•JavaOneで話されていた設計 
–DDD(Domain Driven Design)を出す人が大半 
»Bounded Context/境界づけられたコンテキスト 
–変化の境界を見つけることが大事 
»変化の外的要因と内的要因 
»変化の質と量のギャップ 
»それぞれのドメインに最適な手法を用いる 
–とはいえ、手探りでっていう印象 
»カオスの淵 
10
Japan Java User Group 
アーキテクチャ 
•基本的な構成 
–Silver Bulletではない 
11 
HTML5(ClientMVC) 
API(Reactive/EDA) 
MessageQueue 
BusinessLogic(Domain) 
Database 
WebSocket/HTTP2.0 
AMQP 
AMQP 
JDBC
Japan Java User Group 
Docker 
•Docker 
–コンテナ型仮想化を基盤としたアプリケーションの 構成管理(と、考えた方がすっきりします) 
»OS~アプリケーションまでの構成情報のまとめてレポジト リに登録し、配布できるようになっている 
Networking 
Virtualization 
Storage 
Servers 
OS 
Middleware 
Code 
Configuration 
Runtime 
Data 
ここをまとめて 構成管理してる 
https://www.docker.com/
Japan Java User Group 
Docker 
•Dockerの仕組み1/2 
13 
http://www.slideshare.net/dotCloud/intro-docker-october-2013
Japan Java User Group 
Docker 
•Dockerの仕組み2/2 
14 
http://www.slideshare.net/dotCloud/intro-docker-october-2013
Japan Java User Group 
NoSQL 
•NoSQL 
–CAP定理 
»ノード間のデータ複製において、一貫性(Consistency)と 可用性(Availability)と分断耐性(Partition-tolerance)の3 つ全てを保証することはできない 
–とはいえ、ACIDは重要です 
»原子性(Atomicity)、一貫性(Consistency)、独立性( Isolation)、永続性(Durability) 
–この分野は正解がないので、個別のプロダクトの特 徴を見極めることが大事 
»JavaOneではMongoDBが多かったかな? 
15
Japan Java User Group 
なぜJavaなのか 
•Javaがオープンだから 
–成熟したJavaVMをプラットフォームとして、企業が 求める「安定性」と「挑戦」が両立している 
–両輪がフィードバックするのが理想的 
16 
JavaVM 
Standard 
Java 
Open 
Java 
安定しており、後方 互換性もある 
変化はゆっくり 
JavaME/SE/EE 
常に試行錯誤し、新し いことをやる 
安定しない 
コミュニティドリブン
Japan Java User Group 
サマリ 
•エンタープライズも楽しくなって参りました 
–大量なだけではなく、多様になっている点に注意 
–常に変化する全体にどうアプローチするか 
–ドメインに最適な手法を選択する 
•バズワードに注意 
–製品を安易にくくらない 
–どれもGoldenHammerではない 
»手段から始めない 
17

More Related Content

JavaOne報告会2014アーキテクチャトレンド

  • 1. Japan Java User Group アーキテクチャトレンド 鈴木雄介 日本Javaユーザーグループ グロースエクスパートナーズ株式会社 JavaOne報告会 #JJUG#j1jp
  • 2. Japan Java User Group はじめに •JavaOneで感じたアーキテクチャのトレンドを 紹介 –Javaに閉じる話ではありません •バズワード多めでお送りします –バスワードはトレンドを表現するキーワード –「だいたい」で使います •具体的な実装系の話は出てきません 1
  • 3. Japan Java User Group 世の中の流れ •IoT(Internet of Things) –あらゆるモノがインターネットに接続し、あらゆる コトがインターネットを通じて発生する –デバイスの多様化と大量化 »PC、タブレット、スマホ、ウェラブル »Kiosk、自動車、家電、テレビ »タグ、カード、センサー –経験の一体化 »多様な入り口から同じデータにアクセスする »流通で言うとオムニチャネル 2
  • 4. Japan Java User Group サービスへ •アプリケーション開発からサービス運営へ –アプリケーション開発 »仕様(静的)を定義する »開発者が作るもの »基本的には閉じた世界 –サービス運営 »利用(動的)からフィードバックを受ける »様々な人が関わりながら動かすもの »外的要因に大きく影響を受ける 3
  • 5. Japan Java User Group サービスへ •サービス運営のためのプロセス 4 企画 開発 運用 Agile DevOps Lean Measure Lean Build tools & culture Individuals and interactions Working software Customer collaboration Responding to change
  • 6. Japan Java User Group サービスへ •サービス運営のためのレイヤー 5 Networking Virtualization Storage Servers OS Middleware Code Configuration Runtime Data SaaS PaaS IaaS ロードバランサー ストレージアーカイブ CDN データ転送 RDB・NoSQL データウェアハウス メモリキャッシュ データストリーム 分散処理 オーケストレーション サーチ ストリーミング メール配信 メッセージキュー プッシュ通知 ワークフロー 課金 メディア変換 コンテナ デプロイ ユーザー活動分析 モニタリング 認証認可
  • 7. Japan Java User Group アーキテクチャ •MicroservicesArchitecture –考え方 »固有のドメインに固有のサービスがある ▸サービスの境界はビジネスに従う ▸データもドメインの内側にいれる »サービス同士はAPIとメッセージを介して連携する –SOAとの違い »SOA:モノリシックなアプリケーションをサービス化する ▸トップダウンな設計 »MSA:サービスを小さなサービスによって構成する ▸ボトムアップな設計 6
  • 8. Japan Java User Group アーキテクチャ •Microservicesの9つの特徴 –Componentization via Services/サービスによるコンポーネ ント化 –Organized around Business Capabilities/ビジネスケイパビ リティに基づく組織化 –Products not Projects/プロジェクトではなくプロダクト) –Smart endpoints and dumb pipes/スマートなエンドポイ ントと単純なパイプ処理 –Decentralized Governance/分散ガバナンス –Decentralized Data Management/分散データマネジメント –Infrastructure Automation/インフラの自動化 –Design for failure/フェイルを前提とした設計 –Evolutionary Design/進化的な設計 7 Microservices http://martinfowler.com/articles/microservices.html
  • 9. Japan Java User Group アーキテクチャ •Reactive –日本語でいうと「反応的な」 –特徴は、 »Event-driven/イベント駆動 »Scalable/容易な拡張 »Resilient/障害耐性が高い »Responsive/応答性が高い –技術的には、 »非同期、ノンブロッキングなメッセージング »パターン:フェイル対応、疎結合化 8 The Reactive Manifesto 日本語訳 http://kimitok.hateblo.jp/entry/2014/01/20/220438
  • 10. Japan Java User Group アーキテクチャ •JavaOneの講演で紹介された製品 –OSGi »Microservicesかというと微妙だけどモジュールは大事 –Play+Akka »既存のEJBの手前にReactiveなレイヤーを作って性能改善し た話が面白かった –Spring Boot・Dropwizard »EoDだけではない監視や障害対応機能 –RabbitMQ »メッセージといえば –Closureは、これから 9
  • 11. Japan Java User Group アーキテクチャ •JavaOneで話されていた設計 –DDD(Domain Driven Design)を出す人が大半 »Bounded Context/境界づけられたコンテキスト –変化の境界を見つけることが大事 »変化の外的要因と内的要因 »変化の質と量のギャップ »それぞれのドメインに最適な手法を用いる –とはいえ、手探りでっていう印象 »カオスの淵 10
  • 12. Japan Java User Group アーキテクチャ •基本的な構成 –Silver Bulletではない 11 HTML5(ClientMVC) API(Reactive/EDA) MessageQueue BusinessLogic(Domain) Database WebSocket/HTTP2.0 AMQP AMQP JDBC
  • 13. Japan Java User Group Docker •Docker –コンテナ型仮想化を基盤としたアプリケーションの 構成管理(と、考えた方がすっきりします) »OS~アプリケーションまでの構成情報のまとめてレポジト リに登録し、配布できるようになっている Networking Virtualization Storage Servers OS Middleware Code Configuration Runtime Data ここをまとめて 構成管理してる https://www.docker.com/
  • 14. Japan Java User Group Docker •Dockerの仕組み1/2 13 http://www.slideshare.net/dotCloud/intro-docker-october-2013
  • 15. Japan Java User Group Docker •Dockerの仕組み2/2 14 http://www.slideshare.net/dotCloud/intro-docker-october-2013
  • 16. Japan Java User Group NoSQL •NoSQL –CAP定理 »ノード間のデータ複製において、一貫性(Consistency)と 可用性(Availability)と分断耐性(Partition-tolerance)の3 つ全てを保証することはできない –とはいえ、ACIDは重要です »原子性(Atomicity)、一貫性(Consistency)、独立性( Isolation)、永続性(Durability) –この分野は正解がないので、個別のプロダクトの特 徴を見極めることが大事 »JavaOneではMongoDBが多かったかな? 15
  • 17. Japan Java User Group なぜJavaなのか •Javaがオープンだから –成熟したJavaVMをプラットフォームとして、企業が 求める「安定性」と「挑戦」が両立している –両輪がフィードバックするのが理想的 16 JavaVM Standard Java Open Java 安定しており、後方 互換性もある 変化はゆっくり JavaME/SE/EE 常に試行錯誤し、新し いことをやる 安定しない コミュニティドリブン
  • 18. Japan Java User Group サマリ •エンタープライズも楽しくなって参りました –大量なだけではなく、多様になっている点に注意 –常に変化する全体にどうアプローチするか –ドメインに最適な手法を選択する •バズワードに注意 –製品を安易にくくらない –どれもGoldenHammerではない »手段から始めない 17