어떤 정보를 키-값의 쌍으로 저장하고자 한다.어떤 컬렉션을 사용하여야 하는가

서버 면접

Jun 18, 2020 조회수 259

보안

• 대칭키 비 대칭키
• 패스워드 암호화 방법
  • 단방향해시 함수
    • 인식가능성 문제
    • 충돌
• SQl Injecton
  • SQL 삽입공격은 웹에플리케이션에 대해서 가해지는 가장 흔한 공격 기법 중의 하나로 에플리케이션의 허점을 이용해서 데이터베이스를 비정상적으로 조작하는 기법
• CSRF
  • 일단 사용자가 웹사이트에 로그인한 상태에서 사이트 간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다.
• XSS
  • 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점이다

Network

• OSI 7 계층

  • 물리계층
  • 데이터링크계층
  • 네트워크 계층
  • 전송계층
  • 세션계층
  • 표현 계층
  • 응용 계층

• TCP/UDP 차이

  • TCP : 연결형 서비스 , 3way, 4way 핸드 세이킹, UDP보다 느림, 신뢰성 보장
  • UDP : 비연결형 서비스, TCP보다 빠름, 최소한의 오류 검출, 실식나 서비스같이 연속성이 중요한 경우 사용

• TCP 3way 핸드세이킹(연결과정)

  • A->B SYN : 접속요청, 랜덤한 시퀀스 번호 지정
  • B->A SYN + ACK : ACK 필드를 시퀀스 +1 지정하고, A에게 포트 개방 요청
  • A -> B: ACK : 요청 수락,

• TCP 4way 핸드쉐이킹(연결해제요청)

  • A->B FIN: 연결 해제 xhdqh :
  • B->A ACK : 일단 확인 메세지 전송, 자신의 통신이 끝날때까지 대기
  • B->A FIN : 통신 종료 후, A에게 연결 종료 합의 메세지 전송
  • A->B ACK : 프로세스 A가 확인했다는 메시지 전송

• TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유

  • Client가 데이터 전송을 마쳤다고 하더라도 Server는 아직 보낼 데이터가 남아있을 수 있기 때문에 일단 FIN에 대한 ACK만 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메시지를 보내기 때문이다.

• 만약 Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까?

  • 이러한 현상에 대비하여 Client는 Server로부터 FIN 플래그를 수신하더라도 일정시간(Default: 240sec)동안 세션을 남겨 놓고 잉여 패킷을 기다리는 과정을 거친다. (TIME_WAIT 과정)

• 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유

  • Connection을 맺을 때 사용하는 포트(Port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순처적인 Number가 전송된다면 이전의 Connection으로부터 오는 패킷으로 인식할 수 있다. 이런 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정한다.

• HTTP

  • 80 포트
  • 비연결형, 무상태성

• HTTPS

  • 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전의 프로토콜
  • 따라서 데이터의 적절한 보호를 보장한다
  • 사용자의 데이터를 공개키로 암호화 (공개키를 얻은 인증된 사용자)
  • 서버의 개인키를 통해 복호화하여 요청 처리

• HTTP 요청 응답 헤더

  • 일반헤더

    • Date
    • Connection
    • Content-Type
    • Content-Language
    • Content-Encoding : 해당 개체 데이터의 압축 방식
    • Last-Modified

  • 요청헤더

    • Host: 요청하는 호스트에 대한 호스트명 및 포트번호 (필수)
    • User-Agent : 클라이언트 소프트웨어(브라우저, OS) 명칭 및 버전 정보
    • Cookie :서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
    • Referer :바로 직전에 머물었던 웹 링크 주소
    • Origin : 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타냄
    • Accept: 클라이언트 자신이 원하는 미디어 타입 및 우선순위를 알림
    • Accept-Charset:

  • 응답헤더

    • Server: 서버 소프트웨어 정보
    • Set-Cookie: 서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정)

• CORS

  • 웹 서버에게 보안 cross-domain 데이터 전송을 활성화하는 cross-domain 접근 제어권을 부여한다.
  • 예를 들면, XMLHttpRequest는 same-origin 정책을 따르기에 XMLHttpRequest을 사용하는 웹 애플리케이션은 자신과 동일한 도메인으로 HTTP 요청을 보내는 것만 가능했다.
  • 웹 애플리케이션을 개선시키기 위해, 개발자들은 브라우저 벤더사들에게 XMLHttpRequest가 cross-domain 요청을 할 수 있도록 요청했고 이에 따라 CORS가 생겼다.
  • CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어본다.
  • 이때 Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고,
  • Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알린다.
  • Allow 항목들은 Request에 대응되는 것으로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용된다.
  • Request랑 Allow가 일치하면 CORS 요청이 이루어진다.

