반응형

해당 내용은 '실무로 배우는 시스템 성능 최적화'의 내용중 일부를 발췌한 내용입니다. 웹 방화벽에 의한 성능 저하 사례로 방화벽으로 인해 이러한 문제가 발생할 수 있구나 정도로 인지하고 있다면 비슷한 이슈가 발생했을 때 보다 빠르게 대응을 할 수 있을 거라 생각되어 남겨 봅니다.

현상

전국에서 사용하는 시스템으로, 특정 지역의 윈도우7 사용자만 화면 응답시간이 급격히 느려져 1분 이상 소요되는 현상이 발생했다. 그러나 항상 느린 것은 아니고 동일한 화면도 느릴 때와 빠를 때가 있는데 대부분은 느렸다.

접근 방법

현상을 정확히 확인하기 위해 해당 기관을 방문해 직접 화면을 사용하면서 네트워크 패킷을 수집해서 분석했다. 화면이 느릴 때는 HTTP 요청에서 TCP 재전송이 발생하면서 지연되는데, 결국은 서버로부터 HTTP 요청에 대한 ACK를 받지 못하고 타임아웃인 1분에 걸려서 해당 TCP 세션을 강제로 끊고 새로운 TCP 세션을 맺어 HTTP 요청을 보내어 응답을 받음으로써 1분 이상 소요됐다.

그런데 이상한 것은 아파치 웹 서버의 Keepalive 타임아웃이 5 초인데 사용자단 브라우저 TCP 세션은 5초가 이상 지나도 계속 ESTABLISH 상태를 유지하고 있고, 느릴 때는 5초 이상 경과된 TCP 세션을 사용하고 있었다. 그러나 웹 서버에서는 Keepalive 5초가 경과해서 해당 TCP 세션을 끊기 위해 FIN을 보냈음에도 클라이언트로부터 FIN을 받지 못하고 있는 TIME_WAIT 상태였다.

따라서 클라이언트와 웹 서버 사이 어디에선가 웹 서버가 보낸 TCP 세션 종료 신호인 FIN 패킷을 삼키고 있는 것으로 판단했다. 이런 현상이 특정 기관 사용자에게서만 발생하고 있어 해당 기관 내부 네트워크 이상으로 판단했다. 그러나 웹 서비스의 대표 IP인 L4의 가상 IP 대신 실제 서버 IP를 사용해 테스트를 진행하면 웹 서버 2대 모두로부터 정상적으로 클라이언트가 FIN 패킷을 받았다. 이에 L4 가상 IP 사용과 실 서버 IP 사용 시 발생하는 차이가 웹 방화벽 경유로 기인했음을 확인하고 L4 가상 IP를 사용하더라도 웹 방화벽을 경유하지 않도록 네트워크 설정을 수정해 다시 테스트를 진행한 결과, 웹 서버가 보낸 FIN 패킷을 클라이언트가 정상적으로 받는 것이 확인됐으며, 화면 응답시간도 정상이었다.

원인

웹 서버는 Keepalive 5초가 경과한 TCP 세션을 끊고 있으나 FIN 패킷이 클라이언트에 전달되지 않아 클라이언트는 웹 서버가 close한 세션을 살아있다고 생각하고 해당 TCP 세션으로 HTTP 요청을 전송함으로써 이상을 감지하기까지 오래 걸려 화면 지연이 발생했다. 웹 방화벽에서 웹 서버가 보낸 FIN 패킷을 삼킨 것으로 테스트에서 확인했다.

반응형
반응형

'실무로 배우는 시스템 성능 최적화' 책을 읽다가 L4설정 오류에 따른 알아두면 좋을 법한 성능 저하 사례가 있어 포스팅 해보려고 한다. 해당내용은 모두 '실무로 배우는 시스템 성능 최적화' 책 내용에 기반한다.

[ 현상 ]

웹 포털 화면을 사용할 때마다 대부분 정적 콘텐츠를 반복해서 내려받아 응답시간이 오래 걸리는 성능 저하 현상이 발생했다.

