再利用性を重視したクラウド・システムのライフサイクル · •各サービス毎に、プログラミング言語、ツール、データストアの選択を許容

マイクロサービス概要～クラウド・コンピューティングにおける新たなアプリケーション開発スタイル～

日本アイ・ビー・エム株式会社

クラウド事業本部. クラウド・テクニカル・セールス

樽澤広亨 [email protected]

1Copyright IBM Corporation 2017

目的

• クラウド・アプリケーションの開発スタイルの一つとして、Microservicesを理解する。

• Microservices適用に当たって、設計上のポイントを理解する。


内容

• クラウド・ネイティブ

• Microservices概要

• Microservices実践のポイント• サービス境界

• サービス・インテグレーション

• データベースとトランザクション

• デプロイ

• まとめ


クラウド・ネイティブ


クラウド化の対象ドメイン


SoEとSoIのクラウド化マーケットを先取りするスピードと柔軟性の実現

SoRのリノベーションミッション・クリティカルのデジタル化によるエコ・システム創造

SoRSystems of Record

SoESystems of Engagement

SoISystems of Insights

確実な運用ミッション・クリティカルなアプリケーション運用管理

ビジネスの創造ビジネス成長のための消費者動向の洞察

スピーディな変革マーケット開発のための

開発,デプロイ,フィードバック

クラウド化API化レガシー・モダナイゼーション

Systems of Engagementに求められる要件


スピード~素早いITシステム開発~

柔軟性~容易なシステム変更・保守~

スピードと柔軟性を兼ね備えた IT基盤を実現するのがクラウド・ソリューション業務を実現するのがクラウド・ネイティブ・アプリケーション

クラウド・ネイティブ開発の方針と方策• 方針～アジャイル開発

• 短期間・高頻度で変わるビジネス・ニーズに見合ったITシステム構築を段階的に実現

• 方策

• クラウド• アジャイル開発を支える基盤技術

• マイクロサービス• アジャイル開発を支えるアプリケーション・アーキテクチャー・スタイル

• 継続的デリバリー• アジャイル開発を支える手法


• アジャイル開発により小さく始め、開発の繰り返しを継続することで, クラウドの価値が享受できる

• 特に投資対効果の観点で, One Offの開発では, 十分な効果は得られない

Microservices• クラウド上で稼働するITシステム開発プロジェクトからのフィードバックを集めたもの• James Lewis & Martin Fowler• Martin FowlerのWebサイト(Bliki)で発表

• http://martinfowler.com/articles/microservices.html

• マイクロサービス・アーキテクチャ・スタイル• 小さなサービスを組み合わせて, 一つのアプリケーションを開発する• 各サービスは, それぞれ独立したプロセスで動作する• 各サービスは, RESTのような軽量な仕組みで通信する• 各サービスは, 完全に自動化された仕組みで, それぞれ個別にデプロイ(配備)

される• サービスは, それぞれ異なるプログラミング言語で実装することができるし, 異なる

データ・ストレージを利用できる

• 動機• チーム開発, 各アプリケーション個別の保守, 繰り返し開発を, 促進するためのモジュラー構造(マイクロサービス)を導入• 一枚岩アプリケーション(非マイクロサービス・アプリケーション,モノリス)は, 保守性に劣り, 繰り返し開発を阻害する


継続的デリバリー (Continuous Delivery:CD)


継続的デリバリー(CD)

開発者クラウド(SaaS)

継続的インテグレーション(CI)

コーディング

コンパイル

テスト

自動化

ビルド

ソフトウェア構成管理(SCM)

ソースコード管理構成情報

アプリ

自動デプロイ

PaaS

基盤自動デプロイ

オーケストレーション

コンテナ

サービス

コンテナ

サービス

コンテナ

サービス

コンテナ

サービス

コンテナ

サービス

コンテナ

サービス

コンテナ

サービス

コンテナ

サービス

コンテナ

サービス

チェックインチェックアウト

繰り返し

マイクロサービス

開発

アプリケーションの開発プロセスとデプロイ, 基盤のデプロイを自動化システム・リリースのスピード・アップ, コスト抑制, 品質向上を実現

[参考] Cloud Native Computing Foundation• 非営利団体

• https://www.cncf.io/

• 膨大な数のテナントに対応できるようなモダンな分散システム環境を実現する新たなクラウド・コンピューティング・パラダイムの開発と普及を目標とする

• 傘下のプロジェクト• Fluentd :ロギング• Kubernetes :コンテナのオーケストレーション (デプロイ、スケール等自動管理)

• OpenTracing :トレース• Prometheus :監視

• クラウド・ネイティブ・システムは、次の3つの属性を備える、としている• Container packaged

• コンテナで分離された環境でアプリケーションは稼動

• Dynamically managed• コンピューター資源の使用率と効率化を最適化できるよう、動的に管理できること

