20150421 QCon Tokyo 2015 Azureが切り開く新時代のソフトウェア開発・設計

Azureが切り開く新時代のソフトウェア開発・設計

株式会社ネクストスケープ

上坂貴志

2015/4/21

QCon Tokyo[B6-2]

自己紹介

上坂貴志（うえさかたかし）

株式会社ネクストスケープ

エヴァンジェリストアーキテクトScrumMaster

東京出身、43歳

最近の話題

今更Androidに入門、IoTおもしろい

目がけいれんする、揚げ物食べられない辛さ

2015 02 デブサミ登壇2015 02 SanSan勉強会発表

最近記事書いてないなー書く暇ないなー

会社紹介

配信ソリューション

Microsoft Azure導入支援

DRMソリューション(PlayReady)

システム・インテグレーション

Sitecore(CMS)導入支援

Microsoft Azure パートナーアワード SI部門

3年連続受賞

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

26.7％

31.1%

75.0%

今のIT業界

新規システムの導入・開発プロジェクトの成功率。

2003年

2008年

2014年

出典：日経コンピュータ

システムは劣化していく

大事なこと＝運用を開始してから

でもどんどん壊れていく

伝家の宝刀、サーバのEOS・・・

でも時代は変わった！

クラウドの登場

スケールアップ＝後からのサーバー増強が可能

スケールアウト＝後から大量処理が可能

膨大なストレージ

サーバのEOSはもうない！

Windows 2008 Server 2008～2020

Windows 2012 Server 2012～2023

Windows Server vNext 2015?～

※Windows Server の EOS

MicroServices

長く使い続けるシステムを構築するために

MicroServicesは解のひとつ

• ９つの特性（今日は解説しない）

１．システムを独立したサービスに分割

２．サービス毎に適切なプラットフォームや技術の採用

３．各サービスごとにデータを管理

４．サービスが落ちてもシステムは落とさない

５．サービスは交換可能

今日注目する特性

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

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

思ったよりサービスが大きかったみたい。役割が

多い

他と重複してる箇所がある

汎用性が大事！（予想以上に時間かかる）

どういう指針で分割したらいいのかよくわからない。サブシステム的な？とりあえずやってみる。

汎用性大事！（やっぱり時間かかる）

まずい、思ったより実装量が多い

もう一周・・・できる？

スケジュール延びる開発費膨らむ

Icon made by Freepik from www.flaticon.com

システムを分割

IF設計する

実装

あれなんか違う

仕方がない、一部は再設計だ

サービス分割の難しさ＝SOA失敗の一因

商品管理システム

Domain Driven Design

一つの指針＝「境界付けられたコンテキスト」

在庫 出荷

ドメイン問題領域

在庫コンテキスト

在庫

出荷コンテキスト

出荷

認証

コンテキスト解決領域

認証コンテキスト

認証巨大な泥団子

（サービス毎の）2.適切なプラットフォームや技術

3.データを管理

（サービス毎に）2.適切なプラットフォームや技術

サービス毎に最適なものを

大量の同時リクエスト＝Node.js

高速レスポンスのストレージ＝NoSQL

分析集計ドメイン＝RDBMS

例えば。

一人じゃ無理！＝社内に選任チームが必要

（サービス毎に）3.データの管理

各サービスがデータを持つ

データの連携にはイベント駆動アーキテクチャ

買い物サービス 請求サービス

ユーザーサービス

event raise

上顧客ユーザ↓

一般ユーザ

割引ユーザ↓

定価ユーザ

業務ロジック起動

サービス間のイベント駆動の課題

データ変更側（イベント発火側）

データ同期側（イベント通知側）

• リクエストの到達• リクエストの処理状態

• リクエストの正当性• 処理対象判定• 冪等性

イベント＝非同期通信

Reactive Programming

よく言われる例：Excelのセル参照

対象A

対象B

監視役Observable

通知受け取り役Observer

Push!

変更を監視

Reactive Programming

Aサービス

Bサービス

ドメインイベント発火

時間

時間

データ変更

監視役Observable

通知受け取り役Observer

Push!

イベントを監視

サービス間のイベント駆動の実装に最適

.NETならもっと簡単！Task-based Asynchronous Pattern

async, await

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

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

巨大な泥団子

マイクロサービス

システム継続利用＝キャッシュの利用

サービス復活への対応

Retry CircuitBreaker Scheduler Agent Supervisor

5.サービスは交換可能

サービスは交換可能

Aサービス

Cサービス

新Bサービス

犠牲的アーキテクチャの適用

メリット汎用性の削除＝無駄が無くなる

トレンドにあった作り直し

デメリット やりすぎると、システム劣化が早まる

Bサービス

Azure

Azure と MicroServices

Api Apps のリリース(2015/3/24)

Azure上でREST のWebApiアプリをホスト

スケーリング対応

ASP.NET、Java、PHP、Node.js、または Pythonを使用可能

公開用のメタデータはSwagger 2.0 (http://swagger.io/)

アクセス制御機能

MarcketPlaceへの公開

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

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

システムの寿命：Webサービスだけじゃない

これからの指標：成功率 生存率(5年、10年)

最後のハードル：サービス単位のチーム

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