クラウドネイティブなアーキテクチャを設計する次世代の現場力

Slide 1

Slide 1 text

クラウドネイティブなアーキテクチャを設計する次世代の現場力【】

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

クラウドネイティブなアーキテクチャを設計する次世代の現場力クラウドネイティブへの期待柔軟かつ効率的なシステム運用迅速かつリスクの少ないアプリデプロイ信頼性を維持する運用体制

Slide 4

Slide 4 text

クラウドネイティブへの期待

Slide 5

Slide 5 text

クラウドリソースを意識することなく活用できることクラウドネイティブとはコード開発ビジネス価値創出に集中し、非効率な運用を回避すること。

Slide 6

Slide 6 text

クラウドサービスを利用している企業の割合は年から大幅に上昇クラウド利用の状況出典総務省「通信利用動向調査」クラウド上でアプリケーションを動かすのは当たり前

Slide 7

Slide 7 text

の役割はクラウドの抽象化だけでなく、リソースマネージメントを行うはクラウドのアプリケーションプロセスアプリケーションコンテナシステムコールプロセス管理メモリ管理デバイス管理プロセス間通信割り込み管理コンテナスケジューリングメモリ管理デバイス管理コンテナ負荷分散コンテナ死活監視アプリケーションはが提供する機能を前提として開発されるアプリケーションはクラウドが提供する機能を前提として開発される

Slide 8

Slide 8 text

クラウド上でアプリケーションを構成するためのコンセプトクラウドネイティブアプリケーションクラウド特性を活かして、スピード、柔軟性、品質を向上させ、リリースへのリスクを削減するために設計されたアプリケーション。 “ ” Kubernetesを利用することや、アプリをマイクロサービス化することではない!! 業務が期待するスピードと品質のアプリをどの環境でも展開できる設計コンセプト

Slide 9

Slide 9 text

によるクラウドの定義クラウド特性とはオンデマンド・セルフサービス幅広いネットワークアクセスリソースの共有スピーディな拡張性サービスが計測可能であること出典従来の経営資源を有効活用したい環境の変化に柔軟に対応できる内製化を行いたい事業継続性の強化を図りたい経営課題

Slide 10

Slide 10 text

クラウドネイティブは意識改革であり、意識しなければクラウドネイティブなどありえない。クラウドネイティブを阻害する要因ただクラウド技術を使っているだけ仮想マシンやストレージの払い出しとして使っているだけであり、従来のリソース調達と変わらない。クラウド特性を設計や運用に反映してないクラウド特性を理解しないまま、各クラウドの機能に対してオンプレでできる自由さ属人化と比較する。クラウドでは変更することを前提としているにもかかわらず、塩漬け運用からの差分を補おうとする。役割とプロセスが変わる機能と非機能の双方をアプリ開発者とインフラ運用者でそれぞれ考えており、役割が従来と変わっていない。コード化による自動化クラウドを利用しているにもかかわらず、手作業プロセスから離れられないため、属人化の増加や人手不足を招いている。

Slide 11

Slide 11 text

システムを変えることよりも、意識を変えることのほうが必要な現場アーキテクトが直面する現実オンプレと同じような構成を取りたいけれど、対応する機能がクラウドにない。今の体制では、人手不足でアプリケーションの回収などできない。運用を動的にしたら、ブラックボックス化して障害時に誰も対応できない。外部に開発運用を任せているから、あまり内部を知らなくてもなんとかなる。

Slide 12

Slide 12 text

クラウドネイティブを実現するための意識改革を紐解いていくクラウドネイティブな設計迅速かつリスクの少ないアプリデプロイ柔軟かつ効率的なシステム運用信頼性を維持する運用体制

Slide 13

Slide 13 text

柔軟かつ効率的なシステム運用

Slide 14

Slide 14 text

コンテナは仮想化の延長ではない仮想化とコンテナ Infrastructure Hypervisor OS App Infrastructure OS Container Engine Lib OS App Lib App Lib App Lib アプリケーションの起動にアプリケーションの起動にの起動プロセスの起動

Slide 15

Slide 15 text

【参考】出典 Kubernetes Introduction for VMware Users https://blogs.vmware.com/cloudnative/2017/10/25/kubernetes-introduction-vmware-users/

Slide 16

Slide 16 text

仮想化とコンテナの違いはもぅいいんじゃないか。

Slide 17

Slide 17 text

コンテナは仮想化の延長ではない仮想化とコンテナ Infrastructure Hypervisor OS App Infrastructure OS Container Engine Lib OS App Lib App Lib App Lib だけだと、クラウドネイティブが分かりずらい「結局、とコンテナが起動する速さの違い？」ということで。少し違う視点で見てみる

Slide 18

Slide 18 text

クラウドネイティブにおける柔軟なリソース配置仮想化とコンテナ OS App Lib App Lib App Lib 専用の仮想マシン OS App Lib 専用の仮想マシンイメージ標準化されたコンテナイメージ移行するためにはコンバーターが必要どこでも移行可能

