ToppyMicroServices

RFC 3439 Quiz

大規模systemを単純に保つ判断

🇺🇸🇯🇵
0 / 0

References (URLs)

範囲: RFC 3439はInformationalなarchitecture指針です. この問題では設計上のriskとtrade-offを見つける視点として使い, protocol適合性のchecklistとしては扱いません.

Q1: RFC 3439 Sections 2, 2.4, and 3.1を設計reviewの視点として使う場合, 最も適切な評価はどれか?

Multiple Choice

署名検証とroutingを行うA2A gatewayが10,000 tenantで稼働している。新しい利用分析はbest effortでよく、停止してもrequest処理のSLOを維持する必要がある。案Xはtenant別分析rule、payload正規化、retry coordinationを全gatewayの必須経路へ追加し、rule変更のたびに全gatewayを同時更新する。案Yはgatewayから非同期eventを送り、利用tenantだけが独立したcollectorを有効にする。

**Explanation:** Bが最も適切です. RFC 3439 Section 2はcomplexityを大規模化とCAPEX・OPEXの妨げとして扱い, Section 2.4はcore全体を更新する構成と参加するedgeだけが採用する構成を対比します. Section 3.1はlocal optimizationがcomplexityとcouplingを増やし得ると注意します. A: 1つのdeployment unitでも, path dependency, 同時更新, failure scopeは消えません. B: best effortという前提では正解です. 案Yは任意処理を必須経路から外し, coordinated changeを限定します. C: RFC 3439はcentral retryを要求せず, この主張はcouplingへの懸念を逆転させています. D: source code量はpossible metricの1つにすぎず, 運用上のdependencyを表しません. RFC 3439は設計指針であり, 案Yを適合要件として強制しません. 分析がauthorizationや必須の監査証拠になれば前提が変わり, 案Yを再評価する必要があります.

Q2: RFC 3439のcore stateに関する議論から導けるreview結論はどれか?

Multiple Choice

A2A routing fabricはregion単位に集約したrouteを保持します. 新案は全task ID, token expiry, retry count, conversation stateも全transit gatewayへ複製します. endpointは全gatewayで対応stateを再構築せずにtaskをrestartできる必要があります.

**Explanation:** RFC 3439 Section 2.1はcoreにrouteなどの粗粒度stateが存在すると明記します. 問題にするのはそのstateとend-to-end communication stateのinteractionです. A: 文字どおりstatelessなcoreを要求していません. B: per-session replicationはfateとupgradeのcouplingを増やし, 自動的な改善にはなりません. C: 正解. routingに必要なstateを残しながら, restart要件と衝突する新dependencyを検討します. D: RFC 3439はInformationalな指針であり, gateway schemaを規定しません.

Q3: このamplification pathへの対策として最も適切なのはどれか?

Multiple Choice

1 tenantのverification-key URLを変えると, controllerが10,000 gatewayのcacheを同時にinvalidateして再計算します. CPU saturationにより無関係なtenantも遅延します. 変更を届ける必要があるのは現在そのtenantを扱うgatewayだけで, 5分以内の収束を許容できます.

**Explanation:** RFC 3439 Section 2.2.1のAmplification Principleは, 小さなinputがscale時に不釣り合いに大きなeventを生むと説明します. この設問ではbounded staged convergenceが許容されています. A: synchronized retryは別のamplification mechanismを加えます. B: 正解. 影響をlocalizeし, fleet-wideな同時反応を避けながら収束条件を満たします. C: uniformityは無関係なtenantとnodeへの処理を正当化しません. D: future updateを止めると, load問題をstale security metadataへ置き換えます.

Q4: Coupling Principleが最も支持する対応はどれか?

Multiple Choice

clientはfailureを1秒ごとにretryします. gateway autoscalerとbackend circuit breakerも1秒windowで判断します. overload時に3つが繰り返し同期し, 一時回復しては再びfailureになります.

**Explanation:** RFC 3439 Section 2.2.2はtight couplingとsynchronizationを予期しないfailure stateへ関連付け, randomnessの注入をcoupling低減法の1つとして示します. A: common clockは設問で観測したphase-lockingを強めます. B: 別のsynchronized controllerは原因を除かずinteractionを増やします. C: 正解. bounded jitterで同期を弱め, system testでisolated logicではなくinteractionを評価します. D: control loopが相互作用する場合, component safetyはsystem safetyを証明しません.

Q5: 前提に最も合う配置判断はどれか?

Multiple Choice

document summarizationはoptionalで, 利用tenantは2%です. failureしてもmessage deliveryをblockしてはいけません. 案Aは全gatewayへmodel runtimeを追加し, 案Bは参加tenantだけが別配備のedge serviceを呼び出します.

**Explanation:** RFC 3439 Section 2.4はfleet-wideなsmart-core upgradeと参加edgeだけによるadoptionを対比します. 前提ではsummarizationはoptionalでdelivery SLOの外です. A: 必要になる前から全fleetへruntime, update, failureを課します. B: この要件では正解です. deliveryを依存させず, 参加tenantだけが採用できます. C: RFCは指針を示しますが, intermediary機能を全面禁止しません. D: upgradeとfailure couplingは比較の中心です. 必須securityまたはaudit機能なら評価は変わります.

