1年間モダンなアプリへの移行支援をやってみて分かった、モダナイズの重要性と難しさ

by mokocm

Slide 1

Slide 1 text

1年間モダンなアプリへの移行支援をやってみて分かった、モダナイズの重要性と難しさ 2023/07/08 AWS事業本部モダンアプリケーションコンサルティング部門別優多

Slide 2

Slide 2 text

#devio2023

Slide 3

Slide 3 text

本セッションは 1年間実際に内製化/モダナイズ支援を行ってきた上で詰まった壁を紹介していきます

Slide 4

Slide 4 text

注意事項 • AWS/クラウドの話はほぼしません • 組織の開発レベルは初級〜中級くらいを想定しています • こんな壁があるんだ〜(わかる〜)といった感じで聞いていただけると！

Slide 5

Slide 5 text

自己紹介門別優多 – moko クラスメソッド株式会社 AWS事業本部モダンアプリケーションコンサルティング部 Twitter, GitHub: @mokocm モダンアプリコンサル部の立ち上げしました 4年間ほどAWSのコンサルティング、開発、モダナイズ支援などやってます 2020-2023 Japan AWS Top Engineer 2021, 2023 Japan AWS All Certifications Engineers 2022年技能五輪国際大会クラウドコンピューティング職種敢闘賞最近頑張ってる事: DDD

Slide 6

Slide 6 text

前編 https://dev.classmethod.jp/articles/aws-dev-day-2023-legacy-system-modernize/

Slide 7

Slide 7 text

Agenda ・モダンアプリコンサル is 何？・モダナイズの重要性・モダナイズの種類・フェーズ別の壁と克服策

Slide 8

Slide 8 text

モダンアプリコンサル

Slide 9

Slide 9 text

テックリードみたいな事してます！

Slide 10

Slide 10 text

モダナイズの重要性

Slide 11

Slide 11 text

レガシーシステムの課題レガシーシステムのよくある課題 EOLを迎えている。運用コストが高いサービスそのものが使いにくいそもそもシステムがブラックボックスで、変更が出来ない

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

あるべき姿の整理あるべき姿運用コストを下げたい新機能を沢山、素早くリリースしていきたい操作しやすいUIで顧客体験をよくしたい(機能改善) レガシーシステムから身動きが取れる状態にしたい

Slide 14

Slide 14 text

あるべき姿の整理あるべき姿運用コストを下げたい新機能を沢山、素早くリリースしていきたい操作しやすいUIで顧客体験をよくしたい(機能改善) レガシーシステムから身動きが取れる状態にしたいスピーディーで継続的な改善が必要 +自社でしっかり管理していくケースが増えてきている

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

レガシーシステムの刷新モダナイズが必要！

Slide 20

Slide 20 text

モダナイズの種類

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

「システムのリプレース」

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Rewrite: Stranger Fig Pattern

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

…といった理想論はさておき……

Slide 28

Slide 28 text

今回のメインディッシュ

Slide 29

Slide 29 text

モダナイズ、内製化実際問題、きつくね？

Slide 30

Slide 30 text

つらいポイントたくさんある

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

理想論ばっか話しても仕方ない

Slide 34

Slide 34 text

自分なりにぶつかった壁と克服した策をご紹介します

Slide 35

Slide 35 text

モダナイズ立案段階

Slide 36

Slide 36 text

最先端の技術に夢見がち

Slide 37

Slide 37 text

最先端の技術に夢見がち - Microservices/Serverless/NoSQL, etc…にすれば解決する訳では無い - 最先端の技術を導入する＝モダナイズではない - エンジニアのスキルセットと最新技術のギャップもある - 慣れるまで開発速度が落ちる - 大規模移行するとBig Bang Rewriteになってしまいがち

Slide 38

Slide 38 text

最先端の技術に夢見がち - 目的が「新しい技術使いたい」になってないかは要確認 - (それはそれで良いマインドだとは思います) - 大半において、コンテナ+モジュラーモノリスで済む - 導入するにしても、小さい規模で初めて、小さくリリースする