[ 접근 방식 ]

피들러로 모니터링한 결과, 동일 정적 콘텐츠를 기존에 내려받았음에도 다시 내려받는 현상이 발생하고 있음을 확인하고 HTTP 응답을 분석한 결과, 동일 정적 콘텐츠의 변경일자가 각기 다른 것을 발견했다. 이것은 한 웹 서버에 요청이 들어간다면 발생할 수 없는 상황이므로 웹 서버 액세스 로그를 통해 한 PC에서 들어오는 HTTP 요청이 여러 웹 서버에 골고루 들어온다는 것을 확인했다. 이에 웹 서버 파일시스템 구성과 L4의 분배 방식을 확인해 원인을 찾았다.

[ 원인 ]

-L4에서 단순 라운드 로빈(Round-robin) 형태로 HTTP 요청을 분배시켜 한 사용자의 요청에 대해 4대의 웹 서버에서 서비스가 이루어짐

-웹 서버의 문서 루트는 NAS 같은 공유 파일시스템이 아닌 로컬 파일시스템 내에 개별적으로 존재하고, 같은 콘텐츠임에도 변경일자가 각 서버마다 달랐다.

-위 두 가지 원인으로 한 브라우저에서 이뤄지는 HTTP 요청이 4대의 서버에 무작위로 분배되고, 각 서버 동일 콘텐츠의 변경일자가 모두 달라서 매번 변경된 콘텐츠로 인식됐다.

-이로 인해 브라우저 캐시가 정상적으로 효과를 발휘하지 못하고 매번 콘텐츠 내용을 내려받음으로써 성능 저하가 발생했다.

[ 조치 ]

L4 분배 방식을 해시(HASH)로 변경해 PC의 IP가 동일하면 동일한 웹 서버로 접속이 이뤄지도록 개선했다(NAS 같은 공유 파일시스템을 사용하면 L4의 분배 방식에 상관없이 브라우저 캐시가 동작하게 할 수도 있다).

[ 결과 ]

브라우저 캐시가 정상적으로 동작해 매번 콘텐츠를 내려받지 않음으로써 화면 응답시간이 개선됐다.

반응형
반응형



이번 포스팅은 저번 포스팅(스파크 설정 Part.1)에 이어 spark-submit 실행시 메모리, 익스큐터, 네트워크, 보안,암호화 관련 설정에 대해 정리해보겠습니다. 해당 내용은 '빅데이터 분석을 위한 스파크2 프로그래밍' 책의 내용을 기반으로 정리하였습니다.


[ 메모리 관련 설정 ]

  • spark.memory.fraction : 전체 힙 영역에서 익스큐터와 RDD 데이터 저장에 사용될 크기를 비율로 설정합니다. 기본값은 0.6이며 스파크 내부에서 사용하는 메타데이터나 객체 직렬화 및 역질렬화 등에 필요한 예비 메모리 공간을 확보해서 OOM을 방지할 목적으로 이 값을 조정할 수 있습니다.
  • spark.memory.storageFraction : 할당된 메모리에서 데이터 저장에 사용할 비율을 지정할 수 있습니다. 기본값은 0.5이며 이 값을 크게 할 경우 익스큐터에서 사용할 메모리 크기를 줄여야 합니다.
  • spark.memory.offHeap.enabled : 기본값은 false이며 true로 설정할 경우 off-heap메모리를 사용합니다. 이 값을 true로 설정했다면 spark.memory.offHeap.size에 오프-힙 메모리 크기를 지정해야 합니다.

[ 익스큐터 관련 설정 ]
  • spark.executor.cores : 익스큐터에 할당된 코어의 수를 지정합니다. 지정하지 않을 경우 얀 모드에서는 1, 스탠드얼론 모드와 메소스 coarse-grained모드에서는 사용 가능한 전체 코어의 개수가 사용됩니다.
  • spark.default.parallelism : 스파크에서 사용할 파티션의 수, 즉 스파크의 기본 병렬 처리 수준을 지정합니다.
  • spark.files.fetchTimeout : sparkContext.addFile() 메서드를 이용했을 때 드라이버로부터 파일을 받아오는 데 걸리는 최대 시간을 설정합니다. 기본값은 60s 입니다.

