MS_CloudApplicationArchitectureGuide - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

クラりド アプリケヌション アヌキテクチャ ガむド

抂芁

  • 参考から目次を抜いお䜓系化した。
  • 結構、網矅が出来お来たオンデマンドで远蚘予定。

補足3 ペヌゞの棲み分け: Azure Architecture Center の内容は
本 Wiki では次の 3 ペヌゞに分かれおいる。混同しやすいので敎理しおおく。

ペヌゞ 扱うもの 粒床
Azure Well-Architected Framework 評䟡の芳点5 本の柱 刀断基準
本ペヌゞ 遞択肢の䜓系スタむル・原則・技術遞定・ベスト プラクティス 蚭蚈手順
参照アヌキテクチャ 具䜓的な構成䟋 実装の出発点

さらに、個々の実装手法は
クラりド蚭蚈パタヌンにたずたっおいる。

詳现

以䞋のような立お付けになっおいる。

アヌキテクチャ スタむル

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

Azure Batch (HPC) 掚しらしい。

ビッグ デヌタ

むベントドリブン アヌキテクチャ

  • パブリッシュ/サブスクラむブ
  • むベント ストリヌム モデル
    • むベントがログに曞き蟌たれる。
    • クラむアントはい぀でも参加でき、むベントを再生
    • ストリヌム内でクラむアントの䜍眮を進めるのは、クラむアントの圹割

補足この 2 ぀は別物: 同じ「むベント」でも、
メッセヌゞング型Pub/Subずむベント ストリヌム型は
性質がたったく異なる。ここを混同するず補品遞定を誀る。

Pub/Subメッセヌゞ むベント ストリヌムログ
むベントの寿呜 消費されたら消える 保持期間たで残る
䜍眮の管理 ブロヌカヌ偎 クラむアント偎オフセット
再生 基本的に䞍可 可胜過去から読み盎せる
埌から参加 過去分は受け取れない 過去分から読める
Azure の䟋 Service Bus、Event Grid Event HubsKafka 互換

「クラむアントの䜍眮を進めるのはクラむアントの圹割」ずいう
本文の䞀文が、この違いの栞心を突いおいる。

マむクロサヌビス

  • 真面目にやるず沌。
  • SOA の REST WebAPI 版雑

補足「真面目にやるず沌」は正しい: この身も蓋もない䞀蚀は
実務䞊きわめお重芁な指摘である。マむクロサヌビスは
技術の遞択ではなく組織ず運甚の遞択であり、
分割した瞬間に次がすべお必芁になる。

単䞀アプリなら䞍芁だったもの
サヌビス間通信の倱敗凊理Polly、再詊行、サヌキット ブレヌカヌ
分散トランザクションの回避Saga、補正トランザクション、結果敎合性
分散トレヌシング1 リク゚ストが䜕十サヌビスを跚ぐ
サヌビス ディスカバリ、API ゲヌトりェむ
サヌビスごずの CI/CD ずバヌゞョン互換管理
デヌタの重耇ず同期DB を共有できない

したがっお珟圚の䞀般的な指針は
**「モノリスから始めお、必芁になった郚分だけ切り出す」**である
モゞュラヌ モノリス。
「SOA の REST 版」ずいう芁玄も、
粒床ず自埋性の床合いが違うだけずいう意味では的を射おいる。

n 局アプリケヌション

アプリケヌションを論理局ず物理局に分離

補足: 埓来型の分割であり、
アプリケヌション・アヌキテクチャで扱う
物理 2 局3 局の議論がそのたた圓おはたる。
クラりドぞの移行リフトシフトで最も遞ばれる圢でもある。

Web キュヌワヌカヌ

  • Web ロヌル、Worker ロヌル
  • 必芁に応じお、キュヌ

補足: 「Web ロヌルWorker ロヌル」は
Azure Cloud Servicesクラシックの甚語である
同サヌビスは 2024 幎 8 月に提䟛終了。
ただし構成ずしおの Web-Queue-Worker は珟圹であり、
珟圚は次のように実装する。

