マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に

Japan Java User Group

マイクロサービスアーキテクチャアーキテクチャ設計と開発プロセスの歴史を背景に

2015/11/28

鈴木雄介日本Javaユーザーグループ会長

JJUG CCC 2015 Fall

#ccc_gh3


自己紹介

鈴木雄介– グロースエクスパートナーズ（株）

» 執行役員/アーキテクチャ事業本部長

» http://www.gxp.co.jp/

– 日本Javaユーザーグループ

» 会長

» http://www.java-users.jp/

– SNS

» http://arclamp.hatenablog.com/

» @yusuke_arclamp

1


Agenda

• アーキテクチャの変遷

• サービス管理のトレンド

• MSA

• プラットフォームの視点

• まとめ

2


アーキテクチャの変遷

3



4

メインフレーム

データデータ

ロジック

ロジック

クラサバウェブ

データ

ロジック

ロジックロジック


メインフレームの時代

• サーバにロジックやデータを集中、クライアントは見るだけ

–サーバはハードウェアからソフトウェアまでを統合的に管理する

» AS400

–クライアントはダム端末と呼ばれ、単純なビュワーであり、表現も貧弱

• ITの利用分野は経理や販売管理などの事務作業が中心

5

データ

ロジック


クラサバの時代

• 1か所にデータを集中し、クライアントにロジックを配布する

–PC＋イントラネット（TCP/IP）

–サーバはバッチ処理に利用

–クライアントのファット化

» VisualBasic＋ORACLE

• ITの利用分野が広まり、様々な社内処理に使われてくる

6

データ

ロジック

ロジック


ウェブの時代

• サーバとデータを集約し、クライアントはブラウザ化する

• インターネット！

–広域、オープン、ベストエフォート

–Java! Java! Java!

–ブラウザにどこまでのロジックを載せるかは永遠のテーマ

• ITが”世界に拡がる”ようになる

7

データ

ロジック

ロジック


処理能力の場所と管理

• どこに処理能力があるのか？

–PCやインターネットという技術要素がアーキテクチャを変遷させてきた

• どのように処理能力を管理するのか？

–これまではサーバとクライアントに閉じてきた

8


クラウドの時代

• ウェブ時代を引き継ぎつつも、サーバの処理能力が超巨大化

–巨大なサービスの出現（Amazon.com）

–総体としてのサービスは連続的な変化せざるをえない

• では、巨大なサービスを、どのように管理していくのか？

9

クラウド

データ

ロジック

ロジック

ロジック

ロジック

ロジック


サービス管理のトレンド

10

Japan Java User Group 11https://www.flickr.com/photos/willfolsom/5681274525/

https://www.flickr.com/photos/willfolsom/5681274525/


カナリアリリース

• 別名：ブルー・グリーンデプロイ、A/Bテスト

12


ダークカナリアリリース

• 「本番環境でテストする」

–開発者にしか見えないリリースをする

13


Chaos Monkey

• 平日日中にサーバをランダムにダウンさせるためのOSS

• Netflixではインスタンスは毎週、アベイラビリティゾーンあるいはリージョン丸ごとは毎月障害

14


サービス管理でやること

• コードからサービスまでを自動化：DevOps

–コードをレポジトリからチェックアウト

–ビルドして、テストして、アーカイブして

–デプロイ先のサーバを起動して

–そのサーバにリリースして

–サービスレポジトリにサービスを登録して

–ロードバランサの設定を段階的に変更して

–サービスの稼働状況を監視して

–何かあったら色々する

15


必要な技術群

• デプロイ管理– Jenkins、spinaker

• コンテナ、コンテナ管理–Docker

–Kubernetes、Marathon+Mesos、spinaker

• ルーター–Vamp、Zuul+Ribbon

• サービスレポジトリ–ZooKeeper、Eureka

• 分散ログ集約–Elasticsearch、Vector

16


基本的な前提

• 「全体的にサービス品質を高めるために、部分的な品質劣化を許容する」

–不運なユーザ（≒カナリア）は存在しうるが、サービス全体がダウンするような事態にはならない

• 全てのサービスがこうなるべきではない

–不幸なユーザーは認められない：医療/金融/軍事

–とはいえ、検討可能な領域もあるはず

»現在は技術的に難易度が高いけども

17


そこで何が起きるのか？

• 巨大なサービスをいかに管理するか

–様々な自動化によってサービスの管理が楽になった

–であれば、アプリケーションの数が増えることは怖くない

–そもそも、現代はアプリケーション同士が連携することが前提になっている

• じゃ、もっと積極的に分割していいんじゃね？

–ということで「マイクロサービスアーキテクチャ」

18


MSA

19


Microservices Architecture (MSA)

• サービスによるコンポーネント化

• ビジネスケイパビリティに基づく組織化

• プロジェクトではなくプロダクト

• スマートなエンドポイントと単純なパイプ処理

• 分散ガバナンス

• 分散データマネジメント

• インフラの自動化

• フェイルを前提とした設計

• 進化的な設計

20


MSAの2つの側面

• 技術面：分散配置と統合–サービスによるコンポーネント化

–スマートなエンドポイントと単純なパイプ処理

–分散データマネジメント

–インフラの自動化

–フェイルを前提とした設計

• 組織面：持続性と分権–ビジネスケイパビリティに基づく組織化

–プロジェクトではなくプロダクト

–分散ガバナンス

–進化的な設計

21


MSAの技術面：分散配置と統合

• サービスをサービスで構成する

–静的要素の組み合わせから動的要素の組み合わせへ

• メッセージによる統合

–個々の動的要素は標準プロトコルで協調動作する

• サービスをマネージする

–稼働監視、依存性管理、障害検知と復旧、ver管理

22


MSAの組織面：持続性と分権