[ 네트워크 관련 설정 ]
  • spark.driver.host, spark.driver.port : 드라이버 프로세스의 호스트와 포트 정보를 설정합니다.
  • spark.network.timeout : 스파크의 기본 네트워크 타임아웃을 설정합니다. 이 값은 spark.core.connection.ack.wait.timeout 등 다른 설정 값들의 기본값으로 사용됩니다.

[ 보안 관련 설정 ]
  • spark.acls.enable : 스파크 acl을 활성화할지 여부를 설정합니다. 기본값은 false입니다.
  • spark.admin.acls : 스파크 잡에 접근할 수 있는 사용자(user)와 관리자(administrator) 정보를 설정하며, 콤마(,)를 이용해 다수의 사용자를 지정할 수 있습니다. 만약 그룹으로 설정할 경우 spark.admin.acls, groups 속성을 사용할 수 있습니다.
  • spark.authenticate : 스파크에서 사용자 인증 여부를 확인할 것인지를 설정합니다. 기본 값은 false이며, 이 경우 인증 여부와 상관없이 스파크 잡을 실행하고 접근할 수 있습니다.
  • spark.authenticate.secret : 잡을 실행하기 위한 비밀 키 정보를 설정합니다.
  • spark.ui.view.acls,spark.ui.view.acls.groups : 스파크 UI에서 잡 정보를 조회하기 위한 acl 정보를 설정합니다.
  • spark.ui.filters : 스파크 UI에 적용할 자바 서블릿 필터 정보를 지정합니다. 콤마(,)를 이용해 여러 개의 필터를 지정할 수 있으며, 자바 시스템 프로퍼티를 사용해 필터에서 사용할 파라미터 정보를 지정할 수 있습니다. 

[ 암호화 관련 설정 ]
  • spark.ssl.enabled : 기본값은 false이며 SSL 연결을 활성화할 것인지 설정합니다.
  • spark.ssl.keyStore : 키 스토어 파일이 저장된 경로를 지정합니다.
  • spark.ssl.keyStoreType : 키 스토어 파일의 타입을 지정합니다.
  • spark.ssl.keyStorePassword : 키 스토어 파일에 대한 비밀번호를 지정합니다.
  • spark.ssl.enabledAlgorithms : ssl을 위한 알고리즘(cipher) 리스트를 지정합니다. 콤마(,)를 이용해 여러 개 지정할 수 있습니다.

보안, 암호화 관련 설정은 거의 작업해 본적이 없는 것 같네요...보통 사용하는 하둡 클러스터 장비들이 사내 네트워크망에서만 접근 가능하도록 되어있어서ㅎㅎ

이상으로 포스팅을 마치도록 하겠습니다.


반응형
반응형

클라우드 네트워크 교육(0627)

사내에서 클라우드 네트워크 교육(0627)을 듣고 새롭게 알게된 내용에 대해 간략하게 정리.


공해야할 것 들이 너무 나도 많음을 느낀다.

[ 교육들으며 새로 알게 된 내용 ]

1. 실제 네트워크 확인시 패킷을 뜬다고 소위 말하는데 실제로는 OSI Layer상의 Datalink Layer의 Frame을 의미한다

2. Frame, Packet, Segment의 주요한 차이는 header가 가지는 정보의 차이에 있다고 볼 수 있다.

세그먼트(Segment, OSI 7계층의 전송 계층(Transport Layer)) : 데이터를 네트워크를 통한 실질적인 전송을 위하여 적절한 크기로 분할한 조각.

패킷(Packet, OSI 7계층의 네트워크 계층(Network Layer)) : 전송을 위해 분할된 데이터 조각(세그먼트)에 목적지까지의 전달을 위하여 Source IP 와 Destination IP가 포함된 IP Header가 붙은 형태의 메세지

