와스킹의 사건현장

문자 집합(Character Set)과 인코딩(Encoding)
  문자 집합은 정보를 표현하기 위한 글자나 기호들의 집합을 정의한 것.
  문자나 기호를 컴퓨터에서 저장하거나 통신에 사용할 목적으로 부호화 하는 것을 문자 인코딩이라 하고 인코딩 된 문자 부호를 다시 본래 문자나 기호로 표현하는 것을 복호화(디코딩)이라고 함.

한글문자의 인코딩
  EUC-KR : 2바이트 완성형 인코딩 방식으로 완성된 음절을 코드와 일대일 대응시키는 방식 
    EX) '가' 0xB0A1, '각' 0xB0A2
    
  유니코드 (UTF-7, UTF-8): 하나의 인코딩을 통해 여러가지 문자 집합을 표현할 수 있도록 고안되었으며, 여러가지 유니코드 중 ASCII와 호환이 가능하면서 한글을 표현할 수 있는 UTF-8을 가장 많이 사용.
    ※UTF-8 경우 3바이트로 표현됨

OS Locale
  OS 상에서는 국가와 언어에 따라 다양한 OS Locale을 제공
  Locale에 따라서 입/출력 인코딩을 적용해서 메시지를 출력
    EX) 언어_국가.코드셋 language[_territory][.codeset]
        ko_KR.utf8

  locale 명령으로 시스템의 locale 정보 확인 가능
    LANG - LC_* 값들을 설정하지 않았을 때 적용되는 기본 값
    LC_ALL - LC_* 값으로 override 됨
    LC_TIME - 시간 출력 양식 설정
    LC_NUMBER - 숫자표현양식
    LC_NAME - 이름 표기 형식
    LC_MESSAGES - 시스템 메시지 출력에 사용할 언어
    LC_CTYPE - 바이트를 문자로 변환하거나, 대문자/소문자간의 변환 형식

  java에서는 파일과 소켓등으로 문자열 IO처리시, 문자열의 default charset은 OS Locale 값을 따름.
  default charset은 jvm 옵션 "-Dfile.encoding" 설정을 통해 OS Locale과 다르게 설정 가능.
  
  file.encoding은 파일이나 소켓 등으로 문자열 IO처리 시, 특정 API의 기본값으로 사용.
    System.out.print()는 file.encoding의 영향을 받는다. 
    Out.print()는 response encoding의 영향을 받는다.
    charset을 지정하지 않은 html 또는 jsp 파일은 해당파일을 저장할 때의 인코딩으로 브라우져가 알아서 디코딩 한다.

파일과 인코딩
  한글 파일명의 인코딩
    파일의 이름이 어떤 인코딩으로 서버에 저장되고, 어떤 인코딩으로 다운로드가 되는지는 해당 action을 수행하는 tool에 의해 결정.
      동일한 인코딩으로 업로드와 다운로드를 하지 않는 다면 한글이 깨지게 됨.
  
  파일 내용의 한글 인코딩
    파일 내용의 인코딩은 파일을 최초 생성하여 저장할 때 결정.
      windows의 경우 에디터 및 프로그램에서 원하는 인코딩값으로 저장가능
      Unix 및 Linux에서는 iconv 명령어로 파일내용의 인코딩을 변경 가능
        UTF-8 -> EUC-KR : iconv -c -f utf8 -t euckr utf8.txt > euckr.txt
        EUC-KR -> UTF-8 : iconv -c -f euckr -t utf8 euckr.txt > utf8.txt
    저장된 한글내용을 읽어들일 때 아래와 같은 2가지 경우가 발생
      1. memory에 로딩하는 경우 (file.encoding과 연관)
      2. memory에 로드 하지않고 response로 전달해주는 경우 (response encoding과 연관)

  한글 파일명 업로드
    1. 파일객체를 request 객체를 통해 전달 (전달 시 form을 생성하는 jsp 또는 html의 response encoding으로 전달)
    2. Server의 application 로직에 따른 특정 encoding으로 읽어들여 ememory에 로딩
    3. memory에 로딩된 data를 WAS가 기동 된 OS Locale에 기반하여 파일 생성
   

