今どきのアーキテクチャ設計戦略 - qcon tokyo 2016

A-3 今どきのアーキテクチャ設計戦略

2016/10/24

鈴木雄介グロースエクスパートナーズ株式会社執行役員

日本Javaユーザーグループ会長

Qcon Tokyo 2016

自己紹介

鈴木雄介• グロースエクスパートナーズ（株）

»執行役員/アーキテクチャ事業本部長

» http://www.gxp.co.jp/

• 日本Javaユーザーグループ

»会長

» http://www.java-users.jp/

• SNS

» http://arclamp.hatenablog.com/

»@yusuke_arclamp

1

アジェンダ

•今どきのシステム開発

•アーキテクチャ設計基礎

•今どきのアーキテクチャ設計

•マイクロサービスアーキテクチャ

•アーキテクトの役割

•まとめ

2

今どきのシステム開発

3

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

https://www.flickr.com/photos/iansand/5920421391/

https://www.flickr.com/photos/peaceful-jp-scenery/16346037831/


企業システムの類型化• SoR（System of Record）»情報を正しく「記録」するためのシステム

»ユーザーは従業員が中心。取引情報を長期間にわたって保持し、ビジネスの基幹となるシステム

»変更頻度は低め、システム障害影響大

• SoE（System of Engagement）»顧客や取引先との「絆」を作るためにシステム

»最新の状況を表示し、判断を行ってもらう。機能はユーザーごとに最適化され、高頻度で改善されていく

5AII.orgでのレポート「Systems of Engagement and the Future of Enterprise IT」2011 by Geoffrey Moore


正しい仕様を定義できないシステム開発• SoE型には「正しい仕様」は存在しない

»社内に”本当のユーザー”がいないため、誰にも正解が分からない

»外部環境の”想定しない変化”に合わせていく必要がある

•仮説検証型の進め方にするしかない

»「仮説としての仕様」からはじめる

»あとは状況に応じて対応をしていく

6


一方で、企業システムとしての制約• SoEはSoRと必ず連携する

»基幹システム側は期日ありきで計画主導プロセス

•社内部門/業務と必ず関わりがある

»多くのビジネスはITだけで完結しない

▸事業計画、教育コスト、部門間調整、稟議…

•ビジネスは簡単に止められない

»社会インフラに近いほど「止まっては困る」

7


フィードバックと改善• SoEではフィードバックと改善のリズムを作ることが大事

»リズムの速さは「ビジネスによる」で問題ない

»1日ごと、2週間ごと、3ヶ月ごと、半年ごと

•どうやって継続的に機能を追加していくのか

»アジャイルかウォーターフォールか、の議論ではない

»「時間制限の中でやる仕事」と「終わるまでやるべき仕事」

8

アーキテクチャ設計基礎

9


アーキテクチャ＝システムの分け方と組み方•アーキテクチャとは

»システムのミッションに従い、

»システムのおかれた制約を前提としながら

»システムに関わる複数の利害関係者の関心事を整合させ、

▸経営者、オーナー、ユーザー、PM、開発メンバ、保守メンバ…

»ライフサイクル（設計から保守）まで意識した

»システムの分け方と組合せ方のこと

10

11http://www.wisskab.com/objekte06.phpFranz Reuleaux (1829-1905)

http://www.wisskab.com/objekte06.php

12

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

http://www.museum.kyoto-u.ac.jp/collection/materials/mech18.html

「振る舞い」と「構造」


13

ITサービス

振る舞い

機能

非機能

構造

動的構造

静的構造


「振る舞い」と「構造」•振る舞い

»機能：システムが外部に向けてどういった挙動をするか

▸インプットに対するアウトプット

»非機能：挙動の「質」（早く、確実に、安全に、わかりやすく）

•構造

»動的構造：振る舞いを実現する時間軸の中での仕組み

»静的構造：振る舞いを実現する空間配置の中での仕組み

14


アーキテクチャ設計•ある振る舞いを実現する構造を導く作業

