レガシーシステム、モダナイズへの道筋

by mokonist

Slide 1

Slide 1 text

レガシーシステム、モダナイズへの道筋 2023/06/23 1 AWS事業本部コンサルティング部ソリューションアーキテクト⾨別優多

Slide 2

Slide 2 text

2 本セッションはレガシーシステムを抱えられていて、（内製化で）レガシーシステムと向き合っていく事に興味をお持ちの方に向けたセッションです！

Slide 3

Slide 3 text

3 自己紹介門別優多 – moko クラスメソッド株式会社 AWS事業本部コンサルティング部 Twitter, GitHub: @mokocm 入社: 2019/07 2019年7月〜2021年6月コンサルティング部 2021年7月〜2022年6月 CX事業本部MAD事業部 2022年7月〜コンサルティング部 2020-2023 Japan AWS Top Engineer 2021, 2023 Japan AWS All Certifications Engineers 2022年技能五輪国際大会クラウドコンピューティング職種敢闘賞好きなAWSサービス: AWS CDK

Slide 4

Slide 4 text

4 Agenda ・なぜモダナイズをしたい？・モダナイズ種類・マイクロサービスするべき？・システムとデータベースの共存・分離・本番環境へのリリース・レガシーシステムモダナイズへの道筋

Slide 5

Slide 5 text

5 皆さんのレガシーシステムどんな課題を抱えていますか？

Slide 6

Slide 6 text

6 レガシーシステムの課題レガシーシステムのよくある課題 EOLを迎えている。運用コストが高いサービスそのものが使いにくいそもそもシステムがブラックボックスで、変更が出来ない中身を見てみるとつらい設計・実装になっていた改善・新機能を追加したいが、改修が困難ビジネス上の要求を迅速に実装出来なくなってしまっている開発会社にお願いしていて、実装のリードタイム・コストが掛かる

Slide 7

Slide 7 text

7 あるべき姿の整理あるべき姿運用コストを下げたい新機能を沢山、素早くリリースしていきたい操作しやすいUIで顧客体験をよくしたい(機能改善) 開発会社にお願いしている箇所を自社でしっかりやっていきたい

Slide 8

Slide 8 text

8 あるべき姿の整理あるべき姿運用コストを下げたい新機能を沢山、素早くリリースしていきたい操作しやすいUIで顧客体験をよくしたい(機能改善) 開発会社にお願いしている箇所を自社でしっかりやっていきたいスピーディーで継続的な改善が必要自社でしっかり管理していくケースが増えてきている

Slide 9

Slide 9 text

9 抱えているレガシーシステムがユーザー体験・開発者体験を損ねている

Slide 10

Slide 10 text

10 開発者体験を損ねているので良い物も作れない

Slide 11

Slide 11 text

11 結果的に、微妙なシステムをなかなか改修できない

Slide 12

Slide 12 text

12 改善のサイクルをあげていく必要がある

Slide 13

Slide 13 text

13 レガシーシステムの刷新内製化、モダナイズが必要！

Slide 14

Slide 14 text

14 モダナイズの種類

Slide 15

Slide 15 text

15 Refactor 既存システムのリファクタリング既存システムのソースコードが改修できる温度感の場合に実施直接既存システムをモジュラーモノリスに書き換えるような事も可能メリット既存システムを修正するため、全てを一から作り直すよりは時間が掛からない既存のビジネスロジックを維持出来るため、新しいチャレンジをするよりかは保守的に運用出来るデメリット既存コードによっては難易度が格段に高く、新しく作った方が将来的にも幸せになるケースがあるそもそもリファクタリングは常に開発プロセスで行われ続けるべきものである

Slide 16

Slide 16 text

16 Rewrite: Big Bang Rewrite, Release Big Bang Rewrite, Release 既存システムを一から書き直す。旧来のシステムを模倣して全ての機能を再実装メリット新しい技術・設計から構築できるため、旧来システムのしがらみから解放されるパッと見これで良さそうと思ってしまいガチデメリットリリースリスクが非常に高い。新しいシステムが出来上がるまで時間が掛かる時間を掛けて出来上がった物が既存のシステムと互換性があるとは限らない全ての内容を完全に把握して再実装するため、大量の時間と労力が必要になる。