정의
 Ajax에는 Same Origin Policy 원칙이 적용.
 현재 브라우져에 보여주고 있는 HTML을 응답해준 웹서버(Origin)에게만 Ajax 요청을 보낼 수 있음.
 OpenAPI등의 활성화로 인해 여러 개의 도메인을 사용해야하는 필요성이 높아짐.
 따라서 크로스도메인간에도 Ajax 요청을 주고 받을 수 있는 방법을 표준화 함. 그것이 CORS(Cross-Origi Resource Sharing) 임.
 CORS는 크로스도메인에 위치한 웹서버가 응답에 적절한 Access-Control-Allow-류의 헤더를 보냄으로써 크로스도메인 Ajax를 허용 할 수 있음.
 ※IE는 IE8부터 지원
 
예시
 기본적으로는 한 페이지에서 서비스 되는 도메인이 2개 이상이 되면 browser에서 다른 도메인 resource 사용을 reject
 해당 기능을 쓰고 싶으면 WEB서버에서 크로스도메인 설정이 필요

 a.com 에서 b.com의 자원을 호출하고 싶다.

 b.com 의 WEBTOB 설정에 다음과 같이 추가

 *HEADERS
 xFrame    Action = "AddResponse",
           FieldName = "Access-Control-Allow-Origin",
           FieldValue = "https://a.com"


 *Vhost
      Headers = "xFrame",

NTP에 대한 고찰
ntp는 straum 이라는 계층 구조를 가짐
straum 0  -> GPS나 원자시계등의 직접 시간을 구하는 장비
straum 1  -> straum 0에서 구한 시간을 동기화 해주는 서버들

보통 straum 2 에서 동기화를 하고 동기화를 받은 straum 3 서버에 나머지 같이 운영하는 서버들을 peer로 함.
이 트리구조는 ntp사용의 부하를 줄이기 위함. 만약 straum 1로 모두 붙어서 사용하게 된다면 서비스가 유지가 힘듬.
통상적으로 ntp는 UDP 123포트 사용.

[etc]  /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
+sws1         10.10.10.*      2 u  713 1024  377     1.60   -0.739    0.18
*sws2         10.11.10.*      2 u  573 1024  377     0.64    0.085    0.08

항목 설명
*  현재 sync 받고 있음
+  접속은 가능하지만 sync를 하고 있지 않음
-  접속은 가능하지만 sync 가능리스트에서 제외
공백 접속불가

remote - sync를 하는 straum 서버의 주소
refid - straum 2 서버가 현재 sync를 하고 있는 straum 1 서버
st - remote의 straum 넘버
t - 시간을 받아보는 방식 (uniquest, multicast, broadcast)
when - ntp 서버로 부터 데이터를 수신한 후 경과 시간 (초)
poll - ntp 서버에 sync 요청 주기
reach - 최근 8번 poll 요청에 대한 응답 여부
delay - network 지연시간 (ms)
offset - ntp 서버와 자신의 시간차이 (ms)

/etc/ntp.conf 에 대한 설정
# restrict 설정은 peer 들이 본 서버로 sync 하는 것에 대한 제한
restrict 127.0.0.1
restrict -6 ::1

# NTP 서버 설정
server shcws01
server shcws02  prefer

# driftfile 은 시간 오차치를 보존해 두는 파일 ntpd 데몬에 의해 자동 생성
driftfile /var/lib/ntp/drift

# 인증 받기 위한 key가 저장되는 파일
keys /etc/ntp/keys

개요
 JEUS로그에서 다음과 같은 메시지 발생
[2019.04.07 00:02:06][1] [ms-66] [WEB-3322] Worker (webtob_ms-hth0-7): Reading the request header from Socket[Ip:port, local=47488], sid=2 failed because of java.net.SocketTimeoutException: Read timed out
[2019.04.07 00:02:06][1] [ms-63] [WEB-3322] Worker (webtob_ms-hth0-4): Reading the request header from Socket[ip:port, local=47508], sid=28 failed because of java.net.SocketTimeoutException: Read timed out
[2019.04.07 00:02:06][1] [ms-76] [WEB-3322] Worker (webtob_ms-hth0-17): Reading the request header from Socket[ip:port, local=47530], sid=20 failed because of java.net.SocketTimeoutException: Read timed out

현상 
 DAS에서 MS에 대해 조회시 FAILED라고 뜨는 경우가 발생, USER의 서비스 처리 지연

원인
 WEBTOB에서 JEUS로 연결을 체크하는 부분과 JEUS에서 WEBTOB의 요청을 기다리는 부분에서 상충하여 발생

WEBTOB 설정의  SvrChkTime
*SERVER
ms            SVGNAME = jsvg_ms,            MinProc = 30,  MaxProc = 30, SvrChkTime = 300, Schedule=FA

JEUS 설정의 Read Timeout
DAS WEBADMIN - MS - Engine - WEB Connection - Read Timeout = 120000

