とある現場のシステムアーキテクチャ

とある現場のシステムアーキテクチャ

1. 1. 自己紹介 Name Job Skill Community Shinichi Kozake Systems Architect Java 関ジャバ/Hoge Driven
2. 2. 自己紹介 ! certificate ! Project Application Systems Engineer Database Systems Engineer 挑め！稼働率99.99% 大規模！警報管理システム レガシーからAndroidまで！ 大規模！保守点検サポートシステム
3. 3. アーキテクチャとは フレームワークとは システム設計について まとめ Agenda
4. 4. アーキテクチャとは フレームワークとは システム設計について まとめ Architecture
5. 5. アーキテクチャってなに？
6. 6. Architecture システムの特徴を現すもの システム構造 システム特性 ・動的 ・静的 ・振る舞い ・品質特性 7
7. 7. システム構造 システム特性 Architecture システムの特徴を現すもの ・動的 ・静的 ・振る舞い ・品質特性 アーキテクチャとは システム特性やシステム構造など、 そのシステムの特徴を現すものです。 文書の有無や優劣はともかく どんなシステムにも アーキテクチャは存在します。 8
8. 8. Architecture システムの特徴を現すもの システム構造 システム特性 ・動的 ・静的 ・振る舞い ・品質特性 ! これらを アーキテクチャ設計書として ドキュメントで現します。 9
9. 9. システム構造 システム特性 Architecture システムの特徴を現すもの ・動的 ・静的 ・振る舞い ・品質特性 ! システムの外部から見て分かる振る舞いです。 提供する機能、外部環境やシステムとの 相互関係などについて定義します。 ! ・アクティビティ図 ・ユースケース図 ・ボックス＆ライン図 10
10. 10. システム構造 システム特性 Architecture システムの特徴を現すもの ・動的 ・静的 ・振る舞い ・品質特性 ! 性能要件、システム稼働率、セキュリティなど、 いわゆる非機能要件といわれる システムの品質特性を定義します。 ! ・システム品質要件  → 主に文章で現します。 11
11. 11. システム構造 システム特性 s Architecture システムの特徴を現すもの ・動的 ・振る舞い ・品質特性 ・静的 ! システムの静的構造について、 各要素とそれの関係を定義します。 ! ・クラス図 ・コンポーネント図 ・配置図 ・ER図 ・ボックス＆ライン図 12
12. 12. システム構造 システム特性 Architecture システムの特徴を現すもの ・静的 ・振る舞い ・品質特性 ・動的 ! システムの動的構造について、 ある時点の実行時の要素と相互作用を定義します。 ! ・シーケンス図 ・フローチャート ・ステートチャート図 13
13. 13. どんな観点で検討するのか？
14. 14. Architecture 様々な視点 機能的 情報 並行性 開発 配置 運用 15
15. 15. Architecture 様々な視点 機能的 情報 並行性 開発 配置 運用 ! システム要素の機能・責務・関連システム とのインタフェースや相互作用など アーキテクチャを示す上で一番重要な影響を与えます。 ! ＜システム要素とは＞ システム/サブシステム/ソフトウェア製品/モジュール/クラス など、システムを構成する要素のこと 16
16. 16. Architecture 様々な視点 機能的 情報 並行性 開発 配置 運用 ! システムが扱う情報そのもの 格納・操作・管理方式 データの特性や構造、関係、データ移動やそれに関する問題など 17
17. 17. Architecture 様々な視点 機能的 情報 並行性 開発 配置 運用 ! システムの並行処理に関する技術方式 並行実行の調整や制御方式 18
18. 18. Architecture 様々な視点 機能的 情報 並行性 開発 配置 運用 ! 開発方式 パッケージ構成/モジュール管理/標準ガイドライン/ テスト方式/ソース管理/デプロイ方式/開発ツール/ 適用ライブラリ/etc ! 19
19. 19. Architecture 様々な視点 機能的 情報 並行性 開発 配置 運用 ! システムの配置環境 ハードウェア環境やネットワーク環境などの物理制約や ハードウェア配置場所の格納問題など ! 検討する項目はハードウェアの重量から データセンターの制約まで様々ありますが 見積もりの問題などから不確定要素の多い初期段階で 方式検討と確定が行われやすい傾向があります。 20
20. 20. Architecture 様々な視点 機能的 情報 並行性 開発 配置 運用 ! システムの運用/管理/サポートラインの確立など システム監視方法や障害発生時の解析手順、 システムやデータの移行方式、バックアップ/リストア手順など システム運用後に発生する様々なシナリオに対する方式 21
21. 21. Architecture 様々な品質特性 セキュリティ 性能 可用性 発展性 22
22. 22. Architecture 様々な品質特性 セキュリティ 性能 可用性 発展性 ! セキュリティガイドラインへの準拠 情報リソースへのアクセス管理/権限/監視の必要性 23
23. 23. Architecture 様々な品質特性 セキュリティ 性能 可用性 発展性 ! システムの性能要件 ! スループットや応答時間 スケール方式 ピーク負荷に対する対策など 24
24. 24. Architecture 様々な品質特性 セキュリティ 性能 可用性 発展性 ! システムの可用性要件 ! システム稼働率 計画停止時間 障害回復時間 など 25
25. 25. Architecture 様々な品質特性 セキュリティ 性能 可用性 発展性 ! システムの変更に対する柔軟性 ! 開発やデプロイの容易性 各環境や技術への依存度合いの考慮 知識の保存を見越した技術選択 など 26
26. 26. Architecture 様々な視点と品質特性 機能的 情報 並行性 開発 配置 セキュリティ 性能 可用性 発展性 運用 27
27. 27. Architecture 様々な視点と品質特性 機能的 情報 並行性 開発 配置 セキュリティ 性能 可用性 発展性 運用 ! 品質特性はそれぞれの視点にわたり関連します。 各視点において品質特性を考慮した方式を取捨選択します。 ! 28
28. 28. Architecture 様々な視点と品質特性 機能的 情報 並行性 開発 配置 セキュリティ 性能 可用性 発展性 運用 ! 認証方式 暗号化方式 29
29. 29. Architecture 様々な視点と品質特性 機能的 情報 並行性 開発 配置 セキュリティ 性能 可用性 発展性 運用 ! 守るべき情報リソースの定義 30
30. 30. Architecture 様々な視点と品質特性 機能的 情報 並行性 開発 配置 セキュリティ 性能 可用性 発展性 運用 ! スレッド制御方式 ロック制御方式 31
31. 31. とある現場の品質要件
32. 32. ・システムの稼働率は99.99%  障害によるシステム停止許容時間は10分以内 Architecture ・装置から受信した警報のモニター画面表示は受信後  1分以内に行われる事 ・インターネットに繋がるWebシステムについては  弊社規定のセキュリティガイドラインを満たすこと ・システム移行によるシステム停止は認められない  現行システムで保有する億件データも移行対象 品質要件 33
33. 33. ・システムの稼働率は99.99%  障害によるシステム停止許容時間は10分以内 Architecture ・装置から受信した警報のモニター画面表示は受信後  1分以内に行われる事 ・インターネットに繋がるWebシステムについては  弊社規定のセキュリティガイドラインを満たすこと ・システム移行によるシステム停止は認められない  現行システムで保有する億件データも移行対象 品質要件 管理 番号 優先度 a-1 a-2 a-3 a-4 A A A A 34
34. 34. Architecture ・システムの稼働率は99.99%  障害によるシステム停止許容時間は10分以内 ・装置から受信した警報のモニター画面表示は受信後  1分以内に行われる事 ・インターネットに繋がるWebシステムについては  弊社規定のセキュリティガイドラインを満たすこと ・システム移行によるシステム停止は認められない  現行システムで保有する億件データも移行対象 品質要件 管理 番号 優先度 a-1 a-2 a-3 a-4 A A A A ! 品質要件に管理番号を付与することで、要件管理が明瞭となります。 また、アーキテクチャ方式設計書のドキュメント内での記述が簡潔になります。 ! (例) 品質要件a-1の為、全てのハードウェアについては冗長構成をとる。 これにより、可用性は向上するが、ハードウェアの故障率が増加し、 運用も複雑となる。 ! 35
35. 35. Architecture ・システムの稼働率は99.99%  障害によるシステム停止許容時間は10分以内 ・装置から受信した警報のモニター画面表示は受信後  1分以内に行われる事 ・インターネットに繋がるWebシステムについては  弊社規定のセキュリティガイドラインを満たすこと ・システム移行によるシステム停止は認められない  現行システムで保有する億件データも移行対象 品質要件 管理 番号 優先度 a-1 a-2 a-3 a-4 A A A A ! 品質要件に優先度を定義します。 これにより、アーキテクチャ方式の決定（取捨選択）の際の指針ができます。 ! (例) 品質要件a-1の為、全てのハードウェアについては冗長構成をとる。 これは、品質要件a-xにある運用コストの低減に相反するが可用性の担保 を優先する。 36
36. 36. とある現場の アーキテクチャモデル
37. 37. Architecture システム構造 ボックス＆ライン図
38. 38. Architecture 開発環境 ボックス＆ライン図
39. 39. ! ボックス＆ライン図は正確性に欠けるますが、 専門知識の無いユーザに理解しやすいという利点があります。 アーキテクチャ検討初期の段階において、 またはコミュニケーションツールとして便利です。 Architecture
40. 40. Architecture システム間連携 コンポーネント図
41. 41. Architecture システム配置 配置図
42. 42. ! 一つのアーキテクチャモデルに複数の視点を記述すると モデルが複雑となり、モデルの正確性や理解性が損なわれます。 １つの視点から１つのアーキテクチャモデルを現すよう 心がけましょう。 Architecture
43. 43. Architecture アーキテクチャとはシステムの特徴を現すもの 図表や文章を用いてシステム構造や特性を現す アーキテクチャは様々な視点と品質特性から 検討され、取捨選択により決定する 44
44. 44. アーキテクチャとは フレームワークとは システム設計について まとめ System Structure
45. 45. System Design システムの３層構造 UI Logic Data 46
46. 46. 各層の特徴 UI Logic Data 理解の容易さ理解しやすい 理解しにくい System Design 47
47. 47. 各層の特徴 依存性の方向依存する 依存しない UI Logic Data 理解の容易さ理解しやすい 理解しにくい System Design 48
48. 48. 依存性の方向依存する 依存しない UI Logic Data 各層の特徴 ! UIは理解しやすく、ユーザの要望を捉えやすいです。 そこで、画面イメージやプロトタイプをもとに要件定義を進めると 早期の段階でユーザ要望を適切に把握することが出来ます。 理解の容易さ理解しやすい 理解しにくい System Design 49
49. 49. 理解の容易さ理解しやすい 理解しにくい UI Logic Data 各層の特徴 ! 一方、データ構造とその関連はユーザには理解しにくいです。 しかし、この層の変更は全ての層に対して影響を与えます。 データ構造および関連を正確に設計することがシステム開発の 肝となります。 依存性の方向依存する 依存しない System Design 50
50. 50. 各層の特徴 変化の流れ変化しやすい 変化しにくい UI Logic Data System Design 51
51. 51. とある現場の技術変化 JSP iBatis Flex myBatis Android myBatis Java Logic Java Logic Java Logic Struts BlazeDS JAX-RS 2014∼2015 2011∼2013 ∼2010 System Design 52
52. 52. iBatis myBatis myBatis Java Logic Java Logic Java Logic とある現場の技術変化 JSP Flex Android Struts BlazeDS JAX-RS 2014∼2015 2011∼2013 ∼2010 UI層に近づくほど 技術変化が激しいです。 UI層とロジック層を分離した 方式設計を心がけると変更に 強いシステムになりやすいです。 System Design 53
53. 53. システムを層に分けて捉える 各層の特性に応じて方式を設計する UI層は柔らかい技術 ロジック・データ層は固い技術を System Design 54
54. 54. アーキテクチャとは フレームワークとは システム設計について まとめ Framework
55. 55. Framework User App Framework Library Register Call Call Callback ・ライブラリは呼び出すもの ・フレームワークは呼び出されるもの 56
56. 56. Framework User App Framework Library Register Call Call Callback ! 「ハリウッドの原則」 ! 私たちを呼ぶな、私たちがあなた方を呼ぶ （Don't call us. We'll call you） 57
57. 57. 型にはめることで効率化 Framework ・強力なフレームワークは適用範囲が狭い ・適用範囲が広いと、強力さが失われる 58
58. 58. Framework Framework User Framework Library User App 59
59. 59. Library User App Framework Framework User Framework ! frozen spot ! hot spot 60
60. 60. Framework Framework Library User App User Framework ! 適用フレームワークでカバーが出来ない業務要件について 業務要件に特化したフレームワークを構築します。 いわゆるオレオレフレームワークと呼ばれています。 オレオレフレームワークは存在そのものが悪いのではなく、 その品質が一般的に悪いのが問題です。 61
61. 61. Framework Framework Library User App User Framework ! 業務フレームワークはある業務要件に特化したものなのです。 それを別の業務要件に再利用しようとすると、 適用範囲の相違による非効率さが発生しやすいです。 62
62. 62. User Framework Framework Library User App User App Framework ! 業務フレームワークで業務要件を 全てカバーしようとするのは悪手です。 ２割の労力で８割の処理が楽になる感覚で設計しましょう。 残り２割は業務フレームワークのサポート対象外にしたほうが 複雑性が低減します。 63
63. 63. フレームワークは型にはめることで効率化を計る 業務要件に特化したフレームワークの構築を 64 Framework 全ての業務要件をフレームワークでカバーしない ２：８の原則を
64. 64. アーキテクチャとは フレームワークとは システム設計について まとめ Summary
65. 65. Summary アーキテクチャとは フレームワークとは システム設計について ! あっちを立てればこっちが立たず
66. 66. Summary アーキテクチャとは フレームワークとは システム設計について ! レイヤーという響きがいいよね？
67. 67. Summary アーキテクチャとは フレームワークとは システム設計について ! オレが、オレこそが 真のフレームワークだ!!! (((o(*ﾟ▽ﾟ*)o)))
68. 68. DevLove!
69. 69. Thank you!