트러블 슈팅을 위한 정보 파악 단계

A단계 : 사용자 현상 파악

• 503/500 에러
• 무응답/느린 응답
• 예상과는 다른 어플리케이션 동작 (예) 간헐적 인증 실패)

B단계 : 서버 상태 파악

• 어플리케이션 서버
• 메모리 사용률 (Swap 사용여부 )
• CPU 사용률
• Disk 용량, I/O
• 연계서버 상태 (Database 서버 등)

C단계: 어플리케이션의 정보 파악

• 어플리케이션 로그
• OOM 등 전형적인 Fatal 여러 발생여부
• 자주 발생하는 에러 스택
• WAS의 주요 설정
• 소스
• Stack Dump
• GC로그
• Heap Dump - 서비스 운영중에 덤프를 뜰 수 없음
• 실행경로 프로파일링

자주 만나는 해결 방식

해결유형1: 인프라 요소 설정 변경

어플리케이션의 로직과는 상관없이 공통적인 설정을 변경해서 해결하는 경우

Database 등 외부 Reosurce에서 병목이 있을 때 부적절한 설정 때문에  발생하는 경우가 많음.

사례

• A. 사용자가 몰릴 시 간헐적으로  느린 응답, 500, 503에러
• B. Swapping 영역 사용.
• C. 잦은 GC, OOM, Connection pool의 getConnection()에서 대기

해결책

• ConnectionPool

- DBCP : maxActive (maxTotal), maxWait (maxWaitMills), validation query

• JDBC : Socket timeout 등
• Web Server

- Apache Httpd : maxClients

• Web Application Server

- Tomcat: maxThreads, AJP connector의 backlog 값

• JVM : GC option

해결유형2: 메모리릭 경로 제거

사례

• C. 서버가 동작한지 오래되면 잦은 GC, OOM
• 주로 Cache 로직에서 발생

- 캐쉬 용량의 한도값이 적절한가?

- 모든 서버에 같은 현상이 궁극적으로는 생김.

• Thead 불안정성에 의한 메모리릭

- 일부 서버에만 OOM 발생

해결유형3: 무한 루프 경로 제거

사례

• B. 100%에 가까운 CPU 사용. 특정 서버에서만 발생하는 경우가 많음.
• C. 스택덤프를 뒤져보면 계속 실행 중인 스레드가 있음. 모든 CPU가 100%가 걸리면 덤프조차 못 뜰수 있음.
• 특정 조건이 들어왔을때 혹은 Thread 불안정성 때문에 생기는 무한루프가 많음.

- 부조건 무한루프였으면 개발할때 모를리가 없음.

• 잘못된 정규식에서 발생한 사례도 있음

Thread Dump 생성 방법

• Unix : kill -3 [PID]

• window : Ctrl + Break

• 공통 :  jstack [PID]

• 반드시 생성시 3~5회 연속으로 생성하여 문제 상황에 대한 변화 과정을 확인

Thread Dump 정보

• tid (Java-Level Thread ID )를 이용하여 정보 얻기

• ThreadMXBean을 이용하여 ThreadInfo 정보 획득 가능
• JMX 또는 REST API 등록으로 정보 획득을 가능하게 할 경우 문제 분석 용이
• tid와 threadId가 다른 경우도 존재하기 때문에 name으로 찾는 것이 좋음

•  - nid (Native Thread ID)를 이용하여 정보 얻기

• Linux  : ps -mo , ps - Elf 이용

Thread 상태

 Thread Dump - BLOCKED State ( synchronized )

Thread Dump - BLOCKED State - DEADLOCK

1. 재시작후 Thread  dump를 주기적으로 생성

2. 장애 원인 확인

2. 요청이 증가하는 경우 장애가 발생하지는 않지만 응답시간이 느려지는 현상

1. Thread Dump  생성후 TDA로 분석

4. log4j 문서 확인

3. 요청이 증가한 매우 간헐적으로 CPU가 100%로 폭증 이후 요청량이 줄어들어도 CPU 사용량은 줄어들지 않고 재시작후 정상으로 돌아오는 현상

1. CPU를 많이 사용하는 Thread 확인 - ps -mo 명령어를 통하여 CPU를 사용하는 lwp ( Light Weight Process) 확인

2. 16진수로 변경된 Thread Id를 이용하여 Thread Dump 검색

CDN(Contents Delivery Network)의 정의

- 대용량 또는 사용자의 잦은 요청이 있는 컨텐츠들을 Cache 서버에 분산 배치하여 컨텐츠의 전송 중 발생하는 트래픽 집중 & 병목현상 및 데이터 손실을 해결하기 위해 등장한 컨텐츠 전송 기술 ( 느린 응답속도/다운로딩 타임을 극복하기 위한 기술 )

CDN의 작동 원리

1.  웹 브라우저가 실행되는 디바이스인 PC나 모바일 기기의 사용자 에이전트가 특정 주소에 접근하여 HTML, 이미지, CSS, JavaScript 파일 등 렌더링하는 데 필요한 콘텐츠를 서버로부터 요청

2. DNS는 콘텐츠에 대한 각 요청이 발생하면 End User와 가장 가까운 위치에 최적으로 배치된 CDN 서버에 End User가 매핑되고, 해당 서버는 요청된 파일의 캐싱된(사전 저장된) 버전으로 응답(전송). 

3. 서버가 파일을 찾는 데 실패하는 경우 CDN 플랫폼의 다른 서버에서 콘텐츠를 찾은 다음 End User에게 응답을 전송. 콘텐츠를 사용할 수 없거나 콘텐츠가 오래된 경우, CDN은 오리진 서버에 대한 요청 프록시로 작동하여 향후 요청에 대해 응답할 수 있도록 Patch된 새로운 콘텐츠를 저장

CDN의 구성 요소 

- CDN 서버 : 컨텐츠 저장, 최종 사용자에게 스트리밍 서비스 

- Contents 분배 : 지정된 컨텐츠를 스케쥴에 따라 지정된 CDN 서버에 전송하여 최신 컨텐츠 버전을 유지함. 

- GLB라우터 : 지역적으로 분산되어 설치된 여러 CDN 서버를 사용자와 가장 가까운 CDN서버에서 사용자가 서비스 받을 수 있도록 하는 라우터 

- CDN관리 및 모니터링 SW : 분산되어 있는 CDN서버를 중앙에서 관리, 장애상황 대처

CDN기술요소 

- Contents Sync : CP의 웹컨텐츠 중 변경된 내용이 있다면 CDN서버와 Sync

- Caching 기술 : 자주 사용되는 파일 캐쉬 서버에 저장  

    -  Pull 모델 - ISP들의 POP지점에 Cache서버 배치 

    - Push 모델 = 캐쉬서버를 웹서버 앞에 위치 

