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

変革の先駆け:Cloud Native開発・運用のための3つのポイント / Three key...

Shintaro Kitamura
November 22, 2024
0

変革の先駆け:Cloud Native開発・運用のための3つのポイント / Three key points for Cloud Native development and operations

@IT Cloud Native Week 2024 winter

Shintaro Kitamura

November 22, 2024
Tweet

More Decks by Shintaro Kitamura

Transcript

  1. Update confidential designator here Version number here V00000 変革の先駆け Cloud

    Native 開発・運用のための 3つのポイント Shintaro Kitamura Specialist Solution Architect Red Hat K.K. @IT Cloud Native Week 2024 winter
  2. 2 北村 慎太郎 Red Hat - Specialist Solution Architect -

    OpenShiftを中心としたプリセールス 得意領域:SRE, Automation, CICD #Kubernetes #OpenShift #AWS #GCP #Terraform
  3. 4 Cloud Native 開発・運用で実現するシステム像 
 Innovation Reliability Innovation Reliability Reliability

    Innovation ・市場ニーズへの追従が要件 ・明確(not 厳格)な品質基準 ・流動的な体制、予算、スケジュール ・今後5年を踏まえた明確な要件と計画 ・厳格な品質基準 ・大規模な体制、予算、スケジュール ・イノベーションを最重視 ・新技術や新プラクティスの試験的な採用 ・限られた体制、予算、スケジュール 金融関連や公共インフラなどの バックエンドシステム SoEにあたるフロントエンドシステム、プラッ トフォーム 社内ツール、LPなど 企業が抱えるシステム群 ビジネス価値創出に 寄与するシステム
  4. ノウハウ プロセス ツール Cloud Native 5 Cloud Native 開発・運用に必要な要素 


    ノウハウ プロセス ツール Cloud Nativeアプリケーション開発・運用を効率化するソ フトウェアやプラットフォーム Cloud Native技術を最大限活用するための知識や 経験、ベストプラクティス 開発からデプロイ、運用に至るまでに必要な手順や 役割を体系化し、効率的なフローを確立する方法論
  5. 7 Cloud Native 開発・運用を支える Kubernetes
 ツール コンテナオーケストレーターの デファクトスタンダード 自動スケーリング/負荷分散 Node

    負荷分散 Node Node Auto Scale • アクセス量/処理負荷に応じたコンテナのスケールアウト • コンテナひとつひとつの個性(IPアドレス)を意識しない Node 負荷分散 Node Node 移動して起動 • 障害が起きたコンテナを検知し、自動的にサービスから切り離し • 自動的に正常なNodeにコンテナを退避させ、再起動させる • Immutable(変化しない)なインフラを実現 死活監視(ヘルスチェック)/自己回復性(オートヒール) Node Node Node Namespace ABC Namespace XYZ リソースの抽象化/リソースプールの割り当て • 必要リソースを割り当てることができる • その中で自由にリソースを活用できる
  6. 8 Kubernetes の強み - 自動化との親和性 ツール 開発面
 インフラ運用面 
 アプリケーション

    リポジトリ マニフェスト リポジトリ Deploy polling CI Git clone Update manifest CD Push Test Admin Kubernetes Cluster Pipeline Application Projects GitOps Logging Monitoring Security マニフェスト リポジトリ GitOps K8s マニフェスト bashスクリプト IaCツール tasks pipelines App project logstore exporter alertrule dashboard rbac psa nwpolicy ac user namespace quota limitrange テスト・ビルド・デプロイを自動化し開発を行いながら 継続的なソフトウェアの品質確認を実現 Kubernetesの”宣言型”という特性を活かし IaCツールやGitOpsツール、およびスクリプトを活用して Kubernetes に対する設定(=マニフェスト適用)を自動化
  7. 9 Kubernetes の強み - 充実したエコシステム ツール CNCF Landscape 多数のソフトウェアベンダーが提 供するサービス

    Cloud Native開発・運用を支えるツールのほとんどが Kubernetesとの連携機能を具備
  8. 10 充実しているからこその悩み ツール CNCF Landscape 多数のソフトウェアベンダーが提 供するサービス Cloud Native開発・運用を支えるツールのほとんどが Kubernetesとの連携機能を具備

    Kubernetesで足りない機能をどう補完する・・・? ビルド デプロイ モニタリング ロギング Cl CD セキュリティ レジストリ バックアップ etc…
  9. 11 Red Hat OpenShift ツール ミドルウェア の管理 クラスタの ロギングや監視 コンテナの

    セキュリティ クラスタ アップグレード コンテナの動的 ビルド/デプロイ Virtual Private cloud Bare metal Public cloud Edge エンタープライズに求められる機能を Kubernetesに付随し サポートすることで、ビジネス価値に直結する機能を提供
  10. 12 Red Hat OpenShiftが実現する世界 OpenShift AWS Azure OpenShift OpenShift Dashboard

    Build Automation Pipeline Deployment Automation Orchestration Monitoring Registry Logging ServiceMesh Developer tools/IDEs Infrastructure Built in Console OpenShift Dev Spaces S2i Build OpenShift Pipelines Openshift GitOps Kubernetes Internal Registry / Quay OpenShift Monitoring OpenShift Logging OpenShift Service Mesh VM / Bare metal Built in Console OpenShift Dev Spaces S2i Build OpenShift Pipelines Openshift GitOps Kubernetes Internal Registry / Quay OpenShift Monitoring OpenShift Logging OpenShift Service Mesh Built in Console OpenShift Dev Spaces S2i Build OpenShift Pipelines Openshift GitOps Kubernetes Internal Registry / Quay OpenShift Monitoring OpenShift Logging OpenShift Service Mesh AWS Compute Resources Azure Compute Resources 複数のクラウド上で一貫した開発・運用体験をもたらすプラットフォームを構築 ツール
  11. それぞれの役割が押さえるべきノウハウ ノウハウ 14 開発者が押さえるノウハウ 
 インフラ運用者が押さえるノウハウ 
 両者が押さえるノウハウ 
 •

    開発手法 ◦ スクラム開発 ◦ ドメイン駆動開発 ◦ テストドリブン開発 • Cloud Native アーキテクチャー ◦ マイクロサービス ◦ サービスメッシュ • コンテナ開発 ◦ ログ出力方針 ◦ セキュリティ • テストコーディング • IDE • Docker/Podman • Kubernetes マニフェスト • CI/CDパイプライン • リリース戦略 • Git • K8sによる非機能要件の実装方法 ◦ インストール ◦ 可用性・信頼性 ◦ セキュリティ ◦ モニタリング ◦ バックアップ ◦ キャパシティ ◦ アップグレード • 自動化 ◦ Infrastructure as Code ◦ GitOps • インフラストラクチャー ◦ ストレージ ◦ サーバー ◦ ネットワーク 開発スピードの向上 アプリケーションの品質担保 コーディング〜リリースのプロセス改善 アプリケーションの信頼性の向上 インフラ・プラットフォームの信頼性の担保 環境構築/開発スピード向上支援
  12. 15 いざ取り組むと訪れるノウハウの壁 ノウハウ コンテナ/Kubernetes サーバー/ネットワーク/ OS アップ グレード セキュリティ モニタリング

    可用性 パフォーマンス チューニング CI/CD オペレーション自 動化 トラブル シューティング マイクロ サービス ストレージ キャパシティ プランニング ス キ ル の 深 さ 例:インフラ運用者のスキル領域 コンテナ/Kubernetesをベースとした 信頼性の向上に関するスキル全般 が求められる
  13. 特定の領域を習得してカバーし合う ノウハウ コンテナ/Kubernetes サーバー/ネットワーク/ OS アップ グレード セキュリティ モニタリング 可用性

    パフォーマンス チューニング CI/CD オペレーション自 動化 トラブル シューティング マイクロ サービス ストレージ キャパシティ プランニング ス キ ル の 深 さ 例:インフラ運用者のスキル領域 各領域の基礎スキルは 全メンバーが習得 特定領域に特化した 人材を育成 スキルの共有 16
  14. Red Hatがノウハウの習得をサポート ノウハウ 18 製品技術支援としてのコンサルティングサービスの一例 • 案件に即したご支援 ◦ 設計、プロトタイプの作成ご支援、パフォーマンスチューニング等 ◦

    早期段階からご支援する事で、手戻りや考慮不足を防ぎ、 より満足度の高いシステムのご提供に貢献 • ハンズオントレーニング • 技術 Q&A 製品技術支援 製品サポート お客様 アプリ SIer様 インフラ SIer様 自社IT アドバイザーとしてのコンサルティングサービスの一例 • アーキテクチャやビジョンの策定支援 ◦ セルフサービス化、マイクロサービス設計、 DevOpsなど、 Cloud Native開発・運用 の知見や経験を持つコンサルタントが伴走 ◦ 実績のある現状分析手法や移行方式を用いてデリバリ • 運用後の改修や性能を考慮した品質に関するアドバイス アプリ ご担当 インフラ ご担当 統括 アドバイザー
  15. Red Hatがノウハウの習得をサポート ノウハウ 19 企業や個人の能力を引き出すための『スキルアップ』を最大限支援 オペレーティングシステム市場で 約80%のシェア 最新の OSSのスキルと Cloud

    Native なスキルの習得 実機による認定試験と豊富な資格 コンテナ市場で 47.8%のシェア e-Learning バーチャルトレーニング 一社研修 様々な受講形態をサポート
  16. プロセスの変化で正しいコンテナ導入効果を 21 アプリケーションがマイクロ化するほど リソース調達や変更作業が増える コンテナ導入効果 コンテナ導入のプロセス変化 既存プロセスの課題 リソースの変更工数 1週間 リソースの変更工数

    5分 リソースの払い出し工数 99%削減 コミュニケーションパスの改善 50%削減 変更依頼 変更作業 確認 変更確認 アプリ開発者 インフラ運用者 リソースの変更作業が 開発者自身で行える環境に変更 変更作業 変更確認 アプリ開発者 コンテナ基盤 インフラ運用者 変更者 仮想マシン導入 と異なる 変更者 プロセス
  17. 22 プロセス 従来の開発の目的:大規模なシステムを手戻りなく高い品質でリリースする 開発担当 運用担当 <アプリケーションの特性> • 一度開発しきったらほとんど変更がかからない • 最終形を見据えた設計・開発を行うため仕様が明確

    • モノリシックな構成のため、障害ポイントの検出精度が 高い(=テストで潰せる) • 開発者が「運用手順書」を作成して、運用部門に渡す • 運用部門は受け取ったアラートと運用手順書を見比べて、切り分けフローや障害復旧手順を実行する 開発フェーズと運用フェーズで主担当者を明確に分離できる 運用手順書 ・アラートの種類 ・切り分けフロー ・障害復旧手順 ・エスカレーション先 従来の開発と運用の役割分担
  18. 23 プロセス 従来の開発と運用の役割分担 インフラ構築担当 開発担当 運用担当 引き継ぎ 引き継ぎ (場合によって) インフラ運用担当

    リソース 払い出し フェーズを境に担当を移管 VMを払い出し、OS以上は開発担 当が対応 ア プ リ イ ン フ ラ 開発フェーズ 運用フェーズ
  19. 24 プロセス Cloud Native 開発・運用における役割分担 Cloud Native 開発・運用の目的:ビジネスニーズに応じて柔軟かつ高頻度のリリースを行う 開発担当 <アプリケーションの特性>

    • リリース後も頻繁な改善や機能追加が発生する • 当初の設計とは異なる機能実装になるケースもある • マイクロサービスのような分散アーキテクチャの場合、 障害ポイントの洗い出しが困難 • 機能改修・追加のたびに運用手順書を修正して渡す運用はトイルが大きくなり、リリーススピードの阻害要因になる • 切り分けフローや復旧手順をあらかじめ網羅しドキュメントに落とし込むことが困難 フェーズと主担当者をセットで分離することは困難 運用手順書 v1.0 運用手順書 v1.1 運用手順書 v1.2 運用担当
  20. インフラ構築担当 (場合によって) インフラ運用担当 25 プロセス Cloud Native 開発・運用における役割分担 変更作業のやりとりではなく 開発・運用効率化のために

    チーム間が連携 継続的な開発を行うため、 フェーズによる 担当の移管は発生しない ア プ リ イ ン フ ラ 開発フェーズから 運用を意識したメンバーと連携 運用担当 開発担当 安定運用 開発 稼働投入率
  21. 26 プロセス Cloud Native 開発・運用における役割分担 安定運用 インフラ構築担当 ア プ リ

    イ ン フ ラ 運用担当 開発担当 開発 稼働投入率 (場合によって) インフラ運用担当 K8s resilience Platform Services* による効率化 CICD スクラム開発 による効率化 IaC GitOps による効率化 k8s resilience Operatorによる効率化 *) Service Mesh / Serverless / CICDの導入をサポートする各種ツール群
  22. 28 Cloud Native 開発・運用で実現するシステム像 
 Innovation Reliability Innovation Reliability Reliability

    Innovation ・市場ニーズへの追従が要件 ・明確(not 厳格)な品質基準 ・流動的な体制、予算、スケジュール ・今後5年を踏まえた明確な要件と計画 ・厳格な品質基準 ・大規模な体制、予算、スケジュール ・イノベーションを最重視 ・新技術や新プラクティスの試験的な採用 ・限られた体制、予算、スケジュール 金融関連や公共インフラなどの バックエンドシステム SoEにあたるフロントエンドシステム、プラッ トフォーム 社内ツール、LPなど 企業が抱えるシステム群 ビジネス価値創出に 寄与するシステム 目指すべきはココだけど いきなり実現は難しい
  23. 29 Cloud Native 開発・運用で実現するシステム像 
 Innovation Reliability Innovation Reliability Reliability

    Innovation ・市場ニーズへの追従が要件 ・明確(not 厳格)な品質基準 ・流動的な体制、予算、スケジュール ・今後5年を踏まえた明確な要件と計画 ・厳格な品質基準 ・大規模な体制、予算、スケジュール ・イノベーションを最重視 ・新技術や新プラクティスの試験的な採用 ・限られた体制、予算、スケジュール 金融関連や公共インフラなどの バックエンドシステム SoEにあたるフロントエンドシステム、プラッ トフォーム 社内ツール、LPなど 企業が抱えるシステム群 ビジネス価値創出に 寄与するシステム どちらか一方から アプローチする
  24. 30 Cloud Native 開発・運用で実現するシステム像 
 Innovation Reliability Innovation Reliability Reliability

    Innovation ・市場ニーズへの追従が要件 ・明確(not 厳格)な品質基準 ・流動的な体制、予算、スケジュール ・今後5年を踏まえた明確な要件と計画 ・厳格な品質基準 ・大規模な体制、予算、スケジュール ・イノベーションを最重視 ・新技術や新プラクティスの試験的な採用 ・限られた体制、予算、スケジュール 金融関連や公共インフラなどの バックエンドシステム SoEにあたるフロントエンドシステム、プラッ トフォーム 社内ツール、LPなど 企業が抱えるシステム群 ビジネス価値創出に 寄与するシステム 小さく始める Cloud Native化 メリット • 低予算かつ小規模から導入でき従来の制約の影響を 受けづらいため、Cloud Nativeの考え方が早期に浸 透しやすい • 新しい技術と開発手法に触れられるため、開発メン バーのモチベーションを高められる デメリット • 予算が限られるため、専任メンバーを選出できず結果 としてCloud Native化が十分に進まない可能性があ る • 新規開発のため、従来の開発と比較した効果を測定 しづらい PoCや社内ツールの新規開発をCloud Native 技術とアジャイル開発手法を使って実装し、イノ ベーションの速度向上を実感しながら徐々に信 頼性を高めていく
  25. 31 Cloud Native 開発・運用で実現するシステム像 
 Innovation Reliability Innovation Reliability Reliability

    Innovation ・市場ニーズへの追従が要件 ・明確(not 厳格)な品質基準 ・流動的な体制、予算、スケジュール ・今後5年を踏まえた明確な要件と計画 ・厳格な品質基準 ・大規模な体制、予算、スケジュール ・イノベーションを最重視 ・新技術や新プラクティスの試験的な採用 ・限られた体制、予算、スケジュール 金融関連や公共インフラなどの バックエンドシステム SoEにあたるフロントエンドシステム、プラッ トフォーム 社内ツール、LPなど 企業が抱えるシステム群 ビジネス価値創出に 寄与するシステム 既存のアプリの Cloud Native化 メリット • 余裕を持ったスケジュールと予算が組まれやすい • 広く深い範囲で検討・実装が行われ、しっかりとしたノ ウハウを習得できる • 関係部署が多く、新しい開発・運用プロセスの適用が 難航する恐れがある • システム上の制約が多く、目指すべき Cloud Native化 ができない可能性が高い 開発手法はそのままで、既存のアプリのコンテ ナ化からスタートし、コンテナでの信頼性担保の 実績を作ってからイノベーション加速に注力する デメリット
  26. ① 経営層の理解 ② ビジネス部門との連携 ③ DevOpsの導入 ④ アーキテクチャのモダン化 スクラムによるアジャイル開発では開発のアジリティやスピードを上げるため、ソフトウェアの実装からテストま でを「スプリント」と呼ばれる短期間で実施する。そしてスプリントを繰り返すことで、

    システムを作り上げていく。 問題になるのは、ウォーターフォールの考え方が抜けきらない組織長が 「いつ完成するのか?」「どんな機 能にいくらかかるのか?」「設計書を確認したい」などの要求をしてくるケースである。 この要因として、組織 長とシステム開発チームとの間に、アジャイルの理解に関する 距離があることが挙げられる 。 そこで、開発プロ ジェクトが始動する前に、 役員・プロジェクト責任者・各部門長などに対して 「アジャイルとはそもそも何か、そ の基本概念と価値観および従来手法との違い」 を説明し、その有効性を理解 させたり、協力者を生み出した りすることで、アジャイル開発のチームが円滑に活動できるような環境づくりを行うことを推奨する。 32 小さく始める Cloud Native 化 重視すべきは 高速なフィードバックループを回すための 開発手法の確立 スクラム開発の成功に 必要な要素 経営層・組織長の理解がスクラム開発成功のカギ Ref.独立行政法人情報処理推進機構  DX白書2023「第5部第2章 ITシステム開発手法と技術」より抜粋 Innovation Reliability Reliability Innovation
  27. ① 経営層の理解 ② ビジネス部門との連携 ③ DevOpsの導入 ④ アーキテクチャのモダン化 33 お客様のスクラム開発導入を強力に支援

    知識と経験を持ったプロが支援 ビジネスアジリティ アジャイル開発で 取り組むこと アーキテクチャ モダナイゼーション ビジネス部門の プロダクトデザイン ライフサイクル 開発部門の 育成と運営 会社組織としての 変革取り組み ✔ 経営層のアジャイルトレーニングと強力な支援 ✔ 周知、教育の展開 ✔ 大規模にスケールした際の組織としての活動 ✔ 品質管理の変革 ✔ 正しいアジャイルの理解とマインドセット ✔ 開発と運用のコラボレーション ✔ テスト駆動開発などのエンジニアリングプラクティスの導入 ✔ CI/CD、自動化の導入 ✔ スクラムの実践 ✔ 自己組織の定着 ✔ データの活用、ビジネスへのフィードバック ✔ ドメイン駆動設計 ✔ モノリシックからマイクロサービスアーキテクチャへの移行 ✔ APIライフサイクルの管理 ✔ ビジネスを止めないシステムを支えるインフラ ✔ ビジネス部門への教育 ✔ プロダクト仮説検証プロセスの定着 ✔ アジャイル要求管理の定着 スクラム開発の成功に 必要な要素 エンゲージメントリード アジャイルコーチ DevOpsコーチ App開発コーチ Innovation Reliability Reliability Innovation
  28. 34 簡単かつ迅速にクラスター利用を開始 Red HatとAWS/Azureが共同でサポートする フルマネージド OpenShiftサービス ビジネスニーズに応じた拡張性と、オンデマンドの課金モデル (時間または年間)による柔軟な価格設定 で、必要なリソースだけ支払うことができます。 Simplify

    cluster operations コントロールプレーンとクラスター運用機能( Cluster Operator)の運用監視をフルマネージドで提供しま す。 Empower developers to innovate 各クラウドの使い慣れたAPIやサービスと、Red Hat OpenShiftに付属されている開発ツールを組み合わ せることによって、迅速に開発環境を構築します。 Red Hat OpenShift Service on AWS (ROSA) 運用の複雑さを軽減し、開発者がアプリケーションの開発と運用に集中 Flexible, consumption-based pricing Expert management and support Red Hat SREがデプロイから日々の運用まで 24時間365日のサポートを提供します。 AWS Azure Red Hat OpenShift (ARO) Azure Innovation Reliability Reliability Innovation
  29. 35 既存のアプリの Cloud Native化 重視すべきは Cloud Native 技術を使った環境下における 信頼性の担保 オンプレミス

    VM システム Kubernetes システム コンテナ コンテナ 同等の信頼性をどうやって 担保するのか? • 開発者と運用者の役割は? • コンテナの非機能要件とは? • 開発にどんな影響がある? 従来のシステム構成 コンテナ化された システム構成 本格的なコンテナ開発・運用の導入検討が必要 Innovation Reliability Innovation Reliability
  30. 36 Red Hatがコンテナ導入の完遂をサポート 急なアクセス増にも柔軟にスケール 統合IT基盤 Developer Services ビルド イメージ管理 CIパイプライン

    デプロイ Operation Services 監視 セキュリティ バージョン管理 バックアップ アプリ開発者 インフラ運用者 Aシステム Bシステム Cシステム 迅速なアプリ開発 ・ コンテナイメージビルド ・ 静的/動的テスト ・ セキュリティテスト ・ 負荷テスト ・ 継続的インテグレーション ・ アプリケーションモニタリング ・ 動的デプロイメント ・ 継続的デリバリ 需要に応じた 迅速な対応 サービスの 安定性確保 安全なインフラ運用 ・ コンテナイメージ管理 ・ 基盤セキュリティテスト ・ キャパシティプランニング ・ バージョン管理 ・ バックアップ管理 ・ ログ/監視 ・ ディザスタリカバリ Container Adoption Journey 企業がアプリケーション開発にコンテナやマイクロサービスを活用し、お客様環境に適した形で、継続的にサービスを 改善し続ける運用体制やプロセスを築くことを支援 アプリケーションコンサルタント インフラコンサルタント Innovation Reliability Innovation Reliability
  31. 37 エンタープライズグレードの環境を一括で提供 アプリライフサイクル 統合管理 セキュリティ 統合管理 コンテナイメージ 統合管理 データ 統合管理

    単一のコンソールから複数の クラスタ上で稼働するアプリ ケーションのポリシーを一括制 御 継続的なスキャンによる、脆弱 性の早期に検知を開発の中で 実装するDevSecOpsを実現 分散型で可用性の高い、コン テナイメージデジストリによる ガバナンスの統制 サービスレベルに合わせた柔 軟性のあるデータ保護 Innovation Reliability Innovation Reliability
  32. ノウハウ プロセス ツール Cloud Native 39 Cloud Native 開発・運用に必要な要素 


    ノウハウ プロセス ツール Cloud Nativeアプリケーション開発・運用を効率化するソ フトウェアやプラットフォーム Cloud Native技術を最大限活用するための知識や 経験、ベストプラクティス 開発からデプロイ、運用に至るまでに必要な手順や 役割を体系化し、効率的なフローを確立する方法論
  33. ノウハウ プロセス ツール Cloud Native 40 各要素のポイント 
 ノウハウ プロセス

    ツール Kubernetes導入により自動化やスケーリングを実現し、 開発・運用を大幅に効率化 Cloud Native技術を最大限活用するための知識や 経験、ベストプラクティス 開発からデプロイ、運用に至るまでに必要な手順や 役割を体系化し、効率的なフローを確立する方法論 Kubernetes導入により自動化やスケーリングを実現し、 開発・運用を大幅に効率化 習うより慣れよ! 実践と学習を組み合わせ、 ”生きた”技術スキルを習得 Cloud Native 開発・運用のあるべき姿に向けて体制や役 割分担の変革が必要
  34. Innovation Reliability Innovation Reliability Reliability Innovation Cloud Native 41 組織・システムの特性に応じたアプローチの選択

    
 ノウハウ プロセス ツール ITイノベーションの加速 
 システムの信頼性担保 
 ビジネス成果の向上 コンテナ環境における 信頼性の担保からアプローチ モダンな開発手法の確立によるイ ノベーション加速から アプローチ
  35. Update confidential designator here Version number here V00000 linkedin.com/company/red-hat youtube.com/user/RedHatVideos

    facebook.com/redhatinc twitter.com/RedHat 42 Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you