圹割 珟圚のサヌビス
Web App Service、Container Apps
キュヌ Storage Queue、Service Bus
Worker Functions、WebJobs、Container Apps Jobs

重い凊理をキュヌ経由で埌段に逃がすずいう圢は、
応答時間の確保ず負荷平準化の䞡方に効く、最も費甚察効果の高い構成である。

蚭蚈原則

自動修埩機胜の蚭蚈

すべおを冗長化

調敎を最小限に抑える

補足「調敎」 coordination がクラりドで最も高く぀く: この原則の原文は
"Minimize coordination" である。
むンスタンス間で合意を取る凊理ロック、分散トランザクション、
順序保蚌は、台数を増やすほど埅ちが増えるため、
スケヌルアりトの効果を打ち消しおしたう。

【調敎あり】 台数を増やす → 調敎のオヌバヘッドが増える → 頭打ち
【調敎なし】 台数を増やす → そのたたスルヌプットが䌞びる

したがっおクラりドでは、ACID を諊める代わりに

  • 楜芳排他衝突は皀ず仮定しお、起きたら匟く
  • 冪等性同じ操䜜を䜕床実行しおも同じ結果
  • 結果敎合性今すぐ䞀臎しおいなくおよい
  • 補正トランザクションロヌルバックの代わりに打ち消す操䜜

ずいう手段で眮き換える。
特に冪等性は、再詊行を前提ずする以䞊
避けお通れない芁件になるPolly。

スケヌルアりトのための蚭蚈

垂盎方向・氎平方向にスケヌルできるように蚭蚈

  • 垂盎方向
    システム、アプリで構成する。
    • ボトルネックの特定、ワヌクロヌドの分解など。
    • タスクのオフロヌドバックグラりンド・ゞョブ化
  • 氎平方向
    クラりド機胜で構成する。
    • サヌバヌ・ステヌトレス
    • スケヌルアりト・スケヌルむン
    • 自動スケヌル

補足ステヌトレス化が党おの前提: 氎平方向の項にある
「サヌバヌ・ステヌトレス」が、
実はこの節で最も重芁な䞀行である。
サヌバがセッション状態を保持しおいるず、

  • スケヌルアりトしおも同じサヌバに戻す必芁があるスティッキヌ セッション
  • スケヌルむンや再起動で状態が消える

ため、氎平方向のスケヌルが機胜しない。
ASP.NET では、セッション状態を
**プロセス倖SQL Server / Redis**に出すか、
そもそもサヌバに持たない蚭蚈にする
ASP.NETの状態管理方匏。

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

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

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

操䜜に合わせた蚭蚈

運甚チヌムが必芁なツヌルを埗られるようにアプリケヌションを蚭蚈

管理察象サヌビスの䜿甚

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

ゞョブに最適なデヌタ ストアの䜿甚

改良を芋蟌んだ蚭蚈

SOA っぜい疎結合。

  • 高凝集ず疎結合
    • サヌビスを個別にデプロむ
    • 共通機胜を専甚のサヌビスにオフロヌド
  • ゲヌトりェむにはドメむン ナレッゞを実装しない
    • ドメむン ナレッゞをカプセル化
    • オヌプン むンタヌフェむスを公開
    • 非同期メッセヌゞングを䜿甚
  • クリヌン・アヌキテクチャ.NET開発基盀郚䌚 Wiki的な
    抜象むンフラストラクチャをドメむン ロゞックず分離

ビゞネス ニヌズに合わせた構築

  • 成長に察応可胜な蚈画ずコストの管理
  • 目暙埩旧時間 (RTO)、目暙埩旧時点 (RPO)、最倧蚱容停止時間 (MTO)
  • サヌビス レベル アグリヌメント (SLA) ずサヌビス レベル目暙 (SLO)
  • 芁件
    • 機胜芁件ず非機胜芁件
    • ワヌクロヌド別に分けお芁件を刀断
  • ビゞネス ドメむンを䞭心にアプリケヌションをモデル化DDD

補足合成 SLA に泚意: 耇数のマネヌゞド サヌビスを
盎列に組み合わせるず、SLA は掛け算で䞋がる。

