코딩은 내일부터

DB 커넥션은 개수가 제한적이므로 단위 프로그램이 커넥션을 소유하는 시간이 길어질수록 사용 가능한 커넥션의 개수는 줄어든다. 따라서 하나의 작업이(트랜잭션이 필요 없는 로직이 붙어있는) 아무리 빨리 처리한다 해도 DBMS 트랜잭션에 포함될 필요 없다. 그리고 어느 순간 각 단위 프로그램에서 커넥션을 가지기 위해 대기해야 하는 상황에 안 좋을 수,,,,,, 위에 내용은 Real MySQL을 읽으면 나오는 내용으로 DB의 커넥션을 오래 가지고 있으면 웹 서버뿐 아니라 DB서버의 장애로 이어지는데 특히 지금 개발하고 있는 동글 서비스는 외부 API와 통신하는 로직이 많다. 만에 하나 외부 API를 요청할 때 서버와의 송수신의 문제가 생긴다면 현재 API요청 로직과 DB로 쿼리를 요청하는 로직이 섞여있어 DB서..

서론 및 버그가 일어나는 상황 동글 프로젝트를 하면서 개발서버와 실제 배포서버 2개의 서버를 사용하고 있는 상태였다.(DB서버까지 하면 총 3개다.) 회원가입 기능을 만들고 개발서버에서 1/10확률로 회원가입을 하면 똑같은 회원이 2명 생기는 거였다. 그래서 그 회원은 우리가 DB에서 1명 제거하지 않는 이상 로그인을 못하는 상황이다. 분명 OAuth로그인을 할 때 회원이 아니면 회원가입하게 로직을 구현해 놨는데 회원가입이 2번 일어나 나는 거였다. 프론트에서 말하길 react에서 api 로직을 수행하려면 useEffect라는 훅 내부에서 api 함수를 호출하는데 이 useEffect가 개발모드에서는 두 번 API가 호출된다. 그래서 이것 때문이구나 생각을 했는데 어떻게 해결해야 하는지 감이 안 왔다. ..

동글 프로젝트 특성상 블로그에 글을 발행하고, 글의 정보를 얻어오고,... 등등 이러한 정보를 얻기 위해서는 외부 API를 통해 데이터를 얻어오는데 요청하는 값과 응답하는 값이 비슷해서 공통 메서드를 분리해서 추상화시키면 좋을 거 같아서 팀원에게 의견을 말한 결과 추상화를 시키자고 결론을 내렸다. 이번 포스팅은 내가 어떻게 외부 API를 추상화를 진행했는지 글을 써보려고 한다. 원래 구조 먼저 원래 코드는 API를 처리하는 부분이 앞단에 있고 인증 인가를 담당하는 부분이 뒤에 있었다. 외부 API를 담당하는 부분을 우리 중요 비즈니스가 아닌 외부 시스템으로 보고 인프라스트럭처라고 생각해서 위에 사진에 있는 현재 구조가 아닌 기대하고 있는 구조를 생각하면서 리팩터링을 시작했다. 공통 메서드 추출 추상화를 ..

Thread를 이해하기 위해서는 Process를 이해해야하는데 Process Process는 실행된 프로그램을 가리키는 말이고, 프로세스는 OS에서 실행될때 필요한 자원을 할당 받게된다.(데이터 or 메모리 or CPU) 프로세스가 할당받은 자원은 다른프로세스와 공유가 안된다.(!!!) Thread Thread는 Process가 실행되면 관련 로직(연산, 화면처리 등등..)을 수행할때 작업을 수행해주는 일꾼이라고 생각하면 편할거같다. 여기서 중요한 점은 Process는 자원을 공유하지않는다고 위에서 얘기했지만, Thread는 자원을 공유한다(!!!!!!!!) Thread가 여러개일때 문제점 그래서 다중 스레드 환경에서 두 개 이상의 스레드가 변경 가능한(mutable) 공유 데이터를 동시에 업데이트하면 ..