- Load Balancing : 서버사이의 트래픽 향상

    - Product-Based 솔류션 : 기업 소유 형태

    - Service-Based 솔류션 : 아웃소싱 형태 

- Streaming 기술 : 실시간으로 사용자가 원하는 컨텐츠 전송 기술

     - Multicasting Streaming : 동시에 많은 고객

     - On-demand Streaming : 주문형 서비스

CDN 캐싱 방식의 종류

- Static Caching

– 사용자의 요청이 없어도 Origin Server에 있는 Content를 운영자가 미리 Cache Server에 복사함

– 따라서 사용자가 Cache Server에 접속하여 Content를 요청하면 무조건 그 Content는 Cache Server에 있음! (100% Cache Hit)

– 대부분의 국내 CDN에서 이 방식을 사용함 (예. Pooq 동영상 스트리밍/다운로드, NCSOFT 게임파일 다운로드 등)

Dynamic Caching

– 최초 Cache Server에는 Content가 없음

– 사용자가 Content를 요청하면 해당 Content가 있는지 확인하고, 없으면(Cache Miss) Origin Server로 부터 다운로드 받아(Cache Fill) 사용자에게 전달해 줌

– 이후 동일 Content를 요청 받으면 저장(캐싱)된 Content를 사용자에게 전달(Cache Hit)

– 각 Content는 일정 시간(TTL)이 지나면 Cache Server에서 삭제될 수 있고, 혹은 Origin Server를 통해 Content Freshness 확인 후에 계속 가지고 있을 수 있음

–  Akamai, Amazon과 같은 Global CDN 업체, 그리고 Cisco나 ALU의 통신사업자향 CDN 장비 솔루션에서 이 방식을 지원함

CDN 도입효과

- CP측면 : Web성능향상, 다양한 멀티미디어 제공, 비용절감, QoS증가

- ISP측면 : Performance 향상, 사용자 만족도 향상 

- User측면 : QoS확보된 서비스 제공, 다양한 컨텐츠 서비스

참고 

https://blog.naver.com/paninfo/10139797986

https://cdn.hosting.kr/cdn%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94/

http://brainwave.tistory.com/82

https://idchowto.com/?p=16938

http://i5on9i.blogspot.com/2014/05/cdn-proxy-server.html

https://www.kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=231&dbnum=127531&mode=detail&type=techreport

DNS란 

• www.example.com과 같이 사람이 읽을 수 있는 이름을 192.0.2.1과 같은 숫자 IP 주소로 변환하여 컴퓨터가 서로 통신할 수 있도록 한다. 
• 인터넷의 DNS 시스템은 이름과 숫자 간의 매핑을 관리하여 마치 전화번호부와 같은 기능
• DNS 서버는 이름에 대한 요청을 IP 주소로 변환하여 최종 사용자가 도메인 이름을 웹 브라우저에 입력할 때 해당 사용자를 어떤 서버에 연결할 것인지를 제어한다. 이 요청을 쿼리라고 한다.

Domain 구조

• 인터넷상에서 사용되는 도메인은 전 세계적으로 고유하게 존재하는 이름
• 정해진 규칙 및 체계에 따라야 하며, 임의로 변경되거나 생성될 수 없음.
• 인터넷상의 모든 도메인은 ".(dot)" 또는 루트(root)라 불리는 도메인 아래에 그림과 같이 나무를 거꾸로 위치시킨 역트리(Inverted tree)구조로 계층적으로 구성되어 있음
• 루트 도메인 바로 아래의 단계를 1단계 도메인 또는 최상위도메인(TLD, Top Level Doamin)이라고 부르며, 그 다음 단계를 2단계 도메인(SLD, Second Level Domailn)이라고 함
• 도메인은 일반최상위도메인(gTLD: Generic Top Level Domain)과 국가최상위도메인(ccTLD: Country Code Top Level Domain)로 구분할 수 있으며 여기서 일반최상위도메인은 다시 스폰서도메인(Sponsored TLD)과 언스폰서도메인(Unsponsored TLD)으로 구분됩니다.
• 
  



• 
  

HTTP/1.1 동작 방식

• HTTP/1.1는 기본적으로 Connection당 하나의 요청을 처리 하도록 설계
• 동시 전송이 불가능하고 요청과 응답이 순차적으로 이뤄짐
• HTTP 문서 안에 포함된 다수의 리소스 (Images, CSS, Script)를 처리하려면 요청할 리소스 개수에 비례해서 Latency(대기 시간)는 길어짐

HTTP/1.1 단점

HOL (Head Of Line) Blocking - 특정 응답의 지연

• HTTP의 HOL Blocking
• TCP의 HOL Blocking

  - HTTP/1.1의 connection당 하나의 요청 처리를 개선할 수 있는 기법 중 pipelining이 존재 

- Connection을 통해서 다수개의 파일을 요청/응답 받을 수 있는 기법

예 ) 하나의 TCP연결에서 3개의 이미지( a.png, b.png, c.png )를 얻으려고 하는 경우 HTTP의 요청 순서.

| --- a.png --- |

            | --- b.png --- |

                        | --- c.png --- |

순서대로 첫번째 이미지를 요청하고 응답 받고 다음 이미지를 요청하게 되는데 만약 첫번째 이미지를 요청하고 응답이 지연되면 아래 그림과 같이 두, 세번째 이미지는 당연히 첫번째 이미지의 응답 처리가 완료되기 전까지 대기하게 되며 이와 같은 현상을 HTTP의 HOB (Head of Line Blocking) 이라 부르며 pipelining의 큰 문제점 중 하나이다.

| ------------------------------- a.png ------------------ |

                                                                                       | -b.png- |

                                                                                                 | --c.png-- |

RTT( Round Trip Time ) 증가

• 일반적으로 하나의 connection에 하나의 요청을 처리
• 그렇기 때문에 매 요청별로 connection을 만들게 되고 TCP상에서 동작하는 HTTP의 특성상 3-way Handshake 가 반복적으로 일어나고 또한 불필요한 RTT증가와 네트워크 지연을 초래하여 성능을 저하 시킴

SPDY 등장

• HTTP/1.1 단점을 근본적으로 해결되지 않음
• 구글은 더 빠른 Web을 실현하기 위해 throughput 관점이 아닌 Latency 관점에서 HTTP를 고속화한 SPDY(스피디) 라 불리는 새로운 프로토콜을 구현
• SPDY는 HTTP를 대치하는 프로토콜이 아니고 HTTP를 통한 전송을 재 정의하는 형태로 구현 

SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여줬고 이는 HTTP/2 초안의 참고 규격이 됨

HTTP/2 등장

• HTTP가 유선 상에서 표현 방법을 대치 하는 것
• 성능에 초점
• 최종 사용자가 대기 시간, 네트워크 및 서버 리소스 사용을 인식
• 하나는 브라우저에서 웹 사이트로의 단일 연결을 허용하는 것

