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

”Developers Summit 2018 KANSAI”で発表した資料です。
https://event.shoeisha.jp/devsumi/20180928

Transcript

1. クラウドネイティブなアーキテクチャを設計する 次世代の現場力 【 】
3. クラウドネイティブなアーキテクチャを設計する次世代の現場力 クラウドネイティブへの期待 柔軟かつ効率的なシステム運用 迅速かつリスクの少ないアプリデプロイ 信頼性を維持する運用体制
4. クラウドネイティブへの期待
5. クラウドリソースを意識することなく活用できること クラウドネイティブとは コード開発 ビジネス価値創出 に集中し、非効率な運用を回避すること。
6. クラウドサービスを利用している企業の割合は 年から大幅に上昇 クラウド利用の状況 出典 総務省「通信利用動向調査」 クラウド上でアプリケーションを動かすのは当たり前
7. の役割はクラウドの抽象化だけでなく、リソースマネージメントを行う はクラウドの アプリケーションプロセス アプリケーションコンテナ システムコール プロセス 管理 メモリ 管理 デバイス管理 プロセス 間通信 割り込み 管理 コンテナ スケジューリング メモリ 管理 デバイス管理 コンテナ 負荷分散 コンテナ 死活監視 アプリケーションは が提供する機能を前提として開発される アプリケーションはクラウドが提供する機能を前提として開発される
8. クラウド上でアプリケーションを構成するためのコンセプト クラウドネイティブアプリケーション クラウド特性を活かして、スピード、柔軟性、品質を向上させ、 リリースへのリスクを削減するために設計されたアプリケーション。 “ ” Kubernetesを利用することや、アプリをマイクロサービス化することではない!! 業務が期待するスピードと品質のアプリをどの環境でも展開できる設計コンセプト
9. によるクラウドの定義 クラウド特性とは オンデマンド・セルフサービス 幅広いネットワークアクセス リソースの共有 スピーディな拡張性 サービスが計測可能であること 出典 従来の経営資源を 有効活用したい 環境の変化に 柔軟に対応できる 内製化を行いたい 事業継続性の 強化を図りたい 経営課題
10. クラウドネイティブは意識改革であり、意識しなければクラウドネイティブなどありえない。 クラウドネイティブを阻害する要因 ただクラウド技術を使っているだけ 仮想マシンやストレージの払い出しとして使っているだけであり、従来のリソース調達と変わらない。 クラウド特性を設計や運用に反映してない クラウド特性を理解しないまま、各クラウドの機能に対してオンプレでできる自由さ 属人化 と比較する。 クラウドでは変更することを前提としているにもかかわらず、塩漬け運用からの差分を補おうとする。 役割とプロセスが変わる 機能と非機能の双方をアプリ開発者とインフラ運用者でそれぞれ考えており、役割が従来と変わっていない。 コード化による自動化 クラウドを利用しているにもかかわらず、手作業プロセスから離れられないため、 属人化の増加や人手不足を招いている。
11. システムを変えることよりも、意識を変えることのほうが必要な現場 アーキテクトが直面する現実 オンプレと同じよう な構成を取りたい けれど、対応する機 能がクラウドにない。 今の体制では、人 手不足でアプリケー ションの回収などで きない。 運用を動的にした ら、ブラックボックス 化して障害時に誰 も対応できない。 外部に開発運用を 任せているから、あ まり内部を知らなく てもなんとかなる。
12. クラウドネイティブを実現するための意識改革を紐解いていく クラウドネイティブな設計 迅速かつリスクの少ない アプリデプロイ 柔軟かつ効率的な システム運用 信頼性を 維持する 運用体制
13. 柔軟かつ効率的なシステム運用
14. コンテナは仮想化の延長ではない 仮想化とコンテナ Infrastructure Hypervisor OS App Infrastructure OS Container Engine Lib OS App Lib App Lib App Lib アプリケーション の起動に アプリケーション の起動に の起動 プロセスの起動
15. 【参考】 出典 Kubernetes Introduction for VMware Users https://blogs.vmware.com/cloudnative/2017/10/25/kubernetes-introduction-vmware-users/
16. 仮想化とコンテナの違いは もぅいいんじゃないか。
17. コンテナは仮想化の延長ではない 仮想化とコンテナ Infrastructure Hypervisor OS App Infrastructure OS Container Engine Lib OS App Lib App Lib App Lib だけだと、 クラウドネイティブが分かりずらい 「結局、 とコンテナが起動する速さの違い？」 ということで。少し違う視点で見てみる
18. クラウドネイティブにおける柔軟なリソース配置 仮想化とコンテナ OS App Lib App Lib App Lib 専用の 仮想マシン OS App Lib 専用の仮 想マシンイメージ 標準化された コンテナイメージ 移行するためには コンバーターが必要 どこでも移行可能
19. クラウドネイティブを実現するためのツールも、利用対象によって意味合いが異なる クラウドロックインからの開放 ・ベンダーロックイン ・自由な の選択 レイヤの依存により、各ベンダーごとに仮想 マシンの作成方法が変わる。その分、どの でも利用 できるため、設定の自由度が高い。 ・ベンダーロックインの開放 ・ の依存 コンテナエンジン を利用することによって、アプリ ケーションそのものをどこでも実行することができる。ただ し、 が限定されるため、 などには専用 が必要。 ベンダーごとに異なる設定や、個別のカスタマ イズを重視した設定をコードに反映することで、 クラウドネイティに必要な柔軟性やスピード、 品質に対応する。 ベンダーロックインを避けるコンテナの特性を活 かし、オーケストレーションの機能によって、クラ ウドネイティブが必要とするスピードと品質に対 応する。
20. カスタム運用の回避と回復性の高い設計が重要。 クラウドネイティブなシステム運用 正常稼働 障害検知 状態確認 復旧作業 正常確認 正常稼働 障害検知 動的復旧 手作業 不具合修正 再構築 正常確認 自己修復 自動作業 個別対応 クラウドネイティブな運用 ・各ベンダーの運用作業を統一 ・カスタム運用を極小化 クラウドネイティブな運用 ・自動修復 ・動的リソース調整
21. カスタム運用の回避と回復性の高い設計が重要。 クラウドネイティブなシステム運用 正常稼働 障害検知 状態確認 復旧作業 正常確認 正常稼働 障害検知 動的復旧 手作業 不具合修正 再構築 正常確認 自己修復 自動作業 個別対応 クラウドネイティブな運用 ・各ベンダーの運用作業を統一 ・カスタム運用を極小化 クラウドネイティブな運用 ・自動修復 ・動的リソース調整 複雑な運用に関しては、 で解決。 マネージドサービス を活用 カスタム運用そのものを 極小化する一歩へ。 「自動化」 「自律化」
22. カスタム運用を減らすことで得られる効果 マネージドサービスの利点 実証済みのソリュー ションによる、導入の 迅速化と容易化 日常業務における リソース運用 からの解放 予測可能で経済的 な価格設定による コスト削減 迅速かつ 費用対効果の高い 拡張 継続的な監視で ビジネスを保護 マネージドサービスは運用ノウハウをサービス化したもの。 自律化されたシステムを利用。
23. が、より自社の運用にあったものを選択 マネージドサービスに求められること プロセスの観察 プロセス状態の判断 プロセス復旧作業 アプリケーションの現在の状態を判断する。 例 アプリケーションの現在の状態とアプリケーションの予想される状態を比較する。 例 アプリケーションの実行状態を期待状態に一致させるための処理を実行します。 例
24. マネージドサービスも創る時代 マネージドサービスを展開する ・ 年からコンセプトとして導入された機能 ・ 環境を監視し、現在のアプリの状態を使用して、コンテナ運用を行う拡張機能 は人間の運用知識をソフトウェアで表した もので、アプリケーションの信頼性を管理する。
25. 【参考】 出典 Comparing Kubernetes Operator Pattern with alternatives
26. クラウドネイティブを実現するための意識改革を紐解いていく クラウドネイティブな設計 迅速かつリスクの少ない アプリデプロイ 柔軟かつ効率的な システム運用 信頼性を 維持する 運用体制 複雑な運用を自律化し、回復性の高いシステムに
27. 迅速かつリスクの少ないアプリデプロイ
28. 多くのアプリケーションはモノリシック。その一方で、マイクロサービス化の流れ モノリシックとマイクロサービス ディスパッチャー プレゼンテーション ビジネスロジック 機能 機能 機能 データアクセス サービス 機能 データアクセス サービス 機能 データアクセス サービス 機能 データアクセス 疎結合
29. マイクロサービス化の流れ モノリシックとマイクロサービス ディスパッチャー プレゼンテーション ビジネスロジック 機能 機能 機能 データアクセス サービス 機能 データアクセス サービス 機能 データアクセス サービス 機能 データアクセス 疎結合 マイクロサービス化することが 必ずしも正義ではない ※結構大変：どの単位で分割するの ただし、モノリシックなロジックを分割し リリースのリスクを最小化する意識は必要
30. サービスを更新できないことが致命的 モノリシックを分割する理由 変更による影響範囲がわからない アプリケーションに変更を加える人が増えれば増えるほど、影響範囲が拡大していく。 メンバーの学習コスト増加 新しいメンバーがそのアプリケーションを理解すること自体に時間や知識を要する。 スケールにコストがかかる 急なアクセス増加や、 に対応するためには、まずはスケールアップが必要。 テストが複雑化していく テストする対象範囲も大きいため、時間やテスト内容がわからない。
31. アプリケーションをクラウドに移行するアプローチ アプリケーションモダナイゼーション ・既存アプリのコンテナ化 ・コンテナ基盤にデプロイ ・既存システムと外部統合を 実施、データ連携を維持する ・既存アプリはそのまま ・新しいアプリをコンテナ基盤に デプロイ ・新しいアプリと既存アプリを を通して連携 ・完全に既存アプリのロジック を置き換える ・新しいインターフェイスとデー タ構造をデザイン ・ほとんどの機能を見直す
32. 既存サービスのクラウド移行 アプリマイグレーション Application Database Load Balancer KVS ロジックを分割する前に とりあえずクラウドに移行する
33. アプリマイグレーション Application Database Load Balancer KVS Database 接続
34. アプリマイグレーション Application Database Load Balancer KVS Database Application サービスの ％を向けて確認
35. アプリマイグレーション Application Database Load Balancer KVS Database Application サービスの接続先 を切り替える Load Balancer は接続元を参照
36. アプリマイグレーション Application Database Load Balancer KVS Database Application を最後に切り替える Load Balancer KVS
37. アプリマイグレーション Application Database Load Balancer KVS Database を最後に切り替える Load Balancer KVS
38. アプリマイグレーション Application Database Load Balancer KVS Database を最後に切り替える Load Balancer KVS ここまでは、ただのクラウド移行。 サービスメッシュ を活用し、 サービス間を管理する。 「完璧なリリース」 「アクセスに応じたデプロイ」 どこでも同じリリース方式
39. サービスの疎結合と独立性を徹底する サービスメッシュの利点 サービス切り替えの 迅速化と容易化 日常業務における サービスリリース作業 からの解放 予測可能で経済的 な価格設定による コスト削減 言語にとらわれず、 サービスリリース機能 そのものの拡張 継続的な監視で ビジネスを保護 サービスメッシュはリリースにおける運用リスクを回避
40. サービスメッシュを展開する ・ などが共同して作成したサービスメッシュ ・環境非依存で、 に限らず、どのプラットフォームでも利用できる。 パターンでデプロイするため、 コード変更なくどの環境においても、 サービスメッシュ機能が追加できる。
41. 【参照】サービスメッシュの仕組み 出典 Service Mesh vs API Gateway
42. 【参照】サービスメッシュの可視化
43. クラウドネイティブを実現するための意識改革を紐解いていく クラウドネイティブな設計 迅速かつリスクの少ない アプリデプロイ 柔軟かつ効率的な システム運用 信頼性を 維持する 運用体制 サービス間の接続を、レスポンスに応じて動的に 複雑な運用を自律化し、回復性の高いシステムに
44. 信頼性を維持する運用体制
45. コンウェイの法則 クラウドネイティブにあった組織編成 役割と組織の再編成 クラウドネイティブは意識改革であり、意識し なければクラウドネイティブなどありえない。 組織の設計するシステムには ... その組織のコミュニケーション構造をそのまま反映した設計になるという制約がある
46. 【参照】コンウェイの法則 出典 マイクロサービスとサービス・メッシュ（ が求められる背景
47. サービスレベル指標 例 稼働率、レイテンシー、スループット、運用のシンプルさ、安定性を図るメトリクス、ユーザー満足度 サービスレベル目標 例 稼働率 、ある期間の接続エラーの平均が 以下、サービスの利用数 万ユーザー サービスレベル合意 開発者と 、ユーザーの間で決める が満たされなかった場合の サービスレベル目標 信頼性についてのサービスレベルの目標値を決める
48. チーム内でどのくらいの指標を目指すのかを共有し、それによって運用を決める の利点 開発コストと、開発スピード、品 質におけるトレードオフを、チーム 感で話し合うことが出来る。 予め を共有することによって、 達成できないサービスレベルを要 求されることを回避する。 サービスに不適切な、高い信頼 性に応えず、ユーザーに理解して もらう。 コストとスピード 過剰な要求の回避 期待値管理
49. チームワーク 意識改革 を育成する 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.
50. 組織とプロセスの意識改革をして、運用体制を整える クラウドネイティブな運用体制を創る
51. まとめ
52. クラウドネイティブは、意識改革であり、プロセスを改善しなければ始まらない。 クラウドネイティブな設計 迅速かつリスクの少ない アプリデプロイ 柔軟かつ効率的な システム運用 信頼性を 維持する 運用体制 サービス間の接続を、レスポンスに応じて動的に 複雑な運用を自律化し、回復性の高いシステムに
53. コード開発 ビジネス価値創出 に集中し、 非効率な運用を回避すること
54. 開催決定！ 東京｜11月8日（木） ウエスティンホテル東京 〒153-8580 東京都目黒区三田1-4-1 本年度は大阪での開催も予定しております。 大阪｜12月12日（水）ヒルトン大阪 皆さまのご参加をお待ちしております。