프레임(Frame, OSI 7계층의 데이터링크 계층(Data Link Layer)) : 최종적으로 데이터를 전송하기 전에 패킷에 Header(Mac Address 포함)와 CRC를 위한 Trailer가 붙은 메세지

3. 리눅스에서 MAC ADDRESS확인시 ifconfig외에 ip link 및 ip -4 addr로 확인 가능 (가급적이면 ip 명령어에 익숙해지자 - 네트워크관련 모든 명령 처리가능)


4. MAC ADDRESS는 유니크한가? 로컬 LAN안에서는 유니크해야한다.


5. MAC ADRRESS는 permanent한가? permanent하지 않다. ip link set을 통한 abusing가능. 그렇기 때문에 MAC ADDRESS를 통한 인증처리는 지양하자.


6. 패킷 전송 크기를 정하는 MTU(Maximum Transmission Unit) 가 작을 경우 header에 의한 overhead를 초래할 수 있다.

ex) 
데이터 사이즈 3000byte
MTU=500 (byte) 인경우 6frame 으로 나눠 전송, 각 프레임에 헤더는 14byte * 6이된다
MTU=1500 (byte, 일반적 설정) 2frame, 헤더는 14byte * 6이 된다.

     [ MTU 더 궁금하면참고 ] http://www.packetinside.com/2013/02/mtumaximum-transmission-unit.html


7. 네트워크 연결 확인시 ping보다는 arping 명령어 이용 ping의 경우는 어떤 layer에서 막혔는지 확인이 힘들다.