• GET, POST

  • GET
    • URL에 요청 정보를 붙여서 전송한다.
    • URL에 요청 정보가 이어붙기 때문에 길이 제한이 있어서 대용량의 데이터를 전송하기 어렵다
    • 요청 정보를 사용자가 쉽게 눈으로 확인할 수 있다.
    • HTTP 패킷의 Body는 비어 있는 상태로 전송한다.
    • POST 방식보다 빠르다
  • POST
    • 요청 정보를 HTTP 패킷의 Body 안에 숨겨서 서버로 전송한다.
    • Request Header의 Content-Type에 해당 데이터 타입이 표현되며, 전송하고자 하는 데이터 타입을 적어주어야 한다
    • Body 안에 숨겨서 요청 정보를 전송하기 때문에 대용량의 데이터를 전송하기에 적합하다.
    • 클라이언트 쪽에서 데이터를 인코딩하여 서버로 전송하고, 이를 받은 서버 쪽이 해당 데이터를 디코딩한다.
    • GET 방식보다 보안상 안전하다.
  • 조회하기 위한 용도 POST가 아닌 GET 방식을 사용하는 이유
    • 설계 원칙에 따라 GET 방식은 서버에게 여러 번 요청을 하더라도 동일한 응답이 돌아와야 한다
    • GET 방식은 가져오는 것(Select) 으로, 서버의 데이터나 상태를 변경시키지 않아야 한다.
    • POST 방식은 수행하는 것 으로, 서버의 값이나 상태를 바꾸기 위한 용도이다
    • 웹에서 모든 리소스는 Link할 수 있는 URL을 가지고 있어야 한다
    • 즉, 어떤 웹페이지를 조회할 때 원하는 페이지로 바로 이동하거나 이동시키기 위해서는 해당 링크의 정보가 필요하다.
    • 링크를 통해 특정 페이지로 바로 이동하려면 해당 링크와 관련된 정보가 필요한데 POST는 요청 데이터가 Body에 담겨 있기 때문에 링크 정보를 가져올 수 없습니다

• 쿠키와 세션

  • 쿠키
    • HTTP 프로토콜은 위와 같은 특징으로 모든 요청 간 의존관계가 없다.
    • 클라이언트 로컬에 저장되는 키와 값이 들어있는 파일이다.
    • 쿠키의 이름(name)
    • 쿠키의 값(value)
    • 쿠키의 만료시간(Expires)
    • 쿠키를 전송할 도메인 이름(Domain)
    • 쿠키를 전송할 경로(Path)
    • 보안 연결 여부(Secure)
    • HttpOnly 여부(HttpOnly
    • 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있다.
  • 세션
    • 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태로 보고 그 상태를 유지하는 기술이다.
    • 서버가 해당 웹브라우저(클라이언트)에 유일한 ID(Session ID)를 부여함
    • 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 Session ID를 포함해서 전송
    • 쿠키에 Session ID를 JSESSIONID 라는 이름으로 저장
    • 서버는 세션 ID를 확인하고, 해당 세션에 관련된 정보를 확인한 후 응답
    • 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다.

REST와 RESTful의 개념

• REST란

  • REST의 정의
    • "Representational State Transfer(대표적인 상태 전달)"의 약자
    • 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
      • REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
      • REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.
  • REST의 구체적인 개념
    • HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
      • 즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
      • 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
  • REST 장단점
    • 장점
      • 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해준다.
      • Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
      • HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
    • 단점
      • 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
      • 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.
        • PUT, DELETE를 사용하지 못하는 점
        • pushState를 지원하지 않는 점
  • REST가 필요한 이유
    • '애플리케이션 분리 및 통합'
    • '다양한 클라이언트의 등장'
    • 즉, 최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
  • REST 구성 요소
    1. 자원(Resource): URI
       • 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
       • 자원을 구별하는 ID는 '/groups/:group_id'와 같은 HTTP URI 다.
       • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
    2. 행위(Verb): HTTP Method
       • HTTP 프로토콜의 Method를 사용한다.
       • HTTP 프로토콜은 GET, POST, PUT, DELETE, HEAD 와 같은 메서드를 제공한다.
    3. 표현(Representation of Resource)
       • Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
       • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
       • JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
  • REST 특징
    1. Server-Client(서버-클라이언트 구조)
    2. Stateless(무상태)
    3. Cacheable(캐시 처리 가능)
    4. Layered System(계층화)
    5. Code-On-Demand(optional)
    6. Uniform Interface(인터페이스 일관성)

• REST API

  • REST API의 정의
    • REST 기반으로 서비스 API를 구현한 것
    • 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
  • REST API의 특징
    • 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
    • REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
    • 즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.
  • REST API 설계 기본 규칙
    1. URI는 정보의 자원을 표현해야 한다.
       • resource는 동사보다는 명사를 사용한다.
       • resource는 영어 소문자 복수형을 사용하여 표현한다.
       • Ex) GET /Member/1 -> GET /members/1
    2. 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.
       • URI에 HTTP Method가 들어가면 안된다.
       • Ex) GET /members/delete/1 -> DELETE /members/1
       • URI에 행위에 대한 동사 표현이 들어가면 안된다.
       • Ex) GET /members/show/1 -> GET /members/1
       • Ex) GET /members/insert/2 -> POST /members/2
  • REST API 설계 규칙
    1. 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다.
       • Ex) //restapi.example.com/houses/apartments
    2. URI 마지막 문자로 슬래시(/ )를 포함하지 않는다.
       • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다.
       • REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
       • Ex) //restapi.example.com/houses/apartments/ (X)
    3. 하이픈(- )은 URI 가독성을 높이는데 사용
       • 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.
    4. 밑줄(_ )은 URI에 사용하지 않는다.
       • 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.
    5. URI 경로에는 소문자가 적합하다.
       • URI 경로에 대문자 사용은 피하도록 한다.
       • RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문
    6. 파일확장자는 URI에 포함하지 않는다.
       • REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
       • Accept header를 사용한다.
       • Ex) //restapi.example.com/members/soccer/345/photo.jpg (X)
       • Ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)
    7. 리소스 간에는 연관 관계가 있는 경우
       • /리소스명/리소스 ID/관계가 있는 다른 리소스명
       • Ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)
    8. :id는 하나의 특정 resource를 나타내는 고유값
       • Ex) student를 생성하는 route: POST /students
       • Ex) id=12인 student를 삭제하는 route: DELETE /students/12

