week 8 incheol - GANGNAM-JAVA/JAVA-STUDY GitHub Wiki

알고리즘

Baseball game

기술 문제

JAVA(최주빈)
- 자바 8 특징
  1. Lambda expressions
    - 람다 표현식은 Anonymous Function라고 할 수 있다
  2. Method Reference
    - 특정 람다 표현식을 축약한 것으로 볼 수 있다
  3. Stream
    - 간결하게 컬렉션의 데이터를 처리하는 기능
    - 위 Stream을 병렬로 처리가능하도록 하는 기능
    - 여러 쓰레드에서 처리할 수 있도록 분할한 Stream 이다
  4. Default Method
    - 인터페이스의 구현체를 인터페이스 자체에서 기본으로 제공 가능하다
  5. Optional
    - 값을 Optional로 캡슐화하여 NullPointerException을 막는다
  6. CompletaleFuture
    - Future의 기능을 확장시켜준다
    - 두 개의 비동기 계산 결과를 하나로 합친다
      - 각 계산 결과는 독립적이거나 종속적일 수 있다
    - Future 집합이 실행하는 모든 태스크의 완료를 기다린다
    - Future 집합에서 가장 빨리 완료되는 태스크를 기다렸다가 결과를 얻는다
    - Future가 완료되면 추가 작업을 수행 할 수 있다
  7. New date / time APIs
    - Joda-Time의 많은 기능을 java.time 패키지로 추가했다
      - LocalDate, LocalTime, Instant, Duration, Period …
- String, StringBuilder, StringBuffer 차이
  - String : immutable 데이터로써 추가 연산에 대해서 새로운 메모리 영역에 새롭게 할당 되므로 연산이 복잡할수록 가비지 데이터가 많이 발생한다.
  - StringBuilder : mutable 데이터이고 멀티 스레드 환경에서는 동기화 보장을 해주지 않는다. (단일 스레드 환경에서는 성능이 더 우수하다)
  - StringBuffer : mutable 데이터이고 추가 연산에 대해서 기존 메모리 영역의 데이터를 변경해준다. (멀티 스레드 환경에서는 동기화를 보장해준다)
SPRING(정인철)
- dispatcherServlet이란?
  
  Dispatcher Servlet이란 무엇인가
  
  Dispatcher Servlet이란 외부의 요청을 특정 컨트롤러로 매핑하기 위해 Front Controller 패턴을 적용한 Servlet이다.
  
  Q1. 그렇다면 Front Controller 패턴이란 무엇인가?
  
  Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤러인데, MVC 구조에서 함께 사용되는 패턴이다. 이전에는 서블릿을 컨트롤러 당 하나씩 두고 있어서 컨트롤러가 추가될 때마다 서블릿 설정도 추가해주어야 했다. 그러나 dispatcher servlet을 두면서 컨트롤러 추가시 별도의 servlet 설정을 할 필요가 없었다. 그리고 dispatcher servlet을 통해서 Tracking이나 Security를 적용할 때 편하게 구현이 가능하고, URL 구성이 간편해졌다.
  
  Dispatcher Servlet 동작 순서
  1. 클라이언트가 해당 어플리케이션에 접근하면 DispatcherServlet이 가로챈다.
    
    Q2. 어떻게 dispatcherServlet이 외부의 요청을 가로채는가?
    
    web.xml에 등록된 dispatcherServlet의 이 '/'와 같이 해당 어플을 통과하는 모든 URL로 등록했기 때문이다. 특정 URL만 적용하고 싶다면 의 내용을 변경해주면 된다.
    
    스프링은 web.xml 파일에 아래와 같이 dispatcher servlet적용 url pattern을 적용할 수 있다.
