Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Webアプリ開発向け ゆるふわDocker使いが Cloud Naive開発に必要なetc.

2,326 views

Published on

Cloud Native Kansai #02
https://cnjp.connpass.com/event/117651/

Published in: Technology
  • Be the first to comment

Webアプリ開発向け ゆるふわDocker使いが Cloud Naive開発に必要なetc.

  1. 1. Webアプリ開発向け ゆるふわDocker使いが Cloud Naive開発に必要なetc. Cloud Native JP Kansai #02 やっさん @yassan168
  2. 2. はじめに dockerやKubernetes(以下k8s)自身の話は、 ほぼしません(期待してたらスミマセン)。 k8sをベースとしたCloud Native(以下、CN)な開発に 必要な取っ掛かりについて話します。
  3. 3. はじめに k8sとかdockerについては、以下の本がオススメです。 また、引用元は、スライド最後にまとめています。
  4. 4. 想定している人 以下な開発者 • docker-composeを何となく使った事がある • k8sとかCNな開発にピンと来ない • それ美味しいの?
  5. 5. ゴール お持ち帰り出来そうな事 • CNな開発やその効果 • そもそも必要なのかの判断材料 • どっから始めてどうやって実現したら良いのか?
  6. 6. 流れ • Twelve-Factor Appのおさらい • Cloud Native技術がもたらすもの • Cloud Nativeな設計について • どうやって始めていくか
  7. 7. Twelve-Factor Appのおさらい 1. コードベース バージョン管理されている1つのコードベースと複数のデプロイ 2. 依存関係 依存関係を明示的に宣言し分離する 3. 設定 設定を環境変数に格納する 4. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う 5. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する 6. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとし て実行する 7. ポートバインディング ポートバインディングを通してサービスを公開する 8. 並行性 プロセスモデルによってスケールアウトする 9. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する 10. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ 11. ログ ログをイベントストリームとして扱う 12. 管理プロセス 管理タスクを1回限りのプロセスとして実行する CN開発の根底にある Twelve-Factor App とは
  8. 8. Twelve-Factor Appのおさらい これらを満たすことが前提となっている(はず)。 つまり、これらから外れると途端にしんどくなる。
  9. 9. Cloud Nativeって何? クラウドネイティブ技術は、パブリッククラウド、プライベートクラウ ド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、 スケーラブルなアプリケーションを構築および実行するための能力を 組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサー ビス、イミューダブルインフラストラクチャ、および宣言型APIがありま す。 これらの手法により、回復性、管理力、および可観測性のある疎結合シス テムが実現します。 これらを堅牢な自動化と組み合わせることで、 エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおり に行うことができます。 cf. Cloud Nativeの定義 より
  10. 10. Cloud Native技術がもたらすもの 変化の激しい環境下で、 スケーラブルな開発を行うための能力を 組織にもたらす。
  11. 11. Cloud Native技術がもたらすもの 本当に必要ですか? あなたのプロダクトは頻繁に変化が求められてますか? 1日に10回20回リリースしたいですか? それが出来る or それを望む 組織ですか?
  12. 12. Cloud Native技術がもたらすもの とりあえず、k8sが流行ってるから、いっちょかみたいんで、 導入ありきで、まずは本番投入しちゃうぞ とか考えている人は 止めた方が良いです。 必要なプロダクトに必要なタイミングで導入せずに 準備不足で無理やりねじ込んで失敗してしまった場合、 本当に必要なときに導入しようとする誰かが非常に困ります。 作り逃げされた経験無いです?筋の悪いシステムで苦労してません?
  13. 13. Cloud Native技術がもたらすもの Cloud Native技術で開発を行うのは、 今まで、PerlやRubyなどで開発してた人が、 ScalaやHaskellで開発するくらいのインパクトがあります。 単純なアプリの導入ではなく、もっと根底にあるものを プロダクトだけでなく、組織ごと変えるって位の覚悟が必要です。
  14. 14. Cloud Native技術がもたらすもの その覚悟と、そして、同志(3人以上推奨)と信頼貯金ありますか? とは言え、この流れはどんどん加速するのでキャッチアップはしておき 必要なタイミングに迅速に行動に移せるようにしておいた方が無難です。 まずは、コミュニティに参加して、 ホビーとして楽しむ程度に留めておいても良いと思います。
  15. 15. Cloud Nativeにシステム構築するには? 「やっていき!」ってなっても、そもそも、今あるやつをただコンテナ化 すればOK〜♪ ってな事にならない。。。 プロダクトのコンテキストが変わるので、適している設計があります。 CNの定義として、マイクロサービスをアプローチの代表例に挙げている ことから、分散システムを目指す事になります。 では、分散システムを構築するにはどうやったら設計したら良いのか?
  16. 16. Cloud Nativeにシステム構築するには? アプリ開発者なら、夜通し話しちゃうくらい、 酒の肴にぴったりなみんな大好き設計の話になってきました。 今回は、コンテナベースの開発向けのデザインパターンとして、 Brendan Burns, David Oppenheimerらの論文 Design Patterns for Container-based Distributed Systems をご紹介。
  17. 17. Cloud Nativeな設計とは? また、これをベースとしたBrendan Burnsさんの書籍 Designing Distributed Systems は以下から無料でDL可能!。 Designing Distributed Systems E-Book | Microsoft Azure ※日本語訳は、4/19に発売予定らしいです  分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計    細かく話す時間もないので、詳しくは本を参照ください(ぁ
  18. 18. Cloud Nativeな設計とは? また、Brendan BurnsさんのGithubリポジトリ brendandburns/designing-distributed-systems-labsに、 各パターンの一部をAzureでお試し出来る手引きまであります。
  19. 19. Designing Distributed Systems • Single-Node Patterns • The Sidecar Pattern • Ambassadors • Adapters • Serving Patterns • Replicated Load-Balanced Services • Sharded Services • Scatter/Gather • Functions and Event-Driven Processing • Ownership Election • Batch Computational Patterns • Work Queue Systems • Event-Driven Batch Processing • Coordinated Batch Processing 書籍で紹介されているパターンは以下
  20. 20. Single-Node Patterns
  21. 21. Sidecar Pattern Sidecar Pattern は、共有Volumeを中継して、 Sidecarが主コンテナを補助する。 例えば、外部とSidecarが同期して 変更があれば、App側の更新をかける 利点:AppとSidecarで責務を分離    AppはAppの責務だけに集中出来る Config Manager Sidecar Cloud Config Service App 共有Volume Config File 1. 同期 3. シグナル 2. Update 4. Read
  22. 22. Ambassadors 主コンテナの代わりに通信を 肩代わりするコンテナを配置。 利点:  Appは自分の責務に集中  通信はAmbassadorに丸投げOK MySQL Service Broker Ambassador App 接続 localhost:3306 Service Brocker MySQL Service Broker Ambassador App 接続 localhost:3306 MySQL サービスへ Service Brocker MySQL インスタンス MySQL Service Broker Ambassador App 接続 localhost:3306 接続
  23. 23. コンテナグループ Adapters Ambassadorとは逆に、 コンテナグループから外部に対して メトリクスをエクスポートする。 Adapterはモニタリングのみ行う。 モニタ対象となるAppは複数種類でも良 い。 外部 Consumer Adapter App 2 外部 I/F コンテナグループ AdapterApp 外部 I/F
  24. 24. Serving Patterns
  25. 25. Replicated Load-Balanced Services LBを軸にして、 その先を縮退するよくあるやつ。 また、セッションを固定して 同じサーバにリクエストを固定させる ことも可能。 レプリカ LB レプリカ レプリカ レプリカ・・・ Scaling Down Scaling Up
  26. 26. Sharded Services レプリカじゃなくて、 シャード、つまり、分割。 分割によって均等に分散。 偏ってきた場合は、 少ないリクエストのシャードはまとめ、 リクエストの多いシャードはレプリカを作成。 Shard A LB Shard B Shard C Shard A LB Shard B Shard C Shard A LB Shard A Shard B Shard C
  27. 27. Scatter/Gather 散布(Scatter)/収集(Gather)。 リクエストをRootNodeに投げ RootNodeはLeafNodeに並列にリクエスト を送信(散布)。 LeafNodeはリクエストされた情報を RootNodeに返し、RootNodeは返ってきた 情報を収集して、レスとして返す。 Leaf Node Root Node Leaf Node doc1, doc2, doc4 doc1, doc3, doc4 doc1, doc3 犬と猫の 情報plz 猫plz 犬plz
  28. 28. Functions and Event-Driven Processing ≠ マイクロサービスアーキテクチャ Functionは、FaaS(= Decorator Function)と考えてOK(右図) ただし、FaaS≠イベント駆動型 FaaS:  リクエストに装飾しながら処理を加える イベント駆動型:  発火したイベントに合わせて、並列に処 理が発生する(例:新規ユーザのサイン アップ) Main Application Function Decorator Function Arguments Main Function User Requests Delegated requests
  29. 29. Ownership Election オーナー選出のみを専門で行うコンテナを 配置することで、アプリは自分の責務だけ を果たせば良い。 いわゆるにPaxosやRAFTのような 分散合意アルゴリズムを使った実装。 (例:etcd、ZooKeeper、consul) 可用性が高まるので自動復旧やバージョン アップなどが容易になる。 が、ライブラリを使うとかしない限り、 独自実装は非常に難しい... Master #1 レプリカ Master #2 レプリカ Master #3 レプリカ Master Election Protocol Master #1 レプリカ Master #2 レプリカ Master #3 レプリカ Master Election Protocol Master #1 レプリカ Master #2 レプリカ Master #3 レプリカ Master Election Protocol
  30. 30. Batch Computational Patterns
  31. 31. Work Queue Systems 並列に大量の処理を実行する パターン。いわゆるバッチ。 キューを作成するマネージャ が直接キューを作成せずに、 キュー出し部分はAmbassador 使って切り分けると良い。 ワーカー側は2回以上実行した り悪意のある操作をされない ようにする為に、呼び出した ら1回だけ実行して役目を終え る コンテナグループ Work Queue Source Container (Ambassador) Work Queue Manager Container 外部 Work Queue Source Workerコンテナグループ Worker Container Implementation K8s API ConfigMap Volume Work Item Data ConfigMap
  32. 32. Event-Driven Batch Processing 前述のWork Queueではなく、 右図のように入力が派生したり、 Filterされるなどして出力が作成され る、いわゆるワークフローシステム。 ただ、それをそのまま実装すると複雑に なりがちなので、Kafkaの様なPub/Sub なAPIまたはサービスを利用する方が良 い。 Copy Output to Multiple Queues Input Copier Stage #2a Stage #2b Stage #3 Copyだけじゃなく SplitterやShaderの 場合もある 途中でFilter することも
  33. 33. Coordinated Batch Processing 分割した出力を一定のルールに基づいて、 集約するパターン。 例:Map/ReduceのReduce Parallel Work Distribution Work Queue Result Aggrecation
  34. 34. どこから始めるか? Cloud Native Trail Map を 参考に段階的に始めていくと良いです。 一足飛びでk8sなんて無理です。 ダメ。絶対。 以下の記事が参考になります。 Kubernetes、コンテナ技術を活用した開 発アジリティー向上にインフラアーキテク トはどう貢献したのか
  35. 35. 開発スタイルの再検討 GitOpsなんてものも。時間も無いし前回もあったので割愛。 Kubernetesで作るコンテナベースCI★CDの夕べ / ochacafe#1 - Speaker Deck 前回にもお話ありました。 GitOpsでKubernetesのManifest管理
  36. 36. どうやって始めるか? Rancher Labsの有償サポートと言う手も。 Rancherだけでなくその周辺までサポート。 (OS/docker/k8s/etcd/flanel/canal/GKE/AKS/EKS等) 詳しい人雇ったと思えば安いし雇うのも大変なので検討の余地アリです。 Rancher Labs Support and Maintenance – Terms of Service
  37. 37. ふりかえり お持ち帰り出来そうな事 • CNな開発やその効果 • そもそも必要なのかの判断材料 →CNの概念と目指す方向性 • どっから始めてどうやって実現したら良いのか? →CNに適した設計の話とTrail Map、GitOpsの紹介
  38. 38. 関西で、Cloud Nativeな技術を盛り上げて、 ワイワイ(悩みを肴に相談する会)出来る仲間が欲しい! 一緒にやっていきませんか? 最後に
  39. 39. 資料:k8sやdocker ● Cloud Nativeの定義 ● Cloud Native Trail Map ● CNCF Cloud Native Interactive Landscape ● インフラエンジニアとしてのわたしの研究開発とこれから注目のコンテナ技術 - Speaker Deck ● 今話題のいろいろなコンテナランタイムを比較してみた :Docker Meetup Tokyo #26発表レポート ● コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう - エンジニア Hub|若手Webエンジニアのキャリアを考える! ● Docker Compose入門~今日から始めるComposeの初歩からswarm mode対応まで ● Docker Comose & Swarm mode Orchestration (Japan Container Days … ● コンテナ導入概要資料2018
  40. 40. 資料:設計関連 ● The Twelve-Factor App (日本語訳) ● Kubernetes、コンテナ技術を活用した開発アジリティー向上にインフラアーキテクトはどう貢献したのか ● 「Kubernetesで運用する」その前に Kubernetesを本番環境で利用する際のポイント ● Brendan Burns, David Oppenheimerらの論文:Design Patterns for Container-based Distributed Systems ○ その書籍:Designing Distributed Systems E-Book | Microsoft Azure ○ 実装のお試しリポジトリ:brendandburns/designing-distributed-systems-labs ○ その日本語訳版:分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計 ● コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を 読んだ - kakakakakku blog ● Web Developer も知っておきたい Kubernetes における Sidecar Pattern と Ambassador Pattern - Quipper Product Team Blog ● I will tell you the passion of Kubernetes - Speaker Deck ● コンテナ・デザイン・パターンの論文要約  - Qiita
  41. 41. 資料:k8sやdocker(書籍) ● Dockerからおさらいしたいならこれ。段階的に理解できるのでオススメ ○ Docker/Kubernetes 実践コンテナ開発入門 ● k8sからで良いならこの2冊 ○ Kubernetes完全ガイド ○ Kubernetes実践入門 プロダクションレディなコンテナ&アプリケーションの作り方
  42. 42. 資料:CNJP以外の関連コミュニティ 挙がっている資料だけでも知見の塊 ● Cloud Native Meetup Tokyo ● Cloud Native Developers JP ● Rancher JP ● Container Build Meetup ● Container SIG ● くじらや ロゴはそのうち変えます...

×