新規構築や移行時のリスクを軽減、「ストラングラーパターン」とは？：特集：マイクロサービス入門（5）

モノリシックなサービスをマイクロサービス化する際、どのように移行させればいいのか。オイシックス・ラ・大地の川上徹氏がOisixのマイクロサービス移行に当たって採用したアプローチと開発プロセスを紹介します。

[川上徹，オイシックス・ラ・大地]

　今回は、ECサイトのOisixをマイクロサービスアーキテクチャへ移行するに当たって採用したアプローチを紹介する。OisixはJavaによるServletベースのWebアプリケーションで、画面表示にはJSP（JavaServer Pages）を用いている。このシステムをマイクロサービス化するに当たって、以下の構成になるよう目指した。

• バックエンドの業務ロジックを全てステートレスな「RESTful API」として実装する
• フロントエンドの実装をアプリケーションサーバから分離する
• 迅速にサービスを開発するため、アーキテクチャや開発プロセスを整備する

システム移行のアプローチ

　まず前提として、別のシステムとして新規にスクラッチで構築するのではなく、既存のサイト、業務を回しながら段階的に移行するアプローチを採用した。

　新しいアーキテクチャを採用するに当たって技術的なリスクがあることはもちろん、稼働していないシステムの開発のためにチームを長期間維持するコスト面のデメリットも大きく、事実上不可能と判断したためだ。

ストラングラーパターン

　「システムを段階的に移行する」ためのアプローチとして採用したのがストラングラーパターンだ。既存のアプリケーションと新しいアプリケーションを振り分ける「ストラングラーファサード」というレイヤーを設け、機能の特定部分を新しいアプリケーションに徐々に置き換えながら機能を移行する手法だ。

　Oisixでは、ストラングラーファサードに、以前より利用していたALB（Application Load Balancer）サービスとAPI Gatewayサービスを利用した。

ストラングラーパターンを用いた移行の流れ

　ALBサービスを用いて新規アプリケーションに対するルーティングを制御し、API Gatewayサービスを用いてRESTful APIとして開発するアプリケーションに対するルーティングを実装した。

　同一ドメインに対するリクエストをパスに応じて振り分けることで、フロントエンドのアプリケーションサーバからの分離と業務ロジックのAPI化を段階的に実施できるようにした。

パイプラインファースト

　昨今「パイプラインファースト」という言葉を聞くことがある。アプリケーションを開発する際、まずCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインを整備するというものだ。これはマイクロサービスアーキテクチャを用いて開発する際にも重要なアプローチだと言える。

　マイクロサービスアーキテクチャを採用して変更に強いシステムを目指すのは、アプリケーションに対して何度もアップデートしたり新機能を追加したりする必要があるからだ。リリースするときの「手動テスト」や「手動デプロイ」といったものを極力減らさないと工数が増えてしまい、開発スピードを落としてしまう恐れもある。自動テストや自動デプロイを取り入れたCI/CDパイプラインを構築することで、マイクロサービスアーキテクチャのメリットを高められるわけだ。

　どの企業でも、新しいアーキテクチャを採用する際にはPoC（Proof of Concept：概念実証）を行ってから導入を進めると思うが、その際にはぜひCI/CDパイプラインも検証項目に含めることを推奨したい。

開発者向けのアプローチ