• RESTful

  • RESTful의 개념
    • RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
      • 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
    • RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
  • RESTful의 목적
    • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
    • RESTful API를 구현하는 근본적인 목적이 퍼포먼스 향상에 있는게 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는게 주 동기이니, 퍼포먼스가 중요한 상황에서는 굳이 RESTful API를 구현하실 필요는 없습니다.
  • RESTful 하지 못한 경우
    • Ex1) CRUD 기능을 모두 POST로만 처리하는 API
    • Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)

• WebSocket

  • 개념
    • 웹 페이지의 한계에서 벗어나 실시간으로 상호작용하는 웹 서비스를 만드는 표준 기술
  • 배경
    • HTTP 프로토콜은 클라이언트에서 서버로의 단방향 통신을 위해 만들어진 방법이다.
    • 실시간 웹을 구현하기 위해서는 양방향 통신이 가능해야 하는데, WebSocket 이전에는 Polling, Streaming 방식의 AJAX 코드를 이용하여 이를 구현하였다.
    • 하지만 이 방법들을 이용하면 각 브라우저마다 구현 방법이 달라 개발이 어렵다는 문제점이 있었다.
    • 이를 위해 HTML5 표준의 일부로 WebSocket이 만들어지게 되었다.
  • 일반 TCP Socket과의 차이점
    • 일반 HTTP Request를 통해 handshaking 과정을 거쳐 최초 접속이 이루어진다.
  • 특징
    • 소켓을 이용하여 자유롭게 데이터를 주고 받을 수 있다.
    • 기존의 요청-응답 관계 방식보다 더 쉽게 데이터를 교환할 수 있다.
    • 다른 HTTP Request와 마찬가지로 80포트를 통해 웹 서버에 연결한다.
    • // 대신 ws:// 로 시작하며 Streaming과 유사한 방식으로 푸쉬를 지원한다.
    • 클라이언트인 브라우저와 마찬가지로 웹 서버도 WebSocket 기능을 지원해야 한다. (WebSocket을 지원하는 여러 서버 구현체(Jetty, GlassFish, Node.js, Netty, Grizzly 등)가 있다.)
    • 클라이언트인 브라우저 중에서는 Chrome, Safari, Firefox, Opera에서 WebSocket을 사용할 수 있으며, 각종 모바일 브라우저에서도 WebSocket을 사용할 수 있다.
    • WebSocket 프로토콜은 아직 확정된 상태가 아니기 때문에 브라우저별로 지원하는 WebSocket 버전이 다르다. (예전 브라우저는 지원하지 않는다.)
    • 즉, WebSocket은 다가올 미래의 기술이지 아직 인터넷 기업에서 시범적으로라도 써 볼 수 있는 기술이 아니다.
  • 장점
    • HTTP Request를 그대로 사용하기 때문에 기존의 80, 443포트로 접속을 하므로 추가로 방화벽을 열지 않고도 양방향 통신이 가능하다.
    • HTTP 규격인 CORS 적용이나 인증 등의 과정을 기존과 동일하게 사용할 수 있다.