HTTP/2 주요 특징

Multiplexed Streams

• 한 커넥션으로 동시에 여러 개의 메세지를 주고 받을 있으며, 응답은 순서에 상관없이 stream으로 주고 받음
• HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선

Stream Prioritization

클라이언트가 요청한 HTML문서 안에 CSS파일 1개와 Image파일 2개가 존재하고 이를 클라이언트가 각각 요청하고 난 후 Image파일보다 CSS파일의 수신이 늦어지는 경우 브라우저의 렌더링이 늦어지는 문제가 발생하는데 HTTP/2의 경우 리소스간 의존관계(우선순위)를 설정하여 이런 문제를 해결

Server Push

• 서버는 클라이언트의 요청에 대해 요청하지도 않은 리소스를 보내줄 수 있음
• 클라이언트(브라우저)가 HTML문서를 요청하고 해당 HTML에 여러 개의 리소스(CSS, Image...) 가 포함되어 있는 경우 HTTP/1.1에서 클라이언트는 요청한 HTML문서를 수신한 후  HTML문서를 해석하면서 필요한 리소스를 재 요청하는 반면 HTTP/2에서는 Server Push기법을 통해서 클라이언트가 요청하지 않은 (HTML문서에 포함된 리소스) 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화 해서 성능 향상을 이끌어 냄
• PUSH_PROMISE 라고 부르며 PUSH_PROMISE를 통해서 서버가 전송한 리소스에 대해선 클라이언트는 요청을 않음

Header Compression

HTTP/2는 Header 정보를 압축하기 위해 Header Table과 Huffman Encoding 기법을 사용하여 처리하는데 이를 HPACK 압축방식이라 부르며 별도의 명세서(RFC 7531)로 관리.

위 그림처럼 클라이언트가 두번의 요청을 보낸다고 가정하면 HTTP/1.x의 경우 두개의 요청 Header에 중복 값이 존재해도 그냥 중복 전송한다. 하지만 HTTP/2에선 Header에 중복값이 존재하는 경우 Static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고 중복된 Header는 index값만 전송하고 중복되지 않은 Header정보의 값은  Huffman Encoding 기법으로 인코딩 처리 하여 전송한다.

참고

https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/

http://americanopeople.tistory.com/115

https://developers.google.com/web/fundamentals/performance/http2/?hl=ko

https://kemptechnologies.com/solutions/http2/

아래 아티클을 번역

https://www.spiceworks.com/it-articles/troubleshooting-steps/ 

1 단계 : 문제가 정확히 무엇입니까?

문제의 진상을 파헤치는 것은 때때로 "스무고개 게임"을 하는 것처럼 느껴질 때가 있다. 즉 근본적인 문제를 빨리 발견하고 싶다면 무엇보다도 올바른 질문을 하는 것이 중요하다.

• 다른 사람과 대화하거나 전자 메일을 주고받는 경우 주의 깊게 듣거나 읽고 메모하세요(상대방의 의중 또는 기타). 작업이 완료되면 "예/아니오"로 대답하거나 정량적으로 답변할 수 있는 질문을 진행합니다(예: "이 일이 몇 번이나 발생했습니까?"). 이 접근은 상황을 움직이고 애매한 반응을 줄일 수 있다.
• 무엇을 물어야 할까요? 핵심은 문제의 "누가, 무엇을, 언제"를 찾아내는 것입니다. 이 문제가 한 사람에게만 영향을 미치는지 아니면 많은 사람에게 영향을 미치는지? 컴퓨터나 네트워크에서 중요한 이벤트가 발생한 직후에 발생 했습니까? "이메일을 보낼 수 없습니다."와 같은 일반적인 문구 아래에 자세히 설명하도록 요청할 수 있는 구체적인 질문이 있습니다. PC나 모바일 장치를 사용하고 있습니까? PC 전원이 켜져 있습니까? 전자 메일 클라이언트를 열 수 있습니까? 이메일을 보내거나받을 수 있습니까?
• 일단 여러분이 이 문제에 대해 이해하게 되면, 그 문제에 대한 당신의 이해를 되풀이하여 같은 페이지에 무엇이 잘못되었는지 확인하십시오. 그들이 사용하는 것과 동일한 언어를 사용하고 복잡한 기술 용어를 사용하는 것을 피하는 것은 좋은 생각이다. 이렇게 하는게 이상적으로 문제와 관련된 잠재적인 혼란을 제거하는 데 도움이 됩니다.

이제 문제의 본질에 대한 기본적인 이해를 하셨으니, 해결 방법을 찾을 수 있는 기술적인 세부 사항을 살펴보실 수 있습니다.

2 단계 :  자세한 정보 수집, 변수 제거

많은 경우에서 일반적인 문제로 보고 된 내용(예 : 인터넷이 다운 됨)은 사실 특정 웹 사이트가 오프라인 상태 인 것과 같이 매우 특별한 것입니다. 이것을 알아내는 가장 좋은 방법은 무엇일까요? 적절한 질문을 한 후 다음과 같은 다양한 출처에서 더 많은 정보를 찾아보십시오.

• 에러 메시지 : 사용자가 에러를 보고하거나 우리가 에러를 확인하려고하는 경우, 에러가 발생한 이유에 대해 정확한 이유를 알려줄 수 있습니다. 예를 들어, Windows(윈도우)의 파란 화면은 고장 원인에 대한 적절한 오류 코드를 제공합니다.
• 이벤트 로그 : 존재하고 있습니까, 그렇다면 정확히 어떻게 적혀 있습니까? 에러 메시지 외에도 로그는 타임 스탬프를 제공하므로 정확한 이벤트가 언제 발생했는지에 대한 질문에 대답 할 수 있습니다. Windows 이벤트 뷰어를 확인하면 관련 로그를 찾을 수 있는 첫 단계가 될 수 있습니다.
• 사용자가 문제 해결 프로세스에 도움이 될 수 있는 스크린샷, 비디오 또는 기타 지원 정보를 제공할 수 있습니까?
• 진단 결과: 스템 유틸리티를 실행하여 추가 정보를 얻었습니까? 예를 들어: ping은 해당 서버 또는 웹 사이트에 연결할 수 있는지 원격으로 확인하는 데 도움이 됩니다. 또한 Windows 메모리 진단은 오류가 있는 메모리를 확인할 수 있으며, 리소스 모니터 또는 성능 모니터는 비정상적으로 높은 CPU나 메모리 사용량을 확인할 수 있으며, 디스크 검사로 하드 드라이브에 오류가 있는지 검사할 수 있습니다.
• 모니터링 : 문제가 발생하기 전에 더 많은 단서를 제공하거나 문제를 예측할 수있는 모니터링 툴이 있습니까? Spiceworks와 같은 네트워크 모니터링 솔루션은 다운 될 위험이있는 서버에 대한 (사전)경고를 제공합니다. 또한 네트워크 인벤토리 응용 프로그램은 디스크 공간, 사용 가능한 메모리, 설치된 OS 및 해당 devies에서 실행중인 소프트웨어와 같은 수십 또는 수백 개의 시스템에 대한 중요한 통계를 제공 할 수 있습니다.

