Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

マイクロサービス入門(Spring fest 2017)

9,791 views

Published on

Spring Fest 2017の発表資料です。

Published in: Engineering
  • Be the first to comment

マイクロサービス入門(Spring fest 2017)

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

×