»「振る舞いへの要求」に従って構造を定義する

»「システムの設計や実装」は定義された構造に従って行われる

•構造は事前的に定義される

»後から想定範囲外への変更することは非常に困難

15


システム開発のプロセス

16

振る舞いへの要求

アーキテクチャ設計

システム設計

システム実装

システムテスト

振る舞いの外部定義

振る舞い

理解構造定義

定義

実現


アーキテクチャ設計の（理想的な）進め方•必要な振る舞いを定義し、それに対応する構造を設計する

»振る舞いが正確に定義できているほど、適切な設計を行える

•実装が始まる前までに、すべての要求が明確で、それに対して最適な構造が定義される

17

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

18


アーキテクチャ設計のジレンマ

19

振る舞いへの要求

振る舞い構造

要求が曖昧では構造を定義できない

振る舞いを見ないと要求が分からない

構造がないと振る舞いを実現できない


アーキテクチャ設計のジレンマ• SoEでは正しい要求が先にない

»正しい要求は「フィードバックと改善」で導かれる

»そのためには動くソフトウェアが必要

»動くソフトウェアを作るためには構造が必要

»構造を決めるには正しい要求が必要

20


変更に対応する構造を作れるか？•もはや初期段階で最適な構造を確定できないことが前提

»とはいえ「流行のフレームワークでいい」ではない

•必要な機能が段階的に足されていく

»新たな機能は既存の構造が最適ではないかもしれない

•なんらかのアーキテクチャ設計戦略が必要になる

»予測型、犠牲型、拡張型

21

アーキテクチャ設計戦略

予測型•追加される機能に対して同一の構造を割り当てる

•最も効率的（※予測が正しければ）

22

機能A

構造

機能A

構造

機能B 機能C


予測増改築型•予測型を長期間維持してこじらせたパターン

•保守性が悪く、コストが増加する（別名：温泉旅館型）

23

機能A

構造

機能A機能B

機能C

構造


犠牲型•最初に作る構造は最低限にしておき、のちに再整備する

•機能移植にコストはかかるが長期保守にメリット

24

機能A

構造1

機能A 機能B 機能C

構造2構造1

機能A

技術的負債


拡張型•構造そのものに拡張性を持たせる

•（※天才に限る）

25

機能A

基本構造

構造1

機能A

構造2

機能B 機能C

基本構造

構造1


設計戦略の整理•そもそも「予測型」には限界がある

»特にSoE型では予測が困難になってきている

•いつでも「犠牲型」になる覚悟は必要

»ただし、すべてに対して前提にするのは困難

•「拡張型」をベースにしていく

»あくまでも自分で作らず、他人が作った拡張構造を利用する

▸オープンソースやクラウドサービス

26


他人が作った拡張構造に頼る•オープンソースのフレームワークを利用する

»優秀なOSSは「拡張可能な構造」を備えている

»パターンに従って実装することで構造が拡張される

•コミュニティが蓄積しているノウハウに頼る

»他の製品がベースにするような製品を選ぶ

»設定ファイル＋クラス構造のパターン化

27

Spring Security

•認証と認可についての基本的な考え方が整理されており、これを拡張すれば独自機構を提供できる

»AuthenticationManager

»AuthenticationProvider

»UserDetailsService

»WebSecurityConfigurerAdapter

»AsyncConfigurerSupport

28

Figure 1. An AuthenticationManager hierarchy using ProviderManager

https://spring.io/guides/topicals/spring-security-architecture/

https://spring.io/guides/topicals/spring-security-architecture/


他人が作った拡張構造に頼る•クラウドサービスを利用する

»利用すべきはPaaS（Platform as a Service）

»パターンに従って実装することで構造が拡張される

•構造だけではなく非機能要件まで含めて構造が保証する

»PaaSの進化

▸ミドルウェアレベル：データベースサービス

▸システムレベル：Webアプリケーション構成サービス、構成管理サービス

29

サーバレスアーキテクチャ

•コードを配置するだけで実行される

