템닉의 개발저장소

운영중인 체계에서 11월 20일부터 DB에 메일 발송 내역이 쌓이지 않는 것을 발견하였다.
깃에 올라와있는 당일 변경 내역은 메일 발송에 크게 영향을 주는 부분이 아니었어서 약간 당황스러웠다.
변경 내역이 DB쪽과 충돌을 일으키나 싶어서 DB에 입력되어있는 ID값을 확인해봤는데 DB에도 잘 적용이 되어있었다.
흠… 디버깅 모드를 켰지만 내가 아직 디버그에 미숙한건지 발견해내지 못했다.
포스트맨으로 확인해보려고 했으나 body에 넣어줘야할 값들이 41개정도 들어가는 걸로 확인을 해서 다른 방법을 찾으려 했다.
일단 크론탭으로 돌아가는 시스템이기에 서버로그에 메일발송 관련 로그가 찍혀있을것이라고 생각을 했다.
그런데 메일발송완료 로그는 찍혀있었다. 당일로부터 5일 내외를 확인해봤는데 모두 로그가 찍혀있었다.
서버 로그 확인시에 11월 20일자에 서버가 한번 셧다운되었다가 다시 작동하기는 했었다.
그 이후로 NoSuchMethodError가 발생하기 시작했다.
관련해서 자료를 찾아보았는데, 아마 최신 버전 수정후 배포할때 문제가 있지 않았을까 생각이들었다.
다음 내역들을 하나하나 확인해보려고 했다.

• 매개 변수를 잘못 사용했을까?
• 메소드가 아예 없는가?
• 타이핑 오류가 있는가?
• 클래스,  jar가 정상적으로 올라가 있는가?
• 내부에서 참조하는 lib가 빠졌는가?
• classpath 상에서 중복되는 class가 있어서 메서드를 정상적으로 찾지 못하는가?

우선 1~3 까지 인텔리제이에서 확인했을때는 문제가 없었다.
매개변수 잘못 사용했는지 확인하려고 스택트레이스 에러메시지를 읽으면서 관련부분을 찾았다.
Djava. Ljava 이런식으로 나오는 로그에 대해서도 알게되었다.


https://okky.kr/articles/338405
이 글을 참고하니 도움이 많이 되었다.

따라서 이때 코드상의 문제가 아니라 배포하면서 문제가 생겼을 것이라고 확신했다.

이때 자바 디컴파일러를 처음 사용해봤다. gui버전이라서 그렇게 어렵지 않았다.
파일질라에서 운영 서버 접속후 문제가 되는 것처럼 보이는 클래스를 로컬에 저장하고, 디렉토리 따라 파일만 찾아주면 디컴파일하는데 시간은 걸리지만 바로 어떤 클래스가 돌아가고 있었는지를 확인 할 수 있었다.

확인해본 결과 깃에 올라온 버전은 수정이 된 버전인데 서버에 붙어있는 파일은 예전 버전이라서 실제로 메소드가 없었던 것이다.

깃에 올라온 코드를 전적으로 신뢰하면 안된다는 것을 느꼈다. CICD가 구축되는 환경이라면 이런일도 없었을텐데.. 라는 아쉬움도 들고 나중에 CI/CD 공부를 해보긴 해야겠다는 생각도 하게되었다.

이전 시간에 배운 것

1. 스프링부트 동작 원리

(1) 내장 톰캣을 가진다.

(2) 서블릿 컨테이너

오늘은 (2) 서블릿 컨테이너를 배우기 전에 Tomcat에 대한 공부를 먼저 할 것이다.

http: 소켓으로 만들어짐. 
http같은 프로그램이 운영체제를 통해 소켓을 불러와서 쓰는 것이 시스템 콜이라고한다. (시스템이 들고 있는 기능을 콜함)

톰캣과 웹 서버에 대한 차이를 알아야하고, 웹 서버에 대해서 이해를 해야한다.

을이 갑에게 request(요청)하는 형식, request할때는 IP주소를 알아야하고, 어떤 Data가 필요한지 URL을 알아야한다. (자원을 요청하는 주소) URL의 L은 Location의 L이다. Request가 들어가면 갑이 Response를 해준다. 이때 갑이 웹서버이다. 갑은 을의 IP주소를 모르고 요청할때만 응답해주는 구조이다. 요청하지 않았을때 응답을 못함. 

소켓통신은 연결되어있기 때문에 언제나 데이터를 전달해 줄 수 있지만, 웹서버는 갑이 을의 IP주소를 모르기 때문에 데이터를 요청시에만 보낼 수 있다. 이때 자원들은 Static자원이라고 한다. 

