Jins' Dev Inside

CORS(Cross Origin Resource Sharing)

최근에는 대부분의 웹 서버가 REST API 서버를 통해 동작하며, 백엔드 개발자라면 익숙하겠지만 프론트엔드만 담당한다면 당황할 수도 있다. 실제로 처음에 본인도 웹페이지부터 서버 개발에 입문하면서 당황했던 부분이다.

웹사이트는 종종 인터넷 상의 다른 서버에 호스팅된 리소스를 요청하는 경우가 있다. 이때, 서버를 거치지 않고 Browser 단에서 직접 외부 호스트로부터 리소스를 받는 일은 서버의 보안 입장에서 유쾌한 일은 아니며, 호스팅하는 서버 입장에서도 무분별한 요청을 받게 되는 일이다. CORS는 이를 위해 보안정책을 통해 이를 제한하고자 하는 개념이다.

 CORS는 웹페이지가 리소스가 존재하는 다른 도메인으로 요청이 발생하는 것을 제한하는 규칙이다. 브라우저와 서버에서 다른 도메인과 안전하게 연결을 하고자 요청을 제약하는 규칙이다.

 이러한 정책이 생겨나게 된 배경에는 웹서버의 API 적 역할이 강화되었기 때문이다. REST API 를 소개하면서 포스팅하겠으나, 많은 종류의 Web API 는 GET을 제외한 요청들이 데이터를 변경할 수 있게끔 되어 있다. 

그렇기 때문에 GET이 아닌 다음과 같은 요청들의 경우 전처리과정(Pre-flight Request) 라 하여, HTTP 요청을 보내기 전에 먼저 OPTIONS 요청을 보내서 호스팅 서버로부터 확인 작업을 거친다.

 만약 호스팅 서버로부터 인증받은 도메인의 허가받은 요청이라면, 그다음 본 요청으로 리소스를 가져온다.

 - Pre-flight 요청이 선행되는 경우 : PUT , DELETE , CONNECT, OPTIONS, TRACE, PATCH

(POST 요청의 경우 조건적으로 특정 MIME Type에 대한 호출에 대해서 Pre-flight가 선행된다.)

 이는 브라우저에서 쉽게 확인할 수 가 있다. 브라우저는 위와 같이 GET / POST 이외의 요청에 대해 OPTIONS Request를 보내는데, 다음처럼 Origin 이라는 헤더를 Request 에 담아 보내게 되고, 서버 측에서 Response로 Access-Control-Allow-Origin 라는 헤더에 허용된 도메인을 담아 보낸다.

그렇다면 호스팅 서버의 응답 값을 같이 살펴보자

위의 예에서 해당 서버는 example.com 이라는 도메인에서 요청한 PUT, DELETE 메서드만 허용한다. 물론 example.com 에서 요청했기 때문에 위의 요청은 PUT 또는 DELETE 라면 에러를 발생시키지 않고, 해당 PUT / DELETE API 를 요청한다.

 CORS 표준은 서버가 지정한 일련의 도메인 들에 대해 정보를 읽을 수 있도록 허가하는 HTTP 헤더를 추가하여 문제를 해결한다.

 * 일반적으로 서버측에서는 요청들에 대해 Credentials 를 담아 처리하게 하며, 별도로 리소스에 대한 접근을 허용하는 Whitelist 방식으로 처리한다.

처음 서버 실무를 시작할 때, 몰랐던 내용인데 의외로 명확히 설명해주는 곳이 없었다. 당연하게들 알고있는것 같다 ㅜ