»AWS Lambda：Node.js、Java、Python

»Azure Functions：JavaScript、C#、Python、PHP

•特性

»インフラのマネジメント不要でオートスケール

»ステートレスなイベント駆動

▸タイマー、Webトリガー、データトリガー、メッセージトリガー…

»処理内容には制約がある

▸PaaSの他のサービスに対する操作であればサポートされている

30


機能ごとに最適な構造を用意するのは無駄か？•技術の成熟に伴い、ニッチな構造が増えている

•例えば

»ビックデータ：大規模分散処理

»リアルタイム処理：ストリームプロセッシング

»スケールするデータストア：NoSQLデータベース

»検索：検索エンジン（インデクサー）

•すべてオープンソースでもPaaSでも利用可能

31


拡張型×犠牲型•基本構造を変えずに、必要な機能に応じて構造を導入する

•場合によっては犠牲にする構造もあってよい

32

機能A

構造2

機能B

構造1

基本構造

基本構造

機能A

構造2

機能B 機能C

構造1構造3 構造4

機能A+

基本構造


その集大成がマイクロサービス•マイクロサービスアーキテクチャ（MSA）

•※とはいえ成熟の途中（特に企業システムとしては）

33

PaaS

ｻｰﾋﾞｽA

構造2

ｻｰﾋﾞｽB ｻｰﾋﾞｽC

構造1構造3 構造4

ｻｰﾋﾞｽA+

クラウドサービス

システム

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

34


簡単な概要•システム全体をサービスの組み合わせで実現する

»（小さな）サービスによって（大きな）サービスを動かす

»サービス同士はAPI/メッセージで連携する

•サービスの単位でチームが分割される

»チームが複数のサービスを管理しても良い

35


メリット•モノリシックなシステムでは変更が全体に影響する

»影響調査とリグレッションテストで工数の大半が消える

•サービス同士が疎結合なら変更の影響が全体に及ばない

»チーム/サービスごとに好きなリズムでリリースしてよい

•サービスごとに構造と非機能要件を変えてよい

»例：サービスによって性能特性を変えられる

36

カナリアリリース

37

Web App DB

ルーター100

100

Web App DB


38

Web App DB

ルーター100

100

Web App DB


39

Web App DB

ルーター100

95

Web App DB

5


40

Web App DB

ルーター100

100

Web App DB


41

ルーター100

100

Web App DB


いかにサービスを管理するのか•なぜ分けるか、どう分けるかの議論は終わりつつある

»ドメインは重要だが、正解がない

•数が多くなったサービスをどう管理していくのか？

»Netflixのトップページでは500個のサービスが動く

▸1サービス10インスタンスなら、5000インスタンス

▸Amazonは700-800個

»分けた場合のデメリットをどう減らしていくのか

42


疎結合を維持する戦略

43


疎結合を維持する戦略•データ分離

•テスト戦略

•不整合の許容

44

データ分離

•データの共有を疎結合化していく

»データの同期タイミングとサイズに注意

»巨大データをリアルタイムに共有したいなら共有データしかない

»通常、2フェーズコミットは避ける

45

ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽB

共有データビュートリガー/ストアド

ｻｰﾋﾞｽA ｻｰﾋﾞｽB

ETL

•イベントソーシング

»データのステートではなくデータへのイベントを共有する

»CQRS/コマンドクエリ責務分離

▸コマンド：更新などのロジックを含む処理

▸クエリ：検索などの単純な処理

ｲﾍﾞﾝﾄｽﾄｱ

データ分離

46


ｽﾃｰﾄ

イベントソーシング

テスト戦略

• Test Doubles

»本物を動かすのが大変なのでスタブやモックを使ってテストする

»コンシューマー側でプロバイダの想定する挙動を実装し、それを使ってテストする

»プロバイダの変更が発生するとモックの変更が必要になる

47

ｻｰﾋﾞｽAｻｰﾋﾞｽBのﾓｯｸ

テスト戦略

• Dark Canaries

