エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4

#natsumiB4
© 2013 IBM Corporation
エンタープライズJava環境における
マイクロサービス・アーキテクチャーの必要性
2015/7/29
⽇日本アイ･ビー･エム株式会社
IBM Systems アプリケーションプラットフォーム
テクニカル・セールス⽥田中孝清

#natsumiB4 © 2015 IBM Corporation
2
Microservices Architecture

Microservices Architecture（MSA）とは
§ きっかけ
– ソフトウェア・
アーキテクチャーの⼤大家
マーティン・ファウラーの
2014年年3⽉月の
Blogエントリー
3
http://martinfowler.com/articles/microservices.html

Microservices Architectureの基本思想
§ 技術⾯面：分散配置と統合
– サービスによるコンポーネント化
– スマートなエンドポイントと単純なパイプ処理理
– 分散データマネジメント
– インフラの⾃自動化
– フェイルを前提とした設計
§ ⽂文化⾯面：持続性と分権
– ビジネスケイパビリティに基づく組織化
– プロジェクトではなくプロダクト
– 分散ガバナンス
– 進化的な設計
4
グロースエクスパートナーズ（株）鈴鈴⽊木雄介⽒氏
「マイクロサービスアーキテクチャとは何か」より
http://www.slideshare.net/yusuke/msa-share-02

Microservices Architectureアプリケーション
§ 単⼀一の（モノリシックな）アプリとして実装するのではなく，
複数のサービスの統合として実装する
– 変更更の影響範囲を極⼩小化
– 機能の再利利⽤用を促進
5 http://martinfowler.com/articles/microservices.html

どこかで聞き覚えが・・・
§ SOA：Service Oriented Architecture
6
2004〜～
IBM，Gartner他

Microservices ArchitectureはSOAの進化型
§ モノリシック・アプリケーション
– 全体を単⼀一のコードとして実装
§ SOA（サービス指向アーキテクチャー）
– サブシステムごとに独⽴立立して実装／依存関係が可視化
§ MSA（マイクロサービス・アーキテクチャー）
– システムを構成する機能（ファンクション）単位でサービス化
7
Monolithic App SOA Micro-services

粒粒度度を細かくして機能単位のスケールアウトを実現
§ ⼩小さなサービス単位でプロセスを起動することで
負荷に応じた柔軟なスケールアウト（拡張）が可能に
8
http://martinfowler.com/articles/microservices.html

結局Microservice Architectureとは
§  SOAを追求し，改善を続けていったらMSAになった
– SOAからのいくつかの改良良
• サービスの粒粒度度は「企業の組織単位」ではなく「業務の機能単位」で
• 通信経路路は⾼高機能なSOAP通信ではなく単純なREST通信も活⽤用
• ESBは必須ではなくメッシュ型の直接呼び出しもOK
§ 「新しく考え出された理理想論論」ではなく
多くの成功したWebシステムのに共通する
「観測された現実解」に名前をつけたもの
9

SOA / MSA導⼊入の⽬目的
§ 変化への対応を早く
10
オペレーションのスピード
ミッション・クリティカルな
アプリケーションの管理理、運⽤用
Systems of Record
マラソンランナー
q  サービスレベル重視
q  ウォーターフォール開発
q  ⻑⾧長期に渡るシステム構築
¦ 数ヶ⽉月〜～数年年
イノベーションのスピード
成⻑⾧長機会のための
探索索、開発、デプロイ
Systems of Engagement
スプリンター
q  スピード開発
q  試⾏行行錯誤、継続的デプロイ
q  早期のシステム構築/改修
¦ 数⽇日〜～数週間

11
MSAを必要とする「変化」とは

企業のITシステムが直⾯面する⼤大きな変化
§ クライアント・ブラウザの進化
§ モバイルへの対応
§ 外部システム連携・APIエコシステム
12

企業のITシステムが直⾯面する⼤大きな変化（１）
13

クライアント・ブラウザの変化
§ MSIE 6 全盛期（2000年年代〜～）
– Windows XP＋MSIE 6をターゲットにすればよかった
– HTML4によるフォーム型Webアプリケーション
§ マルチ・ブラウザ時代（2010年年代〜～）
– Firefox / Google Chrome / Safariなどモダンブラウザの台頭
– MSIEが7から11まで進化 / Windows 10ではEdgeが標準に
– HTML5によるSPA型Webアプリケーション
14
+

