태그 보관물: http

고성능 앱 서비스를 위한 아키텍처링..

아래 내용은 제가 테스트한 내용이 아니라, 경험을 기반으로 제가 생각하는 고성능의 서비스를 위한 아키텍처링에 대한 내용이고, 아래 내용은 앱<->API 서버 간의 성능향상을 위한 방안에 대한 내용이다.

요즘 상당히 많은 앱들이 네트웍으로 데이터를 전송받아서 랜더링하고, 유저가 만들어낸 데이터를 전송하기도 한다. 그래서, 네트웍으로 데이터를 주고 받는 앱들은 서버(보통 웹서버)와의 통신에서 JSON을 표준(많이 사용하는 추세) 프로토콜처럼 사용하고 있다. JSON을 사용하는 아키텍처가 가지고 있는 성능저하 요소를 살펴보면, 아래의 목록을 예상할 수 있습니다.

– JSON의 사용은 파싱에 드는 비용, 데이터 사이즈로 인한 전송(3G 대비)속도 저하가 예상이 된다.
– HTTP/HTTPS 프로토콜을 사용하는 서버(웹 서버)를 사용해서, 연결과 데이터 전송과 수신에 오버헤드(HTTP 프로토콜의 헤더만 읽어봐도 이해가 되실 듯)가 발생한다. 

그래서, 위의 성능저하 요소를 걷어내고 고성능의 앱을 개발하기 위한 방법으로, 아래의 방식을 고려할 필요가 있다. 아래의 형태로 개발하게 되면, 개발 비용이 증가하는 단점이 있다. 하지만, 네트웍을 많이 사용하는 앱(예로 카카오톡이나 채팅앱)이라면 연결기반의 프로토콜을 서버가 제공하고, 앱이 그 프로토콜을 사용한다면, 매번 연결하지 않고 네트웍으로 데이터를 보내고 받는 것이, 위의 비 연결지향의 프로토콜인 HTTP/HTTPS와는 비교할 수 없을 정도로 빠른것을 알게 될 것이다.

– JSON 보다는 고 성능의 데이터 직렬화 라이브러리(MessagePack, Thrift, Google Protocol Buffers)를 사용한다.
– 소켓(SSL 적용) 서버(Netty 프레임윅 등으로 개발)로 연결지향 프로토콜 기반에서 데이터를 처리한다. 이 방식의 경우에는 소켓 서버에서 클라이언트의 idle time을 적절하게 계산해서 주기적으로 클라이언트의 소켓을 제거해 주는 로직이 필요합니다.. 이 로직이 없을 경우, file descriptor가 부족해 지겠죠.. ^^

당장은, 필요하다고 느끼지 못하거나, 너무 오버한다고 생각할 수 있으나, 기본적으로 유저가 많은 포털의 앱이나, 이미 많은 유저가 사용하는 앱들은 프로토콜과 데이터 형식만 바꿔도 상당한 성능향상을 가져올 수 있을 것이라 생각한다. ^^

HTTP 1.1 메쏘드(Method)들

대략적으로 아래의 기능들이 있다.

OPTIONS : Request와 Response 관계 정의
GET : Entity Body로 정보 요청
HEAD : 서버 정보 요청
POST : 바디에 포함된 정보 요청
PUT : 바디의 정보를 URI로 보냄
DELETE : 특정 자원 삭제
TRACE : 요청이 최종 수신까지 도달하는 과정 조사
CONNECT : 터널을 형성하고 다이나믹하게 바꾸기위한 프락시 지원

위 메쏘드들은 ftp://ftp.isi.edu/in-notes/rfc2616.txt 에 정리되어 있다.

* Reference
http://flex.okjsp.pe.kr/seq/43089

HTTP 1.0 메서드

HTTP 1.0 스펙의 메서드에 대해서 정리된 내용이고, 이 내용은 아래의 파일로 저장했다.  HTTP 1.0 스펙

8. Method 정의

HTTP/1.0 프로토콜에는 요구 메시지에 지정하는 대상에 대한 활용 방법에 대한 표시를 하도록 되어 있는데 method라고 하는 것이다. 즉, 지정한 Request-URI에 대해 보내달라고 전송 요청 (GET) 할지, 서버에 전달하고자 (POST) 할지, 해당 문서의 헤드 정보 (HEAD) 만을 전송 요청 할지, 이에 대한 활용 방법을 지정하는 것이다.