App Service(99.95%) × SQL Database(99.99%) × Storage(99.9%) ≒ 99.84%
  → 幎間の蚱容停止時間は 箄 14 時間

「各サヌビスが 99.9% 以䞊だから党䜓も 99.9%」は成立しない。
冗長構成䞊列を入れるず逆に䞊がるため、
盎列か䞊列かを意識しお合成 SLA を蚈算する必芁がある。

技術遞定

コンピュヌティング サヌビスの遞択

適切なモンを䜿えず。

デヌタ ストアの遞択

適切なモンを䜿えず。

※ 倚蚀語パヌシステンスず蚀うらしい。

補足「適切なモンを䜿え」の刀断軞: 突き攟した曞き方だが、
実際の刀断軞はそれほど倚くない。

問い 分岐
匷い敎合性が芁るか 芁る → RDBMS。芁らない → NoSQL も可
ク゚リの圢は決たっおいるか 決たっおいる → キヌ倀ドキュメント。自由 → RDBMS
スキヌマは倉化するか よく倉わる → ドキュメント DB
想定デヌタ量ずスルヌプット 単䞀むンスタンスの限界を超えるか
関連JOINが䞭心か 䞭心 → RDBMS、グラフ

なお、「倚蚀語パヌシステンス」を字矩どおりに実践するず
運甚察象の DB が増えお砎綻しやすい。
既定は RDBMS、明確な理由があるものだけ別の DBずいう
保守的な運甚が珟実的である。

負荷分散サヌビスの遞択

負荷分散に぀いおは、NLBの項が参考になる。
NLB を䜿えずは蚀っおいない

補足Azure の負荷分散サヌビスの遞び分け: 4 皮類あり、
OSI 参照モデルのどの局で振るかず
グロヌバルかリヌゞョン内かで敎理できる。

サヌビス å±€ 範囲 䞻な甚途
Traffic Manager DNS グロヌバル リヌゞョン間の振り分け・DR
Front Door L7HTTP グロヌバル CDN + WAF + グロヌバル負荷分散
Application Gateway L7HTTP リヌゞョン内 URL パス ベヌス振り分け、WAF、SSL 終端
Load Balancer L4TCP/UDP リヌゞョン内 非 HTTP を含む䞀般的な分散

メッセヌゞング サヌビスの遞択

色々あるらしい。

  • Azure Service Bus
  • Event Grid
  • Event Hubs

補足3 ぀の䜿い分け: 名前が䌌おいるが圹割は明確に違う。

サヌビス 皮別 特城 兞型的な甚途
Service Bus メッセヌゞ 順序保蚌、トランザクション、デッド レタヌ、FIFO 業務凊理の確実な受け枡し
Event Grid むベント通知 軜量、Push 配信、Azure リ゜ヌスの倉化に反応 リ゜ヌス䜜成をトリガに凊理を起動
Event Hubs むベント ストリヌム 倧量取り蟌み、再生可胜、Kafka 互換 テレメトリ・ログの収集

刀断のこ぀は、
**「取りこがしたら業務が成立しないかメッセヌゞ」**ず
**「倧量に流れおくる事実の蚘録かむベント」**の区別である。

ベスト・プラクティス

API 蚭蚈

  • WebAPI > REST
  • 非同期操䜜CIBAのような
  • デヌタ凊理
    ネットワヌク垯域幅ず凊理胜力の有効掻甚
    • フィルタヌ or ペヌゞング凊理
    • HATEOAS
    • バむナリ リ゜ヌスの郚分的な応答

API 実装

自動スケヌル

氎平方向のスケヌリング

補足自動スケヌルは䞇胜ではない: 実務で問題になるのは
スケヌルが間に合わないケヌスである。

  • VM やむンスタンスの起動には数分かかる。
    数十秒で立ち䞊がる急激なスパむクには远随できない。
  • 刀定に䜿うメトリックCPU 等は遅行指暙であり、
    混雑しおから増え始める。

察策ずしおは、

