![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>アーキテクチャ設計]] * 目次 [#h6747479] #contents *概要 [#w7763973] -[[参考>#t8f6cd32]]から目次を抜いて体系化した。 -結構、網羅が出来て来た（オンデマンドで追記予定）。 *詳細 [#gaec9e0b] 以下のような立て付けになっている。 **アーキテクチャ スタイル [#z4be5a2f] ***ビッグ コンピューティング [#y5a64662] Azure Batch (HPC) 推しらしい。 ***[[ビッグ データ>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF]] [#gb32cf50] ***イベントドリブン アーキテクチャ [#i151f65f] -[[パブリッシュ/サブスクライブ>クラウド設計パターン#we34db20]] -イベント ストリーム モデル --イベントがログに書き込まれる。 --クライアントはいつでも参加でき、イベントを再生 --ストリーム内でクライアントの位置を進めるのは、クライアントの役割 ***マイクロサービス [#n23c0f60] -真面目にやると沼。 -SOAの[[REST WebAPI>#n2ef0ae7]]版（雑） ***n 層アプリケーション [#z12e0109] アプリケーションを論理層と物理層に分離 ***Web キューワーカー [#n91ccc69] -Webロール、Workerロール -必要に応じて、キュー **設計原則 [#f09541eb] ***自動修復機能の設計 [#qe6679ef] -[[Polly>Polly(Retry, Circuit Breaker, Timeout, Bulkhead, Fallback)]] ＋ [[Pollyで足りていないサーバ実装>Polly(Retry, Circuit Breaker, Timeout, Bulkhead, Fallback)#e81e1274]] -[[フェイル・オーバー>高信頼性設計のポイント#t09e8fc8]] -パターン --[[補正トランザクション>クラウド設計パターン#d113b16e]] --[[リーダー選択>クラウド設計パターン#b5489904]] -その他 --フォールト挿入でテストする。 --Chaos エンジニアリングを利用する。 ***すべてを冗長化 [#qfea7327] -[[従来型のフェイル・オーバーに加え。>#qe6679ef]] -[[システム・データのパーティション分割>#c1a7c7a9]] -複数のリージョンにデプロイ --geo レプリケーション --[[Traffic Manager>Azureの高可用性設計#wfcf8512]] ***調整を最小限に抑える [#nb44cea4] -トランザクション（ACID特性）以外の実現方法を検討する。 --[[楽観排他>DBMSのロック・分離戦略と同時実行制御#fcfbae68]] --[[補正トランザクション>クラウド設計パターン#d113b16e]] --[[データのパーティション分割>#c1a7c7a9]] -その他 --ドメイン イベントと同期 --読取 / 書込ワークロードの競合を削減 ---[[イベント ソーシング>クラウド設計パターン#gd32eb7b]] ---[[コマンド クエリ責務分離 (CQRS)>クラウド設計パターン#z972b50e]] --別のインスタンス ---冪等操作の設計 ---[[リーダー選定>クラウド設計パターン#b5489904]] --並列の分散アルゴリズム（ビッグデータ系の分散） ***スケールアウトのための設計 [#b899f21a] 垂直方向・水平方向にスケールできるように設計 -垂直方向~ システム、アプリで構成する。 --ボトルネックの特定、ワークロードの分解など。 --タスクのオフロード（バックグラウンド・ジョブ化） -水平方向~ クラウド機能で構成する。 --サーバー・ステートレス --スケールアウト・スケールイン --[[自動スケール>#x277761f]] ***パーティション分割による制限の回避 [#c1a7c7a9] スケール・アップに限界があるので、パーティション分割。 -システム --データベース --キューまたはメッセージ バス --App Service Web アプリ -データベース --行方向 ---[[SQL Server パーティション分割]] ---[[シャーディング>クラウド設計パターン#i8ed3766]] --列方向~ 簡単に言うとテーブルの分割 --機能的~ 請求書テーブルと製品在庫テーブルを分割 ***操作に合わせた設計 [#d77bdaf2] 運用チームが必要なツールを得られるようにアプリケーションを設計 ***管理対象サービスの使用 [#z6a5c300] なるべく、[[PaaS / FaaS, SaaS>#c4803bbc]]を選択。 ***ジョブに最適なデータ ストアの使用 [#m8572b6f] -[[データ ストアの選択>#j2ff0ab1]] -[[調整を最小限に抑える>#nb44cea4]] -その他 --開発チームのスキルセット --コンテキスト境界を確認（DDD） ***改良を見込んだ設計 [#z58393db] SOAっぽい（疎結合）。 -高凝集と疎結合 --サービスを個別にデプロイ --共通機能を専用のサービスにオフロード -ゲートウェイにはドメイン ナレッジを実装しない --ドメイン ナレッジをカプセル化 --オープン インターフェイスを公開 --非同期メッセージングを使用 -[[クリーン・アーキテクチャ>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%83%BB%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3]]的な~ （抽象インフラストラクチャをドメイン ロジックと分離） ***ビジネス ニーズに合わせた構築 [#ded084da] -成長に対応可能な計画とコストの管理 -目標復旧時間 (RTO)、目標復旧時点 (RPO)、最大許容停止時間 (MTO) -サービス レベル アグリーメント (SLA) とサービス レベル目標 (SLO) -要件 --機能要件と非機能要件 --ワークロード別に分けて要件を判断 -ビジネス ドメインを中心にアプリケーションをモデル化（DDD） **技術選定 [#k95d0d83] ***コンピューティング サービスの選択 [#c4803bbc] 適切なモンを使えと。 -[[ホスティング環境>Azureの高可用性設計#j9978891]] -参照アーキテクチャ --[[IaaS>参照アーキテクチャ#e7e8cd61]] --[[PaaS / FaaS>参照アーキテクチャ#e426fc8a]] --[[SaaS>参照アーキテクチャ#p371a1a7]] ***データ ストアの選択 [#j2ff0ab1] 適切なモンを使えと。 -RDBMS([[SQL Server]]など) -[[NoSQL>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?NoSQL]] -, etc. ※ [[多言語パーシステンス>#gc2d31ea]]と言うらしい。 ***負荷分散サービスの選択 [#n234e875] 負荷分散については、[[NLB]]の項が参考になる。~ （[[NLB]]を使えとは言っていない） ***メッセージング サービスの選択 [#g243b803] 色々あるらしい。 -Azure Service Bus -Event Grid -Event Hubs **ベスト・プラクティス [#lc27f6c5] ***API 設計 [#n2ef0ae7] -[[WebAPI]] > [[REST]] -[[非同期操作>クラウド設計パターン#i947e3b1]]([[CIBA>CIBA(Client Initiated Backchannel Authentication)]]のような) -データ処理~ （ネットワーク帯域幅と処理能力の有効活用） --フィルター or ページング処理 --[[HATEOAS>#nccfbb60]] --バイナリ リソースの部分的な応答 ***API 実装 [#d9c56aed] -サーバー実装 --[[スケーラビリティ>#b899f21a]]、[[可用性>#qe6679ef]]、[[応答性>参照アーキテクチャ#z6ed15db]]の維持 ---非同期サポート ---ステートレス ---クライアントの~ ・追跡と調整~ ・HTTP Keep-Aliveの管理 --Web API ---テスト ---公開と管理（[[Azure API Management]]） -クライアント実装 --[[Polly>Polly(Retry, Circuit Breaker, Timeout, Bulkhead, Fallback)]] --クライアント SDKの開発 -[[API Gateway]]の利用 --[[一般的機能>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?API%20Gateway#y4ee7f24]] --監視 ---[[Azure API Management]] ---[[ASP.NET Application Insights>Azureの監視と管理#j415f034]] -その他 --ドキュメント ***自動スケール [#x277761f] 水平方向のスケーリング -[[アプリケーション設計>#b899f21a]] -クラウド機能の活用 --[[PaaS組込の機能>#c4803bbc]] --Azure Monitor(上記のPaaSと組み合わせて利用) -関連のあるパターンとガイダンス --パターン ---[[競合コンシューマー パターン>クラウド設計パターン#m8158a06]] ---[[スロットル パターン>クラウド設計パターン#r5f048d8]] --[[監視と診断>#mecb66f4]]（アーキ・ガイド） ***バックグラウンド ジョブ [#a1ddbf3e] -トリガ --イベント ドリブン トリガー --スケジュール ドリブン トリガー。 -その他 --結果の返送方法 --[[ホスティング環境>#c4803bbc]] --[[パーティション分割（システム）>#c1a7c7a9]] --競合（リソース） --調整、回復性~ タスクの協調動作と補正 ---[[パイプとフィルター>クラウド設計パターン#d56122e0]] ---[[Scheduler Agent Supervisor>クラウド設計パターン#d9b6b869]] ---[[補正トランザクション>クラウド設計パターン#d113b16e]] ---冪等性 --スケーリング -関連のあるパターンとガイダンス --[[キュー ベースの負荷平準化>クラウド設計パターン#m8158a06]] --[[優先順位キュー パターン>クラウド設計パターン#r5f048d8]] ***キャッシュ [#v32fc794] -注意点 --高可用性の実装、スケーラビリティ・パフォーマンスの向上 --コンカレンシーの管理、最終的な整合性 ---データをキャッシュするタイミングを決める ---データを効率的にキャッシュする方法を決める ---非常に動的なデータをキャッシュする ---キャッシュ内のデータの有効期限を管理する ---クライアント側キャッシュ内のデータを無効にする -[[Redis Cache>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?Redis%20Cache]] ***Content Delivery Network (CDN) [#tdd6c563] -ルーティングとバージョン管理 -キャッシュ制御 -セキュリティ -CDN フォールバック ***データのパーティション分割 [#o8cf4cf1] -パーティションの設計 --水平的パーティション分割 (行方向、シャーディング) --垂直的パーティション分割（列方向） --機能的パーティション分割（機能的） -関連のあるパターンとガイダンス --[[テーブルのインデックス作成>クラウド設計パターン#q19a433d]] --[[マテリアライズド・ビュー>クラウド設計パターン#t9eed998]] --[[シャーディング>クラウド設計パターン#i8ed3766]] ***データのパーティション分割戦略 (サービスごと) [#x7539ab4] -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 のパーティション分割 ***デプロイ スタンプ [#rfa6ef1d] -データ ストアを含め、アプリケーション コンポーネントの複数の独立したコピーをデプロイする。 -個々のコピーは "スタンプ" と呼ばれ、"サービス ユニット" または "スケール ユニット" と呼ばれる場合もある。 -このアプローチにより、 --顧客データを分離でき、 --ソリューションのスケーラビリティが向上し、 --インスタンスを複数のリージョンにデプロイすることが可能となる。 -自動化された完全に反復可能なデプロイ プロセスを使用する ***監視と診断 [#mecb66f4] -正常性の監視 -可用性の監視 -パフォーマンスの監視 -セキュリティの監視 -SLA の監視 -ユーザー操作の監査 -利用状況の監視 -問題追跡 -操作のトレース -リリースのデバッグ -監視と診断のパイプライン -監視と診断のデータ ソース -アプリケーションのインストルメント化 -データの収集と保存 -データの分析と問題の診断 -データの視覚化とアラートの生成 ***特定のサービスの再試行ガイダンス [#ga1c9efc] -Azure サービスの再試行機能~ https://docs.microsoft.com/ja-jp/azure/architecture/best-practices/retry-service-specific ***一時的な障害の処理 [#ea4840f2] -標準の再試行機構が存在するかどうかを調べる。 -操作を再試行するのが妥当かどうかを判断する。 -適切な再試行回数と間隔を決める。 -アンチパターンを避ける。 -再試行の戦略と実装をテストする。 -再試行ポリシーの構成を管理する。 -一過性の障害と一過性ではない障害を記録、追跡する。 -絶えず失敗する操作に対処する。 **チューニング [#sf92174b] -テレメトリでメトリックを収集できるようコードをインストルメント化する。 -平均値によって、外れ値が解らなくなる可能性があるので、~ 90/95/99 パーセンタイルパーセンタイル値を閾値にも監視する。 -一度に１つのボトルネックに取り組む~ （ボトルネックを取り除くと、次の別のボトルネックが明らかになる） -エラーと再試行は、パフォーマンスに大きな影響を与える可能性がある。 -並列、分散化できる可能性を探す（[[パーティション分割>#c1a7c7a9]]）。 --1 つの操作を包括的にエンドツーエンドで把握するのは困難になる。 --一貫性のあるビューを取得するにはログとメトリックを 1 か所で集計する。 --自動スケールは、 ---基の問題が解らなくなる可能性がある。 ---また、スケールアウト・スケールインの閾値も解らなくなる。 --カスケード エラー ---エラーが連鎖して根本原因とは~ 異なるコンポーネントでシグナルが現れる ---上流のエラーが原因で下流で障害が発生する。 ***分散トランザクション [#pe656b8c] https://docs.microsoft.com/ja-jp/azure/architecture/performance/distributed-transaction ***複数のバックエンド サービス [#a97a228f] https://docs.microsoft.com/ja-jp/azure/architecture/performance/backend-services ***イベントのストリーミング [#zabfc6e8] https://docs.microsoft.com/ja-jp/azure/architecture/performance/event-streaming ***アンチ・パターン [#ncdca084] -ビジー状態のデータベース -ビジー状態のフロント エンド -頻度の高い I/O -余分なフェッチ -不適切なインスタンス化 -モノリシック永続化 -キャッシュなし -同期 I/O **サービス毎 [#l2f69b36] ***[[Azure IoT>Microsoft Azure IoT#u9e76988]] [#daa49ba8] *参考 [#t8f6cd32] **Microsoft Docs [#if55fe9b] -Azure Architecture Center --Azure アプリケーション アーキテクチャ ガイド~ https://docs.microsoft.com/ja-jp/azure/architecture/guide/ ***アーキテクチャ スタイル [#d27a4c5c] https://docs.microsoft.com/ja-jp/azure/architecture/guide/architecture-styles/ ***10 の設計原則 [#scc533d0] https://docs.microsoft.com/ja-jp/azure/architecture/guide/design-principles/ ***技術選定 [#a6bb1af4] https://docs.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/ ***ベスト・プラクティス [#w3bc7d7e] https://docs.microsoft.com/ja-jp/azure/architecture/best-practices/ ***チューニング [#p29c3cc5] https://docs.microsoft.com/ja-jp/azure/architecture/performance/ **その他 [#j1a18824] ***多言語パーシステンス [#gc2d31ea] -Scott Leberknight氏、多言語パーシステンスについて語る~ https://www.infoq.com/jp/news/2009/08/leberknight-polyglot-persistence/ ***HATEOAS [#nccfbb60] -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: [[:アーキテクチャ]], [[:クラウド系開発]]
