Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

mokocm
July 12, 2023

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

mokocm

July 12, 2023
Tweet

More Decks by mokocm

Other Decks in Technology

Transcript

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

    View Slide

  2. #devio2023

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. モダンアプリコンサル

    View Slide

  9. テックリード
    みたいな事してます!

    View Slide

  10. モダナイズの重要性

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  20. モダナイズの種類

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  25. Rewrite: Stranger Fig Pattern

    View Slide

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

    View Slide

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

    View Slide

  28. 今回のメインディッシュ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. モダナイズ立案段階

    View Slide

  36. 最先端の技術に夢見がち

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. 技術選定どうしよう

    View Slide

  41. 技術選定どうしよう
    - 無数の技術とツールを選択するのは難しい
    - 技術スタック・言語選定は、開発者のリソース・採用まで響

    - 最初の技術選定をミスると、ずっとつらい 😇

    View Slide

  42. 技術選定どうしよう
    - 無数の技術とツールを選択するのは難しい
    - 技術スタック・言語選定は、開発者のリソース・採用まで響

    - 最初の技術選定をミスると、ずっとつらい 😇
    - 技術のトレンドは常に変わるため、陳腐化していく物もたく
    さんある

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  54. モダナイズ始動段階

    View Slide

  55. どの機能から
    モダナイズしていく?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  59. 成功体験だいじ!
    59

    View Slide

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

    View Slide

  61. Stranger Fig Pattern
    きつくね?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  67. リリースが恐い

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  74. まとめ

    View Slide

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

    View Slide

  76. View Slide