그래서 톰캣이 뭐냐?

흔히 사용하는 웹서버 중 하나가 아파치이다. 컴퓨터에 특정 폴더인 C/Work라는 폴더를 공유한다고 하자. .JSP(자바코드)를 request을 하면, 아파치는 자바 코드를 이해하지 못해서 응답하지 못한다. 그렇기 때문에 톰캣을 달아서 이해하지 못하는 요청에 대한 제어권을 톰캣에게 넘기고, 톰캣은 JSP파일을 자바 파일로 컴파일하며, .html에 덮어씌운다. 그리고 아파치에게 돌려주고, 그 html파일을 아파치가 response하는 구조이다. 또한 웹브라우저도 JSP를 이해하지 못하기에 톰캣이 컴파일해서 돌려줘야 이해할 수 있다.

다음시간에 배울 내용

(2) 서블릿 컨테이너 (진짜)

이 블로그 포스팅은 인프런 최주호님의 스프링부트 개념정리(이론) 강의에 대한 정리 포스팅입니다. 
다음은 강사님의 강의 링크입니다. 무료 강의라서 가입만 하면 볼 수 있습니다. (강의 링크)

이전 시간에 배운 것

1. JPA란?

• JPA는 Java Persistence API이다.
• JPA는 ORM 기술이다.
• JPA는 반복적인 CRUD 작업을 생략하게 해준다.
• JPA는 영속성 컨텍스트를 가지고 있다.
• JPA는 DB와 OOP의 불일치성을 해결하기 위한 방법론을 제공한다. (DB는 객체저장 불가능)
• JPA는 OOP의 관점에서 모델링을 할 수 있게 해준다. (상속, 콤포지션, 연관관계)
• 방언 처리가 용이하여 Migration하기 좋음. 유지보수에도 좋음
• JPA는 쉽지만 어렵다.

1. 스프링부트 동작 원리

(1) 내장 톰캣을 가진다.

톰캣을 따로 설치할 필요가 없다. 즉시 실행 가능.

Socket: 운영체제가 가지고 있는 것. A라는 대상이 있고, B라는 대상이 있는데 메시지를 교환하려고 함. 이때 소켓을 이용한다.
처음에 A가 소켓을 오픈한다. 5000번 포트를 열고 소켓을 오픈 했다. B가 A와 통신하고 싶다면, 5000번 포트와 A가 있는 IP주소를 넣어서 전송한다. 

C가 A와 통신을 하고 싶어하는데, B와 A간의 통신에 5000번 포트를 사용하고 있기 때문에, C가 5000번 포트로 연결할 수 없음.
따라서 5000번 포트는 연결용으로만 쓰고, 연결이 된 이후의 통신은 랜덤한 포트(편의상 5001)를 사용하는 시스템을 사용. 
그런데 만약에 5001번 포트를 통해서 B와 A가 통신할때, CPU는 모든 자원을 5001번 포트의 통신에다가 쓰게 되어 5000번 포트가 작동하지를 못함. 따라서 5001번에는 새로운 스레드를 만들어주어야한다.

5000번에는 메인 스레드, 새로운 사용자의 요청을 받는다.
5001번에는 스레드 1, B와 통신하는 스레드
이런 시스템을 통해 C는 5000번에 연결하고, 5002번에 스레드 2가 만들어지면서 5000번 연결이 끊기고, 5002번에 연결되면서 통신하게 된다.

소켓통신 , time slice, 동시 동작
-> 연결이 끊어지지 않기 때문에 부하가 크고, 연결이 많아질 경우 느려질수 있다.

http 통신은 stateless방식을 사용. A, B 가 C와 연결해서 데이터를 받으려고 한다.
근데 Http는 문서를 전달하는 통신인데, A가 C에게 a.txt 달라고 80번 소켓에 연결. 다이렉트로 돌려주고 통신선을 끊음
B도 마찬가지로 b.txt.파일을 응답해주고 끊어버린다.
-> 연결이 끊어져서 부하가 적지만, 다시 연결될때 새로운 사람으로 인식함.
http는 cern연구소에서 다양하게 퍼져있는 논문들을 하나의 서버로 모아놓고 필요할때만 html문서를 꺼내쓰는 것이 목적이었기 때문에 연결을 끊는 방식을 채택했다.

이러한 단점들을 보완한게 Web Server임.

다음 시간에 배울 내용

(2) 서블릿 컨테이너

...더 보기

이 블로그 포스팅은 인프런 최주호님의 스프링부트 개념정리(이론) 강의에 대한 정리 포스팅입니다. 
다음은 강사님의 강의 링크입니다. 무료 강의라서 가입만 하면 볼 수 있습니다. (강의 링크)