여기에 설정된 시간 동안 WebtoB로부터 아무런 메시지가 오지 않는다면 커넥션에 문제가 있다고 간주하고 새로 맺는다.
WebtoB와 JEUS 사이에 방화벽이 있을 경우, WebtoB가 보내는 Ping 메시지 도착 여부를 이 설정으로 체크할 수 있다.

따라서 WEBTOB에서 JEUS로 연결을 체크하는 주기는 300초 이지만, JEUS에서는 120초가 지나면 연결을 끊도록 되어 있었기 때문에 발생한 문제

해결방안

 WEBTOB 설정의 SvrChkTime보다 JEUS 설정의 Read Timeout이 크도록 설정
 JEUS 설정의 Read Timeout을 500초로 지정하여 해결

 

개요
 AP서버에서 WAS의 JDBC Connection이 JDBCConnectionTimeout 발생

현상
 DB서버(2대-RAC구성) 재기동 이후 JDBC Connection 시도 시 JDBCConnectionTimeout 발생


원인
 1) 비정상 JDBC Connection을 확인하여 제거하는 WAS의 JDBC Connection 설정이 없음
 2) DB서버에 대해 RAC 구성이 되어 있지만, 설정의 primary가 크로스로 구성되어 있지 않았음.
    AP1 - DB2 , AP2 - DB2 =====TO-BE======> AP1 - DB1 , AP2 - DB2

 3) 현상 유발원인 예상 시나리오
  1. DB2의 서버 종료
  2. AP1, AP2 모두 DB1로 fail-over
  3. DB2의 서버 기동
  4. DB1의 서버 종료
  5. AP1, AP2 에 DB1로의 비정상 연결이 잔재
   
 
해결방안
 1) WAS에 아래의 설정을 추가하여 비정상 JDBC Connection을 제거 할 수 있도록 함.
  ※Tmax사의 권고 사항으로 RAC구조의 Datasource 설정을 할 시에는 아래의 설정이 필수

                    <check-query>SELECT 1 FROM dual</check-query>
-> 어플리케이션이 JDBC 커넥션 요청을 했을 때(getConnection) 특정 select 쿼리를 보내서 커넥션의 상태를 점검(validation)하는 기능이다.
                    <check-query-period>120000</check-query-period>
-> JDBC 커넥션을 일정 시간마다 체크하여 문제가 있는 커넥션을 닫아준다.
                    <check-query-timeout>15000</check-query-timeout>
-> check-query를 했을 때 DB 상황에 따라서 JDBC 드라이버가 응답을 못 받고 계속 기다릴 수 있다. 그에 대한 timeout
                    <non-validation-interval>5000</non-validation-interval>
-> connection 단위로 check-query를 할 때 마지막으로 커넥션을 사용한 시각과 현재 시각과의 차이가 어떤 시간 간격보다 작으면 체크하지 않는다. 
                    <destroy-policy-on-check-query>AllConnections</destroy-policy-on-check-query>
->JDBC 커넥션 유효성 체크가 실패했을 경우 해당 커넥션 풀에 있는 커넥션들을 어떻게 할지 정책을 결정하는 옵션이다.

해당 설정으로 인해 fail-bak이 실패한 모든 커넥션이 종료되고 새로이 커넥션을 맺으면서 문제가 없어짐.

하지만 Tmax에서는 해당 설정을 통한 fail-back을 보장하지 않으며, fail-back이 필요한 경우 재기동을 권고함

 2) RAC 설정의 primary를 크로스가 되도록 구성
    AP1 - DB1 , AP2 - DB2

 
WEBTOB 큐잉 중인 요청 건 인데 클라이언트 연결을 끊으면 어떻게 되는지??

 1) 연결 끊김 인지되서 큐잉에서 제거 or JEUS 로 전달하지 않음
  -> cqcnt가 증가하는 큐잉인 상태인 경우
    cqcnt에서 대기 중인 클라이언트가 연결을 끊으면 webtob에서 큐잉 제거 및 JEUS로 해당 연결을 전달하지 않습니다.

  log keyword
   jsv: Premature client close
 
 2) 일단 JEUS 전달까지 되어 로직도 다 수행되고 완료 후 클라이언트로 응답 줄 때 끊김 인지하여 에러로그 발생
  -> cqcnt가 아닌 정상적인 Thread 요청에 대해 Client가 응답을 받기 전 연결을 끊으면 응답 시 끊김에 대한 인지와 함께 에러로그 발생합니다.

  log keyword
   Client has closed connection. Discard response message