• サービス全体を持続的に動作させる

–ソフトウェア開発からITサービス運営へ

• ドメイン固有の技術と運営

–ドメインごとの自主性を認め、標準化を否定する

• ドメイン個別のライフサイクル

–個別再構築の許容、あるいは犠牲的アーキテクチャ

23


MSAへの理解

• 広義には、粒度ではなく関係性に注目を

• どの粒度でもよい（マイクロに惑わされない）

–アプリとコンポーネント

–システムとサブシステム

–システム全体と個別システム

• 重要なのはサービス相互の関係性のあり方

–複雑なものを、いかに管理するのか

24


MSAへの理解

• 技術論と組織論の両輪が重要

–技術面：分散配置と統合

–組織面：持続性と分権

• 巨大なサービスはトップダウンに管理できない

–サービスとチームを分割していく

–それをDevOpsが保証していく

25


サービスの分割

• モジュール分割の基本は「時間軸の中で変化するスピードの違いの境目」で切る

–経年劣化するものは交換可能にする

–消費するものは充填可能にする

–可能な限りは標準化して交換や充填を容易にする

–外部要因と内部要因に注意

–機能だけではなく非機能にも気を遣う

26


参考：ソフトウェア品質

• ソフトウェア品質メトリクス

27

品質特性品質副特性

機能適合性完全性、正確性、適切性

性能効率性時間効率性、資源利用性、キャパシティ

互換性共存性、相互運用性

使用性適切度認識性、習得性、運用性、ユーザエラー防止性ユーザインタフェースの快美性、アクセシビリティ

信頼性成熟性、可用性、障害許容性、回復性

セキュリティ機密保持性、インテグリティ、否認防止性、責任追跡性、真正性

保守性モジュール性、再利用性、解析性、変更性、試験性

移植性順応性、設置性、置換性

「情報システム/ソフトウェアの品質メトリクスセット」経済産業省ソフトウェアメトリクス高度化プロジェクトhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdfhttp://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf

http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_04.pdf

http://www.meti.go.jp/policy/mono_info_service/joho/cloud/2011/11_03.pdf


サービスの多様性を保証する

• サービスは多様である

–でも、完全に多様ではうまくいかない

–適切に全体を管理しつつ、ボトムアップを許容する

• あるルールの元で多様性を保証する

–それがプラットフォーム

28


プラットフォームの視点

29


クラウドとプラットフォーム

30

ネットワーク

仮想化

ストレージ

サーバ

OS

ミドルウェア

コード

設定

実行環境

データ

SaaS

PaaS

IaaS

仮想マシンバッチリモート実行モバイルアプリAPI管理プッシュ通知リアルタイム分析RDBNoSQLキャッシュストレージサーチHadoopクラスタ機械学習ストリーム処理データ変換

イベント処理仮想ネットワーク負荷分散ロードバランサDNSVPNメディア変換CDNハブ処理バックアップリカバリ認証認可開発ツールスケジューラーインフラ自動化


プラットフォームとは

• 巨大なサービスを管理するための基盤

–あるルールを定義し、それに則る限りにおいては、多様性を認める

–AWSのサービスを利用したほうが便利

–Web企業の柔軟なプラットフォームは、チームのばらつきも許容する

»チームを細かく指導するぐらいなら、多少のミスを受け入れた方がよい

※すべてのITサービスが、それでいいわけではない

31


プラットフォームを利用する

• パブリッククラウドのPaaS

– IaaSとしてだけ利用するのはもったいない

–クラウドデザインパターンを参考に

–積極的に”そのPaaS”に従うことで柔軟性が手に入る

»でも、ロックインも発生する！

»様々なプラットフォームが存在するので、いろいろなものを経験することを推奨する

»今後は業界特化のプラットフォームは増えていくはず

32


プラットフォームを設計する

• アーキテクチャ設計の対象がアプリだけではなく、プラットフォームになっていく

–より全体的な視点の上で判断が必要になる

–パブリッククラウドを利用することも重要だけど、プライべートなプラットフォームも増える

• プライベートなPaaSの登場

–エンタープライズでは自社PaaSを作るための仕組みが主流になっていくはず

–インフラの統合から、プラットフォームの統合へ

33


まとめ

34



• どこに処理能力があるのか？

–メインフレーム＞クラサバ＞ウェブ

» PCやインターネットが大きく変えた

–現在はクラウドという超巨大サーバ

• その処理能力をどう管理するか？

–サーバとクライアントという時代から、超巨大なサービスを管理する時代に

35


サービス管理のトレンド

• 全てを自動化する

–カナリアリリース

–ダークカナリアリリース

–Chaos Monkey

• 全体的にサービス品質を高めるために、部分的な品質劣化を許容する

• 機能の分割が許容できるようになってきた

36


マイクロサービス

• 技術面：分散配置と統合

• 組織面：持続性と分権

• 巨大なサービスはトップダウンに管理できない

–でも、ボトムアップだけではうまくいかない

–適切に全体を管理しつつ、ボトムアップを許容する

–「あるルールの元で多様性を保証する」

37


プラットフォーム

• 巨大なサービスを管理するための基盤

–あるルールを定義し、それに則る限りにおいては、多様性を保証する

• まだまだ技術的にも設計的にも未成熟な状況

–先端的な事例がでてきて、OSSなどを通じて広まりつつある

–成熟すればプライベートなPaaSは増えていく

38


最後に

• プラットフォームをデザインする、プラットフォームを利用するという視点を持とう

–「アプリを作って、それを動かすサーバを作る」という考え方は終わる

–プラットフォームに従うかぎりは柔軟性を保証する

–今後、プラットフォームの標準化が進めば、より柔軟性が高まっていくと思われる

39

マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に

Technology