Slide 17

Slide 17 text

17 Rewrite: Big Bang Rewrite, Release Big Bang Rewrite, Release 既存システムを一から書き直す。旧来のシステムを模倣して全ての機能を再実装メリット新しい技術・設計から構築できるため、旧来システムのしがらみから解放されるパッと見これで良さそうと思ってしまいガチデメリットリリースリスクが非常に高い。新しいシステムが出来上がるまで時間が掛かる時間を掛けて出来上がった物が既存のシステムと互換性があるとは限らない全ての内容を完全に把握して再実装するため、大量の時間と労力が必要になる。システムの”リプレース”ではよくこれが選択されてしまいがち

Slide 18

Slide 18 text

18 Rewrite – Strangler Fig Pattern Strangler Fig Pattern 既存システムの機能毎に徐々にリライトして置き換えていく手法システム前段にProxyを置いて新旧サービスにルーティングしたりも可能既存システムを絞め殺すようにリプレースしていくメリット旧システムを完全に置き換えるのではなく、部分的に新システムに切り替えるため、リスクを最小限に抑えられる。小さい成功体験を積んでいける。チーム全体のスキルアップもできる。 Big Bang Rewriteと比べ、少しずつの変更なため、リスクが小さいデメリット旧システムと新システムを並行して稼働させる必要があり、労力がかかる特にデータベース周りの実現方法が難しい

Slide 19

Slide 19 text

19 Rewrite – Strangler Fig Pattern

Slide 20

Slide 20 text

20 既存システムのモダナイズは Strangler Fig Patternで少しずつ置き換えていくのがおすすめ

Slide 21

Slide 21 text

21 マイクロサービスするべきか？

Slide 22

Slide 22 text

22 個人的結論

Slide 23

Slide 23 text

23 ステップアップで導入がオススメ

Slide 24

Slide 24 text

24 マイクロサービス化のつらみ多くの利点がある一方で

Slide 25

Slide 25 text

25 マイクロサービス化のつらみ多くの利点がある一方で・サービス間通信・トランザクションの管理・SAGAパターン・サービスが増えてきたときの開発と運用の負荷・依存性の無いデプロイ・認証、認可・インフラ設計・監視、トレーシングの設計

Slide 26

Slide 26 text

26 マイクロサービス化のつらみ多くの利点がある一方で・サービス間通信・トランザクションの管理・SAGAパターン・サービスが増えてきたときの開発と運用の負荷・依存性の無いデプロイ・認証、認可・インフラ設計・監視、トレーシングの設計考える事が多い

Slide 27

Slide 27 text

27 まずはレガシーシステムから身動きができる状態にしよう

Slide 28

Slide 28 text

28 成功体験を積んでチームのレベルを上げていく！

Slide 29

Slide 29 text

29 Microservicesを見据えたモジュラーモノリスおすすめ（個人的感想）

Slide 30

Slide 30 text

30 避けて通れないデータベース

Slide 31

Slide 31 text

31 現状既存DB 既存システム

Slide 32

Slide 32 text

32 例を3つ挙げてご紹介します

Slide 33

Slide 33 text

33 例1) 既存DBを参照する新システムを作成するパターン

Slide 34

Slide 34 text

34 Step1 既存DBを参照する新システムを作成既存DB 既存システム新システム

Slide 35

Slide 35 text

35 Step2 移行が完了後、新システムだけにする既存DB 新システム

Slide 36

Slide 36 text

36 Step3 新システムでDB設計の見直しをする Module A DB 新システム Module B DB

Slide 37

Slide 37 text

37 一見、よさそう

Slide 38

Slide 38 text

38 Step1 既存DBを参照する新システムを作成既存DB 既存システム新システム

Slide 39

Slide 39 text

39 Step2 移行が完了後、新システムだけにする既存DB 新システム

Slide 40

Slide 40 text