• Socket.io

  • 개념
    • 다양한 방식의 실시간 웹 기술을 손쉽게 사용할 수 있는 모듈 (웹 클라이언트로의 푸쉬를 지원하는 모듈)
    • WebSocket, FlashSocket, AJAX Long Polling, AJAX Multi part Streaming, IFrame, JSONP Polling 등 다양한 방법을 하나의 API로 추상화한 것이다.
    • 즉, Socket.io는 JavaScript를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 한 기술이다.
  • 특징
    • Socket.io는 현재 바로 사용할 수 있는 기술이다.
    • WebSocket 프로토콜은 IETF에서 관장하는 표준 프로토콜이라서 WebSocket을 지원하는 여러 서버 구현체(Jetty, GlassFish, Node.js, Netty, Grizzly 등)가 있지만 Socket.io는 Node.js 하나 밖에 없다.
  • 장점
    • 개발자는 Socket.io로 개발을 하고 클라이언트로 푸쉬 메시지를 보내기만 하면, WebSocket을 지원하지 않는 브라우저의 경우는 브라우저 모델과 버전에 따라서 AJAX Long Polling, MultiPart Streaming, Iframe을 이용한 푸쉬, JSONP Polling, Flash Socket 등 다양한 방법으로 내부적으로 푸쉬 메시지를 보내준다.
    • 즉, WebSocket을 지원하지 않는 어느 브라우져라도 푸쉬 메시지를 일관된 모듈로 보낼 수 있다.

• status code
  <img src="//static.podo-dev.com/blogs/images/2020/07/05/origin/0b4aeee4-81d0-44cc-bd1c-3181b90d80a6.png" alt="base64.png" style="width:720px;">

OS

• 프로세스 스레드 차이
• 멀티 프로세스 대신 멀티 스레드를 사용하는 이유
• 쓰레드 세이프
• 지역성원리
• 교착상태 개념 조건
  • 상호 배제
  • 점유대기
  • 비선점
  • 순환대기
• 외부단편화 내부 단편화
• 컨텍스트 스위칭
  • Task의 대부분 정보는 Register에 저장되고 PCB(Process Control Block)로 관리된다.
  • 현재 실행하고 있는 Task의 PCB 정보를 저장한다. (Process Stack, Ready Queue)
  • 다음 실행할 Task의 PCB 정보를 읽어 Register에 적재하고 CPU가 이전에 진행했던 과정을 연속적으로 수행할 수 있다.
• 스와핑

spring-batch

• //jojoldu.tistory.com/324?category=902551

레디스

• //meetup.toast.com/posts/226

• 왜 레디스를 캐시로 씀?

  • memcahce 와 고민- 멀티쓰레드라 빠르지만 동시성 이슈있음.
  • 레디스가 제공하는 다양한 데이터 형식과, 싱글쓰레드 기반에 동시성 이슈 해결이 추후를 위해 더 좋을거라 생각헀음.
  • 레퍼런스 차원에서돠 관리하기가 더편함

• 레디스 죽으면 어떻게 할꺼?

  • 기존에 센티넬 구조로 클러스터링 되있어서,
  • 마스터가 죽으면 슬레이브가 승격되도록 함.
  • 보팅을 위해 3개 레디스 클러스터링 구성

카프카

• //12bme.tistory.com/529?category=737765
• rabbitMQ, 카프카 선택한 이유?
  • rabbitMQ : 라우팅이되지 가능, 구성쉬움, 관리자페이지 제공, 카프카 비해 느림
  • 카프카 : 라우팅 되지 않음, publsiher가 topic에 삽입함, 고성능,

아키텍처

• 싱크, 어싱크 / 불록 논불록 차이

• Http header 설명

• 멀티쓰레드시 문제점

  • 동시성 이슈, 공유자원 락 처리

• 대용량 트래픽 처리 관련 이슈

  • //post.naver.com/viewer/postView.nhn?volumeNo=27046347&memberNo=2521903
  • //d2.naver.com/helloworld/6070967

Java

• Optional 사용 유무

  • Optional은 null 또는 실제 값을 value로 갖는 wrapper로 감싸서 NPE(NullPointerException)로부터 자유로워지기 위해 나온 Wrapper 클래스이다. 따라서 Optional을 반환하는 메소드는 절대 null을 갖는 value를 반환해서는 안된다. 또한 Optional은 값을 Wrapping하고 다시 풀고, null일 경우에는 대체하는 함수를 호출하는 등의 오버헤드가 있으므로 성능이 저하될 수 있다. 그렇기 때문에 메소드의 반환 값이 절대 null이 아니라면 Optional을 사용하지 않는 것이 성능저하가 적다. 즉, Optional은 메소드의 결과가 null이 될 수 있으며, 클라이언트가 이 상황을 처리해야 할 때 사용하는 것이 좋다.

• OrElse 와 orElseget 차이

  • orElse는 값이 null이면, 해당 값을 반환, null이든 아닌든 항상 호출
  • orElseGet은 값이 null이면, 해당 함수를 호출하여, 함수 반환값을 반환.