더군다나 각종 프레임워크나 영미권의 Document 들에서는 Roll the log files 와 같이 쓰면서 Log rolling 을 검색하면 정치 용어 가 등장하여 정리해두었다.

 Log rolling 이란 일정 단위로 로그파일을 재갱신하는 작업으로 Log rotation이라고도 한다. 하지만 영어적 표현으로 Roll(굴리다) 으로 할 뿐 정식 명칭은 Log Rotation 이 맞는 것으로 보인다.

 무식하게 로그를 계속 쌓아나가는 것이 아니라 일정 주기로 백업 또는 별도 처리하고 파일을 덮어쓰면서 순환시킨다. 이 때 순환의 주기는 데이터 별로 다른데, 지워도 문제가 없을 수준으로 보통 정한다.

 이를 정하는 건 역시 노하우... 대부분 크리티컬한 유저 데이터가 아닌 이상 CS 가 발생하지 않을 수준에서 정리하곤 한다.

 apache의 경우 이슈에 대해 파이프 로그를 수행한다. 좀 더 자세히 말하면 아파치 웹서버의 경우 Log가 끊기지 않게 하기 위해서 서버와 함께 파이프 Process를 동작시켜서 Process가 죽더라도 Logging이 죽지 않도록 파이프를 이용해서 순환시킨다. 

 대부분 로그를 작성 시에 Error Log에는 날짜, 시간, 심각성, IP주소, 오류문, 경로, 해결책 등을 포함시키며 포맷을 벗어나지 않게 작성한다. Access Log에는 모든 요청을 기록하며 보통 Access Log는 에러로그 보다도 Massive 한 경우가 많기 때문에 메시지 큐를 담당하는 미들웨어로 보내서 처리하는 경우가 많다. 

개인적인 목적으로 사용할 때에나 개발을 위한 더미 환경을 구축해서 사용할 때나 VirtualBox 는 좋은 도구이다.(무료이기도 하고...)

처음에 환경을 세팅할 때 잘 몰랐던 부분 중 하나인 네트워크 세팅 방법을 정리해두었다.

(1) NAT : 각 가상머신을 별도의 가상 네트워크로 할당하여 호스트를 Gateway로 한 NAT를 구성하는 방식이다. 가상 머신이 호스트와 별도의 네트워크로 묶이기 때문에 가상머신 끼리의 연결은 지원되지 않는다.

(2) Bridged Network : 호스트 네트워크를 이용한 Bridged Network를 구성한다. 호스트와 동일하게 사용할 수도 있고 혹은 별도의 네트워크 설계도 가능하다. 단, IP 구성이 원활하지 않은 경우에 제한적이다.

(3) Host Only Network : Internal network 처럼 호스트와 격리된 네트워크를 구성하지만 호스트와 통신이 지원되고 DHCP를 이용한 IP할당이 가능하다. 가상머신들과 호스트 간의 네트워킹은 가능하나 인터넷이 안되므로 NAT방식과 같이 사용된다.

이 외에도 몇가지 방식들이 더 있으나, 하위호환 되면서 유명한 3가지 방법들만 정리해두었다.

방법들이 다양하지만 관건은 독립된 가상환경의 OS를 같은 망으로 묶을 것인가 아니면 별도의 독립 망으로 연결하고 터널링을 할 것인가에 따라 분류되는 듯 하다.

이 방법들을 활용하면 VM에서 직접 인터넷에 붙이거나 아니면 호스트의 인터넷 연결을 빌려 사용하거나, 또는 설정을 하지않음으로써 Private Subnet 처럼 가상환경을 구성할 수도 있다.

필자의 경우에는 주로 더미 환경 구축에 사용하므로 Private Subnet 으로 격리시키고 이런저런 테스트를 해보는 편이다.

data에 대한 데이터를 말하는 것으로, 다른 데이터를 설명해준다.

 정보를 효율적으로 찾기 위해서 일정한 규칙에 따라 컨텐츠에 부여되는 데이터이다.

 데이터 자체를 좀더 적은 정보량으로 표현하기 위하여 만들어졌으며, 이는 인터넷에서 문서들을 찾기 위한 일종의 태그 역할을 수행하기도 한다.

 즉, 메타데이터를 기준으로 문서를 구분할 수 있는 일종의 Unique 한 Key 역할을 할 수 있으며 이로 인해 주로 분석이나 분류 목적으로 따로 쓰이기도 한다.

실무에서도 주로 서버를 구성할 때, 관리하는 데이터는 이 meta data가 되며, meta data를 이용한 참조 혹은 인덱스로 실제 데이터를 가리키는 데 사용한다.

메타 데이터의 쓰임새는 워낙 무궁무진하며 혹자는 메타 데이터에 대한 설계 능력이 data를 설계하는 중요한 역량이라고 말하기도 하더라.

* 실무에서도 많이 쓰이는 용어이기 때문에 간단하지만 알아둘 필요가 있다.