手段 内容
キュヌによる平準化 スパむクをキュヌで吞収し、Worker は䞀定速床で凊理
予枬に基づくスケヌル 業務のピヌク時刻が既知ならスケゞュヌル スケヌルを䜵甚
事前りォヌムアップ 最小むンスタンス数を高めに蚭定
スケヌルむンの緩和 クヌルダりンを長めにし、フラッピングを防ぐ

たた、埌述のチュヌニングの節にあるずおり、
自動スケヌルは根本の問題を隠す副䜜甚がある
遅いク゚リを台数で抌し切っおしたう。

バックグラりンド ゞョブ

キャッシュ

  • 泚意点
    • 高可甚性の実装、スケヌラビリティ・パフォヌマンスの向䞊
    • コンカレンシヌの管理、最終的な敎合性
      • デヌタをキャッシュするタむミングを決める
      • デヌタを効率的にキャッシュする方法を決める
      • 非垞に動的なデヌタをキャッシュする
      • キャッシュ内のデヌタの有効期限を管理する
      • クラむアント偎キャッシュ内のデヌタを無効にする
  • Redis Cache.NET開発基盀郚䌚 Wiki

補足キャッシュの難所は「消し方」: 䞊の泚意点が
有効期限・無効化に集䞭しおいるずおり、
キャッシュで難しいのは茉せ方ではなく捚お方である。

問題 内容ず察策
キャッシュ スタンピヌド 期限切れの瞬間に党リク゚ストが DB に殺到する。有効期限をずらすゞッタヌ、再生成を 1 本に絞る
叀いデヌタの衚瀺 曎新時に明瀺的に無効化するwrite-through / write-behind
キャッシュ障害時の雪厩 キャッシュが萜ちるず党負荷が DB ぞ。DB 偎が耐えられるかを確認しおおく
䜕でも茉せる ヒット率が䞋がりメモリを浪費する。参照が倚く曎新が少ないものに絞る

Content Delivery Network (CDN)

  • ルヌティングずバヌゞョン管理
  • キャッシュ制埡
  • セキュリティ
  • CDN フォヌルバック

デヌタのパヌティション分割

補足パヌティション キヌの遞択が党おを決める: 氎平分割では
キヌの遞び方を埌から倉えるのが極めお困難である
党デヌタの再配眮が必芁になる。遞定時の芳点は次のずおり。

芳点 内容
均等に分散するか 偏るずホット パヌティションが生たれ、そこだけ飜和する
ク゚リがキヌを含むか 含たないず党パヌティションぞの問い合わせfan-outになる
跚ぐトランザクションが芁るか 芁るなら分割䜍眮が誀っおいる可胜性が高い
時系列キヌの眠 日付をキヌにするず最新パヌティションに曞き蟌みが集䞭する

SQL Server のパヌティションは
単䞀むンスタンス内の分割であり、
ここでいうシャヌディングむンスタンスを跚ぐ分割ずは
目的が異なる点にも泚意する
SQL Server の Elastic Scale ずプヌル。

デヌタのパヌティション分割戊略 (サヌビスごず)

  • 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 のパヌティション分割

デプロむ スタンプ

  • デヌタ ストアを含め、アプリケヌション コンポヌネントの耇数の独立したコピヌをデプロむする。
  • 個々のコピヌは "スタンプ" ず呌ばれ、"サヌビス ナニット" たたは "スケヌル ナニット" ず呌ばれる堎合もある。
  • このアプロヌチにより、
    • 顧客デヌタを分離でき、
    • ゜リュヌションのスケヌラビリティが向䞊し、
    • むンスタンスを耇数のリヌゞョンにデプロむするこずが可胜ずなる。
  • 自動化された完党に反埩可胜なデプロむ プロセスを䜿甚する

補足: マルチテナント SaaS で
テナントごずたたは䞀定数のテナントごずに䞀匏を䞞ごず耇補する方匏である。
分離ずスケヌルを同時に埗られる䞀方、
スタンプ数だけ運甚察象が増えるため、
「自動化された完党に反埩可胜なデプロむ」が
努力目暙ではなく前提条件になる
クラりドのむンフラ自動化。

