Downloaded 54 times
Uploaded byYusuke Suzuki
マイクロサービスに至る歴史とこれから - XP祭り2021
2021年9月18日に開催されたXP祭り2021での講演「マイクロサービスに至る歴史とこれから」の講演資料です。 https://xpjug.connpass.com/event/218516/
More Related Content
Similar to マイクロサービスに至る歴史とこれから - XP祭り2021
マイクロサービスに至る歴史とこれから - XP祭り2021
- 1.
- 2. ⾃⼰紹介 鈴⽊雄介 • Graat（グラーツ） » グロース・アーキテクチャ＆チームス株式会社 »代表取締役 社⻑ • アイムデジタルラボ（三越伊勢丹グループ) » 取締役 • ⽇本Javaユーザーグループ » CCC運営委員⻑/サブリーダー • その他 » @yusuke_arclamp » http://arclamp.hatenablog.com/ 1
- 3. アジェンダ 2 • 導⼊ • Agile •Cloud • DevOps • Microservices • これからのための技術 » Cloud Native » Serverless • これから • まとめ
- 4.
- 5.
- 6. 導⼊ その時の課題を、新しい技術が解決する • テクノロジーやテクニックが改善サイクルを早くする »テクノロジー︓技術そのもの »テクニック ︓⼈による技術の活かし⽅ 5 2001年Agile 202X年 これから 2009年 DevOps 2006年 Cloud 2015年 Serverless 2015年 Cloud Native 2014年 Microservices テクノロジー テクニック
- 7. 導⼊ そろそろ、新しい⾔葉が出てきそう︖ • 新しいテクノロジーを⼟台にテクニックが成⻑する • CloudNativeやServerlessを⼟台にしたテクニックとは︖ 6 2001年 Agile 2023年 これから 2009年 DevOps 2006年 Cloud 2015年 Serverless 2015年 Cloud Native 2014年 Microservices 8年 8年︖ 8年
- 8.
- 9.
- 10. Agile ウォーターフォール • 初期に全体計画を⽴案し、それに沿って実⾏していく »計画︓ゴールを定義し、それを実現する計画を⽴案 »実⾏︓その計画に従って実⾏ »計測︓フェーズごとに計画とのズレを把握 »調整︓計画通りになるように調整 ▸調整要素︓リソース →スケジュール→スコープ 9 基本設計 実装 テスト 要件定義 計 画 受 ⼊ 成果物 ⽂書 ⽂書 ⽂書 ⽂書 ⽂書 要件
- 11.
- 12.
- 13. アジャイルの仕組み • 短期の再計画＆実⾏を通じて調整し続ける »計画︓⼀定の期間1＝作業量を定め、その範囲でゴールを計画 »実⾏︓その⼩さな計画に従って実⾏。実⾏中の調整は禁⽌ »計測︓ゴール後に完成品を⾒て判断する »調整︓次の計画をもって調整とする ▸調整要素︓スコープのみ 成果物 成果物 要件 要件要件 成果物 Agile 12 実装 計 画 受 ⼊ 設計 テスト 実装 計 画 受 ⼊ 設計 テスト 実装 計 画 受 ⼊ 設計 テスト 1 ⼀定の期間とは1週間〜3ヶ⽉程度、チームメンバーは安定させる
- 14. Agile アジャイルは電⾞型 • 定期的に電⾞を運⾏する »①その時点で並んでいる⼈ から定員まで乗⾞ »②電⾞が発⾞したら、到着 するまでは乗降禁⽌ »③次の電⾞が来るまで並び 順は⾃由に変えていい »④到着した⼈と話して、成 果を確認する 13 b a 出発ホーム到着ホーム d c b a 出発ホーム 到着ホーム d c b a 出発ホーム 到着ホーム f e 出発ホーム 到着ホーム d c b a d c 定員︓2名 定員︓2名 ① ③ ④ f e 定員︓2名 ②
- 15.
- 16.
- 17.
- 18.
- 19. 参考 クラウド・コンピューティングの定義 18 オンデマンド・ セルフサービス (On-demand self-service) ユーザは、各サービスの提供者と直接やりとりすることなく、必要に応じ、⾃動的に、サーバーの稼 働時間やネットワークストレージのようなコンピューティング能⼒を⼀⽅的に設定できる。 幅広いネットワークアクセス (Broadnetwork access) コンピューティング能⼒は、ネットワークを通じて利⽤可能で、標準的な仕組みで接続可能であり、 そのことにより、様々なシンおよびシッククライアントプラットフォーム（例えばモバイルフォン、 タブレット、ラップトップ コンピュータ、ワークステーション）からの利⽤を可能とする。 リソースの共⽤ (Resource pooling) サービスの提供者のコンピューティングリソースは集積され、複数のユーザにマルチテナントモデル を利⽤して提供される。様々な物理的・仮想的リソースは、ユーザの需要に応じてダイナミックに割 り当てられたり 再割り当てされたりする。物理的な所在場所に制約されないという考え⽅で、ユーザ は⼀般的に、提供されるリソースの正確な所在地を知ったりコントロールしたりできないが、場合に よってはより抽象的なレベル （例︓国、州、データセンタ）で特定可能である。リソースの例として は、ストレージ、処理能⼒、メモリ、およびネットワーク帯域が挙げられる。 スピーディな拡張性 (Rapid elasticity) コンピューティング能⼒は、伸縮⾃在に、場合によっては⾃動で割当ておよび提供が可能で、需要に 応じて即座にスケールアウト／スケールインできる。ユーザにとっては、多くの場合、割当てのため に利⽤可能な能⼒は無尽蔵で、いつでもどんな量でも調達可能のように⾒える。 サービスが 計測可能であること (Measured Service) クラウドシステムは、計測能⼒1を利⽤して、サービスの種類（ストレージ、処理能⼒、帯域、実利⽤ 中のユーザアカウント数）に適した管理レベルでリソースの利⽤をコントロールし最適化する。リ ソースの利⽤状況はモニタされ、コントロールされ、報告される。それにより、サービスの利⽤結果 がユーザにもサービス提供者にも明⽰できる。 1. 通常、従量課⾦(pay-per-use)または従量請求 (charge-per-use)ベースで計算される。 The NIST Definition of Cloud Computing https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf ⽇本語訳 https://www.ipa.go.jp/files/000025366.pdf
- 20. Cloud X as aService（XaaS） • 全てがサービスとして提供される »仮想化技術によってシステム構成や運⽤作 業までサービス化できるようになった »PaaSの進化として現れている ▸インスタンスの提供 ▸ミドルウェア単体の提供︓データベースなど ▸Webアプリケーションの実⾏環境 ü コンテナランタイム ü サーバレス 19 ハードウェア ネットワーク 仮想化OS OS ミドルウェア コード・設定 データ IaaS PaaS SaaS ユーザ⾃⾝の管理範囲
- 21. Cloud Infrastructure as Code •仮想化されたインフラやプラットフォームがコードから操 作ができる »つまり、「インフラを構成する」という作業が⾃動化できる »Terraform、Ansible、AWS CloudFormation、Pulumi.... • ⾮機能要件がコーディングで表現できる »これまでは機能要件しかコーディングできなかった »サービス（機能＋⾮機能）がコード化された世界 20
- 22.
- 23.
- 24. DevOps DevOpsのはじまり • 2009年︓DevOps »Agile 2008︓AgileInfrastructure & Operations ▸政府系データセンターの移⾏にスクラムを導⼊した事例発表 ▸インフラ/運⽤系にアジャイル⽂化を導⼊しようとする機運 »Velocity 2009︓10+ Deploys Per Day ▸Flickrにおける開発と運⽤の協業について »Devopsdays Ghent 2009 ▸ここから「DevOps」が⽣まれる 23 参考︓「The (Short) History of DevOps」（Damon Edwards） https://www.youtube.com/watch?v=o7-IuYS0iSE
- 25. DevOps “10+ Deploys PerDay”のテーマ • そもそも開発と運⽤は仲が悪かった »「新機能追加」と「安定稼働」は相反する • でも、頻繁に機能追加することが前提になった »リリース回数の圧倒的な増加 »システムの停⽌＝価値の棄損 • ツールを活⽤し、⽂化を変えていく »ツール︓IaC、CI/CD、メトリクス、ChatBot »⽂化︓リスペクト、信頼、⼼理的安全性、 24 ※2009年⽤語 ツール︓Automated Infrastructure, Shared version control, One step build and deploy, Feature flags, Shared Metrics, IRC and IM robots ⽂化︓Respect, Trust, Healthy attitude about failure, Avoiding Blame
- 26. DevOps NoOpsの登場 • 2011年︓NoOps »「I DonʼtWant DevOps. I Want NoOps.」 ▸NoOps は、アプリケーション開発者がオペレーションプロフェッショナル と話す必要がないことを意味します。 ▸Ops は <略> 責任を持ってアプリケーションを迅速に展開するために必要 なツールを開発者に提供できます。 »「NoOps」という⾔葉が強かったため炎上 ▸運⽤はいらない︖運⽤担当者はいらない︖ 25 I Donʼt Want DevOps. I Want NoOps. https://www.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/
- 27. DevOps あるいはPaaS • 2012年︓Ops, DevOpsand PaaS (NoOps) at Netflix »Dev組織にいる数名のDevOpsエンジニアが⾃動化を推進 »NoOpsでデプロイされ、何かあれば数百名の開発者に直接通知 »開発者がやりたいことはツールを使ってセルフサービス »Ops組織はなく、開発者が運⽤で何かしたいと思った時、Opsの ⼈と話す必要はない ▸運⽤センター（NOC）はないが、SREチームはいる »これをDevOpsの進化版としてPaaS (NoOps)と呼んでいる 26 Ops, DevOps and PaaS (NoOps) at Netflix http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html
- 28. DevOps DevOps/NoOpsがもたらした概念 • システムを継続的に変更し、動かし続ける »開発者は「作る」から「作って動かす」まで担当する ▸開発者がインフラ構築、リリース作業、障害通知、復旧作業をやる ü セキュリティとか品質も ▸すべてツール化＆⾃動化され、セルフサービス化される 27 成果物 アプリ DevOps 成果物 Dev SRE Ops ﾂｰﾙ インフラ アプリ インフラ DevOpsエンジニア
- 29.
- 30. Microservices マイクロサービスアーキテクチャ • 2014年︓「Microservceis」 byJames Lewis »2011年︓先端的なウェブサービス企業が似たようなアーキテクチ ャスタイルを取っていることが議論に »Microservices - Java, the Unix Way ▸33rd Degree 2012 • 起きていた事象に名前を付けたもの »コンセプトが先にあったわけではない 29 Microservceis http://martinfowler.com/articles/microservices.html Microservices - Java, the Unix Way http://2012.33degree.org/talk/show/67
- 31. Microservices マイクロサービスの特徴 • サービスによるコンポーネント化 • ビジネス視点でのチーム分割 •プロジェクトではなくプロダクト • スマートなエンドポイントと単純なパイプ（API連携） • 分散ガバナンス（脱標準化） • 分散データ管理 • インフラの⾃動化 • 障害のための設計 • 進化的設計 30 https://martinfowler.com/articles/microservices.html ←DevOpsな部分 ←アジャイルな部分
- 32.
- 33.
- 34.
- 35. どうサービスを設計するか︖ Domain-Driven Design（2003） • サービス分割の設計指針として有効 »システム構造は、対象ドメインの概念と近づけなさい ▸そうすれは業務の変更についていきやすくなるから »ドメインのことはビジネス側の有識者に聞きなさい ▸ビジネスの成⻑とともに継続的に進化させていきなさい •ドメイン︖ »その業務を成り⽴たせるための作業、⼿順、規則、情報など »ビジネスの仕組みというよりは、それを業務の仕組み 34
- 36.
- 37.
- 38. どうサービスを実装するか︖ Twelve-Factor App（2011） • 疎結合を実現するための実装 »コーディング時、ビルド＆デプロイ時、実⾏時、運⽤時などにお いて他者/環境に対する依存度を下げることで取り回しを良くして いくための⼯夫 »BeyondThe Twelve-Factor App（2016） ▸クラウド前提で変更と追加（3つ） ▸特に認証認可（シングルサインオン）は⾮常に重要 37
- 39. Twelve-Factor App（2011） • I.コードベース » バージョン管理されている1つのコードベ ースと複数のデプロイ • II. 依存関係 » 依存関係を明⽰的に宣⾔し分離する • III. 設定 » 設定を環境変数に格納する • IV. バックエンドサービス » バックエンドサービスをアタッチされた リソースとして扱う • V. ビルド、リリース、実⾏ » ビルド、リリース、実⾏の3つのステージ を厳密に分離する • VI. プロセス » アプリケーションを1つもしくは複数のス テートレスなプロセスとして実⾏する 38 • VII. ポートバインディング » ポートバインディングを通してサービス を公開する • VIII. 並⾏性 » プロセスモデルによってスケールアウト する • IX. 廃棄容易性 » ⾼速な起動とグレースフルシャットダウ ンで堅牢性を最⼤化する • X. 開発/本番⼀致 » 開発、ステージング、本番環境をできる だけ⼀致させた状態を保つ • XI. ログ » ログをイベントストリームとして扱う • XII. 管理プロセス » 管理タスクを1回限りのプロセスとして実 ⾏する https://12factor.net/ja/
- 40. Beyond The Twelve-FactorApp （2016） • One codebase, one application • API first • Dependency management • Design, build, release, and run • Configuration, credentials, and code • Logs • Disposability • Backing services 39 • Environment parity • Administrative processes • Port binding • Stateless processes • Concurrency • Telemetry • Authentication and authorization https://tanzu.vmware.com/content/blog/beyond-the-twelve-factor-app
- 41. どうサービスを実装するか︖ Beyond Beyond TheTwelve-Factor App • さらなる進化 »Monorepo（2017） »Ahead-Of-Time (AOT) コンパイル »オブザーバビリティ »サービスメッシュ • いずれにせよコンテナライズは重要 40
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49. Cloud Native Cloud Nativeとは •CNCF(2015)による定義（2018） 48 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/main/DEFINITION.md クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドな どの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実⾏する ための能⼒を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイ クロサービス、イミュータブルインフラストラクチャ、および宣⾔型APIがあります。 これらの⼿法により、回復性、管理⼒、および可観測性のある疎結合システムが実現します。 これら を堅牢な⾃動化と組み合わせることで、エンジニアはインパクトのある変更を最⼩限の労⼒で頻繁か つ予測どおりに⾏うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中⽴プロジェクトのエコシステ ムを育成・維持して、このパラダイムの採⽤を促進したいと考えてます。 私たちは最先端のパターン を⺠主化し、これらのイノベーションを誰もが利⽤できるようにします。 Cloud Native Computing Foundation https://www.cncf.io/
- 50. Cloud Native Cloud NativeTrail Map • Cloud Nativeへの道のり 1. コンテナ化 2. CI/CD 3. オーケストレーション 4. オブザーバビリティ 5. サービスメッシュ 6. セキュリティ 7. 分散データベース＆ストレージ 8. ストリーミング 9. コンテナレジストリ＆ランタイム 10.ソフトウェアディストリビューション 49 Cloud Native Trail Map https://raw.githubusercontent.com/cncf/trailmap/master/CNCF_TrailMap_latest.pdf
- 51.
- 52.
- 53.
- 54.
- 55. エコシステムの発展 • KubernetesだけではPaaSとしては機能不⾜ »k8sは「コンテナを動かす」だけ • 周辺プロダクト群が増えて続けている オーケストレーション 54 Thecloud native landscape Serverless landscape Continuous Delivery landscape Kubernetes
- 56.
- 57.
- 58.
- 59. サービスメッシュ Istio • 現時点でのデファクトスタンダード »2017年にGoogle、IBM、LyftがOSS化 • Istioの仕組み »データプレーン ▸サイドカーとしてデプロイし、全ての通信 をインターセプトして制御 ▸EnvyProxyを利⽤ »コントロールプレーン ▸設定の配布とログの収集 58
- 60.
- 61.
- 62. ストリーミング CQRSとEvent-Sourcing • データを疎結合に共有する »CQRS(Command QueryResponsibility Segregation) ▸更新と表⽰のモデルを分離する ▸＝元システムと先システムは異なるモデルでよい »Event-Sourcing ▸データに対する操作をイベントとして記録 ▸＝欲しい操作だけ、任意のタイミングで反映 61 元 先 変更 ① 変更 ① 最新の データ
- 63.
- 64.
- 65. Serverless Serverlessのはじまり • Serverless FaaS »2015年のAWSAPI Gateway＋Lambda(2014) ▸REST API経由でLambdaを起動することができる »Serverless FaaSとは何か︖ ▸イベントで起動する ▸短時間実⾏される、コードから起動し ▸スケーリングするまではフルマネージ »代表的なサービス ▸AWS Lambda、Azure Functions、GCP Cloud Functions 64 Serverless Architectures https://martinfowler.com/articles/serverless.html
- 66. Serverless コンテナを前提としたServerless • Container Serverless »コンテナを前提としたサーバレス環境 ▸⻑時間稼働、複雑な業務ロジックなど広いユースケースに対応可能 ▸ただし、スケーラビリティはFaaSに劣る •Kubernetes Serverless »k8sを前提としたContainer Serverless ▸仕様︓Knative、KEDA ▸製品︓GCP Cloud Run、AWS App Runner »ビルドが統合され、Gitから起動まで含む 65 Serverless Architectures https://martinfowler.com/articles/serverless.html
- 67.
- 68.
- 69. これから 2023年ごろに必要なこと • Cloud NativeやServerlessが基礎技術 •その上で、どんなテクニックが重要になるか︖ 68 2001年 Agile 2023年 これから 2009年 DevOps 2006年 Cloud 2015年 Serverless 2015年 Cloud Native 2014年 Microservices 8年 8年︖ 8年
- 70. これから Kubernetesの状況整理 • Cloud Native、K8sServerlessは未成熟な段階 »巨⼤サービスには魅⼒的だが、中規模にはオーバーキル »標準化を重視しているため、進化はちょっと遅め ▸AWS対抗の雰囲気は強い。中⼼はGoogle、Microsoft、Red Hat(IBM) »⼗分に実⽤的になるには数年かかるはず • 現時点ではコンテナライズやCI/CDに取り組んでおく »⾮k8sなコンテナサーバレスは実⽤性が⾼い 69
- 71.
- 72. これから イベント管理の技術は未成熟な状態 • Istioとの統合 »試⾏錯誤はされている状態 • データは共有しないが、スキーマは共有すべき »受け取る側はスキーマのバージョンに関する情報が重要 »1つの⽅向性︓ConfluentSchema Registry ▸Kafka向けのスキーマ管理ツール ü スキーマ定義、およびシリアライズ・デシリアライズ処理 71 Schema Registry Overview https://docs.confluent.io/platform/current/schema-registry/ The benefits of integrating Apache Kafka with Istio on Kubernetes – Istio Con 2021 https://events.istio.io/istiocon-2021/sessions/the-benefits-of-integrating-apache-kafka-with-istio-on-kubernetes/
- 73.
- 74.
- 75. まとめ そろそろ、新しい⾔葉が出てきそう︖ • イベント駆動あたりな気がする »コンテナのよる分割とサービスメッシュによる統合 »k8sサーバレスによるNoOpsの実現 74 2001年 Agile 2023年これから 2009年 DevOps 2006年 Cloud 2015年 Serverless 2015年 Cloud Native 2014年 Microservices 8年 8年︖ 8年
- 76.