Slide 39

Slide 39 text

最先端の技術に夢見がち - 目的が「新しい技術使いたい」になってないかは要確認 - (それはそれで良いマインドだとは思います) - 大半において、コンテナ+モジュラーモノリスで済む - 導入するにしても、小さい規模で初めて、小さくリリースするステップアップで導入しよう！

Slide 40

Slide 40 text

技術選定どうしよう

Slide 41

Slide 41 text

技術選定どうしよう - 無数の技術とツールを選択するのは難しい - 技術スタック・言語選定は、開発者のリソース・採用まで響く - 最初の技術選定をミスると、ずっとつらい 😇

Slide 42

Slide 42 text

技術選定どうしよう - 無数の技術とツールを選択するのは難しい - 技術スタック・言語選定は、開発者のリソース・採用まで響く - 最初の技術選定をミスると、ずっとつらい 😇 - 技術のトレンドは常に変わるため、陳腐化していく物もたくさんある

Slide 43

Slide 43 text

技術選定どうしよう - エンジニアの採用が容易そうな技術選定をすると、将来的には詰まりにくい（肌感）

Slide 44

Slide 44 text

技術選定どうしよう - エンジニアの採用が容易そうな技術選定をすると、将来的には詰まりにくい（肌感） - フロントがTypeScriptで書かれるため、Backendも合わせて TypeScriptを採用するケースを最近はよく見た - TypeScriptで苦しくなってきたら他の言語に移行するようなケースが多い（肌感）

Slide 45

Slide 45 text

Slide 46

Slide 46 text

認証サービスどれにしよう

Slide 47

Slide 47 text

認証サービスどれにしよう認証サービスで誤った選択をすると、全てに影響する - 既存の認証方法からの移行方法も検討しないといけない - 個人的にはAuth0かFirebase Authentication(Google Identity Platform) - なお、政治的な理由で認証サービスを決めるべきではありません

Slide 48

Slide 48 text

Slide 49

Slide 49 text

既存システムがブラックボックスでつらい

Slide 50

Slide 50 text

既存システムがブラックボックスでつらい既存システムの内部構造や振る舞いが不明で、理解するのが困難 - システムのドキュメントが存在しない - システムに対する深い知識を持つスタッフが不足/退職している - そもそもパッケージ製品でソースコードの中身は見れない - システムの更新や修正が困難で、リスクが高い

Slide 51

Slide 51 text

既存システムがブラックボックスでつらい - システム面からのアプローチではなく、業務面からのアプローチをする - 本来やりたかった事を整理して、新しいシステムとしてリリースする - 小規模な実装から始めて、システムの理解を深めて行く - ここである程度のBig Bang Rewrite/Releaseは致し方ない

Slide 52

Slide 52 text

既存システムがブラックボックスでつらい - システム面からのアプローチではなく、業務面からのアプローチをする - 本来やりたかった事を整理して、新しいシステムとしてリリースする - 小規模な実装から始めて、システムの理解を深めて行く - ここである程度のBig Bang Rewrite/Releaseは致し方ない - 完全にブラックボックスな場合、既存のデータを見ながら移行していく

Slide 53

Slide 53 text

Slide 54

Slide 54 text

モダナイズ始動段階

Slide 55

Slide 55 text

どの機能からモダナイズしていく？

Slide 56

Slide 56 text

どの機能からモダナイズしていく？どの機能からモダナイズしていけば良いのか？簡単＝他の箇所と絡み合っていない箇所、取得系など難しい=他の箇所と絡みまくって何やってるか分からん

Slide 57

Slide 57 text

どの機能からモダナイズしていく？どの機能からモダナイズしていけば良いのか？簡単＝他の箇所と絡み合っていない箇所、取得系など難しい=他の箇所と絡みまくって何やってるか分からん次の順番でステップアップで実施する 1. ビジネス的に重要ではなく、簡単な所から着手 2. ビジネス的に重要で、簡単な所を着手 3. ビジネス的に重要で、難しいところを着手 4. ビジネス的に重要ではなく、難しいところを着手

