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