1. A-3 今どきのアーキテクチャ設計戦略
2016/10/24
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
Qcon Tokyo 2016

2. 自己紹介
鈴木雄介
• グロースエクスパートナーズ（株）
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
• SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1

3. アジェンダ
• 今どきのシステム開発
• アーキテクチャ設計基礎
• 今どきのアーキテクチャ設計
• マイクロサービスアーキテクチャ
• アーキテクトの役割
• まとめ
2

4. 今どきのシステム開発
3

5. 4https://www.flickr.com/photos/iansand/5920421391/https://www.flickr.com/photos/peaceful-jp-scenery/16346037831/

6. 今どきのシステム開発
企業システムの類型化
• SoR（System of Record）
»情報を正しく「記録」するためのシステム
»ユーザーは従業員が中心。取引情報を長期間にわたって保持し、
ビジネスの基幹となるシステム
»変更頻度は低め、システム障害影響大
• SoE（System of Engagement）
»顧客や取引先との「絆」を作るためにシステム
»最新の状況を表示し、判断を行ってもらう。機能はユーザーごと
に最適化され、高頻度で改善されていく
5AII.orgでのレポート「Systems of Engagement and the Future of Enterprise IT」2011 by Geoffrey Moore

7. 今どきのシステム開発
正しい仕様を定義できないシステム開発
• SoE型には「正しい仕様」は存在しない
»社内に”本当のユーザー”がいないため、誰にも正解が分からない
»外部環境の”想定しない変化”に合わせていく必要がある
• 仮説検証型の進め方にするしかない
»「仮説としての仕様」からはじめる
»あとは状況に応じて対応をしていく
6

8. 今どきのシステム開発
一方で、企業システムとしての制約
• SoEはSoRと必ず連携する
»基幹システム側は期日ありきで計画主導プロセス
• 社内部門/業務と必ず関わりがある
»多くのビジネスはITだけで完結しない
▸事業計画、教育コスト、部門間調整、稟議…
• ビジネスは簡単に止められない
»社会インフラに近いほど「止まっては困る」
7

9. 今どきのシステム開発
フィードバックと改善
• SoEではフィードバックと改善のリズムを作ることが大事
»リズムの速さは「ビジネスによる」で問題ない
»1日ごと、2週間ごと、3ヶ月ごと、半年ごと
• どうやって継続的に機能を追加していくのか
»アジャイルかウォーターフォールか、の議論ではない
»「時間制限の中でやる仕事」と「終わるまでやるべき仕事」
8

10. アーキテクチャ設計基礎
9

11. アーキテクチャ設計基礎
アーキテクチャ＝システムの分け方と組み方
• アーキテクチャとは
»システムのミッションに従い、
»システムのおかれた制約を前提としながら
»システムに関わる複数の利害関係者の関心事を整合させ、
▸経営者、オーナー、ユーザー、PM、開発メンバ、保守メンバ…
»ライフサイクル（設計から保守）まで意識した
»システムの分け方と組合せ方のこと
10

12. 11
http://www.wisskab.com/objekte06.php
Franz Reuleaux (1829-1905)

13. 12
http://www.museum.kyoto-u.ac.jp/collection/materials/mech18.html
京都大学総合博物館 アニメーションで見る機械メカニズム模型の動き
遊星歯車応用の回転運動から直線運動への変換機構

14. 「振る舞い」と「構造」
アーキテクチャ設計基礎
13
IT
サービス
振る舞い
機能
非機能
構造
動的
構造
静的
構造

15. アーキテクチャ設計基礎
「振る舞い」と「構造」
• 振る舞い
»機能：システムが外部に向けてどういった挙動をするか
▸インプットに対するアウトプット
»非機能：挙動の「質」（早く、確実に、安全に、わかりやすく）
• 構造
»動的構造：振る舞いを実現する時間軸の中での仕組み
»静的構造：振る舞いを実現する空間配置の中での仕組み
14

16. アーキテクチャ設計基礎
アーキテクチャ設計
• ある振る舞いを実現する構造を導く作業
»「振る舞いへの要求」に従って構造を定義する
»「システムの設計や実装」は定義された構造に従って行われる
• 構造は事前的に定義される
»後から想定範囲外への変更することは非常に困難
15

17. アーキテクチャ設計基礎
システム開発のプロセス
16
振る舞い
への要求
アーキテクチャ
設計
システム
設計
システム
実装
システム
テスト
振る舞いの
外部定義
振る舞い
理解構造
定義
定義
実現