Slide 58

Slide 58 text

Slide 59

Slide 59 text

成功体験だいじ！ 59

Slide 60

Slide 60 text

モダナイズ実践リリース段階

Slide 61

Slide 61 text

Stranger Fig Pattern きつくね？

Slide 62

Slide 62 text

Stranger Fig Pattern、きつくね？ Stranger Fig Pattern、きつくね？ - 新旧システム同時稼働の弊害、きつい - 既存のテーブル設計からデータを切り離すのも一苦労 - 分離した新システムと旧システム間のデータの繋がりがある場合は、考える事が爆増する - 既存のAPI設計が微妙/そもそもAPI化されていない場合など、改修する箇所が増えていく可能性もある - かといって古いAPI設計のまま再実装するべきかもムズい話題

Slide 63

Slide 63 text

Stranger Fig Pattern、きつくね？ - データベースとシステムの分割・分離方法は多数あるので各種メリ/デメを元にして検討する - オライリーの「モノリスからマイクロサービスへ」が良書

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Stranger Fig Pattern、きつくね？ - データベースとシステムの分割・分離方法は多数あるので各種メリ/デメを元にして検討する - オライリーの「モノリスからマイクロサービスへ」が良書 - 旧API設計が微妙な場合は、Feature Flag等で新設計(環境)を使えるようにする - まずは小さい粒度で良いので、分離して経験を積むのが一番の近道 - Big Bang Rewriteが完全なる悪ではない - Big Bang Rewriteの方が早く安定性を持ってリリースできるのであれば諦めるのも手

Slide 66

Slide 66 text

Slide 67

Slide 67 text

リリースが恐い

Slide 68

Slide 68 text

リリースが恐いリリースが恐い - 新機能の不具合・予期せぬ問題が起こるリスクがある - ユーザーに悪影響を与えてしまい、信頼を失う恐れがある - リリースのロールバック手順が確立されていない - 過去に事故っちゃったので、恐い

Slide 69

Slide 69 text

リリースが恐いリリースが恐い - 新機能の不具合・予期せぬ問題が起こるリスクがある - ユーザーに悪影響を与えてしまい、信頼を失う恐れがある - リリースのロールバック手順が確立されていない - 過去に事故っちゃったので、恐いリリースが恐いので、逆にまとめてリリースしてしまいがち

Slide 70

Slide 70 text

リリースが恐い克服策 - たくさんリリースすることは、スピードを上げるために不可欠 - 我らがGitHubもちょくちょく障害を起こしている - 大前提として完璧は無理。著名なサービスも障害は起こしている

Slide 71

Slide 71 text

リリースが恐い克服策 - たくさんリリースすることは、スピードを上げるために不可欠 - 我らがGitHubもちょくちょく障害を起こしている - 大前提として完璧は無理。著名なサービスも障害は起こしている - Testを書いて再現可能な動作確認をする - Testを書いていないケースで意図しないバグが発生する

Slide 72

Slide 72 text

リリースが恐い克服策 - たくさんリリースすることは、スピードを上げるために不可欠 - 我らがGitHubもちょくちょく障害を起こしている - 大前提として完璧は無理。著名なサービスも障害は起こしている - Testを書いて再現可能な動作確認をする - Testを書いていないケースで意図しないバグが発生する - 常にリリース・ロールバックができるようにする - 何かあったときはロールバックが容易な粒度でリリースする

Slide 73

Slide 73 text

Slide 74

Slide 74 text

まとめ

Slide 75

Slide 75 text

まとめ • 壁はたくさんあるけど、1個1個乗り越えていかないといけない • システム/組織の特性などによってやり方は無限大 • 小さい規模で実際にやってみて、経験値を積むのが一番早い近道 • 参考になれば…!

Slide 76

Slide 76 text

No content