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