今まで以上にPLとBLの分離離が必要に
§ プレゼンテーション・ロジック（PL）の変化と
ビジネス・ロジック（BL）の変化の速度度の⼤大きな不不⼀一致
– 頻繁な変更更を要求されるプレゼンテーションロジック
– ⻑⾧長期にわたって使⽤用されるビジネスロジック
§ 独⽴立立したシステムとして構築するメリットが増⼤大
– PLとBLをサービスとして連携
15
ビジネス
ロジック
プレゼンテーション
ロジック

Webアプリケーションの実装スタイルの変化
§ 「サーバーサイドMVC」から「クライアントMVC」へ
16
Web Browser
Application Server
Application
HTTP
Request
HTML/JS
Controller Session
Data
View
Business
LogicModel
DomainDomain
Web Browser
Application Server
Application
View
HTML/JS
Controller
Data
Store
Model
Model
DomainDomain
RESTful or
WebSocket
JSON
Business Logic

企業のITシステムが直⾯面する⼤大きな変化（２）
17

モバイル機器の急速な普及
18
Source: Wikipedia　　http://en.wikipedia.org/wiki/Mobile_operating_system
世界　スマートフォン売り上げ台数（単位：千）

Webからモバイルアプリケーションへ
§ モバイル対応の第⼀一段階
– Webアプリケーションの画⾯面をモバイル⽤用にカスタマイズ
§ 本格的なモバイル対応
– モバイル・アプリケーションの実装
• モバイル環境に最適化されたUI
• GPSやカメラなどの機能の活⽤用
• オフライン処理理
19

モバイルアプリケーションのバックエンド連携
§ モバイルアプリケーションは（多くの場合MEAP経由で）
バックエンドシステムをサービスとして利利⽤用
– 必然的にSOA / MSAになる
20
MEAP製品!
!
Mobile!
Enterprise!
Application!
Platform!
ESB製品!
SOAP / HTTP!
REST! 基幹システムや 
クラウド・サービス
基幹システムや 
基幹システムや 

企業ITシステムが直⾯面する⼤大きな変化（３）
21

APIの提供や活⽤用による効果
22
APIの提供 APIの活⽤用
•  Assembly
•  Transformation
•  Rationalization
•  Discovery
•  Composition
•  Deployment
Assets &
Services
Application End
Points
新たなチャネルによ
る収益の増⼤大
今までにない新しい
顧客体験の実現
外部 APIs
パートナー APIs
社内 APIs

実例例：SNSアカウントをつかったログイン
§ メリット
– 利利⽤用者を煩雑なユーザー登録処理理から解放
– 万が⼀一の情報漏漏洩発⽣生時のリスクを軽減
– SNS上のバイラル（⼝口コミ）マーケティングの促進
§ デメリット
– 頻発する外部システムの
仕様変更更への追随
23

24
アプリケーション・アーキテクチャーの刷新

変⾰革期を迎えているエンタープライズJava
§ 2000年年代に多くの企業で
Javaを使⽤用した業務アプリケーションのWeb化を実施
– J2EEアーキテクチャー
– Struts / Spring / Hibernate などのOSSフレームワークの活⽤用
§ 更更新と改良良をつづけてきたアプリケーションの中には
現⾏行行アーキテクチャーの限界がみえてきたものも多い
– Strutsなどのサポート終了了とセキュリティ脆弱性問題
– 旧APIのみを使⽤用したアプリを互換性モードで稼働
– 最新の要件への対応ができない
§ ⼤大きく進歩したJava EE 7の登場
25

式年年遷宮と増改築
§ 数年年に⼀一度度，
いちから作り直す神社
26
あなたのITシステムは
「増築を重ねた温泉旅館」になってませんか？
§ 増築と改築を重ねた
温泉旅館

ITシステムの「式年年遷宮」のすすめ
§ ⼀一定期間毎に，新しいアーキテクチャーで再実装する効果
– 使⽤用しているH/Wやミドルウェアの陳腐化の影響を排除
– 新しいアプリケーション・アーキテクチャーの取り⼊入れ
– 世代を超えてシステムの構築スキル・構成知識識を継承
§ システムの寿命を超えて使い続けると・・・
– ⻑⾧長期延⻑⾧長保守のための⾼高額なサポート費⽤用
– 時代のニーズを満たせない旧式のアプリケーション
– 構築した技術者の引退とともにシステムがブラックボックス化
27

