❓
물음표살인마 블로그
  • README
  • ALGORITHM
    • Sieve of Eratosthenes
    • Lcm, Gcd
    • Sorting Array
    • Round Up
    • Binary Search
    • Union Find
  • Books
    • CS Note for Interview
      • Ch1. Design Pattern & Programming paradigm
        • 1.1.1 Singleton Pattern
        • 1.1.2 Factory Pattern
        • 1.1.4 Observer Pattern
        • 1.1.5 Proxty Pattern & Proxy Server
        • 1.1.8 Model-View-Controller Pattern
        • 1.2.1 Declarative and Functional Programming
        • 1.2.2 Object Oriented Programming
      • Ch2. Network
        • 2.2.1 TCP/IP Four-Layer Model
        • 2.2.1-1 TCP 3, 4 way handshake
        • 2.3 Network Devices L4, L7
        • 2.4.1 ARP, RARP
        • 2.4.2 Hop By Hop Communication
        • 2.4.3 IP Addressing Scheme
      • Ch3. Operating System
        • 3.1.1 Roles and Structure of Operating Systems
        • 3.2.1 Memory Hierarchy
        • 3.2.2 Memory Management
        • 3.3.1 Processes and Compilation Process
        • 3.3.3 Memory Structure of a Process
        • 3.3.4 Process Control Block (PCB)
        • 3.3.5 Multiprocessing
        • 3.3.6 Threads and Multithreading
        • 3.3.7 Shared Resources and Critical Sections
        • 3.3.8 Deadlock
        • 3.4 CPU Scheduling Algorithm
      • Ch4. Database
        • 4.1 Database Basic
        • 4.2 Normalization
        • 4.3 Transaction and Integrity
        • 4.4 Types of Databases
        • 4.5 Indexes
        • 4.6 Types of Joins
        • 4.7 Principles of Joins
      • Ch5. Data Structure
    • Learning the Basics of Large-Scale System Design through Virtual Interview Cases
      • 1. Scalability based on user counts(1/2)
      • 1. Scalability based on user counts(2/2)
      • 2.Back-of-the-envelope estimation
      • 3. Strategies for System Design Interviews
      • 4. Rate Limiter
      • 5. Consistent Hashing
      • 6. Key-Value System Design
      • 7. Designing a Unique ID Generator for Distributed Systems
      • 8. Designing a URL Shortener
      • 9. Designing a Web Crawler
      • 10. Notification System Design
      • 11. Designing a News Feed System
      • 12. Chat System Design
      • 13. AutoComplete
      • 14. Design YouTube
      • 15. Design Google Drive
      • Loadbalancer Algorithms
      • Cache tier
      • CDN, Content Delivery Network
      • Stateless Web tier
    • Computer System A programmer's perspective
    • Effective Java
      • Item 1. Consider Static Factory Methods Instead of Constructors
      • Item 2. Consider a Builder When Faced with Many Constructor Parameters
      • Item 3. Ensure Singleton with Private Constructor or Enum Type
      • Item 4. Enforce Noninstantiability with a Private Constructor
      • Item 5. Prefer Dependency Injection to Hardwiring Resources
      • Item 6. Avoid Creating Unnecessary Objects
      • Item 7. Eliminate Obsolete Object References
      • Item 8. Avoid Finalizers and Cleaners
      • Item 9.Prefer try-with-resources to try-finally
      • Item10. Adhering to General Rules When Overriding equals
        • Handling Transitivity Issues
        • Ensuring Consistency
      • Item11. Override hashCode When You Override equals
      • Item12. Always Override toString
        • Always Override toString
      • Item13. Override Clone Judiciously
      • Item14. Consider Implementing Comparable
      • Item15. Minimize the Accessibility of Classes and Members
      • Item16. Accessor Methods Over Public Fields
      • Item17. Minimize Mutability
      • Item18. Composition over inherentance
      • Item19. Design and Document for Inheritance, or Else Prohibit It
      • Item20. Prefer Interfaces to Abstract Classes
      • Item21. Design Interfaces with Implementations in Mind
      • Item22. Use Interfaces Only to define Types
      • Item23. Prefer Class Hierarchies to Tagged Classes
      • Item24. Favor Static Member Classes Over Non-Static
      • Item28. Use Lists Instead of Arrays
      • Item29. Prefer Generic Types
      • Item30. Favor Generic Methods
    • Head First Design Patterns
      • Ch1. Strategy Pattern
      • Ch2. Observer Pattern
        • Ver1. Ch2. Observer Pattern
      • Ch3. Decorator Pattern
        • Ch3. Decorator Pattern
      • Ch4. Factory Pattern
      • Ch5. Singleton Pattern
      • Ch6. Command Pattern
      • Ch7. Adapter and Facade Pattern
      • Ch8. Template Method Pattern
    • Digging Deep into JVM
      • Chapter 2. Java Memory Area & Memory Overflow
      • Chapter 3. Garbage Collector & Memory Allocation Strategy (1/2)
      • Chapter 3. Garbage Collector & Memory Allocation Strategy (2/2)
      • Chapter 5. Optimization Practice
      • Chapter 6. Class file structure
  • Interview Practices
    • Restful API Practices
      • Url Shortener API
      • Event Ticket Reservation API
      • Course Management API
      • Search posts by tags API
      • Online Code platform API
      • Simple Task Management API
      • Event Participation API
      • Review System API
      • Car management API
      • Online Library
    • Naver Computer Science
      • Process & Thread
      • TCP & UDP
      • Spring & Servlet
      • Filter & Interceptor & AOP
      • Equals() & ==
      • Dependency Injection
  • F-Lab
    • Week1
      • Client & Server
      • HTTP
      • TCP/UDP
      • REST API
      • Questions
        • Object Oriented Programming
        • HTTP
        • Process & Thread
        • Data Structure
    • Week2
      • OSI 7 layer
      • Web vs WAS
    • Week3
      • RDB vs NoSQL
      • RDB Index
      • Cache
      • Redis
      • Messaging Queue
    • Week4
      • Project - Ecommerce
    • Week5
      • ERD - 1
    • Week6
      • Ecommerce - 2
      • Role
      • pw hashing && Salt
      • CreatedAt, ModifiedAt
      • JWT
      • Copy of ERD - 1
    • Week7
      • Vault (HashiCorp Vault)
    • Week 8
      • Api Endpoints
  • Week10
    • Product Create Workflow
  • TOY Project
    • CodeMentor
      • Implementation of Kafka
      • Implementation of K8s
      • Communication between servers in msa
  • JAVA
    • Java 101
      • JVM Structure
      • Java Compiles and Execution Method
      • Override, Overload
      • Interface vs Abstract Class
      • Primitive vs Object Type
      • Identity and equality
      • String, StringBuilder, StringBuffer
      • Checked Exceptions and Unchecked Exceptions
      • Java 8 methods
      • Try-with-reources
      • Strong Coupling and Loose Coupling
      • Serialization and Deserialization
      • Concurrency Programming in Java
      • Mutable vs Immutable
      • JDK vs JRE
    • Java Questions
      • Week 1(1/2) - Basic Java
      • Week 1(2/2) - OOP
      • Week 2(1/2) - String, Exception, Generic
      • Week2(2/2) Lambda, Stream, Annotation, Reflection
      • Week3(1/2) Collections
      • Week3(2/2) Threads
      • Week4 Java Concurrency Programming
      • Week5 JVM & GC
    • Batch delete instead of Cascade
    • Checked vs Unchecked Exception
    • Thread
    • Memory Visibility
    • Synchronized && ReentrantLock
    • Producer & Consumer
    • BlockingQueue
    • CAS (Compare and Set)
  • SPRING
    • Spring Questions
      • Spring Framework
      • Spring MVC & Web Request
      • AOP (Aspect-Oriented Programming)
      • Spring Boot
      • ORM & Data Access
      • Security
      • ETC
    • using profile name as variable
    • Template Method Pattern
    • Strategy Pattern
    • Proxy Pattern
    • @Transactional
    • Ioc container, di practice
  • Programming Paradigm
    • Declarative vs Imperative
  • JPA
    • Template Page
  • PYTHON
    • Icecream
  • FASTAPI
    • Template Page
  • COMPUTER SCIENCE
    • Computer Architecture 101
      • 3 components of a computer
      • RAM vs ROM
      • CPU vs GPU
      • SIMD
      • Two's complement
      • Harvard Architecture vs. von Neumann Architecture
      • The structure of a CPU.
      • Instruction cycle (CPU operation method)
      • Instruction pipelining
      • Bus
      • Memory area
      • Memory hierarchy structure
        • Reason for using memory hierarchy structure
      • Cache memory
      • L1, L2, L3 Cache
      • Locality of reference (cache)
      • Fixed-point vs Floating-point
        • epresentation of infinity and NaN (Not a Number) in floating-point
      • RISC vs CISC
      • Hamming code
      • Compiler
      • Linking
      • Compiler vs Interpreter
      • Mutex vs Semaphore
      • 32bit CPU and 64bit CPU
      • Local vs Static Variable
      • Page
  • OS
    • Operating System 101
      • Operating system
        • The role of the operating system
        • The composition of the operating system.
      • Process
        • In Linux, are all processes except the initial process child processes?
        • Zombie process, orphan process
        • (Linux) Daemon process
        • Process address space
        • Where are uninitialized variables stored?
        • Determination of the size of the Stack and Heap
        • Access speed of Stack vs Heap
        • Reason for memory space partitioning
        • Process of compiling a process
        • sudo kill -9 $CURRENT_PID
      • Thread
        • Composition of a thread's address space
      • Process vs Thread
        • Creation of processes and threads in Linux
      • Multiprocessing
        • Web Browser
        • Implementation of multiprocessing
        • Application areas of multiprocessing
      • Multithreading
        • Application areas of multithreading
      • Interrupt
        • HW / SW Interrupt
        • Method of handling interrupts
        • Occurrence of two or more interrupts simultaneously
      • Polling
      • Dual Mode
        • Reason for distinguishing between user mode and kernel mode
      • System call
        • Differentiation between system calls
        • Types of system calls
        • Execution process of a system call
      • Process Control Block (PCB)
        • PCB의 구조
        • 쓰레드는 PCB를 갖고 있을까?
        • 프로세스 메모리 구조
      • Context switching
        • Timing of context switching
        • Registers saved during context switching
        • Context switching in processes
        • Context switching in threads
        • Difference between context switching in processes and threads
        • Information of the current process during context switching
      • Interprocess Communication (IPC)
        • Cases where IPC is used
        • Process address space in IPC Shared Memory technique
        • Types of IPC
    • Operating System Questions
      • Week1 OS & How Computer Systems Work
      • Week2(1/2) Process
      • Week2(2/2) Thread
      • Week3 CPU Scheduling
      • Week4 Process Synchronize
      • Week5 Virtual Memory
  • LINUX
    • Template Page
  • SERVER
    • Template Page
  • NETWORK
    • Network 101
      • https://www.google.com
      • TCP vs UDP
      • Http vs Https
      • TLS Handshake 1.2
      • HTTP Method
      • CORS & SOP
      • Web Server Software
    • Network Questions
      • Week1 Computer Network Basic
      • Week2(1/3) Application Layer Protocol - HTTP
      • Week2(2/3) Application Layer Protocol - HTTPS
      • Week2(3/3) Application Layer Protocol - DNS
      • Week3 Application Layer
      • Week4 Transport Layer - UDP, TCP
      • Week5 Network Layer - IP Protocol
    • Blocking, NonBlocking and Sync, Async
    • HTTP 0.9-3.0
  • DATABASE
    • Database Questions
      • Week1 DBMS, RDBMS basics
      • Week2 SQL
      • Week3 Index
      • Week4 Anomaly, Functional Dependency, Normalization
      • Week5 DB Transaction, Recovery
    • Normalization
      • 1st Normal Form
      • 2nd Normal Form
      • 3rd Normal Form
    • Ensuring Data Consistency, Atomicity and UX Optimization (feat.Firebase)
    • Redis: Remote Dictionary Server
    • Enhancing Query Performance - User list
  • DATA STRUCTURE
    • Array vs Linked List
    • Counting Sort
  • GIT, Github
    • git clone, invalid path error
  • INFRA
    • Template Page
  • AWS
    • Server Log Archive Pipeline
    • Image Processing using Lambda
  • DOCKER
    • Docker commands
    • Python Executable Environment
    • Docker and VM
  • docker-compose
    • Kafka, Multi Broker
  • KUBERNATES
    • !Encountered Errors
      • my-sql restarts
      • kafka producer: disconnected
    • Kubernetes Components
    • Helm
      • Helm commands
    • Pod network
    • Service network
      • deployment.yaml
      • services.yaml
    • Service type
      • Cluster IP
      • NodePort
    • service-name-headless?
    • kube-proxy
    • Template Page
  • GraphQL
    • Template Page
  • WEB
    • Template Page
  • Reviews
    • Graphic Intern Review
    • Kakao Brain Pathfinder Review
    • JSCODE 자바 1기 Review
  • 😁Dev Jokes
    • Image
      • Plot twist
      • Priorities
      • SQL join guide
      • Google is generous
      • Genie dislikes cloud
      • buggy bugs
      • last day of unpaid internship
      • what if clients know how to inspect
      • its just game
      • how i wrote my achievement on resume
      • self explanatory
      • chr(sum(range(ord(min(str(not))))))
