Nginx와 Apache중 어떤걸 선택할것인가?

우선 만들어야 하는 서비스(시스템)의 특성에 대해서 나열해 보겠습니다.

• 서비스의 사용자
  • 불특정 다수의 일반인을 대상으로 하는 서비스
  • 사용자가 갑자기 증가할 수 있으므로 scalability 를 고려해야 함.
• 서비스 제공 방식
  • 웹 브라우저와 모바일 App을 통한 UI제공
  • UI에서(Client) Http 프로토콜을 이용한 RESTful 방식으로 서비스를 요청함.
• 개발 언어
  • 빨리 개발할 수 있는가?의 측면에서는 상대적 이겠지만, 개발 조직에게 가장 익숙하고 커뮤니티가 활성화 되어 있는 Java를 선택하고 WAS(Servlet container)를 사용해야 함
• 인프라 환경
  • Amazon AWS의 EC2 나 Google AppEngine을 고려하고 있음.
  • 가용할 수 있는 resource가 풍족하지 않고 제한적 임

위와 같은 특성을 기준으로 웹서버 선택에 중요한 조건들을 나열하면 아래와 같습니다.

• 로드 밸런싱(Load Balancing)을 지원해야 함.
• Micro Services Concept 을 유연하게 지원할 수 있어야 하며, 패턴에 의한 URL Redirect, Virtual 기능등을 지원해야 함
• WAS 와 연계가 가능해야 함.(Tomcat 등의 Servlet Container 와의 bridge 제공)
• Static Resource serving이 가능해야 하지만 주 사용목적은 WAS로의 bridge 및 load balancer 기능 제공임
• 불특정 다수의 사용자가 대상이므로 보안(Http Authentication) 및 SSL 사용이 가능해야 함
• 클라우드 환경에서 서비스 되므로 System Resource를 최대한 적게 사용해야 함

웹 서버를 신중하게 선택하는 것이 중요한 이유

• Apache와 Nginx는 함께 인터넷 트래픽의 50 % 이상 을 제공합니다. 이를 통해 세계에서 가장 일반적인 두 가지 오픈 소스 웹 서버가 됩니다.
• 어떤 기술을 선택하든 목표와 요구 사항에 따라 달라지므로 강력한 서버를 선택하면 사이트의 기능과 속도에 긍정적인 영향을 줄 수 있습니다.

Apache와 Nginx 소개

Apache

• 현재 HTTP 표준을 준수하도록 구축 된 오픈 소스, 고성능의 안전한 웹 서버입니다.
• 거의 모든 OS에서 실행 되며 다른 유명한 소프트웨어 프로젝트와의 훌륭한 문서화 및 통합 지원의 이점이 있습니다.

Apache의 또 다른 주요 이점은 다음과 같습니다.

• 클라이언트 요청을 처리하기 위해 멀티 스레드 방식을 따름
• 웹 서버 자체 내에서 동적 컨텐츠를 처리
• 모듈을 동적으로로드 및 언로드 (더 유연하게 만들기)
• 처음부터 웹 서버로 설계됨

Apache의 단점

웹 트래픽이 많아지면 Apache가 여러 요청을 동시에 처리 할 수 없다는 점에 유의해야 합니다. 

• 이는 클라이언트 요청을 처리하기 위한 다중 스레드 접근 방식을 따르고 각 스레드는 한 번에 하나의 연결 만 처리 할 수 있기 때문입니다.

Nginx

Nginx는 최신 웹 요구를 충족하도록 설계된 웹 서버 플랫폼 입니다 .

• 이 웹 사이트는 성장하는 웹의 요구 사항 인 1 만 개의 연결 을 제공 해야 하는 문제에 대한 해답으로 설계
• 효율적인 방식으로 많은 수의 사용자에게 동시에 서비스를 제공하는 데 중점을 두고 있습니다.
  • 효율성에 중점을 두고 있으며 경량 아키텍처와 높은 동시성이 있습니다.

Nginx의 주요 이점 중 일부는 다음과 같습니다.

• 이벤트 중심 접근 방식을 사용하여 클라이언트 요청 제공
• 제한된 하드웨어 리소스로도 여러 클라이언트 요청을 동시에 효율적으로 처리
• 단일 스레드를 통해 여러 연결을 처리 할 수 있습니다
• 최소한의 리소스로 웹 서버의 아키텍처를 개선하기 위해 독립형 HTTP 서버로 배치 가능

Nginx 단점

Nginx의 주요 단점은 동적 컨텐츠를 기본적으로 처리 할 수 없다는 것입니다. 

동적 콘텐츠에 대한 PHP 및 기타 요청을 처리 하려면 Nginx가 이를 실행하기 위해 외부 프로세서로 전달하고