```
<servlet>
  <servlet-name>salesServlet</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  
  <init-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/salesServlet-servlet.xml</param-value>
  </init-param>
  <load-on-startup>1</load-on-startup>
</servlet>


<servlet-mapping>
  <servlet-name>salesServlet</servlet-name>
  <url-pattern>/sales</url-pattern>
</servlet-mapping>
```
    스프링 부트는 appliation.yml , application.properties파일에 server.servlet.context-path 옵션으로 지정할 수 있다.
  2. DispatcherServlet은 가로챈 정보를 HandlerMapping 에게 보내 해당 요청을 처리할 수 있는 Controller를 찾아낸다. HandlerMapping이 컨트롤러를 찾아내는 전략은 BeanNamUrlHandlerMapping과 DefaultAnnotationHandlerMapping이 기본 전략이다.
    
    Q3. HandlerMapping이 컨트롤러를 찾는 다른 전략은 무엇이 있는가?
    1. DefaultAnnotationHandlerMapping : @RequestMapping 이라는 애노테이션을 컨트롤러 클래스나 메소드에 직접 부여하고 이를 이용해 매핑하는 전략이다.
    2. BeanNameUrlHandlerMapping : 빈 정의 태그에서 name attribute에 선언된 URL과 class attribute에 정의된 Controller를 매핑하는 방식으로 동작한다.
    3. ControllerClassNameHandlerMapping : Controller의 클래스 이름중 suffix인 Controller를 제거한 나머지 이름의 소문자로 url mapping한다.
    4. SimpleUrlHandlerMapping : Ant-Style 패턴 매칭을 지원하며, 하나의 Controller에 여러 URL을 mapping 할 수 있다.
  3. 컨트롤러 작업 수행
  4. 컨트롤러는 요청을 응답받을 View의 이름을 리턴하게 된다. 그때 View 이름을 ViewResolver가 먼저 받아 해당하는 View가 존재하는지 검색한다.
  5. 컨트롤러에서 보내온 View 이름을 토대로 처리 View를 검색한다.
  6. 이 결과를 다시 DispatcherServlet 에게 보낸다.
  7. DispatcherServlet은 최종 결과를 클라이언트에 전송한다.
    
    Q4. filter와 interceptor, aop의 수행 시점을 dispatcherServlet를 기준으로 설명하시오
    - filter : dispatcherServlet 이전과 이후에 동작
    - interceptor : dispatcherServlet과 컨트롤러 사이에 동작
    - aop : interceptor와 컨트롤러 사이에 동작
