10年間運用されてきたウェブサービスをモノリシックから変化に対応しやすいマイクロサービスアーキテクチャーへ

始めに

こんにちは。次世代システム研究室のT.D.Qです。
最近、10年間運用されてきたウェブサービスのリニューアルに携わる機会がありました。ビジネス変化への迅速な追従と、変更のスピードと柔軟性に対するニーズを満たすため、既存システムをモノリシックアーキテクチャからマイクロサービスへ転換することになっています。一部の機能が独立したサービスとして本番リリースまでを実施しましたので、今回、この転換について紹介したいと思います。

改善前のウェブサービスの構成

今回、改善前のモノリシック(Monolithic) なウェブアプリケーションは、巨大なウェブシステムで、複数の機能を1つのアプリケーションの実行物として構築されました。ユーザー向けの部分だけでも、機能数が500以上ありますが、APIや管理機能、バッチといった複数のサブシステムのためのコードが含まれており、10年間メンテナンスされています。ユーザー向けのアプリケーションの構成図は以下の通りです。

モノリシック(Monolithic) なウェブアプリケーションの問題

10年間サービスの成長に伴い、大規模で複雑になるWebサービスを提供する上では、いくつか問題が目立つようになりました。

全機能の詳細の把握は困難

大きなブラックボックスとなり、全体像の理解が難しく、意図しないところの変更の影響、処理の流れがつかみにくくなってしまったため、新しい開発メンバーに対して、アプリケーションの全機能を把握・改修するのに困難です。

IDEのオーバーロード

ソースコード全部ロードすると、IDEのオーバーロードになり、開発スピードが落ちる場合もある

継続的なリリースの難しさ

突発的な変更依頼が頻繁にあり1日2～3回更新も珍しくないが、ほとんど全アプリケーションを再ビルド・検証する必要なので、簡単にリリースできません。

柔軟性が低い

アプリケーションの一部の機能をスケールさせることが必要だったとしても全体を複製しなければならないため、スケーリングに柔軟性が非常に低いです。後は、障害が発生した場合は、その箇所だけではなく、全アプリケーションに影響する可能性もあります。

新しい技術の適用に困難

モノリシックの特徴ではありますが、プロジェクトが立ち上げの時点から選択された技術、フレームワークに長期的にコミットする必要で、ミドルウェアやフレームワークをバージョンアップするのに簡単にできません。
上記の問題点を解決するため、マイクロサービスアーキテクチャーへの転換を検討されました。

マイクロサービスで期待できること

マクロサービスとは

「マイクロサービス（Microservices）」という用語が、最近、Web企業を中心に注目を集めています。一言で言いますと、「マイクロサービス」は「サービス全体が、独立した小さなサービスの集合で構成されるようになってきている」です。以下の画像のように、その最大のメリットは、小規模なサービス群を疎結合する作りにすることにより、「一枚岩」（モノリシック）のシステムの複雑さから自由になることです。つまり、マイクロサービスの考え方を導入することで、大規模システムの個々の小さいなサービスを迅速かつ独立的にデリバリ可能になり、変化に強いシステムを作ることができるのです。

マイクロサービスの特徴

James Lewis氏、Martin Fowler氏による解説記事Microservices (2014年3月25日）によると、マイクロサービスの特徴が9つほど挙げられています

①サービスによるコンポーネント化（Componentization via Services）

ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。

②ビジネス能力に基づく組織化（Organized around Business Capabilities-Conway’s Law）

役割ごとにチームが構成されるのではなく、複数の役割が混在したチームがひとつのサービスを構築する。

③プロジェクトではなくプロダクト(Products not Projects)

コンポーネントは期限のあるプロジェクトとして開発されるではなく、継続的なプロダクトとして開発運用していくで、ビジネスとして価値を高まる。

④スマートエンドポイント、ダムパイプ(Smart endpoints and dumb pipes)

サービス間のメッセージは、HTTP経由でAPI呼び出しされるか、RabbitMQやZeroMQといった軽量メッセージングシステムによる通信で交換される。

⑤分散ガバナンス(Decentralized Governance)

サービスごとに言語やデータベースなどは統一されず、個別に適切なものが選択される。

⑥分散データ管理(Decentralized Data Management)

サービスごとにデータを持ち、統合されていない。

⑦インフラストラクチャ自動化(Infrastructure Automation)

継続的デリバリが実現され、自動テスト、自動デプロイなどが採用されている。

⑧フェイルを前提として設計(Design for failure)

構成されるサービスの障害に耐性を持つように設計されている。

⑨進化的設計(Evolutionary Design)

各サービスごとに変更が行なわれ、漸進的に設計がされる。

上記の特徴で、マイクロサービスアーキテクチャーを利用することで以下のことを安易に実現できます

①強固なモジュールの境界

マイクロサービスではモジュラー構造が強化されています。この点は、チームの規模が大きくなるほどその恩恵は増してくるでしょう。

②個別にデプロイ

サービスがシンプルなほどデプロイは容易です。また、マイクロサービスではそれぞれが自律的なため、不具合が起こった時にもシステムエラーに繋がる可能性は高くありません。

③技術の多様性

マイクロサービスでは、複数の言語、開発フレームワーク、そしてデータストレージ技術を組み合わせることが可能です。

モノリシックとマイクロサービスの比較

次の図はモノリシックなアプリケーションとマイクロサービスのコンセプトを対比したもので、いろいろなサイトやブログでよく見られるものです。

http://www.nttdata.com/jp/ja/insights/trend_keyword/2015072301.html

最後に

実際にマイクロサービスアーキテクチャで設計し、異なるチームで独立して開発を実施したところ、全サービスのシステムへの影響を考えなくても1発目の独立したサービスとしてリリースできました。既存モノリシックなアプリケーションとは違う、開発言語やフレームワーク、CI/CDツールも好きな技術を自由に選択できたため、マイクロサービスのメリットを実感できました。リリース後、部分的にメンテナンスされ、稼働できるというのは以前より非常に良くなると思います。ただ、マイクロサービスは銀の弾丸ではありません、運用のコスト（オーバーヘッドとかインフラとか）がかかることとサービス間連携の複雑性が増すため、高度な技術力が要求されることは現在の懸念事項となっています。実際のマイクロサービスの導入について、次回の記事でご紹介したいと思います。

参考文献

①Microservice(日本語訳)
②Microservice Trade-Offs
③マイクロサービス（Microservices）
④Testing Strategies in a Microservice Architecture
⑤Microservice Module Architecture with Spring boot

次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。

皆さんのご応募をお待ちしています。