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

目次

概要

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

詳細

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

アーキテクチャ スタイル

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

Azure Batch (HPC) 推しらしい。

ビッグ データ

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

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

マイクロサービス

  • 真面目にやると沼。

n 層アプリケーション

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

Web キューワーカー

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

設計原則

自動修復機能の設計

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

すべてを冗長化

  • 複数のリージョンにデプロイ

調整を最小限に抑える

  • その他
    • ドメイン イベントと同期
  • 並列の分散アルゴリズム(ビッグデータ系の分散)

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

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

  • 垂直方向
    システム、アプリで構成する。
    • ボトルネックの特定、ワークロードの分解など。
    • タスクのオフロード(バックグラウンド・ジョブ化)
  • 水平方向
    クラウド機能で構成する。
    • サーバー・ステートレス
    • スケールアウト・スケールイン
    • 自動スケール

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

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

  • システム
    • データベース
    • キューまたはメッセージ バス
    • App Service Web アプリ
  • 列方向
    簡単に言うとテーブルの分割
  • 機能的
    請求書テーブルと製品在庫テーブルを分割

操作に合わせた設計

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

管理対象サービスの使用

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

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

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

改良を見込んだ設計

SOAっぽい(疎結合)。

  • 高凝集と疎結合
    • サービスを個別にデプロイ
    • 共通機能を専用のサービスにオフロード
  • ゲートウェイにはドメイン ナレッジを実装しない
    • ドメイン ナレッジをカプセル化
    • オープン インターフェイスを公開
    • 非同期メッセージングを使用

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

  • 成長に対応可能な計画とコストの管理
  • 目標復旧時間 (RTO)、目標復旧時点 (RPO)、最大許容停止時間 (MTO)
  • サービス レベル アグリーメント (SLA) とサービス レベル目標 (SLO)
  • 要件
    • 機能要件と非機能要件
    • ワークロード別に分けて要件を判断
  • ビジネス ドメインを中心にアプリケーションをモデル化(DDD)

技術選定

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

適切なモンを使えと。

データ ストアの選択

適切なモンを使えと。

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

負荷分散サービスの選択

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

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

色々あるらしい。

  • Azure Service Bus
  • Event Grid
  • Event Hubs

ベスト・プラクティス

API 設計

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

API 実装

  • サーバー実装
  • クライアント実装
    • Polly
    • クライアント SDKの開発
  • その他
    • ドキュメント

自動スケール

水平方向のスケーリング

  • クラウド機能の活用

バックグラウンド ジョブ

  • トリガ
    • イベント ドリブン トリガー
    • スケジュール ドリブン トリガー。
  • その他
  • 結果の返送方法
  • 競合(リソース)
  • スケーリング

キャッシュ

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

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 の監視
  • ユーザー操作の監査
  • 利用状況の監視
  • 問題追跡
  • 操作のトレース
  • リリースのデバッグ
  • 監視と診断のパイプライン
  • 監視と診断のデータ ソース
  • アプリケーションのインストルメント化
  • データの収集と保存
  • データの分析と問題の診断
  • データの視覚化とアラートの生成

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

一時的な障害の処理

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

チューニング

  • テレメトリでメトリックを収集できるようコードをインストルメント化する。
  • 平均値によって、外れ値が解らなくなる可能性があるので、
    90/95/99 パーセンタイルパーセンタイル値を閾値にも監視する。
  • 一度に1つのボトルネックに取り組む
    (ボトルネックを取り除くと、次の別のボトルネックが明らかになる)
  • エラーと再試行は、パフォーマンスに大きな影響を与える可能性がある。
  • 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

アーキテクチャ スタイル

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/

その他

多言語パーシステンス

HATEOAS


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-03-24 (火) 21:15:18 (105d)