- JPA Persistence란?
  
  영속성 컨텍스트란?
  - Server side와 Database 사이에 엔티티를 저장하는 논리적인 영역이라고 할 수 있다. 엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에 엔티티를 보관하고 관리한다.
  - 영속성 컨텍스트는 엔티티 매니저(Session)를 생성할 때 하나 만들어진다. 그리고 엔티티 매니저(Session)을 통해서 영속성 컨텍스트에 접근할 수 있고 영속성 컨텍스트를 관리할 수 있다.
  영속성 컨텍스트가 엔티티를 관리하면 얻게되는 장점
  - 1차 캐시
    - Map 객체로 저장 : 엔티티를 식별자 값(@Id 맵핑)으로 구분한다. Key-value로 관리하는데 이때 key 값이 @Id 값이 된다.
    - 식별자 값 필요 : 영속상태의 엔티티는 반드시 식별자 값이 있어야 한다.
    Q1. 1차 캐시를 사용하면 한 가지 기능을 두개의 트랜잭션으로 처리할 경우?
    - OSIV를 사용하여 영속성 컨텍스트의 데이터를 공유한다.
    Q2. 2차 캐시는 언제 사용하나?
    - 하이버네이트가 지원하는 캐시는 크게 3가지가 있다.
      - 엔티티 캐시 : 엔티티 단위로 캐시한다. 식별자로 엔티티를 조회하거나 컬렉션이 아닌 연관된 엔티티를 로딩할 때 사용한다.
      - 컬렉션 캐시 : 엔티티와 연관된 컬렉션을 캐시한다. 컬렉션이 엔티티를 담고 있으면 식별자 값만 캐시한다. (하이버네이트 기능)
        
        문제는 쿼리 캐시나 컬렉션 캐시만 사용하고 대상 엔티티에 엔티티 캐시를 적용하지 않으면 성능상 심각한 문제가 발생할 수 있다.
        
        “select m from Member m” 쿼리를 실행했는데 쿼리 캐시가 적용되어 있다. 결과 집합은 100건이다.
        
        결과 집합에는 식별자만 있으므로 한 건씩 엔티티 캐시 영역에서 조회한다.
        
        Member 엔티티는 엔티티 캐시를 사용하지 않으므로 한 건씩 데이터베이스에서 조회한다.
        
        결국 100건의 SQL이 실행된다.
      - 쿼리 캐시 : 쿼리와 파라미터 정보를 키로 사용해서 캐시한다. 결과가 엔티티면 식별자 값만 캐시한다. (하이버네이트 기능)
  - 동일성 보장
    - 동일한 객체 반환 : Collection에서 객체를 빼오듯이 같은 객체를 반환하게 되면 새로운 객체가 나오는 것이 아니라 동일한 객체가 반환된다.
    Q3. JPQL을 사용하게 되면 기존 영속성 컨텍스트의 데이터는 갱신되나?
  - 변경 감지
    - 자동 Update : 영속성 상태의 객체는 객체의 데이터가 변경이 되면, 자동 update 된다.
    - EntityManager에서 flush가 되고, commit이 됩니다.
    - - flush가 되는 시점
        
        강제 Flush : EntityManager.flush()
        
        트랜잭션 종료시 : 영속성 컨텍스트는 트랜잭션 범위로 만들어지기 때문이다.
        
        JPQL 쿼리 실행 : JPQL은 실제 Database side에서 데이터를 가져오기 때문에 동기화를 위해 JPQL 쿼리가 실행 전에 flush 된다.
  - 트랜잭션으로 인한 쓰기 지연
    - 쓰기 지연 : 영속성 컨텍스트는 트랜잭션 범위 안에서 동작한다. 그래서 트랜잭션이 끝나야 Commit이 이루어지고 반영된다.
  - Lazy 로딩
    - 엔티티와 관계가 맺어진 엔티티의 데이터를 가져올 수 있다.
    - 성능저하의 원인이 될 수도 있다.
