アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
•
2 likes•1,769 views
2023/11/11に開催されたJJUG CCC 2023 Fallでの講演「アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ」の資料です
Recommended
More Related Content
What's hot
What's hot (20)
Similar to アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
Similar to アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ (20)
More from Yusuke Suzuki
More from Yusuke Suzuki (20)
Recently uploaded
Recently uploaded (10)
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
- 2. ⾃⼰紹介 鈴⽊雄介 • ⽇本Javaユーザーグループ »CCC運営委員⻑/サブリーダー • SNS »@yusuke_arclamp »http://arclamp.hatenablog.com/ • Graat（グラーツ） » グロース・アーキテクチャ＆チームス株式会社 » 代表取締役 社⻑ • アイムデジタルラボ » 三越伊勢丹グループ » 取締役 1
- 3. アジェンダ 2 • はじめに • Agile • Cloud • DevOps • Microservices • Cloud Native • Platform • まとめ
- 4. はじめに
- 8. Agile
- 11. Agile Scrum • 電⾞にたとえて理解する »出発ホームから定期的に出発 »①出発ホームには、乗客が⼀列に並んで待 っている »②電⾞が来たら、定員まで乗せて出発 »③出発した電⾞は乗り降り禁⽌ »④次の電⾞が来るまで、出発ホームの乗客 は並び替え⾃由 10 出発ホーム d c b a 出発ホーム d c b a 出発ホーム d c b a 定員：2名 ① f e 定員：2名 ② ③ ④
- 12. 補⾜ 対応表 11 電⾞の説明 スクラム⽤語 説明 電⾞の運⾏ スプリント 繰り返し続ける作業期間。1ヶ⽉以内の決まった ⻑さ 出発ホーム プロダクトバックログ これからやりたいことを優先順に並べたリスト の乗客 プロダクトバックログアイテム そのリストの1⾏ 電⾞に乗る スプリントプランニング スプリントの開始時に、このスプリントでやる ことを決めるイベント 電⾞ スプリントバックログ このスプリントで実施するタスクのリスト。 スプリントプランニングでプロダクトバックロ グからアイテムを移動させてくる の乗客 スプリントバックログアイテム そのリストの1⾏
- 15. Agile 課題：モノリス • 調整が素早さを削ぐ »影響調査 »リグレッションテスト »リリース調整 14 Haystack Rock at 8:30am by Brenda Dobbs https://www.flickr.com/photos/bugldy99/45583127204/ 機能 A 機能 B 機能 C
- 16. Cloud
- 17. Cloud 巨⼤な仮想化インフラを「利⽤」する • 2006年：Google社元CEO エリック・シュミットが名付け »『すべてが雲の中のどこかにあればいい』 • The NIST Definition of Cloud Computing »必要な時にセルフサービスで利⽤できる »ネットワークを通じて利⽤できる »リソースは共有され、必要な分が割り当てられる »いつでも必要なだけの量を調達することができる »利⽤状況に応じて課⾦される 16
- 18. 参考 クラウド・コンピューティングの定義 17 オンデマンド・ セルフサービス (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
- 19. Cloud Cloudがもたらしたもの • IaC（Infrastructure as Code） »インフラ構成をコードで表現できる »アプリケーションだけではなく、稼働環境を含めてサービスそのも のがコードになる • PaaS（Platform as a Service） »インフラだけではなく、ミドルウェアや実⾏環境もサービス ▸スケールだけではなく、機能性もターンキーで利⽤できる ü クラスタ、⾃動デプロイ 18
- 20. DevOps
- 21. DevOps 開発♡運⽤ • 「Devopsdays Ghent 2009」の 開催をきっかけに定着 • 開発と運⽤は仲が悪かった »最⼤の運⽤リスクは変化の受⼊ »でも、変化に素早く対応し続けられ るようにならないといけない 20
- 22. DevOps DevOpsがもたらたしたもの • 運⽤をセルフサービスにする »素早く対応するに部署間のやり取りは無駄 »開発がツールを使って運⽤作業を実施すればいい ▸インフラ構築、ビルド＆デプロイ、スケール変更、監視＆予測、障害復旧... 21 成果物 アプリ Dev Ops 成果物 Dev SRE Ops ﾂｰﾙ インフラ アプリ インフラ DevOpsエンジニア
- 23. Microservices
- 24. Microservices マイクロサービスアーキテクチャ • 2014年：「Microservceis」 by James Lewis • モノリスを解決する »機能間での調整を減らせば、全体として変化に対応しやすくなる ▸影響調査、リグレッションテスト、リリース調整 23 機能 A 機能 B 機能 C 機能 A 機能 B 機能 C
- 26. Microservices 疎結合にする≒変更の伝播を制限する • 機能的にも⾮機能的にも伝播させない »WebAPI（同期/⾮同期）を通じて連携する »データを共有しない »サーバもデータベースも共有しない 25 ｻｰﾋﾞｽA ｻｰﾋﾞｽB ｻｰﾋﾞｽC DB A DB B DB C
- 27. Microservices リリース調整を排除する • 無停⽌リリース（ブルーグリーンデプロイメント） • 連携先サービスがダウンしても稼働できるようにする »サーキットブレーカー 26 ｻｰﾋﾞｽA ｻｰﾋﾞｽB v1.0 ｻｰﾋﾞｽB v1.1 ｻｰﾋﾞｽA ｻｰﾋﾞｽB 障害 障害を伝播 させない
- 29. 補⾜ Microservicesは万能ではない • GitHubの元CTO Jason Warne⽒ »この10年、アーキテクチャ設計における 最⼤の間違いは「すべてをマイクロサー ビスにしようとすること」だ »モノリスからマイクロサービスは以下の ように連続的だ »モノリス > アプリ > サービス > マイク ロサービス 28 https://twitter.com/jasoncwarner/status/1592227285024636928
- 30. 補⾜ マイクロサービス化に取り組む • Netflixは2008年からAWS化し、2016年1⽉に移⾏完了 »Netflixのクラウド移⾏が完了 - About Netflix ▸最も簡単な移⾏⽅法はリフトだが、問題や制約もついてくる ▸クラウドネイティブに技術を⾒直し、モノリシックアプリケーションをマイ クロサービスに移⾏した ▸最後になったのは課⾦や顧客のデータ管理の機能 • 「⼀括再構築でマイクロサービスに取り組む」のは危険 »段階的にマイクロサービス化していく 29
- 31. Cloud Native
- 32. Cloud Native Cloud Native • 2015年：Cloud Native Computing Foundation設⽴ »Kubernetes 1.0のリリースと同時に設⽴ »Cloud Native Definition v1.0 ▸クラウドネイティブ技術＜中略＞の代表例に、コンテナ、サービスメッシュ 、マイクロサービス、イミュータブルインフラストラクチャ、および宣⾔型 API ▸回復性、管理⼒、および可観測性のある疎結合システムが実現 ▸堅牢な⾃動化と組み合わせることで、エンジニアはインパクトのある変更を 最⼩限の労⼒で頻繁かつ予測どおりに⾏う 31 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/main/DEFINITION.md Cloud Native Computing Foundation https://www.cncf.io/
- 33. Cloud Native Cloud Native Trail Map » コンテナ化 » CI/CD » オーケストレーション&アプリ定義 » オブザーバビリティ » サービスメッシュ » ポリシー、セキュリティ » 分散データベース＆ストレージ » ストリーミング＆メッセージング » コンテナレジストリ＆ランタイム » ソフトウェアディストリビューシ ョン 32 Cloud Native Trail Map https://raw.githubusercontent.com/cncf/trailmap/master/CNCF_TrailMap_latest.pdf
- 34. Cloud Native Cloud Native Landscape • 1000近い関連製品 » プロビジョニング » ランタイム » オーケストレーション » サーバレス » オブザーバビリティ » プラットフォーム » ... 33 Kubernetes
- 35. Cloud Native 現在進⾏形で様々な技術が成⻑中 • コンテナ+サーバレス »コンテナを稼働させるためのサーバレス環境 ▸Gitレポジトリからデプロイ＆スケールまで。常駐型もバッチ型も対応 • サービスメッシュ »サービス間連携を管理するための仕組み ▸ルーティング、セキュリティ＆ポリシー、監視、レジリエンスなど 34
- 36. Platform
- 37. Platform プラットフォームとは？ • 2018年： Internal Developer Platform (IDP) 36 内部開発者プラットフォーム (IDP) は、運⽤チームによって構成され、開発 者によって使⽤されます。運⽤チームは、どのリソースをどの環境で、また はどのような要求で起動するかを指定します。また、アプリケーション構成 のベースライン テンプレートを設定し、アクセス許可を管理します。これに より、環境やリソースのスピンアップなどの定期的なタスクを⾃動化し、標 準を適⽤することでセットアップの保守が容易になります。開発チームは、 構成の変更、デプロイ、スピンによって⾃律性を獲得します What is an Internal Developer Platform (IDP)? | Internal Developer Platform https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/
- 38. Platform DevOpsやMSAのアンチパターン • チーム/システムが個別に取り組む 37 チームA チームB チームC DevOps MSA OPS
- 39. Platform Platformを整備して提供する • Internal Developer Platform 38 チームA チームB チームC Platform OPS DevOps MSA
- 40. Platform Platformの中⾝は？ 39 デジタルプラットフォームは、セルフサービスのAPI、 ツール、サービス、知識、サポートの基盤であり、魅⼒的 な社内製品として配置されています。⾃律型デリバリー チームは、このプラットフォームを利⽤して、調整を減ら しながら、より速いペースで製品機能を提供することがで きます。 What I Talk About When I Talk About Platforms (martinfowler.com) https://martinfowler.com/articles/talk-about-platforms.html
- 41. Platform IDPを構築する • 認証認可 »IAM、ユーザー管理、権限管理... • アプリケーション・インフラ構成管理 »コアネットワーク、CI、IaC... »サーバ、データベース、シークレット... • パイプライン »Git、CI、コンテナリポジトリ、無停⽌デプロイ... • ガイドラインやサポート体制 40
- 42. Platform Platform Engineering • Platformを構築することに取り組む 41 プラットフォームエンジニアリングは、クラウドネイティブ時代 のソフトウェアエンジニアリング組織のセルフサービス機能を可 能にするツールチェーンとワークフローを設計および構築する分 野です。プラットフォームエンジニアは、アプリケーションのラ イフサイクル全体の運⽤上の必需品をカバーする「内部開発者プ ラットフォーム」と呼ばれる統合製品を提供します。 What is platform engineering? https://platformengineering.org/blog/what-is-platform-engineering
- 43. まとめ
- 44. まとめ アーキテクチャの進化を学ぶ • 年表 »2001 Agile »2006 Cloud »2009 DevOps »2014 Microservices »2015 Cloud Native/Serverless »2018 Platform • 我々は、20年以上取り組んできている 43
- 45. まとめ 進化の本質 • 全ては「変化に素早く対応し続ける」ために »モジュール化における⾼凝集&疎結合は、古来からの基本原則 ▸コード → アプリ → サービス • どんな取り組みにも副作⽤があり、主に⼈間の認知の問題 »技術の進化が、効率的に副作⽤を抑えられるようにしてきた »ただし、理解せずに使えば、簡単に限界を踏み抜く 44