今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
•
71 gefällt mir•23,839 views
2016年10月24日に開催されたQCon Tokyo 2016での講演「A-3 今どきのアーキテクチャ設計戦略」の資料です。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie 今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
Ähnlich wie 今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016 (20)
Mehr von Yusuke Suzuki
Mehr von Yusuke Suzuki (12)
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
- 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
- 6. 今どきのシステム開発 企業システムの類型化 • SoR（System of Record） »情報を正しく「記録」するためのシステム »ユーザーは従業員が中心。取引情報を長期間にわたって保持し、 ビジネスの基幹となるシステム »変更頻度は低め、システム障害影響大 • SoE（System of Engagement） »顧客や取引先との「絆」を作るためにシステム »最新の状況を表示し、判断を行ってもらう。機能はユーザーごと に最適化され、高頻度で改善されていく 5AII.orgでのレポート「Systems of Engagement and the Future of Enterprise IT」2011 by Geoffrey Moore
- 8. 今どきのシステム開発 一方で、企業システムとしての制約 • SoEはSoRと必ず連携する »基幹システム側は期日ありきで計画主導プロセス • 社内部門/業務と必ず関わりがある »多くのビジネスはITだけで完結しない ▸事業計画、教育コスト、部門間調整、稟議… • ビジネスは簡単に止められない »社会インフラに近いほど「止まっては困る」 7
- 10. アーキテクチャ設計基礎 9
- 19. 今どきのアーキテクチャ設計 18
- 22. 今どきのアーキテクチャ設計 変更に対応する構造を作れるか？ • もはや初期段階で最適な構造を確定できないことが前提 »とはいえ「流行のフレームワークでいい」ではない • 必要な機能が段階的に足されていく »新たな機能は既存の構造が最適ではないかもしれない • なんらかのアーキテクチャ設計戦略が必要になる »予測型、犠牲型、拡張型 21
- 25. アーキテクチャ設計戦略 犠牲型 • 最初に作る構造は最低限にしておき、のちに再整備する • 機能移植にコストはかかるが長期保守にメリット 24 機能A 構造1 機能A 機能B 機能C 構造2構造1 機能A 技術的負債
- 27. アーキテクチャ設計戦略 設計戦略の整理 • そもそも「予測型」には限界がある »特にSoE型では予測が困難になってきている • いつでも「犠牲型」になる覚悟は必要 »ただし、すべてに対して前提にするのは困難 • 「拡張型」をベースにしていく »あくまでも自分で作らず、他人が作った拡張構造を利用する ▸オープンソースやクラウドサービス 26
- 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+ クラウドサービス システム
- 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
- 45. マイクロサービスアーキテクチャ 疎結合を維持する戦略 • データ分離 • テスト戦略 • 不整合の許容 44
- 46. データ分離 • データの共有を疎結合化していく »データの同期タイミングとサイズに注意 »巨大データをリアルタイムに共有したいなら共有データしかない »通常、2フェーズコミットは避ける 45 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽB 共有データ ビュー トリガー/ストアド ｻｰﾋﾞｽA ｻｰﾋﾞｽB ETL
- 49. テスト戦略 • Dark Canaries »本番環境上に開発者しかアクセスできないテスト版をリリース »本物を使ってテストする（ただし、できないものもある） 48 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ﾃｽﾄ版
- 50. テスト戦略 • Consumer-Driven Contract testing »コンシューマーが要求するAPI挙動を契約として定義し、プロバ イダが契約を検証して破壊的変更を防ぐ 49 ｻｰﾋﾞｽA ｻｰﾋﾞｽB 契約 ｻｰﾋﾞｽB 契約 ｻｰﾋﾞｽC ｻｰﾋﾞｽB
- 54. 設定の集中管理 • 環境依存するような設定情報を各サービスが取得する »設定ファイルを配置するのではなくネットワーク経由で取得する 53 設定 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC ①起動時に設定を取得
- 56. 非同期処理 • メッセージキューによる処理の分離 »答えを待たずに処理を非同期に行うようにする ▸パブリッシュ/サブスクライブ型もサポート »機能同士の非機能を分離することができる 55 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽBｷｭｰ 同期型 非同期型 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｷｭｰ Pub/Sub型 ｻｰﾋﾞｽC ｻｰﾋﾞｽD
- 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
- 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 ｻｰﾊﾞ構成 ﾚﾎﾟｼﾞﾄﾘ ｻｰﾊﾞ設定
- 69. アーキテクトの役割 68
- 71. アーキテクトの役割 アーキテクトがいるのは塔か現場か • 塔の上から俯瞰する vs 現場で最適なものを作る »象牙の塔では困るがプラットフォームの採用には全体視点が必要 »チーム（現場）にはプラットフォームから上を権限委譲する 70 PaaS ｻｰﾋﾞｽA 構造2 ｻｰﾋﾞｽB ｻｰﾋﾞｽC 構造1 構造3 クラウドサービス MSA用プラットフォーム 各種のツール群 プラットフォームのアーキテクト 各サービスの専門アーキテクト
- 72. まとめ 71
- 73. まとめ フィードバックと改善 • 企業システムはSoRとSoEに分離していく • SoEでは「フィードバックと改善」が重要 »リズムは最適なものを選べばいい • 段階的に機能が追加されていく 72
- 74. まとめ アーキテクチャ設計戦略 • 段階的な機能拡充に合わせて構造も拡充する »もはやアーキテクチャを初期に完成させるのは無理 • そのためのアーキテクチャ設計戦略 »予測型、犠牲型、拡張型 • 特に重要なのは拡張型 »他人が作った拡張構造をうまく活用しよう ▸オープンソース製品、クラウドサービス 73
- 76. お知らせ もう少し全体感が知りたいなら • Cloud First Architecture 設計ガイド » 第1章 クラウドファーストの意味 » 第2章 クラウド技術の構成 » 第3章 クラウドファーストに至るまでの歴史 » 第4章 エンタープライズとクラウドファースト » 第5章 アーキテクチャー設計ガイド » 第6章 クラウドファーストにおけるエンジニア https://www.amazon.co.jp/dp/4822237818 75