위 세 가지 method 종류 이외에 추가할 수도 있지만, 추가적인 기능 구현의 클라이언트와 서버를 위해 같은 역할을 하는 다른 이름으로 method를 만들 수는 없다.

8.1 GET

GET method는 Request-URI에서 지정한 어떤 정보이든지 entity body로서 전달해 달라고 요청하는 의미로서 쓰인다. Request-URI가 어떤 실행 프로그램을 명시하는 경우에는 실행 프로그램 자체가 전달되는 것이 아니라 실행된 결과가 응답 메시지의 entity body로서 전달된다.

요구 메시지에 If-Modified-Since 헤더 필드가 포함되어 있다면 GET은 조건부 GET으로도 동작할 수 있다. 이 경우의 GET이 가지는 의미는, 지정된 자원이 If-Modified-Since에 의해 지정된 일자 이후에 수정된 것일 경우에만 전송하라는 것이다.

이 조건을 이용하여 불필요한 데이타 전송을 막을 수 있고 이미 캐시되어 있는 데이타를 사용자에게 전달해줌으로써 네트워크의 활용성을 높일 수 있다.

8.2 HEAD

HEAD method는, 응답 메시지의 Entity-Body에 어떤 내용도 실어 보내서는 안 된다는 점을 제외하고는 GET method와 똑같다. HEAD 요구 메시지에 대한 응답으로 HTTP 헤더에 포함되는 데이타 형태 정보는 (metainformation, 4.6절 참조) GET 요구에 대한 응답으로 전달되는 정보와 동일해야 한다.

이러한 HEAD method는 Request-URI에 의해 지정되는 자원에 대해 Entity-Body에 실제 내용을 가져오지 않더라도 자원에 대한 외형 정보 (metainformation) 획득을 위해 사용할 수 있다.

이것을 활용하여 자원에 대한 유효성, 접근성, 최근 수정 정보 등에 대한 검사를 수행할 수 있다. 여기서 조건부 GET과 비슷한 조건부 HEAD 동작은 허용하지 않는다. 따라서, If-Modified-Since 헤더 필드가 HEAD 요구 메시지에 포함된다면 무시하도록 해야 한다.

8.3 POST

POST 요구 메시지는 메시지의 entity body에 포함되어 있는 자원을 Request-Line에 있는 Request-URI에 지정되어 있는 대로 서버에서 수용해달라고 요청할 때 쓰인다. 즉, POST는 다음과 같은 기능을 수행하기 위한 한 가지 방법으로 설계되었다.

– 기존 문서에 주석을 붙일 때
– BBS 게시판, 메일링 리스트, 뉴스그룹, 또는 글 모음 장소 등에 글을 올릴 때
– 어떤 프로그램의 실행을 위해 form과 같은 특정 규격의 데이타를 넘겨줄 때
– 부가적인 동작을 통해 데이타베이스를 확장하고자 할 때

POST method에 의해 수행되는 실제 동작은 서버에 의해 결정되고 통상 Request-URI에 의해 좌우된다. 포스팅되는 대상은, 하나의 화일이 어느 디렉토리에 자리하게 되고 뉴스가 포스팅되는 뉴스그룹에 올려지고 레코드가 데이타 베이스가 등록되는 등과 똑같은 방식으로 지정된 URI에 놓이게 된다.

POST는 대상 서버에 하나의 자원으로서 생성될 필요가 없고 추후의 참조를 위해 접근 가능해야 할 필요도 없다. 즉, POST method에 의해 수행되는 동작은 포스팅 되는 entity가 URI에 의해 지정될 수 있는 자원이 아니어도 된다는 것이다. 이 경우의 적절한 응답 결과 코드는 200 (ok) 또는 204 (no content)가 될 것인데, 응답 메시지에 entity가 포함되어 있느냐 있지 않느냐에 따라 구분이 될 것이다.

어떤 자원이 대상 서버에 생성되는 경우라면 응답 결과 코드는 201(created)이 되어야 하고 상태 정보나 생성된 새 자원에 대한 정보를 알려주는 entity가 포함되어 있어야 한다. HTTP/1.0의 모든 POST 요구 메시지에는 Content-Length가 반드시 있어야 하며, 서버가 이에 대한 정보를 확보하지 못하게 되면 400(bad request) 메시지를 응답해야 한다. 응용 프로그램에서는 POST 요구 메시지에 대한 응답을 캐싱할 필요가 없다. 왜냐하면 서버가 추후의 요구 메시지에 대한 응답으로서 똑같은 응답을 할 것인지 알 수가 없기 때문이다.

