서버 성능 개선

안녕하세요, Brad입니다. 어제 '서버성능개선'이라는 주제로 과제를 했었는데요. 오늘 수업시간에 그에 대해 한층 더 이해할 수 있는 기회가 되었습니다. 수업 시간에 배운 내용을 정리해볼게요!

 

• URI, URN, URL의 차이점은?

  • URI(Uniform Resource Identifier), URN(Uniform Resource Name), URL(Uniform Resource Locator)

  • 사실 URI안에 URN과 URL이 속해져있는 관계입니다.

    

    출처 : http://jesusgilhernandez.com/2012/11/04/uri-url-and-urn/

  • URL이 리소스의 '위치'를 말하는 것이라면 URN은 리소스의 '이름, 그 자체'를 말합니다. 그렇기 때문에 리소스의 위치가 바뀌더라도 해당 리소스를 찾을 수 있습니다.

  • 다만 현재 URN이 잘 사용되고 있지 않고 URL이 보편적으로 사용되고 있다보니 URI이 URL이라고는 할 수는 없지만 같은 것처럼 사용되고 있긴 합니다.

• 대역폭(Bandwidth)과 대기시간(Latency)

  • 대역폭(Bandwidth)은 통신에서 정보를 전송할 수 있는 능력을 말합니다.그리고 대기시간(Latency)은 하나의 요청에 대해 서버로부터 응답받을 때까지 걸리는 시간을 말합니다.

  그럼 Latency와 Ping은 무엇이 다를까요?

  • 개념 자체가 다릅니다. 둘 다 서버에 다녀오는 것은 같지만 Ping은 singal이라고 한다면 Latency는 time입니다. Ping을 보내서 네트워크가 제대로 통신을 하는지 여부를 확인할 수 있습니다. 반면 Latency는 요청한 것에 대해 처리 후 클라이언트까지 오는데 걸리는 시간을 말하는 것입니다. ping을 통해 시간을 확인할 수 있는데 이 시간은 서버를 찍고 오는 시간이라고 볼 수 있습니다.

  대역폭과 대기시간 중에 어떤 것이 더 중요할까?

  • 분명 두 가지 개념이 중요합니다. 하지만 개발을 하는 입장에서 대기시간이 대역폭보다 중요합니다. 왜냐하면 대역폭은 돈을 투자하면 분명 나아질 수 있는 부분이지만 대기시간은 개발자의 역량에 달려있기 때문입니다.

    • 대기시간을 개선시키기 위해 가장 살펴봐야할 부분이 DB에서 데이터를 가져오는 '쿼리'입니다.
    • 인스턴스를 더 만들고 하는 부분도 분명 성능상 불리한 요소이긴 하지만 쿼리로 인해 지연되는 시간에 비하면 정말 사소합니다. 그렇기 때문에 그 부분보다는 쿼리를 개선시킬 생각을 하는 것이 합리적입니다.

• 외부 API의 성능이 떨어진다면 어떻게 개선시킬 수 있을까요?

  • 이런 경우 사용할 수 있는 것이 '캐시'입니다. 캐시를 사용함으로써 해당 자원을 위해 호출하는 횟수를 줄이는 것이지요.

  캐시는 그럼 어디에 있을까요?

  • WAS의 캐시메모리에 있습니다.

• 그렇다면 모든 데이터를 캐시메모리에 두면 되지 그렇게 두지 않는 이유는 뭘까요?

  • 기본적으로 캐시의 크기가 크지 않습니다. 그리고 비용도 비쌉니다.

  • 또 다른 이유로 캐시 안의 내용이 외부에서 변경되었을 경우 문제가 발생할 수 있습니다. 변경이 요구됨에도 캐시 안에 기존의 데이터가 있기 때문에 제대로 반영이 안되기 때문입니다.

    • 이 경우 '만료 시간' 설정 등의 관리가 필요합니다.

  • 그리고 캐시에 있는지 확인하는 별도의 작업으로 인한 비용도 있습니다.

