λ³Έλ¬Έ λ°”λ‘œκ°€κΈ°
  • μž₯원읡 κΈ°μˆ λΈ”λ‘œκ·Έ

πŸ”¬web application39

DDD 의 aggregate 에 λŒ€ν•œ 이야기 TL;DR 이번 κΈ€μ˜ 핡심을 μš”μ•½ν•˜λ©΄ λ‹€μŒκ³Ό κ°™λ‹€ aggregate λž€ 무엇인가 3가지 핡심 도메인 κ΅¬μ„±μš”μ†Œ 쀑 κ°€μž₯ κΈ°λ³Έ entity 와 value 의 composition μ™„μ „ν•œ ν•˜λ‚˜μ˜ κ°œλ… μ™œ aggregate κ°€ ν•„μš”ν• κΉŒ κ³ μ •μž(invariant) 와 일관성 (consistency) 을 μ§€ν‚€λŠ” 핡심 객체 aggregate 의 핡심 κ΅¬μ„±μš”μ†Œ 3가지 entity, root-entity, value aggregate 을 μ„€κ³„ν•˜κΈ° 3가지 섀계 μ§€ν‘œ 일관성을 κΈ°μ€€μœΌλ‘œ λ‚˜λˆ„κΈ° actor λ₯Ό κΈ°μ€€μœΌλ‘œ λ‚˜λˆ„κΈ° usecase λ₯Ό κΈ°μ€€μœΌλ‘œ λ‚˜λˆ„κΈ° 잘 λ‚˜λ‰˜μ–΄μ§„ aggregate 의 νŠΉμ„± aggregate λž€ 무엇인가 에릭 μ—λ°˜μŠ€κ°€ μ œμ‹œν•œ DDD, domain driven design μ—μ„œ 핡심 도메인 κ΅¬μ„±μš”μ†ŒλŠ” 3κ°€.. 2024. 4. 10.
cache 101 - Spring Cache 에 λŒ€ν•˜μ—¬ (feat. μΊμ‹œλ‘œ todo list λ₯Ό λ§Œλ“€μ–΄λ³΄μž) cache 101 μ‹œλ¦¬μ¦ˆλŠ” web application 을 κ°œλ°œν•˜λ©° λ§ˆμ£Όν•˜λŠ” cache 에 λŒ€ν•΄ ν•„μš”ν•œ 지식과 λ„κ΅¬λ“€μ˜ μ‚¬μš©λ²•μ„ ν•™μŠ΅ν•˜λŠ” μ‹œλ¦¬μ¦ˆμž…λ‹ˆλ‹€. 1. Cache 에 λŒ€ν•œ 거의 λͺ¨λ“  것 의 μˆœμ„œλŒ€λ‘œ 글을 μ½μœΌμ‹œλ©΄ ν•™μŠ΅μ— 더 λ§Žμ€ 도움이 λ©λ‹ˆλ‹€. μ˜€λŠ˜μ€ Spring μ—μ„œ μ œκ³΅ν•˜λŠ” Cache 에 λŒ€ν•΄μ„œ 이야기 ν•΄λ³Ό 것이닀 Spring μ—μ„œλŠ” Cache 에 λŒ€ν•˜μ—¬ Spring Transaction κ³Ό λ§ˆμ°¬κ°€μ§€λ‘œ 높은 좔상화λ₯Ό μ œκ³΅ν•œλ‹€ @Transactional // spring transaction support public Todo create() {} @Cacheable // spring cache support public Todo create() {} Spring μ—μ„œλŠ” 이λ₯Ό Cache Abstr.. 2024. 3. 13.
cache 101 - μΊμ‹œμ— λŒ€ν•œ 거의 λͺ¨λ“  것 μ΄λ²ˆμ—λŠ” cache 에 λŒ€ν•΄μ„œ μ•Œμ•„λ³Ό 것이닀. cache 라고 ν•œλ‹€λ©΄ computer science μ—μ„œ 정말 λ‹€μ–‘ν•œ λΆ„μ•Όμ—μ„œ μ‚¬μš©λ˜κ³ , λ™μΌν•œ κΈ°λŠ₯을 μˆ˜ν–‰ν•˜μ§€λ§Œ λ¬Έλ§₯에 λ”°λΌμ„œ λ‹€λ₯Έ 이해도가 ν•„μš”ν•˜λ‹€. λ‚˜λŠ” cache 에 λŒ€ν•΄μ„œ web application layer 의 λ¬Έλ§₯μ—μ„œ μ„€λͺ…을 ν•  것이고, software cache 에 λŒ€ν•œ μ„€λͺ…을 주둜 ν•  것이닀. hardware cache 와 더 low level 의 cache λ₯Ό μ›ν•œλ‹€λ©΄ 이 글은 μ ν•©ν•˜μ§€ μ•Šμ„ 수 μžˆλ‹€. TL;DR 이번 κΈ€μ˜ 핡심을 μš”μ•½ν•˜λ©΄ λ‹€μŒκ³Ό κ°™λ‹€ 1. μΊμ‹œλž€ 무엇인가 cache: 데이터λ₯Ό μ €μž₯ν•˜μ—¬ λ―Έλž˜μ— ν•΄λ‹Ή 데이터에 λŒ€ν•œ μš”μ²­μ„ 더 λΉ λ₯΄κ²Œ μ²˜λ¦¬ν•  수 μžˆλ„λ‘ ν•˜λŠ” hardware ν˜Ήμ€ software cache 의 μ’…λ₯˜ h/w ca.. 2024. 2. 1.
μ˜€ν”„μ…‹ νŽ˜μ΄μ§•, λ‹¨κ³„λ³„λ‘œ μ΅œμ ν™”ν•˜κΈ° 이 글은 offset based pagination 을 빌미둜 λ°μ΄ν„°λ² μ΄μŠ€μ˜ λ‚΄λΆ€ λ™μž‘κ³Ό μ—¬λŸ¬ κ°œλ…λ“€μ„ μ•Œμ•„λ³΄λŠ” κΈ€ μž…λ‹ˆλ‹€. 2개의 κΈ€λ‘œ κ΅¬μ„±λ˜μ–΄ 있고, 각각의 κΈ€μ—μ„œ 얻을 수 μžˆλŠ” insight κ°€ λ‹€λ₯΄λ‹ˆ ν•¨κ»˜ 읽으면 λ”μš± μœ μ΅ν•©λ‹ˆλ‹€. μ˜€ν”„μ…‹ νŽ˜μ΄μ§•μ΄ 느린 μ§„μ§œ 이유 μ˜€ν”„μ…‹ νŽ˜μ΄μ§•, λ‹¨κ³„λ³„λ‘œ μ΅œμ ν™”ν•˜κΈ° 2023. 11. 19.
μ˜€ν”„μ…‹ νŽ˜μ΄μ§•μ΄ 느린 μ§„μ§œ 이유 이 글은 offset based pagination 을 빌미둜 λ°μ΄ν„°λ² μ΄μŠ€μ˜ λ‚΄λΆ€ λ™μž‘κ³Ό μ—¬λŸ¬ κ°œλ…λ“€μ„ μ•Œμ•„λ³΄λŠ” κΈ€ μž…λ‹ˆλ‹€. 2개의 κΈ€λ‘œ κ΅¬μ„±λ˜μ–΄ 있고, 각각의 κΈ€μ—μ„œ 얻을 수 μžˆλŠ” insight κ°€ λ‹€λ₯΄λ‹ˆ ν•¨κ»˜ 읽으면 λ”μš± μœ μ΅ν•©λ‹ˆλ‹€. μ˜€ν”„μ…‹ νŽ˜μ΄μ§•μ΄ 느린 μ§„μ§œ 이유 느림의 근본적인 원인 0번 offset λΆ€ν„° μ‹œμž‘ offset κΉŒμ§€μ˜ λ°μ΄ν„°λŠ” 버렀지고 10건만 결과둜 λ°˜ν™˜λ¨ offset based pagination 이 느린 이유 λ¬Έμ œλŠ” μ •λ ¬ 방식에 있음 정렬을 μœ„ν•΄ κ²°κ³Ό 처리λ₯Ό streaming 이 μ•„λ‹Œ buffering λ°©μ‹μœΌλ‘œ μ „ν™˜ streaming vs buffering streaming: 쿼리 μ‹€ν–‰ κ²°κ³Όλ₯Ό μ¦‰μ‹œ client μ—κ²Œ λ°˜ν™˜ LIMIT ꡬ문과 ν•¨κ»˜ μ‚¬μš©ν•  λ•Œ 이점 쑴재 bufferi.. 2023. 11. 19.
[distributed system] CAP 이둠과 PACELC 에 λŒ€ν•œ 이야기 λͺ©μ°¨ TL;DR λΆ„μ‚° μ‹œμŠ€ν…œμ˜ 3 가지 Gaurantee CAP 이둠 CP μ‹œμŠ€ν…œ AP μ‹œμŠ€ν…œ CAP μ‹œμŠ€ν…œμ΄ μ‘΄μž¬ν•˜μ§€ μ•ŠλŠ” 이유 CAP 이둠의 ν•œκ³„ PACELC 이둠 TL;DR 이번 κΈ€μ˜ 핡심을 μš”μ•½ν•˜λ©΄ λ‹€μŒκ³Ό κ°™λ‹€. CAP 이둠 νŒŒν‹°μ…˜μ΄ 항상 λ°œμƒν•  수 밖에 μ—†λŠ” λΆ„μ‚° μ‹œμŠ€ν…œμ—μ„œ C, A 쀑 ν•˜λ‚˜λ§Œ 선택할 수 μžˆμŒμ„ μ˜λ―Έν•˜λŠ” 이둠 Consistency Availability Partition Tolerance CAP 이둠의 ν•œκ³„ μ™„λ²½ν•œ CP, AP μ‹œμŠ€ν…œμ€ μ‘΄μž¬ν•˜μ§€ μ•ŠλŠ”λ‹€ λŒ€λΆ€λΆ„μ˜ λΆ„μ‚° μ‹œμŠ€ν…œμ€ CP 와 AP 사이 어디쯀이닀 PACELC 이둠 partition 상황과 μ•„λ‹Œ(else) μƒν™©μœΌλ‘œ λ‚˜λˆ„κ³  각각 trade off 의 μ•ž κΈ€μžλ₯Ό λ”΄ 이둠 νŒŒν‹°μ…˜ partition 상황일 경우 Avaliabilt.. 2023. 11. 12.