More Related Content Similar to マイクロサービスに至る歴史とこれから - XP祭り2021 (20) More from Yusuke Suzuki (20) マイクロサービスに至る歴史とこれから - XP祭り20213. アジェンダ
2
• 導⼊
• Agile
• Cloud
• DevOps
• Microservices
• これからのための技術
» Cloud Native
» Serverless
• これから
• まとめ
19. 参考
クラウド・コンピューティングの定義
18
オンデマンド・ セルフサービス
(On-demand self-service)
ユーザは、各サービスの提供者と直接やりとりすることなく、必要に応じ、⾃動的に、サーバーの稼
働時間やネットワークストレージのようなコンピューティング能⼒を⼀⽅的に設定できる。
幅広いネットワークアクセス
(Broad network 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 a Service(XaaS)
• 全てがサービスとして提供される
»仮想化技術によってシステム構成や運⽤作
業までサービス化できるようになった
»PaaSの進化として現れている
▸インスタンスの提供
▸ミドルウェア単体の提供︓データベースなど
▸Webアプリケーションの実⾏環境
ü コンテナランタイム
ü サーバレス
19
ハードウェア
ネットワーク
仮想化OS
OS
ミドルウェア
コード・設定
データ
IaaS
PaaS
SaaS
ユーザ⾃⾝の管理範囲
21. Cloud
Infrastructure as Code
• 仮想化されたインフラやプラットフォームがコードから操
作ができる
»つまり、「インフラを構成する」という作業が⾃動化できる
»Terraform、Ansible、AWS CloudFormation、Pulumi....
• ⾮機能要件がコーディングで表現できる
»これまでは機能要件しかコーディングできなかった
»サービス(機能+⾮機能)がコード化された世界
20
24. DevOps
DevOpsのはじまり
• 2009年︓DevOps
»Agile 2008︓Agile Infrastructure & 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 Per Day”のテーマ
• そもそも開発と運⽤は仲が悪かった
»「新機能追加」と「安定稼働」は相反する
• でも、頻繁に機能追加することが前提になった
»リリース回数の圧倒的な増加
»システムの停⽌=価値の棄損
• ツールを活⽤し、⽂化を変えていく
»ツール︓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ʼt Want 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, DevOps and 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
30. Microservices
マイクロサービスアーキテクチャ
• 2014年︓「Microservceis」 by James 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
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-Factor App (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
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 Native Trail 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
65. Serverless
Serverlessのはじまり
• Serverless FaaS
»2015年のAWS API Gateway+Lambda(2014)
▸REST API経由でLambdaを起動することができる
»Serverless FaaSとは何か︖
▸イベントで起動する
▸短時間実⾏される、コードから起動し
▸スケーリングするまではフルマネージ
»代表的なサービス
▸AWS Lambda、Azure Functions、GCP Cloud Functions
64
Serverless Architectures
https://martinfowler.com/articles/serverless.html
70. これから
Kubernetesの状況整理
• Cloud Native、K8s Serverlessは未成熟な段階
»巨⼤サービスには魅⼒的だが、中規模にはオーバーキル
»標準化を重視しているため、進化はちょっと遅め
▸AWS対抗の雰囲気は強い。中⼼はGoogle、Microsoft、Red Hat(IBM)
»⼗分に実⽤的になるには数年かかるはず
• 現時点ではコンテナライズやCI/CDに取り組んでおく
»⾮k8sなコンテナサーバレスは実⽤性が⾼い
69