JavaOne報告会2014アーキテクチャトレンド
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 535 views

2014/10/18に開催されたJavaOne報告会での「アーキテクチャトレンド」での発表資料です。

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

Statistics

Views

Total Views
535
Views on SlideShare
401
Embed Views
134

Actions

Likes
6
Downloads
1
Comments
0

3 Embeds 134

https://twitter.com 132
http://kikutaro777.hatenablog.com 38
https://yyyank.blogspot.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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