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

[鈴木史朗，ネットプロテクションズ 取締役 CTO]

マイクロサービスとは

　マイクロサービスアーキテクチャとは、「複数の基本的なサブシステムを、RESTのような軽量プロトコルを用いて適切につなぎ合わせて、一つの大きなシステムを実現するもの」である。ただし、マイクロサービスそのものは、ビジネス上の組織力、すなわちビジネス上で組織されているチーム単位、または業務単位で定義されるべきものとされている。

チーム単位で分ける

　これはSOAの概念をやや具体化した概念であるが、特に新しい考え方は導入されておらず、事業の構築・拡大を進めるに当たっては自然な発想であるともいえる。

実現に向けて目指すべきチーム

　ただし、EJBの概念を完全に閉じ込め、SOAのように「APIの構成に着目するもの」からは一歩進んでいるのがマイクロサービスアーキテクチャだ。その開発は、マイクロサービスごとに行うが、業務の汎用化・効率化に責任を持ったチームが開発を担当することで、品質が安定する期待がある。

　各マイクロサービスを「独立したもの」として扱い、それらを自律分散型で管理することによって全体の統合を目指している。こうした点は「ビジネスサイドにおける組織作り」の理想に類似している。この点で、マイクロサービスアーキテクチャでは、ビジネス組織の管理と同様、システム全体および各マイクロサービスにおける理念やビジョンの「緩やかな共有」が重要となる。

　一方で、「APIの構成に着目する」SOAとは異なり、各チームがAPI以下の全レイヤーのスキル、および運用スキルを持つ必要があるため、組織全体で見た場合にはやや冗長な人員構成となる恐れがあり、IT系のスキル管理や人材採用をより戦略的に進める必要があるだろう。

　ビジネスと、その前提となるマーケットを常に観察しながら、時には市場の要求に即時に対応し、時には提供が予想される機能を早めに準備するなど、ビジネス、開発、運用の各チームが密に連携し、相互に深く理解し合ったチーム体制が望まれる。

マイクロサービスにDevOpsが必要な理由

　実装面に目を移すと、各マイクロサービスが疎結合でありながら連携してビジネスを実現しているため、ビジネスを止めないためには、システムのプロビジョニングは素早く正確に行う必要がある。

　また、マイクロサービスに障害が発生した際、ビジネスの全てが停止するリスクはモノリシックな情報システムに比べてやや低減しているものの、その影響範囲を事前に予測することは非常に困難であり、より複雑な障害対応フローを設計しなければならないし、影響範囲を極小化するために、迅速な復旧が求められる。

　これらに対する解は、システム運用の自動化、およびモニタリングの充実に他ならず、開発時点から運用プロセスを考慮することが推奨される。この点からDevOpsの必要性が理解されるのではないだろうか。

　管理者側から考えると、汎用的かつ継続的なサービス設計、他のマイクロサービスとの柔軟な連携、耐障害設計を実現するためには、事業の形によらない（どのような事業にでも対応できる）柔軟なロードマップと運用要件を踏まえて統合的に開発を進めることが大事である。

　サイクルの短い開発スタイルを適用することで、フィードバックサイクルを短く多くして新陳代謝のスピードを上げ、ビジネスの変化に柔軟に対応できる体制を敷く必要がある。

　この実現には、PaaSや、Dockerなども有効な手段の一つとなり得る。

新規事業を構築する際のマイクロサービスアーキテクチャに必要な施策

　新規事業を構築する際には、多くの場合、ビジネス側でプロジェクトチームを立ち上げ、マーケティング、セールスをメインに行いながら、財務チーム、ITチーム、オペレーションチームと連携し、必要に応じて特殊オペレーションを実施するチームを立ち上げる。すでに存在しているビジネス機能や販路、ワークフローを活用しながら、必要に応じて新規に構築、開拓する。

　マイクロサービスにおいても、これと同様のことが求められるため、全てのマイクロサービスには高い汎用性が求められる。一方で、存在しない事業に対応できる汎用性を求めることは、ビジネス組織においては最高難度のものであること、汎用性の高い機能ほど改善スピードが低下していくことから、新規ビジネスの構築とマイクロサービスアーキテクチャの相性は必ずしも良くないことが想像できる。

　組織風土や技術力、組織のコアコンピタンス、既存ビジネスと新規ビジネスの直接的なシナジーの大きさ、ビジネスの方向性やポジショニングなどに依存するものではある。しかし（人間ほど柔軟ではない）ITにおいては、既存機能の利用に必ずしも固執せず（当然のことながら、簡単に使えるものは使う方が望ましい）、スピードを再優先として新規ビジネスを構築するべきだろう。ビジネスのビジョンと実態が一致し始め、提供価値に一定の落ち着きが見られ始めてから、既存のアーキテクチャへの統合を図ることが、ビジネスの可能性を狭めることなく汎用性を高めていくための効率的な進め方であると考えられる。

　ただし、事業の内容に大きく左右されることは言うまでもない。例えばコンシューマー向けのポイントサイトやキュレーションサイトなど、マーケットに合わせて多くの施策を投じる必要があるビジネスの場合は、常にスピードが優先されるし、ビジネスプロセスがコアコンピタンスではないことが多い。この場合においては、初期の時点でマイクロサービスアーキテクチャを採用することで、ビジネスの速度を上げられると考えられる。

　一方で、ビジネスプロセスがコアのビジネスであったとしても、ビジネスモデルに一定の落ち着きが出ており、さらなるスケールが予測される場合には、ある時点でマイクロサービスアーキテクチャを採用することで、組織を安定させながら、ビジネスの拡大を実現させることが可能になることが想像される。

　冒頭にも述べた通り、数多くの事例を参照し、読者を取り巻く環境を照らし合わせ、適用のタイミングを適切に図っていただきたい。

技術と組織を一体のものとした議論を要する時代

　IaaS、PaaS、SaaSなどが台頭したことであらためて技術者の在り方が議論され、技術者自身のアイデンティティが問われる中、ITに対する理解は技術だけにとどまることはなくなってきている。逆に言えば、ビジネス側からの踏み込みがより深くなることが強く望まれている。

　自然で真っ当な流れではあるが、技術と組織を一体のものとした議論を要する時代になってきているとも言える。そうすることで、よりスムーズで安定した組織運営ができ、結果的により質の高いサービスが提供できるようになるであろうことは容易に想像がつく。

　マイクロサービスアーキテクチャの概念は、一つの通過点ではあるが、一般的な組織運営に対して大きな示唆を与えていると考えられる。今後の発展に大いに期待したい。

筆者紹介

鈴木 史朗（SUZUKI, Shiroh）

ネットプロテクションズ 取締役 CTO

IT系2社で数理技術を利用した、ビジネス課題解決プロジェクトを歴任した後、2002年11月にネットプロテクションズに入社。その後、同取締役CTOに就任。入社当初から、後払い決済サービス「NP後払い」のシステム構築に従事し、後払い決済構築のパイオニアとしての地位を確立する。

現在は、企業間の後払い決済に特化した「FREX BtoB 後払い決済」を中心としつつも、全事業を横断する形でビジネスアーキテクト部門を統括する。