Downloaded 29 times
![[基調講演] DLL_RealtimeAI](https://cdn.slidesharecdn.com/ss_thumbnails/dllabdaykeynotesakakibara-180710072423-thumbnail.jpg?width=640&height=640&fit=bounds)
Azure アプリケーション アーキテクチャ ガイド 紹介
- 1. 1 Azure アプリケーション アーキテクチャ ガイド 紹介 KazuyukiNomura Technical Evangelist Microsoft Co., Ltd.
- 2. 2 アジェンダ – 設計上の意思決定 •アーキテクチャスタイル • デザインパターン • コンピューティング/ ストレージの選択 • その他の技術選択 • 設計原理
- 3.
- 4. 4 オンプレミス vs. クラウドアプリケーション 従来のオンプレミス最新のクラウド リレーショナルデータベース 複数のストレージ技術（Polyglot persistence） 厳密な整合性 結果整合性 予測可能なスケーラビリティのための設計 柔軟な拡張性のための設計 直列同期処理 並列非同期処理 モノリシック、集中型 分解、分散化 障害を避けるための設計（MTBF） 障害を前提とした設計（MTTR） 頻度の低い大規模な更新 頻繁で小規模な更新 手動管理 自動化されたセルフ管理 スノーフレークサーバー イミュータブルなインフラストラクチャ
- 5.
- 6.
- 7. 8 アーキテクチャスタイルの選択 • ビジネスドメイン（機能、非機能） • 前提条件 •利点 vs. チャレンジ • 適合度
- 8. 9 いつマイクロサービスを選択するか？ 利点 - 独立したデプロイ - 障害の分離 -様々な技術の混在 - 小規模な専任チーム - 独立に規模拡張 課題 - 複雑性 - ネットワークの輻輳 - データ整合性 - テスト - ガバナンスの欠如 ビジネスドメイン - 複雑なドメイン - 高速にリリース - 複数の開発チーム 前提条件 - 分散システムのスキルセット - ドメイン知識 - DevOps 文化 - モニタリング機能
- 9.
- 10. 12 アーキテクチャスタイルの選択 依存関係の管理 ドメインの種類/複雑度 N層 水平方向のレイヤ(open/close) ビジネスロジックの大部分は CRUD Web キューワーカー フロント/バックエンドのジョブを 非同期メッセージングにより分離 比較的単純なドメインで、リソースを集中的 に使用するタスク マイクロサービス 垂直方向（機能的）に分解されたサー ビスがAPIを通じて相互に通信 各サービスがドメイン知識をカプセル化する ことを要求する複雑なドメインロジック CQRS 読み込み/書き込みの分離、スキーマ とスケールを個別に最適化 多くのユーザーが同じデータにアクセスする 共同作業ドメイン イベントドリブン アーキテクチャ ストリーミングに取り込まれたデータ、 サブシステムごとに独立したビュー IoT ビッグデータ 大規模なデータセットを小さいチャン クに分割、ローカルデータセットを並 列処理 バッチ及びリアルタイムのデータ分析、ML による予測分析 ビッグコンピューティン グ 何千ものコアにデータを割り当て 数値計算を集中的に使用するドメイン（シ ミュレーションなど）
- 11.
- 12.
- 13.
- 14. 16 N層 アーキテクチャ Web 層 データベー ス リモート サービス NVA ミドル 層2メッセージン グ キャッ シュ ミドル 層 1 踏み台 ユーザー 管理者
- 15. 17 N層 アーキテクチャの ベストプラクティス Web 層 データ ベース リモート サービス NVA ミドル 層2 メッセージ ング キャッ シュ ミドル 層 1 踏み台 ユー ザー 管理者 高可用性のた めにNVAを複 数配置 階層を分離す るためメッ セージングを 使用 半-静的データをキャッ シュ NVA によりイ ンターネット アクセスを制 限 データアクセスを制限 踏み台経由で管理タスク 複数仮想マシンが入る 階層ごとにサブネットに分割 SQL AlwaysOn などを活用 しデータ冗長性を構成
- 16. 18 N層 • いつ使うか: • 既存アプリから最低限のリファクタリングで移行するシナリオ •シンプルな Web アプリ（例：管理用 Web サイト） • オンプレミスとクラウドをまたがり開発と管理を統一する必要あり • 利点: • 高い移植性 • なだらかな学習曲線 • 従来のアプリケーションモデルからの自然な進化 • 異種混合環境（Windows/Linux）への適合性 • 課題: • モノリシックなため独立にデプロイ不可 • 管理性が最適ではない • 仮想マシン上で実行される各サービスのバージョン管理 • ネットワークセキュリティの構成が大変 • 業界規制への準拠（PCI、SOX、HIPPA、など ）
- 17. 20 Web キューワーカー アーキテクチャ SPA & モバイル Webフ ロントエ ンドサー ビス SQL NoSQL CDN リモート サービス キャッ シュバック エンド ジョブ メッセージン グ IdP
- 18. 21 Web キューワーカー – サービスマッピング SPA & モバイル Webフ ロントエ ンドサー ビス SQL NoSQL CDN リモート サービス キャッ シュバックエ ンドジョ ブ メッセージン グ IdPAAD Web App Web Role ストレージ キュー ServiceBus Webjobs Worker Role Azure Redis Cache 外部サービ ス Azure SQL DB Storage Cosmos DB Search CDN ブラウ ザ 電話
- 19.
- 20. 23 SPA & モバイ ル Web フ ロントエ ンドサー ビス SQL NoSQL CDN リモート サービス キャッ シュバック エンド ジョブ Blob メッセージ ング IdP Webキューワーカーのデザインパターン Throttling Circuit breaker Cache aside Federated authentication Sharding Static content hosting Competing consumersLoad leveling Valet key
- 21. 24 SPA & モバイ ル Web フ ロントエ ンドサー ビス SQL NoSQL CDN リモート サービス キャッ シュバック エンド ジョブメッセージ ング IdP Web キューワーカーのアンチパターン Busyfrontend No CacheSynchronous IO Improper instantiation Busy database Monolithic persistence Serial message processing Chatty IO Extraneous fetching
- 22. 25 Web キューワーカー • いつ使うか •比較的単純なビジネスロジックの Web アプリケーション • 可能ならマネージサービスを活用 • 利点 • 初期からの Azure アーキテクチャ ☺ • 理解しやすい比較的単純なアーキテクチャ • デプロイと管理の容易さ • 明確な関心事の分離 • 非同期メッセージングによりワーカーからフロントエンドを分離 • フロントエンドとワーカーは独立に拡張可能 • 課題 • 注意深く設計しないと、Webフロントエンドとワーカーが大規模なモノリシックコン ポーネントになり、保守や更新が困難に • フロントエンドとワーカーがデータスキーマやコードモジュールを共有している場 合、隠れた依存関係が存在する可能性
- 23.
- 24.
- 25. 28 マイクロサービス • いつ使うか • 頻繁な更新が必要 •複雑なドメインを扱う • 利点 • 独立にデプロイ • 障害の分離 • 技術の混在 • 小規模な専任チーム • 独立に規模拡張 • 課題 • 複雑性 • ネットワークの輻輳 • データ整合性 • テスト、監視
- 26.
- 27. 30 CQRSによるデータの分離 Delivery Account DeliveryID PackageIDDrones 1234 0011 003154 DeliveryID PackageID Date Delivered 1234 0011 9901/19/2017 MessageBroker 書き込みモデル (イベントソーシング) 読み込みモデル (マテリアライズドビュー) 結果整合 PackageDelivered
- 28. 31 SPA & モバイ ル マイクロサービ ス SQL NoSQL API ゲートウェ イ CDN リモート サービス キャッ シュ Read model 書き込み モデル マイクロサービ ス Blob Command Query メッセージング IdP マイクロサービス/CQRSのデザインパターン 読み込み モデル GW- aggregation Bulkhead SidecarBackendfor frontend イベントソー シング マテリアライズ ドビュー AmbassodarGW- offloading
- 29. 32 CQRS • いつ使うか • 同じデータを何度も更新する共同作業ドメイン •読み込み/書き込みのワークロードが非対称 • 高スケーラビリティが必要 • 利点 • 読み込み/書き込みに対する独立したスケーラビリティ • 書き込みと読み込みを分離 • 書き込みと読み込みに最適化されたスキーマ • 課題 • データ一貫性 • 実装の複雑さ
- 30.
- 31.
- 32. 36 EDA (IoT) いつ使うか • 大量・高速なデータのストリーム処理 •パターンマッチング、特定の時間範囲内の集計 • 複数のサブシステムが同じイベントを処理 • 利点 • 大量/高速/多様なリアルタイムデータを処理 • 課題 • 一貫したセキュリティの維持 • 標準の遵守 • 高いスループット処理 • リアルタイムデータ分析
- 33.
- 34. 48 技術の選択 – コンピューティング •ホスティングモデル • DevOps 機能のサポート • スケーラビリティ • コスト • アーキテクチャスタイル • (可用性) • (セキュリティ)
- 35. 49 技術の選択 - ストレージ •RDBMS • キーバリュー ストア • ドキュメント • グラフ • サーチ • タイムシリーズ • オブジェクトストア • 共有ファイル
- 36. 50 技術の選択 – その他 •メッセージングプラットフォーム • Storage queue, Service bus, Event Hub, Event Grid • コンテナオーケストレーター • ACS/AKS/ACI, Service Fabric • ロギング/モニタリングフレームワーク • Application Insight, Prometheus, ELK • CI/CD パイプライン • VSTS, Jenkins 最初にマネージサービスを評価し、次にOSSを検討
- 37.
- 38.
- 39.
- 40. 54 Azure アプリケーションのための設計原理 • マネージサービスを利用する •コーディネーションを最小限に抑える • パーティション分割により制限を回避する • スケールアウトできるよう設計する • 自己復旧できるよう設計する • 全てを冗長化する • 業務に最適なデータストアを使用する • 進化に対応した設計にする • 運用を重視して設計する • ビジネスのニーズに合わせて構築する
- 41.
- 42. 56 マネージサービスを利用する • マネージサービスは管理上のリスクを著しく下げる • パッチ、バージョン管理、リソースのチューニング、クラスタ管理 •自分で Elasticsearch を立てるか、Azure Search を利用するか？ • マネージサービスはIaaS ワークロードの中でも利用可能 • キャッシュ, メッセージング, ストレージ etc. • もしバージョン管理、スケーラビリティの制限、コスト、ポー タビリティなどが要求に合わなければ、IaaS アプローチを検討
- 43.
- 44.
- 45.
- 48.
- 49.
- 50. 64 スケールアウトできるよう設計する • インスタンスの持続性は避ける • ボトルネックを特定し、闇雲にスケールアップ/アウトする代わり に解消する •システムのステートフルな部分が、ボトルネックの原因となる可 能性が高いと心得る • 予測可能な負荷についてはスケジュールで、予想不可能な負荷に ついてはパラメータに基づき自動スケーリングを行う • スケールインが可能な設計にする • 重要なワークロードについては、積極的に自動スケーリング を検討する 次のステップ ⇒ スケーラビリティのチェックリスト (https://docs.microsoft.com/ja-jp/azure/architecture/checklist/scalability)
- 51.
- 52.
- 53. 67 自己復旧できるよう設計する • 一時的な障害の場合は再試行する • リモート呼び出しが行われないようにする(Circuit Breaker パ ターン) • 失敗したトランザクションを補正する • Bulkhead パターン • 縮退運転に切り替える • サービスの規模縮小 (degradation) • フォールト挿入でテストを実施する • カオスエンジニアリング 次のステップ ⇒ 回復性のチェックリスト (https://docs.microsoft.com/ja-jp/azure/architecture/checklist/resiliency)
- 54.
- 55. 69 全てを冗長化する • 可用性セット /スケールセット • 複数のリージョンにデプロイする • 自動フェールオーバー / 手動フェールバック（切り戻し） • フロントエンドとバックエンドのフェールオーバーを同期する • Traffic Manager を冗長化する • ジオレプリケーション • RTO/RPO 次のステップ ⇒ 回復性のチェックリスト
- 56.
- 57. 71 業務に最適なデータストアを使用する • 全てにSQLを使おうとしない (モノリシックパーシステンス) • ロギング、BLOB、ドキュメント • 適切なストレージを選択する • データの種類、ユースケース、など • マイクロサービス アーキテクチャは多種多様な(polyglot)ストレージ の使用を奨励 • それぞれのサービスがプライベートなデータを最適な形式で所有 • ACID から BASE トランザクションへシフトする • 結果整合性 • 補正トランザクション 次のステップ ⇒データ ストアの選択条件 https://docs.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/ data-store-comparison
- 58.
- 59. 73 進化に対応した設計にする • サービスを個別にデプロイする • 凝集度を高め、疎結合を保つ •データ/サービスモデルに不必要な前提を置かない • ドメインの知識を1か所にカプセル化する • サービス コントラクトに基づいて設計とテストを行う • インフラを抽象化してドメイン ロジックから切り離す
- 60.
- 61. 75 運用を重視して設計する • 全てのことを観察できるようにする • 根本原因分析とシステムの健全性の両方を計測する •分散トレーシングを使用する • 管理タスクを自動化する • 構成をコードとして扱う • ログとメトリクスを標準化する • 運用チームを設計と計画に関与させる Next step > Data store comparison guide, ADAG
- 62.
- 63. 77 ビジネスのニーズに合わせて構築する • 機能要求 –DDD、DCA • コンテキスト境界がサービスの境界につながる • コンテキストマップがサービスの依存関係につながる • 集約、ドメインサービス/イベントがマイクロサービスとサービス間通信 につながる • 非機能要求 – RTO/RPO/MTO、SLO/SLA • RTO がフェイルオーバー期間につながる • RPO がバックアップ間隔につながる • SLA が冗長性レベルのサービスの選択につながる • スループット/レイテンシーがパーテショニングを伴うSKUの選択につな がる
- 64. 78 次のステップ • Azure アプリケーションアーキテクチャ ガイド https://docs.microsoft.com/ja-jp/azure/architecture/guide/ • Azure Data Architecture Guide (WIP) • Azure の参照アーキテクチャ https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/ • Azure でのマイクロサービスの設計、構築、および操作 https://docs.microsoft.com/ja-jp/azure/architecture/microservices/ • CQRS Journey https://msdn.microsoft.com/ja-jp/library/jj554200.aspx • クラウドデザインパターン https://docs.microsoft.com/ja-jp/azure/architecture/patterns/ • 設計レビューのチェックリスト https://docs.microsoft.com/ja-jp/azure/architecture/checklist/ aka.ms/mspnp
- 65.
- 66.