Powered by GitBook
On this page
  • 무상태(Stateless) 웹 계층
  • 1. 상태 정보 의존적인 아키텍처 (Stateful Architecture)
  • 2. 무상태 아키텍처 (Stateless Architecture)
  • 3. 무상태 웹 계층을 갖도록 변경된 설계
  • 데이터 센터
  • 메시지 큐
  • 로그, 메트릭 그리고 자동화
  • 1. 로그, 메트릭, 자동화가 추가된 설계
  • 1.로그 (Logs)
  • 2. 메트릭 (Metrics)
  • 3. 자동화 (Automation)
  • 4. 메시지 큐, 로그, 메트릭, 자동화를 반영한 설계안
  • 데이터베이스의 규모 확장
  • 1. 수직적 확장 (Vertical Scaling)
  • 2. 수평적 확장 (Horizontal Scaling)
  • 백만 사용자, 그리고 그 이상
  1. Books
  2. Learning the Basics of Large-Scale System Design through Virtual Interview Cases

1. Scalability based on user counts(2/2)

사용자 수에 따른 규모 확장성

Previous1. Scalability based on user counts(1/2)Next2.Back-of-the-envelope estimation

Last updated 8 months ago

무상태(Stateless) 웹 계층

웹 애플리케이션은 일반적으로 상태 정보가 있는 아키텍처와 무상태 아키텍처로 나눌 수 있습니다.

