웹이 동작하는 원리 & 데이터 모델링

# 웹이 동작하는 원리

• HTTP 프로토콜: 웹에서 클라이언트와 서버 간의 통신을 담당하는 규칙과 규약.
• 3-way 핸드쉐이크: TCP/IP 프로토콜을 사용하여 클라이언트와 서버가 연결을 설정하는 과정.
• HTTP/1.1과 HTTP/2.0: HTTP 프로토콜의 버전 차이와 기능적 향상.

 

• API와 라이브러리의 차이점
  • API (Application Programming Interface): 외부 시스템과 상호작용하기 위한 인터페이스로, 다른 애플리케이션에 기능을 노출시키는 방법.
  • 라이브러리: 코드 조각들의 집합으로, 어플리케이션의 특정 기능을 제공하거나 보완하는 데 사용.

 

•  웹 브라우저 동작 원리
  • DOM (Document Object Model): 웹 페이지의 구조화된 표현 방식으로, 웹 브라우저가 HTML 문서를 파싱하여 객체 형태로 구성하는 방식.

 

•  웹 프로젝트 시작 전 준비 과정
  • 아이디어 탐색: 프로젝트 아이디어를 찾고 구체화하는 단계.
  • 관심사 탐색: 개인적으로 좋아하는 것과 지출하는 자원 등을 파악하는 단계.
  • 문제 정의: 프로젝트에서 해결하고자 하는 문제들을 정의하고 목표를 설정하는 단계.
  • 상세 기획: 프로젝트의 세부 사항과 기능들을 계획하는 단계.
  • 5 Whys: 문제를 근본적으로 파악하기 위해 '왜'라는 질문을 반복하는 기법.아이디어 탐색
    • 다양한 아이디어를 찾고, 프로젝트의 주제를 구체화하는 단계입니다.
    1. 관심사 탐색
       • 자신이 좋아하는 것과 지출하는 자원에 대해 파악하여 프로젝트의 방향성을 설정하는 단계입니다.
       • 좋아하는 것: 축구, 게임
       • 지출하는 것: 헬스, 옷, 음식, 유튜브 프리미엄
    2. 문제 정의
       • 프로젝트에서 해결하고자 하는 문제들을 정의하고 목표를 설정하는 단계입니다.
    3. 상세 기획
       • 프로젝트의 세부 사항과 기능들을 계획하는 단계입니다.
    4. 기획의 검토
       • 기획서를 검토하고 수정하는 단계입니다.
    5. 디자인 및 검토
       • 프로젝트의 디자인을 구상하고 검토하는 단계입니다.
    6. 5 Whys
       • 문제를 근본적으로 파악하기 위해 '왜'라는 질문을 반복하는 기법입니다.
    7. 핵심 기능 정의
       • 프로젝트에서 핵심적인 기능들을 정의하는 단계입니다.
    8. 사용자 스토리
       • 시스템 요구사항을 상세하게 설명하는 단계입니다.
       • 예시: 사용자 유형으로서, 축구 경기 일정을 조회하고 싶다. 목적은 최신 일정을 파악하기 위함입니다.
    9. Use Case
       • 시스템 요구사항과 사용자의 상호작용을 정의하는 단계입니다.
    10. API 설계
        • 프로젝트에서 사용할 API를 설계하는 단계입니다.
    11. UI 설계
        • 프로젝트의 사용자 인터페이스를 카카오오븐, 스케치, 피그마 등의 도구를 활용하여 디자인하는 단계입니다.

 

 

  # 데이터 모델링 - 관계형 데이터 모델(RDB)

