More Related Content
What's hot (20)
Similar to Fundamentals of Microservices Japanese Webinar (20)
More from NGINX, Inc. (20)
Fundamentals of Microservices Japanese Webinar
- 1. マイクロサービスの基本 ＆NGINX解説セミナー Fundamentals of Microservices F5ネットワークスジャパン合同会社 NGINX – テクニカルソリューションズアーキテクト 鈴木 孝彰
- 2. | ?2021 F5 2 本日のアジェンダ ? マイクロサービスについて ? コンテナ, Kubernetesについて ? Ingress 颁辞苍迟谤辞濒濒别谤について ? Service Mesh について ? まとめ ? Q/A
- 4. | ?2021 F5 4 NGINXによるアプリケーションモダナイズ例 NGINXの特性を生かし、 アプリ開発者はアプリの開発に注力し、セキュリティも担保できる基盤を実現する案。 APIマネジメント モニタリング 自動化 NGINX App Protect WAFモジュール サービスメッシュ 2021 HTTP/HTTPS レート/アクセス制限 軽量/高速処理 コンテンツキャッシュ 従来型アプリケーション マイクロサービス パブリッククラウド OpenShift NGINX Ingress Operator 2020 NGINX Ingress Controller 2016~
- 5. | ?2021 F5 5 NGINXによるアプリケーションモダナイズ例 NGINXの特性を生かし、 アプリ開発者はアプリの開発に注力し、セキュリティも担保できる基盤を実現する案。 APIマネジメント モニタリング 自動化 NGINX App Protect WAFモジュール サービスメッシュ 2021 HTTP/HTTPS レート/アクセス制限 軽量/高速処理 コンテンツキャッシュ 従来型アプリケーション マイクロサービス パブリッククラウド OpenShift NGINX Ingress Operator 2020 NGINX Ingress Controller 2016~
- 6. | ?2021 F5 6 あなたの組織のマイクロサービスに 関する状況を教えてください 1. マイクロサービスの情報収集をしている. 2. マイクロサービスアーキテクチャの採用を考えている. 3. マイクロサービスを本番環境に適用しようとしている. 4. マイクロサービスと従来型アーキテクチャの両方を運用しています. 5. 私たちは(ほぼ)完全にマイクロサービスを適用した組織です.
- 7. | ?2021 F5 7 造船の歴史と革命 ヨーロッパの造船 (1500年頃) 船は1つの場所と手作業で何ヶ月もかけて作られました. ギルド制度が職人を提供し技術や訓練を独占. ギルドは職人を保護し優れた品質の製品を生み出した が時間がかかり非効率であった. ブリガンティンを建造する船舶、1541年
- 8. | ?2021 F5 8 ヴェネツィア国立造船所は世界で最も強力で効率的な 造船所であった. 毎日1隻の船が建造され, 様々な仕様のガレー船 (人力でオールを漕いで進む軍艦)が100隻もストック されていた. 現在のヴェネツィア国立造船所 マイクロサービスの起源は首都ヴェネツィア
- 13. | ?2021 F5 13 従来型アプリケーション マイクロサービス
- 14. | ?2021 F5 14 従来型アプリケーション 一般 UI 画像解析 検索 課金 支払 通知 予約 管理者 UI マイクロサービス 全機能 Ruby Go Python Ruby Scala JavaScript Rust TypeScript Python 巨大な1つのアプリケーション 機能ごとに複数言語のアプリケーションで構成
- 15. | ?2021 F5 15 https://paypay.ne.jp/ 2018 2021
- 16. | ?2021 F5 16 https://paypay.ne.jp/ 2018 2021 v v v v v v v v v vc vc v v
- 17. | ?2021 F5 17 マイクロサービスアーキテクチャは アプリケーションが多くの疎結合で機能ごとに 小分けしたサービスで構成するアプローチです. ? 高いメンテナンス性とテストの容易性 ? 機能単位でのスケールアップ/ダウン ? サービスファースト、素早いアップデートが可能 ? コードがデータベースが分散されセキュア ? 様々な技術エンジニアチームで開発が可能
- 18. | ?2021 F5 18 マイクロサービスに関する 懸念事項はありますか? 1. 学習と知識 - 本番環境への適用の難しさ 2. 本番環境 - ロギング, 可視化, モニタリング 3. 本番環境 - セキュリティ 4. 本番環境 – アプリケーションや複数チーム組織のスケーリング 5. 特になし
- 19. | ?2021 F5 19 モダンアプリケーションには最新アーキテクチャが必要 FROM MONOLITHIC ... ...ダイナミックに 3層構造、J2EEスタイルのアーキテクチャ 高級言語や共通ライブラリ 持続的なデプロイメント 固定された静的インフラ 大規模な機能リリース サイロ化したチーム(開発、テスト、運用) マイクロサービス 軽量 (REST、JSON) APIコール Dockerコンテナ、Kubernetes 自動化、コード化インフラストラクチャ 継続的デリバリー 様々な言語でのDevOps カルチャー モノリシックから.. 開発効率重視のプログラミング言語を選択して開発、迅速なアップデート、自動化
- 20. | ?2021 F5 20 コンテナとは,アプリケーションに必要な最低限のものを集めて, 1つのイメージとしてパッケージ化したものです. ? 実行可能なアプリケーションコード – コンパイル済みまたはフレームワーク ? ランタイムアーティファクト – ライブラリ、ログ基盤エージェント、ログファイルなど ? ランタイム要件の宣言 – ネットワーク、ストレージなど コンテナとは? 開発 ビルド イメージ テスト デプロイ 運用 コード コンテナ 各機能を担当する開発者のラップトップからテスト/本番環境へコンテナイメージを展開できる
- 21. | ?2021 F5 21 Kubernetesは, 多数のサーバー ('ノード') を組み合わせてコンテナを実行するためのプラットフォームを作成します Kubernetesとは? Kubernetes Master API Server Scheduler Controller- Manager etcd Kubernetes Node Kubelet Kubernetes Node Kubelet Kubernetes Node Kubelet Ingress Controller Internal Network KubeProxy KubeProxy KubeProxy External Load Balancer ? BIG CIS ? NGINX ? Cloud LB Users コンテナのスケールアウト/イン、モニタリング、マルチテナント管理
- 22. | ?2021 F5 22 Kubernetesとは? Kubernetes Master API Server Scheduler Controller- Manager etcd Kubernetes Node Kubelet Kubernetes Node Kubelet Kubernetes Node Kubelet Ingress Controller Internal Network KubeProxy KubeProxy KubeProxy External Load Balancer ? BIG CIS ? NGINX ? Cloud LB Users Ingress Service Deployment Pod Pod Pod コンテナのスケールアウト/イン、モニタリング、マルチテナント管理 Ingress – 外部からのリクエストをコントロール Service – Podへのアクセスを可能にする Deployment – アプリケーションをデプロイする Pod – コンテナが動作する最小単位
- 23. | ?2021 F5 23 本番サービスを支えるKubernetes環境 開発者 運用チーム Infrastructure Dataplane Application Dataplane Application Runtime アプリケーション Code Repo CI/CDパイプライン 自動化 コンテナ ModSecurity AppProtect 認証 モニタリング ログ収集 WAF ユーザー
- 24. | ?2021 F5 24 Development Operations Infrastructure Dataplane Application Dataplane Application Runtime App Code Repo CI/CD pipeline Automation Pod ModSecurity AppProtect Auth Monitoring Logging WAF Users 本番サービスを支えるKubernetes環境
- 25. | ?2021 F5 25 マイクロサービスを支える NGINX ソリューション NGINX Ingress Controller NGINX Service Mesh
- 26. | ?2021 F5 26 Ingress 颁辞苍迟谤辞濒濒别谤について
- 27. | ?2021 F5 27 Ingress Controllerを使用してますか? 1. Default Kubernetes Ingress Controller 2. Default OpenShift Router 3. NGINX Ingress Controller 4. F5 Container Ingress Services 5. その他 6. 特になし
- 28. | ?2021 F5 28 ? Kubernetes プラットフォームの外部からのトラ フィックを受け入れ、プラットフォーム内で実行 されているPod(コンテナ) に負荷分散します。 ? Kubernetes API を使用して設定され、 「Ingressリソース」と呼ばれるオブジェクトを 利用する ? Kubernetes で実行中のポッドを監視し、例えば ServiceにPodが追加または削除された場合に、 ロードバランシングルールを自動的に更新します Ingress Controller Internal Network ユーザー Ingress Controller Kubernetes 環境用のロードバランサー Ingress
- 29. | ?2021 F5 29 NGINX Ingress Controller ロードバランサー, キャッシュ, API Gateway, WAF オールインワンソフトウェア アプリケーションをコントロールし保護する ? NGINX Ingress Controller 大規模アプリケーショントラフィックを実現 ? JWT認証: OpenID接続を介して承認されたユーザーを検証する ? NGINX App Protect: F5 WAFに基づいて開発された最新のアプリセキュリティ ソリューション Ingress
- 30. | ?2021 F5 30 L7リクエストルーティング トラフィック分割 レート制限 JWT認証 Web Application Firewall NGINX Snippets URLパス, リクエストメソッド A|B テスト, Canaryリリース 不正クライアント対策 認証機能をNGINXにオフロード アプリケーション脆弱性対策 既存のNGINXコンフィグを適用 NGINX Plus Ingress Controller ユースケース
- 31. | ?2021 F5 31 スケールにおいて2つの課題 マルチテナント (チーム) 複数チームがアプリケーションコンテナ 環境を安全に共有する方法 複雑なアプリケーション 複雑なアプリケーションに必要 な高度な設定するにはどうすれ ばよいでしょうか
- 32. | ?2021 F5 32 Host TLS Upstreams Routes - Path Action Split Match Route ErrorPage pass redirect return proxy delegation optional Host TLS Upstreams Routes - Path Action Split Match Route ErrorPage pass redirect return proxy delegation optional NGINX Ingress Resources – 豊富な機能 Host TLS Policies Upstreams Routes - Path Policies Action Split Match Route ErrorPage pass redirect return proxy delegation VirtualServer ドメインやURLパスの設定 pass redirect return proxy pass redirect return proxy Host Upstreams Subroutes - Path Policies Action Split Match ErrorPage pass redirect return proxy VirtualServerRoute URLパスの詳細設定 NGINX server configuration NGINX http configuration Server and HTTP snippets NGINXコンフィグ拡張 NGINX location configuration Location snippets NGINXコンフィグ拡張 Policies レート制限や認証 Access Control Rate Limiting Auth (JWT, OIDC) MTLS (Ingress/Egress) App Protect WAF
- 33. | ?2021 F5 33 NGINX Ingress Resource – 分散設定
- 34. | ?2021 F5 34 NGINX Ingress Resource – 分散設定 インフラ アプリケーション 開発者 SRE 認証管理 セキュリティ
- 35. | ?2021 F5 35 NGINX Ingress Resource – 分散設定 SI 開発会社A 開発会社B 開発会社C 本社 認証管理 セキュリティ
- 36. | ?2021 F5 36 アプリケーション Internet Ingress アプリケーション NGINX Ingress Controller Cloud Shell productpage.takaaki-nginx.xyz Kubernetes API Ingress Resources NGINX Ingress Resource – ユーザーとの関係性を管理 マルチテナント, 様々なチーム L7リクエスト コントロール
- 37. | ?2021 F5 37 Service 惭别蝉丑について
- 38. | ?2021 F5 38 本番環境でサービスメッシュを使用していますか? 1. はい、 Istioを利用中です 2. はい、その他のサービスメッシュ製品 3. いいえ、積極的に評価しています 4. いいえ、予定はありません
- 39. | ?2021 F5 39 サービスメッシュ活用範囲 Users Ingress Controller “North-South” トラフィック “East-West” トラフィック productpage.takaaki-nginx.xyz
- 40. | ?2021 F5 40 サービスメッシュとは K8Sに欠けているもので何が必要ですか? サービスメッシュは、分散システムの アプリケーショントラフィック制御、監視、 セキュリティの向上を目的としています。 - The New Stack
- 41. | ?2021 F5 41 サービスメッシュ サービスメッシュはアプリ間トラフィック管理, テレメトリー収集をします. セキュアトラフィック エンドツーエンド暗号化(相互 TLS/mTLS), ACL すべてのサービス トラフィックの管理 ロードバランス, サーキットブレーカ, B|G, レート制限 オーケストレーション インジェクションとサイドカー管理, k8s API統合 トラフィックの測定 トランザクション?トレースとリアルタイム?モニタリング Istioはオープンプラットフォーム トラフィック管理 ポリシー適用 テレメトリー収集 https://developer.ibm.com/jp/videos/new -builders-istio4/ マイクロサービス マイクロサービス 設定管理
- 42. | ?2021 F5 42 NGINX Service Mesh 概要 ? NGINX サービスメッシュは K8s クラスタ内で動作します ? 外部サービスへの入力/出力トラフィックを安全に管理 ? 任意のK8sクラスタプラットフォームに展開可 AWS EKS, AzureAKS, GoogleGKE
- 43. | ?2021 F5 43 アプリに「トラフィック制御, アクセス制限, 外部通信を許可する」という メッシュポリシーを適用することが可能です。 (kubectl apply –f policy.yaml) NGINX Service Mesh サイドカー アプリケーションA Pod アプリケーションB Pod 通信制御: ポリシー
- 44. | ?2021 F5 44 Mutual TLS Instrumentation Tracing Rate Limiting Traffic Splitting Access Control Egress Control 暗号化、セキュリティ保護 パフォーマンス、待機時間、可用性を監視する トランザクションのデバッグと障害の特定 脆弱なアプリを保護、クライアントを制限する A|Bテスト, Canaryリリース, Blue-Green トラフィックを正確に管理, アクセスリスト 内部から外部サービスへのトラフィックの管理 サービスメッシュのユースケース
- 45. | ?2021 F5 45 トラフィック分割 サーキットブレーカー productpage.takaaki-nginx.xyz NGINX サービスメッシュ – システム観点での管理 アクセス制御 暗号化
- 46. | ?2021 F5 46 Istio と NGINX Service Mesh o 概念とレイヤーが増えるので、ネットワークは複雑になってくる. o Service MeshデータプレーンはNGINX基本機能と専用モジュールで実現. o データプレーンやログがNGINXなので属人化しにくい. o マルチクラウドで共通のNSM環境が利用が可能 o NGINXパフォーマンスはサイジング可能. o SMI仕様を共有利用できるので運用難度を軽減. o F5 NGINXサポートで導入しやすい. o ロードマップにより破壊的アップデートを避け安定リリース. istioctl o 概念とレイヤーが増える、ネットワークは複雑になってくる o 高機能、高い知名度 o K8s, Nomad, Consul 様々なオーケストレーション o 独自のサービスメッシュ環境を構築 o 学習コストが高く属人化しやすい o コミュニティが活発、陳腐化しやすい o 運用負荷が高い o Google, IBM, Amazonなどでマネージドメッシュサービス nginx-meshctl
- 47. | ?2021 F5 47 ? マイクロサービスを取り入れ、Kubernetesを利用しています. ? 自動化された CI/CD パイプラインを使用します. ? アプリケーションを頻繁にリリースします (平日1回程度). ? ゼロトラストネットワーク環境にしていきます(mTLS, 暗号化). ? コンテナのトラフィックのモニタリングを行います. サービスメッシュを活用するには
- 49. | ?2021 F5 49 本日お伝えした内容 マイクロサービスアーキテクチャを適用するサービスやアプリケーション. アプリケーションを反復して機能改善やリリースを行う必要性. マイクロサービス向け技術選定ではコンテナやKubernetesを考えることになります. アプリケーションの開発と運用のための組織変更が必要になることもあります. Ingress Controller, Service Meshを活用するのが鍵となります. 無償トライアルを利用してNGINX Ingress Controller, Service Meshをお試しください！