3 단계 : 문제를 재현하고 근본 원인에 대한 가설을 세웁니다.

이제 기본 배경 정보를 수집했으므로 이제 문제를 직접 해결할 때입니다. 문제를 재현하는 것은 사용자가 보고한 것과 동일한 에러를 재현할 수 있음을 확인하는 것을 의미합니다. 이 작업은 문제가 되는 실제 사이트에서 또는 원격 데스크톱/원격 제어 응용 프로그램을 통해 수행할 수 있습니다. 이러한 옵션을 사용할 수 있습니까? 당신은 유사한 컴퓨터 환경에서 동일한 조건을 비슷하게 만들 수 있을 것입니다.

같은 오류가 발생하면 관찰 한 내용을 바탕으로 근본 원인에 대한 이론을 보다 쉽게 ​​개발할 수 있으며 문제를 해결하기 위한 조치를 취하기 시작할 수 있습니다. 때로는 범인을 (솔루션을 생각해내는 것) 빨리 찾아 낼 수도 있을 겁니다. 가설과 다른 경우에는, 시간이 더 오래 걸릴 것이고, 가지고 있는 여러 지식을 파고들어야 할 수도 있고, 오래된 헬프 데스크 티켓들을 뒤적거리거나, 같은 문제에 직면한 다른 사람들의 해결책을 찾기 위해서 구글을 검색해야 할 수도 있다.

이 단계에서 컴퓨터의 작동 방식에 대한 깊은 이해가 입증될 것입니다. 예를 들어, 컴퓨터 네트워킹에서 네트워크에 대한 7계층 OSI 모델을 이해하는 경우(이 중 하나에 문제가 존재할 수 있음), 네트워킹 문제의 잠재적인 원인을 체계적으로 처리할 수 있는 프레임워크가 있습니다. 연결 문제의 경우 이더넷 케이블이 손상되거나 또는 분리되거나(Layer 1 문제), 네트워크 요청이 수행되지 않거나(Layer 3),  응용 프로그램이 제대로 코드화되지 않을 수 있습니다(Layer 6).

4 단계:발견한 결과를 기반으로 해결 시도

이미 수집한 증거는 근본 원인의 가능성이 있는 부분으로 좁혀갈 수 있고, 문제를 해결 할 수 있는 부분을 지적하고 있어야 한다. 이 시점부터는 초점을 맞추고 실험을 해야 할 단계이다. 문제와 관련된 변경 설정 변경, 문제가 있는 부분 교체, 손상된 파일을 복구, 드라이버와 소프트웨어 업데이트 등을 문제가 해결될 때까지(또는 최소한 가까워질 때까지) 시도해 볼 수 있습니다.

아직도 엉망진창? 모든 것이 정상적으로 작동하면 언제든지 기계를 다시 복원할 수 있습니다. 다시 말하면, 문제가 발생하기 전에 누군가가 데이터 또는 시스템 상태를 백업하는 매우 중요한 단계를 밟았을 때 문제가 발생하기 전의 정상적인 PC로 돌아갈 수 있습니다.

모든 문제는 고유한 눈송이와 유사하지만 문제 있는 시스템 재부팅, DNS 및 DHCP 문제 확인, 장치 관리자 드라이버 문제 확인, 시스템 정리 또는 방화벽 설정 확인 등의 일반적인 문제 해결 단계를 통해 많은 문제를 해결할 수 있습니다. 더 어려운 문제의 경우, 각자의 여러가지의 시도와 Google 검색 결과가 만족스럽지 않을 경우 Spiceworks와 같은 IT 포럼에서 토론을 검색하는 것이 PC 문제를 해결하는 데 매우 유용할 수 있습니다. 아무것도 나타나지 않으면 언제든지 Spiceworks의 수백만 명의 IT 전문가 커뮤니티에 문의할 수 있습니다.

문제가 해결 되었나요? 미래의 문제를 준비하세요

기본적인 기술 문제(네트워크 문제, 드라이버 충돌, 디스크 문제 등)가 무엇이든 간에, 위에 설명된 프로세스는 정보 수집, 문제의 가능한 원인 확인, 문제 발생 시 솔루션을 찾는데 적합합니다. 하지만 여전히 각각의 독특한 사례에 따라 판단을 내려야 할 것입니다.

이런 종류의 시스템을 마련하고, 이전의 컴퓨터 문제를 통해 학습된 지식을 통해 여러분은 더 많은 경험을 쌓을 때 더 효율적으로 컴퓨터 문제를 해결할 수 있을 것입니다. 또한 향후 위기를 사전에 방지하기 위해 유사한 문제에 직면한 모든 사용자가 참조할 수 있도록 문제를 문서화할 수 있습니다.

참고

https://b.luavis.kr/server/linux-performance-analysis

https://www.spiceworks.com/it-articles/troubleshooting-steps/

Container란 무엇인가?

사전적 의미로 컨테이너는 어떤 물체를 격리하는 공간을 뜻합니다. 클라우드에서 컨테이너는 어떤 의미를 가질까요? 컨테이너는 애플리케이션과 애플리케이션을 구동하는 환경을 격리한 공간을 뜻합니다. 컨테이너 기술은 약 10여 년 전에 리눅스에 내장된 기술로 소개되었으며, 현재는 차세대 트렌드 기술로 주목받으며 클라우드 서비스 환경에 적용되고 있습니다.

왜 Container인가?

1)   Virtual Machine과 Container의 차이점

Virtual Machine Server에서는 Hypervisor로 하드웨어를 가상화 하고, 그 위에 Guest OS가 설치된 Virtual Machine들을 구동 시켰다. 반면에 Container Server는 운영체제 레벨에서 CPU, RAM, Disk, Network 등의 자원을 격리하여 Container에 할당하기 때문에 게스트 OS가 따로 필요 없다.

2)   효율성
안정적인 운영을 위해, 1개의 가상머신(VM, Virtual Machine)에 1개의 서비스를 구동하는 것이 권장된다. 이의 경우 가상머신의 모든 자원을 사용하는 것이 아니기 때문에 성능적 오버헤드가 발생한다. 반면 컨테이너의 경우, OS 커널을 공유하기 때문에 자원을 필요한 만큼 효율적으로 사용할 수 있다.