• default 메서드 설명

  • 구현체가 오버라이딩 가능
  • 하위호환성 때문에 생성, 인터페이스가 널리 퍼졌는데 새로운 인터페이스 메소드를 제공하면 문제가 생김

• jvm 역할

  • JVM은 자바프로그램을 실행시키는 주체입니다.
  • 자바컴파일러는 .java파일을 .class파일인 자바바이트코드로 컴파일합니다.
  • OS는 이를 이해 할 수 없기에, JVM은 OS가 이를 이해할 수 있도록 도와주며, 따라서 OS에 상관없이 자바프로그램이 구동이 가능합니다. 또한 JVM은 메모리관리, 가비지컬렉션을 수행합니다.

• jvm 구조

  • ClassLoader는 자바바이트코드파일인 .class파일을 엮어써, JVM이 운영체제로부터 할당받은 Runtaime Data Area에 적재하는 역할을 합니다.
  • Excution Engine은 ClassLoder에 의해 적재된 바이트코드들을 기계어로 변경해 명령어 단위로 실행하는 역할을 합니다.
  • Runtime Data Area는 JVM의 메모리 영역으로 자바어플리케이션을 실행할 때 사용되는 데이터들이 적재된 영익입니다.
  • GC는 가비지 컬렉터로 참조되지 않는 가비지를 메모리 해제 하는 역할을 합니다.

• 자바 1.8 써봤니?

  • 스트림, 람다

• GC

• Checked exception / unchecked exception

  • //blog.benelog.net/1901121
  • Checked Excpetion 반드시 명시적 처리, 롤백 안됨, 기본적으로 복구가 가능하니 롤백하지 않음.
  • UncheckedExcetpion 런타임 예외, 반드시 처리 할 필요 없음

• 스트림에서 메서드 참조랑 람다 중 뭘 선호?

• Stream 에서 자주 사용한 옵션

  • filter, map, collector, reduce

• String, StringBuilder, StringBuffer 차이

  • String
  • String 클래스는 Immutable 객체이기 때문에 + 등 concat 연산 시 원본을 변경하지 않고 새로운 String 인스턴스를 생성해야 하는 단점이 존재한다. 하지만 JDK 1.5 이후부터는 컴파일 타임에 StringBuilder로 변경한다고 한다.
  • StringBuilder
  • String에서 + 등으로 문자열 등을 concat하는 연산이 많은 경우 사용하는것이 좋다. 기존 String 문자들을 concat하는 경우 매번 새로운 String 인스턴스를 사용하기 때문에 성능상의 이슈 존재(JDK 1.5버전 부터는 내부적으로 StringBuilder를 이용하도록 변경되긴 했다.)
  • StringBuffer
  • StringBuffer는 Builder와 비교해서 thread-safe하다. (멀티 스레드 환경에서 동기화의 지원 여부가 다름.) 내부적으로 append 등 모든 메소드에 대해 synchronized 키워드가 붙어있다.

• Comparable, Comparator 차이

  • 정렬을 위해서 사용하는 인터페이스들인데 Comparable 인터페이스는 정렬 기준을 설정할 클래스가 직접 상속해 compareTo 메소드를 오버라이딩 해야 하며, Comparator는 직접 구현해서 Arrays.sort 같은 정렬 메소드에 인자로 넘겨 정렬 기준을 직접 설정해 줄 수 있다.

• Collection
  <img src="//static.podo-dev.com/blogs/images/2020/07/05/origin/b7c6553c-3398-4177-a301-6670933d5c0f.png" alt="base64.png" style="width:628px;">

• HashMap, TreeMap, LinkedHashMap

  • HashMap은 내부 hashing된 값에 따라 키 순서가 정해지므로 key는 특정 순서 없이 나온다.
  • TreeMap은 내부적으로 RedBlack Tree로 저장됨, 키값에 대한 Compartor 구현으로 정렬 순서를 바꿀수 있다. 정렬된 순서로 key 값이 나온다.
  • LinkedHashMap은 내부적으로 LinkedList, 입력 순서대로 key 값이 나온다.

• Java의 접근 제어자

  • public 접근 제한이 없다.
  • protected : 클래스가 정의되어 있는 해당 패키지 내 그리고 해당 클래스를 상속받은 외부 패키지의 클래스에서 접근이 가능
  • default : 아무런 접근 제한자를 명시하지 않으면 default 값이 되며, 동일한 패키지 내에서만 접근이 가능
  • private : 자기 자신, 클래스 내부에서만 접근이 가능

• HashMap과 HashTable을 정의한다면

  • 키에 대한 해시 값을 사용하여 값을 저장하고 조회하며, 키-값 쌍의 개수에 따라 동적으로 크기가 증가하는 associate array라고 할 수 있다. 이 associate array를 지칭하는 다른 용어가 있는데, 대표적으로 Map, Dictionary, Symbol Table 등이다.

