Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What is Cloud Native ?

cyberblack28
November 04, 2021

What is Cloud Native ?

CloudNative Days Tokyo 2021 資料

cyberblack28

November 04, 2021
Tweet

More Decks by cyberblack28

Other Decks in Technology

Transcript

  1. What is
    Cloud Native ?
    Yutaka Ichikawa
    CloudNative Days Tokyo 2021
    Cloud Native Definition DevOps CI/CD Microservices Observability

    View Slide

  2. Publications
    Certification & Community
    CKA CKAD 2018 2019
    Profile
    Name: Yutaka Ichikawa
    Twitter/GitHub/Qiita: cyberblack28
    Hatena Blog: https://cyberblack28.hatenablog.com/
    Slides: https://speakerdeck.com/cyberblack28
    Job
    Principal Cloud Solution Engineer
    Solutions Architect
    Cloud Engineering
    Oracle Corporation Japan
    2021
    #CNDT2021

    View Slide

  3. Agenda
    ● Cloud Native Definition
    ○ Cloud Native Computing FoundationCNCFに぀い
    お
    ○ クラりドネむティブずは
    ○ そもそもクラりドコンピュヌティングずは
    ○ クラりドコンピュヌティングの特性
    ○ クラりドネむティブを実珟する道しるべ
    ○ 自動化の目的
    ○ 結局のずころ、クラりドネむティブずは
    ● DevOps
    ○ DevOpsずは
    ○ DevOpsを実珟する方法
    ● CI/CD
    ○ これたでのアプリケヌション開発
    ○ OS/ラむブラリずアプリケヌションの分離
    ○ 仮想マシンずコンテナの違い
    ○ OS/ラむブラリずアプリケヌションの統合
    ○ コンテナを支えるオヌケストレヌション
    ○ コンテナアプリケヌション開発における CI/CD
    ● Microservices
    ○ マむクロサヌビスの二぀の偎面
    ○ マむクロサヌビスの進化ず挑戊
    ○ コンテナにおけるマむクロサヌビスを実珟する技術
    ○ ビゞネス面におけるマむクロサヌビス
    ○ マむクロサヌビスの特城
    ○ マむクロサヌビスも結局
    ● Observability
    ○ そもそも監芖っお
    ○ オブザバビリティの背景
    ○ オブザバビリティずは ?
    ○ テレメトリヌ
    ○ オブザバビリティは、クラりドネむティブシステムを支え
    る

    View Slide

  4. Cloud Native Definition

    View Slide

  5. Cloud Native Definition
    Cloud Native Computing FoundationCNCFに぀いお
    ● The Linux Foundation傘䞋のプロゞェクトの1぀
    ● 2015幎に創蚭された財団
    ● コンテナ技術の掚進ず、その進化を取り巻くテクノロゞヌ業界の足䞊みを揃えるこずを目的
    ● 倧手クラりド事業者、ミドルりェア䌁業、ハヌドりェア補造䌁業、オヌプン゜ヌス・゜フトりェア䌁
    業、倧孊、その他非営利団䜓などが加入

    View Slide

  6. Cloud Native Definition
    幎3回、Europe、China、North AmericaでCNCF䞻催「KubeCon + CloudNativeCon」を開催
    KubeCon + CloudNativeCon
    North America 2019
    San Diego

    View Slide

  7. Cloud Native Definition
    クラりドネむティブずは
    Cloud Native Computing FoundationCNCFにおけるクラりドネむティブの定矩
    クラりドネむティブ技術は、パブリッククラりド、プラむベヌトクラりド、ハむブリッドクラりドなどの近代的でダむナミックな環境においお、ス
    ケヌラブルなアプリケヌションを構築および実行するための胜力を組織にもたらしたす。 このアプロヌチの代衚䟋に、コンテナ、サヌビ
    スメッシュ、マむクロサヌビス、むミュヌダブルむンフラストラクチャ、および宣蚀型APIがありたす。‚
    ‹
    これらの手法により、回埩性、管理力、および可芳枬性のある疎結合システムが実珟したす。 これらを堅牢な自動化ず組み合わせるこ
    ずで、゚ンゞニアはむンパクトのある倉曎を最小限の劎力で頻繁か぀予枬どおりに行うこずができたす。 ‹
    ‹
    Cloud Native Computing Foundationは、オヌプン゜ヌスでベンダヌ䞭立プロゞェクトの゚コシステムを育成・維持しお、このパラダむムの
    採甚を促進したいず考えおたす。 私たちは最先端のパタヌンを民䞻化し、これらのむノベヌションを誰もが利甚できるようにしたす。‚
    Cloud Native Computing Foundation(CNCF) Cloud Native Definition v1.0 | https://github.com/cncf/toc/blob/master/DEFINITION.md
    ”拡匵性・柔軟性に優れたアプリケヌションをクラりドの特性を掻かしお、
    最小限の劎力で構築および実行できるようにする”

    View Slide

  8. Cloud Native Definition
    そもそもクラりドコンピュヌティングずは
    The NIST Definition of Cloud Computingにおけるクラりドコンピュヌティングの定矩
    クラりドコンピュヌティングずはモデルであり、構成倉曎が可胜なコンピュヌティング資源䟋ずしおネットワヌク、サヌビス、ストレヌゞ、ア
    プリケヌション、サヌビスの共有プヌルを、オンデマンドなネットワヌクアクセスで可胜にする。‚
    ‹
    それはわずかな管理の手間、もしくはサヌビスプロバむダずのやりずりによっお迅速に準備され、提䟛される。‚
    ‹
    このクラりドモデルは可甚性を促進するものであり、5぀の本質的な性質ず、3぀のサヌビスモデル、そしお4぀のデプロむメントモデルか
    ら構成される。‚
    The NIST Definition of Cloud Computing | https://csrc.nist.gov/publications/detail/sp/800-145/final
    5぀の本質的な性質‚
    ● オンデマンド・セルフサヌビス‚
    ● 幅広いネットワヌクアクセス‚
    ● リ゜ヌスの共有‚
    ● 迅速な拡匵性‚
    ● 蚈枬可胜なサヌビス‚
    3぀のサヌビスモデル‚
    ● Cloud Software as a Service (SaaS)
    ● Cloud Platform as a Service (PaaS)
    ● Cloud Infrastructure as a Service (IaaS)
    4぀のデプロむメントモデル‚
    ● プラむベヌトクラりド‚
    ● コミュニティクラりド‚
    ● パブリッククラりド‚
    ● ハむブリッドクラりド‚

    View Slide

  9. Cloud Native Definition
    クラりドコンピュヌティングの特性
    オンプレミスでは困難なこずが、クラりドコンピュヌティングは実珟できる
    ● オンデマンド・セルフサヌビス
    ● 幅広いネットワヌクアクセス
    ● リ゜ヌスの共有
    ● 迅速な拡匵性
    ● 蚈枬可胜なサヌビス
    ● 資産保有が䞍芁
    ● 利䟿性が高い
    ● リ゜ヌス調達が早い
    ● 柔軟な拡匵性
    ● 利した分だけ課金

    View Slide

  10. Cloud Native Definition
    クラりドネむティブの道しるべ
    CNCF Trail Map | https://github.com/cncf/trailmap
    1.CONTAINERIZATION | コンテナ化‚
    仮想マシンずは異なり、環境差異が無く、軜量なむメヌゞで可搬性が高く、リ
    リヌスサむクルを速め、機敏さず信頌性を兌ね備えたアプリケヌションリリヌス
    を実珟‚
    2.CI/CD | 継続的むンテグレヌション/デリバリヌ‚
    ゜ヌスコヌドの倉曎を契機に、自動的なビルド、テスト、ステヌゞング環境およ
    び本番環境ぞのデプロむに぀ながるCI/CD環境を構築する‚
    3.ORCHETRATION & APPLICATION DEFINITION |
    オヌケストレヌションツヌルずアプリケヌション定矩
    コンテナ化されたアプリケヌションをKubernetes基盀で自埋的に運甚‚
    Helmを利甚しお、マニフェストを効率的に管理‚
    コンテナ化‚
    開発自動化‚
    運甚自動化‚
    ”拡匵性・柔軟性に優れたアプリケヌションを最小限の劎力で構築および実行”

    View Slide

  11. Cloud Native Definition
    自動化の目的
    人的関䞎を極力枛らしお向䞊化‚
    技術に任せられるものは任せお効率化、‚
    そしお、人にしかできないこずに時間やコストを傟ける‚
    向䞊したビゞネス䟡倀を゚ンドナヌザ様に提䟛する‚

    View Slide

  12. Cloud Native Definition
    結局のずころクラりドネむティブずは
    「CNCFに関連するプロダクト利甚 = クラりドネむティブ」‚
    ではない‚
    CNCF Cloud Native Interactive Landscape | https://landscape.cncf.io/

    View Slide

  13. Cloud Native Definition
    人的関䞎を極力枛らしおビゞネス䟡倀の向䞊を目指しお、‚
    それを゚ンドナヌザ様に届けるマむンドを持぀こず‚

    View Slide

  14. Cloud Native Definition
    CloudNative Days Fukuoka 2019
    『飛び蟌もうCloud Nativeの䞖界』 草間䞀人(@jacopen) | https://speakerdeck.com/jacopen/fei-biip-mou-cloud-nativefalseshi-jie

    View Slide

  15. DevOps

    View Slide

  16. DevOps
    DevOpsずは
    開発Developmentず運甚Operationsが互いに協力し合うこずで、
    開発・運甚する゜フトりェア・システムによっおビゞネス䟡倀を高めるだけでなく、
    そのビゞネス䟡倀をより確実か぀迅速に゚ンドナヌザに届け続ける抂念
    Dev Ops

    View Slide

  17. DevOps
    DevOpsを実珟する方法
    ● 「蚈画、蚭蚈、実装、テスト」ずいう開発工皋を機胜単䜍の小さいサむクルで繰り返しお開発を行う
    開発手法
    ● りォヌタヌフォヌルず異なり、仕様倉曎に匷く、プロダクトの䟡倀を最倧化するこずを目的ずする
    ● サヌビスむンたでの時間を短瞮できる
    1.アゞャむル開発
    䌁画‚ リリヌス‚ リリヌス‚ リリヌス‚
    蚈画‚
    実装‚
    蚭蚈‚
    テスト‚
    蚈画‚
    実装‚
    蚭蚈‚
    テスト‚
    蚈画‚
    実装‚
    蚭蚈‚
    テスト‚

    View Slide

  18. DevOps
    DevOpsを実珟する方法
    2.CI/CD継続的むンテグレヌション/継続的デリバリヌ
    ‹
    ● ゜ヌスコヌドからアプリケヌションずしおビルドするタむミングでテストを行っお、完成した成果物
    アヌティファクトを保存するたでの工皋を自動化
    ● 早期にバグを発芋、察凊できるこずでアプリケヌションの品質を高めるこずができる仕組み
    継続的むンテグレヌションCI: Continuous Integration
    ● 継続的むンテグレヌションによっお生成された成果物アヌティファクトをステヌゞング環境や本
    番環境などの各環境に配眮する仕組み
    ● リリヌス䜜業を簡玠化しお、安党、スピヌド、品質の向䞊を実珟するプロセス
    継続的デリバリヌCD: Continuous Delivery

    View Slide

  19. CI/CD

    View Slide

  20. CI/CD
    これたでのアプリケヌション開発
    物理マシン‚
    仮想マシン‚
    仮想マシンクラりド ‹
    コンテナ‚
    VM
    物理サヌバでアプリケヌションを皌働
    ‹
    物理サヌバ䞊に耇数の仮想マシンでアプリケヌションを皌働
    ‹
    クラりドをベヌスずしたスケヌラブルな仮想マシンでアプリケヌション
    を皌働‚
    物理マシン・仮想マシンもノヌドずしお束ねお、コンテナずいう小さい
    単䜍でアプリケヌションを皌働
    ‹

    View Slide

  21. CI/CD
    Developer Code Repository CI/CD Pipeline
    アプリケヌション
    OS/ラむブラリ
    開発環境 怜蚌環境 ステヌゞング環境 本番環境
    VM
    Operator
    Infrastructure
    Engineer
    コヌドをコヌドリポゞトリにコミット
    /プッシュ‚
    CI/CDパむプラむンによるテス
    ト、ビルド、デプロむ‚
    すべお自動化されおいる堎合もあれば、手動で行う堎合もありたす。
    ‹
    物理マシン‚ 仮想マシン‚ 仮想マシンク
    ラりド‚

    View Slide

  22. CI/CD
    アプリケヌション
    OS/ラむブラリ
    開発環境 怜蚌環境 ステヌゞング環境 本番環境
    VM
    OS/ラむブラリずアプリケヌションの分離‚
    物理マシン‚ 仮想マシン‚ 仮想マシンク
    ラりド‚
    アプリケヌションは物理マシンや仮想マシンの
    OS/ラむブラリ䞊で皌働
    皌働するアプリケヌションは 実行環境に䟝存する
    環境差異が原因で他の環境で皌働するけど、
    本番環境で皌働しない 等の障害が発生する
    OSのパッチバヌゞョンが異なる、このラむブラリ
    が無かった、関係ないものがむンストヌルされお
    いる ‚

    View Slide

  23. CI/CD
    アプリケヌション
    OS/ラむブラリ
    物理/仮想マシンにおける、OS/ラむブラリのアップデヌトには
    人手や時間を芁するため、アプリケヌションのリリヌスに圱響
    する 
    ハむパヌバむザヌ‚
    VMWare Xen/Server KVM
    ハヌドりェア‚
    VMWare
    Xen/Server
    KVM
    仮想マシン
    むメヌゞ‚
    ● 仮想マシンむメヌゞが ベンダヌ補品特有ベン
    ダヌロックむン‚
    ● 容量も重い数ギガ数十ギガ ‹
    ● 可搬性が䜎い‚

    View Slide

  24. CI/CD
    これたでのアプリケヌション開発
    ‹
    OS/ラむブラリが既に敎っおいる実行環境にアプリケヌションをデプロむするずいう圢匏
    1.アプリケヌション
    ● 環境差異による問題が発生‚
    ● OS/ラむブラリ偎に䜕かあるずアプリケヌションに圱響
    ‹
    2.むンフラ
    ● 仮想マシンむメヌゞがベンダヌ補品特有ベンダヌロックむン
    ‹
    ● 仮想マシンむメヌゞの容量が重く可搬性が䜎い
    ‹
    ● 物理/仮想マシンの特性䞊、OS/ラむブラリのアップデヌトに時間を芁しお、アプリケヌションのリ
    リヌスに圱響する‚

    View Slide

  25. CI/CD
    仮想マシンずコンテナの違い
    ハヌドりェア‚ ハヌドりェア
    ハむパヌバむザヌ‚ カヌネル
    仮想マシン‚ 仮想マシン‚
    コンテナ゚ンゞン
    コンテナ‚ コンテナ‚
    カヌネル‚ カヌネル‚
    ラむブラリ‚ ラむブラリ‚
    アプリケヌション‚ アプリケヌション‚
    ラむブラリ‚
    アプリケヌション‚
    ラむブラリ‚
    アプリケヌション‚
    仮想マシン‚ コンテナ‚
    各仮想マシンのカヌネル䞊で実行、 隔離性が高い
    が、起動が遅く数分オヌバヘッドが倧きい 。‚
    カヌネルを共有しおいるため、 隔離性は䜎いが、起
    動が高速数秒でオヌバヘッドが小さい 。‚

    View Slide

  26. CI/CD
    OS/ラむブラリずアプリケヌションの統合
    1.ビルドBuild
    ● OS/ラむブラリずアプリケヌションをパッケヌゞむメヌゞ化
    ● 技術ずしおはOSSのため、ベンダヌロックむンは発生しない
    ● むメヌゞはこれたでの仮想マシンむメヌゞに比べるず
    はるかに軜いので可搬性が高い
    OS/ラむブラリ‚
    アプリケヌション‚
    OS/ラむブラリ‚
    コンテナむメヌゞ‚
    ビルド
    (Build)

    View Slide

  27. CI/CD
    2.シップShip
    ● むメヌゞをレゞストリに保存
    ● レゞストリからコンテナプラットフォヌムぞ共有
    OS/ラむブラリ‚
    コンテナむメヌゞ‚
    プッシュ
    (Push)
    OS/ラむブラリ‚
    むメヌゞレゞストリ‚
    プル
    (Pull)
    OS/ラむブラリ‚
    コンテナプラットフォヌム
    OS/ラむブラリ‚ シップ(Ship)
    むメヌゞ共有

    View Slide

  28. CI/CD
    3.ランRun
    ● コンテナむメヌゞをベヌスにコンテナを起動
    OS/ラむブラリ‚
    コンテナプラットフォヌム
    ランRun
    コンテナむメヌゞ‚ コンテナ‚
    OS/ラむブラリ‚
    コンテナプラットフォヌム䞊でむメヌゞからコンテナを起動しお、アプリケヌションを皌働。
    コンテナむメヌゞもプラットフォヌムもベンダヌ技術に䟝存しないため、ベンダヌロックむンも無い。

    View Slide

  29. CI/CD
    コンテナアプリケヌション開発‚
    OS/ラむブラリずアプリケヌションを統合しお、軜量むメヌゞ化しお、コンテナプラットフォヌムにコンテナず
    しおデプロむする圢匏
    1.アプリケヌション
    ● OS/ラむブラリずアプリケヌションが䞀぀に統合されおいるため、環境差異による問題が起きにくい
    ‹
    2.むンフラ
    ● 仮想マシンむメヌゞず仕組みが異なり、OSSベヌスでベンダヌロックむンもなく、軜量で可搬性が高
    い‚
    ● OS/ラむブラリのアップデヌトも容易なため、リリヌスサむクルを速め、スピヌドAgilityが向䞊
    ‹

    View Slide

  30. CI/CD
    コンテナを支えるオヌケストレヌション
    ‹
    Kubernetesは、Google瀟内のコンテナヌオヌケストレヌションシステムである
    Borgからむンスパむアさ
    れお開発されたOSSのコンテナヌオヌケストレヌション。
    読み方クヌバヌネヌティス、クヌバネティス、クバネティス等
    略称K8sKubernetes
    8文字
    珟圚は、CNCF(Cloud Native Computing Foundation)で管理され、倚数の䌁業が参加するコミュニ
    ティで開発。

    View Slide

  31. 䞻な圹割‚ 実珟‚
    CI/CD
    Kubernetesの䞻な圹割ず実珟
    ● コンテナのスケゞュヌリング ‹
    ● ロヌリングアップデヌト ‹
    ● オヌトスケヌリング ‹
    ● 死掻監芖‚
    ● コンテナの自動修埩 ‹
    ● サヌビスディスカバリ ‹
    ● ロヌドバランシング ‹
    ● 頻繁なアプリケヌションのデプロむ を可胜にするシ
    ステム基盀‚
    ● 無停止によるリリヌス、高可甚 なシステム基盀 ‹
    ● 負荷に応じた䌞瞮自圚なシステム基盀 ‹

    View Slide

  32. CI/CD
    YAML
    Kubernetesクラスタ
    宣蚀的オペレヌション
    マニフェストファむル
    Controller
    Reconciliation
    loop
    登録
    監芖
    コンテナ管理
    䜜成・削陀
    Controller内のReconciliation loop調敎ルヌプず呌ばれる、
    あるべき理想の状態ぞ収束させるルヌプ凊理を実行。
    Controllerがあるべき理想の状態ぞ収束

    View Slide

  33. CI/CD
    Reconciliation loop
    Observe
    珟圚の状態を確認‚
    Analyze
    あるべき理想の状態ず珟圚の状態
    ‹
    ずの差分を分析‚
    Act
    分析した差分に察する凊理を実行
    ‹

    View Slide

  34. CI/CD
    Kubernetesクラスタ
    あるべき理想の状態
    Controller
    Reconciliation loop
    宣蚀的オペレヌション
    指定された 「replicas: 3」 のPod数を維持するこず
    Observe
    Analyze
    Act

    View Slide

  35. CI/CD
    Kubernetesクラスタ
    あるべき理想の状態
    Controller
    Reconciliation loop
    宣蚀的オペレヌション
    䟋起動しおいるPodが2個の堎合
    Observe
    Analyze
    Act
    Observe 理想:3 珟状:2

    View Slide

  36. CI/CD
    Kubernetesクラスタ
    あるべき理想の状態
    Controller
    Reconciliation loop
    宣蚀的オペレヌション
    䟋起動しおいるPodが2個の堎合
    Observe
    Analyze
    Act
    Analyze 理想状態ず比范しお、Podが1個足りない

    View Slide

  37. CI/CD
    Kubernetesクラスタ
    あるべき理想の状態
    Controller
    Reconciliation loop
    宣蚀的オペレヌション
    䟋起動しおいるPodが2個の堎合
    Observe
    Analyze
    Act
    Act 「image: nginx:1.21.0」のPodを䜜成

    View Slide

  38. CI/CD
    Kubernetesは分散凊理基盀‚
    Virtual Machine
    BareMetal
    Kubernetes
    Container

    View Slide

  39. CI/CD
    Kubernetes is becoming the Linux of the cloud
    by Jim Zemlin The Linux Foundation

    View Slide

  40. CI/CD
    Multi-Cloud to Multi-Kubernetes Cloud Native to Kubernetes Native

    View Slide

  41. CI/CD
    コンテナアプリケヌション開発における
    CI/CD
    1.CIOps Push型
    ゜ヌスコヌドが曎新されるたびに
    CIパむプラむンが皌働しお、アプリケヌションテスト、コンテナむメヌゞビ
    ルド、コンテナむメヌゞプッシュ、
    CDパむプラむンによるデプロむ。
    開発環境 怜蚌環境 ステヌゞング環境 本番環境
    物理マシン‚ 仮想マシン‚
    仮想マシンク
    ラりド‚
    VM
    コンテナプラットフォヌム
    OS/ラむブラリ‚ OS/ラむブラリ‚
    Operator
    Infrastructure
    Engineer
    Developer
    Code
    Repository
    CI/CD
    Pipeline
    Build Ship
    Run
    CIパむプラむンによるテスト、ビル
    ド、むメヌゞプッシュ
    コンテナプラットフォヌム
    ぞのデプロむ
    OS/ラむブラリ ‹
    OS/ラむブラリ ‹
    むメヌゞ共
    有
    コヌドをコヌドリポゞトリにコミット/プッシュ
    ‹
    Code,Dockerfile,manifest
    Image
    Registry
    CI
    CD

    View Slide

  42. CI/CD
    2.CIOpsにおけるセキュリティリスクず管理の煩雑化
    Developer
    Code
    Repository
    CI/CD
    Pipeline
    Image
    Registry
    Dev/Staging/Prod
    Read
    Read/Write
    Read/Write Read
    Read/Write
    Image
    Pull
    apply
    Kubernetesクラスタが増えるたびにセキュリティ
    含めた蚭定や暩限管理も増えるため、管理が煩
    雑ずなる。‚
    Kubernetesクラスタ倖郚での暩限管理ずなるため、セキュリティリスクがある。

    View Slide

  43. CI/CD
    3.マニフェストの再珟性
    Developer
    Code
    Repository
    CI/CD
    Pipeline
    Image
    Registry
    Dev
    Image Pull
    1.パむプラむンの実行順序が保蚌されるずは限ら
    ず、適甚されたクラスタ状態が想定ず異なるこず
    に。‚
    Staging Prod
    2.ロヌルバックするにも、マニフェストの曎新履歎
    を远うなど、迅速性に欠けおしたう。 ‹

    View Slide

  44. CI/CD
    4.GitOps Pull型
    Kubernetesクラスタ内に配眮されたGitOpsオペレヌタヌがConfigリポゞトリを定期的にポヌリングし
    お、曎新を怜知しお曎新内容をKubernetesクラスタに反映する仕組み。
    開発環境 怜蚌環境 ステヌゞング環境 本番環境
    物理マシン‚ 仮想マシン‚
    仮想マシンク
    ラりド‚
    VM
    コンテナプラットフォヌム
    OS/ラむブラリ‚ OS/ラむブラリ‚
    Operator
    Infrastructure
    Engineer
    Developer
    Config
    Repository
    CI
    Pipeline
    Build Ship
    Run
    コンテナプラットフォヌム
    ぞのデプロむ
    OS/ラむブラリ ‹
    OS/ラむブラリ ‹
    Image
    Registry
    Code
    Repository
    GitOps
    オペレタヌ
    CI
    CD
    ① Code Change
    & Git Push
    ④ Pull Request
    Merge
    ② Image Build & Test & Image Push
    ③ Pull Request
    â‘€ Polling & Sync
    むメヌゞ共有
    Code
    Dockerfile
    manifest

    View Slide

  45. CI/CD
    5.GitOpsのメリット
    ● マニフェストファむルをGit管理
    ○ デプロむ先に察しお「誰が、䜕時、䜕」を倉曎したのかを履歎で远える
    ○ デプロむ先をい぀でも前の状態に戻すこずロヌルバックができる
    ○ プルリク゚ストによるレビュヌ・マヌゞプロセスを通すこずで組織ガバナンスを適甚できる
    ● 自動化
    ○ 手動コマンドによるヒュヌマン゚ラヌの排陀
    ○ 運甚コストの軜枛

    View Slide

  46. CI/CD
    6.コンテナアプリケヌション開発における
    CI/CDが目指すずころ
    コンテナの可搬性PortabilityずスピヌドAgilityを持ち合わせ、
    品質および生産性の高いアプリケヌション開発を実珟
    これたで時間やコストを芁しおいた箇所の改善、‚
    より良いビゞネスロゞックに時間やコストを傟ける‚
    リリヌスサむクルを速め、‚
    ゚ンドナヌザ様に最高品質のサヌビスを提䟛‚
    ゚ンドナヌザ様の満足床、䌁業収益、ビゞネス䟡倀の向䞊に぀ながる
    ‹

    View Slide

  47. CI/CD
    クラりドネむティブにおけるコンテナアプリケヌション開発は、銀の匟䞞ではない
    実際に開発するアプリケヌションの特性、組織䜓制、チヌム䜓制、コスト、教育など
    基盀・開発・運甚の芳点からしっかりず芋据えお適材適所に怜蚎する必芁がある

    View Slide

  48. Microservices

    View Slide

  49. Microservices
    マむクロサヌビスの二぀の偎面
    マむクロサヌビスには、「開発組織・文化の偎面」ず「技術の偎面」の二偎面がある。
    1.開発組織・文化の偎面
    開発組織の成長に䌎うチヌム、人員が増加しおも、小芏暡なチヌム開発ず同様の玠早いプロダクト開
    発を維持する。
    2.技術の偎面
    マむクロサヌビスは、個々に開発された耇数の小さなサヌビスを連結させお、蚭蚈ず運甚を実珟する゜
    フトりェアのアヌキテクチャ。

    View Slide

  50. Microservices
    マむクロサヌビスの進化ず挑戊
    チヌムが小さい堎合‚
    ● 䞀぀のアプリケヌションに機胜を集玄しお開発
    ‹
    ● 速床ず開発品質の面で合理的
    ‹
    チヌムが倧きい堎合‚
    ● コミュニケヌションコストの増加
    ‹
    ● 20人以䞊になるずチヌム砎綻ぞ
    ‹
    䌚議に限らず、開発チヌム人数においおも理想は “ Two Pizza Rule ”
    “䌚議の参加者が倚いほど、生産性は䜎䞋する。これを解決するために、参加メンバヌを2枚のピザを分け合える人数に抑える。” ‹
    https://landing.directorpoint.com/blog/amazon-two-pizza-rule/

    View Slide

  51. Microservices
    マむクロサヌビスの前段ずしお組織の现分化
    100人を䞀぀にしお開発するよりも、䞻芁な機胜を10個に分けお機胜ごずに10人のチヌムを10個䜜っお
    開発した方が効率的。‚
    100人で開発‚ 10人のチヌムを10チヌム䜜っお開発‚

    View Slide

  52. Microservices
    組織の分散化による課題
    倧きいチヌムずしおの課題を解消しきれない
    ‹
    コミュニケヌションコストの増
    加‚
    チヌム裁量の䜎䞋‚ 曖昧な責任範囲‚

    View Slide

  53. Microservices
    技術においおも組織の分散化に合わせお分散化を進める
    この開発手法がマむクロサヌビス
    ‹
    ● 小さいチヌムが自埋的に機胜するこずで、党䜓ずしおのプロダクト開発スピヌドを向䞊
    ‹
    ● 各チヌムでデプロむサむクルが独立しおいるので、芁件に沿っお自由にリリヌス可胜
    ‹
    ● チヌムごずにパフォヌマンス芁件の異なるアプリケヌションをスケヌリング可胜
    ‹
    ● 機胜増加ず共にチヌムず人員もスケヌルするこずで、アプリケヌションず組織が同時に成長
    ‹

    View Slide

  54. マむクロサヌビスの9぀の特城
    Microservices
    マむクロサヌビスにおけるガむドラむン
    ‹
    ● サヌビスによるコンポヌネント化‚
    ● ビゞネス機胜に基づいたチヌム線成‚
    ● プロゞェクトではなく補品ずしお捉えお開発運甚‚
    ● むンテリゞェントな゚ンドポむントシンプルなパむプ‚
    ● 非䞭倮集暩的な蚀語やツヌルの遞択‚
    ● 非䞭倮集暩的なデヌタ管理‚
    ● ITむンフラの自動化Infrastructure as Code‚
    ● 障害、゚ラヌを前提ずした蚭蚈‚
    ● 先進的な蚭蚈‚
    James Lewis/Martin Fowlerの"Microservices" | https://martinfowler.com/articles/microservices.html

    View Slide

  55. Microservices
    2018幎にメルカリがマむクロサヌビスアヌキテクチャを採甚しお、組織、サヌビス、そしお䌁業ずしおも
    拡倧を目指し、継続䞭。
    https://www.itmedia.co.jp/enterprise/articles/1810/11/news049.html

    View Slide

  56. Microservices
    モノリスからマむクロサヌビス
    アプリケヌション
    アプリケヌション
    アプリケヌション
    アプリケヌション
    アプリケヌション
    モノリス マむクロサヌビス

    View Slide

  57. Microservices
    そしお、モダナむズ
    クラりドネむティブ技術を利甚したマむクロサヌビス
    Virtual Machine / BareMetal
    Kubernetes

    View Slide

  58. Microservices
    コンテナにおけるマむクロサヌビスを実珟する技術
    Service Mesh
    App Proxy
    Pod
    Container Container
    アプリケヌションずプロキシ機胜の分離 ‹
    アプリケヌションプロセスごずに専甚のプロキシを配眮しお、
    そのプロキシにネットワヌク呚りの仕事をたかせたす。
    ‹
    プロキシ機胜の䞭倮管理 ‹
    Control
    Plane
    App Proxy App Proxy
    App Proxy App Proxy
    プロキシ機胜は倧量になるのでコンフィグレヌションの管理
    コストが増加。䞭倮にプロキシ機胜の管理するコントロヌル
    プレヌンを配眮しお効率的に管理。
    ‹

    View Slide

  59. Microservices
    マむクロサヌビスの特城
    マむクロサヌビス・アヌキテクチャ
    倧芏暡なシステムを疎結合な耇数のサヌビスの組み合わせで実珟する蚭蚈方匏 ‹
    ● アップデヌトの容易性 ‹
    ● スケヌルの容易性‚
    ● 高可甚性‚
    サヌビスA‹
    サヌビスB
    サヌビスC
    サヌビスF
    サヌビスE
    サヌビスD
    サヌビスA‹
    サヌビスB
    サヌビスC
    サヌビスF
    サヌビスE
    サヌビスD
    システムA‹ システムB‹

    View Slide

  60. Microservices
    アップデヌトの容易性 ‹
    ● 他のサヌビスぞの圱響を極小化した圢で、アップデヌト察象のサヌ
    ビスのみをアップデヌト可胜 ‹
    ● 高頻床にサヌビスのアップデヌトが可胜 ‹
    スケヌルの容易性‚
    ● 他のサヌビスに圱響を䞎えるこずなく、必芁なサヌビスのみをス
    ケヌルアりト可胜‚
    ● 䜿甚するリ゜ヌスを最適化 ‹
    高可甚性‚
    ● サヌビスが独立しおいるため、障害の圱響を極小化 ‹
    ● 残ったサヌビス矀でサヌビス提䟛を継続しおいくこずが可胜 ‹
    アップデヌト ‹
    スケヌル‚
    障害‚
    障害圱響なし‚

    View Slide

  61. Microservices
    ビゞネス面におけるマむクロサヌビス
    顧客向け
    新ビゞネス
    創造
    瀟内業務
    効率化
    瀟倖
    瀟内
    ビゞネス
    創造
    業務効
    率化
    ビゞネスには進化のスピヌドず品質が求められる
    ● サヌビスの早期リリヌス ‹
    ● 垂堎の動向/反応を早期フィヌドバックしお察応 ‹
    ● サヌビス停止による機䌚損倱をなくす ‹
    システムは倉化するビゞネス芁件に合わせ短い時間で
    高頻床にリリヌスするこずが求められる
    ● アプリの倉曎をすぐに本番環境に適甚 ‹
    ● 倉化を蚱容できるシステムを構築 ‹
    ● 停止時間の短瞮ず運甚䜜業の効率化 ‹
    高頻床か぀即時に本番反映
    可胜なアプリケヌションが必芁

    View Slide

  62. Microservices
    マむクロサヌビスも結局
    マむクロサヌビスには文化的偎面ず技術的偎面があり、
    ‹
    その調和の最終的に目指すずころは
    ‹
    速く、正確に高品質なサヌビスを提䟛しお、
    ‹
    ゚ンドナヌザ様の満足床、䌁業収益、ビゞネス䟡倀の向䞊
    ‹
    これたで孊んできたクラりドネむティブの意矩ず同じ
    ‹

    View Slide

  63. Observability

    View Slide

  64. Observability
    Monitoring = 監芖、芳察しお蚘録する‚
    そもそも監芖っお

    View Slide

  65. Observability
    䜕のために、監芖、芳察しお蚘録する

    View Slide

  66. Observability
    ● サヌビスやアプリケヌションの健党性を確認
    ‹
    ● 障害やトラブルの原因調査‚
    ● キャパシティ分析‚
    ● サヌビス利甚者の行動分析‚
    技術、運甚、ビゞネスなど倚岐にわたる
    ‹

    View Slide

  67. Observability
    サヌビスやシステムを利甚するナヌザに圱響を䞎えないため‚

    View Slide

  68. Observability
    サヌビスやシステムの利甚者が、問題なく利甚できる、‚
    「安定皌働しおいる状態」を維持する‚
    ‹

    View Slide

  69. Observability
    ● より良い方法で、システムの皌働状況を把握できおいる状態
    ‹
    ● システム運甚においお、刀断に必芁ずなる情報を取埗できおいる状態
    ‹
    ● 迅速に障害やトラブルに察応できる状態
    ‹
    監芖の意矩‚
    これたでもこれからも、こうした本質は倉わらない
    ‹

    View Slide

  70. Observability
    オブザバビリティの背景‚
    これたでのシステム‚
    User
    Operator
    埓来のWeb3局モデルのようなシンプルな構成のシステムであれば、比范的容易に障害を調査するこず
    が可胜。‚
    LB/Web/App/D
    Bなどそれぞれの
    コンポヌネントを
    远いやすい‚
    Web‹ Application‹ Database‹
    LB‹

    View Slide

  71. Observability
    分散システム‚
    User
    分散システムのような小さなサヌビスが疎結合するようなシステムでは、構成が耇雑ずなり障害発生個
    所や原因远求が困難であり、たしお人の手で行うこずは非珟実的。
    ‹
    それぞれのコンポヌネ
    ントを远うのは非珟実
    的
    LB‹
    Operator

    View Slide

  72. Observability
    右図にあるような分散システムでは、倧量のサヌビ
    スが連携しお、䞀぀のシステムずしお成り立っおい
    るため、障害が発生した際の怜知など、これたでの
    ように容易にはいかない ‚
    『Adoption of Cloud Native Architecture, Part 2: Stabilization Gaps and Anti-Patterns』
    https://www.infoq.com/articles/cloud-native-architecture-adoption-part2/

    View Slide

  73. Observability
    Observability might mean different things to different people.
    可芳枬性は、人によっお意味が異なる堎合がありたす。
    ‹
    『 Distributed Systems Observability』
    https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/
    オブザバビリティずは
    Observability可芳枬性は、人によっおたたはシステムによっお基準、芳点、解釈の仕方が違うもの
    なので、本セッションの内容も䞀䟋ず捉えおください。
    ‹

    View Slide

  74. Observability
    クラりドネむティブにおけるオブザバビリティ
    クラりドネむティブ技術は、パブリッククラりド、プラむベヌトクラりド、ハむブリッドクラりドなどの近代的でダむナミックな環境においお、ス
    ケヌラブルなアプリケヌションを構築および実行するための胜力を組織にもたらしたす。 このアプロヌチの代衚䟋に、コンテナ、サヌビ
    スメッシュ、マむクロサヌビス、むミュヌダブルむンフラストラクチャ、および宣蚀型APIがありたす。‚
    ‹
    これらの手法により、回埩性、管理力、および可芳枬性のある疎結合システムが実珟したす。 これらを堅牢な自動化ず組み合わせるこ
    ずで、゚ンゞニアはむンパクトのある倉曎を最小限の劎力で頻繁か぀予枬どおりに行うこずができたす。 ‹
    Cloud Native Computing Foundation(CNCF) Cloud Native Definition v1.0 | https://github.com/cncf/toc/blob/master/DEFINITION.md
    クラりドネむティブの文脈では、Observability可芳枬性は、
    クラりドネむティブなシステムを実珟するたたは支える䞀芁玠

    View Slide

  75. Observability
    Kubernetes䞊のPod(コンテナ)を䟋に考えおみるず、決められた
    Nodeに決められたPod(コンテナ)が皌
    働するずは限らないため、これたでの監芖方法ずは違うアプロヌチが必芁ずなる。
    Kubernetes
    Operator
    Node状況、Kubernetes
    Cluster状況Podなど、ア
    プリケヌション、デヌタベヌス
    など色々ある

    View Slide

  76. Observability
    ● 人たたはシステムによっお基準・芳点は異なる
    ‹
    ● クラりドネむティブなシステムを実珟するたたは支える䞀芁玠
    ‹
    ● 埓来のシステムずは異なるアプロヌチが必芁分散システム、コンテナなど
    ‹
    オブザバビリティずは‚
    この本質も䞍倉‚
    ● より良い方法で、システムの皌働状況を把握できおいる状態
    ‹
    ● システム運甚においお、刀断に必芁ずなる情報を取埗できおいる状態
    ‹
    ● 迅速に障害やトラブルに察応できる状態
    ‹

    View Slide

  77. Observability
    Telemetry
    Observabilityを実珟する3芁玠
    Telemetryの各芁玠が連携しお、Observabilityを実珟させるこずが重芁
    Telemetry
    システムの状態を収集埌、付加情報を付䞎し
    お数倀に倉換したもの
    コンポヌネント間を跚ぐむベントたたはトラン
    ザクションの因果連鎖の指暙
    正垞・異垞動䜜など、システムにより生成されるテキ
    ストデヌタ
    Logs
    Metrics Traces

    View Slide

  78. Observability
    Observabilityを実珟する䞻なツヌル
    Prometheus & Grafana
    Grafana Loki EFK
    Jaeger Zipkin Open Telemetry
    この他に、ベンダヌ補品や
    クラりドベンダヌサヌビス
    もある
    Metrics
    Logs
    Traces

    View Slide

  79. Observability
    The CNCF End User Technology Radar
    The CNCF End User Technology Radarは、CNCF゚ンドナヌザヌコミュニティに代わっお、クラりド
    ネ
    むティブテクノロゞヌを評䟡するためのガむド。
    1.最も䞀般的に採甚されおいるツヌルはオヌプン
    ゜ヌス
    2.可芳枬性の領域に統合はない
    3.PrometheusずGrafanaはほが䞀緒に利甚
    最も「採甚」祚を獲埗した 3぀のツヌルPrometheus、Grafana、Elasticず
    最も合蚈祚を獲埗した 5぀のツヌルPrometheus、Grafana、Elastic、
    Jaeger、OpenTelemetryはすべおオヌプン゜ヌス。
    倚くの䌁業が耇数のツヌルを䜿甚。䌁業の半数は 5぀以䞊のツヌルを䜿
    甚しおおり、3分の1は10以䞊のツヌルを䜿甚した経隓がある。
    回答者の3分の2は、これら2぀のツヌルを組み合わせお䜿甚 。これは圓
    然だが、高い盞関関係は泚目に倀する。
    『The CNCF End User Technology Radar Observability, September 2020』
    https://radar.cncf.io/2020-09-observability

    View Slide

  80. Observability
    速く、正確に高品質なサヌビスを提䟛しお、
    ‹
    ゚ンドナヌザ様の満足床、䌁業収益、ビゞネス䟡倀の向䞊
    ‹
    オブザバビリティは、クラりドネむティブシステムを支える
    ‹
    提䟛だけではなく、垞にナヌザ゚クスペリ゚ンスを損なうこずが無いよう維持、
    ‹
    そしお、障害やトラブルが発生した堎合も速く、正確に察応できる䜓制も維持する
    ‹

    View Slide

  81. What is Cloud Native ?

    View Slide

  82. 人的関䞎を極力枛らしおビゞネス䟡倀の向䞊を目指し、それを゚ン
    ドナヌザ様に届けるマむンドを持぀
    速く、正確に高品質なサヌビスを提䟛し、゚ンドナヌザ様の満足
    床、䌁業収益、ビゞネス䟡倀の向䞊
    提䟛だけでなく、垞にナヌザ゚クスペリ゚ンスを損なうこずが無いよ
    う維持、障害やトラブルが発生した堎合も迅速に察応できる䜓制を
    維持

    View Slide

  83. Thank you !!

    View Slide