일일신우일신

토비의 스프링: Vol. 1: 스프링의 이해와 원리 스프링은 주로 자바 엔터프라이즈 환경에서 동작하는 애플리케이션을 개발하는 목적으로 사용됨 아키텍처: 어떤 경계 안에 있는 내부 구성요소들이 어떤 책임을 갖고 있고, 어떤 방식으로 서로 관계를 맺고 동작하는지를 규정하는 것 시스템 레벨 아키텍처 결정하기 스프링 엔터프라이즈 애플리케이션의 서비스와 협력 구조 애플리케이션 서버 스프링으로 만든 애플리케이션을 자바 서버환경에 배포하려면 JavaEE(.J2EE) 서버가 필요함 JavaEE 서버 종류 WAS(Web Application Server): 완전한 웹 애플리케이션 서버 경량급 WAS / 서블릿 컨테이너: 톰캣(Tomcat) 등의 가벼운 서블릿 컨테이너 실제 개발환경과 운영환경에서 가장 많이 사용되는 자바..

토비의 스프링: Vol. 1: 스프링의 이해와 원리 스프링의 정의 스프링의 정의: 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크 애플리케이션 프레임워크: 특정 계층이나, 기술, 업무 분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크 스프링의 일차적인 존재 목적: 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용해서 엔터프라이즈 애플리케이션 전 계층과 전 영역에 전략과 기능을 제공해줌으로써 애플리케이션을 편리하게 개발하게 해주는 애플리케이션 프레임워크 경량급: 군더더기 없이 깔끔한 기술을 가진 프레임워크 자바 엔터프라이즈 개발을 편하게: 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 많은 신경을 쓰지 않으면서도 애플리케이션의 핵심인 사용자의 요구사..

1부와 2부에서는 디스크에 저장된 데이터의 레이아웃부터 결함이 있는 상황에서의 분산된 일관성의 한계까지, 분산 데이터베이스로 가기 위해 고려해야 할 모든 주요 사항들을 살펴봤다. 하지만 1, 2부에서는 애플리케이션이 단일 데이터베이스를 사용한다고 가정했다. 사실 데이터 시스템은 더 복잡하다. 큰 애플리케이션에서는 데이터를 접근하고 처리하는 데 다양한 종류의 데이터베이스 및 시스템이 필요하다. 하지만 모든 요구사항을 만족하는 하나의 데이터베이스는 없기 때문에, 대개 여라 다른 데이터스토어, 색인, 캐시, 분석 시스템 등 몇 가지를 조합해서 사용하고 한 저장소에서 다른 저장소로 데이터를 이동하는 메커니즘을 구현한다. 3부에서는 데이터 모델도 다르고 최적화도니 접근 양식도 다른 여러 데이터 시스템을, 일관성 ..

토비의 스프링: Vol. 1: 스프링의 이해와 원리 스프링의 3대 핵심 기술 IoC/DI 서비스 추상화 AOP 스프링이 가장 가치를 두고 적극적으로 활용하려고 하는 것은 결국 자바 언어가 기반을 두고 있는 객체지향 기술 리소스 변환 DI JAXB(Java Architecture for XML Binding): XML를 동일한 구조의 오브젝트로 매핑해줌 언마샬링(unmarshalling): XML 문서를 읽어서 자바의 오브젝트로 변환 마샬링(marshalling): 바인딩 오브젝트를 XML 문서로 변환 스프링에서는 자신을 참조하는 자기참조 빈을 만들 수 있음 디폴트 의존관계: 외부에서 DI 받지 않는 경우 기본적으로 자동 적용되는 의존관계 서비스 추상화 OXM(Object-XML Mapping): XML과..

Part 2. 분산 데이터 8장에서 설명했듯이 분산 시스템에서는 많은 것들이 잘못될 수 있다. 이런 결함을 다루는 가장 간단한 방법은 전체 서비스가 실패하도록 두고 사용자에게 오류 메시지를 보내는 것이다. 하지만 이 해결책을 받아들이기 힘들다면 결함을 견뎌낼(tolerating), 즉 내부 구성 요소 중 뭔가에 결함이 있더라도 서비스는 올바르게 동작하도록 할 방법을 찾아야 한다. 이번 장에서는 내결함성을 지닌 분산 시스템을 구축하는 데 쓰이는 알고리즘과 프로토콜의 몇 가지 예를 얘기한다. 내결함성을 지닌 시스템을 구축하는 가장 좋은 방법은 유용한 보장을 해주는 범용 추상화을 찾아 이를 구현하고 애플리케이션에서 이 보장에 의존하게 하는 것이다. 트랜잭션을 예로 들면, 트랜잭션을 사용함으로써 애플리케이션은 ..

