クラウド アプリケーション アーキテクチャ ガイド のバックアップ(No.9)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• クラウド アプリケーション アーキテクチャ ガイド へ行く。
  • 1 (2020-03-20 (金) 18:49:52)
  • 2 (2020-03-20 (金) 21:53:12)
  • 3 (2020-03-20 (金) 21:57:47)
  • 4 (2020-03-21 (土) 14:16:56)
  • 5 (2020-03-21 (土) 14:59:35)
  • 6 (2020-03-21 (土) 20:12:20)
  • 7 (2020-03-22 (日) 01:25:42)
  • 8 (2020-03-22 (日) 15:09:50)
  • 9 (2020-03-24 (火) 21:15:18)
  • 10 (2020-10-20 (火) 15:11:00)

---

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

• 参考から目次を抜いて体系化した。
• 結構、網羅が出来て来た（オンデマンドで追記予定）。

詳細 †

以下のような立て付けになっている。

アーキテクチャ スタイル †

ビッグ コンピューティング †

Azure Batch (HPC) 推しらしい。

ビッグ データ †

イベントドリブン アーキテクチャ †

• パブリッシュ/サブスクライブ

• イベント ストリーム モデル
  • イベントがログに書き込まれる。
  • クライアントはいつでも参加でき、イベントを再生
  • ストリーム内でクライアントの位置を進めるのは、クライアントの役割

マイクロサービス †

• 真面目にやると沼。

• SOAのREST WebAPI版（雑）

n 層アプリケーション †

アプリケーションを論理層と物理層に分離

Web キューワーカー †

• Webロール、Workerロール
• 必要に応じて、キュー

設計原則 †

自動修復機能の設計 †

• Polly ＋ Pollyで足りていないサーバ実装

• フェールオーバー

• パターン
  • 補正トランザクション
  • リーダー選択

• その他
  • フォールト挿入でテストする。
  • Chaos エンジニアリングを利用する。

すべてを冗長化 †

• 従来型のフェールオーバーに加え。

• システム・データのパーティション分割

• 複数のリージョンにデプロイ
  • geo レプリケーション
  • Traffic Manager

調整を最小限に抑える †

• トランザクション（ACID特性）以外の実現方法を検討する。
  • 楽観排他
  • 補正トランザクション
  • データのパーティション分割

• その他
  • ドメイン イベントと同期

• 読取 / 書込ワークロードの競合を削減
  • イベント ソーシング
  • コマンド クエリ責務分離 (CQRS)

• 別のインスタンス
  • 冪等操作の設計
  • リーダー選定

• 並列の分散アルゴリズム（ビッグデータ系の分散）

スケールアウトのための設計 †

垂直方向・水平方向にスケールできるように設計

• 垂直方向
  システム、アプリで構成する。
  • ボトルネックの特定、ワークロードの分解など。
  • タスクのオフロード（バックグラウンド・ジョブ化）

• 水平方向
  クラウド機能で構成する。
  • サーバー・ステートレス
  • スケールアウト・スケールイン
  • 自動スケール

パーティション分割による制限の回避 †

スケール・アップに限界があるので、パーティション分割。

• システム
  • データベース
  • キューまたはメッセージ バス
  • App Service Web アプリ

• データベース
  • 行方向
    • SQL Server パーティション分割
    • シャーディング

• 列方向
  簡単に言うとテーブルの分割

• 機能的
  請求書テーブルと製品在庫テーブルを分割

操作に合わせた設計 †

運用チームが必要なツールを得られるようにアプリケーションを設計

管理対象サービスの使用 †

なるべく、PaaS / FaaS, SaaSを選択。

ジョブに最適なデータ ストアの使用 †

• データ ストアの選択
• 調整を最小限に抑える

• その他
  • 開発チームのスキルセット
  • コンテキスト境界を確認（DDD）

改良を見込んだ設計 †

SOAっぽい（疎結合）。

• 高凝集と疎結合
  • サービスを個別にデプロイ
  • 共通機能を専用のサービスにオフロード

• ゲートウェイにはドメイン ナレッジを実装しない
  • ドメイン ナレッジをカプセル化
  • オープン インターフェイスを公開
  • 非同期メッセージングを使用

• クリーン・アーキテクチャ的な
  （抽象インフラストラクチャをドメイン ロジックと分離）

ビジネス ニーズに合わせた構築 †