18. アーキテクチャ設計基礎
アーキテクチャ設計の（理想的な）進め方
• 必要な振る舞いを定義し、それに対応する構造を設計する
»振る舞いが正確に定義できているほど、適切な設計を行える
• 実装が始まる前までに、すべての要求が明確で、それに対
して最適な構造が定義される
17

19. 今どきのアーキテクチャ設計
18

20. 今どきのアーキテクチャ設計
アーキテクチャ設計のジレンマ
19
振る舞い
への要求
振る舞い構造
要求が曖昧では
構造を定義できない
振る舞いを見ないと
要求が分からない
構造がないと
振る舞いを実現できない

21. 今どきのアーキテクチャ設計
アーキテクチャ設計のジレンマ
• SoEでは正しい要求が先にない
»正しい要求は「フィードバックと改善」で導かれる
»そのためには動くソフトウェアが必要
»動くソフトウェアを作るためには構造が必要
»構造を決めるには正しい要求が必要
20

22. 今どきのアーキテクチャ設計
変更に対応する構造を作れるか？
• もはや初期段階で最適な構造を確定できないことが前提
»とはいえ「流行のフレームワークでいい」ではない
• 必要な機能が段階的に足されていく
»新たな機能は既存の構造が最適ではないかもしれない
• なんらかのアーキテクチャ設計戦略が必要になる
»予測型、犠牲型、拡張型
21

23. アーキテクチャ設計戦略
予測型
• 追加される機能に対して同一の構造を割り当てる
• 最も効率的（※予測が正しければ）
22
機能A
構造
機能A
構造
機能B 機能C

24. アーキテクチャ設計戦略
予測増改築型
• 予測型を長期間維持してこじらせたパターン
• 保守性が悪く、コストが増加する（別名：温泉旅館型）
23
機能A
構造
機能A
機能B
機能C
構造

25. アーキテクチャ設計戦略
犠牲型
• 最初に作る構造は最低限にしておき、のちに再整備する
• 機能移植にコストはかかるが長期保守にメリット
24
機能A
構造1
機能A 機能B 機能C
構造2構造1
機能A
技術的負債

26. アーキテクチャ設計戦略
拡張型
• 構造そのものに拡張性を持たせる
• （※天才に限る）
25
機能A
基本構造
構造1
機能A
構造2
機能B 機能C
基本構造
構造1

27. アーキテクチャ設計戦略
設計戦略の整理
• そもそも「予測型」には限界がある
»特にSoE型では予測が困難になってきている
• いつでも「犠牲型」になる覚悟は必要
»ただし、すべてに対して前提にするのは困難
• 「拡張型」をベースにしていく
»あくまでも自分で作らず、他人が作った拡張構造を利用する
▸オープンソースやクラウドサービス
26

28. アーキテクチャ設計戦略
他人が作った拡張構造に頼る
• オープンソースのフレームワークを利用する
»優秀なOSSは「拡張可能な構造」を備えている
»パターンに従って実装することで構造が拡張される
• コミュニティが蓄積しているノウハウに頼る
»他の製品がベースにするような製品を選ぶ
»設定ファイル＋クラス構造のパターン化
27

29. Spring Security
• 認証と認可についての基本
的な考え方が整理されてお
り、これを拡張すれば独自
機構を提供できる
»AuthenticationManager
»AuthenticationProvider
»UserDetailsService
» WebSecurityConfigurerAdapter
»AsyncConfigurerSupport
28
Figure 1. An AuthenticationManager hierarchy using ProviderManager
https://spring.io/guides/topicals/spring-security-architecture/

30. アーキテクチャ設計戦略
他人が作った拡張構造に頼る
• クラウドサービスを利用する
»利用すべきはPaaS（Platform as a Service）
»パターンに従って実装することで構造が拡張される
• 構造だけではなく非機能要件まで含めて構造が保証する
»PaaSの進化
▸ミドルウェアレベル：データベースサービス
▸システムレベル：Webアプリケーション構成サービス、構成管理サービス
29

31. サーバレスアーキテクチャ
• コードを配置するだけで実行される
»AWS Lambda：Node.js、Java、Python
»Azure Functions：JavaScript、C#、Python、PHP
• 特性
»インフラのマネジメント不要でオートスケール
»ステートレスなイベント駆動
▸タイマー、Webトリガー、データトリガー、メッセージトリガー…
»処理内容には制約がある
▸PaaSの他のサービスに対する操作であればサポートされている
30

