arclamp

ITアーキテクト 鈴木雄介のブログ

エンタープライズにおけるマイクロサービスアーキテクチャについて

エンタープライズ業界でもマイクロサービスアーキテクチャの議論が盛り上がりはじめてて、それは良いのですが、やはり本質的ではない技術論にばかり夢中になっている気がしています。

f:id:arclamp:20160824195126j:plain

エンタープライズシステムの現状

モノリシックな巨大システムでは一部分の改修であっても、システム全体対する影響調査やリグレッションテストによる工数増加が発生し、共通機能をいじるとなれば関連機能も含めた改修が発生するなど、スピード感は落ちる一方です。
つまり、従来型のコンポーネント集約のような手法で巨大システムを作ると、開発効率が上がったとしても、保守における変化効率が極端に下げることが分かっているわけです。

一方で、旧来から部門別で構築されてきた中小規模システム達は、いつのまにやら複雑に連携しあっており、相互に影響を与える中では、個別システムの都合だけでリリーススケジュールを決めることが困難になってます。
特に場当たり的に作って乱立してきた顧客フロント側サービスは、バラバラで不便すぎるのに、微妙な担当部門の業務都合によって統合が困難になってます。
そのうえ力のある部門が「うちの部門ではシステム化が競合他社より遅れてる」とか言おうものなら、さらに場当たり的な新規システムを構築することになります。
そういうシステムはSaaSやパッケージだから既存システムとの連携が難しくて「とりあえず手動」で始めた業務が定期バッチになり、そこを担当する事務部門は人件費が下がりません。

そんな乱立は裏方である顧客サポート部門も不幸にします。顧客のシステム横断ビューどころか、シングルサインオンもままならず、問い合わせ対応には数個のシステムと膨大な暗黙知をもって対応し続けている。ミスが起きればクレームになり、そこの品質を上げようにもコストセンターにシステム投資はまかりならんし、だいたいシステム構築経験者が少なすぎて提案すらできない。

さらに今や偉くなった役員から「弊社のシステムは分散していて使いにくいという声が上がってる。全体最適化の視点がない!」とかしたり顔で言われても「おめーが担当の時にゴリ押しで導入したからだろうが」とは言えずに統合連携基盤なる検討を始めるしかないわけです。
ところが、いざSOAだと連携基盤を持ち込んでも、えらい複雑なワークフローを組んで破綻するか、データフォーマットを標準化したら最小公倍数状態で各システム側で変換ロジックをゴリゴリと書くことになり「なにが楽になったの?てか、障害が起きてもどこが原因か分かりにくすぎて対応コストが上がったよ」と現場は大ブーイングになります。

まぁ、システム部門も「それぞれの担当システムが平穏無事であればよい」という姿勢なのが問題なわけです。分かる、分かりますよ、新規システム構築に際して既存システム側の改修見積りしたら、そっちのコストのほうが高くなっちゃって文句を言われ、工夫を凝らして既存流用したら、逆に保守性が下がっちゃったりするわけです。なんで他シスのせいで怒られなきゃいかんのかと。

じゃあ、システム部門主導で全体最適だと。よかろう標準化だと。具体的には標準フレームワークや標準データモデルだと。それらに意味がないまでは言わないまでも、ユーザーが多様化し、ビジネスニーズも多様化する中で果たして標準的な技術やデータで何ができるのでしょうか。フロントシステムとバックエンドのシステムは非機能特性が違うので、同じ技術は適しません。ツーシーターのスポーツカーと業務用のバンが同じ構造でいいのかってことですよ。


そんなわけで目の前には山頂が雲に隠れ、裾野も霧の向こうという巨大基幹システムと、周辺には複雑な地下水脈でつながり合う部門システムがまとわりついており、次の再構築ってどうするのよと、業務が止まるような再構築できないよ、という状況なわけです。

安心してください。みんな悩んでますから。たいていの企業で多かれ少なかれ似たようなことが起きています。

昔は1つのシステムをどうするのか考えれば良かったのです。ところが、お互いがシステム連携を始めてしまい、それが重要になってくると、個別システムを効率的に開発・管理する視点よりも、企業システム全体を効率的に開発・管理する視点が大事になってきています。でも、そういう全体視点でシステム配置を最適化するための考え方で良さそうなものがなかった。

MSAはシステム全体視点の戦略

そこでMSAですよ、というのが話の流れ。

例えばAmazonだって社歴は20年を超え、その巨大な売上を支えるシステムは当然そこらの大規模システムと引けを取らない。そういう彼らが言うMSAというのは、オンラインサービスを主軸にしながらもバックエンドの物流や会計までもが緩やかに繋がる「企業システム」なわけです。それらをどう管理したらいいんだろう、かつ、フロントシステムの改修速度は落としたくない。その答えがMSAだったわけです。

MSAのメリットは「巨大なシステム(群)をチームで見れる程度のサービスに分割していくことで、それらのサービスごとに個別ライフサイクルを実現し、システム全体としての変化スピードを上げる」ということです。
サービス同士が疎結合である、つまり、機能改修の変更が他のサービスに及ばない、かつ、リリースに伴う停止や切替が他サービスから隠蔽されるということが出来ていれば、個別のサービスは、そのサービスに求められる変化スピードを実現することができます。早ければいいって話ではないです。そのシステムに求められるスピードが他者に干渉されないことが大事。
そのための技術としてクラウドによる仮想化やDevOpsによる自動化というのは大きな役割を果たします。

エンタープライズにおけるMSAというのは、技術論の前に、全体システムをいかに最適化するのか、という概念として考えればよいと思います。単体システムや単体アプリの視点ではなく、企業内部の全システムを見る視点。「木」をどうこうではなく、「森」をどう管理するか。
木は、その木に思い入れのあるチームに任せたほうが良い。大事に育ててくれよと。ただ、森の土壌や治水といった、森全体を健全に管理するのは、また別な視点で別な人が責任を持って取り組まないといけない。
エンタープライズでMSAに取り組むなら、こういうことを考えてもらいたいなと思うのです。

「MSAに再構築する」のはNG

では、MSAにどうやって取組みべきでしょうか?
僕個人としては「巨大なシステムを分割しながら段階的にMSAに移行していく」という取組みそのものがMSA的な姿勢であると思います。「MSAなシステムを作るために大規模再構築をする(リリースは3年後)」というのはMSA的ではありません
来週、来月にでも最初の一歩は踏み出せるはずです。巨大なシステムに対して、部分的にでも、ほんの少しでもアジャイルクラウドや自動化や、なんらかモダンな技術を導入していく。そして時間を掛けて全体システムを最適化していく。その営みがMSA的なのです。

アジャイルが、具体的にはプロセス論(do Agile)であるながらも、その本質が「アジャイルにするという姿勢(be Agile)」であるように、MSAも、具体的には個別の技術論(do MSA)ではありますが、その本質は「MSAにしていくという姿勢(be MSA)」であると思っています。


宣伝1.僕の部署では、こういうお悩み解決のために全体システムの分析やら再構築の方針策定やらの手伝いもしてますよ。ご興味がある方は連絡ください → グロースエクスパートナーズ株式会社

宣伝2.もう少し詳しくMSAに至る流れを知りたい、という方は以下の本を。2016/8/25発売です!

Cloud First Architecture 設計ガイド

Cloud First Architecture 設計ガイド