マイクロサービス入門(Spring fest 2017)
•Descargar como PPTX, PDF•
8 recomendaciones•14,674 vistas
Spring Fest 2017の発表資料です。
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a マイクロサービス入門(Spring fest 2017)
Similar a マイクロサービス入門(Spring fest 2017) (20)
Más de Yuichi Hasegawa
Más de Yuichi Hasegawa (16)
マイクロサービス入門(Spring fest 2017)
- 3. 3 長谷川 裕一 • 合同会社Starlight&Storm 代表 • 日本Springユーザ会 会長 • Springやオブジェクト指向を中心にしたコンサルティ ングや教育で活動中 https://www.facebook.com/ starlightandstorm/ https://twitter.com/StarlightFuku 3
- 4. 本日の内容 • マイクロサービスの基本的なハナシ • マイクロサービスが、なぜ必要なのか？本当 に必要なのか？ • マイクロサービスの開発は、どうしたら上手く いくのか？失敗するのはなぜか？ • と云ったことを、自分なりの経験とか知識とか で咀嚼して… • 技術的なハナシは少ないです 4
- 5. マイクロサービスとは… • みんなが欲しいのは、狭義のマイクロサービ スではなく、広義のマイクロサービス – 狭義 • Microservice • Spring Bootなどで作った1つのアプリケーション – 広義 • Microservices • マイクロサービス=アーキテクチャで作られた、マイクロ サービス=エコシステム 5
- 6. マイクロサービスとは？ • 固有の責務を持ったサービスをコンポーネント化 （部品化）したもの • 別プロセスで動作するサービス（コンポーネント化さ れたアプリケーション） – そのコンポーネントの規模が小さい（マイクロ） – データは統合されず、サービスごとにデータを持つ 中身の設計は、基本的に 今まで通りのNレイヤ マイクロサービス マイクロサービス マイクロサービス 6
- 8. あれ？オブジェクト指向の説明だっけ？ • メッセージ指向で自律分散協調 • マイクロサービスの位置透過性（サービスロケータ） なども、昔からある設計の考え方 オブジェクト指向自律分散協調 オブジェクト指向はチームワーク１ • オブジェクトは単独で存在するのでなく、メッセージによる コラボレーションを行いつつ全体でひとつの仕事をする。 • オブジェクトは固有の責務（responsibility）を持つ。 オブジェクト オブジェクト オブジェクト メッセージ オブジェクト オブジェクト メッセージ ごめんなさい。 前スライドはこれ のパクリです 8
- 9. 参考：これはマイクロサービスではない • 「オブジェクト指向開発超入門」2003年頃の資料から抜粋 • オブジェクト指向の必要性 – 製品やサービスの開発サイクル、ソフトのバージョンアップ間隔が短くなっている • 段階的仕様追加に柔軟に対応した開発体制 • 仕様変更、機能追加、システム保守への柔軟な対応 • 信頼性の高い堅牢なシステムを短期開発で • インタフェース重視で、部品化と並行開発の現実化 • 高い拡張性/保守性 – 保守の容易性 • カプセル化により、変更の影響が広がらない – 交換、拡張が容易 • 部品となるオブジェクトを取り替えるだけ • 再利用の仕組み – オブジェクトを単位として、様々なレベルでのソフトウェアの部品化が可能 • 関連するデータと手続きをパッケージ – 使い方が明確に決まっているため、クライアント側からの利用が容易 • カプセル化により内部はブラックボックス • 明確な利用インターフェース • オブジェクトモデルなら反復型開発 9
- 10. マイクロサービス=エコシステム • マイクロサービスで実現されたシステムは、各サービスごとに 変更/追加が行なわれ、漸進的に設計が行われ、進化する • それを支えるための、ハードウェア等からなるレイヤ レイヤ1: ハードウェア レイヤ2： 通信 レイヤ3： アプリケーション=プラットフォーム レイヤ4： マイクロサービス • 物理サーバやデータベース、OSなど • ホストレベルの監視、ログ • ネットワーク、サービスレジストリ、 負荷分散など • 開発環境、テスト、ビルド、リリース ツールなど • マイクロサービスレベルの監視、ログ • マイクロサービスとその構成情報 10
- 11. レイヤ3：インフラストラクチャ自動化 • マイクロサービスの開発では必須事項 – 継続的デリバリが実現され、自動テストや自動デプロイな どが採用されてなければならない 11 Concourse CI コーディング UnitTest... Unit Test Metrics Find Bugs Spring Cloud Contract ST 本番 結合 システム 管理者 commit Blue/Green Deployment 結果通知 開発者 自動化の例 Spring Cloud Contracは Microserviceの単体テス トを簡単に実現 Cloud Foundryの CI/CD用に作られた パイプラインCI
- 12. エコシステムのチームワーク • マイクロサービス=エコシステムにおける2つの重要な チームワーク – システム内のマイクロサービスのチームワーク • マイクロサービスの分散協調 • メッセージ連携による自立と自律 • 責務を持ったマイクロサービスによる役割分担 – 顧客と開発者、開発者、開発チーム同士のチームワーク マイクロサービス マイクロサービス開発チーム 開発チームごめんなさい。 このスライドも、文章の 部分はオブジェクト指向 のパクリです 12
- 13. マイクロサービスの粒度 • まとめ方 – 固有のサービスをデータとそれを扱う処理の単位でまとめる – 不自然な複数のサービスをまとめてはいけない – 単一責任原則 • 変更の理由が同じものは集め、違うものは分ける • 規模 – 2週間で書き直せる程度（Jon Evans） – 概ね、「郵便番号検索」よりは大きく、基幹システムに含まれる「販売」 や「物流」「会計」などよりは小さい – サービスがチーム構造と一致する程度の大きさ（コンウェイの法則） – 経験的には、マイクロではなくミニがいい 13
- 14. マイクロサービスの正解 • クラスの作り方や粒度も、最近になってDDDなどのお陰でよう やく分かるようになってきてるのに（それでも現場では四苦八 苦してるのに）、新しいマイクロサービスに正解を求めることが 誤っている – 正解はプロジェクトで異なる。作ってみないと分からない • 多分 今後は、異常に大きい（小さい）マイクロサービスや、必 要以上に複数の役割を持ったマイクロサービスなどが作られ て、10年後ぐらいに笑い話になる なんでもクラス なんでも マイクロ サービス 将来は… 14
- 16. 方法論が抜けている… • マイクロサービスには技術論はあっても、開発の方 法論（プロセスと表記法）が抜けている – サービスとして分割するために、DDDのシステム境界とい う考え方は役に立つ、とか場面だけを切り取られても… • 方法論があってもオブジェクト指向開発は、上手くい かなかったケースが多いらしいが… – アジャイルで動くモノをさっさと作るというのは、少なくとも エンプラ系のマイグレーションには向かないだろう – 方法論がない方が上手くいくという結論にはならないだろ う • カタリシス（コンポーネントベース開発の方法論）やSOAを持ってく る!? 16
- 17. マイクロサービス、なぜ必要なのか？ • モノリシックなシステムの問題 – コードが巨大化→全体の把握が困難→１つの修正でデグ レが発生→大量のテスト→デプロイのプロセスが複雑→ ビジネスの変化に対応できない⇨ じゃあ、マイクロサービ スだ！ • マイグレーション • 時代的な背景の結果 – ビジネスの変化に強い→直ぐに作ってリリースできる→小 さく作る→変更した時の影響も小さくしたい→独立性を高く する→そこだけスケールしたい⇨ じゃあ、マイクロサービス だ！ • 新規開発（派生開発の機能追加） 17
- 18. モノリシック→マイクロサービス(1) • 最初に理解しておきたいこと – 複雑なもの（難しいもの）は簡単にならない • 「マンガでわかる量子力学」→マンガで描いても量子 力学の難しさは無くならない（導入には役立つけど、先 に進めば難しさにぶつかる） • そして、複雑なものは容易に（マイクロサービスに）分 割できない • 間違った理解（新技術に対してよくある） – マイクロサービスやDDDなどの新技術を使うと、複雑な （難しい）既存システムが簡単になる • 1つ1つのオブジェクト（コンポーネントやマイクロサービ スを含む）のテストなどは簡単になるが、全体が複雑 なものは、やっぱり複雑で難しい 18
- 19. モノリシック→マイクロサービス(2) • 成功の鍵？その1 – レガシシステムが複雑すぎることを認めて、マイクロサービス化を諦 める • 成功の鍵？その2 – マイクロサービス化の前に準備する • データモデルを整理する • MyBatisで複雑なSQLを利用するのをやめて、JPAやHibernateで 動作可能にする • 役割ごとにパッケージ化して、複雑な依存関係（特に相互依存）を なくす – 一度にマイクロサービス化しない • 変更が多い部分などから少しずつモノリシックから抜き出して、マ イクロサービス化する – 最初から最高を求めない（次からのスライドを参考） 19
- 21. 参考：Cloud Native Maturity Model 21 レベル 概要 Cloud Native ・最適化されたMicroservices アーキテクチャが適用されている ・APIファーストな設計が行なわれている Cloud Resillient ・Microserviceは、依存するサービスの障害に影響を受けない ・障害やパフォーマンスも含めたMicroserviceの測定とモニタリングが できている ・作成するMicroserviceはクラウド環境に影響されないようになっている Cloud Friendry ・アプリケーション（Microservice）では、Twelve Factorが実現されてい る ・システムは、水平方向にスケーラブルとなっている ・システムは高可用性となっている Cloud Ready ・アプリケーションは独立している ・インフラはコードで管理されている ・クラウド環境を利用している
- 22. 参考：Cloud Native Application Maturity Model 22 レベル 概要 Adaptive （適応） GOAL: 運用や管理が自動化された状態 ・アプリケーションは、サービスの中断なしで、動的にインフラ間を移動できる ・アプリケーションは適切にスケールイン/アウトを行うことができる Abstracted （抽象化） GOAL: マイクロサービスの構築 ・サービスはステートレスである ・アプリケーションは依存しているサービスを知らない。また失敗による影響も受けな い ・アプリケーションは、インフラストラクチャにとらわれないで、どこでも実行することがで きる Loosely Coupled （疎結合） GOAL: 主要なコンポーネント（もしくはレイヤ）が独立している ・アプリケーションは、疎結合なサービスで構成されている ・アプリケーション（サービス）は、名前によって発見される ・アプリケーションの処理とストレージが分離している ・アプリケーションは1つ以上のサービスを利用している Virtualized （仮想化） GOAL: 迅速なインストール ・アプリケーションは仮想化されたインフラ上で実行される ・システムはイメージとして保存され、インスタンス化できる
- 24. つまり、誰が管理するのか？ • 誰が、システム全体もしくは1つのマイクロサービスを運用/保 守するのか？（コンウェイの法則!?） • マイクロサービスでは、ビジネスケイパビリティに基づく組織化 （役割ごとにチームが構成されるのではなく、複数の役割が混 在したチームがひとつのサービスを構築する）、プロジェクトで はなくプロダクト（コンポーネントは期限のあるプロジェクトとして 開発されるのではなく、継続的なプロダクトとして提供される）と 言われるが… • そもそも、サービスの数は管理するか？ 上限はどうやって決ま るのか？ 24
- 26. 注文システム 復元できないデータモデル • FKはマイクロサービス化で消した、ER図はもちろん ない、いや待てよマイクロサービス図がある…の!? – そもそもスケールさせることを考えたら、RDBは捨てなけ ればダメ…!? 商品管理 注文管理 商品 TBL 注文 TBLFK 商品 サービス 商品 TBL 注文 TBL 注文 サービス 【外部キーの削除として紹介されているテクニック】 26
- 27. 技術的な選択 • マイクロサービスでは、分散ガバナンス（サービスごとに言語 やデータベースなどは統一されず、個別に適切なものが選択 される）などとも云われるが、現実的には、言語はJavaで、 Springに統一した方が良い • Java以外の言語が許されるのは、フロントエンドのUI部分だ けにした方が無難 フロントエンドUI マイクロ サービス HTML テンプレート CSS $websocket (Kaazing) $http データ モデル ロジック Web ストレージ コントローラ ロジック ビュー ロジック ビュー コントローラ モデル ディレクティブ フィルタ バリデータ $scope サーバサイドは Spring Boot Angularなど HTTP/ REST 27
- 28. 現在のシステム • 現在のシステムをSoR(System of Record)とSoE(System of Engagement)で俯瞰してみる – SoRはメインフレームの基幹システムに代表されるデータを記録するような、定 型的なシステム – SoEはクラウドやモバイル、センサーデバイスを積極的に利用するような、非定 型的なシステム 28 SoE SoR オンプレ + モノリシック 勘定系 販売系 B2B IoT • Cloud • 分散 • 可用性 • Legacy • 集中 • 一貫性
- 29. マイクロサービスの適用 • 既存システムの有無、データモデルや組織的な部分で成功 と失敗が分かれると推測する 29 SoE SoR オンプレ + モノリシック 勘定系 販売系 B2B IoT • Cloud • 分散 • 可用性 • Legacy • 集中 • 一貫性 MIcroservices 多分、成功する（してい る）ところ MIcros ervices 多分、あまり成功しな いところ
- 30. 結論!? • 適材適所でマイクロサービスとレガシシステ ムのハイブリッド マイ ク ロ サービス マイ ク ロ サービス マイ ク ロ サービス メ ッ セージ メ ッ セージ マイ ク ロ サービス マイ ク ロ サービス マイ ク ロ サービス XXX システム OOO システム Legacy、一貫性 勘定系… Cloud、分散 B２C… コンシューマ 無理にマイクロサー ビスにしないところ マイクロサービスを積 極的に取り入れると ころ 30
- 31. まとめ • いろんな意味でまだまだ、マイクロサービスに は課題は多い • でも、やってみる、勉強してみるだけの価値 はある（エンジニアにとっては） • そして、 マイクロサービスをやるのなら Spring ! 新しいものは決してうまく働かない。だがいつも、 今度こそうまくゆくだろうという希望がある（G・M・ ワインバーグ ） 31