• 해시함수를 통해 얻은 해시코드 값이 두 개 이상 같은 경우 해시의 충돌이 발생한다.

  • 충돌은 아무리 해시 함수를 잘 구현하더라도 필연적으로 발생할 수 밖에 없다.
  • 이렇듯 발생하는 충돌에 대해서 해시 충돌이 발생하더라도 키-값 쌍 데이터를 잘 저장하고 조회할 수 있게 하는 방식에는 대표적으로 두가지가 존재하는데 하나는 Open Addressing이고, 다른 하나는 Separate Chaining이다.
  • Open Addressing은 데이터를 삽입하려는 해시 버킷이 이미 사용 중인 경우 다른 해시 버킷에 해당 데이터를 삽입하는 방식이다. 데이터를 저장/조회할 해시 버킷을 찾을 때에는 Linear Probing, Quadratic Probing 등의 방법을 사용한다.
  • Separate Chaining에서 각 배열의 인자는 인덱스가 같은 해시 버킷을 연결한 링크드 리스트의 첫 부분(head)이다.
  • Java HashMap에서 사용하는 방식은 Separate Channing이다. Open Addressing은 데이터를 삭제할 때 처리가 효율적이기 어려운데, HashMap에서 remove() 메서드는 매우 빈번하게 호출될 수 있기 때문이다. 둘 모두 Worst Case O(M) 이며 자세한 설명한 생략한다.

인프라

• Ci cd 뭐임?

  • 말그대로 개발을 하면서 ‘코드에대한 통합’을 ‘지속적’으로 진행함으로써 품질을 유지하자는 것이다
  • 층을 하나씩 쌓을때마다 올바르게 지어지고있는지 체크해주는것이 질적, 비용적 측면에서 모두 유리할 것이다.
  • CD란 지속적 배포(Continuous Deploy 또는 Delivery)로써,
  • 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하자는 개념이다.
  • 사실 어려울 것 없이 그냥 CI의 연장선으로 생각하면 된다.

• Jdbc preparedstatement 설명

• 대용양 트래픽이 갑자기 발생했다. 어떻게 대응할꺼냐?

  • 로드 밸런싱 분산처리
  • 데이터 캐싱

• 지금 회사의 설계에 그 부분이 반영되어 있는가?

• 무중단 서비스

  • 블루 그린 전략
  • 롤링 업데이트, 구버전가 신버전이 공존할 수 있음.

Spring

• 스프링 버전 몇?

• @Autowired, Constructor

• spring 트랜잭션 원리

  • 프록시로 동작

• spring aop

  • AOP는 관점지향 프로그래밍의 약자입니다.
  • 객체지향의 응집도 관련있으며, 공통기능과 핵심기능을 분리하고
  • 공통기능이 필요한 핵심기능에서 사용할 수 있도록 하는 프로그래밍입니다.
  • AOP는 Proxy 기반으로 동작합니다.
  • 메소드 요청을 Proxy가 가로채 핵심기능 전/후로 공통기능을 수행합니다.
  • 공통기능을 분리함으로써, 코드의 중복되는 부분을 제거하고, 재활용성을 극대화 할 수 있습니다.
  • 또한 관련된 책임을 가지는 기능만 묶음으로써 응집도가 높아집니다.
  • 주의해야 할 점: Spring AOP에서 @AspectJ 애노테이션을 사용하는 것은 AspectJ를 통한 compile time weaving을 수행하는 것이 아니다. JDK Dynamic Proxy / CGLib 기반 Runtime weaving 하에서 AspectJ의 문법만을 갖다 쓰는 것 에 불과하다.

• Spring 요청 처리과정에 대해서 설명해보세요.

  • 우선 사용자의 요청을 디스패처서블릿이 받습니다.
  • 요청을 받은 디스패처서블릿은 Handler Mapping에 URL과 매핑되는 컨트롤러 메소드를 물어보고 결정합니다.
  • 컨트롤러는 사용자의 요청을 받아 로직을 수행합니다, 이 과정에서 Model에 결과값을 주입하고, View이름을 리턴해줍니다.
  • View Resolver는 View 이름을 받아 물리적 View파일을 검색합니다.
  • 결정되는 View는 Model정보와 함께 화면을 표시 후, 최종적으로 디스패쳐서블릿은 요청에 응답합니다.

• servlet

  • 서블릿은 자바를 이용한 서버 프로그래밍으로써, 웹에서 자바프로그래밍을 사용하기 위해 탄생하였습니다. 사용자의 리퀘스트 요청이 오면, HttpServletRequest, HttpServletResponse 객체를 생성합니다.web.xml에서 요청에 매핑되는 서블릿을 찾고, 서블릿이 메모리에 적재되어있는지 확인하고 적재되어있지 않다면 init() 메소들 호출한후 메모리에 적재합니다.service()메소들를 호출하여, get, post에 따라 doGet(), doPost() 메소드를 수행 후 동적페이지를 생성하여 HttpServletReponse 객체로 응답합니다. 응답 후에는 HttpServletRequest, HttpServletResponse 객체는 소멸됩니다.

