꾸준함

예외 계층 예외도 객체이기 때문에 Object가 최상위 부모 Throwable이 최상위 예외이며 하위에는 Exception과 Error가 존재 Error는 Out of Memory 혹은 시스템 오류와 같이 애플리케이션 내 복구 불가능한 시스템 예외 이러한 예외는 잡아도 별도로 처리할 수 있는 방법이 없으므로 언체크 예외 가끔 귀찮다고 try catch문을 Throwable로 잡는 경우가 있는데 이럴 경우 Error 예외도 함께 잡을 수 있기 때문에 이러한 코드는 안 좋은 안티 패턴 Exception은 애플리케이션 로직에서 사용할 수 있는 실질적인 최상위 예외이며 잡아서 처리해줘야 하는 체크 예외 Exception의 하위 예외는 모두 컴파일러가 체크하는 체크 예외이지만 RuntimeException의 경우..

클라우드 컴퓨팅 인터넷을 통해 컴퓨팅과 가상화된 IT 서비스를 제공하여 유연하고 안전하면서 사용하기 쉬운 환경을 제공하는 것 여기서 IT 서비스는 DB, 서버, 소프트웨어, 네트워크, 분석 등을 포함 낮은 초기 투자 비용, 유지 보수 용이성, 그리고 확장성과 같은 이점 제공 사용자는 클라우드 컴퓨팅 모델에 따라 제공받는 정보 및 서비스 통제 수준을 선택할 수 있음 ex) IaaS, CaaS, PaaS 등 이를 통틀어서 XaaS라고 칭함 (Anything as a Service) OPEX 비용은 증가하지만 CAPEX 비용을 줄일 수 있는 것이 특징 OPEX (Operating Expense): 운영 비용 CAPEX (Capital Expenditures): 투자 비용 대표적인 클라우드 컴퓨팅 소개 IaaS..

개요 이번 포스팅에서는 Kafka를 도입해야 하는 이유와 함께 Kafka 관련 개념 설명과 모니터링 오픈소스에 대해 정리해보겠습니다. 이번에 알아볼 개념과 모니터링 툴은 아래와 같습니다. topic broker, replication, ISR partitioner consumer lag burrow (모니터링 오픈소스) 1. Kafka를 도입해야 하는 이유 데이터를 전송하는 소스 애플리케이션과 데이터를 받는 타깃 애플리케이션이 있고 초기에는 간단하게 단방향 구조라고 가정 시간이 지나 소스와 타겟 애플리케이션이 늘어나면서 라인이 복잡해짐 이에 따라 배포 및 장애 대응에 어려움이 느껴지고 데이터 전송할 때 프로토콜, 포맷 파편화가 심해져 유지보수가 힘들어짐 이런 복잡함을 해결하기 위해 Apache Kafka..

타임리프 특징 서버 사이드 렌더링 (SSR) Natural Template 스프링에서 권장하고 통합 지원 1. 서버 사이드 렌더링 (SSR) HTML 최종 결과를 서버에서 만들어 웹 브라우저에 전달 정적인 화면에서 자주 사용 JSP, 타임리프가 대표적인 예시이며 현재는 타임리프를 주로 사용 * SSR을 사용하더라도, 자바스크립트를 통해 화면 일부를 동적으로 변경 가능 (무조건 정적인 페이지는 아님) 2. Natural Template 타임리프는 순수 HTML을 최대한 유지하기 때문에 웹 브라우저에서 파일을 직접 열어도 HTML 내용을 확일할 수 있음 (퍼블리셔로부터 파일을 전달받을 때 리뷰하기 유용함) 서버를 통해 뷰 템플릿을 거치면 동적으로 변경된 결과 확인 가능 정리를 하자면, 타임리프 파일을 열었을..

전체적인 흐름 레지스트리로부터 이미지를 PULL 받고 이미지를 실행시키기 위해 컨테이너를 생성(CREATE)한 뒤 START 명령어를 통해 메모리에 띄워서 애플리케이션 실행 (CREATE와 START 명령어를 하나로 묶어 RUN 명령어 대체 가능) 컨테이너에 추가된 내용을 이미지화하기 위해 COMMIT 명령어를 실행 이미지를 레지스트리에 등록하기 위해 PUSH 명령어 실행 (이때, 권한 필요) 컨테이너를 중지시키기 위해 STOP 명령어 실행 컨테이너 제거를 위해 RM 명령어 실행 (우선, STOP 명령어가 실행되어있어야 함) 이미지를 삭제하기 위해 RMI 명령어 실행 추가 설명 PULL만 받은 이미지는 실행 불가능한 상태 (실행 위해서는 컨테이너가 필요) RUN 명령어를 실행할 때마다 컨테이너를 생성하기..

