2014/10/18に開催されたJavaOne報告会での「アーキテクチャトレンド」での発表資料です。 （誤字があったので再アップしました）

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