• 成長に対応可能な計画とコストの管理
• 目標復旧時間 (RTO)、目標復旧時点 (RPO)、最大許容停止時間 (MTO)
• サービス レベル アグリーメント (SLA) とサービス レベル目標 (SLO)

• 要件
  • 機能要件と非機能要件
  • ワークロード別に分けて要件を判断

• ビジネス ドメインを中心にアプリケーションをモデル化（DDD）

技術選定 †

コンピューティング サービスの選択 †

適切なモンを使えと。

• ホスティング環境

• 参照アーキテクチャ
  • IaaS
  • PaaS / FaaS
  • SaaS

データ ストアの選択 †

適切なモンを使えと。

• RDBMS(SQL Serverなど)
• NoSQL
• , etc.

※ 多言語パーシステンスと言うらしい。

負荷分散サービスの選択 †

負荷分散については、NLBの項が参考になる。
（NLBを使えとは言っていない）

メッセージング サービスの選択 †

色々あるらしい。

• Azure Service Bus
• Event Grid
• Event Hubs

ベスト・プラクティス †

API 設計 †

• WebAPI > REST

• 非同期操作(CIBAのような)

• データ処理
  （ネットワーク帯域幅と処理能力の有効活用）
  • フィルター or ページング処理
  • HATEOAS
  • バイナリ リソースの部分的な応答

API 実装 †

• サーバー実装

• スケーラビリティ、可用性、応答性の維持
  • 非同期サポート
  • ステートレス
  • クライアントの
    ・追跡と調整
    ・HTTP Keep-Aliveの管理

• Web API
  • テスト
  • 公開と管理（Azure API Management）

• クライアント実装
  • Polly
  • クライアント SDKの開発

• API Gatewayの利用
  • 一般的機能
  • 監視
    • Azure API Management
    • ASP.NET Application Insights

• その他
  • ドキュメント

自動スケール †

水平方向のスケーリング

• アプリケーション設計

• クラウド機能の活用
  • PaaS組込の機能
  • Azure Monitor(上記のPaaSと組み合わせて利用)

• 関連のあるパターンとガイダンス
  • パターン
    • 競合コンシューマー パターン
    • スロットル パターン

• 監視と診断（アーキ・ガイド）

バックグラウンド ジョブ †

• トリガ
  • イベント ドリブン トリガー
  • スケジュール ドリブン トリガー。

• その他

• 結果の返送方法

• ホスティング環境

• パーティション分割（システム）

• 競合（リソース）

• 調整、回復性
  タスクの協調動作と補正
  • パイプとフィルター
  • Scheduler Agent Supervisor
  • 補正トランザクション
  • 冪等性

• スケーリング

• 関連のあるパターンとガイダンス
  • キュー ベースの負荷平準化
  • 優先順位キュー パターン

キャッシュ †

• 注意点
  • 高可用性の実装、スケーラビリティ・パフォーマンスの向上
  • コンカレンシーの管理、最終的な整合性
    • データをキャッシュするタイミングを決める
    • データを効率的にキャッシュする方法を決める
    • 非常に動的なデータをキャッシュする
    • キャッシュ内のデータの有効期限を管理する
    • クライアント側キャッシュ内のデータを無効にする

• Redis Cache

Content Delivery Network (CDN) †

• ルーティングとバージョン管理
• キャッシュ制御
• セキュリティ
• CDN フォールバック

データのパーティション分割 †

• パーティションの設計
  • 水平的パーティション分割 (行方向、シャーディング)
  • 垂直的パーティション分割（列方向）
  • 機能的パーティション分割（機能的）

• 関連のあるパターンとガイダンス
  • テーブルのインデックス作成
  • マテリアライズド・ビュー
  • シャーディング

データのパーティション分割戦略 (サービスごと) †

• Azure SQL Database のパーティション分割
• Azure Table Storage のパーティション分割
• Azure Blob Storage のパーティション分割
• Azure Queue Storage のパーティション分割
• Azure Service Bus のパーティション分割
• Cosmos DB のパーティション分割
• Azure Search のパーティション分割
• Azure Cache for Redis のパーティション分割
• Azure Service Fabric のパーティション分割
• Azure Event Hubs のパーティション分割

デプロイ スタンプ †

• データ ストアを含め、アプリケーション コンポーネントの複数の独立したコピーをデプロイする。

