본문 바로가기

24DAY 백엔드

(17)
24DAY 백엔드 - 23DAY 확장성 1. 마이크레이션 전략 가장 일반적인 6가지 애플리케이션 마이그레이션 전략은 다음과 같습니다. 1. 리호스팅 — “리프트 앤 시프트” 많은 초기 클라우드 프로젝트는 클라우드 네이티브 기능을 사용하여 새로운 순 개발로 전환되지만, 조직이 비즈니스 사례를 충족하기 위해 마이그레이션을 신속하게 확장하려고 하는 대규모 레거시 마이그레이션 시나리오에서는 대부분의 애플리케이션이 재호스팅됩니다. 예를 들어, GE Oil & Gas는 클라우드 최적화를 구현하지 않더라도 리호스팅을 통해 약 30%의 비용을 절감할 수 있다는 사실을 발견했습니다. 대부분의 리호스팅은 도구(예: AWS VM 가져오기/내보내기, Racemi)를 통해 자동화할 수 있지만, 일부 고객은 레거시 시스템을 새로운 클라우드 플랫폼에 적용하는 방법을 배..
24DAY 백엔드 - 22DAY 웹 소켓 1. 웹 소켓 웹소켓은 HTTP의 문제를 해결해주는 약속입니다. HTTP에서 원리적으로 해결할 수 없었던 문제는 “클라이언트의 요청이 없음에도, 그 다음 서버로부터 응답을 받는 상황”이었는데요. 웹소켓은 HTTP가 해결할 수 없었던 이 문제를 해결하는 새로운 약속이었습니다. 즉, 브라우저가 서버에 데이터를 요청하고 서버가 브라우저에 데이터를 보내기 위해 별다른 제약이 없습니다. 웹소켓에서는 서버와 브라우저 사이에 양방향 소통이 가능합니다. 브라우저는 서버가 직접 보내는 데이터를 받아들일 수 있고, 사용자가 다른 웹사이트로 이동하지 않아도 최신 데이터가 적용된 웹을 볼 수 있게 해줍니다. 웹페이지를 ‘새로고침’하거나 다른 주소로 이동할 때 덧붙인 부가 정보를 통해서만 새로운 데이터를 제공하는 웹서비스 환경..
24DAY 백엔드 - 21DAY 메시지 브로커 1. RabbitMQ AMQP를 따르는 오픈소스 메시지 브로커인데, 메세지를 많은 사용자에게 전달하거나, 요청에 대한 처리 시간이 길 때, 해당 요청을 다른 API에게 위임하고 빠른 응답을 할 때 많이 사용합니다. 또한 MQ를 사용하여 애플리케이션 간 결합도를 낮출 수 있는 장점도 있습니다. RabbitMQ에서 중요한 개념으로는 Producer, Consumer, Queue, Exchange, Binding이 있습니다. 2. kafka 아파치 재단의 카프카는 Pub-sub모델의 메세지 큐이고, 분산환경에 특화되어 설계되어 있다는 특징을 가짐으로써, 기존의 RabbitMQ와같은 메시지큐와의 성능 차이가 납니다. 그외에도 클러스터 구성, fail-over, replication와 같은 여러 가지 특징들을 가..
24DAY 백엔드 - 20DAY 겜색엔진, 아키텍처 패턴 1. Elastic search elasticsearch는 Shay Banon이 Lucene을 바탕으로 개발한 분산 검색엔진입니다. 설치와 서버 확장이 매우 편리하기 때문에 개발하고 있는 시스템에 검색 기능이 필요하다면 elasticsearch를 적용하는 것을 권장하고 싶습니다. 분산 시스템이기 때문에 검색 대상 용량이 증가했을 때 대응하기가 무척 수월하다는 것이 장점입니다. 우선 관계형 데이터베이스에 익숙한 사람들을 위해 관계형 데이터베이스와 elasticsearch의 용어를 비교한 표를 참고 자료에서 인용했습니다. JSON 기반의 스키마 없는 저장소 elasticsearch는 검색엔진이지만, NoSQL처럼 사용할 수 있습니다. 데이터 모델을 JSON으로 사용하고 있어서, 요청과 응답을 모두 JSON ..
24DAY 백엔드 - 19DAY 개발과 설계원칙 1. GOF 디자인패턴 GOF에서는 23가지 디자인 패턴을 3가지 유형으로 분류합니다. A. Creational Pattern 객체를 생성하는데 관련된 패턴들 객체가 생성되는 과정의 유연성을 높이고 코드의 유지를 쉽게 함 B. Structural Pattern 프로그램 구조에 관련된 패턴들 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 활용할 수 있는 패턴들 C. Behavioral Pattern 반복적으로 사용되는 객체들의 상호작용을 패턴화 해놓은 것들 A. 생성패턴 Abstract Factory (추상 팩토리) -동일한 주제의 다른 팩토리를 묶어 준다. Builder -생성(construction)과 표기(representation)를 분리해 복잡한 객체를 생성한다 Fact..
24DAY 백엔드 - 18DAY 테스팅 1. 단위 테스트 단위 테스트는 모듈이나 애플리케이션 안에 있는 개별적인 코드 단위가 예상대로 작동하는지 확인하는 반복적인 행위입니다. 이것은 보통 여러분의 코드를 테스트하는 코드의 형태를 취합니다. 테스트 코드를 테스트하는 코드를 작성할 필요는 없습니다. 단위 테스트의 중요한 특징 몇가지는 테스트들은 서로 분리되어 있고, 실행은 자동화되며 애플리케이션의 같은 부분을 테스트하는 테스트들은 그룹화되어 한 번에 처리된다는 것입니다. 테스트 코드들은 서로 분리되어 있고 테스트 되고 있는 코드와도 분리되어 있습니다. 이는 문제를 쉽게 찾고 해결하게 해줍니다. 편의를 위해 단위테스트는 자동화된 경우에만 동작합니다. 보통 애플리케이션 코드보다 테스트 코드가 더 많으며 테스트를 수동으로 실행하는 것은 매우 좋지 않은..
24DAY 백엔드 - 15DAY 웹 보안 지식 1. MD5와 사용하지 않는 이유 MD5(Message-Digest algorithm 5)는 128비트 암호화 해시 함수이다. RFC 1321로 지정되어 있으며, 주로 프로그램이나 파일이 원본 그대로인지를 확인하는 무결성 검사 등에 사용된다. 1991년에 로널드 라이베스트가 예전에 쓰이던 MD4를 대체하기 위해 고안했다. 1996년에 MD5의 설계상 결함이 발견되었다. 이것은 매우 치명적인 결함은 아니었지만, 암호학자들은 해시 용도로 SHA-1과 같이 다른 안전한 알고리즘을 사용할 것을 권장하기 시작했다. 2004년에는 더욱 심한 암호화 결함[1]이 발견되었고. 2006년에는 노트북 컴퓨터 한 대의 계산 능력으로 1분 내에 해시 충돌을 찾을 정도로 빠른 알고리즘이 발표[2]되기도 하였다. 현재는 MD5 ..
24DAY 백엔드 - 14DAY 캐싱 1. CDN 콘텐츠 전송 네트워크(Content delivery network 또는 content distribution network (CDN))는 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템을 말합니다. 인터넷 서비스 제공자에 직접 연결되어 데이터를 전송하므로, 콘텐츠 병목을 피할 수 있는 장점이 있습니다. CDN의 목적은 높은 사용성과 효율로 사용자에게 컨텐츠를 전달하고 있습니다. 인터넷에 존재하는 컨텐츠의 상당수를 서비스하고 있는데 이에는 웹 요소 (텍스트, 그래픽, 스크립트), 다운로드 가능한 요소 (미디어 파일, 소프트웨어, 문서), 애플리케이션 (전자상거래, 포털), 실시간 미디어, 주문형 스트리밍, 그리고 소셜 네트워크 등이 있습니다. 미..
24DAY 백엔드 - 13DAY API에 대해서 배우기 1. REST 이제는 전통적인 JSP 웹 애플리케이션이나 ASP.NET 애플리케이션처럼 하나의 프로젝트로 전체 애플리케이션을 구현하는 설계보다는 클라이언트와 서버간의 역활 분리 및 서버 애플리케이션의 안정성과 확장성, 그리고 고가용성을 고려한 부산 애플리케이션/API 서버의 구현이 더욱 일반적이 되어가고 있습니다. 이러한 현상은 REST API의 등장 이후 더욱 뚜렷해 집니다. REST API는 Representational State Transfer API의 약자로, 간단히 설명하면 "웹 애플리케이션이 제공하는 각각의 데이터를 리소스, 즉 자원으로 간주하고 각각의 자원에 고유한 URI를 할당함으로써 이를 표현하는 API를 정의하기 위한 소프트웨어 아키텍처 스타일입니다. 특이한 점은 해당 자원에 대한 기..
24DAY 백엔드 - 12DAY 인증 인증이 필요한 이유 클라이언트가 서버에 접속하면 서버는 클라이언트을 식별하기 위해서 인증이 필요합니다. 1. Session / Cookie 방식 Cookie 란? 하이퍼 텍스트의 기록서의 일종으로서 인터넷 사용자가 어떠한 웹사이트를 방문할 경우 그 사이트가 사용하고 있는 서버를 통해 인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일입니다. 1. 사용자가 로그인을 합니다. 2. 서버에서는 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장한 후, 이와 연결되는 세션ID를 발행합니다. 3 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냅니다. 4. 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대..