Download as PDF, PPTX
Uploaded byYusuke Suzuki
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
2023/11/11に開催されたJJUG CCC 2023 Fallでの講演「アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ」の資料です
More Related Content
Similar to アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
- 1.
- 2. ⾃⼰紹介 鈴⽊雄介 • ⽇本Javaユーザーグループ »CCC運営委員⻑/サブリーダー • SNS »@yusuke_arclamp »http://arclamp.hatenablog.com/ •Graat（グラーツ） » グロース・アーキテクチャ＆チームス株式会社 » 代表取締役 社⻑ • アイムデジタルラボ » 三越伊勢丹グループ » 取締役 1
- 3. アジェンダ 2 • はじめに • Agile •Cloud • DevOps • Microservices • Cloud Native • Platform • まとめ
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. Agile Scrum • 電⾞にたとえて理解する »出発ホームから定期的に出発 »①出発ホームには、乗客が⼀列に並んで待 っている »②電⾞が来たら、定員まで乗せて出発 »③出発した電⾞は乗り降り禁⽌ »④次の電⾞が来るまで、出発ホームの乗客 は並び替え⾃由 10 出発ホーム d cb a 出発ホーム d c b a 出発ホーム d c b a 定員：2名 ① f e 定員：2名 ② ③ ④
- 12. 補⾜ 対応表 11 電⾞の説明 スクラム⽤語 説明 電⾞の運⾏スプリント 繰り返し続ける作業期間。1ヶ⽉以内の決まった ⻑さ 出発ホーム プロダクトバックログ これからやりたいことを優先順に並べたリスト の乗客 プロダクトバックログアイテム そのリストの1⾏ 電⾞に乗る スプリントプランニング スプリントの開始時に、このスプリントでやる ことを決めるイベント 電⾞ スプリントバックログ このスプリントで実施するタスクのリスト。 スプリントプランニングでプロダクトバックロ グからアイテムを移動させてくる の乗客 スプリントバックログアイテム そのリストの1⾏
- 13.
- 14.
- 15. Agile 課題：モノリス • 調整が素早さを削ぐ »影響調査 »リグレッションテスト »リリース調整 14 Haystack Rockat 8:30am by Brenda Dobbs https://www.flickr.com/photos/bugldy99/45583127204/ 機能 A 機能 B 機能 C
- 16.
- 17. Cloud 巨⼤な仮想化インフラを「利⽤」する • 2006年：Google社元CEO エリック・シュミットが名付け »『すべてが雲の中のどこかにあればいい』 •The NIST Definition of Cloud Computing »必要な時にセルフサービスで利⽤できる »ネットワークを通じて利⽤できる »リソースは共有され、必要な分が割り当てられる »いつでも必要なだけの量を調達することができる »利⽤状況に応じて課⾦される 16
- 18. 参考 クラウド・コンピューティングの定義 17 オンデマンド・ セルフサービス (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
- 19. Cloud Cloudがもたらしたもの • IaC（Infrastructure asCode） »インフラ構成をコードで表現できる »アプリケーションだけではなく、稼働環境を含めてサービスそのも のがコードになる • PaaS（Platform as a Service） »インフラだけではなく、ミドルウェアや実⾏環境もサービス ▸スケールだけではなく、機能性もターンキーで利⽤できる ü クラスタ、⾃動デプロイ 18
- 20.
- 21. DevOps 開発♡運⽤ • 「Devopsdays Ghent2009」の 開催をきっかけに定着 • 開発と運⽤は仲が悪かった »最⼤の運⽤リスクは変化の受⼊ »でも、変化に素早く対応し続けられ るようにならないといけない 20
- 22. DevOps DevOpsがもたらたしたもの • 運⽤をセルフサービスにする »素早く対応するに部署間のやり取りは無駄 »開発がツールを使って運⽤作業を実施すればいい ▸インフラ構築、ビルド＆デプロイ、スケール変更、監視＆予測、障害復旧... 21 成果物 アプリ Dev Ops成果物 Dev SRE Ops ﾂｰﾙ インフラ アプリ インフラ DevOpsエンジニア
- 23.
- 24. Microservices マイクロサービスアーキテクチャ • 2014年：「Microservceis」 byJames Lewis • モノリスを解決する »機能間での調整を減らせば、全体として変化に対応しやすくなる ▸影響調査、リグレッションテスト、リリース調整 23 機能 A 機能 B 機能 C 機能 A 機能 B 機能 C
- 25.
- 26.
- 27.
- 28.
- 29. 補⾜ Microservicesは万能ではない • GitHubの元CTO JasonWarne⽒ »この10年、アーキテクチャ設計における 最⼤の間違いは「すべてをマイクロサー ビスにしようとすること」だ »モノリスからマイクロサービスは以下の ように連続的だ »モノリス > アプリ > サービス > マイク ロサービス 28 https://twitter.com/jasoncwarner/status/1592227285024636928
- 30. 補⾜ マイクロサービス化に取り組む • Netflixは2008年からAWS化し、2016年1⽉に移⾏完了 »Netflixのクラウド移⾏が完了 -About Netflix ▸最も簡単な移⾏⽅法はリフトだが、問題や制約もついてくる ▸クラウドネイティブに技術を⾒直し、モノリシックアプリケーションをマイ クロサービスに移⾏した ▸最後になったのは課⾦や顧客のデータ管理の機能 • 「⼀括再構築でマイクロサービスに取り組む」のは危険 »段階的にマイクロサービス化していく 29
- 31.
- 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 NativeTrail 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.
- 37. Platform プラットフォームとは？ • 2018年： InternalDeveloper 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 DeveloperPlatform 38 チームA チームB チームC Platform OPS DevOps MSA
- 40. Platform Platformの中⾝は？ 39 デジタルプラットフォームは、セルフサービスのAPI、 ツール、サービス、知識、サポートの基盤であり、魅⼒的 な社内製品として配置されています。⾃律型デリバリー チームは、このプラットフォームを利⽤して、調整を減ら しながら、より速いペースで製品機能を提供することがで きます。 What I TalkAbout 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 プラットフォームエンジニアリングは、クラウドネイティブ時代 のソフトウェアエンジニアリング組織のセルフサービス機能を可 能にするツールチェーンとワークフローを設計および構築する分 野です。プラットフォームエンジニアは、アプリケーションのラ イフサイクル全体の運⽤上の必需品をカバーする「内部開発者プ ラットフォーム」と呼ばれる統合製品を提供します。 Whatis platform engineering? https://platformengineering.org/blog/what-is-platform-engineering
- 43.
- 44. まとめ アーキテクチャの進化を学ぶ • 年表 »2001 Agile »2006Cloud »2009 DevOps »2014 Microservices »2015 Cloud Native/Serverless »2018 Platform • 我々は、20年以上取り組んできている 43
- 45. まとめ 進化の本質 • 全ては「変化に素早く対応し続ける」ために »モジュール化における⾼凝集&疎結合は、古来からの基本原則 ▸コード →アプリ → サービス • どんな取り組みにも副作⽤があり、主に⼈間の認知の問題 »技術の進化が、効率的に副作⽤を抑えられるようにしてきた »ただし、理解せずに使えば、簡単に限界を踏み抜く 44
- 46.