Files
2nd/10_Wiki/Topics/Architecture/Space-Based_Architecture.md
T
koriweb d8a80f6272 chore(wiki): dangling 링크 canonical 정규화 (768파일/1200건)
이름만 다른(표기 변형) [[위키링크]]를 대상 문서의 canonical 제목으로 치환해
끊겼던 1,200개 링크를 연결. 제목/파일명 정규화 일치만 적용하고 별칭 매칭은
과병합 위험으로 제외(애매성 가드). 원본은 _link_reconcile_backup/ 에 백업.
도구: Datacollect/scripts/link_reconcile_apply.mjs

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-08 12:24:15 +09:00

4.7 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score verification_status tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0508-space-based-architecture Space-Based Architecture 10_Wiki/Topics verified self
Space-Based Architecture
SBA
Tuple Space Architecture
none A 0.85 applied
architecture
scalability
in-memory-data-grid
2026-05-10 pending
language framework
java hazelcast

Space-Based Architecture

매 한 줄

"매 database bottleneck 의 제거 — 매 in-memory data grid (tuple space) + 매 processing units 의 horizontal scale". Linda tuple space (1985) 의 후예. 매 Gigaspaces, Hazelcast, Apache Ignite 가 매 commercial 구현. 매 high-volume, low-latency 의 trading, gaming, real-time bidding.

매 핵심

매 components

  • Processing Unit (PU): 매 stateless application + 매 local in-memory data partition.
  • Virtualized Middleware:
    • Messaging Grid: load balancer.
    • Data Grid: 매 distributed in-memory cache (replicated/partitioned).
    • Processing Grid: 매 orchestrate distributed work.
    • Deployment Manager: 매 PU lifecycle.
  • Data Pumps: 매 data grid → DB async write-behind.
  • Data Writers / Readers: 매 eventual persistence.

매 trade-off

  • 장점: 매 elastic horizontal scale, 매 DB 의 single point of bottleneck X, 매 sub-ms latency.
  • 단점: 매 eventual consistency, 매 complexity 의 폭발, 매 in-memory cost 의 high, 매 split-brain risk.

매 응용

  1. Online ticketing (Ticketmaster).
  2. Real-time bidding (ad exchange).
  3. MMO game state (player position grid).

💻 패턴

Hazelcast IMDG — distributed map (Java 21)

HazelcastInstance hz = Hazelcast.newHazelcastInstance();
IMap<String, Order> orders = hz.getMap("orders");
orders.put("o-123", new Order("sku-1", 99));
Order o = orders.get("o-123"); // 매 local or remote partition

EntryProcessor — 매 data-local computation

orders.executeOnKey("o-123", (EntryProcessor<String, Order, Void>) entry -> {
    var o = entry.getValue();
    o.markPaid();
    entry.setValue(o); // 매 in-place mutation, 매 network round-trip 1회
    return null;
});

Write-behind to RDBMS (data pump)

MapConfig cfg = new MapConfig("orders")
    .setMapStoreConfig(new MapStoreConfig()
        .setClassName("com.acme.OrderMapStore")
        .setWriteDelaySeconds(5)
        .setWriteBatchSize(100));
hz.getConfig().addMapConfig(cfg);

Apache Ignite — SQL on data grid

IgniteCache<Long, Order> cache = ignite.cache("orders");
SqlFieldsQuery q = new SqlFieldsQuery(
    "SELECT customerId, SUM(amount) FROM Order GROUP BY customerId");
cache.query(q).forEach(row -> System.out.println(row));

Affinity colocation — 매 join-friendly partition

@AffinityKeyMapped Long customerId; // 매 same partition 의 customer + orders

Near cache (read-heavy)

NearCacheConfig near = new NearCacheConfig()
    .setInMemoryFormat(InMemoryFormat.OBJECT)
    .setTimeToLiveSeconds(30);

Continuous query (event subscription)

orders.addEntryListener((EntryAddedListener<String, Order>) e ->
    eventBus.publish("order.created", e.getValue()), true);

매 결정 기준

상황 Approach
Sub-ms read/write @ 100k+ TPS Space-based (Hazelcast/Ignite)
Strong consistency 필요 Traditional RDBMS / NewSQL (CockroachDB)
Read-heavy, eventual OK CDN + cache-aside (Redis)
Stream-first Kafka + Flink (event-driven)

기본값: 매 default 가 X — SBA 의 specialized. 매 일반 backend → microservices + Postgres + Redis.

🔗 Graph

🤖 LLM 활용

언제: extreme write throughput, DB bottleneck, latency budget < 10ms. 언제 X: 매 일반 CRUD, 매 strong consistency 의 필요, 매 small team — 매 complexity 의 cost 의 huge.

안티패턴

  • SBA for CRUD: 매 over-engineering. Postgres 의 sufficient.
  • Sync write-through to DB: 매 SBA 의 point 의 lost — async write-behind 의 의도.
  • Single PU instance: 매 distributed grid 의 X — 매 SPOF.
  • No backup partitions: 매 node failure → data loss.

🧪 검증 / 중복

  • Verified (Mark Richards, Software Architecture Patterns O'Reilly; Hazelcast 5.x docs 2025).
  • 신뢰도 A.

🕓 Changelog

날짜 변경
2026-05-08 Phase 1
2026-05-10 Manual cleanup — full SBA spec with Hazelcast/Ignite patterns