40 新システムに移行するとき Big Bang Rewrite, Release してしまいがち

Slide 41

Slide 41 text

41 一寸先には Big Bang Rewrite, Release

Slide 42

Slide 42 text

42 可能ならば少しずつリライト&リリース

Slide 43

Slide 43 text

43 例2) 既存のレガシーシステムに APIを作る場合

Slide 44

Slide 44 text

44 技術的負債を解消する前に機能を実装する必要がある場合も多々ある

Slide 45

Slide 45 text

45 Step1 既存システムにAPIを追加既存DB 既存システム APIを作成して公開

Slide 46

Slide 46 text

46 Step2 既存システムのAPIを呼ぶ新システムを作成既存DB 既存システム APIを作成して公開新システム

Slide 47

Slide 47 text

47 Step3 既存システムのAPIをサービスとして分離既存DB 既存システム新サービス新システム

Slide 48

Slide 48 text

48 Step4 データベースを分離既存DB 既存システム新サービス新システム新DB

Slide 49

Slide 49 text

49 例3) データベースとサービスを分離する場合

Slide 50

Slide 50 text

50 現状既存DB 既存システム

Slide 51

Slide 51 text

51 Step1 機能のデータベース切り出し既存DB 既存システム新DB 機能毎に切り出し

Slide 52

Slide 52 text

52 Step2 新システムからも読み書き既存DB 新DB 既存システム機能を切り出した新システム

Slide 53

Slide 53 text

53 Step3 新システムから新サービスに書き込み・参照既存DB 新DB 既存システム機能を切り出した新システム API経由で読み書き ※必要に応じて

Slide 54

Slide 54 text

54 Step4 どんどん既存システムから機能を切り出す既存DB Module A 既存システム機能を切り出した新システム既存システムの機能をたくさん切り出していく Module B

Slide 55

Slide 55 text

55 Step5 既存システムをもぬけの殻にする既存DB 既存システム機能を切り出した新システム Module A Module B

Slide 56

Slide 56 text

56 Step6 新システムに完全移行機能を切り出した新システム Module A Module B

Slide 57

Slide 57 text

57 既存システム段階的に移行していく事がポイント

Slide 58

Slide 58 text

58 色々なケースがあります

Slide 59

Slide 59 text

59 本番環境へのリリース

Slide 60

Slide 60 text

60 スムーズなモダナイズ？

Slide 61

Slide 61 text

61 結論

Slide 62

Slide 62 text

62 開発体験をあげて小さいリリースをたくさんして成功体験を積もう

Slide 63

Slide 63 text

63 直接手で動作確認してませんか？

Slide 64

Slide 64 text

64 Test書こう

Slide 65

Slide 65 text

65 Testは絶対に書く結局、テストを書かないとモダナイズの意味が無い・動作確認で直接手を動かす癖をやめる（もちろん手動テスト全部やめようとまでは言わない）・動作確認としてテストがある状態

Slide 66

Slide 66 text

66 Testは絶対に書く結局、テストを書かないとモダナイズの意味が無い・動作確認で直接手を動かす癖をやめる（もちろん手動テスト全部やめようとまでは言わない）・動作確認としてテストがある状態・あとから挙動を確認するときにテストは有用・→テストから何をやっているのか一発で分かる

Slide 67

Slide 67 text

67 Testは絶対に書く結局、テストを書かないとモダナイズの意味が無い・動作確認で直接手を動かす癖をやめる（もちろん手動テスト全部やめようとまでは言わない）・動作確認としてテストがある状態・あとから挙動を確認するときにテストは有用・→テストから何をやっているのか一発で分かる今日書いたコードは将来のレガシーコード

Slide 68

Slide 68 text

68 小さくリリースする小さいリリースを繰り返す全てを一度で実装する必要は無い。 Feature Flagを活用しつつ新機能や改修をガンガンリリースしていく

Slide 69

Slide 69 text

69 小さくリリースする小さいリリースを繰り返す全てを一度で実装する必要は無い。 Feature Flagを活用しつつ新機能や改修をガンガンリリースしていく小さいリリースをして実際にシステムを本番環境にデプロイする切り戻しが容易な粒度でリリースを繰り返す

