Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

クラウドネイティブトランスフォーメーションのススメ

509 Aufrufe

Veröffentlicht am

2019/10/9 に開催したマイナビセミナー「クラウドネイティブトランスフォーメーションのススメ」の資料です。

開催概要:https://news.mynavi.jp/itsearch/seminar/335

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

クラウドネイティブトランスフォーメーションのススメ

  1. 1. クラウドネイティブ トランスフォーメーションのススメ 株式会社ZOZOテクノロジーズ Chief ZOZOTOWN Architect 岡 大勝 マイナビセミナー 2019.10.9
  2. 2. 株式会社ZOZOテクノロジーズ Chief ZOZOTOWN Architect 岡 大勝 NoOps Japan 主催 アーキテクト(設計屋) @okahiromasa 2
  3. 3. 3 クラウドネイティブって何?
  4. 4. 4 CNCF Cloud Native Definition v1.0 クラウドネイティブ技術は、パブリッククラウド、プライベートクラ ウド、ハイブリッドクラウドなどのモダンで動的な環境において、スケ ーラブルなアプリケーションを構築および実行するための能力を組織に もたらします。 このアプローチの代表例に、コンテナ、サービスメッシ ュ、マイクロサービス、イミュータブルインフラストラクチャ、および 宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合 システムが実現します。 これらを堅牢な自動化と組み合わせることで、 エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どお りに行うことができます。 https://github.com/cncf/toc/blob/master/DEFINITION.md
  5. 5. クラウドネイティブ技術は、パブリッククラウド、プライベートクラ ウド、ハイブリッドクラウドなどのモダンで動的な環境において、スケ ーラブルなアプリケーションを構築および実行するための能力を組織に もたらします。 このアプローチの代表例に、コンテナ、サービスメッシ ュ、マイクロサービス、イミュータブルインフラストラクチャ、および 宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合 システムが実現します。 これらを堅牢な自動化と組み合わせることで、 エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どお りに行うことができます。 5 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/master/DEFINITION.md スケーラブルな アプリケーション モダンで動的な環境 =クラウドプラットフォーム 疎結合システム 自動化 影響の大きな変更も、最小限の労力で 頻繁かつ予測どおりに行う
  6. 6. 6 クラウドネイティブの目指す姿 影響の大きな変更も、最小限の労力で 頻繁かつ予測どおりに行う
  7. 7. 7 クラウドネイティブの目指す姿 影響の大きな変更も、最小限の労力で 頻繁かつ予測どおりに行う リリース 障害対応 ダウンタイム 夜間待機 コスト 監視 性能低下
  8. 8. 8 クラウドネイティブの目指す姿 影響の大きな変更も、最小限の労力で 頻繁かつ予測どおりに行う リリース 障害対応 ダウンタイム 夜間待機 コスト 監視 性能低下 不安のない日常を 手に入れる
  9. 9. 9 クラウドネイティブの目指す姿 影響の大きな変更も、最小限の労力で 頻繁かつ予測どおりに行う 嬉しくない運用をなくしたい No Uncomfortable Ops https://noops.connpass.com/ NoOps Japan Community
  10. 10. 10 嬉しくない運用をなくしたい 1.ユーザーの体験を妨げないシステム運用保守の実現 障害時のダウン、計画停止、負荷集中時の性能低下、etc.. 2.システム運用保守で発生する「トイル」の最小化 リリース手続き、パッチの適用、リソース監視、待機、etc.. 3.システム運用保守コストの最適化 余剰資源を持たない、適正品質、時間外勤務、人材活用、etc..
  11. 11. 11 嬉しくない運用をなくしたい 1.ユーザーの体験を妨げないシステム運用保守の実 現 障害時のダウン、計画停止、負荷集中時の性能低下、etc.. 3.システム運用保守で発生する「トイル」の最小化 リリース手続き、パッチの適用、リソース監視、待機、etc.. 3.システム運用保守コストの最適化 余剰資源を持たない、適正品質、時間外勤務、人材活用、etc.. もし、これら全てを クラウドネイティブが解決するなら...?
  12. 12. 12 そりゃできれば最高だけど、どうやって? 「… このアプローチの代表例に、コンテナ、サービスメッシュ、 マイクロサービス、イミュータブルインフラストラクチャ、 および宣言型APIがあります。…」 ?????
  13. 13. 13 視点を変える
  14. 14. 14 Q. これは何をしているところ?
  15. 15. 15 A. 1956年、IBM から世界初のハードディスク(5MB)が出荷。 https://nextshark.com/ibm-5mb-hard-drive/
  16. 16. 16 コンピュータは物理的な存在(だった)
  17. 17. 17 https://images.app.goo.gl/yyfzJTvFMi4Y7vb79 IBM 7094 / 1970 京 / 2012 https://blog.global.fujitsu.com/jp/2019-06-18/01/
  18. 18. 18 設計すべき非機能要求 ● 性能 ● 信頼性 ● セキュリティ ● 互換性 ● 運用性 ● 保守性 ● コスト
  19. 19. 19 設計すべき非機能要求 ● 性能 ● 信頼性 ● セキュリティ ● 互換性 ● 運用性 ● 保守性 ● コスト 非機能要求は、 初期のアーキテクチャ設計に よってシステムに実装される
  20. 20. 20 これまで我々は、 物理的な制約を前提に設計してきた ● 処理速度 ● メモリサイズ ● 記憶装置のサイズ ● 転送速度 ● 筐体サイズ ● 電源容量 ● 重量 =物理ネイティブな設計
  21. 21. 21 クラウドネイティブとは、 「物理的制約が存在しない世界」と仮定する ところから始める ”無限のコンピューティングリソースを瞬時に調達できる” なら、どう設計するのか = クラウドネイティブな設計
  22. 22. 22 クラウドネイティブな設計を知る
  23. 23. 変動するトラフィック • キャンペーンのWebトラフィック • 新商品発売日のアクセス集中 • 証券取引の手数料計算バッチ処理 • ポイント付与・キャッシュバック
  24. 24. サイジングの悩ましさ コストを考えると 平常時でサイジングしたい ピーク
  25. 25. サイジングの悩ましさ ピーク時への対処は? ユーザーに我慢してもらう? ピーク
  26. 26. サイジングの悩ましさ コストはかかるが、 ピーク時までカバーしたい ピーク
  27. 27. サイジングの悩ましさ 未使用リソースの コストは許容できる? ピーク
  28. 28. サイジングの悩ましさ 想定ピークを 超える可能性は? ピーク
  29. 29. 29 サイジングの悩ましさ 冗長構成で リソース2倍 ピーク
  30. 30. 30 サイジングの悩ましさ 冗長構成で リソース2倍 リソースの大部分を 遊ばせている
  31. 31. 31 クラウドネイティブな設計手順 1.クラウドネイティブな発想で理想形を描く ■ 物理制約を忘れる ■ 意識するのは「データ量」と「伝達遅延」のみ 2.理論的な解決策を割り当てる ■ 分散、キューイング、リトライなどの解決策を組み合わせて設計する ■ 全て「メモリ上でのソフトウェア処理」と仮定すると組みやすい 3.実際に利用可能な技術を適合させる ■ クラウド上のミドルウェア等を組み合わせる ■ ここでの妥協を最小化することが重要
  32. 32. クラウドネイティブな発想 ① 処理量に応じた適切なリソースを割り当てたい
  33. 33. クラウドネイティブな発想 ダウンタイム 数秒以内で回復 ② 落ちてもすぐに回復してほしい
  34. 34. 物理ネイティブなバッチ処理のシステム構成 ① 処理データの リクエスト ③計算処理を100万回ループ Databas e 仮想マシン 想定される嬉しくない運用 • 事前に適切なサイジングができない • 処理途中でアプリが落ちた時の復旧 • 処理時間が長くなりすぎる可能性 • etc.. ④ 処理結果の書き込み ② 100万件のデータ
  35. 35. 設計で回復性を持たせる ① 処理データの リクエスト ③ 100万件の個別処理に分 離 Databas e Serverless ② 100万件のデータ ⑥ 処理結果の書き込み ④ Jobを1件ずつキューに投入 ⑤(可能であれば) Jobの並列実行 Serverless Firm • MWで処理状況がモニター可能 • 失敗したJobのみ再実行可能 • キュー障害時は新たなキューを作成し処理続行 (障害キューは解析用に保持) • Serverlessはバッチ特有の不具合が発生しづらい (メモリリーク、連鎖障害) クラウドネイティブなバッチ処理のシステム構成 データストアも スケールできると ボトルネックがなくなる
  36. 36. クラウドネイティブ技術は、パブリッククラウド、プライベートクラ ウド、ハイブリッドクラウドなどのモダンで動的な環境において、スケ ーラブルなアプリケーションを構築および実行するための能力を組織に もたらします。 このアプローチの代表例に、コンテナ、サービスメッシ ュ、マイクロサービス、イミュータブルインフラストラクチャ、および 宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合 システムが実現します。 これらを堅牢な自動化と組み合わせることで、 エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どお りに行うことができます。 36 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/master/DEFINITION.md スケーラブルな アプリケーション モダンで動的な環境 =クラウドプラットフォーム 疎結合システム 自動化 影響の大きな変更も、最小限の労力で 頻繁かつ予測どおりに行う
  37. 37. クラウドネイティブ技術は、パブリッククラウド、プライベートクラ ウド、ハイブリッドクラウドなどのモダンで動的な環境において、スケ ーラブルなアプリケーションを構築および実行するための能力を組織に もたらします。 このアプローチの代表例に、コンテナ、サービスメッシ ュ、マイクロサービス、イミュータブルインフラストラクチャ、および 宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合 システムが実現します。 これらを堅牢な自動化と組み合わせることで、 エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どお りに行うことができます。 37 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/master/DEFINITION.md スケーラブルな アプリケーション モダンで動的な環境 =クラウドプラットフォーム 疎結合システム 自動化 影響の大きな変更も、最小限の労力で 頻繁かつ予測どおりに行う
  38. 38. 38 クラウドネイティブな設計のヒント ● 12Factor App ■ 依存関係を明示的に宣言し分離する ■ アプリケーションをステートレスなプロセスとして実行する ■ プロセスモデルによってスケールアウトする ■ 高速な起動とグレースフルシャットダウンで堅牢性を最大化する ■ ... ● CNCF Cloud Native Definition ■ コンテナ ■ サービスメッシュ ■ イミュータブルインフラストラクチャ ■ 宣言型API ■ 回復性、管理性、可観測性 https://12factor.net/ja/ http://kimitok.hateblo.jp/entry/2014/11/09/211820 https://github.com/cncf/toc/blob/master/DEFINITION.md
  39. 39. 39 CNCF Cloud Native Definition アプリケーションをステートレスな プロセスとして実行する イミュータブルインフラストラクチャ プロセスモデルによって スケールアウトする コンテナ サービスメッシュ 12Factor App と Cloud Native Definition は表裏 一体
  40. 40. クラウドネイティブ技術は、パブリッククラウド、プライベートクラ ウド、ハイブリッドクラウドなどのモダンで動的な環境において、スケ ーラブルなアプリケーションを構築および実行するための能力を組織に もたらします。 このアプローチの代表例に、コンテナ、サービスメッシ ュ、マイクロサービス、イミュータブルインフラストラクチャ、および 宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合 システムが実現します。 これらを堅牢な自動化と組み合わせることで、 エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どお りに行うことができます。 40 CNCF Cloud Native Definition v1.0 https://github.com/cncf/toc/blob/master/DEFINITIO N.md スケーラブルな アプリケーション モダンで動的な環境 =クラウドプラットフォーム 疎結合システム 自動化 影響の大きな変更も、最小限の労力で 頻繁かつ予測どおりに行う
  41. 41. 41 これまでの自動化 ● 繰り返し作業の自動化 ○ バッチ処理 ○ 運用作業(ローテーションなど) ○ ビルド・テスト・デプロイ(CI/CD) ● 状態の変化を自動で検知・通知 ○ しきい値の監視・通知 ○ ログの記録 ○ クラスタフェールオーバー
  42. 42. 42 クラウドネイティブでの自動化 ● システム構成の動的な変化 ○ トラフィック量に応じたリソース増減 ○ 障害検知による自律的回復 ○ 最適な環境へのデプロイ/ルーティング ● 予測からカオスエンジニアリングへ ○ 予測:過去から推測。処理量/故障率 ○ カオス:不確実性。Fault Injection/Tuning
  43. 43. 43 可観測性 = Observability ・システムを運用する上で必要な情報を提供できる能力 ・取得手段は様々(モニタリング、ロギング、トレーシング...)
  44. 44. 44 クラウドネイティブの落とし穴 1.Kubernetesを使ってもすぐにはリソース最適化 とはならない(ことが多い) 2.VPC(Virtual Private Cloud) を使うと一般的に 弾力性が損なわれる 3.リザーブドインスタンス(サーバ資源の長期契約) は、クラウドネイティブの敵
  45. 45. 弾力性とコスト: VMのスケール • スケール完了まで10分程度要するため、スパイクの事前にScale-outしておく必要がある。 スパイク前に Scale-out 落ち着いたら Scale-in VMへの課金
  46. 46. 弾力性とコスト: クラウドのKubernetesサービス • Kubernetesのスケールは数秒~数十秒程度だが、動作基盤のノード(VM)はやはり事前に Scale up/outしておく必要がある。 スパイク前に VMのScale up/out 落ち着いたらVMSSを Scale down/in 課金はVMに Kubernetesは 弾力性が高いが..
  47. 47. 弾力性とコスト: PaaS/Serverless • App EngineやApp Serviceでは数秒単位でスケール可能のため、 より細かな負荷への適応が可能。 • インスタンス利用時間に対する課金のため、 理想とするリソース:コスト体系に近い。 割り当て時間に課金 細かなメッシュで 負荷に追従 Azure App Service
  48. 48. 48 クラウドネイティブの落とし穴 1.Kubernetesを使ってもすぐにはリソース最適化 とはならない(ことが多い) 2.VPC(Virtual Private Cloud) を使うと一般的に 弾力性が損なわれる 3.リザーブドインスタンス(サーバ資源の長期契約) は、クラウドネイティブの敵
  49. 49. “Cold Pool” • コントローラブルでセキュア、でも … Server HW Hypervisor VM App Container App Deploy Ready-to-go-Infrastructure Provision/Boot Install/Configure VNet/Virtual Private Cloud いつでもセルフプロビジョニング できるリソースプール
  50. 50. “Hot Pool” • “several pools of Workers pre-provisionedand ready to hostyour applications” • “allocated from a pool of ready-to-goWorkers” https://msdn.microsoft.com/en-us/magazine/mt793270 Server HW Hypervisor VM App Container App Deploy Pre-provisioned/readyto host どのノードもいつでもデプロイできるように ”暖めてある”リソースプール
  51. 51. 51 クラウドネイティブの落とし穴 1.Kubernetesを使ってもすぐにはリソース最適化 とはならない(ことが多い) 2.VPC(Virtual Private Cloud) を使うと一般的に 弾力性が損なわれる 3.リザーブドインスタンス(サーバ資源の長期契 約)は、クラウドネイティブの敵
  52. 52. 52 クラウドネイティブの落とし穴 1.Kubernetesを使ってもすぐにはリソース最適化 とはならない(ことが多い) 2.VPC(Virtual Private Cloud) を使うと一般的に 弾力性が損なわれる 3.リザーブドインスタンス(サーバ資源の長期契 約)は、クラウドネイティブの敵 思想と矛盾する
  53. 53. 53 クラウドネイティブな旅の供(製品)の選び方 クラウドネイティブ の理想の姿 製品A 物理ネイティブの 有名な事例 製品C 製品B 製品 D 製品E
  54. 54. 54 クラウドネイティブな旅の供(製品)の選び方 クラウドネイティブ の理想の姿 製品A 物理ネイティブの 有名な事例 製品C 製品B 製品 D 製品E
  55. 55. 55 クラウドネイティブな旅の供(製品)の選び方 クラウドネイティブ の理想の姿 製品A 物理ネイティブの 有名な事例 製品C 製品B 製品 D 製品E ● 目の前の事例に惑わされず、目指す方向性が同じ製品を選ぶ ● 機能ではなく非機能に着目する(特に回復性、スケール性) ● オープンなアプローチを取っている(OSS、ドキュメント公開) ● ユーザーと共に未来に向けて歩もうとしている組織とともに
  56. 56. 56 クラウドネイティブへ向かう旅は、 知的な刺激に満ちあふれています。 一緒に楽しみましょう。 Have Fun!!

×