32. 今どきのアーキテクチャ設計
機能ごとに最適な構造を用意するのは無駄か？
• 技術の成熟に伴い、ニッチな構造が増えている
• 例えば
»ビックデータ：大規模分散処理
»リアルタイム処理：ストリームプロセッシング
»スケールするデータストア：NoSQLデータベース
»検索：検索エンジン（インデクサー）
• すべてオープンソースでもPaaSでも利用可能
31

33. アーキテクチャ設計戦略
拡張型×犠牲型
• 基本構造を変えずに、必要な機能に応じて構造を導入する
• 場合によっては犠牲にする構造もあってよい
32
機能A
構造2
機能B
構造1
基本構造
基本構造
機能A
構造2
機能B 機能C
構造1
構造3 構造4
機能A+
基本構造

34. アーキテクチャ設計戦略
その集大成がマイクロサービス
• マイクロサービスアーキテクチャ（MSA）
• ※とはいえ成熟の途中（特に企業システムとしては）
33
PaaS
ｻｰﾋﾞｽA
構造2
ｻｰﾋﾞｽB ｻｰﾋﾞｽC
構造1
構造3 構造4
ｻｰﾋﾞｽ
A+
クラウドサービス
システム

35. マイクロサービスアーキテクチャ
34

36. マイクロサービスアーキテクチャ
簡単な概要
• システム全体をサービスの組み合わせで実現する
»（小さな）サービスによって（大きな）サービスを動かす
»サービス同士はAPI/メッセージで連携する
• サービスの単位でチームが分割される
»チームが複数のサービスを管理しても良い
35

37. マイクロサービスアーキテクチャ
メリット
• モノリシックなシステムでは変更が全体に影響する
»影響調査とリグレッションテストで工数の大半が消える
• サービス同士が疎結合なら変更の影響が全体に及ばない
»チーム/サービスごとに好きなリズムでリリースしてよい
• サービスごとに構造と非機能要件を変えてよい
»例：サービスによって性能特性を変えられる
36

38. カナリアリリース
37
Web App DB
ルーター100
100
Web App DB

39. カナリアリリース
38
Web App DB
ルーター100
100
Web App DB

40. カナリアリリース
39
Web App DB
ルーター100
95
Web App DB
5

41. カナリアリリース
40
Web App DB
ルーター100
100
Web App DB

42. カナリアリリース
41
ルーター100
100
Web App DB

43. マイクロサービスアーキテクチャ
いかにサービスを管理するのか
• なぜ分けるか、どう分けるかの議論は終わりつつある
»ドメインは重要だが、正解がない
• 数が多くなったサービスをどう管理していくのか？
»Netflixのトップページでは500個のサービスが動く
▸1サービス10インスタンスなら、5000インスタンス
▸Amazonは700-800個
»分けた場合のデメリットをどう減らしていくのか
42

44. マイクロサービスアーキテクチャ
疎結合を維持する戦略
43

45. マイクロサービスアーキテクチャ
疎結合を維持する戦略
• データ分離
• テスト戦略
• 不整合の許容
44

46. データ分離
• データの共有を疎結合化していく
»データの同期タイミングとサイズに注意
»巨大データをリアルタイムに共有したいなら共有データしかない
»通常、2フェーズコミットは避ける
45
ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽB
共有データ ビュー トリガー/ストアド
ｻｰﾋﾞｽA ｻｰﾋﾞｽB
ETL

47. • イベントソーシング
»データのステートではなくデータへのイベントを共有する
»CQRS/コマンドクエリ責務分離
▸コマンド：更新などのロジックを含む処理
▸クエリ：検索などの単純な処理
ｲﾍﾞﾝﾄ
ｽﾄｱ
データ分離
46
ｻｰﾋﾞｽA ｻｰﾋﾞｽB
ｽﾃｰﾄ
イベントソーシング

48. テスト戦略
• Test Doubles
»本物を動かすのが大変なのでスタブやモックを使ってテストする
»コンシューマー側でプロバイダの想定する挙動を実装し、それを
使ってテストする
»プロバイダの変更が発生するとモックの変更が必要になる
47
ｻｰﾋﾞｽA
ｻｰﾋﾞｽB
のﾓｯｸ

