Download as PDF, PPTX
Uploaded byYusuke Suzuki
PDF, PPTX2,289 views
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
2023/11/11に開催されたJJUG CCC 2023 Fallでの講演「アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ」の資料です
![スマホゲームのチート手法とその対策 [DeNA TechCon 2019]](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2ftechcon2019funakubo-190218065153-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ
- 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.AgileScrum• 電⾞にたとえて理解する»出発ホームから定期的に出発»①出発ホームには、乗客が⼀列に並んで待っている»②電⾞が来たら、定員まで乗せて出発»③出発した電⾞は乗り降り禁⽌»④次の電⾞が来るまで、出発ホームの乗客は並び替え⾃由10出発ホームd cb a出発ホームd c b a出発ホームdc b a定員：2名①fe定員：2名②③④
- 12.補⾜対応表11電⾞の説明 スクラム⽤語 説明電⾞の運⾏スプリント 繰り返し続ける作業期間。1ヶ⽉以内の決まった⻑さ出発ホーム プロダクトバックログ これからやりたいことを優先順に並べたリストの乗客 プロダクトバックログアイテム そのリストの1⾏電⾞に乗る スプリントプランニング スプリントの開始時に、このスプリントでやることを決めるイベント電⾞ スプリントバックログ このスプリントで実施するタスクのリスト。スプリントプランニングでプロダクトバックログからアイテムを移動させてくるの乗客 スプリントバックログアイテム そのリストの1⾏
- 13.
- 14.
- 15.Agile課題：モノリス• 調整が素早さを削ぐ»影響調査»リグレッションテスト»リリース調整14Haystack Rockat 8:30am by Brenda Dobbshttps://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 Computinghttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf⽇本語訳 https://www.ipa.go.jp/files/000025366.pdf
- 19.CloudCloudがもたらしたもの• IaC（Infrastructure asCode）»インフラ構成をコードで表現できる»アプリケーションだけではなく、稼働環境を含めてサービスそのものがコードになる• PaaS（Platform as a Service）»インフラだけではなく、ミドルウェアや実⾏環境もサービス▸スケールだけではなく、機能性もターンキーで利⽤できるü クラスタ、⾃動デプロイ18
- 20.
- 21.DevOps開発♡運⽤• 「Devopsdays Ghent2009」の開催をきっかけに定着• 開発と運⽤は仲が悪かった»最⼤の運⽤リスクは変化の受⼊»でも、変化に素早く対応し続けられるようにならないといけない20
- 22.DevOpsDevOpsがもたらたしたもの• 運⽤をセルフサービスにする»素早く対応するに部署間のやり取りは無駄»開発がツールを使って運⽤作業を実施すればいい▸インフラ構築、ビルド＆デプロイ、スケール変更、監視＆予測、障害復旧...21成果物アプリDev Ops成果物DevSREOpsﾂｰﾙインフラアプリインフラ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年、アーキテクチャ設計における最⼤の間違いは「すべてをマイクロサービスにしようとすること」だ»モノリスからマイクロサービスは以下のように連続的だ»モノリス > アプリ > サービス > マイクロサービス28https://twitter.com/jasoncwarner/status/1592227285024636928
- 30.補⾜マイクロサービス化に取り組む• Netflixは2008年からAWS化し、2016年1⽉に移⾏完了»Netflixのクラウド移⾏が完了 -About Netflix▸最も簡単な移⾏⽅法はリフトだが、問題や制約もついてくる▸クラウドネイティブに技術を⾒直し、モノリシックアプリケーションをマイクロサービスに移⾏した▸最後になったのは課⾦や顧客のデータ管理の機能• 「⼀括再構築でマイクロサービスに取り組む」のは危険»段階的にマイクロサービス化していく29
- 31.
- 32.Cloud NativeCloud Native•2015年：Cloud Native Computing Foundation設⽴»Kubernetes 1.0のリリースと同時に設⽴»Cloud Native Definition v1.0▸クラウドネイティブ技術＜中略＞の代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣⾔型API▸回復性、管理⼒、および可観測性のある疎結合システムが実現▸堅牢な⾃動化と組み合わせることで、エンジニアはインパクトのある変更を最⼩限の労⼒で頻繁かつ予測どおりに⾏う31CNCF Cloud Native Definition v1.0https://github.com/cncf/toc/blob/main/DEFINITION.mdCloud Native Computing Foundationhttps://www.cncf.io/
- 33.Cloud NativeCloud NativeTrail Map» コンテナ化» CI/CD» オーケストレーション&アプリ定義» オブザーバビリティ» サービスメッシュ» ポリシー、セキュリティ» 分散データベース＆ストレージ» ストリーミング＆メッセージング» コンテナレジストリ＆ランタイム» ソフトウェアディストリビューション32Cloud Native Trail Maphttps://raw.githubusercontent.com/cncf/trailmap/master/CNCF_TrailMap_latest.pdf
- 34.Cloud NativeCloud NativeLandscape•1000近い関連製品» プロビジョニング» ランタイム» オーケストレーション» サーバレス» オブザーバビリティ» プラットフォーム» ...33Kubernetes
- 35.Cloud Native現在進⾏形で様々な技術が成⻑中• コンテナ+サーバレス»コンテナを稼働させるためのサーバレス環境▸Gitレポジトリからデプロイ＆スケールまで。常駐型もバッチ型も対応•サービスメッシュ»サービス間連携を管理するための仕組み▸ルーティング、セキュリティ＆ポリシー、監視、レジリエンスなど34
- 36.
- 37.Platformプラットフォームとは？• 2018年： InternalDeveloper Platform (IDP)36内部開発者プラットフォーム (IDP) は、運⽤チームによって構成され、開発者によって使⽤されます。運⽤チームは、どのリソースをどの環境で、またはどのような要求で起動するかを指定します。また、アプリケーション構成のベースライン テンプレートを設定し、アクセス許可を管理します。これにより、環境やリソースのスピンアップなどの定期的なタスクを⾃動化し、標準を適⽤することでセットアップの保守が容易になります。開発チームは、構成の変更、デプロイ、スピンによって⾃律性を獲得しますWhat is an Internal Developer Platform (IDP)? | Internal Developer Platformhttps://internaldeveloperplatform.org/what-is-an-internal-developer-platform/
- 38.PlatformDevOpsやMSAのアンチパターン• チーム/システムが個別に取り組む37チームA チームBチームCDevOps MSAOPS
- 39.PlatformPlatformを整備して提供する• Internal DeveloperPlatform38チームA チームB チームCPlatform OPSDevOps MSA
- 40.PlatformPlatformの中⾝は？39デジタルプラットフォームは、セルフサービスのAPI、ツール、サービス、知識、サポートの基盤であり、魅⼒的な社内製品として配置されています。⾃律型デリバリーチームは、このプラットフォームを利⽤して、調整を減らしながら、より速いペースで製品機能を提供することができます。What I TalkAbout When I Talk About Platforms (martinfowler.com)https://martinfowler.com/articles/talk-about-platforms.html
- 41.PlatformIDPを構築する• 認証認可»IAM、ユーザー管理、権限管理...• アプリケーション・インフラ構成管理»コアネットワーク、CI、IaC...»サーバ、データベース、シークレット...•パイプライン»Git、CI、コンテナリポジトリ、無停⽌デプロイ...• ガイドラインやサポート体制40
- 42.PlatformPlatform 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.