[ Java의 인터페이스 ]
∘ 극단적으로 동일한 목적 하에 동일한 기능을 수행하게끔 강제하는 것
∘ 자바의 다형성을 극대화하여 코드수정을 줄이고, 프로그램 유지보수성을 높이기 위해 사용한다.
∘ java8 이전까지는 상수, 추상메서드만 선언 가능했으나 java8부터 default메서드, static메서드가 추가
ⅰ. 상수 : 인터페이스에서 값을 정해줄테니 바꾸지 말고 제공해주는 값만 참조해라
ⅱ. 추상메서드 : 가이드만 줄테니 무조건 오버라이딩해서 재구현해라.
ⅲ. default 메서드 : 인터페이스에서 기본적으로 제공해주겠지만, 맘에 안들면 재구현해서 써라.
ⅳ. static 메서드 : 인터페이스에서 제공해주는거니까 무조건 이거 써라.
public interface Bank {
// 상수 : 변경 불가
public int MAX_INTEGER = 10000000;
// 추상메소드(인출하는 메소드)
void withDraw(int price);
// 추상메소드(입금하는 메소드) : 오버라이딩 필수
void deposit(int price);
// defualt 메소드 : 오버라이딩 선택
default String findAccount(String custId){
return "00은행 000-000-0000-00";
}
// static 메소드 : 오버라이딩 불가
static void auth( String bankName){
System.out.println("전 금융사 공통 로직 수행");
}
}
[ 웹 서버 vs WAS ]
웹 서버
∘ 웹 브라우저 클라이언트로부터 HTTP 요청을 받아들이고 HTML 문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램
∘ 요청에 따라 정적 컨텐츠를 제공하는 서버 (html, css, js, image, file...)
ex) Apache
WAS [ Web Application Server ]
∘ 인터넷 상에서 HTTP 프로토콜을 통해 애플리케이션을 수행해주는 미들웨어
∘ 동적 서버 컨텐츠를 수행하며 주로 DB서버와 같이 수행
∘ 웹서버가 단독으로는 처리할 수 없는 DB조회나 로직처리 등의 동적 컨텐츠 제공
ex) Tomcat
WAS는 웹서버의 역할 수행도 가능하지만 DB조회 및 로직처리에 집중해야하므로 단순한 정적 컨텐츠는 웹서버에게 맡겨 서버 부하를 방지한다.
[ 프레임워크 vs 라이브러리 ]
라이브러리
∘ 단순 활용 가능한 도구(미리 작성된 코드,변수,함수,클래스)들의 집합
∘ 개발자가 흐름에 대한 제어 권한을 지닌다.
∘ 도구를 사용하기만 하면 되므로 자유도가 높다.
프레임워크
∘ 소프트웨어의 특정 문제를 해결하기 위해 재사용 가능하도록 만들어진 소프트웨어 환경(뼈대)
∘ 전체적인 흐름에 대한 제어 권한을 자체적으로 가지고 있다.
∘ IoC(제어의 역전)이 적용되어있음
∘ 프레임워크가 지닌 규약을 지키며 개발해야 한다.
[ 동기화 vs 비동기화 ]
동기화
∘ 요청을 하면 시간이 얼마나 걸리던지 요청한 자리에서 결과가 주어져아 한다.
∘ 장점 : 설계가 간단하고 직관적이다.
∘ 단점 : 결과가 주어질 때까지 대기해야 한다.
비동기화
∘ 요청을 보낸 후의 응답(결과)과는 관계없이 다음 요청이 동작하는 방식
∘ 장점 : 결과가 주어지는 데 시간이 걸리더라도 다른 작업을 할 수 있으므로 자원을 효율적으로 사용할 수 있다.
∘ 단점 : 복잡하다.
[ HTTP : HyperText Transfer Protocol ]
특징
ⅰ. 클라이언트 – 서버 구조
∘ 클라이언트에서 서버에 요청을 하는 단방향 통신
ⅱ.Statless
∘ 서버는 클라이언트의 상태를 저장하지 않는다. ⇨ 클라이언트의 이전 요청이 무엇인지 모른다.
∘ 대규모 트래픽이 발생하는 서비스에서 정보 공유를 최소화하여 비용을 줄이기 위해
∘ 각 서버가 요청을 독립적으로 처리할 수 있게 된다.
ⅲ. Connectionless
∘ 연결을 유지할 수록 리소스가 많이 발생하기 때문에 연결을 유지하지 않는다.
∘ 단점 : 동일한 클라이언트의 모든 요청에 대해 매번 새로운 연결/해제 과정을 거친다.
∘ 해결방법 : HTTP KeepAlive 속성으로 지정된 시간동안 연결 유지
[ 쿠키 vs 세션 ]
쿠키와 세션 모두 HTTP 프르로토콜의 특성이자 약점인 Connectionless, Stateless를 보완하기 위해 사용
쿠키 Cookie
∘ 클라이언트 로컬에 저장되는 key-value 형식의 데이터 파일
∘ 브라우저가 종료되어도 유지
∘ Response Header에 Set-Cookie 속성을 통해 클라이언트에 쿠키 생성 가능
∘ 속도가 빠르다.
∘ 동작 방식
ⅰ. 클라이언트의 페이지 Request
ⅱ. 서버에서 HTTP Header에 쿠키를 포함시켜 Response
ⅲ. 이후 쿠키를 서버에서 읽거나 수정하여 사용
∘ 쿠키의 사용 예
⋅ 로그인 시 “아이디와 비밀번호를 저장하시겠습니까?”
⋅ 쇼핑몰의 장바구니
⋅ 팝업에서 “오늘 더이상 이 창을 보지 않음”
세션 Session
∘ 사용자 정보 파일을 서버 측에서 관리
∘ 클라이언트를 구분하기 위해 세션 ID를 부여하여 브라우저 종료 전까지 인증 상태 유지
∘ 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 사용하게 된다.
∘ 동접자 수가 많은 웹사이트에 서버 과부하를 줄 수 있다.
∘ 세션도 결국 쿠키를 사용
∘ 동작 방식
ⅰ. 클라이언트가 서버에 접속시 세션ID를 발급받음
ⅱ. 클라이언트가 세션ID에 대해 쿠키를 사용하여 지닌다.
세션은 사용자 수 만큼 서버 메모리를 차지하기 때문에, 이런 문제를 보완하고자 토큰 기반의 인증방식을 사용하는 추세 (JWT)
[ JWT : Json Web Token ]
∘ Self-Contained (자가 수용적)
JWT는 필요한 모든 정보를 자체적으로 지닌다. JWT 시스템에서 발급된 토큰은 기본정보, 전달정보, 토큰이 검증됨을 증명하는 signature를 포함한다.
- 로그인
- 사용자 로그인 -> 서버가 해당 유저의 토큰을 유저에게 전달 (JWT)
-> 유저가 유청을 할때 토큰을 포함해서 전달
-> 서버는 해당 토큰일 권한이 있는지 유효하고 인증이 되었는지 확인하고 작업을 진행 - 서버는 유저의 세션을 유지할 필요가 없다.
유저가 보낸 토큰만 확인하면 된다.
서버의 자원을 아낄수 있다.
- 사용자 로그인 -> 서버가 해당 유저의 토큰을 유저에게 전달 (JWT)
- 정보교류
- JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법이다.
그 이유는, 정보가 sign 이 되어있기 때문에 정보를 보낸이가 바뀌진 않았는지,
또 정보가 도중에 조작되지는 않았는지 검증할 수 있다.
- JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법이다.
[ 대용량 트래픽 처리 ]
∘ 기존 단일 서버 환경의 제한된 리소스로 수많은 사용자를 수용하기에는 어려움이 있다.
∘ 더 많은 사용자를 수용하기 위해서는 서버 리소스(CPU, RAM)를 늘려야 한다.
Scale Up (수직 확장)
∘ 기존 서버의 성능을 높이는 방법
∘ 성능 확장에 한계 존재
∘ 단일 장애 지점 : 한 대의 서버가 다운될 경우 서비스를 제공할 수 없다.
Scale Out (수평 확장)
∘ 동일한 목적을 갖는 서버를 여러대 추가
∘ Load Balancer 사용
Load Balancer
∘ 부하 분산을 위해 가상 IP를 통해 여러 서버에 접속하도록 부하를 분배하는 기능
∘ 서버 메모리 공간에 저장되는 Session의 불일치 문제점(정합성 문제)가 발생한다.
∘ 해결 방법
1. Sticky Session ( 고정 세션 )
∘ 세션 기간동안 동일한 client의 http request를 항상 동일한 서버로 라우팅해주는 기능
∘ AWS ELB와 같은 경우 쿠키에 해당 client와 바인딩된 EC2인스턴스 정보를 저장하여
Sticky Session 기능을 동작시킨다.
∘ 장점 : 여러 서버가 세션 데이터를 교환할 필요가 없다.
∘ 단점 : 특정 서버에 몰린 사람들만 활발하게 활동하는 경우 과부하가 발생할 수 있다.
2. Session Clustering
∘ 다중 서버 환경에서 로드밸런서를 통해 어떤 서버로 접속하든지 세션이 동일하게 유지되도록 설정
DeltaManager
⋅ 특정 서버의 Session 정보를 나머지 모든 서버에 복제
⋅ 비용이 큰 작업이므로 대규모 환경에서 적합하지 않다.
BackupManager
⋅ Backup 서버를 하나만 두는 전략
⋅ 특정 서버에서 발생한 Session 정보를 나머지 서버들 중 오직 1대에만 복제
⋅ 성능 확장에 한계가 있다.
세션 데이터 저장을 목적으로 인메모리 데이터베이스를 사용하여 해결할 수 있다.
[ 캐싱 전략 ]
서버를 구성할 때 DB는 주로 RDBMS를 사용한다. 규모가 커지면 쿼리 하나 실행에도 많은 시간이 걸린다. DB 튜닝, 효율적인 index 생성 등의 해결방법도 있지만 가장 근본적인 문제인 RDBMS로의 쿼리 전송을 데이터 캐싱을 통해 줄이는 방법이 존재한다.
∘ 데이터 캐싱 : 처음 쿼리 전송시 DB에서 직접 가져오지만 두번째 쿼리부터는 캐시에 저장된 데이터를 가져온다.
∘ DB 캐시용으로 인메모리 데이터베이스인 NoSQL류의 Redis / Memcached를 주로 사용한다.
∘ Amazon ElastiCache는 Redis, Memcached와 호환 가능
∘ 단점 : 캐시미스시 더 시간이 오래걸린다. 동기화 문제가 중요해진다.
∘ 캐싱 전략
ⅰ. Read-Through
∘ 캐시 미스가 발생하면 DB에서 누락된 데이터를 다시 로드하고 캐시를 채우고 반환한다.
장점 : 읽기가 많은 상황에 적합하다.
단점 : 데이터를 처음 요청하면 항상 캐시 누락이 발생한다.
ⅱ. Write-Through
∘ 데이터를 DB에 작성할 때마다 캐시에 데이터를 추가/수정한다.
장점 : 항상 동기화되어있다.
단점 : 쓰지 않는 데이터도 캐시에 저장되기 때문에 리소스 낭비가 심하다.
쓰기 지연시간이 증가한다.
여러 장점과 단점이 있지만, Write-Through 캐시와 Read-Through 캐시를 함께 사용하면 Read-Through 캐시의 모든 이점을 얻을 수 있으며 데이터 일관성 보장도 얻을 수 있다. (ex. AWS DynamoDB Accelerator )
ⅲ. Write-Around
∘ 데이터는 DB에 직접 기록, read data만 캐시에 저장
장점 : 데이터가 한번 쓰여지고 자주 읽히지 않는 상황에 적합하다.
실시간 로그 & 채팅방 메시지에 적합
ⅳ. Write-Back
∘ 캐시에 먼저 데이터를 Write, 약간의 지연 후 데이터를 다시 DB에 Write
장점 : Write가 많은 상황에 적합
DB에 대한 전체 Write 비용을 감소할 수 있다.
단점 : 캐시에서 오류가 발생하면 데이터를 영구 소실한다.
∘ 캐시를 적용하는 위치에 따라 두가지로 나뉜다.
ⅰ. Local Cache
∘ 서버마다 캐시를 따로 저장한다.
장점 : 서버 내에서 작동하기 때문에 속도가 빠르다
단점 : 데이터를 처음 요청하면 항상 캐시 누락이 발생한다.
캐시에 저장된 데이터가 변경될 경우 해당 서버를 제외한 모든 peer에 변경사항을 전달해야 한다.
ⅱ. Global Cache
∘ 여러 서버에서 캐시 서버에 접근하여 참조할 수 있다.
장점 : 별도의 캐시 서버를 사용하기 때문에 서버간 데이터 공유가 쉽다.
캐시에 저장된 데이터가 변경되는 경우 추가적인 작업이 필요없다.
단점 : 네트워크를 통해 데이터를 가져오므로 로컬 캐시보다 느리다.
[ Redis ]
- Redis는 싱글쓰레드를 사용하며 쓰레드 스케쥴링처리가 필요없고 처리도중 에러가 발생할 확률이 적다.
- Memcached에 비해 많은 API를 제공하기때문에 (Spring Redis제공) 상대적으로 진입하기 쉽다.
- 손쉽게 master - slave 구조로 구성 가능하기 때문에 Failover에 대응하기 쉽다.
[ Cloud ]
∘ 종류 : IaaS, PaaS, SaaS
[ Connection Pool ]
∘ DB와 연결된 커넥션을 미리 만들어 Pool속에 저장해두고 필요할 때 커넥션을 사용하고 다시 Pool에 반환하는 기법
∘ 미리 생성해두기 때문에 DB의 부하를 줄일 수 있다.
∘ 커넥션 생성, 삭제등의 불필요한 작업을 하지 않는다.
∘ SpringBoot에서는 히카리cp를 사용, 보통 pool size : 10
[ CORS : Cross-Origin Resource Sharing ]
교차 출처 리소스 공유
∘ 도메인이 다른 2개의 사이트가 데이터를 주고 받을 때 발생하는 문제
∘ 브라우저는 보안상의 이유로 교차 출처 HTTP 요청을 제한한다.
∘ 도메인A에서 도메인B로 데이터를 요청한다고 하면, 따로 설정을 해주지 않는 한 CORS 에러를 만나게 된다.
∘ Access-Control-Alow-Origin: {도메인} 과 같은 내용을 Response의 헤더에 추가해주어야 한다.
[ 디자인 패턴 ]
- 생성 패턴
- 팩토리 패턴: 객체를 생성하기 위한 디자인 패턴
- 추상 팩토리 패턴: 객체를 생성하는 팩토리를 생성하기 위한 디자인 패턴
- 빌더 패턴: 상황에 따라 동적인 인자를 필요로 하는 객체를 생성하기 위한 디자인 패턴
- 싱글톤 패턴: 객체를 1개만 생성하여 항상 참조가능하도록 고안된 디자인 패턴
- 구조 패턴
- 어댑터 패턴: 호환성이 맞지 않는 두 클래스를 연결하여 사용하기 위한 디자인 패턴
- 프록시 패턴: 어떤 객체에 접근하기 위해 대리인을 사용하는 디자인 패턴
- 데코레이터 패턴
- 퍼사드 패턴: 어떤 복합적인 기능에 대해 간략화된 인터페이스를 제공하는 디자인 패턴
- 행위 패턴
- 전략 패턴: 상황에 따라 다른 전략을 사용하기 위한 디자인 패턴
- 옵저버 패턴: 값을 관찰하여 빠르게 반영하기 위한 디자인 패턴
- 커맨드 패턴: 실행될 기능을 캡슐화하여 재사용성이 높은 클래스를 설계하기 위한 디자인 패턴
[ MVC 패턴 ]
MVC(Model-View-Controller)패턴은 아키텍쳐를 설계하기 위한 디자인 패턴입니다.
MVC 패턴은 애플리케이션을 개발할 때 그 구성요소를 3가지로 나눕니다.
- Model: 데이터를 저장하는 컴포넌트
- View: 사용자 인터페이스(UI) 컴포넌트
- Controller: 사용자의 요청을 처리하고 Model과 View를 중개하는 컴포넌트ㅁ
[ Redirect vs Forward ]
Redirect
∘ Redirect를 통해서 웹페이지 이동을하게 되면 웹 컨테이너가 웹 브라우저에게 페이지 이동 명령을 내린다.
그후 웹 브라우저는 URL을 지시된 주소로 바꾸고 그 주소를 이동한다.
∘ 이때 새로운 페이지에서는 req,res 객체들이 새롭게 생성되기 때문에 req,res를 같이 넘기지는 못한다.
Forward
∘ 웹 컨테이너 에서 페이지 이동이 있지만, 실제로 웹 브라우저는 다른 페이지로 이동했음을 알수가 없다.
∘ 그렇기 때문에 웹 브라우저에는 최초에 호출한 URL이 그대로 표시되고 이동한 URL은 알수가 없다.
∘ 현재 실행중인 페이지에서 Forward를 통해서 호출될 페이지는 req,res를 공유하게된다.
[ Error ]
404 : Not found — 현재는 요청한 페이지를 찾을 수 없지만, 나중엔 사용 가능할지도 모름.
503 : Service unavailable — 서버 현재 사용 불가 (과도한 데이터요청으로 서버 다운 상태)
400 :파라미터 변수값이 맞지 않은 상태에서 화면을 넘어갈 경우(값을 넘겨줄 경우)
'면접' 카테고리의 다른 글
| IT 인성면접 질문&팁 모음 (3) | 2021.11.29 |
|---|
댓글