前回、これまでの連載の内容とマイクロサービスの「9つの特徴」との紐付けや特徴同士の関係性を説明しました。また、「9つの特徴」のうち4つを説明しました。

最終回の今回は残りの5つの特徴を説明した後、マイクロサービスの適用シーンについてまとめたいと思います。

5. Decentralized Governance :
　分散統治

組織で開発プロセスやフレームワークを「標準化」することで、人材の流動性を高められるといったメリットが得られるなどの理由で中央集権型が当たり前のように語られてきました。

マイクロサービスの文脈においては、分散統治が推奨されます。つまり、「全ての問題が釘ではなく、全ての解決方法がハンマーではない」のです。例えば、非機能の観点では、超高性能を求められる業務にはNode.jsやmemcachedといった選択肢がある一方で、そうでない業務には通常通りJavaでRDBMSを選択するといった使い分けが考えられます。

もっとも、Monolithなアプリケーションにおいても、こういった使い分けは可能ですが、マイクロサービスは、サービス間の独立性を確保できるため、分散統治がやりやすいと言えます。

6. Decentralized Data Management :
　分散データ管理

ドメイン駆動設計(DDD:Domain Driven Design)という言葉を聞いたことがあるでしょうか。業務のドメインの境界を定義し、その単位で区切って開発します。これは、前述のNo2「ビジネス遂行能力に基づいた組織整理」での分割により効果的に実現されます。

データの管理単位に目を向けると、Monolithなアプリケーションにおいてはシステムで一つのデータベースが好まれます。一方マイクロサービスにおいては、「分散データ管理」と呼ばれ、それぞれのサービスの単位でのデータベースが好まれ、それぞれのデータベースは異なるRDBMSでも構いません。このアプローチをPolyglot Persistenceと呼びます。

データが分散するということは、当然ながら相互に関連するデータの場合、一貫性の管理が必要となり、Monolithなアプリケーションであれば、2フェーズコミット等を用いたトランザクション管理により実現される場合が多くなります。

一方、マイクロサービスにおいては、サービス間を密結合になってしまうことを避けるため、「サービス間のトランザクションレスな連携を重要視」します。この連携方式においては、一貫性は結果的に満たされていればよく、問題が起った場合は補完処理(お金に絡む場合は補償処理)されます。一貫性の確保により失われる機会損失のコストは補償にかかるコストよりも大きいという、ある種の割り切りの考え方に基づいています。

こうした非一貫性を前提としたデータ管理はある種のチャレンジであり、マイクロサービスサービス適用の上での注意点となります。

データ管理の単位の違い

7. Infrastructure Automation :
　インフラの自動化

インフラの自動化技術はここ数年で目覚ましく進化しています。CI(Continuous Integration:継続的インテグレーション)/CD(Continuous Delivery:継続的デリバリ)がその中核にあり、インフラの自動化の中では、以下の2点の自動化に着目しています。

  • テスト自動化
  • デプロイ自動化

連載第6回で紹介した内容に当てはめると、第二・第三の自動化が該当します。テスト自動化に関しては、単体テスト・機能テスト・パフォーマンステストといった一連のテストを自動化するものです。デプロイ自動化については、開発環境・ステージング環境・本番環境へのデプロイを自動化します。

表 : フェーズ別のツール/手法

No 領域名 対象フェーズ 利用技術例
1 ソースコード自動生成 開発(設計・実装) Eclipse、TERASOLUNA ViSC
2 テスト自動化 単体テスト JUnit、Jasmine、JsTestDriver
機能テスト Selenium、Selenide
パフォーマンステスト Apache JMeter
3 デプロイ自動化
(DevOps、CI/CD)		 開発環境 Jenkins、Gradle、Maven、Capistrano、Fabric
ステージング環境
本番環境
4 基盤自動化
(Infrastructure as Code)		 環境構築・環境変更 構築 : SDN、Chef、Puppet
テスト : ServerSpec
概念 : Immutable Infrastructure
仮想化 : Docker

8. Design for failure :
　障害発生を前提とした設計

マイクロサービスが全ての点において、Monolithなアプリケーションよりも優れているというわけではありません。サービスを小さな単位で分割しているが故に、呼び出される側のサービスの稼働状況に起因して呼び出し側の処理が失敗する可能性があり、この状況にうまく対応する設計が必要となります。

ここで登場するのが、「Design for failure:障害発生を前提とした設計」です。ここでいう設計とは、耐障害性設計と監視設計のことを指します。例えばNetflixでは、主に平日日中帯のオンライン時間帯に、サービスやデータセンタ単位で「敢えて」障害を発生させます。これにより、開発・運用チームは耐障害性と監視の有効性について、絶えず検討・改善することができます。