3)   신속성
사용자의 서비스 request traffic이 증가함에 따라, 가상머신이나 컨테이너를 추가적으로 배포한다. 가상머신의 크기는 최소 몇 GB이지만, 컨테이너의 경우 Guest OS가 없어 MB단위의 크기를 가진다. 결과적으로 가상머신은 배포하는데 수 분에서 수십 분의 시간이 소요되지만, 컨테이너는 배포에 소요되는 시간이 수 초에 불과하다.

4)   라이센스 비용 절감
가상화 서버의 경우 가상머신의 개수만큼 Guest OS의 라이센스 비용이 발생한다. 반면에 컨테이너 서버의 경우 Host OS 1대의 라이센스 비용만 발생한다. 만약 서버의 수가 많아진다면 비용의 차이도 기하급수적으로 증가할 것이다.

5)   안정성
가상머신의 경우 정확히 할당된 자원 내에서 가상머신이 운영되기 때문에, 컨테이너에 비해 안정적으로 운영할 수 있다. 반면에 컨테이너들은 OS 커널을 공유하기 때문에, 하나의 컨테이너가 무리하게 자원을 사용하게 될 수 있다. 자원 할당량을 사전에 지정 시켜줄 수 있지만, 만약 이런 상황이 발생하면 컨테이너에 장애가 발생 한다. 이런 컨테이너의 문제는 뒤에 등장할 쿠버네티스 등과 같은 Container 오케스트레이션 툴로 해결할 수 있다.

https://developer.ibm.com/kr/cloud/2018/01/12/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EC%99%80-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88%EB%A5%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/

https://www.backblaze.com/blog/vm-vs-containers/

HTTP란 ?

- HyperText Transfer Protocol의 준말로 링크 기반으로 데이터를 요청하고 받겠다는 것

- 클라이언트와 서버가 요청을 하고 응답을 하기 위해 따르는 프로토콜

- HTML 문서를 주고 받을 수 있음, 뿐만 아니라 이미지, 동영상, 오디오, 텍스트 문서 등을 주고 받을 수 있음

 

HTTP 동작 방식

- 클라이언트 : 웹어플리케이션의 경우 브라우저를 통해서 서버에 요청 ( 프로토콜 + 도메인 + URI )

- 서버 : 클라이언트로부터 받은 요청을 내부적으로 처리하여 그에 대한 결과를 응답

 

HTTP 특징 및 기능

1) connectionless + stateless

- 1번 요청-응답 후 연결을 해제

- 클라이언트의 이전 상태를 알 수 없음 : 쿠키와 세션(클라이언트와 서버의 이전 상태 정보 저장)이 필요함

- 수십만 명이 웹서비스를 사용(요청)하더라도 최소 유지를 할 수 있기 때문에, 많은 유저의 요청을 처리할 수 있음

 

2) keep-alive : HTTP 1.1부터 지원하는 기능

- HTTP는 1번의 요청에 대해 1번의 응답 하는 것을 기준으로 설계

- 웹사이트는 하나의 페이지에 수십 개 이미지, css 파일, js 파일들로 구성

- 1 요청 1응답 기준이라면 여러 번 연결을 끊었다 붙였다 해야해서 비효율적

- keep-alive 지원으로 지정된 시간 동안 연결을 끊지않고 연결된 상태를 유지할 수 있음

- keep-alive의 time out 내 클라이언트가 재 요청하면 새로운 연결이 아닌 기존 연결된 것을 이용함

1) 웹서버 연결

2) HTML 문서 다운로드

3) 필요한 img, css, js 등 다운로드

4) 연결 끊음

- 아래는 네이버 페이지에 대한 요청 헤더임 

             

HTTP method 그리고 REST API

메소드란?

요청의 종류를 서버에 알리기 위해 사용하는 것, 게시판 기능(CRUD, REST API)을 만들 때 사용

 

메소드 종류

1) GET : 정보를 요청하기위해 사용(Read)

2) POST : 정보를 입력하기위해 사용(Create)

3) PUT : 정보를 업데이트하기위해 사용(Update)

4) DELETE : 정보를 삭제하기위해 사용(Delete)

 

REST API란?

 -  HTTP 프로토콜 장점을 살릴 수 있는 네트워크 기반 아키텍처

 -  REST API을 구현하기위해 HTTP method + 모든 개체 Resource화 + URL 디자인(라우팅) 필요

 - 라우팅이란? 클라이언트의 요청에 대한 결과(응답)을 어떻게 이어줄 것인가를 처리하는 것

 - URI를 이용한 접근 : 모든 개체를 리소스로 보고, 리소스에 고유번호를 부여

 - URL 디자인 원칙 : 자원에 대한 처리를 주소에 나타내지않는다(HTTP method는 내부적으로 처리하도록), 어떤 자원인지 주소에 명확하게 나타냄

 - REST API를 구현하기위해 HTTP 프로토콜에 대한 이해, method 종류, 라우팅에 대한 이해가 있어야함

 - HTTP method를 클라이언트가 필요한 처리에 맞게 선택하여 서버에 요청

l  API의 본질은 무엇인가 -> Decoupling, 탈 동조화

l  그렇다면 Web API의 본질은 무엇인가 -> Decoupling + Platform Agnostic

※ Platform Agnostic 이란? 

   플랫폼에 종속적이 않음을 뜻한다. 즉, 특정 기기나 OS에서만 돌아가는 것이 아닌 광범위하게 사용될 수 있는 것.

ex) 데이터 파일(텍스트파일, 그래픽 파일, 음원파일)은 윈도우든 OS X 든 안드로인드든 어디에서도 잘 돌아가니까.

 

REST하다는 것은?

REST(REpresentational State Transfer)란, "웹에 존재하는 모든 자원(이미지, 동영상, DB 자원)에 고유한 URI를 부여해 활용"하는 것으로, 자원을 정의하고 자원에 대한 주소를 지정하는 방법론을 의미한다고 한다. 따라서 RESTful API는 REST 특징을 지키면서 API를 제공하는 것을 의미한다.

Roy Fielding에 의해 처음 쓰인 용어(필딩 논문)로써 일반적인 웹(혹은 유사한)을 만들기 위한 제약 조건들을 나열하여 제안한 일종의 디자인 가이드이다.  

" 현재 아키텍처가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했기 때문에, 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처를 소개한 것이 Representational state transfer(REST) 이다."

HTTP 1.0이후 웹의 성공으로 인해 HTTP 프로토콜의 의도에 맞지 않은 사용으로 인한  확장성이나 유지보수성이 좋지 않은 웹이 늘어나면서 다시 한번 주목을 받게 되었다. 아래 설명할 6가지 조건을 “REST”라고 하며 이를 잘 지키는 서비스 디자인을 보고 RESTful하다고 한다.

l  Uniform Interface

l  Client-Server

