20231211_CloudNative Days講演「from monolith to cloud native」株式会社ジール

from monolith to cloud native ～実現可能なcloud-native化手法～

モノリシックな環境と比べてクラウドネイティブな環境のメリットって？実際にはどんな環境なの？と、具体的にイメージができていない方に向け、BtoB SaaSにおいてモノリシックな環境のマイクロサービス化、クラウドネイティブ化を実現してきたからわかるメリット・デメリットや、検討ポイントとなる「ロジック分離」「コンテナ化」「IaC」「CI/CD」「observability」についてお伝えします。
ーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーー
2023年12月11日・12日開催「CloudNative Days」講演
イベントURL：https://event.cloudnativedays.jp/cndt2023/timetables
講演：株式会社ジール　クラウドマネージドサービスユニット　チーフスペシャリスト　NOH SEONTAEK

本資料の無断転載を禁じます

Transcript

1. ©2023 ZEAL CORPORATION. All Rights Reserved. ～実現可能なcloud-native化手法～ from monolith to cloud native 株式会社ジール クラウドマネージドサービスユニット チーフスペシャリスト NOH SEONTAEK 2023.12.11
2. 2 ©2023 ZEAL CORPORATION. All Rights Reserved. 自己紹介
3. 3 ©2023 ZEAL CORPORATION. All Rights Reserved. 自己紹介 NOH SEONTAEK ノソンタク 株式会社ZEAL クラウドマネージドサービスユニット チーフスペシャリスト 韓国で約15年間サーバープログラマー、クラウドエンジニア、エンジニアリングマネー ジャーとして勤務 2016年より日本の会社に入社後、サーバプログラマー、クラウドエンジニア、アーキテ クトとして勤務中 好きな技術：分散クラスタリング、マイクロサービス、IaC 北海道の大自然を満喫しながら日々を楽しんでいる中
4. 4 ©2023 ZEAL CORPORATION. All Rights Reserved. 実績 分散コンピューティングシステム、グリッドコンピューティング、Hadoop関連論文寄稿(韓国) データ分析プラットフォームの構築および開発 • Hadoop, Hive, Flume クラスター構築 (AWS Cloudformation + Ansible) • データ分析および集計ETLシステム : Opensearch, Kafka, AWS EMR, AWS EKS, GCP BigQuery • API プログラミング : Java Springboot (MSA), Go, Scala ゲームプラットフォームの構築および開発 • APおよびバックエンドの構築 (AWS Cloudformation + Azure Resource Templates) • AWS DynamoDB, AWS redshift, AWS ECS / Fargate • 対数分析および行動パターン分析 : Fluentd, Elasticsearch, AWS Athena スポーツ競技ブロードキャスティングマッシュアップサービスの構築および開発 チームDevOps、GitOps環境構築
5. 5 ©2023 ZEAL CORPORATION. All Rights Reserved. ジールの事業紹介 SRE支援 クラウドインフラの整備やクラウド環境の自動 化などを通じて、サービスの信頼性を向上の 支援 Site Reliability Engineering コア事業：データプラットフォーム開発 クラウド事業：SRE支援 Infrastructure as Code Container Orchestration microservice CI/CD Observability FinOps
6. 6 ©2023 ZEAL CORPORATION. All Rights Reserved. なぜジール入社したのか？SRE支援なのか？ 自身のキャリア ジール新規事業 SRE支援 広く顧客企業の支援
7. 7 ©2023 ZEAL CORPORATION. All Rights Reserved. スタート:モノリスからクラウドネイティブへ
8. 8 ©2023 ZEAL CORPORATION. All Rights Reserved. レガシーアプリケーション レガシ アプリケーション (モノリス) • 新機能のリリースに時間がかかる -> Technical Debt • ビジネスニーズへの機敏な対応が困難 • 既存の機能を変更および改善するには、多くの手順を実行する必要がある インフラストラクチャの問題 (オンプレミス) • ハードウェアとオペレーティングシステムの老朽化 -> 運用コストの増加、信頼性の低下 • 新規システムへの移転には多くの時間が必要
9. 10 ©2023 ZEAL CORPORATION. All Rights Reserved. Cloud Native クラウドネイティブ技術は、組織がパブリック、プライベート、ハイブリッドクラウド のような現代的で動的な環境で拡張可能なアプリケーションを開発·実行できるようにす る コンテナ、サービスメッシュ、マイクロサービス、不変(Immutable)インフラ、そして 宣言型(Declarative)APIなどを活用して回復性、管理利便性、可視性を備えた緩やかに 結合されたシステムを可能にする CNCFのクラウドネイティブの定義には、4つの重要な要素が含まれている • DevOps • CI/CD • Containers • Microservices
10. 11 ©2023 ZEAL CORPORATION. All Rights Reserved. レガシーを解決するために Monolithic Architecture System S/W Middleware Databases OS Virtual Machine Hardware Hardware SRE/DevOps Container CI/CD Microservice Architecture Microservice Microservice Microservice Operation Environment Development Environment System S/W Middleware Container Legacy Ststem Cloud Native Ststem Microservices Divide&Conquer PaaS conversion Cloud Integration Infrastructure as Code Observability
11. 12 ©2023 ZEAL CORPORATION. All Rights Reserved. CloudNative VS Cloud-based systems カテゴリ クラウドネイティブ クラウドベース サービスモデル コンテナ基盤PaaS 仮想化基盤IaaS 設計 スタート段階からクラウドの長所である敏捷性、拡 張性、そして移動性を最大限活用できるよう設計 オンプレミスで構築したシステムをクラウドに移行して 運用 構築 ハードウェアやソフトウェアに依存することなく、 標準ベースのソフトウェアを使用して迅速かつ効率 的に導入 セットアップは特定のハードウェアとソフトウェアに依 存しており、構築に時間がかかる 拡張性 マイクロサービスに基づいて、サービス全体に影響 を与えることはなく、更新が必要なサービスのみを 変更でき、サービス単位のスケールイン/スケール アウトをサポート アプリケーションのアップデートが手作業のため、長時 間のダウンタイムが必要で、スケールイン/スケールアウ トが難しい 費用 インフラ部分への依存性がないのでコストが安い アプリケーションが大きくなるほど、インフラストラク チャのコストは高くなる メンテナンス CI / CD バージョン管理、インストール、および構成管理は手作 業で複雑
12. 13 ©2023 ZEAL CORPORATION. All Rights Reserved. 何が変わるのか 自動化 敏捷性 拡張性 可用性 自動復元性
13. 15 ©2023 ZEAL CORPORATION. All Rights Reserved. 旅行に必要な持ち物 マイクロサービス ロジックの分解 コンテナ化 IaC (Infrastructure as Code) CI / CD Observability
14. 16 ©2023 ZEAL CORPORATION. All Rights Reserved. Monolithic VS Microservices
15. 17 ©2023 ZEAL CORPORATION. All Rights Reserved. Monolithic 構造が簡潔で長期間広く使用され、十分に検証されたアーキテクチャ Application 開発チーム
16. 18 ©2023 ZEAL CORPORATION. All Rights Reserved. Monolithic システムの構造が大きくなり、サービスが継続的に追加されていくと、 Application 開発第３チーム 開発第４チーム 開発第２チーム 開発第１チーム
17. 19 ©2023 ZEAL CORPORATION. All Rights Reserved. Monolithic Module Dependency 一部のモジュールの変更
18. 20 ©2023 ZEAL CORPORATION. All Rights Reserved. Monolithic Module Dependency 一部のモジュールを拡張する必要がある場合
19. 21 ©2023 ZEAL CORPORATION. All Rights Reserved. Microservices 2011年、ベネチアの一部アーキテクトが集まり、自分たちが探求していた アーキテクチャスタイルを「Microservice」と命名 自生的に生まれたため明確な定義がない 独立して開発·実行されるソフトウェアコンポーネント（サービス）を 複数組み合わせて1つのアプリケーションとして構築する仕組み
20. 22 ©2023 ZEAL CORPORATION. All Rights Reserved. Microservices 独立したサービスへの分離 開発第３チーム 開発第４チーム 開発第２チーム 開発第１チーム Service A Service B Service C Service D Service F Service E
21. 23 ©2023 ZEAL CORPORATION. All Rights Reserved. マイクロサービスへの分離 Microservices A B C D E F G H Microservices Microservices Microservices Microservices Microservices Microservices Interface A B C D E H G F FIFO Queue SUB-PUB Microservices Microservices
22. 24 ©2023 ZEAL CORPORATION. All Rights Reserved. 事例 Netflix 2008年深刻なデータベース損傷によりDVD配送が3日間中断 これを機にクラウドへの転換と共にモノリシックからマイクロサービスへ変更 Uber 2013年頃、二つのモノリシックシステムから2015年マイクロサービスに転換完了 SoundCloud プロセス短縮のためフィーチャー単位のチームを構成、モノリシックシステムのコードを分離し て独立したサービスに転換(既存配布時間66日から9日に短縮)
23. 25 ©2023 ZEAL CORPORATION. All Rights Reserved. 事例 Netflix プロダクション環境に600以上のサービスが存在。1日に500回以上配布 Uber プロダクション環境に1000以上のサービスが存在。毎週数千回以上配布 WeChat プロダクション環境に3000以上のサービスが存在。毎日1000回以上配布 Google GmailからYouTube、検索に至るまでGoogleのすべての製品はコンテナで実行 毎週数十億個以上のコンテナを生成
24. 26 ©2023 ZEAL CORPORATION. All Rights Reserved. ロジック分解
25. 29 ©2023 ZEAL CORPORATION. All Rights Reserved. マイクロサービスアーキテクチャの定義 ドメイン専門家が文書で整理した要件と既存アプリケーションを出発点として、3段階 プロセスを経て定義する • システム作業識別 • サービス分解戦略決定 • サービス別API定義
26. 30 ©2023 ZEAL CORPORATION. All Rights Reserved. ユーザーストーリーに関連するユーザーシナリオなどの機能要件を定義 アプリケーションドメインモデルを大まかに描いた後、各システムタスクの動作を記述 するために必要な単語を定義 各アプリケーションがどのリクエストを処理するかを識別し、明細を定義 マイクロサービス アーキテクチャ定義:ステップ 1 – システム作業識別 機能要件 私はユーザーとして00をして XXになりたい 私はサーバーとして00をして XXにしたい service createRequest() acceptRequest()
27. 32 ©2023 ZEAL CORPORATION. All Rights Reserved. ビジネス能力パターン別分解 • ビジネス能力とは、ビジネスが価値を生み出すために行う行為を意味 • ビジネス能力は通常、ビジネスオブジェクトに集中し、複数のサブ能力に分解でき、各開発し たいソフトウェアのドメインを分析してビジネス能力を導出し、分離する マイクロサービスアーキテクチャ定義ステップ 2 – サービス分解戦略決定 機能要件 私はユーザーとして00をして XXになりたい 私はサーバーとして00をして XXにしたい createRequest() acceptRequest() AA サービス BB サービス CC サービス
28. 33 ©2023 ZEAL CORPORATION. All Rights Reserved. サブドメインパターン別分解 • DDDは、オブジェクト指向ドメインモデル中心のソフトウェアアプリケーションをモデリングする手法 • よくユビキタスランゲージと呼ばれるドメインの専門家や開発者などを含むチーム全体で共用で使用する 言語を定義する •DDDにはマイクロサービスアーキテクチャに適用できる有用なサブドメインとバウンデッドコンテキスト という概念がある. マイクロサービスアーキテクチャ定義ステップ 2 – サービス分解戦略決定 機能要件 私はユーザーとして00をして XXになりたい 私はサーバーとして00をして XXにしたい createRequest() acceptRequest() AA サービス BB サービス CC サービス CC サブドメイン BB サブドメイン AA サブドメイン AA ドメイン モデル BB ドメイン モデル CC ドメイン モデル mapped mapped mapped
29. 35 ©2023 ZEAL CORPORATION. All Rights Reserved. マイクロサービスアーキテクチャ定義ステップ ３ – サービス別API定義 各サービスごとのAPI（作業とイベント）を定義 どのサービスが要請の進入点なのかを設定しなければならず、配分後にサービスがどの ように協同すべきかを決める 機能要件 私はユーザーとして00をして XXになりたい 私はサーバーとして00をして XXにしたい createRequest() acceptRequest() AA サービス BB サービス CC サービス verifyRequest()
30. 37 ©2023 ZEAL CORPORATION. All Rights Reserved. AA 서비스 Hexagonal Architecture DOMAIN BUSINESS LOGIC Repository DAO Browser App Message Broker ADAPTER ADAPTER ADAPTER ADAPTER PORT PORT PORT APPLICATION
31. 38 ©2023 ZEAL CORPORATION. All Rights Reserved. サービス分解の妨げ ネットワーク遅延 同期IPCによる可用性の低下 データ一貫性の維持 分解を阻害する万能クラス
32. 39 ©2023 ZEAL CORPORATION. All Rights Reserved. コンテナ化 (Containerization)
33. 40 ©2023 ZEAL CORPORATION. All Rights Reserved. コンテナ化 アプリケーションとその依存要素をコンテナ画像形式で梱包することを意味 コンテナビルドプロセスはOCI (Open Container Initiative) を遵守しなければならな い
34. 42 ©2023 ZEAL CORPORATION. All Rights Reserved. コンテナ化 コンテナ環境の構造比較 Hardware Operating System Hardware Operating System Hypervisor Hardware Operating System Container Runtime Operating System Operating System Bin / Library Bin / Library Bin / Library Bin / Library Bin / Library App App App App App App App App App App Traditional Deployment Virtualized Deployment Container Deployment Virtual Machine Virtual Machine Container Container Container
35. 43 ©2023 ZEAL CORPORATION. All Rights Reserved. コンテナ化 コンテナ環境の構造比較 Virtualized Deployment Container Deployment C VM VM VM VM C C C C C C C C C C C C
36. 45 ©2023 ZEAL CORPORATION. All Rights Reserved. コンテナ化その後。 配布の問題点 サービスディスカバリーの問題 サービス公開の問題 サービス障害、負荷モニタリングの問題点
37. 46 ©2023 ZEAL CORPORATION. All Rights Reserved. コンテナオーケストレーション (Container Orchestration) 複雑なコンテナ環境を効果的に管理するためのツール サーバー管理者の役割に代わるプログラムを作成するツール 多様なコンテナオーケストラが登場 • DEIS • RANCHER • MESOS • MARATHON • Nomad • Docker SWARM • Kubernetes
38. 47 ©2023 ZEAL CORPORATION. All Rights Reserved. Kubernetes コンテナを簡単かつ迅速に配布/拡張し、管理を自動化するオープンソースプラット フォーム 2015年グーグルにより公開 (v 1.0 release) • 週に20億個のコンテナを作成 • コンテナ配布/管理のために使用していたborgをベースに作ったオープンソース CNCFにコード寄付
39. 50 ©2023 ZEAL CORPORATION. All Rights Reserved. 開発環境 既存システム vs. K8S 開発１チーム 開発２チーム 開発Nチーム 業務 業務 業務 業務 業務 業務 middle ware middle ware middle ware OS OS OS server server server on- premise cloud cloud shell- script web- console macro Kubernetes server container container container container container container Image repository SRE / Platform 動的な開発チーム構成 コンテナベースの標準化 された環境と管理 無停止配布 開発１チーム 開発２チーム 開発Nチーム
40. 51 ©2023 ZEAL CORPORATION. All Rights Reserved. インフラ管理 既存システム vs. K8S インフラ第1 チーム インフラ第2 チーム インフラ第3 チーム SRE Kubernetes 運用技術の標準化による作業時間の効率化/システム一括設定作業時間の短縮/Human Error減少
41. 52 ©2023 ZEAL CORPORATION. All Rights Reserved. サーバーの設定と配布 既存システムvs. K8S Servers 開発チーム 開発チーム インフラ チーム SRE サーバー 追加要請 必要設定等 調整 サーバーの追加作業 ガイドの参照と作成 配布 ビルドファイル配信 Kubernetes 配布 AutoScailing 運用・管理 Image push
42. 53 ©2023 ZEAL CORPORATION. All Rights Reserved. Database 二重化 既存システム vs. K8S master slave sync Database Container Database Container storage
43. 54 ©2023 ZEAL CORPORATION. All Rights Reserved. IaC (Infrastructure as Code)
44. 56 ©2023 ZEAL CORPORATION. All Rights Reserved. Infrastructure as Code 基本構成 https://scand.com/company/blog/infrastructure-as-code/
45. 58 ©2023 ZEAL CORPORATION. All Rights Reserved. Infrastructure as Code example Terraform exam-route.tf AWS CFN exam-route.yaml
46. 59 ©2023 ZEAL CORPORATION. All Rights Reserved. Infrastructure as Code Terraformを活用したGitOps
47. 61 ©2023 ZEAL CORPORATION. All Rights Reserved. CI / CD
48. 62 ©2023 ZEAL CORPORATION. All Rights Reserved. CI / CD CI (Continuous Integration) • 開発環境で開発中のコードを統合し、必要に応じてテストを並行して行う一連のプロセス CD (Continuous Delivery / Continuous Deployment) • Continuous Delivery • 開発者がアプリケーションに適用した変更点がバグテストを経てリポジトリ(gitまたはコンテナレジス トリ)に自動的にアップロードされる一連のプロセス • Continuous Deployment • 開発者の変更をリポジトリから顧客が利用可能なプロダクション環境まで自動的にリリースする一連の プロセス
49. 65 ©2023 ZEAL CORPORATION. All Rights Reserved. CI / CD Example (Jenkins + argoCD) Developer Pipeline System Operator Pipeline Code commit / push webhook trigger application codes repository Jenkins CI AWS ECR Kubernetes Argo CD GitOps repository Docker image push New docker image pull Manifest sync Manifest commit / push Manifest / Chart.yaml upload Manifest sync / diff
50. 66 ©2023 ZEAL CORPORATION. All Rights Reserved. Observability
51. 67 ©2023 ZEAL CORPORATION. All Rights Reserved. Observability Observability • ITやクラウドコンピューティングにおいて、オブザーバビリティは、ログ、メトリック、ト レースなどのシステムで生成されるデータに基づいて、システムの現在の状態を測定（また は推論）する機能 Monitoring • ある対象を監視、観察するという意味で、モニタリングの目的は持続的な監視、監察を通じ て対象の状態や可用性、変化などを確認し備えること
52. 69 ©2023 ZEAL CORPORATION. All Rights Reserved. Observability Observability vs Monitoring MONITORING OBSERVABILITY SMS NMS DBMS APM FMS TMS IMS VMS BMS Server1 Server2 Server3 NET1 NET2 NET3 DB1 DB2 DB3 APP1 APP2 APP3 Metrics Tracing Logging AI より良い可視性の確保 潜在的問題識別 信頼性と性能改善 会議時間短縮
53. 70 ©2023 ZEAL CORPORATION. All Rights Reserved. Observability DevOpsとObservability組合 https://www.mdpi.com/1999-5903/14/10/274
54. 72 ©2023 ZEAL CORPORATION. All Rights Reserved. ようこそ！クラウドネイティブへ！
55. 73 ©2023 ZEAL CORPORATION. All Rights Reserved. 結論 理想的なクラウドネイティブ Observability (AIOps) IaC (GitOps) CI / CD (DevOps) Kubernetes Patterns (Automatable Containers at Scale) Microservices Principles (Services optimized for change) Hexagonal Architecture (Decoupled infrastructure components) Domain-Driven Design (Ubiquitous domain model) Clean Code (Well-crafted code)
56. 74 ©2023 ZEAL CORPORATION. All Rights Reserved. 結論 クラウドネイティブの成熟度 Level 0 : Cloud Ready Level 1 : Cloud Friendly Level 2 : Cloud Resilient Level 3 : Cloud Native • クラウド準備段階 • ハードウェア仮想化 • コンテナ化された画像による実行環境 • 内部ファイルシステムのない環境 • クラウド親和段階 • 緩いシステム結合構造 • 名前で探すサービス(サービスディスカバリー) • 12-factor app 原則の遵守 • クラウド深化段階 • 集中化されたモニタリング、メトリクス • マルチクラウドを網羅するスケール戦略 • 積極的な障害テスト、カバレッジを90%以上追求 • クラウドネイティブ • マイクロサービス構造を使用し、原則に従う • APIベースのソフトウェアアーキテクチャ
57. 76 ©2023 ZEAL CORPORATION. All Rights Reserved. 結論 Stranger Facade Pattern Stranger Facade Stranger Facade Legacy App. (Monlith) Modern App. (Microservice) Legacy App. (Monlith) Modern App. (Microservice) Modern App. (Microservice) Modern App. (Microservice) Modern App. (Microservice) Modern App. (Microservice) Modern App. (Microservice) Modern App. (Microservice) Modern App. (Microservice) Modern App. (Microservice) Modern App. (Microservice) 初期転換 転換加速 転換完了
58. 77 ©2023 ZEAL CORPORATION. All Rights Reserved. ありがとうございます。 株式会社ジール クラウドマネージドサービスユニット zeal-cms@zdh.co.jp