• spring filter, interceptor, aop 차이

• DI 설명

  • 의존성주입
  • setter 주입, 생성자 주입, 메소드 주입
  • 외부에서 추상화된것을 주입함으로써, 구체화된 것에 대한 의존성을 숨길 수 있음.

• 필터 인터셉터 순서 / 차이/ 어떨때 써봤나

  • 필터 -> 인턴셉터
  • 필터- spring외에, servlet단에서 지원, spring 프레임워크가 바뀌더라도 사용할 수있어야 함, 전역적인 이슈에 사용, 보안이슈라던가.
  • 인터셉터 - spring단에서지원, spring에 국한된 경우 사용
  • Interceptor는 DispatcherServlet이 실행된 후(= Controller로 가기 전), Filter는 DispatcherServlet이 실행되기 전에 호출된다.

• 모놀리틱 마이크로 장단점

• 스프링 컴포넌트 생각나는거 말하기 (gradle관련)

  • //galid1.tistory.com/494
  • Service, Controller, Repoisotry

• 컨트롤러에서 return 을 redirect와 forword 로 할때의 차이

  • redirect : 새로운 url 을 요청함,
  • forword : 요청정보 그대로 타며, 페이지만 변동

JPA

• Db 마스터 슬레이브 구조 썼나? 다른거?

  • 마스터 슬레이브 구조 씀

• Mysql, maria db일경우 클러스터링(또는 마스터-슬레이브) 시 스프링 옵션 설정 어떻게?

  • //velog.io/@kingcjy/Spring-Boot-JPA-DB-Replication-설정하기
  • config 커스텀해서, 여러개 db넣고, readOnly 인 경우, salve 사용.

• Sql 조인 종류설명

• Unique index pk fk

• fk시 cascade 사용했나?

  • 안했다, 개발자가 인지 할 수없는 부분이생기기 떄문에 추후 문제가 될가능성이 많다.

• cascade 사용시와 미사용시 장단점

  • 사용시 편함, 예를들면 1:n관계에서, 설정서 1 삭제시 n이 자동으로 삭제됨
  • 반대로 설정안하고 1을 삭제하면, 데이터 일관성이 깨지므로, 예외처리발생
  • 서비스단에서 모르게 row가 삭제되므로, 문제될 가능성이 있음.
  • 하지만 delete 쿼리를 여러번 서비스단에서 날려줘야함.

• JPA란

  • JPA의 시작은 DB에 데이터를 컬렉션 처럼 사용하면 얼마나 좋을까라는 생각부터 시작
  • JPA는 특별한것이 아니라 하나의 프레임워크임
  • jdbc 앞단에서, 쿼리를 생성해주고, 결과를 Entity에 매핑함.
  • 1차캐싱이라는 개념을 통해 데이터 동일성을 제공해줌

• JPA 구동방식

  • 개발자가 JPA를 사용하면, JPA 내부에서 JDBC API를 사용하여 SQL을 호출하여 DB와 통신한다.
  • 조회 :
    • 엔티티의 매핑 정보를 바탕으로 적절한 SELECT SQL을 생성한다.

• N+1 문제의 원인

  • 지연로딩일때, 컬렉션 조회 시 문제 발생
  • 1:1 관계는 기본적으로 즉시로딩이지만, 지연 로딩으로 설정했다면 fetch join으로해결
  • 1:N batch_size 지정으로하여, 컬렉션 entity 의 id값을 in절로 연관관계 데이터 batch 크기로 조회.

• RDB와 OOP 세계의 불일치를, JPA가 어떻게 해결하는가

  • 쿼리를 JPA가 만들어 주기 때문에 Object와 RDB 간의 패러다임 불일치를 해결할 수 있다.

• 1차 캐시, 2차 캐시

  • 1차캐시 한 컨텍스트내에서 1차 캐시, 컨텍스트가 종료되면 캐싱이 비워짐
  • 2차캐시 어플리케이션 단에서 캐시, 동일성을 보장하지 않음.

• JPA 로 복잡한 쿼리는 어떻게 짜는가

  • 적당히, 복잡한 건 Querydsl 로 구현
  • 아니면 앱단에서 쿼리, 여러번 요청 후 처리
  • 더 복잡하거나 통계, 관리자 페이지 쪽은 jdbc나 바티스로 분리하여 구현

• JPA 장점

  • 기본적으로 쿼리 필요없음
  • 따라서 DB 바꾸면 config 한줄만 바꾸면 됨
  • 필드 바뀌면 한줄만 바꾸면 됨

• 애그리거트

  • 하나의 도메인 집합.

