アジャイル開発を支えるアーキテクチャ設計とは
•
30 j'aime•26,985 vues
2017/12/15に開催されたエンタープライズアジャイル勉強会2017年12月セミナーでの講演資料です。 https://easg.smartcore.jp/
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à アジャイル開発を支えるアーキテクチャ設計とは
Similaire à アジャイル開発を支えるアーキテクチャ設計とは (20)
Plus de Yusuke Suzuki
Plus de Yusuke Suzuki (12)
Dernier
Dernier (11)
アジャイル開発を支えるアーキテクチャ設計とは
- 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
- 3. アジェンダ • エンタープライズアジャイル • エンタープライズシステムの状況 • アーキテクチャ設計 • 大きなアーキテクチャ設計 »何をするのか？ »誰がやるのか？ • その先にあるマイクロサービス • まとめ 2
- 6. エンタープライズアジャイル アジャイルの目的 • アジャイル採用の理由 »製品のデリバリ速度の加速(62%) »優先順位の変更可能性(56%) »生産性向上(55%) • 採用した結果の効果 »優先順位の変更可能性(87%) »生産性向上(85%) »プロジェクトの可視性(84%) 5 参考：アジャイルの採用状況レポート2016の要約(The 10th Annual State Of Agile Report ) https://qiita.com/kenjihiranabe/items/b9540696b3a0198fcecd
- 7. エンタープライズアジャイル アジャイル導入の難しさ • アジャイル採用の障害 »組織文化の変革(55%) »組織の変化への抵抗(42%) »既存のウォーターフォール手法(40%) • アジャイルが失敗した理由 »企業文化とアジャイルの価値観が合わない(46%) »アジャイルの経験不足(41%) 6 参考：アジャイルの採用状況レポート2016の要約(The 10th Annual State Of Agile Report ) https://qiita.com/kenjihiranabe/items/b9540696b3a0198fcecd
- 11. エンタープライズシステムの状況 2種類のシステム • SoR（System of Record）/mode 1 »情報を正しく「記録」するためのシステム »ユーザーは従業員が中心。取引情報を長期間にわたって保持し、 ビジネスの基幹となるシステム »変更頻度は低め、システム障害影響大 • SoE（System of Engagement）/mode 2 »顧客や取引先との「絆」を作るためにシステム »最新の状況を表示し、判断を行ってもらう。機能はユーザーごと に最適化され、高頻度で改善していく 10
- 14. エンタープライズシステムの状況 エンタープライズもアジャイルしたいのに！ • 「そのシステムがアジャイル」だけでは厳しい »連携先システムのスケジュールに強く影響される »結果「サービス」として求められるスピード感が出ない • かといって連携から逃げるとサービスの価値が下がる »トライアルはそれでもいいが商用に持って行きにくい • これを「組織文化の違い」という表現もできる »情報システム部門 vs 新サービス開発部門 13
- 15. アーキテクチャ設計 14
- 17. アーキテクチャ設計 アーキテクチャ＝システムの分割と統合 • システムは複数のコンポーネントの組み合わせで成立する »コンポーネント：部品、特定の機能を果たす単位 • アーキテクチャとは、システムが1.どのようなコンポーネ ントで構成され 2.それらがどのように連携するのか？を定 義したもの（≒システムの構造） 16 コンポーネント コンポーネント コンポーネント
- 18. アーキテクチャ設計 コンポーネントの種類 • アプリケーション内部のライブラリ、クラスなど »UIであれはUI部品、テンプレートなど • DBMS、アプリケーションサーバなどのミドルウェア • ハードウェア、ネットワークなどのインフラ • クラウド上の各種サービス • システム、アプリ、APIといったそのもの 17
- 20. アーキテクチャ設計 アーキテクチャのレベル 1/3 • 全体システム/企業 »企業内外のシステム配置やシステム連携 • 企業内/システム間 »あるシステムを中心とした連携先システムとの関係性 19 シス テム シス テム シス テム シス テム システム シス テム シス テム
- 21. アーキテクチャのレベル 2/3 • システム内/アプリ間 »システム内のアプリ配置、アプリ間連携 »物理的なノード配置なども含む アプリ アーキテクチャ設計 20 アプリ システム アプリ アプリ
- 22. アーキテクチャ設計 アーキテクチャのレベル 3/3 • アプリ内/フレームワーク »アプリケーションフレームワーク選定、パッケージ構成など • コードレベル »クラス分割やメソッドコールの方法など 21 クラスアプリ クラス クラス クラス ライブ ラリ フレームワーク クラス ライブ ラリ mylist.stream().filter(v -> v > 1) .forEach(System.out::println);
- 27. 何をするのか？ サマリ • 様々な観点での社内標準とのすり合わせ »認証認可、セキュリティ、運用保守など • システム連携における機能適合性と時間軸の調整 »どこまでのことなら、いつできるのか？ • システム連携における性能や可用性 »どこまで負荷を掛けられるのか、障害発生時はどうするのか 26
- 28. 何をするのか？ 社内標準 1/2 • 認証 »アカウント管理ポリシー（顧客/社内） »シングルサインオン（顧客/社内） • 認可 »組織と権限の管理の仕方 ▸特に業務側が使う機能でのデータ管理 »端末やアクセス経路制御 27
- 29. 何をするのか？ 社内標準 2/2 • セキュリティ »PCIDSSや個人情報保護などによるデータ管理ポリシー ▸場合によってはマスキング »監査証跡 »ネットワーク経路 • 運用保守 »スケジューラー、監視、バックアップなど運用サービス適合 »インフラ構成や構築 28
- 40. その先にあるマイクロサービス マイクロサービスは「マイクロ」必須か？ • サービス粒度は？ »ナノ： 0-3人月程度の単機能なAPI »マイクロ：3-20人月程度で複数のAPIを提供 »ミニ：20-100人月程度。3-6人でメンテ »中規模：100-300人月程度。7-10人がかりでメンテ »大規模：中規模以上 • 境界線は曖昧 39 大きなアーキテクチャ 小さなアーキテクチャ
- 41. その先にあるマイクロサービス マイクロサービスと設計レベル • 小さなアーキテクチャとしてのマイクロサービス »ナノレベルのAPI設計（例：Serverless）の話 »マイクロレベルのサービス設計（例：SpringBoot）の話 • 大きなアーキテクチャとしてのマイクロサービス »システム間連携（例：ETL）の話 • もはや、サービスやシステムの境界を決める意味が無い »連携しないサービスは存在しないのだから 40
- 44. マイクロサービスに学ぶ大きな設計 サマリ • どのようにサービス同士の結合度を調整するか？ »データ分離 »メッセージ連携 »無停止デプロイ »レジリエンス • ※細かい話なので、飛ばします。参考↓ » https://www.slideshare.net/yusuke/aws-dev-day-tokyo-2017 43
- 46. データ分離 • 共有データ：テーブルを共有する。変更同期が必要 »カラム追加/変更などは段階的に対応 • ビュー：参照公開前提だが、変更同期が必要 • トリガー/ストアド：変更同期は不要。非機能同期が必要 • ETL：全て非同期になる 45 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽB 共有データ ビュー/マテビュー トリガー/ストアド ｻｰﾋﾞｽA ｻｰﾋﾞｽB ETL
- 48. メッセージング サービス同士を連携させる • RESTful API over HTTP »もっともシンプルで分かりやすい実装 • メッセージキューによる非同期化 »機能同士の非機能を分離することができる 47 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽA ｻｰﾋﾞｽBｷｭｰ 同期型 非同期型 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｷｭｰ Pub/Sub型 ｻｰﾋﾞｽC ｻｰﾋﾞｽD
- 51. レジリエンス マイクロサービスにおける可用性 • 障害が発生しないようにする、ではない »レジリエンス＝復元力 »個別サービスの障害でシステム全体が停止しないようにする »従来の「停止しない部分を積み重ねる方式」は限界 • 階層型障害を避ける事が重要 »サーキットブレーカー 50 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC
- 52. テスト戦略 サービス間のテスト戦略 • サービス間テスト »サービス内のテストは閉じているが、他のサービスを呼び出し部 分のテスト手法をどうするか？ »モックの限界を超える？Consumer-Driven Contract testing • 本番環境でのテスト »レジリエンスのテストは本番環境でやるしかない »Netflixのカオスモンキー 51
- 53. まとめ 52