次世代をみすえ最新のアーキテクチャーへの移⾏行行を
§ アプリケーション・アーキテクチャ
– モバイル・HTML5クライアントへの対応
– Microservices Architectureの採⽤用
– APIエコシステムの構築
§ アプリケーション開発体制
– Agile開発・継続的インテグレーション
– DevOpsの実現
§ アプリケーション実⾏行行基盤
– クラウド環境の利利⽤用
– 構築の⾃自動化・Immutable Infrastructure
28

29
Java EE 7とWAS Libertyプロファイル

2013年年に正式版となった最新仕様：Java EE 7
§ Java EE 7の三つのゴール
– HTML5環境への対応
– 開発⽣生産性の向上
– エンタープライズ・ニーズへの対応
30
⼤大幅な機能拡張

Java EE 7 の主なAPI群
§ JSR 342: Java Platform, Enterprise Edition 7
– HTML5環境への対応
•  JSR 344: JavaServer Faces (JSF) 2.2
•  JSR 353: Java API for JSON Processing (JSONP) 1.0
•  JSR 356: Java API for WebSocket 1.0
•  JSR 339: Java API for RESTful Web Services (JAX-RS) 2.0
– 開発生産性の向上
•  JSR 345: Enterprise JavaBeans (EJB) 3.2
•  JSR 346: Contexts and Dependency Injection
for Java EE (CDI) 1.1
•  JSR 907: Java Transaction API (JTA) 1.2
•  JSR 349: Bean Validation 1.1
– エンタープライズ・ニーズへの対応
•  JSR 343: Java Message Service (JMS) 2.0
•  JSR 338: Java Persistence API (JPA) 2.1
•  JSR 236: Concurrency Utilities for Java EE 1.0
•  JSR 352: Batch Applications for the Java Platform 1.0
31

JAX-‐‑‒RS 2.0：JavaでRESTfulなWebサービスを実現
§ アノテーションベースでRESTfulなWebサービスを実装
§ JAX-‐‑‒RS 2.0の新機能
– クライアント⽤用のAPI
– ⾮非同期クライアント・⾮非同期サーバー
– メッセージ・フィルタ
およびエンティティ・インターセプター
•  ヘッダやコンテンツを操作するインターセプター
32
Response response = ClientBuilder.newClient() 
.target("http://www.foo.com/book") 
.request(MediaType.TEXT_PLAIN) 
.get();
@Path("repository")
public class TestRepositoryService {
@Path("version")
@GET
@Produces("text/plain; charset=UTF-8")
public String getVersion() { 
return "Test Service version 1.0"; 
}

CDIによるアプリケーション内のPL / BLの分離離
§ 画⾯面デザイン
– JSF / EL / Servlet / JSP
§ 外部連携
– JAX-‐‑‒RS / WebSocket
– JAX-‐‑‒WS
33
§ 依存性注⼊入・ビジネスロジック
– CDI / EJB / JTA
§ DB連携・ORマッピング
– JPA
JSF
JSP / EL
JAX-RS
WebSocket
CDI 　　　　　　　　　　.
EJB / JTA
JPA Database

CDI使⽤用のメリット
§ 外部接続のパラメーターのハードコーディングの防⽌止
– ネーミングサービス利利⽤用からアノテーション指定へ
§ コンポーネント間の依存性の除去
– モックやスタブを利利⽤用したテストが容易易に
34
@Inject 
Service s;
実際の
サービス実装
テスト⽤用の
スタブ
業務DB
ダミーデータ
本番環境で
インジェクション
テスト環境で
インジェクション

WebSphere Application Server Java EE7対応
§ IBMのWAS Libertyプロファイルは6⽉月25⽇日出荷の
V8.5.5.6でJava EE 7のFull Platformに対応
35
http://www.ibm.com/jp/press/2015/06/1601.html

36
WASの新しいランタイム：Libertyプロファイル
WAS V8.5.5 Liberty & WDT
Java EE 7準拠
Java EE 7のFull Platform標準に
準拠したアプリを完全サポート
JAX-WS, JAX-RS, JMSもサポート
Unzipによる導⼊入とデプロイ
パッケージをした
サーバー + アプリ + 構成情報を
Unzipでデプロイ可能
簡単な構成と動的変更更
最低限必要な構成ファイルは
server.xmlひとつだけ
デフォルトベースで簡単構成
構成変更更は再起動なしに反映
軽量量ランタイム
メモリー使⽤用量量が⼩小さい: 60MB程度度〜～
ディスク使⽤用量量も100MB以下
起動が速い
起動時間: 5秒程度度
統合ツール（WDT)
⾼高機能なEclipse⽤用の連携ツールを無償で提供
Eclipseから簡単に使⽤用可能
⾃自動化ツールとの連携
多くのOSSツールに
無償でプラグインを提供

