こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。
私はAWSの DEV DAY 2023 TOKYOに参加させていただきました
その中で DAY 2 の「レガシーシステム、モダナイズへの道筋」というセッションを試聴したため、概要や私なりの感想を記事として投稿したいと思います！
【2023/6/26 追記】
スピーカーの門別により、登壇資料などが公開されていますので、ぜひご確認ください！
スピーカーについて
クラスメソッド株式会社
AWS事業本部コンサルティング部 ソリューションアーキテクト
門別 優多 氏
AWS事業本部コンサルティング部にAWSエンジニアとして入社。
その後開発部門へ異動し、モダンアプリケーション開発に携わる。
再びコンサルティング部へ戻り、新たなモダンアプリコンサルサービスの提供を開始する。
AWSを活用したアプリケーションの開発、並びにモダンアプリケーションコンサルティングが得意。弊社の門別がスピーカーであり、私もまっさらな状態で楽しまさせてもらいました。
セッションの構成
【2023/6/26 追記】
再掲となりますが、スピーカーの門別により、登壇資料などが公開されていますので、ぜひご確認ください！
目次は以下のとおりでした。
- なぜモダナイズをしたい？
- モダナイズ種類
- マイクロサービスするべき？
- システムとデータベースの共存・分離
- 本番環境へのリリース
- レガシーシステムモダナイズへの道筋
以下はそれぞれの章について、内容の簡単なまとめと私の感想を記載いたします。
なぜモダナイズしたいのか
レガシーシステムのよくある課題をあげながら、モダナイズへ向けたモチベーションや目指したい利用の姿について話をしていました。
例えばレガシーシステムの課題としては以下のようなものが挙げられていました。
- EOLを迎えている、運用コストが高い
- サービスそのものが使いにくい
- 中のソースコードを見ると設計・実装がつらかった
これらのような原因で開発者体験を損ねたり、結果的に良いものが作れなかったり、微妙だと思っているシステムを改修できなかったりとなりかねないとのこと。
このような状態になると、「負のスパイラルを抜け、改善のサイクルへ向かう」ことが重要になり、レガシーシステムの刷新や、内製化、モダナイズといったものが必要になってくるとのことでした。
モダナイズの種類
モダナイズにも以下のような種類があるとのことでした。
- 既存システムのリファクタリング
- Big Bang Rewrite, Relase
- 既存システムを一から作り直す
- システムのリプレースでは選択されがち
- リリースのリスクは高い
- Strangler Fig pattern
- 既存システムの機能ごとに徐々にリライトしていくパターン
- 部分的に新システムに切り替えるためリスクを最小限にできる
スピーカーとしては Strangler Fig pattern がおすすめとのこと。
AWSでやる一例としては、旧システムとは別に新システムを稼働（例えばECS Faragateなどで）し、特定の機能を呼び出す処理について、新システムにトラフィックを流すようなことです。
例えばALBなどで特定のパスに対しては新システムの方に流すような形です。(/v2/blogs というパスに関しては新システムにトラフィックを流し、それ以外は旧システムに流すような。)
マイクロサービス化するべきか
最初にスピーカー的結論を述べていました。
「ステップアップで導入がおすすめ」
というのも、マイクロサービスには多くのメリットがあるものの、サービス間通信・トランザクションの管理・SAGAパターンなど考えることが多いとのこと。
スピーカーとしては「まずはレガシーシステムから身動きが取れる状態にすること」が大事であると話をされていました。
スピーカーは「小さく成功体験を積んでチームのレベルを上げる」ということを繰り返し話をしていたので、いきなり全てマイクロサービスに移行！とするよりも、小さく変更や機能改修をできる状態にしていくことが先決ということをお話ししていたのかと思います。
また、既存システムが動作している限り既存のDBから新規DBへの移行は避けては通れないため、考える必要があるとのこと。
具体的には以下のようなパターンを紹介されていました。
新システムへのDB移行パターン1（既存DBを参照する新システムのパターン）
主に以下のようなステップを踏むパターンです。
- 既存DBを参照する新システムを作成
- 移行が完了後、新システムだけにする
- 新システムだけの稼働にするときに、大規模な改修とかが必要になる可能性が高い
- 可能ならば少しづつリライト・リリースする
- 新システムでDB設計の見直しをする
一見良さそうに見えるのですが、移行が完了後、新システムだけにするの際に、大規模な変更・大規模なリリースになりがちというデメリットがあるとのこと。
新システムへのDB移行パターン2（既存のレガシーシステムにAPIを作る場合）
技術的負債を解決する前に、機能を実装する必要がある場合もあるとのこと。
そのような場合には以下のパターンが考えられるとのこと。
- 既存システムにAPIを追加
- 既存システムのAPIをよぶ新システムを作成
- 既存システムのAPIをサービスとして分離
- データベースを分離する
新システムへのDB移行パターン3（データベースとサービスを分離する場合）
- 機能のデータベース切り出し
- 新システムからも読み書き
- 新システムから新サービスに書き込み・参照
- どんどん既存システムから機能を切り出す
- 既存システムをもぬけの殻にする
- 新システムに完全移行する
ここでもスピーカーは「既存システムから段階的に移行していくことがポイント」と話していました。
いずれのパターンにしろ、大きな変更を一発で切り替え！ということではなく、小さな単位で変更や切り替えをしていくことがおすすめ。ということを言いたかったのかと感じました。
本番環境へのリリース
スムーズなモダナイズとは？
スピーカー的な結論としては「開発体験をあげて小さいリリースをたくさんして成功体験を積もう」とのこと。
開発体験をあげるとは？以下のような例があるとのこと。
- 手で動作確認をせずにテストを書く（テストは絶対に書く）
- 状態を持たないテストから書いていく
- 最低限ビジネスにコアに関わる領域など
- テストを書かないとモダナイズの意味がない
- 手動テストを全部やめるという意味ではない
- 動作確認としてテストがある状態
- 小さくリリースする
- Feature Flagを活用、新機能や改修をリリースする
- 切り戻しができる小さな粒度でリリースをしていく
- 成功体験を積む
- チームのレベルを上げるのに必要不可欠
- 成功体験を踏むことで、新しい技術スタックに挑戦する余裕が出てくる
- 失敗は次に活かす！
「今日書いたコードは将来のレガシーコード」という意識を忘れない。
レガシーシステムモダナイズへの道筋
スピーカー： と、ここまで話してきたものの「実際問題きつくね？」とのこと。
簡単に「モダナイズ」といっても、以下のような壁がたくさんある
- 言語・フレームワーク選定
- 特にフロントエンドは移り変わりが激しい
- CI/CD、Gitに入門する必要がある
- アジャイル開発と言っても実質ウォーターフォールになるなど
- 経験がないと回避できないトラップがあるなど
道筋を案内できるリードエンジニアが必要とのこと。
レガシーシステムの悪循環から抜けることが何よりも重要。
その他（弊社サービス紹介を含みます）
※ こちらのブロックに関しては弊社サービスの紹介を含むため、興味がない場合は次のブロックへ進んでいただきますようお願いいたします。
残りのわずかな時間でクラスメソッドのモダンアプリケーションコンサルティングサービスについて紹介がありました。
これまで話してきた壁を越えるようにリードするような役割で、内製開発を支援するサービスを提供しています。
- 言語の選定・FWの選定
- AWSアーキテクチャの設計
- それらアーキテクチャを活かすためにアプリ側をどのように記述するのか
- 弊社メンバーがお客様の開発メンバーの中に入り、ペアプロやモブプロなども行うなどスキルトランスファーも行う
以下事例についても紹介していました。
私なりの感想
特に以下のようなことを繰り返しスピーカーが言っていました。
- 開発体験を上げて小さくリリース
- 小さくリリースを上げて、成功体験を積み上げる
- チームのレベルを引き上げる
これに関しては私の体験としても非常に納得感がありました。
また、リファクタリングをするにも新システムを作ることに対しても「絶対にテストを書け」という強いメッセージを感じました。
リファクタリング(第2版): 既存のコードを安全に改善するという書籍においても、「リファクタリングをする時に最初にやることは必ずテストを書く」というようなことが記載されています。
リファクタリングという言葉の定義を「外部からの振る舞いを変えずに、ソフトウェアの内部をわかりやすく・簡単に変更できるようにすること」とすると、外部からの振る舞いを変えずにということを担保するにはテストが必要になりますよね。
スピーカーは「まずレガシーコードから身動きが取れるように表現する」といっていましたが、テストが充実していない場合などは、旧システムに対して有効なテストを書いていくことから移行を考えないと「とんでもないことになるな」と再認識できました。
また、小さくリリースすることで開発者が「レベルアップ感」「楽しいという感覚」を感じることに関しても実体験として納得感があります。
終始「実際のところどうするの」というポイントを押さえた発表であると感じており、私は講演中にずっと頷いていました。
私がスピーカーとおなじ会社に勤めているため情が移ったためかと考えていたのですが、3席ほど隣の方も首がもげるように頷いていたので、開発経験のある方にはたまらない、学びのあるセッションだったように思います。
本イベントのクロージングセッションにて、各セッションの動画に関してはオンデマンド配信される旨が説明されていました！
もし今後配信されれば、本記事でもURLなどを紹介したいと思います。
本記事では、私の意見や感想を多分に含んでいるため、ぜひみなさんセッションを見ていただき、スピーカーの伝えたいことを考えていただければと思います。
以上、最後までご覧いただきありがとうございました。
今泉でした。
5