이번글은 톰캣을 구현하면서 공부한 HTTP, 톰캣 그리고 헷갈렸던 포인트인 서블릿부분을 포스팅했다. 웹 서버 웹 서버는 http요청을 처리하고 응답을 제공한다. 웹 서버는 HTTP프로토콜을 구현하고, 웹 리소스를 관리하고, 웹 서버 관리 기능을 제공하는데 기본 웹 서버의 요청은 다음 사진과같이 이루어진다. 우리가 http://localhost:8080/beaver.index페이지를 열어볼 때, 웹브라우저는 HTTP요청을 http://localhost:8080서버로 보낸다. 서버는 요청받은 객체를 찾고, 성공했다면 그것을 타입, 길이 등의 정보와 함께 http응답에 실어서 클라이언트에게 보낸다. HTTP가 뭔데? HTTP는 Hyper Text Transfer Protocol의 두문자어로, 인터넷에서 데이터..

개발을 하면서 도커라는 단어를 많이 접할거다. 도커 왜씀? 먼저 개발을 하면서 특정 프로그램을 다운받는 과정을 생각해보자 보통을 위와같은 흐름으로 프로그램을 설치할 것 이다. But!!! 원하는 흐름대로 프로그램 설치가 안될것이다. 왜냐면 일반적으로 첫번째 사진처럼 흘러가지만, 갖고있는 서버, 버전,운영체제 등등 여러환경에서 에러가 발생한다. 그리고 설치과정이 (비교적)복잡하다(?) 이러한 과정을 도커한테 실행시켜줘라고 말하면 도커는 바로 실행 시켜준다!! 이렇게 도커의 장점 중 하나를 알아봤다. 다음으로는 도커가 무엇인지 알아보겠다. 도커가 뭔데? 컨테이너를 사용하여 응용프로그램을 더 쉽게 만들고 배포하고 실행할 수 있도록 설계된 도구 이며 컨테이너 기반의 오픈소스 가상화 플랫폼이며 생태계이다. 라고 ..

트랜잭션이란? 트랜잭션은 꼭 여러개의 변경작업을 수행하는 쿼리가 조합됐을때 의미 있는 개념이 아니다. 작업이 모두 적용되거나 아무것도 적용되지 않아야함을 보장해주는것을 의미한다. 다시 말해 논리적 작업 단위를 트랜잭션이라고 부른다. ACID? 그게 뭔데. ACID는 트랜잭션의 4가지 특성의 약자들을 모아놓은거다. Atomicity(원자성) 원자성이란 하나의 트랜잭션이 모두 성공하거나, 모두 실패해야하는 성질이다. 말 그대로 작업을 수행하는 도중 하나의 쿼리가 잘못됐을때 그 전에 수행한 쿼리는 모두 반영되지 않고 초기 상태로 돌린다는 뜻이다. Consistency(일관성) 일관성은 하나의 트랜잭션 이전과 이후, 데이터베이스의 상태는 이전과 같이 유효해야한다는 것이다. 예를 들어 비버 서비스의 회원가입할때 ..

OAuth가 뭐야? Oauth를 검색해보면 위키백과에는 이렇게 정의하고있는데… 이렇게 보면 잘모르겠다.. 예를 들어서 설명하면 비버라는 서비스를 이용하고있는데 서비스중에 카카오톡에 내 프로필사진을 가져오는 가능이있다고가정을 하겠다. 사용자는 비버한테 카카오톡 아이디와 패스워드를 입력하면 카카오톡의 프로필사진을 가져오는 흐름이다. 이때! 사용자 입장에서는 비버를 믿을 수 없고(카카오톡에 다른 정보를 빼오면 어떡하지?) 비버 입장에서도 이러한 정보를 가지고있는것이 부담이 될 수 있다. (만약에 비버서비스를 해킹 당해서 사용자의 정보가 노출이 될 수 있으니까!!) 그리고 카카오톡 입장에서도 높은 보안으로 서비스를 만들어놨는데 이러한 정보가 노출되는게 싫을거같다. 그래서 도입할 수 있는게 OAuth이다. 쉽게말..