자료구조

• Array
• LinkedList
• HashTable
• Stock
• Queue
• Graph
• Heap
  • 완전 이진트리의 일종
  • 최대힙, 최소힙
• Tree
  • 이진트리
  • 이진탐색트리

정렬

<img src="//static.podo-dev.com/blogs/images/2020/07/05/origin/85e0eca3-e78d-427d-9904-2b06a5fd5900.png" alt="base64.png" style="width:720px;">

• 선택정렬
  • 선택정렬은 N번의 순환과정에서, 가장 작은 또는 큰값을 찾아 처음부터 차례대로 교체함으로써 정렬하는 방식입니다. N번의 순환에대해서 N번의 비교를 하기 때문에 bigO(N^2)의 시간 복잡도를 가집니다. 비교적 데이터 이동이 적은 것이 장점입니다.
• 버블정렬
  • 버블정렬은 가장 간단한 정렬 방식입니다. 다음 데이터와 비교하여, 정렬에 맞게 위치를 교체해줍니다.버블정렬은 N번의 순환과정에서 최대 N번의 비교/교체 하며 따라서 bigO(N^2)의 시간복잡도를 가집니다. 장점은 가장 간단하지만, 비교적 자료 교환연산이 많아 잘 사용하지 않습니다.
• 삽입 정렬
  • 자신의 앞의 데이터와 비교하여, 자신의 위치를 찾아 "삽입"함으로써 정렬하는 방식입니다. 최악의 경우 N번의 루트에서 최대 N번의 비교를 가져 bigO(N^2)의 시간 복잡도를 가집니다. 최선으 경우 이미 정렬되어있는 경우에 bigO(N)의 시간복잡도를가집니다. 삽입 정렬의 장점은 안정된 정렬이며, 이미 어느 정도 정렬되어있는 경우에 효과적입니다.
• 병합 정렬
  • 병합 정렬은 분할정복 방식을 이용한 정렬 방법입니다. 데이터를 분할하고, 이를 반복합니다. 최대 분할하여 병합과정에서 정렬하는 방식입니다. 최대 log2N개로 분할되며, 각 병합과정마다 최대 N개의 비교가 이루어지기 때문에 bigO(Nlog2N)의 시간 복잡도를 가집니다.병합정렬의 장점은 안전한 정렬이며, 최악 평균 최대 모두 동일한 시간복잡도를 가집니다. 단점으로는 추가공간을 필요로하며, 비교적 이동연산이 많아 링크드 리스트를 사용하는 것으로 보안 할 수 있습니다.

db

• mysql 클러스터 //chaggun.egloos.com/v/3344309

• 정규화

  • 제1정규화 : 모든 값을 단일값을 가져야한다.
  • 제2정규회 : 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되면 제2정규형이다.
  • 제3정규화: non-key들간에 함수 종속이 없어야한다.
  • //yaboong.github.io/database/2018/03/09/database-normalization-1/

• 트랜잭션

  • ACID
  • 격리수준
  • 전파레벨
  • JOIN

• 파티셔닝

• JDBC

• Database Index

  • 인덱스는 Clustered Index와 Nonclustered Index 두가지 종류로 나눌 수 있다.
  • Clustered Index는 테이블당 하나만 생성된다 일반적으로 PK에 생성된다. 지정한 열에 대해서 내용 자체가 정렬되어 있어 검색 시 빠르게 검색이 가능하다.
  • Nonclustered Index는 Clustered Index처럼 자동 정렬되지 않는다.
  • MySQL에서는 기본적으로 B-Tree 형태의 인덱스 구조를 사용하며 InnoDB 엔진은 B-Tree 구조를 기본으로 Clustered 인덱스 구조를 가짐 Clustered 인덱스의 Leaf Node에 모든 Row 데이터를 저장하여, Primary Key 혹은 Unique Key가 Clustered Key 역할을 수행하며 Clustered Key는 한 테이블에 1개만 존재
  • Primary/Unique Key 모두 선언되지 않은 테이블의 경우에는 6 byte의 Hidden Key를 생성 (rowid) Non-Clustered Key는 데이터의 물리적인 위치 대신 PK 값을 참조함
  • 일단 index를 타지 않아 테이블 full scan하는 경우에 대해서 쿼리 튜닝이 필요하다. 쿼리 작성 시 explain으로 쿼리 실행 계획을 확인해서 index를 잘 타는지 full scan을 하지 않는지 체크하고 튜닝을 하자.

개발 문화

• 배포 어떤방식으로

  • 기존

• 깃 어떤 방식으로 사용

  • vcs 코드로, gitflow로 관리

• 코드리뷰 어떤걸 중점적으로 하는가

  • 아키텍쳐 관점은, 추후에 회의때 토론
  • 더 효율적인 코드가 있으면 코멘트로 제시

• 코드리뷰 하는 방식