新規構築や移行時のリスクを軽減、「ストラングラーパターン」とは？：特集：マイクロサービス入門（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パイプラインも検証項目に含めることを推奨したい。
開発者向けのアプローチ
迅速にサービスを開発するためアーキテクチャや開発プロセスを整備するという観点でOisixでの取り組みを紹介する。いわゆる「Developer Experience」（DX）を向上させるための取り組みともいえる。
前述の通り、システム移行のアプローチとして「パイプラインファースト」を挙げたが、ただテストやデプロイを自動で実行する他に、さまざまなステップをCI/CDパイプラインに組み込むことでDXを向上させられる。本記事では、Oisixのアプリケーション開発でパイプラインに組み込んでいるステップを幾つか紹介する。
テスト／カバレッジレポートの取得
CIパイプライン上で実行されるテストの結果やテストによって品質が保証されている機能とそうでない機能をまとめたカバレッジレポートをビルドの成果物として保存している。
RESTful APIとして開発している新規アプリケーションで、プログラミング言語としてJavaやKotlin、ビルドツールとしてオープンソースの「Gradle」を利用しており、プラグインを利用することでカバレッジレポートを取得できる。
GitHubリポジトリに送られたPull Requestを通じてコードをレビューする際にひも付いたビルドからテスト／カバレッジレポートを参照してレビューできる環境を実現している。
コードフォーマットチェック
長期にわたってアプリケーションを開発していると、フォーマットがそろっていないソースコードが増え、可読性を下げることがある。CIパイプラインの先頭でコードフォーマットをチェックして、不正である場合にはエラーを返すよう設定している。これにより、可読性が下がるのを防いでいる。
これはGradleのプラグインを使用して実現している。
静的解析
フォーマットチェックと同様に、静的解析もCIパイプライン内で実行させ、結果をモニタリングできるようにしている。
静的解析を行うことで、テストだけでは検出できない不具合を未然に防ぐことができる。製品によって異なるが、特にテストの難しいセキュリティ観点での不具合を検知できるなど、受けられるメリットは大きい。
パイプラインの構築に利用しているサービスやプログラミング言語で実現方法は異なると思うが、どのサービスを利用していても近しいことが実現可能なはずなので検討してみてほしい。
「OpenAPI Specification」の活用
Oisixでは、RESTful APIのインタフェース設計にOpen API Initiative が公開しているAPIのオープン規格「OpenAPI Specification」を使用している。オープンソースソフトウェア（OSS）の「OpenAPI Generator」を使用してOpenAPI Specificationから同じインタフェース仕様に従ったクライアント／サーバサイドコードを生成できる。
生成されたクライアントライブラリを使用することで、インタフェースの整合性を過度に気にせずAPIを呼び出す部分を実装できる。
CIパイプラインにおいて、1つのOpenAPI Specificationから複数の言語に対応したクライアントライブラリを生成し、リポジトリにPublishすることで、フロントエンドやスマートフォンアプリから呼び出しやすいサーバサイドアプリケーションを構築している。
OpenAPI Specificationからは、APIの仕様を示すHTMLドキュメント（SwaggerUI）を出力できる。
CIパイプラインの中でドキュメントを生成し、アプリケーションを開発する際はコードレビュー時の資料として活用している。アプリケーションをリリースする際は、指定のクラウドストレージに配置することで運用フェーズにも役立てている。
アプリケーションの実装と仕様を示すドキュメントが実態として乖離（かいり）するケースもよくあるが、この方法を用いて仕様と実装の乖離（かいり）を防ぐアプローチを取っている。
開発リソースの改善
前述したパイプラインの設定は便利である一方で相応に複雑なものであり、各アプリケーションのリポジトリに設定する必要がある。マイクロサービスアーキテクチャを採用するに当たって多数のアプリケーションの開発が必要となり、それぞれにパイプラインやビルドツールを設定すると稼働するツールやそれをまとめるプロジェクトが増えるため、アプリケーションのプロジェクトテンプレートを作成した。
プロジェクトテンプレートの作成に当たって、「lazybones」というプロジェクト作成ツールを採用した。このツールは、ベースとなるファイルセットに対してJavaベースのスクリプト言語「Groovy」による後処理（置換やリネームなど）をコマンドラインから柔軟に実行できる。
コマンド実行時には対話式でパラメーターを入力させることも可能で、新規に開発するアプリケーションの情報を入力するとその時点でビルド可能なアプリケーションのひな型を生成できるようになった。
今回は、Oisixでのマイクロサービス移行に当たって採用したシステム的なアプローチと開発プロセスを紹介した。モノリシックなアプリケーションのマイクロサービス化を決めた際、どのように進めていくかは各企業や各システムで異なると思うが、Oisixのアプローチが参考になれば幸いだ。
次回は、このようなアプローチをとった結果生まれた課題にどう取り組んだのか紹介する。
筆者紹介
川上徹
金融系のSIerを経て2018年にオイシックス・ラ・大地入社。ECサイトOisixのマイクロサービス化に向けた開発プロセスの整備を実施。好きなプログラミング言語はKotlin。趣味は住宅ローンの繰り上げ返済。野菜よりはお肉が好き。
特集：マイクロサービス入門 「2025年の崖」を乗り越えるためのシステム開発の姿
複雑化、老朽化、ブラックボックス化した既存システムの残存で、2025年以降に予想される経済損失は最大12兆円／年といわれている。これを経済産業省は「2025年の崖」と呼び、企業に警鐘を鳴らす「DXレポート」を公開した。レポートでは、システム開発に取り入れるべきアーキテクチャとして「マイクロサービス」を挙げている。本特集では、マイクロサービスとは何か、システムをマイクロサービスにさせるとどのような課題が生まれるのか、モノリシックなサービスをマイクロサービスに移行させた事例などを通じて、どの場面でマイクロサービスを活用すべきか、現実解を探る。
関連記事
ダイソーが6年でIT内製化、マイクロサービス化、サーバレスに成功した理由
アイティメディアが開催した「ITmedia DX Summit 2019年秋・ITインフラ編」の特別講演にダイソーの丸本健二郎氏が登壇。内製化によって、データ管理基盤の最適化、高度化を図ったいきさつと結果について講演した。
「こんなのクラウドネイティブじゃない」と思うこと
本連載では、2019年7月の「Cloud Native Days Tokyo 2019」でCo-chairを務めた青山真也氏と草間一人氏に、クラウドネイティブに関してじっくり語ってもらった対談の内容を、4回に分けて掲載している。今回は最終回として、「『こんなのクラウドネイティブじゃない』と思うこと」をお届けする。
DXも台無しにしかねない日本企業の「ソーシング問題」――「内製化が難しい」なら、どう戦うか？
デジタルトランスフォーメーション（DX）の潮流が高まる中、社会全体で「イノベーション」や「スピード」といった要素が注目されている。だが、いくら「新たな価値」を生み出したところで、それがビジネス／サービスである以上、信頼に足る品質を担保していなければ意味がない。特に内製が難しいトラディショナルな企業にとっては、一般的なIT活用でもDXにおける価値創出でも、社外の開発・運用パートナーと組むことが不可欠となる。そうした中でも、今のスタンスのままで本当に「ビジネス価値」を生み出すことができるのだろうか？
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。