サービスはいつでも停止し得るため、即時検知および可能であれば自動回復の仕組みが重要となります。多くの開発プロジェクトにおいては、個々のサービスごとに、以下を一覧表示するいわゆるダッシュボードが活用されます。

  • サービスの死活状態
  • システム面のメトリクス : データベースが受け付けるトランザクション数など
  • ビジネス面のメトリクス : 顧客からの注文数など

9. Evolutionary Design :
　進化的な設計

マイクロサービスの導入を検討する際は大きく以下の2通りが考えられます。本節では後者について説明します。

  • システム「全体」をマイクロサービスで構築する
  • システムの「一部」をマイクロサービスで構築する　→　「進化的な設計」

システム開発の全てが新規開発で、一度作れば終わりというわけではありません。機能追加・削除やハード更改などが行われ、いわば進化していくため、変更容易性が重要となります。例えば、当初GurdianのWebサイトは、Monolithで構築されました。新しい機能をマイクロサービスで構築する際、既存のMonolith APIを活用します。

こういったアプローチはスポーツイベントの特設サイトのような一過性のイベントサイトを構築する際に有効です。Webサイトを構築する際は高生産性が期待できる言語を用いて開発し、イベント終了後削除するのも容易です。また、金融機関においても同様のアプローチが見られます。マーケティング用のWebサイトを構築し、数ヶ月あるいは数週間にて削除されます。

マイクロサービスは銀の弾丸か

Monolithなアプリケーションと比較し、マイクロサービスが銀の弾丸となり得るわけではなく、「6.分散データ管理」や「8.障害発生を前提とした設計」等の特徴を踏まえた適用が必要ですし、「9.進化的な設計」にて示されるように、マイクロサービス適用のアプローチを選定していくことが重要です。

また、SIerの立場から言えば、請負開発でフェーズや業務・基盤等の役割で分割したチーム構造になることが多く、マイクロサービスがそのまま適用できるとは限りません。特定のパイロットプロジェクトを通じたPoC(Proof of Concept:コンセプト検証)を行ったり、HerokuのThe Twelve Factor Appに代表されるような、いわば開発標準に相当するものをシステム開発の特性に応じたかたちで整備したりするなどが必要になってくるでしょう。

Martin Fowler氏がMicroservicePremiumにて、「複雑さ」に応じてMonolithとマイクロサービスを選択すべきだと述べています。「複雑さ」を表す要素はチームの大きさやマルチテナントなどが挙げられています。特にCD(Continuous Delivery)を実現できないほど複雑なMonolithなアプリケーションに対しては、生産性を大きく下げる要因となるためマイクロサービスを選択すべきです。また、チームのスキルも選択における大きな要素となります。

「複雑さ」と「生産性低下」の関係性の観点でのMonolithとの違い

連載を振り返って

これまで9回に渡って、マイクロサービスをさまざまな切り口から解説しました。マイクロサービスそのものは新しい技術というよりは、さまざまな技術の組み合わせで実現されているため、紹介した技術の一部は既に採用しているという方も多かったのではないでしょうか。

オンプレミスからクラウドへ大きく舵を切っていく潮流の中で、マイクロサービスは今後中心となっていく可能性を秘めています。本稿の内容を読者の皆様の技術の引き出しの一つとしてお役に立てれば幸いです。

以下に連載回次別の掲載トピックを載せておきますので、気になるところがあれば、見返してみてください。

表 : 連載回次別の掲載トピック

回次 分類 主なトピック
1 技術比較 vs Monolith
2 技術比較 vs SOA
3 起源や実例 ガートナーのハイプサイクル、AWSやNetflixの事例
4 周辺技術 DevOps、CI/CD
5 周辺技術 クラウドネイティブ、The Twelve Factor App
6 周辺技術 クラウドネイティブ、Infrastructure as Code、Docker
7 周辺技術 Spring Boot
8 9つの特徴 第1～4の特徴
9 9つの特徴 第5～9の特徴

著者紹介


正野 勇嗣 (SHONO Yuji ) - NTTデータ シニア・エキスパート

2011年頃まで開発自動化技術のR&Dに従事。その後、開発プロジェクト支援やトラブルシューティング等に主戦場を移す。「ソースコード自動生成」に加えて、JenkinsやMaven等の「ビルド自動化」、JsTestDriverやSelenium等の「テスト自動化」を扱うようになり、多様化する開発自動化技術動向に興味。

最近は第四の自動化であるInfrastructure as Code等の「基盤自動化」の魅力に惹かれている。開発自動化技術に関する雑誌・記事執筆も行う。2児のパパ。