QCon Tokyo 2015に登壇した時の資料です。

1. Azureが切り開く
新時代のソフトウェア開発・設計
株式会社ネクストスケープ
上坂貴志
2015/4/21
QCon Tokyo[B6-2]

2. 自己紹介
上坂貴志（うえさかたかし）
株式会社ネクストスケープ
エヴァンジェリスト
アーキテクト
ScrumMaster
東京出身、43歳
最近の話題
今更Androidに入門、IoTおもしろい
目がけいれんする、揚げ物食べられない辛さ
2015 02 デブサミ登壇
2015 02 SanSan勉強会発表
最近記事書いてないなー書く暇ないなー

3. 会社紹介
 配信ソリューション
 Microsoft Azure導入支援
 DRMソリューション
(PlayReady)
 システム・インテグレー
ション
 Sitecore(CMS)導入支援
Microsoft Azure パートナー アワード SI部門
3年連続受賞

4. なぜ新しい手法が必要なのか

5. 26.7％
31.1%
75.0%
今のIT業界
新規システムの導入・開発プロジェクトの成功率。
2003年
2008年
2014年
出典：日経コンピュータ

6. システムは劣化していく
大事なこと＝運用を開始してから
でもどんどん壊れていく
伝家の宝刀、サーバのEOS・・・

7. でも時代は変わった！
クラウドの登場
スケールアップ＝後からのサーバー増強が可能
スケールアウト＝後から大量処理が可能
膨大なストレージ
サーバのEOSはもうない！
Windows 2008 Server 2008～2020
Windows 2012 Server 2012～2023
Windows Server vNext 2015?～
※Windows Server の EOS

8. MicroServices

9. 長く使い続けるシステムを構築するために
MicroServicesは解のひとつ
• ９つの特性（今日は解説しない）
１．システムを独立したサービスに分割
２．サービス毎に適切なプラットフォームや技術の採用
３．各サービスごとにデータを管理
４．サービスが落ちてもシステムは落とさない
５．サービスは交換可能
 今日注目する特性

10. 1.独立したサービスに分割

11. 1.独立したサービスに分割
思ったよりサービスが大
きかったみたい。役割が
多い
他と重複してる箇所が
ある
汎用性が大事！
（予想以上に時間かかる）
どういう指針で分割したらいいの
かよくわからない。サブシステム
的な？とりあえずやってみる。
汎用性大事！
（やっぱり時間かかる）
まずい、思ったより実装量
が多い
もう一周・・・できる？
スケジュール延びる
開発費膨らむ
Icon made by Freepik from www.flaticon.com
システム
を分割
IF設計する
実装
あれな
んか違う
仕方がない、一部は
再設計だ
サービス分割の難しさ＝SOA失敗の一因

12. 商品管理システム
Domain Driven Design
一つの指針＝「境界付けられたコンテキスト」
在庫 出荷
ドメイン
問題領域
在庫コンテキスト
在庫
出荷コンテキスト
出荷
認証
コンテキスト
解決領域
認証コンテキスト
認証
巨大な泥団子

13. （サービス毎の）
2.適切なプラットフォームや技術
3.データを管理

14. （サービス毎に）
2.適切なプラットフォームや技術
サービス毎に最適なものを
大量の同時リクエスト＝Node.js
高速レスポンスのストレージ＝NoSQL
分析集計ドメイン＝RDBMS
例えば。
一人じゃ無理！＝社内に選任チームが必要

15. （サービス毎に）
3.データの管理
各サービスがデータを持つ
データの連携にはイベント駆動アーキテクチャ
買い物サービス 請求サービス
ユーザーサービス
event raise
上顧客ユーザ
↓
一般ユーザ
割引ユーザ
↓
定価ユーザ
業務ロジック起動

16. サービス間のイベント駆動の課題
データ変更側
（イベント発火側）
データ同期側
（イベント通知側）
• リクエストの到達
• リクエストの処理状態
• リクエストの正当性
• 処理対象判定
• 冪等性
イベント＝非同期通信

17. Reactive Programming
よく言われる例：Excelのセル参照
対象A
対象B
監視役
Observable
通知受け取り役
Observer
Push!
変更を監視

18. Reactive Programming
Aサービス
Bサービス
ドメインイベント発火
時間
時間
データ変更
監視役
Observable
通知受け取り役
Observer
Push!
イベントを監視
サービス間のイベント駆動の実装に最適
.NETならもっと簡単！
Task-based Asynchronous Pattern
async, await

19. 4.サービスが落ちてもシステム
は落とさない

20. 4.サービスが落ちてもシステムは落とさない
巨大な泥団子
マイクロサービス
システム継続利用＝キャッシュの利用
サービス復活への対応
Retry CircuitBreaker Scheduler Agent Supervisor

21. 5.サービスは交換可能

22. サービスは交換可能
Aサービス
Cサービス
新Bサービス
犠牲的アーキテクチャの適用
メリット
汎用性の削除＝無駄が無くなる
トレンドにあった作り直し
デメリット やりすぎると、システム劣化が早まる
Bサービス

23. Azure

24. Azure と MicroServices
Api Apps のリリース(2015/3/24)
Azure上でREST の WebApiアプリをホスト
スケーリング対応
ASP.NET、Java、PHP、Node.js、または Pythonを使用可能
公開用のメタデータはSwagger 2.0 (http://swagger.io/)
アクセス制御機能
MarcketPlaceへの公開

25. 新時代のソフトウェア開発・設計
とは？

26. 新時代のソフトウェア開発・設計とは
システムの寿命：Webサービスだけじゃない
これからの指標：成功率 生存率(5年、10年)
最後のハードル：サービス単位のチーム

27. ご清聴ありがとうございました