1. 상태 정보 의존적인 아키텍처 (Stateful Architecture)

  • 정의: 서버가 각 클라이언트의 상태 정보를 유지하는 아키텍처.

  • 특징: 세션 데이터가 서버에 저장되며, 클라이언트가 동일한 서버에 요청을 보내야만 일관된 세션 상태를 유지할 수 있습니다.

  • 장점: 특정 클라이언트의 상태를 서버에서 쉽게 관리할 수 있습니다.

  • 단점: 서버 간 로드 밸런싱이 어려워지고, 서버 장애 시 세션 정보가 손실될 수 있습니다.

2. 무상태 아키텍처 (Stateless Architecture)

  • 정의: 각 요청이 독립적이며, 서버가 클라이언트의 상태 정보를 유지하지 않는 아키텍처.

  • 특징: 각 요청은 독립적이며, 클라이언트의 상태는 클라이언트 측에 저장되거나 외부 서비스(예: 데이터베이스, 캐시)에 저장됩니다.

  • 장점: 서버 간 로드 밸런싱이 용이하고, 서버 장애 시에도 세션 정보 손실이 없습니다.

  • 단점: 모든 요청에 필요한 상태 정보를 포함해야 하므로 네트워크 오버헤드가 발생할 수 있습니다.

3. 무상태 웹 계층을 갖도록 변경된 설계