• 모델 : 어떤 (목적)을 위해 (현실)의 무언가를 잘 (설명)하기 위한 (수단)
• 목적 : 데이터를 저장
• 데이터 모델링 과정:
  1. 업무파악: 비즈니스 요구사항을 파악하는 단계.
  2. 개념적 모델링: 업무 영역과 엔티티, 속성, 관계 등을 정의하는 단계.
  3. 논리적 모델링: 실제 데이터베이스 테이블과 관계 등을 설계하는 단계.
  4. 물리적 모델링: 실제 데이터베이스에 적합한 형태로 구현하는 단계.
     1. 업무파악
        • 도메인에 대한 이해: 프로젝트의 주제와 목적에 대해 파악하고 해당 분야에 대한 지식을 확보하는 단계.
        • 상호작용: 사용자와 시스템 간의 상호작용을 파악하여 필요한 데이터와 기능을 정의하는 단계.
        • 화면 표시: 사용자 인터페이스를 구성하는 화면 표시 요소를 고려하는 단계.
     2. 개념적 모델링
        • 관계형 데이터베이스: 데이터를 중첩되지 않고 하나씩 분리하여 표 형태의 테이블로 표현하며, 내포관계를 허용하지 않는 특징을 갖습니다.
        • Entity(게시글, 댓글, 유저) -> Table: 개념적 모델링 단계에서 업무 영역과 데이터를 표현하는 데 필요한 Entity를 정의하고, 이를 데이터베이스의 테이블로 변환합니다.
        • Attribute(글, 좋아요 수 등) -> Column: Entity가 가지는 속성들을 Column으로 정의하여 테이블에 저장합니다.
        • Relation -> PK, FK: 각 테이블 간의 관계를 Primary Key(PK)와 Foreign Key(FK)를 통해 연결합니다.
        • Cardinality:
          • 1 : 1: 두 엔티티 간에 서로 하나의 인스턴스만을 가질 수 있는 관계.
          • 1 : N: 한 엔티티의 인스턴스가 다른 엔티티의 여러 인스턴스와 관계를 맺을 수 있는 관계.
          • N : M: 두 엔티티가 서로 여러 개의 인스턴스와 다대다 관계를 가지는 관계. 이를 중간 테이블을 만들어 해소할 수 있습니다.
     3. 논리적 모델링
        • 1 : 1, 1 : N, N : M: 논리적 모델링 단계에서 정의한 관계들을 실제 데이터베이스 테이블 간의 관계로 변환합니다
        • 1 : N = N에서 1로 참조해야 한다: 1:N 관계에서 다(N) 쪽에 외래키(Foreign Key)를 두어 1 쪽과 연결합니다.
        • N : M = 중간에 테이블을 만든다. 서로 짝지어주는 방법으로 구성: 다대다 관계를 처리하기 위해 중간 테이블을 생성하여 각 엔티티를 연결합니다.

 

 

# 데이터 모델링 - NoSQL 데이터 모델링RDB와 NoSQL의 차이점

 

• RDB (관계형 데이터베이스)
  1. 도메인 분석: 비즈니스 도메인을 파악하고 데이터 요구사항을 이해하는 단계.
  2. Entity와 Relationship 식별: 데이터 엔티티와 그들 사이의 관계를 식별하는 단계.
  3. Table 추출: 식별한 Entity와 Relationship을 기반으로 테이블을 설계하는 단계.
  4. 쿼리 설계: 데이터베이스에서 원하는 데이터를 조회하는 쿼리를 설계하는 단계.
  5. 쿼리 구현: 설계한 쿼리를 실제 데이터베이스에서 실행하여 결과를 얻는 단계.
•  NoSQL (비관계형 데이터베이스)
  1. 도메인 분석: 비즈니스 도메인을 분석하고 데이터 요구사항을 파악하는 단계.
  2. Entity와 Relationship 식별: NoSQL은 스키마가 유연하므로 Entity와 Relationship을 더 유연하게 처리.
  3. 데이터 저장 모델 설계: 데이터를 저장하는 방식과 구조를 정의하는 단계.
  4. 쿼리 설계: NoSQL은 특정 쿼리 언어를 지원하지 않으며, 쿼리를 사용하기보다는 데이터 모델링에 중점을 둠.
  5. 쿼리 구현: NoSQL은 쿼리 언어 대신 특정 인터페이스나 API를 이용하여 데이터에 접근하는 단계. 

 

• 등장하게된 계기: 분산형 데이터베이스 등장
  • RDB는 기존에 사용되던 중앙집중식 데이터베이스의 한계점을 극복하고자 분산형 데이터베이스가 등장하게 되었습니다. 분산형 데이터베이스는 여러 대의 서버에 데이터를 분산하여 저장하고 처리함으로써 확장성과 성능을 높일 수 있습니다.

 

