Today's Dev Notes(2019-01-09)

안녕하세요, Brad입니다. 오늘 과제가 있었는데요. 그 부분에 대해서 간략하게 정리해볼게요.

 

웹 클라이언트, 서버간 성능 개선

웹 자원 캐시

• 서버에서 Status Code 200 또는 304와 같은 상태값을 보낼 수 있는 방법은?

  • 이것은 API 만들 때 주로 써봤는데요. ResponseEntity 의 매개변수로 HttpStatus.OK 또는 HttpStatus.FOUND 를 통해 명시적으로 넘겨줄 수 있습니다.

• HTTP Request Header의 If-Modified-Since의 용도는?

  • 출처에 따르면 If-Modified-Since 는 HTTP header로 하여금 요청이 조건적으로 보낼 수 있도록 한다고 합니다. 음.. 그것이 무슨 말이냐 하면 given date로 주어진 날짜 이내에 요청에 변경이 있다고 한다면 200코드로 정상적으로 자원을 받게될 것이구요. 만약 변경내용이 없다면 304코드와 함께 아무런 자원을 받지 않는 것이라고 합니다.
  • 보통 Last-Modified 와 함께 쓰인다고 하는데요. 여기서 Last-Modified 에 최근 변경된 날짜가 있겠죠? 이 날짜가 If-Modified-Since 에 명시된 날짜보다 그 이전에 있어야 효력이 발생하는 것입니다.
  • 어떻게보면 저기 뜻 그대로 '(어느시점) 이래로 변경했을 때' 로 보면 제일 정확할 것 같네요.

  If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
  

• HTTP Response Heade의 Cache-Control, Age, Expires의 용도는?

  • Cache-Control은 HTTP header인데요. 클라이언트의 요청과 서버의 응답에서 브라우저의 캐싱 전략을 구체화하기 위해 사용된다고 합니다.

  • 캐싱 전략에는 얼마만큼의 양의 자원들이 cashed될 것인지, 어디에서 cashed될 것인지, 그리고 소멸되기 전까지 얼마나 살아있을 것인지를 담고 있습니다.

    

    출처 : https://www.incapsula.com/cdn-guide/glossary/cache-control.html

  • Cache-Control 종류(참고)

    • Cache-Control: Max-Age

      • max-age요청은 얼마동안 캐시된 자원을 가지고 있을 것인가를 지시합니다. 예를들어 cache-control: max-age=120 이라면 120초 동안 반환된 자원이 유효하며 이후엔 무조건 다시 서버로 요청을 하여 refresh해야 합니다.

    • Cache-Control: No-Cache

      • 브라우저가 응답에 대해 캐시를 할 수도 있지만 무조건 처음은 서버로 요청을 통해 검증 요청을 받아야 한다고 하네요.

    • Cache-Control: No-Store

      • 이 설정은 캐시에 담지 않고 매번 서버로 요청을 해야하는 것을 말합니다. 보통 은행 정보와 같은 민감한 데이터에 사용된다고 합니다.

    • Cache-Control: Public

      • 해당 자원이 다른 곳에서의 캐시에도 남아있어도 될 떄 사용됩니다. 바로 뒤의 Private와 비교하여 이해하면 더 이해가 쉬울 것 같네요.

    • Cache-Control: Private

      • 캐시는 될 수 있다는 점에서 Public설정과 유사하지만 다른 점은 user specific하다는 점입니다. 즉, 해당 유저의 데스크탑에는 캐시가 저장될 수 있지만 다른 곳, 예를들어 CDN(Content Delivery Network)의 캐시에는 남아있을 수 없다는 뜻입니다.

  • 이외 다른 HTTP Cache Headers가 있는데요. Expires 는 이름에서도 알 수 있듯이 캐쉬의 소멸날짜입니다. 예를들어 Expires: Sat, 13 May 2017 07:00:00 GMT 와 같이 설정할 수 있는데요. 다만 Max-age와 함께 쓰이면 Expires 가 먹지 않는다고 하네요.

• HTTP Header에서 ETag, If-None-Match의 용도는?

  • ETag도 위에서 말한 것과 같은 HTTP Cache Header입니다. 이건 저희 git에서 각각 commit들에 부여하는 id와 같은 버전 식별값인데요.
  • 자원이 변경이 되면 이 식별값도 바뀌는데요. 만약 더이상 요청이 발생하지 않으면 이 식별값은 바뀌지 않으며 그때까지 는 이 식별값의 버전으로 브라우저의 자원으로 사용되는 것입니다.
  • If-None-Match 도 If-Modified-Since 와 같이 특정 조건에 발휘가 되는 요청인데요. 만약 자원의 버전 식별값이라고 할 수 있는 ETag가 변경사항이 있을 때 서버로 요청한 자원이 반영이 되도록 하는 것입니다.

 

 

HTTP Compression