이전 시간에 배운 것

1. JPA란?

• JPA는 Java Persistence API이다.
• JPA는 ORM 기술이다.
• JPA는 반복적인 CRUD 작업을 생략하게 해준다.
• JPA는 영속성 컨텍스트를 가지고 있다.
• JPA는 DB와 OOP의 불일치성을 해결하기 위한 방법론을 제공한다. (DB는 객체저장 불가능)

• JPA는 OOP의 관점에서 모델링을 할 수 있게 해준다. (상속, 콤포지션, 연관관계)

Class Car {
    int id;
    String name:
    String color:
    Engine engine; // <- 컴포지션
}

Class Engine {
    int id;
    int power;
}

잘 만든 엔진을 차에 상속하고 싶지만, 엔진이 차의 부모가 되는 관계가 형성이 되면 말이 안된다. 컴포지션이라는 방법을 써야한다. (결합)  
JPA는 DB를 먼저만들고 그 테이블을 통해 Car클래스를 모델링하는게 아니라, 클래스를 먼저 만들고 이를 토대로 자동생성을 해서 DB에 테이블을 만들어주기 때문에 다음처럼 만들어진다.

모든 클래스에 날짜를 넣고 싶을때 

Class EntityDate{
    Timestamp createDate;
    Timestamp updateDate;
}

이처럼 EntityDate 클래스를 만들고 각 클래스에 상속시킨다.

Class Car extends EntityDate {
    int id;
    String name:
    String color:
    Engine engine; // <- 컴포지션
}

Class Engine extends EntityDate {
    int id;
    int power;
}

• 방언 처리가 용이하여 Migration하기 좋음. 유지보수에도 좋음

스프링을 JPA를 이용해서 DB에 접근을 한다. 이때 JPA가 무조건 MySQL만 지원을 한다면 DB접근이 MySQL밖에 안됨. 하지만 Dialect( 오라클, 마리아, MSSQL, PostgreSQL)들이 있기때문에 JPA에 추상화객체가 붙어있어서 각 Dialect에 연결되는 구조.

• JPA는 쉽지만 어렵다.
  
  개념이 조금 헷갈림. 기존에 사용하던 방식과 다르고 생소한 개념들이 많이 나오는데, 적응하면 쉬워짐. 적응하다 보면 또 무자비한 Select 때문에 해결하기 어려워짐. 

이 블로그 포스팅은 인프런 최주호님의 스프링부트 개념정리(이론) 강의에 대한 정리 포스팅입니다. 
다음은 강사님의 강의 링크입니다. 무료 강의라서 가입만 하면 볼 수 있습니다. (강의 링크)

이전 시간에 배운 것

1. JPA란?

• JPA는 Java Persistence API이다.
• JPA는 ORM 기술이다.
• JPA는 반복적인 CRUD 작업을 생략하게 해준다.

• JPA는 영속성 컨텍스트를 가지고 있다.
  영속성 : 데이터 -> 영구적으로 저장하는 속성 (자바에서는 DB에 저장)
  컨텍스트란? Context: 모호한 개념 중 하나. 모든 컨텍스트를 가지고 있다 == 모든 정보를 가지고 있다. "대상의 모든 정보"
  영속성 컨텍스트에 있는 데이터와 DB 데이터는 동기화가 됨. 따라서 동물 데이터를 영속성 컨텍스트를 통해 DB에 입력했을때, 영속성 컨텍스트 내의 동물 데이터를 지우면 DB의 동물 데이터도 같이 지워짐. Select를 통해서 DB의 과일 데이터에 접근시 영속성 컨텍스트를 거쳐서 DB로 이동함. 영속성 컨텍스트에는 과일 데이터가 없기 때문에 자바 오브젝트로 바꾼 과일 데이터를 가진다. 영속성 컨텍스트는 자바 오브젝트 타입의 과일데이터를 자바에게 넘겨준다. 
  
  이때 자바, 영속성 컨텍스트, DB의 데이터는 서로 일치하는데, 자바에서 과일 데이터 중 사과를 딸기로 변환하면 영속성 콘텍스트에 있는 과일 데이터가 딸기로 변하고 커밋해서 밀어넣는 경우 과일 데이터의 형상이 달라져서 insert가 아니라 update가 일어난다. 
  
  자바는 항상 영속성 컨텍스트를 통해서 디비에 데이터를 저장하고, 데이터베이스의 데이터도 영속성 컨텍스트를 통해서 자바쪽으로 전달이 된다. 그리고 영속성 컨텍스트에서 일어난 모든 일들은 자동으로 처리가 된다.
  
  
