Download as PDF, PPTX
![分散統治
柔軟な変更
About Microservices
堅牢巨⼤なアプリを⼩さなサービスへ分離し、ビジネス変化へ柔軟に対応
[アプリ肥大化]
• コードは複雑、影響範囲が不明確
• 関わる開発者が増える
[ビジネスへの影響]
• 1つのバグが全サービス停止の可能性
• ビジネスへの機敏な対応ができない
一極集中開発
変更が困難
S
Y
U
%
[
{
Integrated Storage
Q
U
Y
%
S
[
{ Microservices
(1) 障害時のサービス影響の極小化 (2) ビジネス速度への柔軟な対応
1枚岩のアプリを
小さなサービスへ分離](https://image.slidesharecdn.com/microservices-12fa-160724063806/85/Microservices-9-320.jpg)
Uploaded byTakashi Abe
Microservicesを実現するために、インフラエンジニアと開発者がすべきこと
Microservies を実現するために、インフラエンジニアおよびアプリケーション開発者が、すべきことをまとめました。
More Related Content
Similar to Microservicesを実現するために、インフラエンジニアと開発者がすべきこと
Microservicesを実現するために、インフラエンジニアと開発者がすべきこと
- 1.
- 2. • 妻1娘4 • 外資PaaS/SaaS系企業 •ソリューションエンジニア • 初級アクアリスト • 深⽥恭⼦殿堂⼊り • Perfume-かしゆか派/BABYMETAL • 座右の銘:⼈⽣即是遊戯 • 年齢不詳。 しょっさん ID : sho7650
- 3. Why Microservices? そもそも Microservicesはどのようにして⽣まれたか
- 4. アプリを細かく分解したらどうなの p 開発者が増えるとコードが増え、デプロイに時間がかかる p 開発者の得意な⾔語や、サービスを利⽤できない p変更があると、どこに影響が発⽣するか分からない p 個別のコンポーネントだけをスケールできない p どこかに問題があると、すべてのサービスが停⽌する The Background “Microservices” の⽣まれた背景 アプリケーションの規模がおおきくなり、開発者が増えた結果、 開発制約が増え、開発者の不満が増えました。
- 5. Background of WebServices 出典:「BlueGreenDeployment」 http://martinfowler.com/bliki/BlueGreenDeployment.html ⾃動化と使い捨てによる新しいWebアーキテクチャが⽣み出されました INFRASTRUCTURE VERSIONING VIRTUALIZATION (Bootstrapping) IMAGE APPLICATION DEPLOYMENT (Command and Control) SERVER CONFIGURAION (Configuration) CONTINUOUSINTEGRATION SYSTEMTOOL ⾃動化が急速に発展し、⾃動化に特化したアーキテクチャへの変⾰が進む Blue Green Deployment DevOps / System Automation 稼働中システム(⻘)には⼿を⼊れず、まったく別 に更新済みインフラ、アプリケーション(緑)を準 備。それをネットワーク毎、⼀気に切り替えるソ フトウェアリリース⽅式を提唱。 インフラ、ミドルウェア、アプリケーションのデ プロイ、そしてテストまで⾃動化。継続的インテ グレーションと呼ばれ、短サイクルでのソフト ウェアリリースを実現。 安全なリリース プロセスを提⽰ リソース使い捨て⽂化 による⽅式の実現 Immutable Infrastructure
- 6.
- 7. The Birth ofMicroservices 出典 : 「Microservices」 http://martinfowler.com/articles/microservices.html James Lewis/Martin Fowler - "Microservices" • 25 March 2014 • James Lewis/Martin Fowler らは、優れたWebサービスの要 素をまとめていくと、ある特性と効果があることに気がつきま した。 • “ビジネス遂⾏能⼒に関わる組織、⾃動化されたデプロイメント、エン ドポイントの知性(intelligence)、そしてプログラミング⾔語とデータ の分散制御に関する明確に共通な特性” • そしてそれを “Microservices” と名付けました 単⼀のアプリケーションを⼩さなサービス群の組み合わせとして構築 する⼿法。個々のサービスは⾃⾝のプロセス上で動作し、HTTPのリ ソースAPIなど軽量の機構により通信を⾏う。 サービスはビジネス遂⾏能⼒に合わせて構築され、完全に⾃動化。 各サービスは異なるプログラミング⾔語により記述され、異なるデー タストレージ技術により実現。
- 8.
- 9. 分散統治 柔軟な変更 About Microservices 堅牢巨⼤なアプリを⼩さなサービスへ分離し、ビジネス変化へ柔軟に対応 [アプリ肥大化] • コードは複雑、影響範囲が不明確 •関わる開発者が増える [ビジネスへの影響] • 1つのバグが全サービス停止の可能性 • ビジネスへの機敏な対応ができない 一極集中開発 変更が困難 S Y U % [ { Integrated Storage Q U Y % S [ { Microservices (1) 障害時のサービス影響の極小化 (2) ビジネス速度への柔軟な対応 1枚岩のアプリを 小さなサービスへ分離
- 10. Characteristics of aMicroservice Architecture 出典 : 「Microservices」 http://martinfowler.com/articles/microservices.html Microservicesのもつ特性は、SOAの概念を実装に近づけたものとも⾔えます • Componentization via Services サービスを通じたコンポーネント化 • Organized around Business Capabilities ビジネス遂⾏能⼒に関わり組織が整理されること • Products not Projects プロジェクトではなくプロダクト • Smart endpoints and dumb pipes 賢いエンドポイントと⼟管 • Decentralized Governance 分散統治 • Decentralized Data Management 分散データ管理 • Infrastructure Automation インフラ⾃動化 • Design for failure 障害のための設計 • Evolutionary Design 進化的な設計 Microservices とは、世の中で「実際に」成功しているWebサービスアーキテクチャの特性に名前を付け たものです。概念先⾏の学術的なアーキテクチャとは違い、「モダンで成功するWebアーキテクチャ」と して、急速に認知されていきました。
- 11. To Dicide Issuesof a Monolithic Application 出典 : 「Microservices」 http://martinfowler.com/articles/microservices.html 変化に強いアプリケーション開発の⼿段 • モノリシックアプリケーションからの脱却 • モノリシックアプリケーションの課題 • 変更サイクルが⼀蓮托⽣ • モジュール構造が密結合で、影響範囲が拡⼤ • スケールするためのリソースも増⼤ • “Microservices” は、unix の設計思想を元 に書き直したもの。 1つのアプリケーションを、複数のサービ スに分解して、独⽴して稼働するようにリ プログラミング。
- 12. About ”Microservices” 出典 : 「「O'Reilly Japan - マイクロサービスアーキテクチャ」 https://www.oreilly.co.jp/books/9784873117607/ 協調して動作する、⼩規模で⾃律的なサービス § ⼩さく、かつ1つの役割に専念 § コードベースが⼤規模になっていくと、変更の必要な箇 所が分かりにくくなる。 § 特定のサービス境界をビジネス境界とをマッチさせ、特 定の機能コードの場所を明確にする § ⾃律性 § サービス間のすべての通信はネットワークを介して、 サービスの分離を強制し、密結合を阻害 § サービスは技術に依存しないAPIを公開し、技術制約に とらわれず、分離されたサービスを提供
- 13. § 技術特異性 § サービスごとに異なる技術を利 ⽤できる §回復性 § 障害時のサービス範囲を極⼩化 § スケーリング § 必要なサービスだけのスケーリ ング § デプロイの容易性 § 頻繁で迅速なデプロイの実現 § 組織⾯の⼀致 § コードベース毎の作業者の最⼩ 化と、サービス所有者と組織の ⼀致による責任の明確化 § 合成可能性 § サービス再利⽤機会の拡⼤ § 交換可能にするための最適化 § サービス書き換えの障壁・リス クの最⼩化 出典 : 「 「O'Reilly Japan - マイクロサービスアーキテクチャ」 https://www.oreilly.co.jp/books/9784873117607/ Microservices化することによる、7つの利点 The Advantage of ”Microservices”
- 14.
- 15. ”Microservices” Issues Microservices は、より複雑に、そして多くの課題を抱えることになります インフラの爆発 開発と運⽤の協業 コードの重複 テストの複雑さ ビジネスコストが削減できるとは限らない 分割によるインフラの増⼤ オーバーヘッドの増⼤ 複雑怪奇化するインフラ 開発者が運⽤を継続 DevOpsの実現が不可⽋ 似たようなサービスの重複 異⾔語での同アルゴリズム 改修の限界 正常サービスの判断基準 テストの責任範囲 そもそも、ビジネスの課題ではなく、 エンジニアの課題を解決するために、⾃然発⽣的に⽣まれたもの
- 16. 新しいサーバを数時間で準備できること “Microservices” Prerequisites 出典 : 「MicroservicePrerequisites」 http://martinfowler.com/bliki/MicroservicePrerequisites.html Miroservicesは、基盤とアプリ、テストが⾃動化されなければなりません Microservices を実現するために、開発者はアプリケーションの開発に注⼒できる環境が必要不可⽋です。 その為には、基盤もデプロイのプロセスも全て⾃動化されていることが条件になります。また、ソフト ウェアのリリース後、サービスが適切に稼働しているかどうかも、⾃動的に検出できなければなりません。 迅速なプロビジョニング ビジネスサービスでの問題を、すぐに検出できるかどうか基本的なモニタリング 信頼できるデプロイプロセスを実現できる環境が準備できること迅速なアプリデプロイ 継続的デリバリーの実現が、Microservices の実現の鍵
- 17. The Principle of“Microservices” 出典 : 「 「O'Reilly Japan - マイクロサービスアーキテクチャ」 https://www.oreilly.co.jp/books/9784873117607/ 適切に連携し⾃律して稼働する “Microservices” を作るための7つの原則 Microservices 小規模で自律的なサービス 高度な観測性 内部実装 詳細の隠蔽 独立したデプロイ 自動化の文化 ビジネス概念に 沿ったモデル化 障害の分離 すべての分散化
- 18. • ビジネス概念に沿ったモデル化 • システムが稼働するドメインをモデル化できる か •ビジネス境界を明確にできるか • ⾃動化の⽂化の採⽤ • ひとつのサービスを提供するが正常に動作して いるかどうかを保証することが難しい • 内部実装詳細の隠蔽 • 技術⾮依存のAPIを採⽤できるか • データベースを隠蔽・分離できるか • すべての分散化 • チームと組織を⼀致させ、責任を負わせられる か • 独⽴したデプロイ • マイクロサービスごとにデプロイできるか • 密結合を回避できるか • 障害の分離 • サービス下流の呼出に失敗が伴う前提で上流 サービスをコーディングできるか • サービスをリモート呼び出しできるか • ⾼度な観測性 • 各マイクロサービスの単体監視ではなく、提供 する全体サービスを監視・観測できるか 出典 : 「 「O'Reilly Japan - マイクロサービスアーキテクチャ」 https://www.oreilly.co.jp/books/9784873117607/ ビジネスとITを直結し、どれだけ標準化と⾃動化を進められるかが鍵です。 The Obstacles Implementing “Microservices”
- 19.
- 20.
- 21. Microservices on PublicCloud 増⼤するインフラへは、オンプレでの対策は不可能です Microservices を実現した⼤⼿企業は、(ほぼ)すべて Public Cloud (AWS) 上で実装しています。 増⼤する基盤への対応には、IaaS は必要不可⽋です。その上で、アプリケーションデプロイを標準化・ ⾃動化する、CD(継続的デリバリー) が重要になります。
- 22.
- 23. The Twelve-Factor Appでモダンなアプリ開発 Cloud 上での開発には、これまでのお約束は通じません 12-Factor APP ウォーターフォール アジャイル 集中開発 分散開発 ⼈海戦術 システム⾃動化 スケールアップ スケールアウト シェアード型 シェアードナッシング 仮想化 コンテナ
- 24. I. コードベース バージョン管理されている1つのコードベースと複数の デプロイ II. 依存関係 依存関係を明⽰的に宣⾔し分離する III.設定 設定を環境変数に格納する IV.バックエンドサービス バックエンドサービスをアタッチされたリソースとして 扱う V.ビルド、リリース、実⾏ ビルド、リリース、実⾏の3つのステージを厳密に分離 する VI.プロセス アプリケーションを1つもしくは複数のステートレスな プロセスとして実⾏する VII.ポートバインディング ポートバインディングを通してサービスを公開する VIII.並⾏性 プロセスモデルによってスケールアウトする IX.廃棄容易性 ⾼速な起動とグレースフルシャットダウンで堅牢性を最 ⼤化する X. 開発/本番⼀致 開発、ステージング、本番環境をできるだけ⼀致させた状態 を保つ XI.ログ ログをイベントストリームとして扱う XII.管理プロセス 管理タスクを1回限りのプロセスとして実⾏する 出典: 「The Twelve-Factor App」http://12factor.net/ Adam Wiggins : Heroku co-founder モダンなアプリケーション開発を実現するための 12 の⽅法論 The Twelve-Factor App (2012) の原理原則
- 25. Realize “Microservices” with“The Twelve-Factor App” “Microservices” の実現のために、12Factor App で解決できること ⾼度な観測性 内部実装詳細の隠蔽 独⽴したデプロイ ⾃動化の⽂化 ビジネス概念に沿ったモデル化 障害の分離 すべての分散化 コードベース 依存関係 設定 バックエンドサービス ビルド・リリース・実⾏ プロセス ポートバインディング 並⾏性 廃棄容易性 開発/本番⼀致 ログ 管理プロセス Microservices The Twelve-Factor App
- 26.
- 27. インフラエンジニア • ⾃動化された基盤の提供 アプリケーション開発者 • Microservices適⽤に適した、 原理・原則の採⽤ Microservicesを実現するために必要なこと アプリとインフラの共闘・共同・協⼒なしに実現不可能です INFRASTRUCTURE VERSIONING VIRTUALIZATION (Bootstrapping) IMAGE APPLICATION DEPLOYMENT (Command and Control) SERVER CONFIGURAION (Configuration) CONTINUOUSINTEGRATION SYSTEMTOOL 12-Factor APP
- 28.
- 29.