49. テスト戦略
• Dark Canaries
»本番環境上に開発者しかアクセスできないテスト版をリリース
»本物を使ってテストする（ただし、できないものもある）
48
ｻｰﾋﾞｽA ｻｰﾋﾞｽB
ｻｰﾋﾞｽA
ﾃｽﾄ版

50. テスト戦略
• Consumer-Driven Contract testing
»コンシューマーが要求するAPI挙動を契約として定義し、プロバ
イダが契約を検証して破壊的変更を防ぐ
49
ｻｰﾋﾞｽA
ｻｰﾋﾞｽB
契約
ｻｰﾋﾞｽB
契約
ｻｰﾋﾞｽC
ｻｰﾋﾞｽB

51. 不整合の許容
• 「Amazonのクーポン」
• 非同期メッセージによる不整
合を許容する
»サービス間の疎結合を重視する
»運用でリカバリするほうがメリ
ットが大きい
50

52. マイクロサービスアーキテクチャ
リジリエンスの確保
51

53. マイクロサービスアーキテクチャ
リジリエンスの確保
• サービスの集中管理
»設定の集中管理、知的なルーター、非同期メッセージング
• 階層型障害への対応
»サーキットブレーカー、分散トレース
»障害注入テスト
52

54. 設定の集中管理
• 環境依存するような設定情報を各サービスが取得する
»設定ファイルを配置するのではなくネットワーク経由で取得する
53
設定
ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC
①起動時に設定を取得

55. 知的なルーター
• 知的なルーターによるサービスの発見とルーティング
»新しく起動したサービスは自分の居場所を自分で登録する
»レジストリに問合せてサービスを発見し、ルーティングする
54
ｻｰﾋﾞｽA
レジストリ
ルーター
ｻｰﾋﾞｽA
ｻｰﾋﾞｽA
①自分自身の登録
②リクエスト
③サービスの発見

56. 非同期処理
• メッセージキューによる処理の分離
»答えを待たずに処理を非同期に行うようにする
▸パブリッシュ/サブスクライブ型もサポート
»機能同士の非機能を分離することができる
55
ｻｰﾋﾞｽA ｻｰﾋﾞｽB
ｻｰﾋﾞｽA ｻｰﾋﾞｽBｷｭｰ
同期型
非同期型
ｻｰﾋﾞｽA
ｻｰﾋﾞｽB
ｷｭｰ
Pub/Sub型
ｻｰﾋﾞｽC
ｻｰﾋﾞｽD

57. サーキットブレーカー
• 階層型障害への対応
»自分の身は自分で守る
• 異常処理への対応
»通信エラーが発生しても機能Bが返事をしたように振る舞う
»タイムアウト/リトライの自動化
»値のキャッシュ
56
機能B
ｻｰｷｯﾄ
ﾌﾞﾚｰｶｰ
機能A
ｴﾗｰ処理

58. 分散トレース
• サービスを横断したリクエストのトレース
»リクエストやサービス間通信にIDを発行する
»各サービスからはログ基盤にログを送信する
• ログ分析
»ログを検索し、処理の流れ視覚化する
»メトリクスツールとしての応用
57
ログ基盤
ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC
ログ検索

59. 障害注入テスト
• Chaos Monkey
»Failure Injection Testing（障害注入テスト）
»平日日中にサーバをランダムにダウンさせるためのOSS
▸Netflixではインスタンスは毎週、アベイラビリティゾーンあるいはリージ
ョン丸ごとは毎月障害
58

60. マイクロサービスアーキテクチャ
マイクロサービス向け製品
• 例：Spring Cloud
»設定の集中管理：Spring Cloud Config
»知的なルーター：Netflix Zuul、Netflix Ribbon、Netflix Eureka
»非同期メッセージング：Spring Cloud Stream
»サーキットブレーカー：Netflix Hystrix
»分散トレース ：Spring Cloud Sleuth
59

61. マイクロサービスアーキテクチャ
ツール群
60

62. マイクロサービスアーキテクチャ
ツール群
• CI/CDツール群
»サービスの構成と自動リリースを管理するための仕掛け
»＋インフラ構成管理ツール
»＋コンテナ（Docker）
▸ミドルウェア構成のバージョン管理
• メトリクスツール
»ヘルスチェックやログ分析の延長としての仮説検証ツール
61