• RDB는 저장에 특화, NoSQL은 찾는데 특화
  • RDB는 데이터를 구조화하여 저장하는 데 특화되어 있으며, 정해진 스키마에 따라 데이터를 저장합니다. 반면에 NoSQL은 스키마가 유연하고 데이터를 빠르게 검색하고 조회하는 데 특화되어 있습니다.

 

•  CAP 이론
  • CAP 이론은 분산 시스템에서 세 가지 속성인 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 중에서 두 가지만 선택할 수 있다는 이론입니다. RDB는 일관성과 분할 내성을 중요시하여 ACID(원자성, 일관성, 고립성, 지속성) 속성을 강조하고, NoSQL은 가용성과 분할 내성을 중요시하여 BASE(기본 가용성, 소프트 상태, 최종적 일관성) 속성을 강조합니다.

 

•  NoSQL : new evolution of data model
  • NoSQL은 기존의 관계형 데이터베이스가 가진 한계점을 극복하고 새로운 혁신적인 데이터 모델을 제공하는 새로운 방향성의 데이터베이스입니다. NoSQL은 스키마의 유연성, 수평적 확장성, 대용량 데이터 처리 등을 강조하여 다양한 데이터 요구사항을 충족시킵니다.

 

•  대부분 NoSQL 시스템은 key/value model을 지원
  • NoSQL 데이터베이스의 많은 시스템은 Key-Value 모델을 지원합니다. 이는 데이터를 Key와 Value의 쌍으로 저장하는 방식으로, 빠른 데이터 조회와 검색을 위해 사용됩니다.

 

•  모든 key는 unique하며 하나의 value를 가지고 있음
  • NoSQL에서 Key는 고유해야 하며, 각 Key에는 하나의 Value만 저장됩니다. 이로 인해 빠른 검색과 조회가 가능하며, 확장성을 높이기 위한 분산 처리에도 유리합니다.

 

MSA (Microservices Architecture 또는 마이크로서비스 아키텍처)는 소프트웨어를 작은 독립적인 서비스로 분할하는 소프트웨어 아키텍처 디자인 패턴입니다. MSA는 각 서비스가 하나의 기능 또는 비즈니스 로직을 담당하며, 각 서비스는 독립적으로 배포되고 확장할 수 있도록 설계됩니다. 이러한 독립적인 서비스들이 네트워크를 통해 상호 작용하여 전체 시스템을 구성하게 됩니다.

MSA는 전통적인 모놀리식 아키텍처와 대조되며, 아래와 같은 특징들을 갖습니다.

 

1. 독립적인 서비스들: MSA는 여러 개의 독립적인 서비스로 구성됩니다. 각 서비스는 자체적으로 개발, 배포, 운영이 가능합니다.
2. 서비스 간 통신: 각 서비스는 API를 통해 외부와 통신하며, 서비스들 간의 상호작용은 API 호출을 통해 이루어집니다.
3. 경량화: 각 서비스는 작고 경량적으로 설계되어 있으며, 특정 기능 하나를 수행합니다. 이로 인해 각 서비스를 개발하고 배포하는 속도가 빨라지고 유연성이 높아집니다.
4. 독립적인 데이터 관리: 각 서비스는 자체 데이터 저장소를 가지며, 데이터베이스 등을 독립적으로 관리합니다. 이로 인해 데이터에 대한 결합도가 낮아집니다.
5. 유연한 확장성: 특정 서비스의 부하가 높아지면 해당 서비스만 확장하면 되기 때문에, 시스템 전체를 확장할 필요가 없습니다.
6. 기술 다양성: 서비스 간의 경계가 명확하게 구분되어 있기 때문에, 각 서비스를 다른 기술과 언어로 구현하는 것이 가능합니다.

 

 

MSA의 장점은 높은 유연성, 확장성, 개발/배포 속도 향상, 기술 다양성 등이 있습니다. 하지만 서비스 간 통신 및 분산 시스템 관리에 대한 복잡성과 테스트/디버깅의 어려움, 네트워크 지연 등의 문제도 존재합니다. 따라서 MSA를 적용하기 전에 시스템의 특징과 요구사항을 고려하여 장점과 단점을 비교하고 결정하는 것이 중요합니다.

MSA는 최근에 많은 기업과 조직에서 채택하고 있는 아키텍처 디자인 패턴으로, 클라우드 환경과의 호환성 및 확장성에 많은 장점을 가지고 있습니다.