API・サーバー機能をFeatureとして定義
§  必要なものだけを構成
–  設定されたものだけがメモリにロード・初期化される
→ 最⼩小限の起動時間・メモリー使⽤用
ServletJSPJDBCSSL
JAX-RS
sessionDatabase
<featureManager>

<feature>jsp-‐2.3</feature>

<feature>jdbc-‐4.1</feature>

<feature>jaxrs-‐2.0</feature>

<feature>sessionDatabase-‐1.0</feature>

<feature>ssl-‐1.0</feature>

</featureManager>

構成ファイル server.xml
依存関係も 
自動的に解決
JSON

Libertyプロファイルで提供されているFeature（抜粋）
38
zosSecurity-1.0 zosTransaction-1.0 zosWlm-1.0
zosConnect-1.0
zosLocalAdapters-1.0
scalingController-1.0
scalingMember-1.0
dynamicRouting-1.0
collectiveController-1.0 clusterMember-1.0
mongodb-2.0wsSecurity-1.1
wmqJmsClient-1.1
wasJmsServer-1.0
jmsMdb-3.1
wasJmsClient-1.1jaxws-2.2
jaxb-2.2
wasJmsSecurity-1.0 jca-1.6couchdb-1.0
jcaInboundSecurity-1.6mdb-3.1
jms-1.1
zOS
ND
webProfile-6.0wab-1.0
concurrent-1.0
collectiveMember-1.0
restConnector-1.0
sessionDatabase-1.0
ldapRegistry-3.0
webCache-1.0
jaxrs-1.1
distributedMap-1.0
osgiConsole-1.0
json-1.0
timedOperations-1.0monitor-1.0
oauth-2.0
blueprint-1.0
adminCenter-1.0
openid-2.0
openidConnectServer-1.0
openidConnectClient-1.0
serverStatus-1.0 spnego-1.0
osgiAppIntegration-1.0Core
servlet-3.0
jsp-2.2
jsf-2.0
ejbLite-3.1 jdbc-4.0
jndi-1.0
appSecurity-2.0
managedBeans-1.0
ssl-1.0
beanValidation-1.0
cdi-1.0
jpa-2.0 jsp-2.3
el-3.0
websocket-1.1
jdbc-4.1
servlet-3.1
websocket-1.0
jsonp-1.0
Base
spnego-1.0
osgiAppIntegration-1.0
jsp-2.3
el-3.0
websocket-1.1
jdbc-4.1
zosConnect-1.0
zosLocalAdapters-1.0
scalingController-1.0
scalingMember-1.0
dynamicRouting-1.0
couchdb-1.0
openid-2.0
openidConnectServer-1.0
openidConnectClient-1.0
servlet-3.1
websocket-1.0
jsonp-1.0
New in
1Q15
New in
4Q14

パッケージ作成による複数環境の導⼊入
§ 開発環境でテストしたアプリケーションだけでなく
製品の構成・Fixpackレベルまでふくめて
そのまま本番環境へ移⾏行行することが可能
– サービス単位でZIPを作成
– 使⽤用するFeatureだけパッケージされるので最⼩小サイズのZIPに
– 必要に応じて展開・実⾏行行することで容易易にスケールアウト
39
開発環境
Java SDK
Liberty Profile
サーバー構成
アプリ
①インストール
ディスク
②サーバー構成
③アプリ開発
テスト・本番環境
Java SDK
Liberty Profile
サーバー構成
アプリ
ディスク
ZIPファイル
④パッケージ ⑤展開

Libertyとマイクロサービスの記事を公開中
§ JAX-‐‑‒RS/CDIのサポートで
マイクロサービスの
開発も容易易に
〜～Java EE 7正式対応で
　⼤大幅強化された
　「WebSphere Application
　　Server Liberty Core」
§ Codezine マイクロサービス
で検索索
40
http://codezine.jp/article/detail/8834

41

エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4

Similar to エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4 (20)

More from Takakiyo Tanaka

More from Takakiyo Tanaka (14)

エンタープライズJava環境におけるマイクロサービス・アーキテクチャーの必要性 #natsumiB4