본문 바로가기
Study/Backend Roadmap

[roadmap.sh] Backend 4주차 정리

by Nahwasa 2022. 12. 10.

스터디 메인 페이지

목차

    완벽한 정리가 목적이 아니고, 로드맵을 보면서 기본 개념을 알고 차후 파고들어서 공부하기 위한 사전 준비 과정인 스터디이다. 따라서 이하 정리한 내용이 부실할 수 있습니다.

     

     

    CI/CD

    배포를 자동화하기 위해 사용

     

    CI : 지속적인 통합

    • 개발자가 개발한 소스 코드들은 지속적으로 코드베이스에 통합되어야 하며, 이때 자동으로 빌드 및 테스트가 진행되어야 한다.

     

    CD : 지속적인 배포

    • CI를 통해 자동으로 테스트 및 패키징되었다면 CD를 이용하여 자동으로 해당 시스템에 배포할 수 있다.
    • CD가 없다면 개발자가 패키징된 파일을 각 서버에 분배한 후 직접 서버를 재기동 해야 함.

     


    Design and Development Principles

    GOF Design Patterns

    디자인 패턴 : 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴

     

    GoF(Gang of Four) : 디자인 패턴의 4인방으로 불리는 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides가 '디자인 패턴'을 썼음.

     

     

     

    Domain Driven Design (DDD)

    소프트웨어로 해결해야할 문제의 영역인 도메인을 중심으로 설계해 나가는 방법

     

    기술적인 요소들을 잊고 사용자가 사용하는 것에 초점을 맞춘 것.

     

     

    Test Driven Development (TDD)

     

     

    SOLID

    SRP : 단일 책임 원칙 (Single responsibility principle)

    • 한 클래스는 하나의 책임만 가져야 한다.

     

    OCP : 개방 폐쇄 원칙 (Open/Closed principle)

    • 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

     

    LSP : 리스코프 치환 원칙 (Liskov substitution principle)

    • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

     

    ISP : 인터페이스 분리 원칙 (Interface segregation principle)

    • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다

     

    DIP : 의존관계 역전 원칙 (Dependency inversion principle)

    • 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나다.

     

     

    KISS

    Keep it simple stupid, Keep it small and simple, Keep it short and simple

     

    간단하고 알기 쉽게 만드는 편이 좋다는 원리. '불필요하게' 장황하거나 복잡해지는 것을 경계하라는 원칙

     

     

     

    YAGNI

     You aren't gonna need it

     

      프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 익스트림 프로그래밍(XP)의 원칙. 현재는 사용하지 않지만 확장성을 고려해 미리 작업해두는 그런 것들을 하지 말라는 원칙.

     

     

    DRY

    Do not repeat yourself

     

    소스 코드에서 동일한 코드가 반복되는걸 하지 말라는 원칙.

     

     


    Architectural Patterns

    Monolithic Apps

    ⚈ 하나의 시스템이 서비스 전체 기능을 처리하도록 설계한 것

     

    장점 : 구조가 매우 간단하므로 시스템 운영과 개발이 편리하다. MSA와 달리 네트워크로 인한 지연이나 데이터 유실을 걱정할 필요가 없다.

     

    단점 : 서비스 기능이 많아지면 더욱 복잡해지고 스파게티 코드가 되기 쉽다. 서버 기능과 클라이언트 기능이 뒤섞인 채 개발할 수밖에 없다. 즉, 시간이 지날수록 개발 속도나 생산성이 떨어진다.

     

     

    Microservices (MSA)

    기능별로 쪼개진 작은 서비스 혹은 시스템을 마이크로서비스라고 한다.

     

    모놀리식 아키텍처와 반대되는 개념

     

    장점 : 독립성. 대용량 데이터 처리에 비교적 자유로움. 서로 독립되어 있어 서로 간에 미치는 영향이 적으므로 시스템 장애에 견고함. 마찬가지로 독립되어 있으므로 서비스 배포 주기가 빠름. 또 독립되어 있으므로 마이크로서비스 단위로 확장할 수 있어 서비스 전체적으로 확장성 향상

     

    단점 : 설계 및 개발이 어렵다. 운영하기도 어렵다. 분산 트랜잭션을 사용하지 않는다면 데이터 일관성 유지가 어렵다. MSA를 운영하고 개발하는 개발자의 기술력이 좋아야 함. 각 팀원의 기술 성숙도가 낮은 팀은 MSA를 하기에 부적합하며, 오히려 개발 속도와 서비스 안전성 면에서 역효과가 발생한다.

     

     

    SOA (Service-Oriented Architenture)

    MSA와 비슷한 개념. MSA가 독립 지향이라면, SOA는 최대한 기존껄 재가용. MSA가 REST API를 통해 서로 소통한다면 SOA는 SOAP등 공통적으로 통신.

     

     

     

    CQRS and Event Sourcing

    CQRS(Command and Query Responsibility Segregation) : 명령(CUD)과 쿼리(R) 분리

     

    Event Sourcing : Insert만 존재. Update, Delete도 데이터를 변경하는 것이 아닌 변경된 데이터를 insert하는 방식. 쿼리가 아닌 모든 명령에 대해 DB에 상태 변경이라는 새 행을 생성해서 최종 데이터와 일정 시작 시점을 기준으로 모든 변경사항을 기록하는 방식.

     

     

    Serverless

    개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델. 정말 서버가 없는건 아니고, 서버를 구성하는데 필요한 부분들을 서비스화 하고 단순화시켜 사용자 입장에서는 자기가 필요한 비즈니스 로직을 만들어 넣기만 하면 되도록 만들어 놓은 것.

     

     


    Search Engines

    검색 엔진 : 웹에 존재하는 많은 양의 정보 중에서 사용자가 원하는 정보만을 여러 웹 사이트나 웹 페이지 등에서 검색해주는 시스템이나 프로그램 등

     

    Elasticsearch

    일종의 DB인데 비정형 검색이 빠른 그런것. 스프링부트에 적용 시 Spring Data Elasticsearch 사용. 기존 DB가 SQL을 사용해 데이터를 얻어온다면, 엘라스틱서치는 RESTful API를 사용하므로 Spring Data Elasticsearch가 JPA 쓴걸 RESTful API 요청으로 바꾸어서 Elasticsearch 서버로 보내 데이터 받아오는 방식으로 동작함.

     

     

    Solr

    Solr : 사이즈가 큰 데이터 검색에 용이. 문서 검색에 적합하나 색인주기가 느림. 주로 문서 검색용

    Elasticsearch : 사지으가 작은 데이터에 대한 속성검색/연관검색/실시간 검색에 용이. 주로 커머스 검색용

     


    Message Brokers

    메시지 브로커 : 송신자로부터 전달받은 메시지를 수신자로 전달해주는 중간 역할. 응용 소프트웨어 간에 메시지를 교환할 수 있게 한다.

    메시지 큐 : 메시지 브로커에서 메시지가 적재되는 공간. 큐에 메시지를 담기 때문에 비동기적으로 처리할 수 있어서 동기시의 병목현상같은걸 막을 수 있음. 그리고 독립성에 따른 장점들이 따라옴.

     

    스프링부트에 카프카 적용 : 카프카 서버 설치하고 스프링부트에 implementation 'org.springframework.kafka:spring-kafka' 추가해서 사용 가능. 로그 같이 방대한 부분에 좋을듯.

     

    Kafka vs RabbigMQ

    • 카프카가 더 최신
    • 일반적인 시스템에서는 카프카가 오버스펙일 수 있음.
    • 분산/대용량/고성능/노드장애대응 4가지가 필요하다면 카프가, 큐의 다양한 기능이 필요하다면 RabbitMQ
    • RabbitMQ는 메시지 유실 이슈가 있다고 함

     


    Containerization vs Virtualization

    Docker : 리눅스 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈 소스 프로젝트. LXC 응용해서 좀 더 효율적으로 생성, 관리, 배포 될 수 있도록. 도커는 1 컨테이너 1 응용프로그램을 권장.

    • 개발환경에 구애받지 않고 내가 사용하던 개발환경을 구축할 수 있음
    • 여러개의 독립된 프로세스를 띄워 마이크로서비스가 가능
    • 배포, 수정이 쉬움

     

    LXC(LinuX Containers) : 단일 컨트롤 호스트 상에서 여러 개의 고립된 리눅스 시스템 (컨테이너)들을 실행하기 위한 운영 시스템 레벨 가상화 방법

     

     


    GraphQL

     GraphQL, API 인터페이스를 위한 쿼리임. 웹 클라이언트가 데이터를 서버로 부터 효율적으로 가져오는 것이 목적. 주로 프론트엔드(클라이언트)에서 작성하고 호출.

     

    Apollo : 모든 기능을 갖춘 유연한 GraphQL 클라이언트. 캐싱, 최적화된 UI, 페이지네이션, 서버 사이드 렌더링을 위한 헬퍼, 데이터 프리페칭 등의 간편 기능을 제공. React, Angular, Vue 등 대부분의 UI 프레임워크 뿐 아니라 iOS, Android도 지원.

     

    Relay : 페이스북의 GraphQL 클라이언트. 학습난이도가 높음. 성능 최적화 기능을 제공하며 많은 데이터를 처리해야 하는 복잡하고 큰 규모의 애플리케이션에 적합.

     

     


    Graph Databases

    GDB : 데이터를 그래프(노드, 에지)로 저장하고 표현하는 데이터베이스. 에지를 통해 노드 간 관계를 정할 수 있으며, 데이터의 관계를 그래프를 통해 직관적으로 시각화할 수 있음.

     

    Neo4j : 자바로 구현되어 있는 Neo4j. Inc. 에서 개발한 GDB. Cypher 쿼리 언어 사용. 

     


    WebSockets, Web Servers

    웹소켓 : HTTP처럼 하나의 통신 프로토콜. HTTP처럼 TCP에 의존해서 동작함. HTTP가 보통 클라이언트의 요청이 있을 때 서버가 응답하는 단방향 통신 방식이라면, 소켓 통신은 클라이언트와 서버 양쪽에서 서로에게 데이터를 전달하는 방식의 양방향 통신.

     

    웹서버 : 웹 브라우저 클라이언트로부터 HTTP 요청을 받아들이고 HTML 문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램.

    • 정적 컨텐츠 : 단순 HTML 문서, CSS, javascript, 이미지, 파일 등 즉시 응답가능한 컨텐츠
    • 웹 서버가 동적 컨텐츠 요청받으면 WAS에게 해당 요청을 넘겨주고, WAS에서 처리한 결과를 클라이언트에게 전달해주는 역할도 함.

     

    WAS : 인터넷 상에서 HTTP 프로토콜을 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어. 주로 동적 서버 컨텐츠를 수행하는 것으로 웹 서버와 구별이 되며, 주로 DB 서버와 같이 수행.

    • WAS = 웹 서버 + 웹 컨테이너. 웹 서버 단독으로는 처리할 수 없는 DB 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공.
    • WAS는 JSP, Servlet 구동환경을 제공해주기 때문에 웹 컨테이너 혹은 서블릿 컨테이너라고도 불린다.
    • 웹 컨테이너 : 웹 서버가 보낸 JSP, PHP 등의 파일을 수행한 결과를 다시 웹 서버로 보내주는 역할을 함

     

    ⚈ 웹 서버 선택 : 요구사항과 우선순위에 따라 고르면 됨.

     

     


    Building for Scale

    the company and its systems can acquire and service a large number of new customers without requiring a major structural change.

     

    Instrumentation refers to the measure of a product's performance, in order to diagnose errors and to write trace information. Instrumentation can be of two types: source instrumentation and binary instrumentation.

     

    monitoring allows the user to view the performance of infrastructure i.e. the components that run a web application. These include the HTTP server, middleware, database, third-party API services, and more.

     

    Telemetry is the process of continuously collecting data from different components of the application. This data helps engineering teams to troubleshoot issues across services and identify the root causes. In other words, telemetry data powers observability for your distributed applications.

     

    7 Steps to create the perfect data Migration Strategy

    1. Define the scope of your data migration
    2. Assess your current data
    3. Define your target data environment
    4. Determine risks
    5. Develop your data migration plan
    6. Execute your data migration plan
    7. Validate your data in the target environment

     

    Horizontal vs Vertical Scaling

    • Vertical Scaling (= Scale Up) : 수직확장은 하드웨어를 기준으로 하드웨어의 사양을 늘린다. 램, HDD, CPU 추가 등. 즉, 기존의 서버를 보다 높은 사양으로 업그레이드 하는 것. 예를들어 AWS EC2 사양을 micro에서 small, small에서 medium으로 높이는 것.
    • Horizontal Scaling (= Scale out)  : 장비를 추가해서 확장하는 방식. 비슷한 사양의 서버를 추가로 연결해 처리할 수 있는 데이터 용량을 늘리거나 부하를 분담하는 방식.

     

    Building with Observability in mind

    • datadog

    • 스프링부트 + 프로메테우스 + 그라파나

     

     


    References

    책 - Head First Design Patterns

    책 - 스프링 부트로 개발하는 MSA 컴포넌트

    https://namu.wiki/w/%EB%94%94%EC%9E%90%EC%9D%B8%20%ED%8C%A8%ED%84%B4
    https://y-oni.tistory.com/53
    https://yoonbing9.tistory.com/121
    http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/
    https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)
    https://blog.naver.com/complusblog/221163007357
    https://ko.wikipedia.org/wiki/KISS_%EC%9B%90%EC%B9%99
    https://waspro.tistory.com/602
    https://bluayer.com/37
    https://www.redhat.com/ko/topics/cloud-native-apps/what-is-serverless
    https://namu.wiki/w/%EC%84%9C%EB%B2%84%EB%A6%AC%EC%8A%A4%20%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98
    https://tecoble.techcourse.co.kr/post/2021-10-19-elasticsearch/
    https://danidani-de.tistory.com/48
    http://hochul.net/blog/%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EA%B2%80%EC%83%89%EC%97%94%EC%A7%84-%EB%B9%84%EA%B5%90-solr-vs-elasticsearch/
    https://heodolf.tistory.com/49
    https://velog.io/@taehodot/SpringBoot-%EC%B9%B4%ED%94%84%EC%B9%B4%EC%99%80-%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EC%97%B0%EB%8F%99
    https://ellune.tistory.com/29
    https://ko.wikipedia.org/wiki/%EB%8F%84%EC%BB%A4_(%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4)
    https://hwan-shell.tistory.com/116
    https://ko.wikipedia.org/wiki/LXC
    https://steemit.com/graphql/@dakeshi/graphql-firebase
    https://d2.naver.com/helloworld/8446520
    https://ko.wikipedia.org/wiki/%EC%9B%B9%EC%86%8C%EC%BC%93
    https://kotlinworld.com/75
    https://codechasseur.tistory.com/25
    https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html
    https://velog.io/@deannn/Apache%EC%99%80-NginX-%EB%B9%84%EA%B5%90-%EC%B0%A8%EC%9D%B4%EC%A0%90
    https://news.netcraft.com/archives/category/web-server-survey/
    https://tecoble.techcourse.co.kr/post/2021-10-12-scale-up-scale-out/
    https://www.haedongg.net/?p=179
    https://theecmconsultant.com/data-migration-strategy/
    https://www.datadoghq.com/blog/network-device-monitoring/

     

    'Study > Backend Roadmap' 카테고리의 다른 글

    [roadmap.sh] Backend 3주차 정리  (0) 2022.12.03
    [roadmap.sh] Backend 2주차 정리  (0) 2022.11.26
    [roadmap.sh] Backend 1주차 정리  (0) 2022.11.19

    댓글