Slide 70

Slide 70 text

70 小さくリリースする小さいリリースを繰り返す全てを一度で実装する必要は無い。 Feature Flagを活用しつつ新機能や改修をガンガンリリースしていく小さいリリースをして実際にシステムを本番環境にデプロイする切り戻しが容易な粒度でリリースを繰り返す小さい本番リリースが恐くて逆に一気にリリースすると Big Bang Rewrite 何かあっても小さく切り戻しが出来るようにする

Slide 71

Slide 71 text

71 成功体験成功体験を積んでいく成功体験を積んでいき、チーム全体のレベルを上げていく成功体験が増えれば、ステップアップできる新しい技術スタックに挑戦する余裕が出来てくる Microservices, Kubernetes, DynamoDB, etc…

Slide 72

Slide 72 text

72 成功体験成功体験を積んでいく成功体験を積んでいき、チーム全体のレベルを上げていく成功体験が増えれば、ステップアップできる新しい技術スタックに挑戦する余裕が出来てくる Microservices, Kubernetes, DynamoDB, etc… 仮に失敗しても、Strangler Fig Patternの小さい失敗は後戻りができる

Slide 73

Slide 73 text

73 成功体験成功体験を積んでいく成功体験を積んでいき、チーム全体のレベルを上げていく成功体験が増えれば、ステップアップできる新しい技術スタックに挑戦する余裕が出来てくる Microservices, Kubernetes, DynamoDB, etc… 仮に失敗しても、Strangler Fig Patternの小さい失敗は後戻りができる失敗は次に活かす︕

Slide 74

Slide 74 text

74 ・・・と、ここまで教科書的な事を言ってきましたが

Slide 75

Slide 75 text

75 実際問題、きつくね？

Slide 76

Slide 76 text

76 壁はたくさん結局、これらをうまく回す人, 組織を作る必要がある

Slide 77

Slide 77 text

77 壁はたくさん結局、これらをうまく回す人, 組織を作る必要があるモダンな技術スタックの開発経験があるメンバーが少なかったり言語・ライブラリ・アーキテクチャ選定に対する知見が少なかったりそもそもCI/CD, Gitに入門する必要があったりアジャイル開発と言っても実質ウォーターフォールになってたり経験が無いと回避出来ないトラップがたくさんあったり

Slide 78

Slide 78 text

78 壁はたくさん結局、これらをうまく回す人, 組織を作る必要があるモダンな技術スタックの開発経験があるメンバーが少なかったり言語・ライブラリ・アーキテクチャ選定に対する知見が少なかったりそもそもCI/CD, Gitに入門する必要があったりアジャイル開発と言っても実質ウォーターフォールになってたり経験が無いと回避出来ないトラップがたくさんあったり道筋を案内できるリードエンジニアが必要

Slide 79

Slide 79 text

79 クラスメソッドのモダンアプリケーションコンサルティング

Slide 80

Slide 80 text

80 支援内容

Slide 81

Slide 81 text

81 支援内容

Slide 82

Slide 82 text

82 事例本プロジェクトではクラスメソッドは単なる請負開発ではなく、積極的に旭化成のエンジニアの方々に対して、スキルトランスファーを実施しています。この部分において、プロジェクトメンバーの皆さんから大きな評価をいただいています。たとえば我々としては正しいと取り組んでいる事項についても、それを外部の目から評価・改善提案していただくなど、非常に学びが多い時間でした。特に、受発注者という枠を超えて、チームの一員として取り組んでいただけたことが、良い結果につながったと感じています。 https://classmethod.jp/cases/asahi-kasei/ より抜粋

Slide 83

Slide 83 text

83 事例 https://classmethod.jp/cases/asahi-kasei/ より抜粋

Slide 84

Slide 84 text

84 クラスメソッドスポンサーブースやっております！

Slide 85

Slide 85 text

85 黄色いTシャツを着たクラスメソッド社員にお声がけください！