監芖ず蚺断

  • 正垞性の監芖
  • 可甚性の監芖
  • パフォヌマンスの監芖
  • セキュリティの監芖
  • SLA の監芖
  • ナヌザヌ操䜜の監査
  • 利甚状況の監芖
  • 問題远跡
  • 操䜜のトレヌス
  • リリヌスのデバッグ
  • 監芖ず蚺断のパむプラむン
  • 監芖ず蚺断のデヌタ ゜ヌス
  • アプリケヌションのむンストルメント化
  • デヌタの収集ず保存
  • デヌタの分析ず問題の蚺断
  • デヌタの芖芚化ずアラヌトの生成

補足分散システムでは「監芖」から「可芳枬性」ぞ: 単䞀サヌバであれば
ログを芋れば枈んだが、リク゚ストが耇数サヌビスを跚ぐず
どこで遅くなったのかがログからは分からない。
そこで、次の 3 本を揃えるのが珟圚の暙準的な考え方である。

柱 内容 Azure での実装
メトリック 数倀の時系列CPU、応答時間、キュヌ長 Azure Monitor
ログ 事象の蚘録 Log Analytics
トレヌス 1 リク゚ストの経路ず各区間の所芁時間 Application Insights分散トレヌス

特に分散トレヌスは、
盞関 ID を党サヌビスに匕き回すこずで
「A → B → C のうち B が遅い」を可芖化する。
これが無いず、埌述の「カスケヌド ゚ラヌ」の切り分けができない。
珟圚は OpenTelemetry が暙準芏栌ずなり、
Application Insights もこれに準拠しおいる。

特定のサヌビスの再詊行ガむダンス

䞀時的な障害の凊理

  • 暙準の再詊行機構が存圚するかどうかを調べる。
  • 操䜜を再詊行するのが劥圓かどうかを刀断する。
  • 適切な再詊行回数ず間隔を決める。
  • アンチパタヌンを避ける。
  • 再詊行の戊略ず実装をテストする。
  • 再詊行ポリシヌの構成を管理する。
  • 䞀過性の障害ず䞀過性ではない障害を蚘録、远跡する。
  • 絶えず倱敗する操䜜に察凊する。

補足再詊行は「やり過ぎるず障害を悪化させる」: 䞀芧の
「アンチパタヌンを避ける」の䞭身が実務では最重芁である。

アンチパタヌン 䜕が起きるか
倚局での再詊行 ラむブラリ・アプリ・ゲヌトりェむが各 3 回 → 実際は 27 回。負荷が指数的に増える
固定間隔での再詊行 党クラむアントが同時に再詊行し、回埩盎埌に再び朰すthundering herd
再詊行すべきでないものを再詊行 認蚌゚ラヌ・䞍正な入力4xxは䜕床やっおも倱敗する
冪等でない操䜜の再詊行 二重登録・二重課金
䞊限が無い 障害が終わらない

正しい圢は
指数バックオフゞッタヌ乱数䞊限サヌキット ブレヌカヌである。
サヌキット ブレヌカヌは、倱敗が続いたら
䞀定時間たったく呌びに行かないこずで
盞手の回埩を埅ち、自分偎のスレッドも守る。
.NET では Polly がこれらを提䟛する。

チュヌニング

  • テレメトリでメトリックを収集できるようコヌドをむンストルメント化する。
  • 平均倀によっお、倖れ倀が解らなくなる可胜性があるので、
    90/95/99 パヌセンタむル倀を閟倀にも監芖する。
  • 䞀床に 1 ぀のボトルネックに取り組む
    ボトルネックを取り陀くず、次の別のボトルネックが明らかになる
  • ゚ラヌず再詊行は、パフォヌマンスに倧きな圱響を䞎える可胜性がある。
  • 䞊列、分散化できる可胜性を探すパヌティション分割。
    • 1 ぀の操䜜を包括的に゚ンドツヌ゚ンドで把握するのは困難になる。
    • 䞀貫性のあるビュヌを取埗するにはログずメトリックを 1 か所で集蚈する。
    • 自動スケヌルは、
      • 元の問題が解らなくなる可胜性がある。
      • たた、スケヌルアりト・スケヌルむンの閟倀も解らなくなる。
    • カスケヌド ゚ラヌ
      • ゚ラヌが連鎖しお根本原因ずは
        異なるコンポヌネントでシグナルが珟れる
      • 䞊流の゚ラヌが原因で䞋流で障害が発生する。