8. 네트워크 대역폭 확인 시 iperf3 명령어 사용 (참고, http://sola99.tistory.com/374)


9. 토스트 클라우드 네트워크는 각 서비스별에 맞춰 tenant하게 설계되어짐 (share x) - 서로간 통신을 위해서는 floating IP 필요


10. AWS에서는 virtual private cloud를 사용해 각 계정 전용 가상 네트워크 제공


네트워크에 대한 공부도 틈틈히 시간내서 하도록 하자. 

알고개발하는 것과 모르고 개발하는 것은 천지차이


반응형
반응형

데이터 엔지니어로 살아가기 101일 째


어제(0609 금요일) 하루는 최근 회사 내에서  IDC 네트워크 장애에 대해 공유하는 시간을 가졌다. 

서버룸중 특저 서버룸의 스위치가 문제를 일으키며 해당 룸의 서버들의 네트워크 통신이 정상적으로 되지 않았다. 

사내에서 서비스하는 서비스들 모두가 장애시간동안 정상동작 하지 않았던 대형 이슈였다.

큰 장애가 터진 문제의 시발점은 access switch OS 버그에서 기인했다고 설명해주셨다. 

네트워크적인 지식이 많이 부족해 공유된 내용 모두를 이해하진 못했지만 사소한 버그들이 맞물려 큰 사고로 이어졌고 이에 대한 대응책등을 공유하는 시간을 가졌다.


오후에 저번주 리타겟팅 시스템 장애로 작업이 진행되지 못했던 실시간 모니터링 시스템에 대한 작업을 진행하였다.

실시간으로 처리되고 있는 데이터들이 정상적으로 데이터를 카산드라에 적재하고 있는지 모니터링 하기 위한 시스템이다.

작업을 하면서 어려움을 느꼈던 부분은 현재 알파 클러스터와 리얼클러스터에서 스파크 버전이 1.5에 맞춰져 있어 kafka stream, spark의 maven dependency버전 맞추는 부분에서 시간을 많이 빼앗겼다. 스칼라로 작업했으면 훨씬 빠르게 했을 것을 다른 시스템과의 연동이 많이 필요할 것 같아 자바(java8 이 아닌 java7)로 스파크 작업을 하다보니 시행착오를 많이 겪었다.


알파 클러스터에는 실시간으로 데이터들이 적재되지 않고 있기 때문에 curl을 통해 실시간으로 로그를 쏴주는 스크립트를 작성 후 

카프카에서 실시간 처리하는 시스템 작업으로 생각보다 고려할점들이 많았다.


간만에 시스템 설계부터 코딩작업에 시간은 잘갔던 것 같다. 

시행착오들, 경험들이 쌓여 이후 작업에서는 시스템 설계와 구현시 같은 이유로 시간을 많이 빼앗기지 않도록 열심히 배우고 공부하자.


반응형
반응형


 안녕하세요. 오늘은 저번 정리 PART.1에 이어 정리를 해보도록 하겠습니다.


[ 403 Forbidden ]

 403이 발생한 원인으로는 파일 시스템의 퍼미션이 부여되지 않은 경우와 액세스 권한에 문제(허가되지 않은 송신 IP 주소의 액세스 등) 가 있는 것을 예로 들 수 있다.

-> 실제로 현업에서 API 통신간 자주 보는 상태 코드이며 보통은 ACL문제라고 볼 수 있다.


[ 503 Service Unavailable ]

 이 리스폰스는 일시적으로 서버가 과부하 상태이거나 정검중이기 때문에 현재 리퀘스트를 처리할 수 없음을 나타낸다. 이 상태가 해소되기까지 시간이 걸리는 경우에는 Retry-After 헤더 필드에 따라 클라이언트에 전달하는 것이 바람직하다.


[ 프록시 ]

 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터의 리퀘스트를 서버에 전송하고, 서버로부터의 리스폰스를 클라이언트에 전송한다.

클라이언트 <-> 프록시 서버 <-> 오리진 서버(Origin Server, 리소스 본체를 가진 서버)

프록시 서버를 사용하는 이유는 캐시를 사용해서 네트워크 대역 등을 효율적으로 사용하는 것과 조직 내에 특정 웹 사이트에 대한 액세스 제한, 액세스 로그를 획득하는 정책을 지키려는 목적으로 사용하는 경우가 있다.


[ 프록시 사용 방법 2가지, 캐싱 프록시(Cashing Proxy)/투명 프록시(Transparent Proxy) ]

 캐싱 프록시 (Cashing Proxy) : 프록시에 다시 같은 리소스에 리퀘스트가 온 겨우, 오리진 서버로부터 리소스를 획득하는 것이 아니라 캐시를 리스폰스로서 되돌려 주는 타입의 프록시

 투명 프록시 (Transparent Proxy) : 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는 타입의 프록시, 반대로 메시지에 변경을 가하는 타입의 프록시를 비투과 프록시라고 한다.


[ 게이트웨이 ]

 게이트웨이의 동작은 프록시와 매우 유사하나 게이트웨이의 경우에는 그 다음에 있는 서버가 HTTP 서버 이외의 서비스를 제공하는 서버가 된다.

클라이언트 <-(HTTP 통신) -> 게이트웨이 <-(HTTP 프로토콜 이외의 통신) -> HTTP이외의 서버

두 컴퓨터(노드-node라고도 함)가 네트워크 상에서 서로 연결되려면 동일한 통신 프로토콜(protocol, 통신 규약)을 사용해야 한다. 따라서 프로토콜이 다른 네트워크 상의 컴퓨터와 통신하려면 두 프로토콜을 적절히 변환해 주는 변환기가 필요한데, 게이트웨이가 바로 이러한 변환기 역할을 한다. 한국인과 미국인 사이에 원활한 의사소통을 위해 통역사를 두는 것과 동일하다 

자세한 설명 참고 : http://it.donga.com/6744/


[ 캐시(Cache) ]

 캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킨다. 캐시를 사용하면 리소스를 가진 서버에 액세스를 줄이는 것이 가능하기 때문에 통신량과 통신 시간을 절약할 수 있다. 캐시 서버는 프록시 서버의 하나로 캐싱 프록시로 분류되며 캐시 서버의 장점은 같은 데이터를 몇 번이고 오리진 서버에 전송할 필요가 없다는 것이다. (클라이언트는 네트워크에서 가까운 서버로부터 리소스를 얻을 수 있고 서버는 같은 리퀘스트를 매번 처리하지 않아도 된다)


[ 클라이언트에 존재하는 캐시 ]

 캐시 서버만 캐시를 가지고 있는 게 아니라 클라이언트가 사용하고 있는 브라우저에서도 캐시를 가질 수 있다. IE에서 클라이언트가 보존하는 캐시를 인터넷 임시 파일이라고 부른다. 브라우저가 유효한 캐시를 가지고 있는 경우, 같은 리소스의 액세스는 서버에 액세스하지 않고 로컬 디스크로부터 불러 온다.


오늘은 여기까지 정리하도록 하겠습니다. 뭐든 배울 수록 배워야될게 더 생겨나가는 이 느낌. 정말 공부는 끝이 없을 것 같습니다.





반응형
반응형

 안녕하세요. 오늘은 전에 읽었던 '그림으로 배우는 HTTP&NETWORK BASIC'이라는 책을 간단히 제가 몰랐거나 나중에 다시 한 번 상기가 필요한 내용들로 정리해보려고 합니다. 아무래도 웹 개발을 하다보니 네트워크 지식들이 필요할 때가 많은데요. 중요한 내용을 바탕으로 쉽게 그림으로 잘 설명되어 있는 책을 골라 읽어보았는데 생각보다 괜찮네요. 기본적인 네트워크 지식이 필요하신 분들에게도 좋은 책이 될 것 같네요. 아무래도 제 주관적으로 중요하다 싶은 내용이나 나중에 한 번 더 봐야 될 부분들에 대해서 정리가 될 것 같은데 보시고 괜찮으시다면 책을 사셔서 보시는걸 추천 드리겠습니다.

[ TCP/IP 계층화 ]
-TCP/IP는 '애플리케이션 계층', '트랜스포트 계층(TCP)', '네트워크 계층(IP)', '링크 계층' 이렇게 총 4계층으로 나뉘어 있다.
> 계층화의 메리트는 인터넷이 하나의 프로토콜로 되어 있다면 어디선가 사양이 변경되었을 때 전체를 바꾸지 않으면 안되지만, 계층화되어 있으면 사양이 변경된 해당 계층만 바꾸면 됩니다.

[ 패킷 ]
-패킷이란 전송하는 데이터의 최소 단위 입니다.

[ IP, MAC ]
-IP(Internet Protocl)의 역할은 개개의 패킷을 상대방에게 전달하는 것. 상대방에게 전달하기까지 여러 요소가 필요한데 그 중에서도 IP와 MAC(Media Access Control Address)라는 요소가 중요하다.
IP주소는 각 노드에 부여된 주소를 가리키고 MAC 주소는 각 네트워크 카드에 할당된 고유의 주소이다. IP주소는 변경 가능하지만 기본적으로 MAC 주소는 변경 할 수 없다.

[TCP, Three way handshaking]
-TCP(Transfer Control Protocol)는 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대에게 보내고, 정확하게 도착했는지 확인하는 역할을 담당한다. TCP는 상대에게 확실하게 데이터를 보내기 위해 "쓰리웨이 핸드셰이킹(three way handshaking)"이라는 방법을 사용하고 있는데 이 방법은 패킷을 보내고 나서 바로 끝내는 것이 아니라, 보내졌는지 여부를 상대에게 확인하러 간다. 이것은 'SYN'와 'ACK'라는 TCP 플래그를 사용한다. 송신측에서는 최초 'SYN'플래그로 상대에게 접속함과 동시에 패킷을 보내고, 수신측에서는 'SYN/ACK' 플래그로 송신측에 접속함과 동시에 패킷을 수신한 사실을 전한다. 마지막으로 송신측이 'ACK' 플래그를 보내 패킷 교환이 완료되었음을 전한다.

[ HTTP, STATLESS PROTOCOL ]
-HTTP는 상태를 계속 유지하지 않는 스테이트리스(stateless)프로토콜로 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않는다. HTTP에서는 새로운 리퀘스트가 보내질 때 마다 새로운 리스폰스가 생성된다. 프로토콜로서는 과거의 리퀘스트나 리스폰스 정보를 전혀 가지고 있지 않다. 이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성(scalability)을 확보하기 위해서 이와 같이 간단하게 설계되어 있는 것이다.

[ 지속연결, 파이프라인화 ]
-HTTP/1.1와 일부 HTTP/1.0에서는 TCP 연결 문제를 해결하기 위해 지속연결(Persistent Connections)이라는 방법을 고안하였다.  지속 연결의 특징은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다. 지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인(HTTP pipelining)화를 가능하게 한다. 파이프라인화에 의해서 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 리퀘스트를 발행하던 것을, 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있게 되었다. 지속 연결 < 파이프라인화(리퀘스트 수가 늘어날 수록 현저한 차이)

[ STATELESS PROTOCOL 이점 ]
-상태를 유지하지 않는다는 점에서 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있다. 또한, 단순한 프로토콜이기에 HTTP가 다양한 곳에서 이용되는 측면도 있다.

[ 쿠키 - STATELESS PROTOCOL 문제 해결 ]
-쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다.

[ 인코딩으로 전송 효율을 높이다 ]
-HTTP로 데이터를 전송할 경우 그대로 전송할 수도 있지만 전송할 때에 인코딩을 실시함으로써 전송 효율을 높일 수 있다. 전송할 때 인코딩을 하면 다량의 액세스를 효율 좋게 처리할 수 있다. 단지, 컴퓨터에서 인코딩 처리를 해야 하기 때문에 CPU 등의 리소스는 보다 많이 소비하게 된다.

[ 레인지 리퀘스트 (Range Request) ]
-다운로드 중 커넥션이 끊어지게 되면 처음부터 다시 다운로드를 해야하는 문제를 해결하기 위해 일반적인 리줌(resume)이라는 기능이 필요하게 되었다. 리줌을 통해 이전에 다운로드를 한 곳에서 부터 다운로드를 재개할 수 있다. 이 기능 실현을 위해서는 엔티티의 범위를 지정해서 다운로드를 할 필요가 있다. 이와 같이 범위를 지정하여 리퀘스트 하는 것을 레인지 리퀘스트라고 부른다.

[ 콘텐츠 네고시에이션 ]
- 서로 다른 언어를 주로 사용하는 브라우저가 같은 URI에 액세스할 때에 각각 영어판 웹 페이지와 한국어판 웹 페이지를 표시하는 구조를 콘텐츠 네고시에이션(Content Negotiation)이라고 부른다.
서버 구동형 네고시에이션(서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리하는 방식)과 에이전트 구동형 네고시에이션(브라우저에서 표시 된 선택지 중에서 유저가 수동으로 선택하는 방법)이 있다.

오늘 포스팅은 여기까지 하도록 하겠습니다. :)