• HTTP Header의 Accept-encoding, Content-encoding, gzip가 무엇이며, 용도는?

  • 어떤 Content-encoding이 클라이언트에서 이해할 수 있는지를 말합니다.
  • 그럼 Content-encoding은 뭘까요? 이는 서버에서 보내내주는 해당 값에 대해 encoding하는 것을 말합니다.

  ajax공부할 때 contentType은 클라이언트에서 서버로 보내주는 형식으로 이해했는데 여기선 반대인 것 같네요?!

  • 이러한 encoding과정에서 이루어지는 데이터 압축에서 사용되는 포맷을 gzip이라고 할 수 있습니다.

• 어떤 컨텐츠를 압축하는 것이 의미가 있는가? 모든 컨텐츠를 압축하는 것이 의미있는가?

 

 

브라우저의 웹 자원 요청 방식

• 병렬(Parallel) Connection, 지속(Persistent) Connection, 파이프라인(Pipeline) Connection이란?

  병렬 Connection은 검색하여도 잘 안나오네요. 지속 Connection과 파이프라인 Connection을 통칭하는 용어일까요?

  • HTTP에서는 클라이언트와 서버 사이의 컨넥션을 제공하는 TCP를 전송 프로토콜로 주로 사용합니다. TCP 연결을 여는 것은 자원의 소비하는 작업이기 때문에 성능상 제약이 생깁니다.(참고)
  • 이를 보완한 것이 지속 Connection과 파이프라인 Connection입니다. 먼저 나온 것이 지속 Connection인데요. 지속 Connection은 연속적인 요청 사이에 연결을 끊고 다시 구성하는 작업을 없애 비효율을 제거합니다.

  

  • 파이프라인 Connection은 더 나아가 이전 요청에 대한 응답을 기다리지도 않고 연속적인 요청을 보내 네트워크의 지연을 줄입니다. 모든 종류의 HTTP 요청이 파이프라인으로 처리될 수 있는 것은 아니고 GET, POST, PUT, DELETE와 같은 메서드만 가능하다고 하네요.

• HTTP Header에서 Connection의 Keep-Alive 동작 방식은? Keep-Alive 설정 방법은?

  • Keep-Alive는 일반적인 헤더이며 보내는 곳으로 하여금 얼마나 이 Connection이 유지될 것이며 최대 요청 개수에 대해 언급합니다.

  • 파라미터로 timeout 과 max 가 있는데요. 하나씩 말해보죠.

    • timeout : 이상적인 접속이 되기 위한 최소한의 접속 유지 시간을 말합니다.
    • max : 접속이 닫히기 전 보내져야 할 최대한의 요청 개수를 말합니다.

  • Keep-Alive 설정 방법

    • 설정방법에서는 웹서버를 어떤 것을 사용하는가에 따라 Apache 또는 Nginx에서의 설정 방법이 있고 또는 .htaccess 파일을 통한 설정이 있습니다.(참고)

• Connection 설정에 Keep-Alive 외엔 어떤 설정이 있으며 용도는?

  • Connection설정에 Keep-Alive 외에 close 라는 속성도 있습니다.

  Connection: keep-alive
  Connection: close
  

  • close 속성은 클라이언트나 서버에서 더이상 접속을 유지시키고 싶지 않을 때 사용을 한다고 합니다.

 

 

서버의 요청 수를 줄인다

• CSS Sprite란?

  • 여러 개의 이미지를 하나로 합쳐서 관리하는 이미지를 말합니다.
  • 하나의 페이지에 많은 이미지 요청이 포함될 수 밖에 없는데요. 여러 개의 이미지를 하나로 합쳐서 관리하기 때문에 관리가 용이한 장점과 함께 로딩 개수를 줄임으로써 성능 개선에도 도움이 됩니다.

• data: 스키마를 활용해 이미지를 html 인라인으로 다운로드하는 방법은?

  • Data URIs, data: schema가 접두어로 붙은 URL은 컨텐츠 작성자가 작성 파일은 문서 내에 임베드 하여 전달할 수 있게끔 합니다.

  • Data URIs는 4가지 파트로 구성됩니다.

    data:[<mediatype>][;base64],<data>
    

    • mediatype은 'image/jpeg'와 같은 MIME타입을 말합니다. 기본값으로는 text/plain;charset=US-ASCII 이 사용됩니다.
    • 데이터가 텍스트인 경우 그냥 단순히 임베드할 수 있지만, 텍스트가 아니라면 base64로 인코딩된 이진 데이터를 임베드하기 위해 base64를 설정할 수 있습니다.

• Javascript의 수를 최소화하는 방법은?

  • 웹서비스 기능이 많아짐에 따라 Javascript의 수는 늘어날 수 밖에 없습니다. 이런 경우 여러 개의 자바스크립트 파일을 하나로 통합을 통해 수를 최소화할 수 있습니다.
  • 웹 성능을 개선할 때는 파일의 용량보다는 파일의 개수가 더 중요하다고 합니다. 그렇기 때문에 여러 개의 자바스크립트 파일로 인해 네트워크 비용을 발생시키는 것보다 차라리 하나로 통합하는 것이 좋습니다.(참고)

 

 

Cache

