EJB、SOA、マイクロサービスへと至る大規模システム向けアーキテクチャの変遷：15周年記念特別企画（1/3 ページ）

　近年、「マイクロサービスアーキテクチャ」という言葉が徐々に広がりつつある。「何年か前からあるSOAの概念の焼き直しでは」という意見もあるが、「SOA」の概念自体、さまざまな解釈があるなど、その正しい理解はなかなか難しいのではないだろうか。

　本稿では、2000年前後からのアプリケーションアーキテクチャにおける代表的なフレームワークについて簡単に触れながら、今後主流になってくると思われるマイクロサービスアーキテクチャの理解を試みる。

マイクロサービスアーキテクチャの実例と9つの特徴

　マイクロサービスアーキテクチャを含む統合アーキテクチャを理解するに当たり、まずはマイクロサービスアーキテクチャの採用事例を参照されたい。日本国内で有名な事例として、下記の企業のケースが挙げられる。

• クックパッド
• LINE
• ビズリーチ
• Gunosy
• SkyWay

　アーキテクチャの変遷は、主にそれを支える要素技術の文脈で語られることが多いが、その変遷を技術だけで語ることは難しい。例えば、マイクロサービスアーキテクチャに対しては、提唱者のJames Lewis氏がMartin Fowler氏との共著の記事「Microservices」において詳細な説明を行っている。ここで語られているマイクロサービスアーキテクチャの9つの特徴を挙げる。

• サービスによるコンポーネント化
  主な機能はライブラリとして配布するのではなく、サービスとしてAPIで公開する
• ビジネス上の組織力に基づいたIT組織作り
  従来のレイヤー単位での組織化ではなく、ビジネスにおいて組織されたチームに準じてITチームを組織する
• プロジェクトではなくプロダクト
  成果物は常にマイクロサービスであり、プロジェクトに閉じた議論は意味を成さない。むしろ、マイクロサービスは継続的なプロジェクトである
• 洗練されたインターフェースと太いメッセージングバス
  APIはシンプルかつ過不足のなく構成し、軽量プロトコルで通信する。大量の通信をさばく太いバスが必要
• 自律分散型ITガバナンス
  各マイクロサービスにおいて、そこに特化したITガバナンスを実施する
• 自律分散型データ管理
  各マイクロサービスにおいて必要なデータを適切なDBMSを用いて管理する
• 基盤オペレーションの自動化
  マイクロサービス間のシステム連携や素早いローンチサイクルを実現するために、基盤オペレーションの自動化を図る
• 耐障害設計
  他のサービスの障害を受けにくい設計を施す
• 進化的設計
  マイクロサービスを適切に汎用化できるような設計を目指す

　これらの詳細な解説はここでは避けるが、組織への言及がなされていることからも「技術以外の要素」が大きな割合を占めることが分かるのではないだろうか。その観点を含め、ここでは筆者の考え方も交えながら、より俯瞰的な視座からマイクロサービスアーキテクチャを理解することを目標としたい。

マイクロサービスアーキテクチャのイメージ

　なお、文中で特定の技術について触れた場合については、誤解のない範囲で一般的な解釈において用いるものとする。

一般的な情報システム構築（モノリシック）と、その課題

　何らかのサービスを提供する情報システム（例えばECシステムやポータルサイトなど）の構築を実施する場合、単一のDBスキーマに全データを保存するようデータ構造を設計したり、全機能を一つのアプリケーションサーバーに構築したりする。いわゆる「モノリシックな構造」にするのが一般的である。

　スタートアップのサービスであればなおのこと、将来を見越した汎用的な“ものづくり”よりは、スピードを優先して、「提供するサービスに特化した情報システム」を構築する。

　こうしたシステムは、利用頻度の低い時期は特に問題が生じないことが多いが、サービスがスケールした際に、課題が顕在化する例が少なくない。起こりがちな課題から列挙しよう。

一般的な情報システムのアーキテクチャ

DBへの負荷集中

　システムの構造にも依存するため一概には言えないが、おおむね初めに直面するのがこの事象である。全てのデータが一つのDBに保存されているために、複数のテーブルを複雑に結合したデータ取得が多くなること、論理設計がそのまま実装されるケースが多いため、SQLにビジネスロジックが入り込み、パフォーマンスへの考慮が行き届かないこと、などが主な要因として挙げられる。

ノンコア機能のサービス力低下

　昨今のITサービスにおいては、単一機能で収益が上がるほど単純ではなく、複数の機能を適切に組み合わせて顧客満足度の向上を図る場合がほとんどである。

　全機能にオリジナリティがあり、他社を凌ぐ価値を提供できるに越したことはないが、一般的には一部の機能に価値が集中し、周辺機能は付加的に一般的なレベルで提供されることがほとんどである。その場合、周辺機能に投入する経営資源は限りなく少なくなっていくばかりでなく、それを担当するメンバーのモチベーションも下がり、最低限の価値の維持すら困難になることが多い。

機能間の負荷バランス

　事業規模が拡大するにつれて、一部の機能の負荷が情報システム全体の負荷に占める割合が増大する、いわゆる「パレートの法則」のような事態に陥ることが多い。この課題は、初期はロジックの組み換えやハードウエアの交換などにより、“もぐらたたき”的に一つ一つ力技で解決していくことが多いが、徐々に「情報システム全体の構造」が問題として顕在化し、その改善に投資すべきことが次第に明らかになってくる。

　しかしながら、すでに複雑化した情報システムにおいて、対象となる機能を単体で改善することは非常に困難になっていることが多い。

デッドロックの頻発

　「さまざまな機能から単一のDBスキーマを参照、更新する構造」においては、トランザクションの増大に伴い、同じデータに対する更新処理が同時多発的に発生するケースが増える。データの安全性を保つための排他制御が、サービスを停止させるデッドロックを招くであろうことは容易に想像がつくはずだ。情報システムの規模が拡大すれば、その可能性は指数関数的に増大する。

　開発プロセスを適切に管理すれば起こり得ない事態とはいえ、成長速度が求められる最近においては、そのような管理が完璧にできる事業体はほぼないのではないだろうか。

影響範囲の増大（アプリケーション複雑度の増大）

　前述のデッドロックと様相は類似するが、長いビジネスプロセスの冒頭部分を担うアプリケーションの改修が、後続の処理に悪影響を与えるケースが増加してくる。これはビジネスプロセス自体の複雑さにも起因するが、情報システムの規模が人間の理解の限界を超過することによって起こる。

　これを防ぐために、設計工程とテスト工程を手厚くすることが考えられるが、完璧に防止する策は徐々に限られてくる。

開発規模増大による管理コストの上昇

　単機能の改修であっても、さまざまな機能が複雑に絡み合う巨大なシステムにおいては、全ての可能性を網羅的に検討し、徹底的に調べ上げるプロセスが設けられる。

　調査・設計といったプロセスから、サブシステム単位、ベンダー単位、レイヤー単位で組まれるチーム体制など、複数のチームを多層的に管理する体制を構築する必要が出てくる。情報システムの複雑度と体制の複雑度は比例するものと考えてよい。