반응형
반응형

 


 안녕하세요. 오늘은 최근 작업했던 특정 서비스의 웹 개편 작업 중 경험한 장애 상황에 대해 포스팅 해볼까 합니다. 새롭게 단장한 고객센터 페이지를 해당 서비스에 적용하고 테스트 까지 잘 맞췄었는데 그 다음 날 장애 상황을 경험하게 되었습니다.

먼저 현재 회사의 많은 서비스 고객센터 페이지가 API 형태로 붙게 되는데요. 그렇다보니 그 많은 서비스들의 고객센터 페이지를 계속해서 만들어 낼 수도 없는 상황인지라 사이트메쉬와 데코레이터 패턴을 이용하여 신규 서비스가 오픈하면 해당 서비스에 맞게 CSS를 입혀 서비스하는 방식으로 몇몇 서비스들이 이루어지고 있습니다. 최근 특정 서비스의 웹 리모델링에 맞춰 변경된 CSS로 작업을 진행하는 도중 문제가 발생했습니다.


[상 황]

 웹페이지의 리모델링에 맞춰 CSS작업 팀으로 부터 변경 된 CSS를 받아 특정 서비스의 고객센터에 적용해야하는 상황. 물론 CSS를 새로 받게 되면 로컬에서 CSS를 적용시켜보고 웹 페이지를 띄워 노출되지 않는 이미지가 있는지 깨지는 부분이 있는지를 확인하는 작업이 요구된다. 그렇게 여러번의 수정 작업을 마치고 페이코 웹 개편 작업 반영을 하게 되었다. 

 이번 같은 경우에는 해당 서비스의 메인 페이지 및 다른 부분도 모두 개편되는 부분이라서 여러 팀이 순서대로 반영을 하는 상황. 테스터 분들도 모두 동참하여 반영이 이루어졌다. 그렇게 모든 팀의 반영 및 테스트 작업이 약 7~8시간에 걸쳐 진행되었고 잘 마무리 짓게 되었다.