렌더링 된 콘텐츠가 다시 전송 될 때까지 기다려야 합니다 (프로세스 속도 저하).

Nginx가 외부의 요청을 받아 뒷단 서버로 요청을 전달하는 행위를 리버스 프록시라고 합니다.

---

Apache 및 Nginx 서버의 장단점

• 특정 웹 사이트의 요구를 충족시키는 웹 서버를 선택하는 것이 중요
• 예를 들어 Apache는 기능이 풍부한 옵션이지만 Nginx는 뛰어난 리소스 효율성을 제공
• Nginx 의 가장 큰 특징은 비동기 Event Driven 에 의한 Non Blocking 처리를 한다는 것입니다.
• 동시 접속수가 늘어날 수록 물리 메모리가 증가하는 프로세스 기반의 apache 서버 에 비해 소비 메모리 량이 적어지면서 동시 처리 수를 급격하게 늘릴 수 있습니다.
• 또한 single Thread 기반으로 마스터 / worker 프로세스 구동 방식을 채택하여 context switching 를 하지 않기 때문에 CPU 사용률을 감소시킬 수 있습니다.
• 다만 결국 하드웨어 자원을 사용하는 것이므로 nginx 에서 읽기/쓰기가 자주 일어난다면 아파치가 더 좋을 수도 있습니다.
• 하지만 대부분의 웹 서버에서는 하드웨어 읽기가 발생하지 않는 캐시 제공, 리버스 프록시 서버, 로드 벨런서 등의 역할을 주로 담당하게 되므로 최근들어 더 자주 사용된다고 생각할 수 있을 것 같습니다.
• 그 외에도 nginx 는 여러 기능을 모듈 단위로 개발하여 nginx 를 컴파일할 때 필요한 모듈들만 조합해서 사용할 수 있습니다.

---

웹 사이트에 적합한 서버 유형을 선택하는 방법

대부분의 지역에서 이 두 서버는 서로 잘 경쟁합니다. 여전히, 그들은 뚜렷한 강점을 가지고 있습니다. 

• Apache에는 다양한 동적 모듈을 로드 하기 위한 더 많은 문서와 더 나은 지원이 제공되는 반면 Nginx는 트래픽이 많은 웹 사이트를 위한 많은 정적 컨텐츠 및 미디어 스트림을 제공 할 수 있습니다.
• 공유 호스팅을 사용하는 많은 웹 개발자 는 Apache의 편리함을 선호합니다.  반면 Nginx는 주로 VPS 호스팅 및 전용 호스팅에 사용됩니다.

고려해야 할 또 다른 옵션은 Apache와 Nginx를 함께 사용하는 것입니다.

Nginx는 Apache 앞에 리버스 프록시로 배치 할 수 있습니다. 이는 Nginx의 빠른 처리 속도를 활용하여 클라이언트의 모든 요청을 처리합니다. PHP 파일과 같은 동적 컨텐츠의 경우 Nginx는 요청을 Apache로 프록시 하여 결과를 처리하고 렌더링 된 페이지를 리턴 합니다.

결론은 정적 콘텐츠가 많은 트래픽이 많은 웹 사이트를 실행하는 경우 Nginx가 현명한 옵션이 될 수 있다는 것 입니다. 또는 지원 커뮤니티와 커뮤니티가 제공하는 풍부한 자원을 소중히 생각하는 경우 Apache가 편리한 선택 입니다. 

Nginx의 경우 일반적인 상황에서 아파치 보다 조금 더 많은 커넥션을 처리 하는데 그 이유는?

• 아파치의 경우 커넥션 당 하나의 스레드와 프로세스를 생성
• Nginx의 경우 listener 가 request를 처리하기 때문에 각 request 마다 스레드와 프로세스가 복제 되지 않는다.
• 이 때문에 메모리 적인 측면에서 Nginx는 System Resource를 적게 처리한다는 장점이 있다.
• NetFlix를 비롯한 대량의 요청을 처리하는 많은 서비스들이 Apache에서 Nginx로 옮겨가고 있는 추세이기도 합니다.

그렇다면 Apche와 Nginx는 왜 그렇게 성능의 차이가 날까요?

Apache는 과거 Java Servlet이 대중적이지 않을 당시에 웹 기반 어플리케이션을 만들수 있는 거의 유일한 대안이었습니다.

바로 CGI를 이용하는 것인데, 이때는 많은 웹 서비스들이 C나 Perl로 만들어져 있는 CGI를 이용해서 서비스를 제공 하였습니다.