• 個々のコピーは "スタンプ" と呼ばれ、"サービス ユニット" または "スケール ユニット" と呼ばれる場合もある。

• このアプローチにより、
  • 顧客データを分離でき、
  • ソリューションのスケーラビリティが向上し、
  • インスタンスを複数のリージョンにデプロイすることが可能となる。

• 自動化された完全に反復可能なデプロイ プロセスを使用する

監視と診断 †

• 正常性の監視
• 可用性の監視
• パフォーマンスの監視
• セキュリティの監視
• SLA の監視
• ユーザー操作の監査
• 利用状況の監視
• 問題追跡
• 操作のトレース
• リリースのデバッグ
• 監視と診断のパイプライン
• 監視と診断のデータ ソース
• アプリケーションのインストルメント化
• データの収集と保存
• データの分析と問題の診断
• データの視覚化とアラートの生成

特定のサービスの再試行ガイダンス †

• Azure サービスの再試行機能
  https://docs.microsoft.com/ja-jp/azure/architecture/best-practices/retry-service-specific

一時的な障害の処理 †

• 標準の再試行機構が存在するかどうかを調べる。
• 操作を再試行するのが妥当かどうかを判断する。
• 適切な再試行回数と間隔を決める。
• アンチパターンを避ける。
• 再試行の戦略と実装をテストする。
• 再試行ポリシーの構成を管理する。
• 一過性の障害と一過性ではない障害を記録、追跡する。
• 絶えず失敗する操作に対処する。

チューニング †

• テレメトリでメトリックを収集できるようコードをインストルメント化する。

• 平均値によって、外れ値が解らなくなる可能性があるので、
  90/95/99 パーセンタイルパーセンタイル値を閾値にも監視する。

• 一度に１つのボトルネックに取り組む
  （ボトルネックを取り除くと、次の別のボトルネックが明らかになる）

• エラーと再試行は、パフォーマンスに大きな影響を与える可能性がある。

• 並列、分散化できる可能性を探す（パーティション分割）。

• 1 つの操作を包括的にエンドツーエンドで把握するのは困難になる。
• 一貫性のあるビューを取得するにはログとメトリックを 1 か所で集計する。

• 自動スケールは、
  • 基の問題が解らなくなる可能性がある。
  • また、スケールアウト・スケールインの閾値も解らなくなる。

• カスケード エラー
  • エラーが連鎖して根本原因とは
    異なるコンポーネントでシグナルが現れる
  • 上流のエラーが原因で下流で障害が発生する。

分散トランザクション †

https://docs.microsoft.com/ja-jp/azure/architecture/performance/distributed-transaction

複数のバックエンド サービス †

https://docs.microsoft.com/ja-jp/azure/architecture/performance/backend-services

イベントのストリーミング †

https://docs.microsoft.com/ja-jp/azure/architecture/performance/event-streaming

アンチ・パターン †

• ビジー状態のデータベース
• ビジー状態のフロント エンド
• 頻度の高い I/O
• 余分なフェッチ
• 不適切なインスタンス化
• モノリシック永続化
• キャッシュなし
• 同期 I/O

参考 †

Microsoft Docs †

• Azure Architecture Center
  • Azure アプリケーション アーキテクチャ ガイド
    https://docs.microsoft.com/ja-jp/azure/architecture/guide/

アーキテクチャ スタイル †

https://docs.microsoft.com/ja-jp/azure/architecture/guide/architecture-styles/

10 の設計原則 †

https://docs.microsoft.com/ja-jp/azure/architecture/guide/design-principles/

技術選定 †

https://docs.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/

ベスト・プラクティス †

https://docs.microsoft.com/ja-jp/azure/architecture/best-practices/

チューニング †

https://docs.microsoft.com/ja-jp/azure/architecture/performance/

その他 †

多言語パーシステンス †

• Scott Leberknight氏、多言語パーシステンスについて語る
  https://www.infoq.com/jp/news/2009/08/leberknight-polyglot-persistence/

HATEOAS †

• RESTFul APIsにおいてHATEOASを使用する利点
  https://www.infoq.com/jp/news/2009/04/hateoas-restful-api-advantages/
• RailsのAPIにHATEOASを散りばめてみる : RESTの拡張、HATEOASの詳解と実装例 | POSTD
  https://postd.cc/sprinkle-some-hateoas-on-your-rails-apis/

---

Tags: :アーキテクチャ, :クラウド系開発

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.064 sec.