• Micro-services oriented• 保守性とスピードを改善するために、Microservicesスタイルでアプリケーションを開発、保守


MICROSERVICES概要


[再掲] Microservices• クラウド上で稼働するITシステム開発プロジェクトからのフィードバックを集めたもの• James Lewis & Martin Fowler• Martin FowlerのWebサイト(Bliki)で発表

• http://martinfowler.com/articles/microservices.html

• Microservices アーキテクチャ・スタイル• 小さなサービスを組み合わせて, 一つのアプリケーションを開発する• 各サービスは, それぞれ独立したプロセスで動作する• 各サービスは, RESTのような軽量な仕組みで通信する• 各サービスは, 完全に自動化された仕組みで, それぞれ個別にデプロイ(配備)

される• サービスは, それぞれ異なるプログラミング言語で実装することができるし, 異なる

データ・ストレージを利用できる

• 動機• チーム開発, 各アプリケーション個別の保守, 繰り返し開発を, 促進するためのモジュラー構造(Microservices)を導入• 一枚岩アプリケーション(非Microservicesアプリケーション,Monolith - モノリス)は, 保守性に劣り, 繰り返し開発を阻害する


9つの特徴


Componentization via Serviceサービスによるコンポーネント化

Organized by Business Capabilityビジネス機能に基づいたチーム編成

ビジネス機能に基づくチーム編成14Copyright IBM Corporation 2017

コンウェイの法則：システム構造は, プロジェクト体制を反映する Microservices :

ビジネス目的に基づいてチーム編成システムは、独立して置き換え可能なサービスで構成される

MicroservicesMonolith

ユーザー・インターフェース・チーム

アプリケーション・サーバー・チーム

DBチーム

ユーザーインターフェース層

アプリケーション層

サービス#1チームサービス#1

サービス#2

サービス#3

サービス#2チーム

サービス#3チームDB層

ICTシステム構造開発運用プロジェクト体制

開発運用プロジェクト体制

ICTシステム構造

開発運用

開発運用

開発運用

開発運用

開発運用

開発運用

疎結合

密結合

密結合

疎結合

疎結合

保守時全システムに対する作業が必要保守時各サービスの置き換えが可能

ユーザー・インターフェース・スペシャリスト

アプリケーション・サーバー・スペシャリスト

DBスペシャリスト

DBアクセス・プログラム

アプリケーション・サーバー・プログラム

ユーザー・インターフェース・ページとプログラム

密結合

疎結合

凡例

9つの特徴




Products Not Projectsプロジェクトではなく製品として捉え開発運用する

プロジェクトではなく製品として捉え開発運用する


プロジェクトの例：ダム

製品の例：自動車

運用局面

官公庁・電力会社等

開発局面

ゼネコン

開発・運用局面

開発チーム

開発・運用局面

開発チーム

フィードバックを受けながら, One Teamが継続的に”開発・運用”する

Microservicesの開発・運用スタイル

9つの特徴




Products Not Projectsプロジェクトではなく製品として捉え開発運用する

Smart endpoints and dumb pipesインテリジェントなエンドポイントとシンプルなパイプ

Decentralized Governance非中央集権的な言語やツールの選択

Decentralized Data Management非中央集権的なデータ管理

Infrastructure Automation基盤の自動化

Design Failure障害, エラーを前提とした設計

Evolutionary Design先進的な設計

先進的な設計

• 次に挙げる技術トレンドを盛り込んだ設計• 仮想化

• 自動デプロイ

• クラウド・ネイティブ特有のテクニック

• テスト

• セキュリティ

• ロギングと監視


[参考] 仮想化• 物理的コンピューティング・リソースを論理的に分割したり、統合する技術

• コンピューティング・リソースとして、サーバー、CPU、メモリー、ストレージ、ネットワーク等が考えられる

• 例• 単一の物理的コンピューティング・リソースを複数のリソースに見せる• 複数の物理的コンピューティング・リソースを単一のリソースに見せる

• 実装• ハイパーバイザー

• 仮想マシンを提供するソフトウェア・コンポーネントで、その上にOS(ゲストOS)を含むソフトウェア・スタックを導入できる• タイプ1 : ハードウェア上で直接稼働するタイプのハイパーバイザー• タイプ2 : 別のOS上で稼働するタイプのハイパーバイザー

• 実装製品例• タイプ１ : XEN、VMware ESX

• タイプ2 : Oracle VirtualBox、VMware Workstation

• コンテナ• 1 Linux OS上で、分離された空間 (コンテナ)を提供するソフトウェア・コンポーネント• コンテナには、CPUやメモリーなどのコンピューティング・リソースが割り当てられ、仮想的に独立したLinux OS環境として利用出来る

• 実装製品例• Linux Containers (LXC)、Docker Container


[参考] 仮想化：ハイパーバイザーとコンテナの概念図


