「マイクロサービスアーキテクチャー」はどれくらい世に広まっているだろう。小さなサービスを疎結合に組み合わせ、一連のアプリケーションを構成するマイクロサービス。ソフトウエアの改変しやすさに強みがあり、米ネットフリックスや米アマゾン・ドット・コムといった、サービス改善のスピードを突き詰めたいネット企業を中心に導入が進んできた。

 日本でも活用事例は増えている。日経SYSTEMSの特集記事「マイクロサービスの現実解」では、全日本空輸(ANA)や楽天トラベル、モノタロウなどを取り上げた。メリットが大きい半面、特に既存システムからの移行は一筋縄では行かないという印象だ。マイクロサービスの難しさを考えてみたい。

 従来型システムに比べたマイクロサービスのメリットは明らかだ。現在主流のWebアプリは、プレゼンテーションと業務ロジック、データアクセスの3レイヤーを一体で開発するのが一般的。こうしたモノリス(一枚岩、Monolith)型に密結合で組み上げた結果、ビジネス要件の変化に即応しにくい弊害が目立ってきた。各機能の独立性が高いマイクロサービスであれば、ある機能を変更する影響が他に及ぶのを最小限に抑えられる。

モノリス型システムからマイクロサービスへ
モノリス型システムからマイクロサービスへ
[画像のクリックで拡大表示]

「改変に3カ月、工数の4割はテスト」のモノリス型

 「SoE(Systems of Engagement)に近い機能は改善して毎日でもリリースしたい。しかし他の機能と連携しているので、影響調査やリグレッションテストが必要。個別に変更したいのに、全体調整やスケジュール調整もいる」。マイクロサービスに詳しいグロースエクスパートナーズの鈴木雄介執行役員/アーキテクチャ事業本部長はモノリス型システムを改変する面倒をこう説明する。

 ANAの国内線インターネット予約システムも変更コストの大きさに悩まされていた。「サービス内容の変更や新運賃対応といった改変要望があると、影響範囲などを見極めたうえで、やるかやらないかを判断。やると決めたら、サービスの設計からシステム検討、Webアプリと基幹系のインタフェース設計、開発、テストなどを経てリリースするので、改変に2~3カ月を要するケースもあった」(ANAシステムズの鈴木敦之WEBシステム部第二チームマネージャー)。しかも、画面を少し変更するだけで一連のテストが必要で、テスト工数がプロジェクトの4割を占めるまでに増えてきたという。

 スタートアップ企業であればクラウドを活用し、一からマイクロサービスアーキテクチャーでシステムを作れる。しかしモノリス型システムを抱える企業はそう簡単にはいかない。マイクロサービス化では、目の前で動いているモノリス型システムを解体していく必要がある。

 企業システムには改善し続けたい機能もあれば、一度作ったら“塩漬け”で構わない機能もある。改善して価値が上がる機能を見極め、これを段階的にマイクロサービス化するのがモノリス解体のアプローチ。日本IBMの樽澤広亨IBMクラウド事業本部エグゼクティブITスペシャリストは「“モノリスファースト”で始め、一部のサービスを独立してデプロイや個別メンテナンスできるようにしていき、結果的にマイクロサービスになっているのがベスト」と話す。