[ 문제상황 ]

반영이 끝난 그 다음날 오전 TTS(TROUBLE TICKET SYSTEM) 5급(등급이 낮을 수록 심각 1~5)을 맞게 되었다. 특정 서비스에 문제가 생길 경우 해당 사이트에 문제 상황이 뜨고 담당자에게 연락이 감. 문제는 고객센터 '1:1문의 페이지'에서 문의를 작성한 후 '완료'하는 버튼이 보이지 않는 상황이었다.

 

[동의란 밑에 아무 버튼도 노출되지 않고 있음]



[정상적인 모습]

 

그 문제상황을 보고 받고 속으로 '어떻게 그렇게 테스트를 여러번 했는데 문제가 났다는 게 말이되나?'하는 의구심을 받고 페이지에 접속한 결과 정상적으로 버튼이 노출되고 있는 것을 확인하였다. 그럼 그렇지 하며 익스플로러에서도 확인 결과 정상적으로 버튼이 노출되고 있는 것을 확인하였다. 


[문제원인 & 처리]

그렇게 뭐지???하고 생각하던 중 팀장님께서 외부망으로 접속해보라고 하셨다. 그렇게 외부망으로 접속을 하자 버튼이 노출되지 않고 있음을 파악할 수 있었다. 문제는 변경된 CSS의 버튼의 이미지 경로가 내부망(#밑에 설명) 주소로 박혀있었던 것이다. 보통은 이미지 경로가 해당 작업 하시는 분의 디렉터리 구조에 맞춰 상대경로로 되어 있어 CSS를 받아 적용해보면 어떤 이미지가 없는지 파악이 가능했고 그 이미지를 요청해서 얻어오는 식이었는데 어떻게 보면 뒤통수를 맞은 격이었다. 그것도 딱 해당 2개의 버튼만 "http://{내부망ip}"로 되어 있었던 것이다. 이에 파일을 다운 받아 프로젝트 내에 넣고 경로를 맞추어 준 후 반영을 했지만 뭔가 씁씁한 기분은 가시 질 않았다.


#내부망 

내부망은 일정 조직 내에서 인터넷이 아닌 내부 네트워크를 통해 PC끼리 자원을 공유하게 하거나 그룹웨어 등을 사용할 수 있게 하는 근거리 통신망(LAN, Local Area Network)로 '인트라넷'을 생각하면 이해하기 쉬울 것 같다. 망분리는 현재 정통망법 시행령에 따라 망법 적용을 받는 기업중 개인정보 100만명 이상, 매출액 100억원 이상의 기업은 의무적으로 망 분리를 실시해야고 한다. 보통 보안적인 이슈 때문에 적용하는 듯 하다.


[느낀점]

이런 문제를 처음 경험해 본 나는 적잖이 당황했던 것 같다. 좀 더 꼼꼼히 파악을 했더라면 좋았을 텐데 그렇기엔 그 긴 CSS를 다 파악하기 힘든 상태였고 웹 페이지에 CSS를 적용 후 깨지는 이미지와 CSS에만 초점을 맞춰 작업을 했던게 이런 문제점을 나았다. 외부망으로 한 번 만 확인을 해보았으면 이런 실수가 발생하지 않았을텐데 하는 아쉬움이 남는다. 이번 경험을 계기로 다음부터는 꼭 외부망으로도 접속해 테스트 해보도록 해야겠다. 



똑같은 실수를 반복하지 말자.



반응형

+ Recent posts