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

リプレイスを安心安全に 〜段階的リプレイスと等価比較〜/Safe and Secure Rep...

リプレイスを安心安全に 〜段階的リプレイスと等価比較〜/Safe and Secure Replacement ~ Phased Replacement and Equivalent Comparison ~

こちらで発表した資料になります。
https://zozotech-inc.connpass.com/event/316086/

Shun Uehara

June 26, 2024
Tweet

Other Decks in Programming

Transcript

  1. © ZOZO, Inc. 株式会社ZOZO 基幹システム本部 物流開発部 基幹リプレイスブロック 上原 駿 2023年2月に株式会社ZOZOに中途入社

    前職のSESのベンチャー企業では、 上流工程からのリプレイスプロジェクト等に尽力。 現在は物流システムのリプレイスに従事。 趣味は、ゲーム(APEX)、野球、筋トレ。 2
  2. © ZOZO, Inc. 解決する課題の決定 • ビジネスロジックの複雑化に伴う機能追加の労力の増大 • 障害の分離が出来ず、単一障害点になってしまっている • Classic

    ASPのサポート終了 13 マイクロサービス化の設計難易度 開発、運用コスト > マイクロサービス化のメリット
  3. © ZOZO, Inc. 入荷リプレイスの概要と要件 [概要] 入荷に関する機能をモジュール化して、独立性を高めることを目的とするリプレイスプロジェクト [要件] • 言語をClassic ASPからJavaに変える

    • モジュラーモノリスに加える • テストコードを追加してデグレを起こさないようにする • 言語を変えても既存と等価であることを担保する • 将来的にマイクロサービス化を検討するためにテーブルの使用箇所を可視化する • これらを段階的にリリースする 14
  4. © ZOZO, Inc. 既存課題と要件の対応 • ビジネスロジックの複雑化に伴う機能追加の労力の増大 ◦ モジュラーモノリスに加える • 障害の分離が出来ず、単一障害点になってしまっている

    ◦ 将来的にマイクロサービス化を検討するためにテーブルの使用箇所を可視化する • Classic ASPのサポート終了 ◦ 言語をASPからJavaに変える ◦ テストコードを追加してデグレを起こさないようにする ◦ 言語を変えても既存と等価であることを担保する 18
  5. © ZOZO, Inc. 段階リリースの流れ 入荷リプレイスの全体像 20 フェーズ1 ビジネスロジックAPI化 フェーズ3 マイクロ

    サービス 化 フェーズ2 フロント エンド メリット • フェーズ定義毎にリリースを行うことで大きな問題を起こしにくい状態になる • リプレイスのゴールを途中で変更することができる      リリース      リリース
  6. © ZOZO, Inc. • ASPで実装しているビジネスロジックをJavaAPI化する • JavaAPIは、既に存在しているモジュラーモノリスに実装する • Javaから基幹DBに参照・更新ができるようにする •

    逆にASPからの基幹DBへのアクセスはしないようにする フェーズ1の定義 21 モジュラーモノリス モノリス BackOffice(ASP) 入荷API(Java) 基幹DB フェーズ1 フェーズX フェーズ2 モノリス フェーズ1 実施 BackOffice(ASP) ユーザー 基幹DB ユーザー 発送API(Java) view ロジック ビジネス ロジック view ロジック ビジネス ロジック
  7. © ZOZO, Inc. フェーズ2の定義 • 入荷用のフロントエンドを実装する • オンプレ依存は基幹DBだけとなる このフェーズまで来ると脱ASPが完了する。 22

    AWS(モジュラーモノリス) モノリス ユーザー 基幹DB 入荷用 フロントエンド フェーズ1 フェーズX フェーズ2 フェーズ 2 実施 モジュラーモノリス モノリス BackOffice(ASP) 入荷API(Java) 基幹 DB view ロジック ビジネス ロジック view ロジック ユーザー 発送API(Java) 入荷API(Java) ビジネス ロジック
  8. © ZOZO, Inc. 等価比較の仕組みを導入 私の経験上、 「処理の等価性はどう担保するのか」は、言語リプレイスの大きな壁の一つであると考えている。 この問題に対して入荷リプレイスでは、機械的に等価性を判断してくれる自動テストの仕組みを導入 した。 自動テストをするためには、本来入力値と期待値が必要。 今回は本番環境のユーザー入力と既存システムの出力を使用してテストした。

    この仕組みのおかげで普段よりも正確に、かつ膨大な量のテストをすることが可能になった。 また、本番環境の入力値を使用しているので、潜在的なバグが見つかるなどの嬉しい副産物もあっ た。 フェーズ1では、このようにして「処理の等価性を担保した」 25 フェーズ1 フェーズX フェーズ2
  9. © ZOZO, Inc. 等価比較する 等価比較の仕組み〜取得系処理図解〜 26 本番リクエスト 比較用ファサード 旧実装 (ASP)

    新実装 (Java) 期待値となる 処理結果 (JSON) 処理結果 (JSON) フェーズ1 フェーズX フェーズ2
  10. © ZOZO, Inc. 等価比較する 等価比較の仕組み〜取得系処理図解〜 27 本番リクエスト 比較用ファサード 旧実装 (ASP)

    新実装 (Java) 期待値となる 処理結果 (JSON) 処理結果 (JSON) フェーズ1 フェーズX フェーズ2 本番リクエスト/期待値(旧実装の値)となる 処理結果のペアで新実装の自動テストをしている Slack通知 DB登録 不等価
  11. © ZOZO, Inc. 基幹DB 共通のIDと共にDBに履歴 を残す 等価比較の仕組み〜更新系処理図解〜 28 旧実装 (ASP)

    新実装 (Java) 旧実装のSQL 実行履歴 (共通ID) 新実装のSQL 実行履歴 (共通ID) 本番リクエスト 比較用ファサード ※新実装の更新処理はコミットせずにロールバックする 全実行履歴の 等価比較バッチ 比較処理 Slack通知 比較結果のDB登録 ※旧実装の更新処理はコミットする 新旧実行履歴 フェーズ1 フェーズX フェーズ2
  12. © ZOZO, Inc. 比較期間 : 取得系 1週間くらい 更新系 2週間くらい 不具合が出たら修正する

    等価比較の仕組み〜等価比較中〜 29 フェーズ1 フェーズX フェーズ2 モジュラーモノリス モノリス BackOffice(ASP) 基幹DB ユーザー 発送API (Java) 不等価 入荷API(Java) 等価比較API (Java)
  13. © ZOZO, Inc. 等価比較の仕組み〜メリデメ〜 [メリット] • 自動テストの入力値が本番の値なので本番運用後の不具合が出づらい • 本番運用前に本番環境でテストができる •

    充分な検証の後なので安心して本番運用に新実装を乗せられる • エビデンスの用意に手間がかからない • 入力値や期待値の準備がいらない [デメリット] • 等価比較を実施すると処理量は増えるので本番環境に高負荷がかかってしまうことがある 31 フェーズ1 フェーズX フェーズ2
  14. © ZOZO, Inc. まとめ このように段階的にリプレイスを進め、等価比較などを駆使した結果、安心安全にリプレイスを進め ることができました。 現状はフェーズ2に差し掛かっている状態です。 フェーズ2までは確実に行いますが、マイクロサービス化を進めるかどうかはまだ未定です。 ただし、この選択がそもそもできるのは段階的にフェーズを分けて、リプレイスを進めているからで す。

    立ち止まり、進むか止めるか一度考えることができるのがこのリプレイスの最大のメリットです。 もし、自社システムのリプレイスを検討しているのであれば、 こういった方法でのリプレイスも選択肢の一つとして検討してもらえると嬉しいなと思います。 33