63. CI/CDツール群
• Continues Integration、Deployment、Delivery
»チケット管理、ソースコード管理、CI/CDツールを含む
▸ドキュメント管理、チャットツールなど
62
Git サーバ
V1.1
チケット
管理 V1.1
チケットA
チケットB
サーバ
V1.1
V1.0
CI/CDツール
ｺｰﾄﾞ
V1.1
ｻｰﾊﾞ構成
ﾚﾎﾟｼﾞﾄﾘ
ｻｰﾊﾞ設定

64. マイクロサービスアーキテクチャ
CI/CD開発ツール群
• 例：Atlassian（アトラシアン）
»課題管理：JIRA
»ソースコード管理：Bitbucket
»CI/CDツール：Bamboo
»ドキュメント管理：Confluence
»チャットツール：HipChat
63

65. マイクロサービスアーキテクチャ
エンタープライズ適用
64

66. エンタープライズ適用
“マイクロサービス”にこだわりすぎない
• 本質：サービス同士を疎結合にして個別変更を許容する
»適切な技術を適切な機能で利用するため
»サービスの大きさを気にしすぎない
• 対象は「システム全体」であるべき
»1つのアプリケーションをマイクロサービスにしても意味が無い
65

67. エンタープライズ適用
品質の考え方について整理すること
• サービス全体を保護するために小さな障害を許容する
»日中リリース、障害注入テスト、イベントソーシング…
• 「小さな障害」を許容できるかどうかはドメインによる
»マイクロサービスだから障害を許容していいわけではない
»ただ、企業システムの中でも許容できるものもあるはず
66

68. エンタープライズ適用
明日からでも始めるべき
• 今のシステムから1つ目のサービスを切り出せるか
»少しずつマイクロサービス化していくことが重要
»マイクロサービスの戦略、プラットフォーム、ツールも段階的に
導入していく
• 「マイクロサービスで全体再構築」はうまくいかない
»アジャイル、DevOps、クラウド、マイクロサービスプラットフ
ォームに習熟する期間が必要
67

69. アーキテクトの役割
68

70. アーキテクトの役割
プラットフォームの選択は重要
• プラットフォームの選択は重要
»拡張可能でありながら、無駄のない仕組みであるかどうか
»依存することへの功罪を考える
▸あんなにマイクロソフトは嫌だったのに、Amazonならいいのか？
• 自らのドメインに適用できるか？
»「流行している」で導入するのは危険
»ドメインのFit&Gapこそが最大の役割
69

71. アーキテクトの役割
アーキテクトがいるのは塔か現場か
• 塔の上から俯瞰する vs 現場で最適なものを作る
»象牙の塔では困るがプラットフォームの採用には全体視点が必要
»チーム（現場）にはプラットフォームから上を権限委譲する
70
PaaS
ｻｰﾋﾞｽA
構造2
ｻｰﾋﾞｽB ｻｰﾋﾞｽC
構造1 構造3
クラウドサービス
MSA用プラットフォーム
各種のツール群
プラットフォームのアーキテクト
各サービスの専門アーキテクト

72. まとめ
71

73. まとめ
フィードバックと改善
• 企業システムはSoRとSoEに分離していく
• SoEでは「フィードバックと改善」が重要
»リズムは最適なものを選べばいい
• 段階的に機能が追加されていく
72

74. まとめ
アーキテクチャ設計戦略
• 段階的な機能拡充に合わせて構造も拡充する
»もはやアーキテクチャを初期に完成させるのは無理
• そのためのアーキテクチャ設計戦略
»予測型、犠牲型、拡張型
• 特に重要なのは拡張型
»他人が作った拡張構造をうまく活用しよう
▸オープンソース製品、クラウドサービス
73

75. まとめ
プラットフォームの時代
• プラットフォームをいかに利用するか
»オープンソースやクラウドサービス
»目的やパターンを理解し、独自に拡張していく
• 特にMSA用プラットフォームは成長期
»企業システムでも参考になるアイデアがある
74

76. お知らせ
もう少し全体感が知りたいなら
• Cloud First Architecture 設計ガイド
» 第1章 クラウドファーストの意味
» 第2章 クラウド技術の構成
» 第3章 クラウドファーストに至るまでの歴史
» 第4章 エンタープライズとクラウドファースト
» 第5章 アーキテクチャー設計ガイド
» 第6章 クラウドファーストにおけるエンジニア
https://www.amazon.co.jp/dp/4822237818
75