Slide 19

Slide 19 text

クラウドネイティブを実現するためのツールも、利用対象によって意味合いが異なるクラウドロックインからの開放・ベンダーロックイン・自由なの選択レイヤの依存により、各ベンダーごとに仮想マシンの作成方法が変わる。その分、どのでも利用できるため、設定の自由度が高い。・ベンダーロックインの開放・の依存コンテナエンジンを利用することによって、アプリケーションそのものをどこでも実行することができる。ただし、が限定されるため、などには専用が必要。ベンダーごとに異なる設定や、個別のカスタマイズを重視した設定をコードに反映することで、クラウドネイティに必要な柔軟性やスピード、品質に対応する。ベンダーロックインを避けるコンテナの特性を活かし、オーケストレーションの機能によって、クラウドネイティブが必要とするスピードと品質に対応する。

Slide 20

Slide 20 text

カスタム運用の回避と回復性の高い設計が重要。クラウドネイティブなシステム運用正常稼働障害検知状態確認復旧作業正常確認正常稼働障害検知動的復旧手作業不具合修正再構築正常確認自己修復自動作業個別対応クラウドネイティブな運用・各ベンダーの運用作業を統一・カスタム運用を極小化クラウドネイティブな運用・自動修復・動的リソース調整

Slide 21

Slide 21 text

Slide 22

Slide 22 text

カスタム運用を減らすことで得られる効果マネージドサービスの利点実証済みのソリューションによる、導入の迅速化と容易化日常業務におけるリソース運用からの解放予測可能で経済的な価格設定によるコスト削減迅速かつ費用対効果の高い拡張継続的な監視でビジネスを保護マネージドサービスは運用ノウハウをサービス化したもの。自律化されたシステムを利用。

Slide 23

Slide 23 text

が、より自社の運用にあったものを選択マネージドサービスに求められることプロセスの観察プロセス状態の判断プロセス復旧作業アプリケーションの現在の状態を判断する。例アプリケーションの現在の状態とアプリケーションの予想される状態を比較する。例アプリケーションの実行状態を期待状態に一致させるための処理を実行します。例

Slide 24

Slide 24 text

マネージドサービスも創る時代マネージドサービスを展開する・年からコンセプトとして導入された機能・環境を監視し、現在のアプリの状態を使用して、コンテナ運用を行う拡張機能は人間の運用知識をソフトウェアで表したもので、アプリケーションの信頼性を管理する。

Slide 25

Slide 25 text

【参考】出典 Comparing Kubernetes Operator Pattern with alternatives

Slide 26

Slide 26 text

クラウドネイティブを実現するための意識改革を紐解いていくクラウドネイティブな設計迅速かつリスクの少ないアプリデプロイ柔軟かつ効率的なシステム運用信頼性を維持する運用体制複雑な運用を自律化し、回復性の高いシステムに

Slide 27

Slide 27 text

迅速かつリスクの少ないアプリデプロイ

Slide 28

Slide 28 text

多くのアプリケーションはモノリシック。その一方で、マイクロサービス化の流れモノリシックとマイクロサービスディスパッチャープレゼンテーションビジネスロジック機能機能機能データアクセスサービス機能データアクセスサービス機能データアクセスサービス機能データアクセス疎結合

Slide 29

Slide 29 text

マイクロサービス化の流れモノリシックとマイクロサービスディスパッチャープレゼンテーションビジネスロジック機能機能機能データアクセスサービス機能データアクセスサービス機能データアクセスサービス機能データアクセス疎結合マイクロサービス化することが必ずしも正義ではない ※結構大変：どの単位で分割するのただし、モノリシックなロジックを分割しリリースのリスクを最小化する意識は必要

Slide 30

Slide 30 text

サービスを更新できないことが致命的モノリシックを分割する理由変更による影響範囲がわからないアプリケーションに変更を加える人が増えれば増えるほど、影響範囲が拡大していく。メンバーの学習コスト増加新しいメンバーがそのアプリケーションを理解すること自体に時間や知識を要する。スケールにコストがかかる急なアクセス増加や、に対応するためには、まずはスケールアップが必要。テストが複雑化していくテストする対象範囲も大きいため、時間やテスト内容がわからない。

Slide 31

Slide 31 text

アプリケーションをクラウドに移行するアプローチアプリケーションモダナイゼーション・既存アプリのコンテナ化・コンテナ基盤にデプロイ・既存システムと外部統合を実施、データ連携を維持する・既存アプリはそのまま・新しいアプリをコンテナ基盤にデプロイ・新しいアプリと既存アプリをを通して連携・完全に既存アプリのロジックを置き換える・新しいインターフェイスとデータ構造をデザイン・ほとんどの機能を見直す

Slide 32

Slide 32 text

既存サービスのクラウド移行アプリマイグレーション Application Database Load Balancer KVS ロジックを分割する前にとりあえずクラウドに移行する