»本番環境上に開発者しかアクセスできないテスト版をリリース

»本物を使ってテストする（ただし、できないものもある）

48


ｻｰﾋﾞｽAﾃｽﾄ版

テスト戦略

• Consumer-Driven Contract testing

»コンシューマーが要求するAPI挙動を契約として定義し、プロバイダが契約を検証して破壊的変更を防ぐ

49

ｻｰﾋﾞｽAｻｰﾋﾞｽB契約

ｻｰﾋﾞｽB契約

ｻｰﾋﾞｽC

ｻｰﾋﾞｽB

不整合の許容

•「Amazonのクーポン」

•非同期メッセージによる不整合を許容する

»サービス間の疎結合を重視する

»運用でリカバリするほうがメリットが大きい

50


リジリエンスの確保

51


リジリエンスの確保•サービスの集中管理

»設定の集中管理、知的なルーター、非同期メッセージング

•階層型障害への対応

»サーキットブレーカー、分散トレース

»障害注入テスト

52

設定の集中管理

•環境依存するような設定情報を各サービスが取得する

»設定ファイルを配置するのではなくネットワーク経由で取得する

53

設定

ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC

①起動時に設定を取得

知的なルーター

•知的なルーターによるサービスの発見とルーティング

»新しく起動したサービスは自分の居場所を自分で登録する

»レジストリに問合せてサービスを発見し、ルーティングする

54

ｻｰﾋﾞｽA

レジストリ

ルーターｻｰﾋﾞｽAｻｰﾋﾞｽA

①自分自身の登録

②リクエスト

③サービスの発見

非同期処理

•メッセージキューによる処理の分離

»答えを待たずに処理を非同期に行うようにする

▸パブリッシュ/サブスクライブ型もサポート

»機能同士の非機能を分離することができる

55


ｻｰﾋﾞｽA ｻｰﾋﾞｽBｷｭｰ

同期型

非同期型

ｻｰﾋﾞｽA

ｻｰﾋﾞｽB

ｷｭｰ

Pub/Sub型

ｻｰﾋﾞｽC

ｻｰﾋﾞｽD

サーキットブレーカー

•階層型障害への対応

»自分の身は自分で守る

•異常処理への対応

»通信エラーが発生しても機能Bが返事をしたように振る舞う

»タイムアウト/リトライの自動化

»値のキャッシュ

56

機能Bｻｰｷｯﾄﾌﾞﾚｰｶｰ

機能A

ｴﾗｰ処理

分散トレース

•サービスを横断したリクエストのトレース

»リクエストやサービス間通信にIDを発行する

»各サービスからはログ基盤にログを送信する

•ログ分析

»ログを検索し、処理の流れ視覚化する

»メトリクスツールとしての応用

57

ログ基盤

ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC

ログ検索

障害注入テスト

• Chaos Monkey

»Failure Injection Testing（障害注入テスト）

»平日日中にサーバをランダムにダウンさせるためのOSS

▸Netflixではインスタンスは毎週、アベイラビリティゾーンあるいはリージョン丸ごとは毎月障害

58


マイクロサービス向け製品•例：Spring Cloud

»設定の集中管理：Spring Cloud Config

»知的なルーター：Netflix Zuul、Netflix Ribbon、Netflix Eureka

»非同期メッセージング：Spring Cloud Stream

»サーキットブレーカー：Netflix Hystrix

»分散トレース：Spring Cloud Sleuth

59


ツール群

60


ツール群• CI/CDツール群

»サービスの構成と自動リリースを管理するための仕掛け

»＋インフラ構成管理ツール

»＋コンテナ（Docker）

▸ミドルウェア構成のバージョン管理

•メトリクスツール

»ヘルスチェックやログ分析の延長としての仮説検証ツール

61

CI/CDツール群

• Continues Integration、Deployment、Delivery

»チケット管理、ソースコード管理、CI/CDツールを含む

▸ドキュメント管理、チャットツールなど

62

Git サーバ

V1.1

チケット管理 V1.1

