AWS Summit Tokyoが4年ぶりに現地開催！
この週末、日本で年一回のAWSの祭典「AWS Summit Tokyo」が幕張メッセにて開催されました。
4年ぶりの現地開催ということもあり、2日間ともものすごい数の人々が来場し、会場の熱気は大変なものでした！
大人気セッション「アーキテクチャ道場！」
2日間の中でも特に人気を博していたのが、AWS Japanのチーフテクノロジスト内海さんによる「アーキテクチャ道場2023！」。
昨年もオンライン開催にて好評を集めていたセッションで、30分という限られた時間内でAWS JapanのSAさんがお題に基づいてガチのアーキテクティングを行い、内海さんからその講評を受けるという流れを2本連続で実施する、大変濃密なコンテンツです。
私も最前列でガチ受講していましたので、自社ブログにて詳細なレポートを投稿しております！
実はこのアーキテクチャ道場2023！内で、聞き慣れないシステム移行の戦略「レガシーミミックパターン」と「ストラングラーフィグパターン」がさらっと言及されていました。
日本語の情報が意外と少なかったため、このQiita記事ではこれらの移行戦略について調べた内容をみなさんにも紹介させていただこうと思います。
レガシーミミックパターンとは？
ミミックと聞くと、有名なRPGに登場するニセの宝箱を思い浮かべる方は多いのではないでしょうか？
この設計戦略も実は同じ意味合いで命名されており、宝箱ではなくレガシーシステムに「擬態する（mimic）」というニュアンスです。
古いシステムを少しずつ新システムへ移行していく際、特にトランザクション系のシステムにおいてデータは常に最新である必要があります。上記ブログでは旧システムの「灯を消さないように」と表現されています。
レガシーミミックパターンは有名なドメイン駆動設計（DDD）で登場する「Anti-Corruption Layer（衝突回避レイヤー）」を実現するものです。
移行過渡期のシステムからクライアント向けに機能を提供し続けるため、”隔離層”を作成することによって相手側への影響を極小化しようという思想です。
ミミックは主に「プロバイダー」と「コンシューマー」の2種類がよく見られます。
-
「プロバイダー」ミミックはイベント受信の役割をこなす。旧システム上でクライアントからのリクエストを受け付け、新システムへ連携する。これによってクライアント側はシステムが移行中であることを気にしなくてよくなる。
-
「コンシューマー」ミミックはレコード記録の役割をこなす。新システム上で処理された結果を旧システム側のデータストアにも連携する。これによって新旧システム間でのツジツマを合わせる。
いずれのミミックも過渡的なもので、最終的には不要になります。
ストラングラーフィグパターンとは？
ストラングラーフィグというのは熱帯植物の名前で、他の樹木に寄生するように育ち最終的に包み込んでしまうそうです。（日本でも屋久島などで見られる模様）
この移行戦略も、まさに古いシステムをすこしずつ置き換えて廃止するプロセスをとります。
具体的なアプローチとして、新旧システムの前段に「ファサード」を配置し、クライアントからのリクエストを新もしくは旧システムへルーティングできるようにします。これによって利用者は宛先変更を意識することなく、シームレスに新システムへ移行することができます。
「ファサード」とはフランス語で玄関（façade）を指します。一昔前のサービス指向アーキテクチャ（SOA）で聞いたことのある方も多いかも知れませんが、まさにシステム利用者にとっての玄関口となるレイヤーを設けるのですね。
※ちなみに今回のアーキテクチャ道場2023！のお題では、「システム利用者が任意のタイミングでシステムを移行できること」という前提条件があったためストラングラーフィグは不適となり、レガシーミミックパターンが採用されていました。
おわりに
今回の記事は私が調べた内容に基づく考察を含んでいるため、もし怪しい点やご指摘等あれば気軽にお知らせいただけると嬉しいです。
弊社メンバー @tempa3taku からも早速、世界最速の「アーキテクチャ道場2023！」受講レポが投稿されています！
今回のセッションで各SAさんの設計アプローチとして共通していた戦略部分にフォーカスし、具体例まで落とした考察記事となっていますので是非ご覧ください。
また、前半のお題の総括で触れられた「Outboxパターン」についても以前に弊社メンバー @yoshii0110 が解説記事を書いていますので併せてご覧ください！