OS

アプリケーション

ハイパーバイザー

ハードウェア

ハイパーバイザーのタイプやコンテナによってソフトウェア・スタックの深さが違うソフトウェア・スタックの深さから、一般論としてコンテナは最も軽量と言える





OS

ハードウェア

OSアプリケーション

ハイパーバイザー

OS

ハードウェア





OS

OS


ハイパーバイザータイプ1

ハイパーバイザータイプ2

コンテナ

コンテナ

コンテナの境界





Microservicesの懸念点• サービスの粒度

• チームの粒度でもある• 2 Pizza Team

• ドメイン・スペシャリストであっても一回の分析・設計でサービス粒度を確定することは難しい

• 分散システムであるが故の複雑さ• 設計/開発/テスト

• データ整合性

• 運用オペレーション

• パフォーマンス

• One Off (一回だけの作業) では投資対効果が得られない• MicroservicePremium


Microservices

モノリス

開発期間・複雑さ (規模, 構成, スケーラビリティ, リソース最適化, 保守要件, 追加システム開発要件, …)

生産性

Microservicesの懸念点

• 技術の多様性• 各サービス毎に、プログラミング言語、ツール、データストアの選択を許容

• 課題

• チーム間でのエンジニアの異動が困難になる可能性あり

• 採用技術が一般的では無い場合、エンジニアの新規雇用が困難になる可能性あり

• 現実事例での対応例

• Netflixでは採用技術の標準化をすすめている

• プログラミング言語：Java

• データストア：Cassandra

• 適切な理由があれば、例外を許容する


モノリス・ファースト• モノリス・スタイルのアプリケーションを, 段階的にマイクロサービス・スタイルに置き換えるプラクティス• 初回のアプリケーション開発時：従来通りモノリス・スタイルで開発

• 繰り返し開発/保守時：マイクロサービス・スタイルで開発

• http://martinfowler.com/bliki/MonolithFirst.html

• 動機• マイクロサービスの懸念点の解決

• システム開発現場からのフィードバック


CoreService

Service Service

Service Service

ServiceService

Service Service

Monolith

Service Service

Service Service

Monolith

Serv

ice

Service

繰り返し繰り返し

一部機能をサービスとして分離機能をサービスとして分離新機能をサービスとして追加開発

モノリスとしてアプリケーションを開発

モノリス Microservices

Java EE サーバー

ショッピングサービス

Microservicesとモノリス~Java Webアプリケーションにおける構造の比較~


フロントエンド

JSP/JSF

オーダーEJB

商品カタログEJB

データ

API

Gateway

オーダーサービス

商品カタログサービス

フロントエンド

データデータデータ

ビジネス

Web

クライアント

註：Java EE : Javaによるサーバー・サイド・アプリケーション開発のための技術仕様。JSP/JSF : それぞれJavaによるWebページのテンプレート・ライブラリー、フレームワーク。Java Server Pages, Java Server Facesの略。

EJB : Javaによる、分散型コンポーネント・モデル。Enterprise JavaBeansの略。

MicroservicesとSOA

• Microservicesは、SOAを実現するための1つのアプローチ• 共に、”サービス”主体でITシステムを構成する考え方

• Microservicesは、アジャイル・ソフトウェア開発、リーン・スタートアップ、モダンなクラウド・テクノロジーを積極的に活用したサービス指向開発スタイルの派生形

• トップ・ダウン or ボトム・アップの違いがある• SOAは、トップ・ダウン・アプローチのアーキテクチャー

• ITベンダー、アーキテクトによる概念先行型の”アーキテクチャー”

• W3C策定のWebサービス仕様に深く依存

• Microservicesは、ボトム・アップ・アプローチのアーキテクチャー・スタイル

• 実際のITシステム開発プロジェクトからのフィードバックを基にした”アーキテクチャー・スタイル”

• Technology-Agnostic

• 製品・技術への依存性は最低限


まとめ


まとめ

• Microservicesは、クラウド・ネイティブ開発で効果的なアプリケーション開発手法(アーキテクチャー・スタイル)である

• Microservicesを採用する動機は、チーム開発, 各アプリケーション個別の保守, 繰り返し開発を, 促進すること

• サービス化にあたっては、段階的に、粗い粒度から細かい粒度にブレークダウンする

• 各サービスは、RESTやメッセージングなど、シンプルかつ軽量な手法で通信する

• Microservicesでは、サービス経由でデータにアクセスする

• 各サービスは、それぞれ個別のデリバリー・パイプラインを用いて、独立したコンテナ/仮想マシンにデプロイする



Documents

再利用性を重視した クラウド・システムの ライフサイクル · •各サービス毎に、プログラミング言語、ツール、データストアの選択を許容

再利用性を重視したクラウド・システムのライフサイクル · •各サービス毎に、プログラミング言語、ツール、データストアの選択を許容