• JPA는 DB와 OOP의 불일치성을 해결하기 위한 방법론을 제공한다. (DB는 객체저장 불가능)
  야구 DB에 team(ID, Name, year)과 player(ID, Name, teamId) 테이블이 있다고 하자.
  각 컬럼들은 가질 수 있는 데이터가 기본 자료형이다. Object를 데이터로 가지지 않는다.
  자바의 관점에서 보면, 
  
  

Class Team {
	int id;
    String name;
    String year;
}

Class player {
	int id;
    String name;
    int teamId;
}

자바는 object를 저장할 수 있기 때문에,

Class Team {
	int id;
    String name;
    String year;
}

Class player {
	int id;
    String name;
    Team team;
}

이 될 수 있음. 
ORM 덕분에 자바가 주도권을 쥐고 있는 모델을 만들 수 있음.
또, JPA가 자동으로 DB에 FK(외래키) 데이터를 넣어줌.

다음 시간에 배울 내용

• JPA는 OOP의 관점에서 모델링을 할 수 있게 해준다. (상속, 콤포지션, 연관관계)
• 방언 처리가 용이하여 Migration하기 좋음. 유지보수에도 좋음
• JPA는 쉽지만 어렵다.

이 블로그 포스팅은 인프런 최주호님의 스프링부트 개념정리(이론) 강의에 대한 정리 포스팅입니다. 
다음은 강사님의 강의 링크입니다. 무료 강의라서 가입만 하면 볼 수 있습니다. (강의 링크)

이전 시간에 배운 것

1. JPA란?

• JPA는 Java Persistence API이다.

• JPA는 ORM 기술이다.
  ORM은 Object Relational Mapping의 약자로, 오브젝트를 데이터베이스에 연결하는 방법론 중 하나이다. 
  "ORM은 나의 하인 같은 기술"
  추상적인 개념을 현실세계로 뽑아내는 개념을 모델링이라고 한다.
  Team 테이블에 ID, Name, Year를 넣고 자바에서 사용을 할텐데, Input과 Output이 각각 DML(Delete, Update, Insert), Select라고한다. 자바는 테이블 데이터 타입을 가지지 않는다. 따라서 클래스를 통해서 데이터베이스의 테이블을 모델링해야한다.
  
  

class Team{
	int id;
    String name;
    String year;
}

DB 세상에 있는 데이터를 자바 세상에 모델링한다. 

그런데 ORM은 Class를 먼저 만들고 DB를 자동생성할 수 있는 기술이다. JPA가 가지고 있는 인터페이스 덕분에 자바 클래스를 짜면 테이블을 만들 수 있다. 

• JPA는 반복적인 CRUD 작업을 생략하게 해준다.
  Select 1건
  Select All 전체
  Delete 1건
  Update 1건
  Insert 1건
  자바에서 DB로 연결하기위해서 신원을 확인하고 DB가 세션을 오픈하면 커넥션 시킬 수 있다. 이때 자바가 쿼리를 전송한다. DB는 해당 쿼리를 통해, 어떤 작업을 통해 데이터를 만들어내고, 자바에 응답한다. 응답시 DB 타입값과 자바 타입값이 다르기 때문에 자바 Object로 바꿔야한다. 이때 자바 Object로 바꾸는 작업은 단순한 반복노동이기에 JPA를 사용해서 전송된 쿼리에 대한 응답이 있을때 이 데이터를 받고 자바 오브젝트로 바꾸고 연결된 세션을 끊고, 연결된 커넥션을 끊고하는 이러한 모든 일련의 과정들을 함수 하나로 제공해준다. 기본적인 CRUD를 단순하게 처리하도록 도와준다. 이런 단순한 CRUD를 도와주는 것도 ORM이 해준다.
  
  

다음 시간에 배울 내용

• JPA는 영속성 컨텍스트를 가지고 있다.
• JPA는 DB와 OOP의 불일치성을 해결하기 위한 방법론을 제공한다. (DB는 객체저장 불가능)
• JPA는 OOP의 관점에서 모델링을 할 수 있게 해준다. (상속, 콤포지션, 연관관계)
• 방언 처리가 용이하여 Migration하기 좋음. 유지보수에도 좋음
• JPA는 쉽지만 어렵다.

이 블로그 포스팅은 인프런 최주호님의 스프링부트 개념정리(이론) 강의에 대한 정리 포스팅입니다. 
다음은 강사님의 강의 링크입니다. 무료 강의라서 가입만 하면 볼 수 있습니다. (강의 링크)