- JPA Persistence란?
Infra/운영(이경희)
- jwt란 무엇이며, 구성은 어떻게 되어 있고, oauth와 차이는?
  
  JWT는 서버와 클라이언트 간 정보를 주고 받을 때 HTTP Request Header에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정없이 헤더에 포함되어 있는 JWT 정보를 통해 인증한다.
  
  JWT를 왜 사용할까?
  1. 보안 이슈: 사용자가 자신의 비밀 값으로 서버에 로그인 하게 되면, 서버는 JWT를 리턴합니다. token을 인증 값으로 사용하게 되면 기존 쿠키/세션을 사용하는 방식보다 많은 보안 이슈를 막을 수 있습니다. 서버는 GUI로부터 받은 JWT가 유효할 경우, resouce를 사용하도록 허용합니다. 또한 JWT는 쿠키를 사용하지 않기 때문에, Cross-Origin Resource Sharing (CORS) 이슈가 발생하지 않습니다.
  2. 데이터 용량: JWT는 기존의 XML보다 덜 복잡하고 인코딩 된 사이즈가 작습니다. 따라서 HTTP와 HTML 환경에서 사용하기 좋습니다.
  3. 사용성: JSON parser는 대부분의 프로그래밍이 지원하기 때문에 XML을 사용하는 SAML 보다 만들기 쉽습니다.
  토큰 기반의 인증 시스템을 처음 접한 사람이라면 저 두 가지 개념이 헷갈릴 수 있습니다. 먼저, 정답부터 말하자면 JWT는 토큰 유형이고 OAuth는 토큰을 발급하고 인증하는 방법을 설명하는 일종의 프레임워크입니다. 기존의 /outh/token endpoint에 의해 발급되는 모든 토큰은 일종의 OAuth 프레임워크에 의해 관리된다고 볼 수 있습니다.
  
  OAuth는 Open Authorization, Open Authentication 뜻하는 것으로 애플리케이션(페이스북,구글,트위터)(Service Provider)의 유저의 비밀번호를 Third party앱에 제공 없이 인증,인가를 할 수 있는 오픈 스탠다드 프로토콜이다.
  
  OAuth 인증을 통해 애플리케이션 API를 유저대신에 접근할 수 있는 권한을 얻을 수 있다. OAuth가 사용되기 전에는 외부 사이트와 인증기반의 데이터를 연동할 때 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조였다. 유저의 비밀번호가 노출될 가망성이 크기 때문이다
  
  출처:
  
  https://tristan91.tistory.com/499
  
  [개발모음집]
  
  JWT 구조
  
  JWT 는 . 을 구분자로 3가지의 문자열로 되어있습니다. 구조는 다음과 같이 이루어져있습니다:
  
  1. Header typ: 토큰의 타입을 지정합니다. 바로 JWT 이죠.
  
  alg: 해싱 알고리즘을 지정합니다. 해싱 알고리즘으로는 보통 HMAC SHA256 혹은 RSA 가 사용되며, 이 알고리즘은, 토큰을 검증 할 때 사용되는 signature 부분에서 사용됩니다.
  
  2. Payload
  
  토큰에 담을 정보가 들어있습니다. 여기에 담는 정보의 한 ‘조각’ 을 클레임(claim) 이라고 부르고, 이는 name / value 의 한 쌍으로 이뤄져있습니다. 토큰에는 여러개의 클레임 들을 넣을 수 있습니다.
  
  클레임 의 종류는 다음과 같이 크게 세 분류로 나뉘어져있습니다:
  
  등록된 (registered) 클레임,공개 (public) 클레임,비공개 (private) 클레임
  1. 서명(signature)이 서명은 헤더의 인코딩값과, 정보의 인코딩값을 합친후 주어진 비밀키로 해쉬를 하여 생성합니다.
- 온프로미스 환경과 클라우드 환경의 차이 및 장단점
  
  프레미스(On-premise)란 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식을 말한다.
  
  클라우드 필요성 대두
  
  IT 인프라가 점차 복잡해지면서 기업이 관리해야 하는 네트워크 트래픽은 크게 급증하고 있다.이처럼 환경이 복잡하고 지능화되면서 IT인프라 관리는 점차 어려워지고, 비용은 지속적으로 늘어나는 비효율적인 환경이 되고 있다. 보안이 중요한 시점에서 IT 인프라가 점차 복잡해지면서 네트워크 트래픽에 대한 모니터링과 이를 분석할 관리 솔루션에 대한 지속적인 투자가 필요해지는 상황이다. 기존의 온프레미스(On-premise) 기업들로서는 이러한 복잡성과 비용의 증가는 반갑지만은 않을 것이다.
  
  클라우드의 장점
  
  온프레미스(On-premise) 기업들은 IT 인프라의 확충과 컴퓨팅 파워및 저장능력 향상에 대한 부담감과 고도화되고 지능화되는 핵커들로부터 기업 자산을 보호하기 위해서 끊임없이 네트워크를 모니터링해야 하고 이를 분석할 고성능의 관리 솔루션을 구입해야 한다. 이는 결코 기업에게 즐거운 일은 아니다.클라우드는 기업의 이런 부담감을 줄일수 있는 대안으로 떠 오른지 오래이다. 장점들을 간략하게 나열 해 보자면
  
  ▶ 갑작스러운 환경 변화에 신속하고 탄력적으로 대응할 수 있다.▶ IT 인프라 운영에 대한 부담에서 벗어나 기업의 핵심 업무에 역량을 집중할 수 있다.▶ 클라우드는 IT 투자비용(CAPEX)을 절감한다.
  
  실제로 온프레미스(On-premise) 환경을 클라우드(Cloud) 환경으로 바꾼 기업들이 늘어나면서 성공사례들도 점차 늘어나고 있는 추세이다.