l  Stateless

l  Cacheable

l  Layered System

l  Code on Demand(optional)

REST 구성

REST 요소를 파악하는 데는 Richardson Maturity Model(RMM)을 기준으로 이해하는 것이 좋은 것 같다.

 

LEVEL 0

웹의 기본 메커니즘을 전혀 사용하지 않는 단계로, HTTP를 통해 데이터를 주고받지만 모든 데이터 요청 및 응답과 관련한 정보를 HTTP의 body 정보를 활용한다. POX(Plain Old XML)로 요청과 응답을 주고받는 RPC 스타일 시스템이다. 이 때 HTTP method는 POST만 사용하며, 특정 서비스를 위해 클라이언트에서 접근할 endpoint는 하나이다.

즉, 하나의 URI을 가지고, 하나의 HTTP method(mainly POST)를 사용한다. 내용에 대한 구분은 XML을 Payload로 사용해서 요청을 구분하는 방식을 취한다.  모든걸 하나의 리소스를 가지고 처리한다.

LEVEL 1 – RESOURCE

RMM에서 REST를 위한 첫 단계는 리소스를 도입하는 것이다. 그래서 이제는 모든 요청을 단일 서비스 endpoint로 보내는 것이 아니라, 개별 리소스와 통신한다.

POST /doctors/mjones HTTP/1.1 ​[various other headers] ​<openSlotRequest date = "2010-01-04"/>

즉, 함수를 호출하고 인자들을 넘기는 것이 아니라 다른 정보를 위해 인자들을 제공하는 특정 리소스로 요청을 보낸다. 이럴 경우의 이점은 자원이 외부에 보여지는 방식과 내부에 저장되는 방식을 분리 할 수 있다는 것이다.

예를 들면 클라이언트 단에서 완전히 다른 포맷으로 저장하더라도 JSON 형태의 데이터를 요청할 수 있다. 다양한 URI를 사용하지만 HTTP method는 하나만 사용한다. 그나마 URI를 통해 요청이나 파라미터를 명시한다.

 

LEVEL 2 - HTTP Method

LEVEL 1의 URL + HTTP Method 조합으로 리소스를 구분하는 것으로 응답 상태를 HTTP Status code 를 활용한다. 현재 가장 많은 Restful API가 이 단계를 제공한다.

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1 Host: royalhope.nhs.uk

 

발생한 에러의 종류를 커뮤니케이션하기 위해 상태 코드(status code)를 사용하는 것, 그리고 안전한 오퍼레이션(GET 등)과 안전하지 않은 오퍼레이션 간의 강한 분리를 제공하는 것이 레벨 2의 핵심 요소이다.

우선, Status Code를 사용한다는 것은 어떤 의미일까?

기존에는 유저 생성 요청을 했을 경우 302 등의 Redirect Request을 서버에서 내려주는 방식이었다면, 지금은 201(created)로 유저 생성 성공을 알릴 뿐 페이지 이동은 Client 단에서 해결하는 방식이다. (login의 경우 성공은 200, 실패 시 인증 실패는 401, 성공했으나 권한 문제시엔 403 등) 즉, 서버는 순수하게 api로서의 기능만을 제공하게 된다. View는 Client에서 알아서 표시한다.

두번째로, 강한 분리를 제공하는 것이 어떤 이점이 있는 것일까?

HTTP에서 GET은 멱등방식(Idempotent )으로 자원을 추출하는데, 이 말은 호출 순서나 횟수에 영향 받지 않고 매번 같은 결과를 받을 수 있게 한다. 그렇기 때문에 모든 request에 '캐싱'기능을 지원하는 다양한 방법을 제공한다.

 ※ Idempotent(멱등)의 개념을 설명한 이유는 REST는 각 개별 API를 상태 없이 수행하게 된다.  따라서 해당 REST API를 다른 API와 함께 호출하다가 실패하였을 경우, 트랜잭션 복구를 위해서 다시 실행해야 하는 경우가 있는데,  Idempotent 하지 않은 메서드들의 경우는 기존 상태를 저장 했다가 다시 복원해 줘야하는 문제가 있지만, Idempotent한 메서드의 경우에는 반복적으로 다시 메서드를 수행해주면 됩니다.

   예를 들어 게시물 조회를 하는 API가 있을 때, 조회 시 마다 조회수를 올리는 연산을 수행한다면 이 메서드는 Idempotent 하다고 볼 수 없고, 조회하다가 실패 하였을 때는 올라간 조회수를 다시 -1 만큼 빼줘야 합니다. 즉 Idempotent 하지 않은 메서드에 대해서는 트랜잭션에 대한 처리에 특히 주의가 필요하다.

 

LEVEL 3 - HYPERMEDIA CONTROL

HATEOAS(Hypertext As The Engine Of Application State)

하이퍼미디어란 하나의 컨텐츠가 텍스트나 이미지, 사운드와 같은 다양한 포맷의 컨텐츠를 링크하는 개념이다. 이것은 관련 컨텐츠를 보기 위해 링크를 따라가는 방식과 유사한 방식으로 동작하는데, 클라이언트가 다른 자원에 대한 링크를 통해 서버와 (잠재적으로 상태 변이를 초래하는) 상호작용을 한다.

즉, 특정 API를 요청한 후 다음 단계로 할 수 있는 작업을 알려주는 것이며, 다음 단계의 작업을 위한 리소스의 URI를 알려주는 것이다. 이 단계를 적용하면 클라이언트에 영향을 미치지 않으면서 서버를 변경하는 것이 가능하다.

 

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1

Host: royalhope.nhs.uk

HTTP/1.1 200 OK
[various headers]
<openSlotList>
​
 <slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
            <link rel = "/linkrels/slot/book"
            uri = "/slots/1234"/>
 </slot>
 <slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
            <link rel = "/linkrels/slot/book"
            uri = "/slots/5678"/>
 </slot>
</openSlotList>

단점은, 클라이언트가 수행할 작업을 찾기 위해 링크를 따라가기 때문에 컨트롤 탐색에 꽤 많은 호출이 발생할 수 있다는 것이다. 또한 복잡성이 증가할 수 있으며, HTTP 요청 상에 나타나는 부하로 낮은 지연시간이 요구될 때 문제가 될 수 있다. HTTP 기반의 REST Payload는 JSON 또는 바이너리 등의 포맷을 지원하므로 실제로 SOAP 보다 훨씬 간결할 수 있지만 Thrift와 같은 바이너리 프로토콜에는 상대가 되지 못한다.

또한 WebSocket의 경우 HTTP 초기 handshake 후에 클라이언트와 서버 간에 TCP 접속이 이루어지고 브라우저에서 스트림 데이터를 보낼 때 효율적일 수 있다. 따라서 HTTP가 대규모 트래픽에는 적합할 수 있지만 TCP 또는 다른 네트워킹 기술 기반의 프로토콜과 비교하면 낮은 지연시간이 필요한 통신에는 그다지 좋은 선택이 아닐 수 있다.