가끔 대화를 하다보면 은근히 웹서버(Web Server), 어플리케이션 서버(Application Server) 혹은 웹 어플리케이션 서버(Web Application Server) 간에 단어의 사용이 혼동되어 쓰이는 경우가 많다.

실제로 "웹 프로젝트" 를 한다고 했을때 많은 학생들은 물론 가끔은 실무자 조차도 더러 자신이 만든 프로젝트가 어떤 종류의 서버인지 긴가민가 여기는 때가 있다.

가령 토이 프로젝트로 게시판을 만들었을 때, 이를 웹서버 경험이 있다고 해야하는지, 아니면 웹 뷰가 없을 때 이를 App Server 라고 봐야하는지 헷갈린다거나, 실무에서 해당 웹 프로젝트 아키텍처의 일부분으로 구성된 서버로 어떤 종류의 서버가 붙어야하는지 헷갈린다면 이 문서가 도움이 될 수 있다.

<굉장히 간단히 표현한 Application Server>

먼저 Application Server란 위에 보이는 것 처럼 말그대로 서버 그자체를 나타낸다. 그림에서 보이는 것처럼, 네트워크가 연결되어있기만 하다면, 그 네트워크를 통해 서버와 Endpoint 간의 통신을 할 수 있는 Server 이다.

즉, HTTP 뿐 아니라 TCP, UDP 등 다양한 프로토콜을 전달받아 클라이언트에 다양한 서비스를 제공한다. 

당연히 복잡한 비즈니스 로직의 처리를 할 수 있으며 이에 따라 Client는 단순히 정보를 Display하는 것 이상의 동작이 자유롭다. Java 진영에서는 트랜잭션 처리, 보안 처리, 리소스 풀링, 메시징 등을 처리해주는 EJB, J2EE 등이 대표적이다. 

많은 Application Server는 단순히 Web page를 띄우는 이상을 처리한다.(DB와의 동적인 연동, 클러스터링, fail-over, 로드밸런싱 등) 대표적인 Java 진영의 예로는 레진서버, Spring framework, Expresso 등이 J2EE의 대표적인 Application Server Framework이다. 

Application Server는 엄밀히 말하면 Web Server와 Web Application Server를 포함하는 상위 개념이라고 할 수 있다.

 Web Server 는 HTTP 프로토콜을 주로 처리하는 서버이다. 즉, Web Server는 Application Server에 포함된다. 

HTTP Request를 받아 HTTP Response를 주며, Request를 처리하기 위해 Static HTML, Image 또는 JSON 등을 이용한다. JSP, 서블릿, ASP 등이 이용되어 요청에 대한 단순 응답을 반환하는 간단한 구조를 갖는다. 인터넷 발달 초기, 단순히 인터넷을 통해 문서 조회만 가능하던 시절의 HTTP 서버들은 주로 정적인 동작만 하는 Web Server 였다고 할 수 있다.

 대표적으로 Apache가 있으며, Apache는 정적인 처리에 특화된 웹서버이고, 세트로 있는 Tomcat은 Servelet Container로 정적인 데이터와 동적인 데이터 처리가 가능하지만, 주로 동적인 데이터의 처리를 하는 Web Application Server이다. 

 WAS 가 태어나게 된 배경은, 인터넷의 발달을 예로 들 수 있다. 인터넷의 편한 접근성과 HTTP 라는 단순하면서도 효율적인 프로토콜의 발달로, 인터넷을 통해 단순히 문서 조회 이상의 많은 것들을 요구하게 되었다. 

기존에 TCP / UDP 등의 프로토콜들이 처리하던 전자상거래, 파일 공유 등의 기능 들을 HTTP 로 수행하려다 보니 나타난 새로운 형태의 서버라 볼 수 있다.

 추가로 말하자면 정적인 HTTP 데이터 처리에 특화된 Web server에 동적인 데이터를 이용하게끔 하는 Container를 엮으면 WAS가 되며, WAS는 HTTP 를 이용하는 Application Server로 볼 수 있다.

이러한 미세한 차이 때문에 일반적으로 위에 언급한 Static Server 의 경우 WAS라고 말하기 보다는 Web Server 혹은 스태틱 서버 라고 표현을 많이 하고, HTTP 프로토콜을 사용하지 않는 TCP 서버 등은 WAS가 아닌 App Server 혹은 Application Server 로 표현한다.