マイクロサービスアーキテクチャ FAQ【1】
このFAQは、主に企業の情報システムの部門の方を第一の対象としてまとめております。いわゆるコアな「エンジニア」や「プログラマー」の方を第一の対象としておらず、テクニカルな用語を多用しないようにしています。
概要とメリット
Q1) マイクロサービスアーキテクチャとは？
A1) マイクロサービスアーキテクチャとは、ITシステムの構築手法です。特定の製品やサービスではありません。小さく分割された「マイクロサービス」をつなぎ連携させることによって巨大な能力を持つITシステムを柔軟に構築できます。
Q2) どのような企業が採用していますか？
A2) アマゾン、ツイッター、ネットフリックス、ウーバーなど、グローバルで巨大なデジタルビジネスを展開している企業が中心的に採用しています。
Q3) 何がメリットですか？
A3) グローバルな規模のビジネスに耐えうる「拡張性=スケーラビリティ」と、ビジネスのニーズに即応できる「柔軟性」「俊敏性」です。マイクロサービスアーキテクチャは「変化に強い」といわれます。
Q4) 従来のシステムとの違いは何ですか？
A4) 従来の一枚岩のようなシステム（モノリシックなシステム）は、ひとつのプログラムが一連のITサービスを処理します。マイクロサービスアーキテクチャのシステムは、小さく分割された多数のプログラム（マイクロサービス）が連携して一連のITサービスを処理します。
Q5) 小さく分割された「マイクロサービス」をどうやって連携させるのですか？
A5) API（ Application Programming Interface ）です。最も多く使われるのは「REST API」という方式で、標準的なHTTPプロトコルの通信を経由して連携するので、場所を問わずマイクロサービスを簡単に連携させることができます。
Q6) なぜシステムを分割してマイクロサービスにするのですか？
A6) 分割したマイクロサービスごとに、独立してプログラムを開発できるため、その処理にあったプログラミング言語やインフラを使うことができます。たとえばAIの処理が必要なら高性能なプロセッサを搭載したサーバーとPython言語による機械学習によるマイクロサービスで処理し、大規模なデータ分析をするなら大容量のストレージを搭載したデータベースによるマイクロサービスで処理し、それらを組みあわせればいいのです。マイクロサービスの自由な組み合わせによって、ニーズにあわせた柔軟なシステムを実現できます。
Q7) どのような処理をマイクロサービスとして分割するのですか？
A7) たとえばアマゾンであれば、「商品の紹介」「ショッピングカート」「レビュー」「ランキング」などが分割されています。ツイッターであれば「ツイートの表示」「通知」「トレンド」「ダイレクトメッセージ（DM）」などが分割されています。実際には、もっと細かい単位でマイクロサービスとして分割されています。
デメリットと考慮点
Q8) マイクロサービスアーキテクチャのデメリットは何ですか？
A8) マイクロサービスに分割されたシステムの全体像を把握するのは、一枚岩のシステムより難しくなります。
運用においては、分割された分散システムを一元的に管理して把握するシステムや、そのためのスキルを持った要員が必要になります。開発においては、できる限りプログラムを内製化しないと問題判別に時間がかかることがあります。
Q9) マイクロサービスアーキテクチャの管理は難しいですか？
A9) 一長一短です。マイクロサービスの集合であるシステム全体を把握するのは一枚岩のシステムより難しくなりますが、逆に分割されたマイクロサービスは把握しやすくなります。また、最近はマイクロサービスアーキテクチャの管理をしやすくするオープンソースのソフトウェアなども増え、管理の手法も急速に進化しています。
Q10) マイクロサービスアーキテクチャでは障害が増えますか？
A10) 一概に言えません。マイクロサービスアーキテクチャにおいては、独立したマイクロサービスごとに適切な障害対策やバックアップ・リカバリープランが講じられるため、部分（マイクロサービス）を強化して全体を強靭化することができます。また、マイクロサービスの障害が全体に波及することが少ないため、ITサービス全体が停止することも少なくなります。たとえばオンライン販売システムにおいて、売れ筋ランキングを表示するマイクロサービスに障害が発生しても、ショッピングは継続することができるでしょう。
Q11) なぜ日本ではマイクロサービスアーキテクチャが普及していないのですか？
A11) いくつかの理由が考えられます。最大の理由は、日本企業の多くは、アマゾンやネットフリックスのようにグローバルな規模で億人単位を相手にするビジネスをしていないため、マイクロサービスアーキテクチャのスケーラビリティを必要としなかったことです。またビジネスのデジタル化が遅れているために「柔軟性」「俊敏性」も欧米ほどに求められませんでした。さらに、日本企業はITシステムを内製化せず、システムインテグレータ企業に「丸投げ」することが多いですが、システムインテグレータ企業がマイクロサービスアーキテクチャを知らないために、旧来からのモノリシックなシステムしか提案・構築できないことも大きな理由です。
Q12) マイクロサービスアーキテクチャを導入するために考慮すべきことは何ですか？
A12) システムを内製化することです。物理的に内製化できないとしても、自社主導・ユーザー企業主導でシステムを構築するマインドが必須です。なぜならシステムインテグレータ主導では旧来からのシステムから脱却せず「守りのIT」しか実現しないからです。また、プログラムも可能な限り自社内で開発すべきです。デジタル化に成功した米国企業の多くは自社内でプログラムを開発しています。マイクロサービスアーキテクチャはアマゾン、ネットフリックス、ウーバーのような自社でプログラムを開発しデジタルビジネスを展開する企業が生み出したシステム構築手法です。
Q13) 「SOA」や「EAI」と、マイクロサービスアーキテクチャの違いは何ですか？
A13) SOAやEAIはベンダーの独自技術と製品として提供されていますが、マイクロサービスアーキテクチャは業界標準の技術とオープンソースソフトウェアを中心に形成されていることが大きな違いです。マイクロサービスアーキテクチャでシステムを構築しているアマゾン、グーグル、ツイッター、ネットフリックスなどはオープンソースソフトウェアを推進する企業であり、そのシステムはオープンソースソフトウェアによって実現されています。
実装など
Q14) それぞれのマイクロサービスはどのような構造になっていますか？
A14) それぞれのマイクロサービスは、アプリケーションサーバとデータベースを持ち、リクエストに応じて処理結果をREST APIにおけるJSONのような標準形式で返します。それぞれのマイクロサービスは独立していて、ひとつのマイクロサービスの障害は他のマイクロサービスに影響を与えません。マイクロサービスごとに独自のシステムインフラを持ち、独自の開発チームによってアプリケーションが開発されるのが原則です。インフラの構成は、処理の性質に応じて最適なものを選択すればよいので、計算能力が必要なら高速なCPUやGPUを搭載したサーバーを、大規模データを扱うなら巨大なストレージを搭載したサーバーを選択するとよいでしょう。
Q15) OS、ミドル、開発言語は何を使えばいいですか？
A15) 処理の性質に応じて最適なものを使ってください。よく使われるのはLinuxとMySQL/PostgreSQLとJava、Ruby、Pythonのようなオープンソース系の技術ですが、.NETが必要ならWindowsで開発する、オラクルのデータベースが必要ならUNIXで開発するなど、自由な選択が可能です。
Q16) クラウドを使うべきですか？
A16) クラウドでもオンプレミスでも、どちらでもよいです。マイクロサービスアーキテクチャにおいては。すべては「適材適所」であり、そのマイクロサービスを開発しやすい環境において構築すべきです。自社のERPのデータを共有するならオンプレミスで、グーグルマップの地図情報が必要であればグーグルのクラウドで、など「適材適所」で処理を行い、その結果をAPIで連携すればいいのです。
Q17) コンテナーやKubernetesとマイクロサービスの関係は？
A17) 実は関係ありません。しかし、コンテナーやKubernetesのような技術とマイクロサービスは相性が良いのも事実です。しかしながら、問題なのは、一部のITベンダーなどがコンテナーやKubernetesを使うことがマイクロサービスアーキテクチャだ、と聞こえるような主張をしていますが、これは全く的外れです。なぜならマイクロサービスアーキテクチャはコンテナーやKubernetesといったインフラ技術ではなく、その上のアプリケーションがAPIで連携することに価値があるのであって、どのようなインフラを選択するかは問題ではないのです。
Q18) マイクロサービス開発の体制や、そのインフラ構築の体制はどうあるべきです
A18) 基本はマイクロサービスごとに、アプリケーションの開発をする開発チームとインフラ構築・運用のチームを持ちます。この開発チームとインフラ構築・運用のチームは、他のマイクロサービスのチームとは完全に分離されるのが基本原則です。マイクロサービスアーキテクチャの先進国であるアメリカにおいては、マイクロサービスのチームを”2ピザルール”といって、「2枚のピザでまかなえるくらいの小さなチーム(10人程度?)」で運営すべき、としています。開発はマイクロサービスごとに独立して同時並行で進行させ、システムが巨大になっても柔軟に機能追加・変更することが可能です。
Q19) マイクロサービスをどのように監視すればいいですか？
A19) システムが多数のマイクロサービスで構成されると全体を一元的に見渡すことが難しくなり、「監視」するためのソフトウェアが重要になります。まずはオープンソースの「Prometheus」が基本になりますので、これを使うことをおすすめします。
Q20) マイクロサービスアーキテクチャにAPI管理ソフトウェアは必須ですか？
A20) 必須ではありませんが、使用することを強くおすすめします。
なぜなら人間の目には見えにくいAPIをゲートウェイに集約することで「可視性・管理性」を高めることができることと、APIを「いつ」「何が」使ったかを把握して「ガバナンス」をもたらすとともに、APIレベルでの認証やアクセス管理や流量制御によって強固な「セキュリティ」を実現することができるからです。