이러한 단점에도 HTTP 기반의 REST는 서비스 대 서비스의 상호작용을 위해 합리적이고 기본적인 선택이다.

RMM을 통한 REST 핵심 요소

l  자원(RESOURCE) - URI  , 애플리케이션에서 제공하는 resource를 어떻게 분할하고 통합할 것인가?, ( LEVEL 1의 고민 )

l  행위(METHOD) - HTTP METHOD, STATUS CODE , 에러 상황에 대한 적절한 처리와 method 도입을 통한 불필요한 다양성(복잡성) 제거 (LEVEL 2의 고민)

l  표현(Representations) -  hypermedia, API가 스스로 문서화 가능하도록 지원할 것인가? ( LEVEL 3의 고민 )

 

REST의 특성

1.   Uniform Interface

REST는 HTTP 표준만 따른다면, 어떠한 기술이든 사용이 가능한 인터페이스 스타일이다. 

예를 들어 HTTP + JSON으로 REST API를 정의했다면, 안드로이드 플랫폼이건, IOS 플랫폼이건,  또는 C나 Java / Python 이건 특정 언어나  기술에 종속 받지 않고 HTTP와 JSON을 사용할 수 있는 모든 플랫폼에 사용이 가능한 느슨한 결합(Loosely Coupling) 형태의 구조이다.

 

※ 흔히들 근래에 REST를 이야기하면, HTTP + JSON을 쉽게 떠올리는데, JSON은 하나의 옵션일 뿐, 메시지 포맷을 꼭 JSON으로 적용할 필요는 없다. 자바스크립트가 유행하기전에만 해도 XML 형태를 많이 사용했으며, 근래에 들어서 사용의 편리성 때문에 JSON을 많이 사용하고 있지만, XML을 사용할 경우, XPath, XSL 등 다양한 XML 프레임워크을 사용할 수 있을 뿐만 아니라 메시지 구조를 명시적으로 정의할 수 있는 XML Scheme나 DTD등을 사용할 수 있기 때문에, 복잡도는 올라가더라도, 메시지 정의의 명확성을 더할 수 있다.   

리소스 식별

 각각의 리소스는 URI를 구분자로 식별이 가능해야 한다. 예를 들어, http://www.google.com은 구글의 메인 페이지를 나타낸다. TO-DO list 웹사이트를 예로 들자면 아래와 같을 것이다.

 

http://www.example.com/v2/tasks # 할 일들의 collection http://www.example.com/v2/tasks/2 # id 값이 2인 할 일 http://www.example.com/v2/tasks/14 # id 값이 14인 할 일

 

표현을 통한 리소스 처리

리소스 자체를 전송하는 것이 아닌 리소스의 표현을 전송한다. 

예를 들어, GET http://www.example.com/v2/apple 는 사과 그 자체(리소스)가 아닌 사과를 묘사한 표현를 전송한다. 리소스 자체가 아닌 표현을 사용함으로써 서버의 코드에 얽매이지 않고 client를 구현할 수 있고, 서버의 수정에 거의 영향을 받지 않는다.(최소한 영향을 줄일 수 있다.)  

예를 들어 Database에 있는 리소스를 요청할 경우에 Database에 있는 그대로 응답을 할 경우에는 추후 database scheme가 변경될 경우에 클라이언트가 영향을 받을 수 있어 수정에 제약이 걸릴 수도 있다.

 

자기 서술형 메시지 ( Self-descriptiveness )

REST는 메시지가 자신을 어떻게 처리해야 할 지에 대한 정보를 포함하고 있어야 한다. 즉 수신자가 이해하기 위한 모든 정보를 가지고 있어야 한다. 즉, API 메시지 자체만 보고도 API를 이해할 수 있는 Self-descriptiveness 구조를 갖는 다는 것이다. 

아래 내용을 로이 필딩의 논문에서 제시된 몇가지 예시다:

-       state-less 시스템에서 서버는 클라이언트의 요청을 처리했던 이력을 저장하지 않는다. 그렇기 때문에 각각의 요청에 해당 정보가 포함되어야 한다.

-       표준 method(GET, POST, DELETE, PUT)와 미디어 유형을 사용하여 별도의 설명 없이 명확하게 파악할 수 있도록 한다. 

-       PUT method를 사용할 경우 수정한다는 의미를 파악할 수 있고 Content-Type에 json이 명시되어 있을 경우 client는 response 메시지를 읽기 위한 방법을 알 수 있다.

-       Response에 캐시 가능성을 지정한다. Client가 아닌 server가 해당 내용을 header에 명시해야 한다.

 

하이퍼미디어 제약

어플리케이션의 상태는 하이퍼미디어에 의해 변경된다는 의미이다.

<!-- GET로 task들의 list를 가져오고 --> <a href="http://example.com/v2/tasks"/> <!-- POST로 task를 추가한다 --> <form action="http://example.com/v2/tasks"/>

 

위에서처럼 클라이언트의 하이퍼미디어에 의해 어플리케이션에 task가 추가되고 제거(상태 변화) 된다는 제약이다.

2.  Client-Server

서비스가 수행되길 기대하는 클라이언트 구성 요소는 연결자를 통해 서버에 요청을 보내며, 서버는 해당 요청을 거절하거나 수행하고 클라이언트에 응답을 보낸다. 그리고 모든 통신은 클라이언트-서버 간의 일대일로 연결된다.  

REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임진다. 클라이언트의 경우 사용자 인증이나 Context(세션, 로그인 정보)등을 직접 관리하고 책임 지는 구조로 역할이 나뉘어 지고 있다. 

 

 - 클라이언트는 서버의 자세한 사항에 대해서 신경 쓸 필요 없이(e.g., 데이터베이스) 제공되는 인터페이스를 통해 접근하여 응답을 받는다. 대신 자신의 Context를 관리한다.

- 서버는 클라이언트의 상태를 신경 쓰지 않고 제공한 인터페이스에 대한 처리만 담당하여 요청이 들어올 때 그에 맞는 응답을 제공한다.

 

이렇게 역할이 각각 확실하게 구분되면서, 개발 관점에서 클라이언트와 서버에서 개발해야 할 내용들이 명확하게 되고 서로의 개발에 있어서 의존성이 줄어들게 된다.

 

 

3.  Stateless

State가 있다/없다의 의미는 사용자나 클라이언트의 Context를 서버 쪽에 유지 하지 않는다는 의미로, 쉽게 표현하면 HTTP Session과 같은 Context 저장소에 상태 정보를 저장하지 않는 형태를 의미한다. 