Slide 33

Slide 33 text

アプリマイグレーション Application Database Load Balancer KVS Database 接続

Slide 34

Slide 34 text

アプリマイグレーション Application Database Load Balancer KVS Database Application サービスの％を向けて確認

Slide 35

Slide 35 text

アプリマイグレーション Application Database Load Balancer KVS Database Application サービスの接続先を切り替える Load Balancer は接続元を参照

Slide 36

Slide 36 text

アプリマイグレーション Application Database Load Balancer KVS Database Application を最後に切り替える Load Balancer KVS

Slide 37

Slide 37 text

アプリマイグレーション Application Database Load Balancer KVS Database を最後に切り替える Load Balancer KVS

Slide 38

Slide 38 text

アプリマイグレーション Application Database Load Balancer KVS Database を最後に切り替える Load Balancer KVS ここまでは、ただのクラウド移行。サービスメッシュを活用し、サービス間を管理する。「完璧なリリース」「アクセスに応じたデプロイ」どこでも同じリリース方式

Slide 39

Slide 39 text

サービスの疎結合と独立性を徹底するサービスメッシュの利点サービス切り替えの迅速化と容易化日常業務におけるサービスリリース作業からの解放予測可能で経済的な価格設定によるコスト削減言語にとらわれず、サービスリリース機能そのものの拡張継続的な監視でビジネスを保護サービスメッシュはリリースにおける運用リスクを回避

Slide 40

Slide 40 text

サービスメッシュを展開する・などが共同して作成したサービスメッシュ・環境非依存で、に限らず、どのプラットフォームでも利用できる。パターンでデプロイするため、コード変更なくどの環境においても、サービスメッシュ機能が追加できる。

Slide 41

Slide 41 text

【参照】サービスメッシュの仕組み出典 Service Mesh vs API Gateway

Slide 42

Slide 42 text

【参照】サービスメッシュの可視化

Slide 43

Slide 43 text

クラウドネイティブを実現するための意識改革を紐解いていくクラウドネイティブな設計迅速かつリスクの少ないアプリデプロイ柔軟かつ効率的なシステム運用信頼性を維持する運用体制サービス間の接続を、レスポンスに応じて動的に複雑な運用を自律化し、回復性の高いシステムに

Slide 44

Slide 44 text

信頼性を維持する運用体制

Slide 45

Slide 45 text

コンウェイの法則クラウドネイティブにあった組織編成役割と組織の再編成クラウドネイティブは意識改革であり、意識しなければクラウドネイティブなどありえない。組織の設計するシステムには ... その組織のコミュニケーション構造をそのまま反映した設計になるという制約がある

Slide 46

Slide 46 text

【参照】コンウェイの法則出典マイクロサービスとサービス・メッシュ（が求められる背景

Slide 47

Slide 47 text

サービスレベル指標例稼働率、レイテンシー、スループット、運用のシンプルさ、安定性を図るメトリクス、ユーザー満足度サービスレベル目標例稼働率、ある期間の接続エラーの平均が以下、サービスの利用数万ユーザーサービスレベル合意開発者と、ユーザーの間で決めるが満たされなかった場合のサービスレベル目標信頼性についてのサービスレベルの目標値を決める

Slide 48

Slide 48 text

チーム内でどのくらいの指標を目指すのかを共有し、それによって運用を決めるの利点開発コストと、開発スピード、品質におけるトレードオフを、チーム感で話し合うことが出来る。予めを共有することによって、達成できないサービスレベルを要求されることを回避する。サービスに不適切な、高い信頼性に応えず、ユーザーに理解してもらう。コストとスピード過剰な要求の回避期待値管理

Slide 49

Slide 49 text

チームワーク意識改革を育成する To accelerate the delivery of our customer’s innovative ideas, and create infectious enthusiasm for building applications the Red Hat Way, by leveraging community-powered innovation to deliver an outstanding labs experience.

Slide 50

Slide 50 text

組織とプロセスの意識改革をして、運用体制を整えるクラウドネイティブな運用体制を創る

Slide 51

Slide 51 text

まとめ

Slide 52

Slide 52 text

クラウドネイティブは、意識改革であり、プロセスを改善しなければ始まらない。クラウドネイティブな設計迅速かつリスクの少ないアプリデプロイ柔軟かつ効率的なシステム運用信頼性を維持する運用体制サービス間の接続を、レスポンスに応じて動的に複雑な運用を自律化し、回復性の高いシステムに

Slide 53

Slide 53 text

コード開発ビジネス価値創出に集中し、非効率な運用を回避すること

Slide 54

Slide 54 text

開催決定！東京｜11月8日（木）ウエスティンホテル東京〒153-8580 東京都目黒区三田1-4-1 本年度は大阪での開催も予定しております。大阪｜12月12日（水）ヒルトン大阪皆さまのご参加をお待ちしております。

Slide 55

Slide 55 text

No content