• Cache란?

  • 캐시는 데이터나 값을 미리 복사해놓은 저장소를 말합니다. 하드웨어적이나 소프트웨어적으로 캐시는 많이 사용되고 있는 개념이고 실제로 사용되고 있죠.
  • 캐시의 장점은 데이터의 계산이나 또 다시 접근할 필요성이 없기 때문에 좀 더 효율적으로 원하는 결과를 받을 수 있다는 장점이 있습니다.
  • 캐시는 지역성의 개념을 기초로 하는데요. 지역성은 공간 지역성, 시간 지역성이 있습니다. 공간 지역성은 임의의 데이터를 참조했을 때 다음 참조는 그 데이터 근처에 일어난다는 것이고, 시간 지역성은 한 번 사용된 데이터는 가까운 시일 내에 다시 참조된다는 것입니다.(참고)

• 어떤 성격의 Data를 Cache하는 것이 적합한가?

  • 캐시는 저희가 원하는 데이터가 있는 곳과 실제 처리하는 곳의 중간에 있습니다. 그렇기 때문에 사실 Cache에 많은 데이터가 있다면 좀 더 빠르게 저희가 원하는 데이터를 받을 수 있을 것입니다. 하지만 Cache도 메모리이기 때문에 공간을 차지하고 복잡도를 증가시키기 때문에 Cache에 많이 저장해둔다고 좋은 것은 아닙니다.
  • 그렇기 때문에 어떤 Data를 Cache하느냐가 나온 것인데요. 제가 생각하기론 '자주 사용되는 Data'가 아마 캐시에 놓기 가장 좋겠죠. 자주 사용되면 굳이 저 멀리 둘 필요없이 가까이에서 꺼내서 바로 사용하면 되니까요.

• LRU(Least Recently Used), LFU(Least Frequently Used), First In Frist Out(FIFO) 알고리즘은? 각각의 알고리즘이 어느 경우에 적합한가? 예를 들어 설명한다.

  • 위 3가지 알고리즘은 캐시 안의 데이터를 교환할 때 전략방식들입니다.

  • LRU

    • 데이터를 사용한지 가장 오래된 항목부터 버리는 전략입니다.

  • LFU

    • 가장 적은 참조횟수를 가진 데이터를 버리는 전략입니다.

  • FIFO

    • 먼저 들어온 데이터 순대로 버리는 전략입니다.

• Cache에서 eviction이란?

  • eviction은 캐시 내부에 공간을 마련하기 위해 안 쓰는 데이터를 지우는 것을 말합니다. 위에서 말한 알고리즘 중 LRU를 주로 사용한다고 합니다.
  • eviction과 비슷한 개념으로 expiration이 있습니다. 이는 사용자가 유효기간을 정해놓고 그 기간동안만 캐시에 데이터를 살려두는 것입니다. 이후에 없어지구요
  • 둘의 차이점은 아무래도 eviction은 사용자 의도가 아닌 어쩔 수 없이, expiration은 사용자의 의도가 들어간 점이라는 것입니다.

• Cache적용시 고려사항(참고)

  • 데이터 캐시 시점 결정
  • 데이터를 효과적으로 캐시하는 방법 결정
  • 매우 동적인 데이터 캐싱
  • 캐시 데이터의 만료 관리
  • 클라이언트쪽 캐시에 데이터 무효화

 

 

Message Queue

• Message Queue의 필요성

  • 애플리케이션/시스템 간의 통신

    

    • 어떤 작업을 하면 시스템 에러가 발생할 경우가 있습니다. 이 경우 Message Queue를 사용하면 시스템이 정상적으로 다시 돌아올 때까지 Message Queue에 머무르며, 정상 작동시 제대로 응답을 할 수 있게끔 할 수 있습니다.

  • 서버 부하가 많은 작업

    • 이미지 처리나 비디오 인코딩 같은 작업은 메모리와 CPU를 많이 사용합니다. 한번에 요청을 보내는 것이 아니라 Message Queue를 이용하여 한번에 처리할 수 있는 양만큼 적당히 받아서 처리하면 서버의 부하를 줄일 수 있습니다.

  • 부하 분산

    

    • Message Queue에서 다른 서버에 적절히 요청을 분산시킴으로써 부하를 분산시킬 수도 있습니다.

  • 데이터 손실 방지

    • 서버와 Message Queue 간의 데이터 처리를 하고 있다가 갑자기 서버에서 에러 발생으로 다운이 발생할 수 있습니다. 이 경우 응답이 안된 요청에 대해서 다시 작업이 필요한데 서버에서 Message Queue에게 완료 메시지를 보내지 않으면 Message Queue에선 다시 서버에게 요청을 보내 다시 처리할 수 있게끔 할 수 있습니다.

• Message Queue를 사용시 성능상 유리한 점

• Message Queue를 적용시 고려사항

 

 

어렵네요.. 짧은 시간이었지만 역시나 정말 거대한 컴퓨터 과학의 지식을 깨닫게 합니다. 부족한 부분에 대해선 내일 좀 더 보완해볼게요!