데이터 센터

데이터 센터는 서버, 네트워크 장비, 스토리지 시스템 등이 위치한 시설로, 대규모 시스템의 핵심 인프라입니다.

  • 기능: 대규모 컴퓨팅 및 스토리지 리소스를 제공하며, 시스템의 물리적 인프라를 구성합니다.

  • 구성 요소:

    • 서버, 스토리지 디바이스, 네트워크 장비, 전력 공급 시스템, 냉각 시스템 등이 포함됩니다.

  • 고려사항:

    • 위치: 지진, 홍수 등 자연 재해 위험이 적은 지역에 위치해야 합니다.

    • 보안: 물리적 및 논리적 보안이 중요합니다. 데이터 센터 접근 제어 및 네트워크 보안이 필요합니다.

    • 확장성: 요구사항 변화에 따라 용이하게 확장할 수 있어야 합니다.

    • 비용: 초기 설치 비용과 운영 비용을 고려해야 합니다.

메시지 큐

메세지 큐는 비동기식 통신을 지원하는 시스템으로, 생산자(Producer)와 소비자(Consumer) 간의 메시지 전달을 관리합니다.

  • 기능: 비동기 메시징을 통해 시스템 간 데이터를 교환하며, 시스템의 결합도를 낮추고 확장성을 향상시킵니다.

  • 예: RabbitMQ, Apache Kafka, Amazon SQS

  • 장점:

    • 비동기 처리: 메시지를 큐에 넣고 즉시 반환하여 응답 속도를 개선합니다.

    • 내결함성: 메시지 손실 없이 안정적인 데이터 전송을 보장합니다.

    • 확장성: 다수의 프로듀서와 컨슈머를 쉽게 추가하여 처리 성능을 향상시킬 수 있습니다.

  • 단점:

    • 복잡성: 메시지 큐를 설정하고 관리하는 것이 복잡할 수 있습니다.

    • 지연: 메시지가 큐에 머무르는 시간 동안 지연이 발생할 수 있습니다.