HTTP(Hyper Text Transfer Protocol) 에러 메세지 ..

101: Switching Protocols
– 서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임. (HTTP 1.1에서 처음 등장)

200: OK
– 전송 성공

202: Accepted
– 서버가 클라이언트의 명령을 받음.

203: Non-authoritavive Information
– 서버가 클라이언트 요구중 일부만 정송

204: Non Content
– 클라이언트 요구를 처리했으나 전송할 데이터가 없음.

205: Reset Content
– 새 문서 없음. 하지만 브라우저는 문서 창을 리셋해야 한다. 브라우저가 CGI 폼 필드를 전부 지우도록 할 때 사용 된다. (HTTP 1.1에서 처음 등장)

206: Partial Content
– 클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음. (HTTP 1.1에서 처음 등장)

300: Multiple Choisces
– 최근에 옮겨진 데이터를 요청

301: Moved Permanently
– 요구한 데이터를 변경된 임시 URL에서 찾았음.

302: Moved Permanently
– 요구한 데이터가 변경된 URL에 있음을 명시. 301과 비슷하지만 새 URL은 임시 저장 장소로 해석된다. 이 메시지는 HTTP 1.0에서는 ‘Moved Temporarily’였다. 그리고 HttpServletResponse의 상수는 SC_FOUND가 아니라 C_MOVED_TEMPORARILY다. 이것은 매우 유용한 헤더인데 이 헤더를 통해 브라우저가 자동으로 새 URL의 링크를 따라가기 때문이다. 이 상태 코드는 아주 유용하기 때문에 이 상태 코드를 위해 sendRedirect 라는 특별한 메소드가 있다. response.sendRedirect(url)을 사용하는 것은 response.setStatus(response.SC_MOVED_TEMPORARILY)과 response.setHeader(“Location”, url)를 쓰는 것에 비해 몇 가지 장점이 있다. 첫째, 더 쉽게 사용할 수 있다. 둘째, sendRedirect을 써서 서블릿이 그 링크를 포함한 페이지를 자동으로 만들어 준다(자동으로 redirect를 따라갈 수 없는 오래 된 브라우저에서도 볼 수 있게 해 준다). 마지막으로, sendRedirect에서는 상대 URL이 절대 URL로 해석되기 때문에 상대 URL도 다룰 수 있다. 이 상태 코드는 종종 301번과 혼용된다. 예를 들어 (맨 마지막에 ‘/’이 빠짐)과 같이 오류가 있는 요청에 대해 어떤 서버는 301을 어떤 서버는 302를 보낸다. 기술적으로 브라우저는 원 요청이 GET이었다면 자동적으로 리다이렉션을 따라 가도록 되어 있다. 더 자세한 사항은 307 헤더를 보라

303: See Other
– 요구한 데이터를 변경하지 않았기 때문에 문제가 있음.

304: Not modified
– 클라이언트의 캐시에 이 문서가 저장되었고 선택적인 요청에 의해 수행됨(보통 지정된 날짜보다 더 나중의 문서만 을 보여주도록 하는 If-Modified-Since 헤더의 경우). 서버는 클라이언트에게 캐시에 저장된 이전 문서를 계속 사용해야 한다고 말할 것이다.

305: Use Proxy
– 요청된 문서는 Location 헤더에 나열된 프록시를 통해 추출되어야 함. (HTTP 1.1에서 처음 등장)

400: Bad Request
– 요청실패, 문법상 오류가 있어, 서버가 요청사항을 이해하지 못함, 클라이언트는 수정없이 요청사항을 반복하지 않을 것이다.

401.1: Unauthorized
– 권한 없음 (접속실패)이 에러는 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지 않을 경우 발생한다. 이 경우, 여러분이 요청한 자원에 접근할 수 있는 권한을 부여받기 위해 서버 운영자에게 요청해야 할 것이다.

401.2: Unauthorized
– 권한 없음(서버설정으로 인한 접속 실패)이 에러는 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지않을 경우 발생한다. 이것은 일반적을 으로 적절한 www-authenticate head field를 전송하지 않아서 발생한다.

401.3: Unauthorized
– 권한 없음(자원에 대한 ACL에 기인한 권한 없음)이 에러는 클라이언트가 특정 자원에 접근할 수 없을 때 발생한다. 이 자원은 페이지가 될 수도 있고 , 클라이언트의 주소 입력란에 명기된 파일일 수도 있다. 아니면 클라이언트가 행당 주소로 들어갈때 이용되는 또 다른 파일일 수도 있다. 여러분이 접근할 전체 주소를 다시 확인해 보고 웹 서버 운영자에게 여러분이 자원에 접근할 권한이 있는지를 확인해 본다.

