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

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

1. 1. Japan Java User Group マイクロサービスアーキテクチャ アーキテクチャ設計と開発プロセスの歴史を背景に 2015/11/28 鈴木雄介 日本Javaユーザーグループ 会長 JJUG CCC 2015 Fall #ccc_gh3
2. 2. Japan Java User Group 自己紹介 鈴木雄介 – グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ – 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ – SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
3. 3. Japan Java User Group Agenda • アーキテクチャの変遷 • サービス管理のトレンド • MSA • プラットフォームの視点 • まとめ 2
4. 4. Japan Java User Group アーキテクチャの変遷 3
5. 5. Japan Java User Group アーキテクチャの変遷 4 メインフレーム データ データ ロジック ロジック クラサバ ウェブ データ ロジック ロジック ロジック
6. 6. Japan Java User Group メインフレームの時代 • サーバにロジックやデータを集中、 クライアントは見るだけ –サーバはハードウェアからソフトウェア までを統合的に管理する » AS400 –クライアントはダム端末と呼ばれ、単純 なビュワーであり、表現も貧弱 • ITの利用分野は経理や販売管理など の事務作業が中心 5 データ ロジック
7. 7. Japan Java User Group クラサバの時代 • 1か所にデータを集中し、クライアン トにロジックを配布する –PC＋イントラネット（TCP/IP） –サーバはバッチ処理に利用 –クライアントのファット化 » VisualBasic＋ORACLE • ITの利用分野が広まり、様々な社内 処理に使われてくる 6 データ ロジック ロジック
8. 8. Japan Java User Group ウェブの時代 • サーバとデータを集約し、クライア ントはブラウザ化する • インターネット！ –広域、オープン、ベストエフォート –Java! Java! Java! –ブラウザにどこまでのロジックを載せる かは永遠のテーマ • ITが”世界に拡がる”ようになる 7 データ ロジック ロジック
9. 9. Japan Java User Group 処理能力の場所と管理 • どこに処理能力があるのか？ –PCやインターネットという技術要素がアーキテクチ ャを変遷させてきた • どのように処理能力を管理するのか？ –これまではサーバとクライアントに閉じてきた 8
10. 10. Japan Java User Group クラウドの時代 • ウェブ時代を引き継ぎつつも、サー バの処理能力が超巨大化 –巨大なサービスの出現（Amazon.com） –総体としてのサービスは連続的な変化せ ざるをえない • では、巨大なサービスを、どのよう に管理していくのか？ 9 クラウド データ ロジック ロジック ロジック ロジック ロジック
11. 11. Japan Java User Group サービス管理のトレンド 10
12. 12. Japan Java User Group 11https://www.flickr.com/photos/willfolsom/5681274525/
13. 13. Japan Java User Group カナリアリリース • 別名：ブルー・グリーンデプロイ、A/Bテスト 12
14. 14. Japan Java User Group ダークカナリアリリース • 「本番環境でテストする」 –開発者にしか見えないリリースをする 13
15. 15. Japan Java User Group Chaos Monkey • 平日日中にサーバをランダムにダ ウンさせるためのOSS • Netflixではインスタンスは毎週 、アベイラビリティゾーンあるい はリージョン丸ごとは毎月障害 14
16. 16. Japan Java User Group サービス管理でやること • コードからサービスまでを自動化：DevOps –コードをレポジトリからチェックアウト –ビルドして、テストして、アーカイブして –デプロイ先のサーバを起動して –そのサーバにリリースして –サービスレポジトリにサービスを登録して –ロードバランサの設定を段階的に変更して –サービスの稼働状況を監視して –何かあったら色々する 15
17. 17. Japan Java User Group 必要な技術群 • デプロイ管理 – Jenkins、spinaker • コンテナ、コンテナ管理 – Docker – Kubernetes、Marathon+Mesos、spinaker • ルーター – Vamp、Zuul+Ribbon • サービスレポジトリ – ZooKeeper、Eureka • 分散ログ集約 – Elasticsearch、Vector 16
18. 18. Japan Java User Group 基本的な前提 • 「全体的にサービス品質を高めるために、部分 的な品質劣化を許容する」 –不運なユーザ（≒カナリア）は存在しうるが、サー ビス全体がダウンするような事態にはならない • 全てのサービスがこうなるべきではない –不幸なユーザーは認められない：医療/金融/軍事 –とはいえ、検討可能な領域もあるはず » 現在は技術的に難易度が高いけども 17
19. 19. Japan Java User Group そこで何が起きるのか？ • 巨大なサービスをいかに管理するか –様々な自動化によってサービスの管理が楽になった –であれば、アプリケーションの数が増えることは怖 くない –そもそも、現代はアプリケーション同士が連携する ことが前提になっている • じゃ、もっと積極的に分割していいんじゃね？ –ということで「マイクロサービスアーキテクチャ」 18
20. 20. Japan Java User Group MSA 19
21. 21. Japan Java User Group Microservices Architecture (MSA) • サービスによるコンポーネント化 • ビジネスケイパビリティに基づく組織化 • プロジェクトではなくプロダクト • スマートなエンドポイントと単純なパイプ処理 • 分散ガバナンス • 分散データマネジメント • インフラの自動化 • フェイルを前提とした設計 • 進化的な設計 20
22. 22. Japan Java User Group MSAの2つの側面 • 技術面：分散配置と統合 – サービスによるコンポーネント化 – スマートなエンドポイントと単純なパイプ処理 – 分散データマネジメント – インフラの自動化 – フェイルを前提とした設計 • 組織面：持続性と分権 – ビジネスケイパビリティに基づく組織化 – プロジェクトではなくプロダクト – 分散ガバナンス – 進化的な設計 21
23. 23. Japan Java User Group MSAの技術面：分散配置と統合 • サービスをサービスで構成する –静的要素の組み合わせから動的要素の組み合わせへ • メッセージによる統合 –個々の動的要素は標準プロトコルで協調動作する • サービスをマネージする –稼働監視、依存性管理、障害検知と復旧、ver管理 22
24. 24. Japan Java User Group MSAの組織面：持続性と分権 • サービス全体を持続的に動作させる –ソフトウェア開発からITサービス運営へ • ドメイン固有の技術と運営 –ドメインごとの自主性を認め、標準化を否定する • ドメイン個別のライフサイクル –個別再構築の許容、あるいは犠牲的アーキテクチャ 23
25. 25. Japan Java User Group MSAへの理解 • 広義には、粒度ではなく関係性に注目を • どの粒度でもよい（マイクロに惑わされない） –アプリとコンポーネント –システムとサブシステム –システム全体と個別システム • 重要なのはサービス相互の関係性のあり方 –複雑なものを、いかに管理するのか 24
26. 26. Japan Java User Group MSAへの理解 • 技術論と組織論の両輪が重要 –技術面：分散配置と統合 –組織面：持続性と分権 • 巨大なサービスはトップダウンに管理できない –サービスとチームを分割していく –それをDevOpsが保証していく 25
27. 27. Japan Java User Group サービスの分割 • モジュール分割の基本は「時間軸の中で変化す るスピードの違いの境目」で切る –経年劣化するものは交換可能にする –消費するものは充填可能にする –可能な限りは標準化して交換や充填を容易にする –外部要因と内部要因に注意 –機能だけではなく非機能にも気を遣う 26
28. 28. Japan Java User Group 参考：ソフトウェア品質 • ソフトウェア品質メトリクス 27 品質特性 品質副特性 機能適合性 完全性、正確性、適切性 性能効率性 時間効率性、資源利用性、キャパシティ 互換性 共存性、相互運用性 使用性 適切度認識性、習得性、運用性、ユーザエラー防止性 ユーザインタフェースの快美性、アクセシビリティ 信頼性 成熟性、可用性、障害許容性、回復性 セキュリティ 機密保持性、インテグリティ、否認防止性、責任追跡性、真 正性 保守性 モジュール性、再利用性、解析性、変更性、試験性 移植性 順応性、設置性、置換性 「情報システム/ソフトウェアの品質メトリクスセット」経済産業省 ソフトウェアメトリクス高度化プロジェクト 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
29. 29. Japan Java User Group サービスの多様性を保証する • サービスは多様である –でも、完全に多様ではうまくいかない –適切に全体を管理しつつ、ボトムアップを許容する • あるルールの元で多様性を保証する –それがプラットフォーム 28
30. 30. Japan Java User Group プラットフォームの視点 29
31. 31. Japan Java User Group クラウドとプラットフォーム 30 ネットワーク 仮想化 ストレージ サーバ OS ミドルウェア コード 設定 実行環境 データ SaaS PaaS IaaS 仮想マシン バッチ リモート実行 モバイルアプリ API管理 プッシュ通知 リアルタイム分析 RDB NoSQL キャッシュ ストレージ サーチ Hadoopクラスタ 機械学習 ストリーム処理 データ変換 イベント処理 仮想ネットワーク 負荷分散 ロードバランサ DNS VPN メディア変換 CDN ハブ処理 バックアップ リカバリ 認証認可 開発ツール スケジューラー インフラ自動化
32. 32. Japan Java User Group プラットフォームとは • 巨大なサービスを管理するための基盤 –あるルールを定義し、それに則る限りにおいては、 多様性を認める –AWSのサービスを利用したほうが便利 –Web企業の柔軟なプラットフォームは、チームのば らつきも許容する » チームを細かく指導するぐらいなら、多少のミスを受け入 れた方がよい ※すべてのITサービスが、それでいいわけではない 31
33. 33. Japan Java User Group プラットフォームを利用する • パブリッククラウドのPaaS –IaaSとしてだけ利用するのはもったいない –クラウドデザインパターンを参考に –積極的に”そのPaaS”に従うことで柔軟性が手に入る » でも、ロックインも発生する！ » 様々なプラットフォームが存在するので、いろいろなもの を経験することを推奨する » 今後は業界特化のプラットフォームは増えていくはず 32
34. 34. Japan Java User Group プラットフォームを設計する • アーキテクチャ設計の対象がアプリだけではな く、プラットフォームになっていく –より全体的な視点の上で判断が必要になる –パブリッククラウドを利用することも重要だけど、 プライべートなプラットフォームも増える • プライベートなPaaSの登場 –エンタープライズでは自社PaaSを作るための仕組み が主流になっていくはず –インフラの統合から、プラットフォームの統合へ 33
35. 35. Japan Java User Group まとめ 34
36. 36. Japan Java User Group アーキテクチャの変遷 • どこに処理能力があるのか？ –メインフレーム＞クラサバ＞ウェブ » PCやインターネットが大きく変えた –現在はクラウドという超巨大サーバ • その処理能力をどう管理するか？ –サーバとクライアントという時代から、超巨大なサ ービスを管理する時代に 35
37. 37. Japan Java User Group サービス管理のトレンド • 全てを自動化する –カナリアリリース –ダークカナリアリリース –Chaos Monkey • 全体的にサービス品質を高めるために、部分的 な品質劣化を許容する • 機能の分割が許容できるようになってきた 36
38. 38. Japan Java User Group マイクロサービス • 技術面：分散配置と統合 • 組織面：持続性と分権 • 巨大なサービスはトップダウンに管理できない –でも、ボトムアップだけではうまくいかない –適切に全体を管理しつつ、ボトムアップを許容する –「あるルールの元で多様性を保証する」 37
39. 39. Japan Java User Group プラットフォーム • 巨大なサービスを管理するための基盤 –あるルールを定義し、それに則る限りにおいては、 多様性を保証する • まだまだ技術的にも設計的にも未成熟な状況 –先端的な事例がでてきて、OSSなどを通じて広まり つつある –成熟すればプライベートなPaaSは増えていく 38
40. 40. Japan Java User Group 最後に • プラットフォームをデザインする、プラットフ ォームを利用するという視点を持とう –「アプリを作って、それを動かすサーバを作る」と いう考え方は終わる –プラットフォームに従うかぎりは柔軟性を保証する –今後、プラットフォームの標準化が進めば、より柔 軟性が高まっていくと思われる 39