토비의 스프링: Vol. 1: 스프링의 이해와 원리 스프링의 3대 기반기술 IoC/DI 서비스 추상화 AOP 단위 테스트 고립된 단위 테스트: 고립된 테스트를 하면 테스트가 다른 의존 대상에 영향을 받을 경우를 대비해 복잡하게 준비할 필요가 없을 뿐만 아니라, 테스트 수행 성능도 크게 향상된다 단위 테스트와 통합 테스트 단위 테스트: 목 오브젝트 등의 테스트 대역을 이용해 의존 오브젝트나 외부의 리소스를 사용하지 않도록 고립시켜서 수행하는 테스트 통합 테스트: 두 개 이상의, 성격이나 계층이 다른 오브젝트가 연동하도록 만들어 테스트하거나, 외부의 DB나 파일, 서비스 등의 리소스가 참여하는 테스트 테스트 작성 툴 목 프레임워크: Mockito와 같은 목 오브젝트 지원 프레임워크 등을 이용하여 목 오브젝트..

Part 2. 분산 데이터 지난 몇 개 장에서 되풀이됐던 주제는 시스템이 잘못된 것을 어떻게 처리하느냐였다(복제 서버 장애 복구, 복제 지연, 트랜잭션의 동시성 제어 등). 실제 환경의 시스템에서 나타날 수 있는 다양한 에지 케이스를 잘 이해할수록 이것들을 잘 처리할 수 있다. 이렇게 결함에 대한 이야기를 많이 했지만, 아직도 너무나 낙관적이다. 현실은 훨씬 더 비관적이다. 이제부터 잘못될 가능성이 있다는 것들은 모두 잘못된다고 가정한다. 분산 시스템은 단일 컴퓨터에서 실행하는 소프트웨어를 작성하는 일과는 근본적으로 다르다. 이번 장에서는 네트워크 관련 문제와 시계/타이밍 문제를 조사하고, 이것들을 어느 정도로 회피하여, 분산 시스템을 유지할 수 있도록 보장을 제공하는 알고리즘을 살펴본다. 결국 엔지니어..

토비의 스프링: Vol. 1: 스프링의 이해와 원리 객체지향 객체지향적인 코드는 다른 오브젝트의 데이터를 가져와서 작업하는 대신 데이터를 갖고 있는 다른 오브젝트에게 작업을 해달라고 요청함 오브젝트에게 데이터를 요구하지 말고 작업을 요청하는 것 → 객체지향 프로그래밍의 가장 기본이 되는 원리 서비스 추상화 서비스 추상화: 로우레벨의 기술과 API의 변화에 상관없이 일관된 API를 가진 추상화 계층을 도입하는 추상화 개념 트랜잭션 서비스 트랜잭션 롤백(transaction rollback): 트랜잭션 안에서 문제가 발생해서 트랜잭션 안에서 이미 진행한 SQL 작업들을 모두 취소(무효화)하는 작업 트랜잭션 커밋(transaction commit): 트랜잭션 안의 모든 SQL 작업이 성공적으로 수행된 경우 D..

Part 2. 분산 데이터 냉혹한 현실 세계에서 데이터 시스템은 여러 가지 문제가 생길 수 있다. 데이터베이스 소프트웨어나 하드웨어는 언제라도 실패할 수 있다. 애플리케이션은 언제라도 죽을 수 있다. 네트워크가 끊기면 애플리케이션 데이터베이스의 연결이 갑자기 끊기거나 데이터베이스 노드 사이의 통신이 안 될 수 있다. 여러 클라이언트가 동시가 동시에 데이터베이스에 쓰기를 실행해서 다른 클라이언트가 쓴 내용을 덮어쓸 수 있다. 클라이언트가 부분적으로만 갱신돼서 비정상적인 데이터를 읽을 수 있다. 클라이언트 사이의 경쟁 조건은 예측하지 못한 버그를 유발할 수 있다. 시스템이 신뢰성을 지니려면 이런 결함을 처리해서 전체 시스템의 치명적인 장애로 이어지는 것을 막아야 한다. 그러나 내결함성을 갖춘 시스템을 구현하..

토비의 스프링: Vol. 1: 스프링의 이해와 원리 예외를 처리할 때 반드시 지켜야 할 핵심 원칙: 모든 예외는 적절하게 복구되든지 아니면 작업을 중단시키고 운영자 또는 개발자에게 분명하게 통보되어야 함 예외의 종류와 특징 java.lang.Error (JVM 에러) java.lang.Exception (애플리케이션 에러) 예외처리 방법 예외 복구 예외상황을 파악하고 문제를 해결해서 정상 상태로 돌려놓는 방법 예외처리 코드를 강제하는 체크 예외들이 예외를 복구할 가능성이 있는 경우에 사용함 예외처리 회피 예외처리를 자신이 담당하지 않고 자신을 호출한 쪽으로 던지는 방법 → throws ... 예외 전환(exception translation) 발생한 예외를 그대로 넘기지 않고, 적절한 예외로 전환해서 던..