401.4: Unauthorized
– 권한 없음(필터에 의한 권한 부여 실패)이 에러는 웹 서버가 서버에 접속하는 사용자들을 확인하기 위해 설치한 필터 프로그램이 있음을 의미한다. 서버에 접속한는 데 이용되는 인증 과정이 이런 필터 프로그램에 의해 거부되었다.

401.5: Unauthorized
– 권한 없음(ISAPI/CGI 애플리케이션에 의한 권한부여 실패)이 에러는 여러분이 이용하려는 웹 서버의 어드레스에 ISAPI나 CGI프로그램이 설치되어 있어 사용자의 권한을 검증하고 있음을 의미한다. 서버에 접속하는 데 이용되는 인증 과정이 이 프로그램에 의해 거부되었다.

402: Payment Required
– 예약됨.

403.1: Forbidden
– 금지(수행접근 금지)이 오류는 CGI나 ISAPI,혹은 수행시키지 못하도록 되어있는 디렉토리 내의 실행 파일을 수행시키려고 했을 때 발생한다.

403.2: Forbidden
– 금지(읽기 접근 금지)이 에러는 브라우저가 접근한 디렉토리에 가용한 디폴트 페이지가 없을 경우에 발생한다. 아니면 Eecute나 Script로 분한이 부여된 디렉토리에 들어있는 HTML페이지를 보려했을 때 발생한다.

403.4: Forbidden
– 금지(SSL 필요함)이 에러는 여러분이 접근하려는 페이지가 SSL로 보안유지 되고 있는 것일 때 발생한다. 이것을 보기 위해서 여러분은 주소를 입력하기 전에 먼저 SSL을 이용할 수 있어야 한다.

403.5: Forbidden
– 금지 (SSL 128필요함)이 에러는 접근하려는 페이지가 SSL로 보안유지 되고 있는 것일 때 발생한다. 이 자원을 보기 위해서는 여러분의 브라우저가 SSL의 행당 레벌을 지원해야 한다. 여러분의 브라우저가 128비트의 SSL을 지원하는 지를 확인해 본다.

403.6: Forbidden
– 금지(IP 주소 거부됨)이 에러는 서버가 사이트에 접근이 허용되지 않은 IP주소를 갖고 있는데, 사용자가 이 주소로 접근하려 했을 때 발생한다.

403.7: Forbidden
– 금지(클라이언트 확인 필요)이 에러는 여러분이 접근하려는 자원이 서버가 인식하기 위해 여러분의 브라우저에게 클라이언트 SSL을 요청하는 경우 발생한다. 이것은 여러분이 자원을 이용할 수 있는 상용자임을 입증하는데 사용된다.

403.8: Forbidden
– 금지 (사이트 접근 거부됨)이 에러는 웹 서버가 요청사항을 수행하고 있지 않거나, 해당 사이트에 접근하는 것이 허락되지 않았을 경우 발생한다.

403.9: Forbidden
– 접근 금지(연결된 사용자수 과다)이 에러는 웹서버 BUSY 상태에 있어서 여러분의 요청을 수행할수 없을 경우에 발생한다. 잠시 후에 다시 접근해 보도록 한다.

403.10: Forbidden
– 접근금지(설정이 확실 하지 않음)이 순간 웹 서버의 설정쪽에 문제가 있다.

403.11: Forbidden
– 접근금지(패스워드 변경됨)이 에러는 사용자 확인단계에서 잘못된 패스워드를 입력했을 경우 발생한다. 페이지를 갱신한 후 다시 시도해 본다.

403.12: Forbidden
– 접근금지(Mapper 접근 금지됨)여러분의 클이언트 인증용 맵이 해당 웹 사이트에 접근하는 것이 거부되었다. 사이트 운영자에게 클라이언트 인증 허가를 요청한다. 또한 여러분은 여러분의 클라이언트 인증을 바꿀 수도 있다.

404: Not Found
– 문서를 찾을 수 없음.웹 서버가 요청한 파일이나 스크립트를 찾지 못했다. URL을 다시 잘 보고 주소가 올바로 입력되었는지 확인해본다.