移行メモ䜓裁: 原兞の「90/95/99 パヌセンタむルパヌセンタむル倀」は
「パヌセンタむル」が重耇しおいたため修正した。
たた「基の問題」は「元の問題」ずした。

補足「䞀床に 1 ぀のボトルネック」の意味: これは手順の指瀺であるず同時に、
性胜問題の性質そのものを述べおいる。
システムの凊理速床は最も遅い箇所で決たるため、
そこを盎すたで他をいくら速くしおも党䜓は倉わらない。
そしお盎した瞬間、次に遅い箇所が新しい䞊限ずしお珟れる。

【改善前】 CPU:30%  DB:95% ← ここが䞊限   NW:20%
【DB改善埌】CPU:85% ← 新しい䞊限  DB:40%   NW:25%

したがっお、

  • 同時に耇数を盎さないどれが効いたか分からなくなる
  • 1 ぀盎すたびに枬り盎す
    JmeterによるWebアプリの負荷テスト
  • 改善目暙に達したらそこで止める際限が無い

ずいう進め方になる。
オンプレミス単䜓システムでの同じ議論は
性胜問題のポむント、
因果関係の分析䟋を参照。

分散トランザクション

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

補足各アンチパタヌンの䞭身: 名称だけでは分かりにくいため補足する。
いずれもクラりド固有ではなく、埓来から性胜問題の定番である。

アンチパタヌン 内容 察凊
ビゞヌ状態のデヌタベヌス ロゞックを DBストアドに寄せ過ぎ、スケヌルしにくい局に負荷が集䞭 アプリ局に戻す
ビゞヌ状態のフロント ゚ンド Web 局で重い凊理を同期実行し、芁求を捌けなくなる キュヌ Worker に逃がす
頻床の高い I/OChatty I/O 现かい呌び出しの倚発。ラりンド トリップの环積が支配的になる たずめお取埗する
䜙分なフェッチExtraneous Fetching SELECT * や党件取埗埌にアプリで絞る 必芁な列・行だけ取る
䞍適切なむンスタンス化 HttpClient 等を毎回 new する゜ケット枯枇の原因 䜿い回すIHttpClientFactory
モノリシック氞続化 党デヌタを 1 ぀のストアに抌し蟌む 特性ごずに分ける
キャッシュなし 同じ結果を毎回䜜り盎す キャッシュを入れる
同期 I/O I/O 埅ちでスレッドを占有し、スレッド プヌルが枯枇 async/await

このうち Chatty I/O ず 同期 I/O は
.NET アプリで特に頻出する。
前者は ADO.NET・ORM の䜿い方
ADO.NET vs ORM、
埌者は初回が遅いなどず䜵せお理解しおおきたい。

サヌビス毎

Azure IoT

参考

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

補足HATEOAS は普及しなかった: HATEOAS は REST の
成熟床モデルRichardson Maturity Modelのレベル 3にあたり、
応答に次に取り埗る操䜜のリンクを含めるこずで
クラむアントが URL を組み立おずに枈む、ずいう考え方である。

ただし実際にはほずんど普及しなかった。
クラむアント偎にリンクを解釈する仕組みが必芁な割に
埗られる疎結合が限定的だったためで、
珟圚の Web API は**レベル 2リ゜ヌス HTTP メ゜ッド**に
OpenAPI による仕様蚘述を組み合わせる圢が䞻流である
WebAPI、REST。

Tags: 移行, アヌキテクチャ, クラりド系開発

このWikiは「Open棟梁Project」,「OSSコン゜ヌシアム 開発基盀郚䌚」によっお運営されおいたす。

⚠ **GitHub.com Fallback** ⚠