개요 2019년에 인턴 생활을 했을 때, MSA(Micro Service Architecture)라는 키워드가 동기들 사이에서 자주 등장했었고 실제로 면접에서도 자주 등장했었던 내용이었습니다. 그리고 지금 현재 2021년에는 웬만한 플랫폼 서비스에서 Docker가 사용되고 있고, 많은 기업들이 기존의 레거시 서비스를 모놀리식 아키텍처(Monolithic Architecture)에서 마이크로 서비스 아키텍처로 전환하고 있기 때문에 도커와 마이크로 서비스에 대해서는 알아두는 것이 좋을 것 같습니다. 모놀리식 아키텍처 구시대적 서비스 방법 서비스가 하나의 애플리케이션으로 실행되는 구조 즉, 하나의 거대한 아키텍처 다양한 기능을 동작하는 서비스를 서버에서 실행 모놀리식 아키텍처 장점 하나의 애플리케이션이기 때문..

개요 PRG 패턴의 경우 실제 현업에서 자주 사용하므로 개념을 숙지할 필요성이 있습니다. 상황 설명 아래의 그림과 같이 회원 등록 폼 페이지를 호출하는 컨트롤러 URL과 회원 등록하는 컨트롤러 URL이 동일하다고 가정 (HTTP Method로 구분) 회원을 폼에 등록하면 해당 폼은 회원 등록하는 컨트롤러를 호출하고 해당 컨트롤러는 회원 개인정보 View를 호출하는 구조 이때, 회원 개인정보 페이지의 URL은 여전히 회원 등록하는 컨트롤러 URL이므로 새로고침을 할 때마다 회원을 신규 등록하는 문제점이 발생 (회원을 구분 짓는 Primary Key가 BigInteger 타입이고 AutoIncrement라는 가정) 문제 해결방법 앞선 상황에서 문제점은 회원 등록하는 URL에서 변하지 않은 상태에서 새로고침 ..

복습 기존의 Servlet, JSP를 통한 MVC Pattern의 한계점을 복습해봅시다. (https://jaimemin.tistory.com/1815) 뷰 렌더링과 컨트롤러 역할을 분리한 건 좋지만 페이지가 늘어남에 따라 컨트롤러 내 중복 코드 다량 발생 View로 이동하는 Forward 코드 중복 View 주소 즉, ViewPath 설정하는 코드 중복 별도 응답을 보낼 필요가 없는 경우 서블릿 내 response 코드가 사용되지 않음 HttpServletRequest, HttpServletResponse를 사용하는 테스트 코드 작성하기 쉽지 않음 정리하자면, 공통 처리가 어려운 것이 문제 (이를 해결하기 위해 Front Controller 패턴 도입) Front Controller의 특징 서블릿 하나..

개요 부끄러운 얘기지만 저 같은 경우 웹 프레임워크를 배울 때 처음부터 Front Controller 패턴으로 접했기 때문에 요청을 처리하는 과정을 완벽하게 이해하지 못한 상태로 개발을 시작했습니다. 따라서, 조금 옛날 기술이지만 서블릿과 JSP를 통해 MVC 패턴이 탄생하게 된 기원을 이해하고 어떠한 한계점이 있어 Front Controller 패턴이라는 개념이 등장했는지 알아보고자 합니다. MVC Pattern 이전 사용자의 요청을 서블릿이나 JSP가 전부 다 처리 (Controller의 부재) 웹브라우저 사용자의 요청을 받은 서블릿이나 JSP는 비즈니스 로직을 처리하고 뷰 렌더링까지 처리 뷰 화면을 위한 HTML 만드는 작업과 비즈니스 로직을 모두 서블릿 내에서 처리할 경우 HTML 코드를 자바 코..

WAS를 직접 구현하는 경우 프로세스 서버 연결 대기, 소켓 연결 HTTP 요청 메시지 파싱 HTTP 메서드, URL 확인 Content-Type 확인 HTTP 메시지 바디 내용 파싱 메서드 프로세스 실행 개발자가 개발한 비즈니스 로직 실행 HTTP 응답 메시지 생성 (HTTP 시작 라인, Header, 메시지 바디 생성) 서버 응답 전달 소켓 연결 종료 서블릿을 지원하는 WAS 사용할 경우 상단에 언급된 프로세스 중 비즈니스 로직 실행하는 프로세스 제외 모두 실행 (7번 제외 모두 실행) 즉, 개발자에게 편리성 제공 서블릿 특징 urlPatterns 필드의 URL 호출할 경우 서블릿 코드 실행 HttpServletRequest 객체를 통해 HTTP 요청 정보 편리하게 사용 가능 HttpServletRe..