• HTTP 상태코드 200과 304의 차이

  어떠한 설정을 통해 200코드와 304코드를 만들 수 있을까요?

  • 서버에 별도의 설정을 통해 응답을 보낼 때 헤더에 속성을 추가하여 200코드나 304코드가 발생시키도록 할 수 있습니다.

    

    출처 : https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

  • 그러한 서버의 설정을 통해 ETag 또는 Cache-Control내의 속성값 등을 보낼 수 있는데요. 위 설정을 살펴보면 120초 까지는 기존 데이터를 계속 사용하다가 120초 이후에 다시 서버로 요청을 보내 변경사항을 확인하여 변경사항이 없으면 304코드를, 있으면 서버까지 가서 200코드로 받는 것입니다.

  • 만약 이러한 서버의 설정이 없었다면 새로 요청하는 것 없이 그대로 그 자원을 사용할 것입니다.

• 캐시에 있는 데이터는 어떻게 갱신시킬 수 있을까요?

  • 캐시에 데이터가 있는데 갑자기 데이터가 변경이 발생했을 때 클라이언트 쪽에서 기존의 데이터를 가져오기 때문에 제대로 변경된 데이터를 반영시키기 어려울 것입니다.
  • 보통 url기준으로 캐시를 관리하는데요. 쿠팡의 경우 살펴보겠습니다. 쿠팡의 메인페이지의 css 파일의 경우 url 주소가 https://www.coupang.com/resources/20190110105527/np/css/main_new.min.css 로 구성되어 있는데요. 중간의 20190110105527 부분이 버전정보라고 볼 수 있습니다.
  • 이렇게 사용하면 이후에 변경이 발생했을 때 새로운 버전(다른 수)으로 요청이 발생되기 때문에 기존 캐시에 있는 데이터가 아니라 새로 요청을 보내서 변경된 데이터를 제대로 반영시킬 수 있습니다.

• 304코드와 캐시 비교

  • 헤더 설정을 통해 특정 조건일 경우 요청을 서버로 보내 변경 유무를 파악하여 변경이 없을 경우 304코드가 발생하도록 할 수 있는데요. 캐시는 서버로 요청을 보낼 필요도 없다는 점에서 성능이 우수합니다.
  • 사실 이 2가지는 비교대상이 아니라 같이 상호보완적으로 사용하는 관계이긴 하지만 굳이 따지자면 그럴 것 같네요.
  • 캐시는 적은 비용으로 큰 효과를 낼 수 있는 방법 중 하나이며, 기존의 Bandwidth를 통해 더 많은 요청을 받을 수 있게끔 해준다는 점에서 매우 중요합니다!!

• 서버 요청 수 줄이기

  • 구글 이미지의 경우 그 많은 이미지들을 불러오는데 어떻게 그렇게 빨리 데이터들을 가져올 수 있을까요?

  • 그 이유는 html body안에 image를 넣어서 요청을 줄여서 그렇습니다. 안에 넣으려면 다음과 같은 형식을 사용할 수 있는데요.

    data:image/png;base64,(사진 데이터)
    

  • 이렇게 html안에 이미 데이터를 넣어 보냄으로써 새로운 요청 발생시 캐시된 html을 불러오기 때문에 요청 수를 줄일 수 있습니다.

• HTTP와 HTTPS와의 연결 차이

  • HTTP는 연결할 때 3-way-handshaking을 합니다. 이래와 같습니다.

    

    • 쉽게 설명하면 처음에 클라이언트가 서버에게 '살아있니?' 물어봅니다
    • 그럼 서버는 '응.. 너는?' 이라고 다시 응답을 보내고 클라이언트에게 다시 물어봅니다
    • 그럼 클라이언트는 '나도!!' 라는 마지막 응답과 함께 연결이 되는 것입니다.

  • HTTPS는 3-way-handshaking과 더불어 암호화 키 공유하는 과정이 추가적으로 있습니다.

    

    • HTTPS 에서는 HTTP에서 보았던 3-way-handshaking 이외 추가적인 작업이 있는 것을 볼 수 있습니다.

  • 그럼 저런 추가적 작업때문에 HTTPS의 Latency가 늘어난다고 볼 수 있을까요?

    • 물론 HTTPS가 추가적 작업이 필요하긴 하지만 이런 추가적 작업으로 인해 속도가 느려져 HTTPS를 도입하는 것을 반대하는 것은 말이 안됩니다.
    • 극히 짧은 순간이며 보안을 위해서 이정도 시간은 충분히 감수할 수 있다고 봅니다.