로그, 메트릭 그리고 자동화

대규모 시스템에서는 로그와 메트릭을 통해 시스템 상태를 모니터링하고, 자동화를 통해 운영 효율성을 높이는 것이 중요합니다.

1. 로그, 메트릭, 자동화가 추가된 설계

1.로그 (Logs)

  • 기능: 시스템 활동을 기록하여 문제 해결 및 성능 모니터링에 도움을 줍니다.

  • 구성 요소: 애플리케이션 로그, 시스템 로그, 액세스 로그 등

  • 관리 도구: ELK Stack(Elasticsearch, Logstash, Kibana), Splunk

2. 메트릭 (Metrics)

  • 기능: 시스템 성능 지표를 수집하여 모니터링하고, 이상 상태를 감지합니다.

  • 예: CPU 사용률, 메모리 사용량, 네트워크 트래픽 등

  • 관리 도구: Prometheus, Grafana, Datadog

3. 자동화 (Automation)

  • 기능: 반복적이고 시간이 많이 소요되는 작업을 자동화하여 효율성을 향상시킵니다.

  • 예: CI/CD 파이프라인, 인프라 자동화(Terraform, Ansible)

  • 장점: 일관성 있는 배포, 신속한 오류 수정, 효율적인 자원 관리

4. 메시지 큐, 로그, 메트릭, 자동화를 반영한 설계안

  • 무상태 아키텍처: 서버는 무상태로 설계하고, 상태 정보는 메시지 큐를 통해 전달됩니다.

  • 로그 관리: 모든 서버와 애플리케이션의 로그를 중앙 집중식으로 수집하고, 실시간으로 분석합니다.

  • 메트릭 수집: 시스템 성능 지표를 실시간으로 수집하여 모니터링하고, 이상 상태를 자동으로 감지합니다.

  • 자동화: CI/CD 파이프라인을 구축하여 코드 배포 및 테스트 과정을 자동화합니다.

데이터베이스의 규모 확장

데이터베이스는 시스템의 중요한 구성 요소로, 규모 확장이 필요합니다. 데이터베이스의 규모 확장 방법에는 수직적 확장과 수평적 확장이 있습니다.

1. 수직적 확장 (Vertical Scaling)

  • 정의: 기존 서버의 하드웨어 성능(CPU, RAM, Storage 등)을 업그레이드하여 처리 능력을 향상시키는 방식입니다.

  • 장점: 구현이 간단하며, 기존 애플리케이션의 수정이 거의 필요 없습니다.

  • 단점: 하드웨어 업그레이드에 한계가 있으며, 비용이 기하급수적으로 증가할 수 있습니다.

예를 들어, 전자상거래 사이트의 데이터베이스 서버에서 CPU와 메모리를 업그레이드하여 더 많은 트랜잭션을 처리할 수 있도록 합니다.

2. 수평적 확장 (Horizontal Scaling)

  • 정의: 여러 대의 서버를 추가하여 부하를 분산시키는 방식입니다.

  • 장점: 무한한 확장 가능성을 제공하며, 고가용성과 장애 복구에 유리합니다.

  • 단점: 시스템 복잡성이 증가하며, 데이터 일관성 유지가 어려울 수 있습니다.

샤딩:

예를 들어, 소셜 네트워크 서비스에서 사용자의 데이터를 여러 데이터베이스 서버에 분산 저장하여 각 서버가 병렬로 데이터를 처리할 수 있도록 합니다.

백만 사용자, 그리고 그 이상

  • 목표: 시스템이 백만 명 이상의 사용자를 안정적으로 처리할 수 있도록 확장성을 고려한 설계를 합니다.

  • 전략:

    • 무상태 아키텍처: 서버 간 로드 밸런싱을 용이하게 하기 위해 무상태 아키텍처를 채택합니다.

    • 메시지 큐 도입: 비동기 메시징을 통해 시스템 간 결합도를 낮추고, 확장성을 향상시킵니다.

    • 모니터링 및 로깅: 실시간 모니터링과 로그 분석을 통해 시스템 성능을 지속적으로 개선하고, 문제를 신속히 해결합니다.

    • 자동화 도구: CI/CD 파이프라인과 인프라 자동화를 통해 효율적이고 일관성 있는 운영을 보장합니다.

    • 수평적 확장: 여러 데이터베이스 서버를 통해 데이터를 분산 처리하여 성능과 가용성을 향상시킵니다. (샤딩, 파티셔닝)

    • CDN 사용: 전 세계 사용자에게 빠른 콘텐츠 전달을 위해 CDN을 사용합니다.