기술

쿠키와 세션을 사용하는 근본적인 이유에는 HTTP 프로토콜의 특징에 있다→ HTTP 프로토콜은 connectionless와 stateless 한 특성이 있다.⇒ 따라서 이러한 특성으로 인해 발생하는 문제점들을 해결하기 위해 정보를 저장 & 유지하기 위해 쿠키와 세션을

WAS는 특정 로직을 처리해야 하는 동적인 컨텐츠를 제공하는 서버ex) Tomcat, Jeus: 웹 서버는 정적인 컨텐츠를 제공하는 서버ex) Apache, Nginx하지만 일반적으로 WAS는 정적인 컨텐츠도 같이 제공해줄 수 있기 때문에, 웹 서버 없이 WAS만으

Monolithic 의 경우에는 데이터베이스의 ACID 특성을 활용하여 각 로직을 처리하면 DB에서 자체적으로 보장해준다.하지만 Microservice의 경우, 각 서비스마다 별도의 DB를 가지고 있다.→ 따라서, DB에 의존하는 방식으론 이러한 트랜잭션을 일관적으로

Commit 메시지가 누적될수록 가독성이 떨어진다여러 사람과 협업할 때, 각자의 커밋 메시지의 스타일이 다르다면 그 정도가 더욱 심해진다→ 따라서 협업하는 사람들간의 메시지 스타일을 정형화하여 협업의 능률 증진커밋 메시지는 크게 제목(+타입), 본문, 꼬리말로 구분되며

Docker란 Go언어로 개발된 컨테이너 기반의 오픈소스 가상화 플랫폼이다Docker에 대한 개념을 확립하기 위해서는 우선적으로 container(컨테이너)의 의미와 이 기술이 나온 이유부터 이해할 필요가 있다.대부분의 소프트웨어들은 정상적으로 구동하기 위해서는 OS와

특정 유사한 기능을 개발하는 중에 발생하는 다양한 이슈들을 해결하는 데 도움을 주는 일종의 코드 형태이다. 상황에 따라 간편하게 적용해서 쓸 수 있는 것을 정리하여 특정 패턴으로써 정의된 것을 의미한다.간단히 얘기하자면, 프로그램을 구성하는 요소를 Model(데이터

REST란, REpresentational State Transfer의 약자이다.즉, RESTFUL API란 REST의 기본 원칙을 충실히 지킨 서비스의 API를 의미한다.-> 직역하자면, 자원의 표현에 의한 상태를 전달하는 API!자원 ( URI )행위 ( HTTP

협업을 할 때, 아니 굳이 협업을 하지 않더라도 이제 개발자에게 Git은 더이상 선택이 아닌 의무가 되고 있다. 협업을 할때 로컬에서 작업한 내용을 원격 저장소에 업로드할 수 있는 장점은 두말하면 잔소리고... 개인 프로젝트를 진행할 때도 커밋 내역을 보고 롤백하거나,

ElasticSearch는 Apache Lucene기반의 자바 오픈소스 분산 검색 엔진이다.이것도 데이터베이스처럼 따로 데이터를 json 형태로 저장하고 있다.하지만 일반적인 데이터베이스는 데이터를 저장하고 관리하는데에 범용적인 목적을 두고 있다면, ElasticSea

이번에 elasticsearch를 직접 실습해보려고 로컬에 설치하는 과정에서 Permission Denied가 강림했다... 여태까지와 마찬가지로 sudo 명령어를 통해서 해결해보려고 했으나 어김없이 나오는 에러 로그로 인해 결국 구글링을 통해 문제를 해결했다.하지만

Git Merge 동작 방식

일반적으로 (적어도 내 주변에서) WebRTC라고 하면 "그거 그냥 실시간 통신할 때 쓰는 기술 아닌가요?" 라고 생각한다. 하지만 실시간 통신을 사용하기 위한 기술로는 Polling, WebSocket, SSE 등 다양한 기술들이 존재하고, 그 중 하나로 WebRTC

Zoom, Google Meet 등에서 WebRTC로 화상회의 서비스를 제공한다는 소식을 예\~~전에 접했었다. 하지만 그 이후로 나도 모르게 "실시간 영상 서비스? 그럼 WebRTC 사용하겠지~" 라고 어마어마한 착각을 하고 있었다... 아프리카 TV, YouTube

저번 시간에는 Docker의 기본적인 개념과 장단점에 대해 알아보았다.이번에는 좀 더 세부적으로, 왜 이런 장단점이 생길 수 밖에 없는지, 왜 이런 접근 방법으로 Docker를 만들어야했는지 알아보려고 한다.위의 이미지는 Hypervisor 가상화와 Container

백엔드 입장에서 REST API를 사용하다보면 정\~\~~말 비슷비슷한 작업을 수행하는데도 불구하고, 각 플랫폼별로 디자인이 다르고, 같은 플랫폼내에서도 유사한 화면이 많기 때문에 매번 별도의 API로 생성해야하는 일이 다분하다.이럴때마다 "그냥 프론트에서 필요한 데이

#주저리주저리 사내 프로젝트에서 MSA를 도입한다고 간단하게 공부해보고, 이전 포스팅에서 MSA에서 사용되는 분산 트랜잭션에 대해서도 간략하게 정리해보았지만... 결국 빠듯한 일정으로 인해 기존의 Monolithic 형태로 구현했다. 정말 한번쯤 접해보고 싶은 아키텍

IT분야의 빠른 변화와 함께 다양한 키워드들이 부상하고 있다. MSA, Agile, docker 등등, 다양한 기술들이 활발하게 적용된다. 필자는 이런 기술들이 적용되는 이유는 빠르게 변화하는 환경에 대응할 수 있는 확장성을 갖추기 위한 것이라고 생각한다. MSA를 통

싸피 입과 전, 신생 스타트업에서 근무를 할 때, Redis를 사용하여 서비스를 구성하였다. 하지만 단편적인 지식만을 가지고 접근하여 Redis가 가진 특성을 100% 발휘하지 못했던 것 같아, 이번 기회에 정리해보려고 한다.최근 여러 기업들의 기술 블로그를 탐방하는

Redis는 다양한 자료구조를 공식적으로 지원하고 있다. 하지만 정작 그 자료구조의 특징과 내부 동작에 대해서 무지한 채로 남용하게 된다면, 사용하지 않는 것보다 못할 수 밖에 없다.아래의 자료구조는 전부 Redis에서 공식적으로 지원하는 자료구조다.StringList