상태 정보를 저장하지 않으면 각 API 서버는 들어오는 요청의 메시지로만 처리하면 되며, 세션과 같은 Context 정보를 신경 쓸 필요가 없기 때문에 구현이 단순해 진다.

다시 말하면, 각각의 요청 시에 클라이언트의 Context가 서버에 저장되지 않는다. 그렇기 때문에 위에서 언급한 자기 서술형 메시지가 지켜져야 한다. 이 조건을 지킨 서버는 요청에 대한 처리만 하면 되기 때문에 구현이 단순해 진다. 또한 URI에 해당 내용을 포함시키지 않음으로써 Caching 사용 범위가 넓어질 수 있다.

상태에 대한 정보는 클라이언트가 가지고 있고 서버는 전혀 신경쓰지 않는다. 만약 어떠한 상태가 너무 중요한 나머지 서버에 두어야 할 경우에는 Resource에 추가하는 것을 고려한다.

 

4.  Cacheable

자기 서술형 메시지 덕분에 각각의 요청에 대한 응답은 그 자체로 해석이 가능하다. 그렇기 때문에 독립적으로 처리가 가능한데, 이로 인해 Caching이 가능해진다. 다른 상황에 영향을 받았다면 Caching을 했을 경우 잘못된 결과가 나올 수 있다. 네트워크를 사용하는 비용이 가장 오래 걸리므로 이를 줄이는 것이 어플리케이션 성능을 향상시키는 좋은 방법이 될 수 있다.

 

# 첫번재 요청 GET /v2/tasks/2 # Reponse 200 OK Last-Modified: Sun, 03 Apr 2016 16:09:23 GMT # 두번째 요청 GET /v2/tasks/2 If-Modified-Since: Sun, 03 Apr 2016 16:09:23 GMT # Reponse 304 Not Modified # 기존의 데이터를 그대로 사용한다(이건 구현에 따라서 달라질 수 있다)

 

REST의 큰 특징 중의 하나는 HTTP라는 기존의 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존의 인프라를 그대로 활용이 가능하다. 

HTTP 프로토콜 기반의 로드밸러서나 SSL은 물론이고, HTTP가 가진 가장 강력한 특징 중에 하나인 캐싱 기능을 적용할 수 있다.

일반적인 서비스 시스템에서 60%에서 많게는 80% 가량의 트랜잭션이 Select와 같은 조회성 트랜잭션인 것을 감안하면, HTTP의 리소스들을 웹 캐시 서버 등에 캐싱하는 것은 용량이나 성능 면에서 많은 장점을 가지고 올 수 있다.

구현은 HTTP 프로토콜 표준에서 사용하는 "Last-Modified" 태그나 E-Tag를 이용하면 캐싱을 구현할 수 있다.

아래와 같이 Client가 HTTP GET을 "Last-Modified" 값과 함께 보냈을 때, 컨텐츠가 변화가 없으면 REST 컴포넌트는 "304 Not Modified"를 리턴 하면 Client는 자체 캐쉬에 저장된 값을 사용하게 된다.

 

이렇게 캐시를 사용하게 되면 네트워크 응답시간 뿐만 아니라, REST 컴포넌트가 위치한 서버에 트랜잭션을 발생시키지 않기 때문에, 전체 응답시간과 성능 그리고 서버의 자원 사용률을 비약적으로 향상시킬 수 있다.

 

- E-Tag : 메시지에 담겨있는 Entity를 위한 Entity 태그를 제공한다. 이를 활용하여 리소스를 식별할 수 있다.

- Last-Modified : Entity가 마지막으로 변경된 시각에 대한 정보를 제공한다. (파일인 경우 파일 시스템이 제공해 준 최근 변경 시각, 동적으로 생성된 리소스라면 응답이 만들어진 시간)

 

5.  Layered System

서버는 클라이언트가 모르게 API 서버에 여러 계층을 추가하여 유연한 구조로 개발될 수 있다. 클라이언트 입장에서는 REST API 서버만 호출한다. 그러나 서버는 다중 계층으로 구성될 수 있다.

순수 비즈니스 로직을 수행하는 API 서버와 그 앞 단에 사용자 인증(Authentication), 암호화(SSL), 로드밸런싱 등을 하는 계층을 추가해서 구조상의 유연성을 둘 수 있는데, 이는 근래에 들어서 앞에서 언급한 마이크로 서비스 아키텍쳐의 API Gateway나 간단한 기능의 경우에는 HA Proxy나 Apache와 같은 Reverse Proxy를 이용해서 구현하는 경우가 많다.

6.  Code on Demand(optional)

클라이언트는 리소스에 대한 표현을 응답으로 받고 처리해야 하는데, 어떻게 처리해야 하는지에 대한 Code를 서버가 제공하는 것을 의미한다. Html에서의 javascript가 가장 대표적인 예이다. 하지만 서버에서 제공되는 코드를 실행해야 하기 때문에 보안 문제를 야기할 수 있다.

참조

https://joonyon.tistory.com/13

https://brainbackdoor.tistory.com/53

https://meetup.toast.com/posts/92

http://bcho.tistory.com/m/321

http://amazingguni.github.io/blog/2016/03/REST%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%B4%ED%95%B4-1

http://jinbroing.tistory.com/96

https://blog.npcode.com/2017/04/03/rest%EC%9D%98-representation%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80/

 

Java의 Method Signature란

Java에서 메소드가 무엇인지 먼저 알아보자.

메소드는 일련의 코드를 포함하는 코드 블록으로 프로그램에서 파라미터를 지정하여 메소드를 호출하고 실행할 수 있다. Java에서 실행되는 모든 명령은 메소드의  Context에서 수행되며, main 메소드는 모든 Java 프로그램의 진입접으로 JVM(Java Virtual Machine)에 의해 호출된다. 

아래 간단한 메소드 예제이다.

메소드는 파라미터를 "()"로 묶고 ","로 구분한다. 빈 괄호는 메소드에 파라미터가 없다는 의미이지만 괄호를 생략할 수 없다.

또한 메소드는 클래서에서 public (공개), private(비공개), protect 와 같은 Access 수준과 abstract(추상), final(최종)과 같은 선택적 한정자, 반환값, 메소드 이름 및 메소드 파라미터를 지정하여 선언한다. 

이러한 메소드를 생성하기 위한 규칙들을 중 메소드의 이름과 파라미터 만을  메소드의 시그니처(Method Signature)라고 한다.

참고 : 

http://ngmaster.tistory.com/entry/151-Java-%EB%A9%94%EC%86%8C%EB%93%9C%EC%9D%98-%EC%8B%9C%EA%B7%B8%EB%8B%88%EC%B2%98-Methods-Signature

https://stackoverflow.com/questions/16149285/does-a-methods-signature-in-java-include-its-return-type