이러다 보니 processe-base(fork 방식)로 개발할 수 밖에 없었고 상대적으로 NginX는 웹 어플리케이션을 서비스하기 위한 목적보다 Http Proxy의 목적으로 개발 되었기 때문에 event-base(비동기 방식의 요청 전달)방식으로 개발되어 동시 사용자에 대한 처리 능력이 더 좋을 수 있게 된 것 같습니다.

실제로 Nginx는 FCGI, SCGI 기능은 제공하지만 CGI나 ISAPI는 제공하지 않습니다.

즉, WAS를 비롯한 Web Application을 별도로 가져가지 않고(Tier를 분리하지 않고) CGI를 통한 light한 웹서비스를 제공하고자 한다면 Apache를 선택하는 것이 옳다. Web Server를 Http Proxy방식으로 사용하고자 하다면 Nginx를 사용하는 것이 바람직 하다는 생각입니다.

한줄 정리

메모리 측면에서 동접자 처리시 효율적인 Nginx를 사용하겠다.

Apache vs Nginx Performance: Optimization Techniques - SitePoint

Nginx vs Apache: Which Web Server Is the Best? (2020 Edition)

---

대칭키 암호화 방식과 공개키 암호화 방식의 차이

대칭키 암호화

전송자는 정보를 암호화하는 데 사용하고 수신자는 동일한 방식과 키를 사용해 복호화 한다

공개키(비대칭키) 암호화

공개 키와 개인 키의 개념을 기반으로 하는 비대칭 방식은 대칭 방식의 문제를 해결한다.

• 두 가지 키 중 하나로 평문을 암호화하면 다른 보완 키를 사용해야만 복호화 할 수 있다.

• 밥이 앨리스에게 회신하고 싶다면, 앨리스의 공개 키를 얻어서 평문을 암호화해 암호문을 보낸다. 엘리스는 자신의 개인 키를 사용해 그 암호문을 복호화한다.

언제 대칭 암호화를 사용하고, 언제 비대칭 암호화를 사용할까?

• 당사자 중 한쪽이(서버라고 하자) 일련의 키를 가지고 있으므로 암호화된 메시지를 받을 수 있다.

• 이는 공개 키로 암호화한 정보는 개인키를 사용해야만 복호화 되기 때문에 클라이언트에서 서버로 향하는 단방향으로만 정보를 보호한다.

• 서버에서만 그 정보를 복호화할 수 있다. 반대 방향은 보호되지 않는다.

  • 서버의 개인 키로 암호화된 정보는 공개 키를 가진 누구든지 복호화 할 수 있다.

• 상대편(클라이언트)은 서버의 공개 키를 사용해 무작위로 생성된 세션 시크릿을 암호화해 통신을 시작한다.

  • 그 다음 암호문을 다시 서버로 보내고, 서버는 다시 자신의 개인 키로 복호화 하면 그 시크릿을 갖게 된다.

  대칭키와 공개키 방식의 차이

  • 대칭키(비공개키) 방식

    특징 : 암복호화에 서로 동일한 키가 사용되는 암호화 방식. 그래서 키를 비공개 한다.

    장점 : 속도가 빠르다.

    단점 : 키 배송 위험성 존재하여 송신 측에서 수신 측에 암호 키를 전달하는 과정에서 노출 우려가 있다. 통신 상대가 많아질 수록 키 관리가 어렵다.

    대표 : DES, AES

  • 비대칭키(공개키) 방식

    특징 : 암복호화에 서로 다른 키가 사용되는 암호화 방식. 하나의 키는 공개키로 사용.

    장점 : 키 배송의 문제를 근본적으로 차단하여 안전성이 높다.

    단점 : 대칭키(비공개키)방식에 비해서 느리다.

    대표 : RSA

---

Collection의 종류와 특징을 설명하시오

Collection framework

• 객체나 데이터들을 효율적으로 관리(추가, 삭제, 검색, 저장)하기 위해서 사용하는 라이브러리

1. collection

2. map

크게 이 두 가지를 만들기 위한 인터페이스들, 인터페이스를 구현한 클래스들, 그리고 관련 알고리즘.

( A framework, by definition, is a set of interfaces that force you to adopt some design practices.)

Collection 객체는 여러 원소들을 담을 수 있는 자료구조를 뜻한다

• 배열과 비슷하지만 원소들을 계속 넣을 수 있는 봉투(resizable) (Array List, Queue, Stack, Linked List)

Call By Value / Call By Reference 차이 설명 및 예시

---

AspectJ에 대해 설명해보세요

2주차 내용에 일부 포함 https://lkh6561.tistory.com/1

스프링 빈은 기본적으로 싱글톤 방식으로 생성되는데 굳이 내부에 상태를 두고 싶다면 어떻게 할까?

---