チケットAチケットB

サーバ

V1.1

V1.0

CI/CDツール

ｺｰﾄﾞV1.1

ｻｰﾊﾞ構成ﾚﾎﾟｼﾞﾄﾘ

ｻｰﾊﾞ設定


CI/CD開発ツール群•例：Atlassian（アトラシアン）

»課題管理：JIRA

»ソースコード管理：Bitbucket

»CI/CDツール：Bamboo

»ドキュメント管理：Confluence

»チャットツール：HipChat

63


エンタープライズ適用

64


“マイクロサービス”にこだわりすぎない•本質：サービス同士を疎結合にして個別変更を許容する

»適切な技術を適切な機能で利用するため

»サービスの大きさを気にしすぎない

•対象は「システム全体」であるべき

»1つのアプリケーションをマイクロサービスにしても意味が無い

65


品質の考え方について整理すること•サービス全体を保護するために小さな障害を許容する

»日中リリース、障害注入テスト、イベントソーシング…

•「小さな障害」を許容できるかどうかはドメインによる

»マイクロサービスだから障害を許容していいわけではない

»ただ、企業システムの中でも許容できるものもあるはず

66


明日からでも始めるべき•今のシステムから1つ目のサービスを切り出せるか

»少しずつマイクロサービス化していくことが重要

»マイクロサービスの戦略、プラットフォーム、ツールも段階的に導入していく

•「マイクロサービスで全体再構築」はうまくいかない

»アジャイル、DevOps、クラウド、マイクロサービスプラットフォームに習熟する期間が必要

67

アーキテクトの役割

68


プラットフォームの選択は重要•プラットフォームの選択は重要

»拡張可能でありながら、無駄のない仕組みであるかどうか

»依存することへの功罪を考える

▸あんなにマイクロソフトは嫌だったのに、Amazonならいいのか？

•自らのドメインに適用できるか？

»「流行している」で導入するのは危険

»ドメインのFit&Gapこそが最大の役割

69


アーキテクトがいるのは塔か現場か•塔の上から俯瞰する vs 現場で最適なものを作る

»象牙の塔では困るがプラットフォームの採用には全体視点が必要

»チーム（現場）にはプラットフォームから上を権限委譲する

70

PaaS

ｻｰﾋﾞｽA

構造2

ｻｰﾋﾞｽB ｻｰﾋﾞｽC

構造1 構造3

クラウドサービス

MSA用プラットフォーム

各種のツール群

プラットフォームのアーキテクト

各サービスの専門アーキテクト

まとめ

71

まとめ

フィードバックと改善•企業システムはSoRとSoEに分離していく

• SoEでは「フィードバックと改善」が重要

»リズムは最適なものを選べばいい

•段階的に機能が追加されていく

72

まとめ

アーキテクチャ設計戦略•段階的な機能拡充に合わせて構造も拡充する

»もはやアーキテクチャを初期に完成させるのは無理

•そのためのアーキテクチャ設計戦略

»予測型、犠牲型、拡張型

•特に重要なのは拡張型

»他人が作った拡張構造をうまく活用しよう

▸オープンソース製品、クラウドサービス

73

まとめ

プラットフォームの時代•プラットフォームをいかに利用するか

»オープンソースやクラウドサービス

»目的やパターンを理解し、独自に拡張していく

•特にMSA用プラットフォームは成長期

»企業システムでも参考になるアイデアがある

74

お知らせ

もう少し全体感が知りたいなら• Cloud First Architecture 設計ガイド» 第1章クラウドファーストの意味

» 第2章クラウド技術の構成

» 第3章クラウドファーストに至るまでの歴史

» 第4章エンタープライズとクラウドファースト

» 第5章アーキテクチャー設計ガイド

» 第6章クラウドファーストにおけるエンジニア

https://www.amazon.co.jp/dp/4822237818

75

https://www.amazon.co.jp/dp/4822237818

今どきのアーキテクチャ設計戦略 - qcon tokyo 2016

Technology