Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

アジャイル開発を支えるアーキテクチャ設計とは

12,347 views

Published on

2017/12/15に開催されたエンタープライズアジャイル勉強会2017年12月セミナーでの講演資料です。
https://easg.smartcore.jp/

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

アジャイル開発を支えるアーキテクチャ設計とは

  1. 1. アジャイル開発を支える アーキテクチャ設計とは 2017/12/15 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 エンタープライズアジャイル勉強会 2017年12月セミナー https://easg.smartcore.jp/
  2. 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ(株) » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
  3. 3. アジェンダ • エンタープライズアジャイル • エンタープライズシステムの状況 • アーキテクチャ設計 • 大きなアーキテクチャ設計 »何をするのか? »誰がやるのか? • その先にあるマイクロサービス • まとめ 2
  4. 4. エンタープライズアジャイル 3
  5. 5. エンタープライズアジャイル エンタープライズもアジャイルでしょ!? • 従来型開発プロセスの限界 »最初に大きく計画しても、状況が変わってしまう »そもそも、何が作られているのか最後になるまで分からない • 新規サービスにはアジャイルプロセスを »正解が分からないから試行錯誤しながらサービスを造り上げたい »ユーザーからのフィードバックに応じて素早く改善をしたい 4
  6. 6. エンタープライズアジャイル アジャイルの目的 • アジャイル採用の理由 »製品のデリバリ速度の加速(62%) »優先順位の変更可能性(56%) »生産性向上(55%) • 採用した結果の効果 »優先順位の変更可能性(87%) »生産性向上(85%) »プロジェクトの可視性(84%) 5 参考:アジャイルの採用状況レポート2016の要約(The 10th Annual State Of Agile Report ) https://qiita.com/kenjihiranabe/items/b9540696b3a0198fcecd
  7. 7. エンタープライズアジャイル アジャイル導入の難しさ • アジャイル採用の障害 »組織文化の変革(55%) »組織の変化への抵抗(42%) »既存のウォーターフォール手法(40%) • アジャイルが失敗した理由 »企業文化とアジャイルの価値観が合わない(46%) »アジャイルの経験不足(41%) 6 参考:アジャイルの採用状況レポート2016の要約(The 10th Annual State Of Agile Report ) https://qiita.com/kenjihiranabe/items/b9540696b3a0198fcecd
  8. 8. エンタープライズアジャイル それだけじゃない難しさ • 確かに組織文化やプロセスも大事 • 一方で、技術面についても難しくなっている »トライアルは「なんとかする」でもよい »そこから本格的に展開しようとすると行き詰まることがある 7
  9. 9. エンタープライズシステムの状況 8
  10. 10. エンタープライズシステムの状況 ITサービスの境界線が曖昧に 9 新 サービス 商品 SSO 外部 商品 管理 商品 ポイント ユーザー カート 顧客 管理 顧客 在庫 管理 在庫 クレジッ トカード 物流 販売 管理 購買 物流 監査 外部 外部 コンタクト センター 問合せ監視
  11. 11. エンタープライズシステムの状況 2種類のシステム • SoR(System of Record)/mode 1 »情報を正しく「記録」するためのシステム »ユーザーは従業員が中心。取引情報を長期間にわたって保持し、 ビジネスの基幹となるシステム »変更頻度は低め、システム障害影響大 • SoE(System of Engagement)/mode 2 »顧客や取引先との「絆」を作るためにシステム »最新の状況を表示し、判断を行ってもらう。機能はユーザーごと に最適化され、高頻度で改善していく 10
  12. 12. 11https://www.flickr.com/photos/36008503@N03/3875243958/
  13. 13. エンタープライズシステムの状況 システムは互いに依存し、影響する • ECサービスの改修が連携先システムに影響する »「サービス」の改修には「連携先システム」の対応が必要 »停止や変更を伴うリリース日は調整が必要になる • SoRとSoEはライフサイクルが異なる »本来ユーザーによる改善サイクルが異なる »システム規模も求められる安定性も異なる 12
  14. 14. エンタープライズシステムの状況 エンタープライズもアジャイルしたいのに! • 「そのシステムがアジャイル」だけでは厳しい »連携先システムのスケジュールに強く影響される »結果「サービス」として求められるスピード感が出ない • かといって連携から逃げるとサービスの価値が下がる »トライアルはそれでもいいが商用に持って行きにくい • これを「組織文化の違い」という表現もできる »情報システム部門 vs 新サービス開発部門 13
  15. 15. アーキテクチャ設計 14
  16. 16. アーキテクチャ設計 アーキテクチャ設計が大事です • アジャイルが機能するように技術的に支援する »アーキテクチャ設計によってエンタープライズアジャイルを有効 に機能させる 15
  17. 17. アーキテクチャ設計 アーキテクチャ=システムの分割と統合 • システムは複数のコンポーネントの組み合わせで成立する »コンポーネント:部品、特定の機能を果たす単位 • アーキテクチャとは、システムが1.どのようなコンポーネ ントで構成され 2.それらがどのように連携するのか?を定 義したもの(≒システムの構造) 16 コンポーネント コンポーネント コンポーネント
  18. 18. アーキテクチャ設計 コンポーネントの種類 • アプリケーション内部のライブラリ、クラスなど »UIであれはUI部品、テンプレートなど • DBMS、アプリケーションサーバなどのミドルウェア • ハードウェア、ネットワークなどのインフラ • クラウド上の各種サービス • システム、アプリ、APIといったそのもの 17
  19. 19. アーキテクチャ設計 アーキテクチャのレベル • 5つの階層(※エンタープライズシステムにおける) »企業全体システム »企業内/システム間 »システム内/アプリ間 »アプリ内/フレームワーク »コード 18
  20. 20. アーキテクチャ設計 アーキテクチャのレベル 1/3 • 全体システム/企業 »企業内外のシステム配置やシステム連携 • 企業内/システム間 »あるシステムを中心とした連携先システムとの関係性 19 シス テム シス テム シス テム シス テム システム シス テム シス テム
  21. 21. アーキテクチャのレベル 2/3 • システム内/アプリ間 »システム内のアプリ配置、アプリ間連携 »物理的なノード配置なども含む アプリ アーキテクチャ設計 20 アプリ システム アプリ アプリ
  22. 22. アーキテクチャ設計 アーキテクチャのレベル 3/3 • アプリ内/フレームワーク »アプリケーションフレームワーク選定、パッケージ構成など • コードレベル »クラス分割やメソッドコールの方法など 21 クラスアプリ クラス クラス クラス ライブ ラリ フレームワーク クラス ライブ ラリ mylist.stream().filter(v -> v > 1) .forEach(System.out::println);
  23. 23. アーキテクチャ設計 大きなアーキテクチャと小さなアーキテクチャ • 5つの階層(※エンタープライズシステムにおける) »企業全体システム »企業内/システム間 »システム内/アプリ間 »アプリ内/フレームワーク »コード 22 大きなアーキテクチャ 小さなアーキテクチャ
  24. 24. アーキテクチャ設計 大きなアーキテクチャ 23 新 サービス 商品 SSO 外部 商品 管理 商品 ポイント ユーザー カート 顧客 管理 顧客 在庫 管理 在庫 クレジッ トカード 物流 販売 管理 購買 物流 監査 外部 外部 コンタクト センター 問合せ監視
  25. 25. アーキテクチャ設計 大きなアーキテクチャと小さなアーキテクチャ • 大きなアーキテクチャ »アジャイルチームの外で解決すべきこと(中とは協力) »アジャイルチームを機能させるために頑張る • 小さなアーキテクチャ »アジャイルチームの中で解決すべきこと »基本的には「好きにしてよし」 »そのアプリに最適な言語やフレームワークを選ぶべき 24
  26. 26. 大きなアーキテクチャ設計 何をするのか? 25
  27. 27. 何をするのか? サマリ • 様々な観点での社内標準とのすり合わせ »認証認可、セキュリティ、運用保守など • システム連携における機能適合性と時間軸の調整 »どこまでのことなら、いつできるのか? • システム連携における性能や可用性 »どこまで負荷を掛けられるのか、障害発生時はどうするのか 26
  28. 28. 何をするのか? 社内標準 1/2 • 認証 »アカウント管理ポリシー(顧客/社内) »シングルサインオン(顧客/社内) • 認可 »組織と権限の管理の仕方 ▸特に業務側が使う機能でのデータ管理 »端末やアクセス経路制御 27
  29. 29. 何をするのか? 社内標準 2/2 • セキュリティ »PCIDSSや個人情報保護などによるデータ管理ポリシー ▸場合によってはマスキング »監査証跡 »ネットワーク経路 • 運用保守 »スケジューラー、監視、バックアップなど運用サービス適合 »インフラ構成や構築 28
  30. 30. 何をするのか? 機能適合性と時間軸 • 機能適合性「すぐに反映したい」 »適合度◎:APIを叩いてリアルタイムに反映 »適合度○:バッチで日次反映 »適合度△:手動でCSVダウンロート&アップロード »適合度×:自分で入力しなおし 29
  31. 31. 何をするのか? 機能適合性と時間軸 • 時間軸「いますぐやりたい」 »適合度◎:すでに機能があります »適合度○:3か月後には… »適合度△:6か月後には… »適合度×:1年は無理 30
  32. 32. 何をするのか? 連携における性能や可用性 • 性能 »データの送受信タイミングや量 »トランザクション量 ▸単位時間あたりのスループット • 可用性 »自システムのSLA »連携先システムがダウンしている場合の挙動 ▸瞬断、障害、メンテナンス(定期)、メンテナンス(不定期) 31
  33. 33. 何をするのか? 連携における性能や可用性 • システム連携になると性能と可用性や複雑になる • 性能と可用性 »性能を上げると可用性要求が上がることがある ▸リアルタイムに連携すると停止影響が大きくなる ▸例:基幹は日中しかオンラインがない »機能適合性とのバランスも難しい ▸手動連携をオンライン化する、など 32
  34. 34. 大きなアーキテクチャ設計 誰がやるのか? 33
  35. 35. 誰がやるのか? チームの外側に用意すべき • チームの外側で関連システムとの調整が可能な人 »チームは小さなアーキテクチャ設計に集中させてあげる »もちろん、チームと連携した判断は必要 »チーム内の人でやるならチーム内タスクとは切り分けて作業 • 専任でなくてよいが、それなりには稼働が必要 »フルコミットである必要はないし、1人でなくても良い »POやスクラムマスターが相談できる相手 34
  36. 36. 誰がやるのか? なぜ、チームの外側なのか? • チームが見積もれないことはチームに持ち込まない »外部と調整をしないと見積もれない→生産性が測れない »POが外部部門と調整している状況と同じこと • もちろん、チーム内との連携は必要 »連携手法の検証が必要になった ▸技術検証のための作業をする(スパイク) »連携の検討打ち合わせに出てもらう ▸打ち合わせに出る、というタスクにする 35
  37. 37. その先にあるマイクロサービス 36
  38. 38. その先にあるマイクロサービス マイクロサービスとは? • 大きなシステムを「小さなサービスの連携」で実現する »マイクロサービス同士はオンラインで連携を行う »クラウド(インフラのソフトウェア化)前提 37 サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) システム全体 サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ) サービス (アプリ+ インフラ)
  39. 39. その先にあるマイクロサービス モノリシックからマイクロサービスへ • 大きなシステムを「1つのアプリ」で実現する弊害 »モノリシック(一枚岩)になっていると機能の改善で影響調査や リグレッションテストが膨大にかかってくる »リリースも機能間の調整が必要になってしまう • マイクロサービスのメリット »小さなサービス単位で機能をいれかえられる ▸※小さなサービス同士が疎結合に連携していれば 38
  40. 40. その先にあるマイクロサービス マイクロサービスは「マイクロ」必須か? • サービス粒度は? »ナノ: 0-3人月程度の単機能なAPI »マイクロ:3-20人月程度で複数のAPIを提供 »ミニ:20-100人月程度。3-6人でメンテ »中規模:100-300人月程度。7-10人がかりでメンテ »大規模:中規模以上 • 境界線は曖昧 39 大きなアーキテクチャ 小さなアーキテクチャ
  41. 41. その先にあるマイクロサービス マイクロサービスと設計レベル • 小さなアーキテクチャとしてのマイクロサービス »ナノレベルのAPI設計(例:Serverless)の話 »マイクロレベルのサービス設計(例:SpringBoot)の話 • 大きなアーキテクチャとしてのマイクロサービス »システム間連携(例:ETL)の話 • もはや、サービスやシステムの境界を決める意味が無い »連携しないサービスは存在しないのだから 40
  42. 42. その先にあるマイクロサービス 大きなアーキテクチャが小さくなる • アプリ内においても「コンポーネントをネットワーク越し に連携させる手法」有効に »大きなアーキテクチャから小さなアーキテクチャまでシームレス • ただし、切り分けは必要 »チーム内でやるべきアーキテクチャか、チーム外でやるべきアー キテクチャか 41
  43. 43. マイクロサービスに学ぶ大きな設計 42
  44. 44. マイクロサービスに学ぶ大きな設計 サマリ • どのようにサービス同士の結合度を調整するか? »データ分離 »メッセージ連携 »無停止デプロイ »レジリエンス • ※細かい話なので、飛ばします。参考↓ » https://www.slideshare.net/yusuke/aws-dev-day-tokyo-2017 43
  45. 45. データ分離 データは各サービスが管理する • データをサービス間で共有することは避けるべき »テーブル構造の変更が強制的に同期されるから • とはいえ、データの特性や種類に応じて方式を選択 »RDBの機能は有効活用。ただし、2フェーズコミットを避ける »不整合の許容範囲を決めることが重要 ▸許容できないなら疎結合化は困難になる »メッセージングの仕組みとの組み合わせで検討 44
  46. 46. データ分離 • 共有データ:テーブルを共有する。変更同期が必要 »カラム追加/変更などは段階的に対応 • ビュー:参照公開前提だが、変更同期が必要 • トリガー/ストアド:変更同期は不要。非機能同期が必要 • ETL:全て非同期になる 45 サービスA サービスB サービスA サービスB サービスA サービスB 共有データ ビュー/マテビュー トリガー/ストアド サービスA サービスB ETL
  47. 47. データ分離 • イベントソーシング »データのステートではなくデータへのイベントを共有する ▸非同期ではあるが、時間的ズレを小さくできる »CQRS/コマンドクエリ責務分離 ▸コマンド:更新などのロジックを含む処理 ▸クエリ:検索などの単純な処理 46 イベント ストア サービスA サービスB ステート イベントソーシング
  48. 48. メッセージング サービス同士を連携させる • RESTful API over HTTP »もっともシンプルで分かりやすい実装 • メッセージキューによる非同期化 »機能同士の非機能を分離することができる 47 サービスA サービスB サービスA サービスBキュー 同期型 非同期型 サービスA サービスB キュー Pub/Sub型 サービスC サービスD
  49. 49. メッセージング 不整合の許容 • 非同期による不整合の許容 »サービス間の疎結合を重視する »運用でリカバリするほうがメリッ トが大きければクーポンもあり 48
  50. 50. 無停止デプロイ ブルーグリーンデプロイメント • 瞬断せずにリリースを行うための手法 »1.新verを重複して構築 »2.ルーティングを制御して新verを解放 »3.旧verを削除 49 1.0 1.1 1.0 1.1 1.0 1.1 1.0 1.1
  51. 51. レジリエンス マイクロサービスにおける可用性 • 障害が発生しないようにする、ではない »レジリエンス=復元力 »個別サービスの障害でシステム全体が停止しないようにする »従来の「停止しない部分を積み重ねる方式」は限界 • 階層型障害を避ける事が重要 »サーキットブレーカー 50 サービスA サービスB サービスC
  52. 52. テスト戦略 サービス間のテスト戦略 • サービス間テスト »サービス内のテストは閉じているが、他のサービスを呼び出し部 分のテスト手法をどうするか? »モックの限界を超える?Consumer-Driven Contract testing • 本番環境でのテスト »レジリエンスのテストは本番環境でやるしかない »Netflixのカオスモンキー 51
  53. 53. まとめ 52
  54. 54. まとめ エンタープライズアジャイルの状況 • エンタープライズアジャイルでは技術面も課題 »トライアルは「なんとかする」でもよい »そこから本格的に展開しようとすると行き詰まることがある • エンタープライズシステム同士の依存と影響 »連携先システムのスケジュールに強く影響される »結果「サービス」として求められるスピード感が出ない 53
  55. 55. まとめ 大きなアーキテクチャと小さなアーキテクチャ • 大きなアーキテクチャ »アプリ間やシステム間連携 »チームの外側で設計し、チームと共同で選択する • 小さなアーキテクチャ »アジャイルチームが設計し、選択する »そのチームが担当するサービスにとって最適化すればいい 54
  56. 56. まとめ アーキテクチャ設計は重要です • アジャイルを機能させるのにアーキテクチャ設計が必要 »エンタープライズでは大きなアーキテクチャ設計の比重が大きい • マイクロサービスで検討されることは参考になる »連携することを前提にシステムを作る、のが常識に »そうするとシステム間連携の結合度を調整するための手法が様々 に出てくる 55

×