Q6: layeringへの批判を正しく適用するreview actionはどれか?

Multiple Choice

A2A clientはtask layerでretryし, proxyはHTTP requestをretryし, transport libraryはreconnectします. 各layerは異なるtimeoutを持ち, task deadlineを参照できません. duplicate executionは有害ですが, modular ownershipはproject要件です.

**Explanation:** RFC 3439 Sections 3と3.1はlayeringの構造的価値を認めつつ, 機能重複, 情報隠蔽, local optimization, tight couplingへ注意します. A: 全module boundaryを削除する要件ではありません. B: 設問ではtimeoutが合成され, duplicate workがlayer外へ漏れるinteractionを示しています. C: 正解. modularityを捨てずに重複したrecovery ownershipを除き, coherent decisionに必要なdeadlineを与えます. D: harmful actionを制御せず, 事後処理のcomplexityを加えます.

Q7: Minimum Interventionを最も尊重するgateway動作はどれか?

Multiple Choice

gatewayは受信したAgent messageのsignatureを検証します. downstream verifierも元のsigned representationを必要とします. gatewayはそのまま運べますが, universal schema案は全fieldを書き換えます. normalized viewが必要なのはoptional analyticsだけです.

**Explanation:** RFC 3439 Section 4のMinimum Interventionは, 可能ならpayloadを受信したまま変更せず運ぶと述べます. この設問ではsigned representationの維持も明示的なdownstream要件です. A: 新しいsigned contractがなければ, rewriteによりdownstream signature validationに必要なrepresentationを失います. B: 正解. 必要なevidenceを保ち, optional normalizationをconsumerへ限定します. C: 同原則はtransparent carriageを支持し, edge encapsulationを否定しません. D: 未定義transformationはsemantic divergenceとcouplingを増やします. securityのためcanonicalizationが必要なら, signed dataをad hocに変えず, 明示したinput/signing boundaryで定義します.

Q8: 前提上のriskが低いinterworking boundaryはどれか?

Multiple Choice

2つのA2A domainはlease, revocation, retry, delegationのstate machineが非互換です. bridgeは両control planeを双方向変換するか, 各domainがcontrol stateを保持したままedgeでmessageをencapsulateできます. control model間のisomorphismは示されていません.

**Explanation:** RFC 3439 Sections 3.4.1, 4, and 4.1はedgeでのdata-plane interworkingを支持し, control-plane interworkingが多数のfailure機会を生むと注意します. 一方でisomorphismを示せる例外も認めます. A: 証明されていないsemantic translationはfailure modeを減らさず追加します. B: universal interworking functionはSection 4が警告するpatternです. C: このuncertaintyでは正解です. couplingを限定し, control semanticsが証明されencapsulationでは要件を満たせない場合をchange triggerとして残します. D: replicationは無関係なtransit nodeへstateとupgrade surfaceを広げます.

Q9: RFC 3439がこのreliability reviewで支持できる結論はどれか?

Multiple Choice

serviceのavailability objectiveは99.99%です. 案Xは2つの単純な99.9% componentとfailoverを使います. 案Yは1つの99.999% componentと複雑なoperator recovery processを使います. common-mode failure, repair time, failover成功率は未計測です.

**Explanation:** RFC 3439 Section 7は, 全complex component自体がfive-nines system targetを満たすべきという仮定を疑い, recovery mechanism追加がcomplexity/robustness spiralを招く可能性を示します. A: independence, repair, failover dataなしにavailabilityを単純乗算できません. B: 同sectionが疑うcomponent-level assumptionです. C: 正解. 指針は何を疑うかを示しますが, missing measurementにより設計選択まではできません. D: packet switchingでもcomponentとoperation failureは無関係になりません.

Q10: この7-component service pathについて正当化できる結論はどれか?

Multi-Select

全A2A requestは独立配備された7つのbroker, translator, policy engine, audit serviceを通ります. uniqueなauthorizationまたはevidence要件を持つcomponentがある可能性がありますが, ownershipとfailure dependencyは未整理です. 小規模testでは動作します.

**Explanation:** RFC 3439 Sections 8と8.1はarchitectural complexityをservice-delivery path上のelement数とcomplexityへ関連付けます. numeric availability formulaでも, 要件を捨てる許可でもありません. A: 非選択. ACPLはここではqualitativeであり, exact outage multiplierを与えません. B: 選択. 各elementがmandatory-path costに値するかを試すにはdependency mapが必要です. C: 非選択. simplicityは必須securityとevidence propertyを満たす範囲で評価します. D: 選択. RFC 3439はInformationalなarchitecture指針であり, このA2A pathのconformance specificationではありません. E: 選択. element削除はrequired behaviorとassuranceをredesign後も保てる場合にだけ正当化できます.