해결방법:
도구 ▶ 인터넷옵션 ▶ 일반 ▶ 쿠키삭제, 파일삭제, 목록지우기
도구 ▶ 인터넷옵션 ▶ 고급 ▶ [URL을 항상 UTF-8FH로 보냄] 체크 해제.

405: Method not allowed
– 메쏘드 허용안됨Request 라인에 명시된 메쏘드를 수행하기 위해 해당 자원의 이용이 허용되지 않았다. 여러분이 요청한 자원에 적절한 MIME 타입을 갖고 있는지 확인해 본다.

406: Not Acceptable
– 받아들일 수 없음요청 사항에 필요한 자원은 요청 사항으로 전달된 Acceptheader에 따라 “Not Acceptable”인 내용을 가진 Response 개체만을 만들 수 있다.

407: Proxy Authentication Required
– 대리(Proxy) 인증이 필요함해당 요청이 수행되도록 proxy 서버에게 인증을 받아야 한다. proxy서버로 로그온 한 후에 다기 시도해 본다.

408: Request timeout
– 요청시간이 지남

409: Conflict
– 보통 PUT 요청과 관계 있다. 보통 틀린 버전의 파일을 업로드할 경우 발생한다. (HTTP 1.1에서 새로 등장)

410: Gone
– 영구적으로 사용할 수 없음.

411: Length Required
– 클라이언트가 Content-Length를 보내지 않으면 서버가 처리할 수 없음.(HTTP 1.1에서 새로 등장)

412: Precondition Failed
– 선결조건 실패Request-header field에 하나 이상에 선결조건에 대한 값이 서버에서 테스트 결과 FALSE로 나왔을 경우에 발생한다. 현재 자원의 메타-정보가 하나 이상의 자원에 적용되는 것을 막기 위한 클라이언트 선결조건이 의도되어졌다.

413: Request entity too large
– 요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼. 만약 서버에서 나중에 다룰 수 있다고 생각 되면 Retry-After 헤더를 포함시켜야 한다. (HTTP 1.1에서 새로 등장)

414: Request-URI too long
– 요청한 URI가 너무 길다요청한 URI가 너무 길어서 서버가 요청 사항의 이행을 거부했다. 이렇게 희귀한 상황은 아래와 같은 경우에만 발생한다. 클라이언트가 긴 탐색용 정보를 가지고 POST 요청을 GET으로 부적절하게 전환했다. 클라이언트가 Redirection문제를 접하게 되었다. 서버가, 몇몇 서버가 사용하고 있는 요청한 URI 를 읽고 처리하는 고정된 길이의 메모리 버퍼를 이용해 보안체계에 들어가려는 , 클라이언트에 의한 공격을 받고 있다.

415: Unsupported media type
– 요청이 알려지지 않은 형태임(HTTP 1.1에서 새로 등장)

500: Internal Server Error
– 서버 내부 오류웹 서버가 요청사항을 수행할 수 없다. 다시 한 번 요청해 본다.

501: Not Implemented
– 적용안됨웹 서버가 요청사항을 수행하는 데 필요한 기능을 지원하지 않는다. 에러가 발생한 URL을 확인한 후에, 문제가 지속될 경우에는 웹 서버 운영자에게 연락한다.

502: Bad gateway
– 게이트웨이 상태 나쁨/서버의 과부하 상태Gateway나 proxy로 활동하고 있는 서버가 요구 사항을 접수한 upstream 서버로부터 불명확한 답변을 접수 했을 때 발생한다. 만약 문제가 지속된다면 웹 서버 운영자와 상의해 본다.

503: Service Unavailable
– 외부 서비스가 죽었거나 현재 멈춘 상태 또는 이용할 수 없는 서비스서버는 현재 일시적인 과부하 또는 관리(유지,보수) 때문에 요청을 처리할 수 없다.이것은 약간의 지연후 덜게될 일시적인 상태를 말한다.Retry-After 헤더에 지연의 길이가 표시하게 될지도 모른다.만약 Retry-After를 받지 못했다면 클라이언트는 500 응답을 위해 하고자 했는것처럼 응답을 처리해야 한다. 상태코드의 존재는 서버가 과부하가 걸릴때 그것을 사용해야한다는 것을 말하는 것이 아니다. 몇몇 서버는 접속을 거부하는 것을 바랄지도 모른다.

504: Gateway timeout
– 프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있다. 초기 서버가 원격 서버로부터 응답을 받을 수 없음을 나타낸다. (HTTP 1.1에서 새로 등장)

505: HTTP Version Not Supported

* Reference
http://ko.wikipedia.org/wiki/HTTP