May 2, 2019 - 톰켓 버추얼 호스팅 설정하기

server.xml 을 open

4월 30일 hosts 변경 후, 특정 ip로는 접속이 안되는 서버가 있어,
원일을 찾다가 발견했습니다.

단순히, defaultHost 설정이 버추얼 호스팅 주소와 맞지 않았기 때문입니다.

특정 아이피로 호출 했을 경우, 접속되는 아이피는 자동으로 defaultHost 로 변경되게 됩니다.

그런데 vim /etc/hosts 에도 없을 경우에는 톰캣에서 해당 IP를 찾지 못했다고 판단하여 팅겨내게 됩니다.

/etc/hosts 에 없을 경우 server.xml Alias 에라도 등록해두면, 처리됩니다.

<Engine name="Catalina" defaultHost="www.testtest.com">
  <Realm className="org.apache.catalina.realm.LockOutRealm">
    <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
  </Realm>
  <Host name="www.testtest.com"  appBase="webapps" unpackWARs="true" autoDeploy="false">
      <Context path="" docBase="/home/xxx/public_html" reloadable="false" workDir="/home/xxx/public_html/WEB-INF/work"/>
        <Alias>01.testtest.com</Alias>
        <Alias>02.testtest.com</Alias>
        <Alias>01.test001.com</Alias>
        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="/home/xxx/logs/tomcat" prefix="openrtb03.mediacategory.com-access.log-" suffix="" pattern="%h %l %u %t &quot;%r&quot; %s %b &quot;%{Referer}i&quot; &quot;%{User-Agent}i&quot; %Dms &quot;IP_info: %{IP_info}c ,Start_Time: %{Start_Time}c&quot;" fileDateFormat="yyyyMMdd-HH" resolveHosts="false" />
  </Host>
</Engine>

Engine

defaultHost : Host[name]과 일치하지 않는 호스트로 접속시 기본값으로 대처할 호스트입니다.
예를 들어 서버 아이피로 접속했을 경우 자동으로 defaulthost로 변경되게 됩니다.

예제 샘플으로 쉽게 설명하자면,

<Engine name="Catalina" defaultHost="localhost">
	...
	<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
		<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b" />
	</Host>
	...
</Engine>

개인 PC에서 테스르를 위해, 127.0.0.1 로 접속한 경우 아래 Host[name]에는 localhost 밖에 없어 일치하는 것이 없지만 기본값 localhost를 보고 localhost로 할당하게 됩니다.

Host

name : 호스트 이름입니다. 예를들어서 도메인이름 gs.saro.me 로 접속한경우 Host[name]이 gs.saro.me 인것을 찾고 없으면 위 설명처럼 Engine[defaultHost]의 값으로 접속합니다. appBase : 기본 경로입니다. 예를들어 webapps 라면 [톰켓기본경로/webapps] 를 기본으로 접속하게됩니다. autoDeploy(자동 디플로이) : autoDeploy는 속성값이 true로 자동으로 설정됩니다. 빈번하게 재시작하면 안되는 서버의 경우는 무조건 false 로 설정하셔야합니다.

Valve

호스트 접속시 영향을 주는 것들이라고 보면됩니다.
RemoteAddrValve 같이 IP 필터같은 필터 역활을 하는 것도있고 종류도 다양합니다.
AccessLogValve 같은 로그를 남기는 기능도 있습니다. 해당 로그를 남길때는 헤더정보까지 같이 남길수 있어 매우 편리합니다.

Apr 30, 2019 - HOSTNAME 변경

HOSTSNAME 변경하는 법

  1. vim /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=xxxx-WAS-05

호스트 네임 변경.

  1. hostname xxxx-WAS-05

  2. vi /etc/hosts

    127.0.0.1   xxxx-WAS-01 localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    

여기서 3번은 scouter에서,

오류: 에이전트에 예외사항이 발생했습니다. : java.net.MalformedURLException: Local host name unknown: java.net.UnknownHostException: xxxx-WAS-01: xxxx-WAS-01: 이름 혹은 서비스를 알 수 없습니다.

라는 오류가 발생하는 경우가 생겨서 입니다. localhost 가 등록이 되지 않아 못찾는 것이므로 /etc/hosts에 해당 내용을 수정해야합니다.

추가로 서버를 새롭게 설정한 후에 접속이 안되는 이슈가 있었는데, /etc/hosts 에 자기 자신을 호출 할 수 있게 등록을 해줘야하는 것으로 보입니다.

127.0.0.1   xxxx-WAS-01 localhost.localdomain localhost4 localhost4.localdomain4 test.com
10.251.0.xxx test.com

Apr 26, 2019 - baemin_seminar

의식적인 TDD, 리팩토링

4월 우아한 테크 세미나 “의식적인 TDD, 리팩토링” 세미나에 다녀왔습니다. clusternodeImg

규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만 한다.
규칙 2: else 예약어를 쓰지 않는다.
규칙 3: 모든 원시값과 문자열을 포장한다.
규칙 4: 한 줄에 점을 하나만 찍는다.
규칙 5: 줄여쓰지 않는다(축약 금지).
규칙 6: 모든 엔티티를 작게 유지한다.
규칙 7: 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
규칙 8: 일급 콜렉션을 쓴다.
규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.

에서, 1번부터 7번까지에 대해 기초적인 부분부터 자세히 설명해주셨습니다.

평생동안 연습하겠다는 마음가짐으로 시작하고, 결혼하지 않은 사람이라면, 조금더 공부하는 마음가짐을 가졌으면 좋겠다고 하였습니다.

가장 공감이 가던 것은,
회사 소스에 바로 적용하지 말고, 장난감 프로젝트를 찾아서 만들라는 점이었습니다.
회사에 소스를 적용해보고, 리팩토링한 후에 롤백을 한 경험이 몇번 있었기에 더욱더 동감이 되었습니다.

주변 환경에 영향을 받지 않고 꾸준히 연습할 수 있는 환경이라는 것이 매우 중요한거 같습니다.

결론부터 이야기하자면 의식적인 TDD, 리팩토링 세미나에서 요구하고자한 내용은,

1. ELSE 를 쓰지 않는 조건에 대한 논리를 최소화하여 다형성 유도  
2. 객체지향프로그램의 성배인 데이터의 캡슐화  

로 축약할 수 있을 거 같습니다.

결론 : 코드나 아이디어의 중복이 없는 코드를 만들자!

마틴 파울러 형님은 컴퓨터가 이해하는 코드는 어느 바보나 짤 수 있다. 좋은 프로그래머는 사람이 이해하는 코드를 짠다
(Any fool can write code that a computer can understand. Good programmers write code that humans can understand.)고 하셨습니다.

일을 하다보면, 우선순위에 따라 타협을 하게 됩니다.

제가 개발하고 있는 광고솔류션은 모든 응답을 100ms 안에 맞춰야합니다. 시간으로 따지면 0.1초 안에 응답을 해야합니다.

100ms의 대다수의 시간은 nio 관련된 이슈입니다. 데이터베이스나, nosql 등에서 데이터를 가져오는데 걸리는 시간입니다. 그렇기 때문에 제가 어떤 소스를 짜든 속도의 이슈는 없다고 봐도 무방합니다.

그러나, 하드웨어의 발젼으로 제가 짠 소스만 JUNIT으로 검증할 경우 0.00000001ms 안에 응답이 처리되는 경우가 많고, Source 상에 로직에 의해 100ms 가 걸리는 경우는 없습니다.

그러나, 그 소스를 10만번, 100만번 돌렸을 경우에, 리팩토링한 소스와 기존 레거시 코드를 비교했을 때,
레거시 코드의 성능이 더 나은 경우가 더 많아 리팩토링을 할지 그냥 둘지 고민하게 됩니다.

새로운 기술이 오면, 야근을 하든 철야를 하든 시간을 내서 적용해봅니다.

람다를 적용해보기도 하고, 일정을 맞추기 위해 급하게 만든 소스들을 패턴화하여 간결하게 바꾸는 작업등을 해서 사람이 보기 편한 소스를 짜보기도 합니다.

그렇게 해서 테스트한 속도가 조금더 기계적인, 혹은 원시적인 소스를 짠 속도보다는 당연할지 모르겠지만 더 느리게 나옵니다.
그 타협점을 잘 찾아서 회사에 적용해야합니다.

그전에 세미나에서 들은 데로, 개인적인 장난감 프로젝트를 빨리 진행해서 리팩토링에 대한 즐거움을 조금더 재미있게 즐겨야할 거 같습니다.

여담으로 “규칙 9: 게터/세터/프로퍼티를 쓰지 않는다”는 건 좀 어렵지 않을까 싶습니다.

강한 캡슐화를 의미하는 것으로 보이는데요!

인스턴스 변수는 한번 사용했을 경우 해당 클래스에서 전부 사용(동작)한 후 코드를 만질 다른 프로그래머를 위해 단절시키는 것을 원하는 것으로 보입니다.

누군가 해당 인스턴스 변수를 재사용함으로써 중복 오류 등의 문제를 최소화 하고,
캡슐화로 인해 완전 독립적인 객체지향프로그램으로써의 좋은 점이 있을 수 있겠지만,
개발자들의 편의성(?)과 다시금 사용해야하는 중복되는 인스턴스 변수를 다시 생성해야하는 문제가 있을 것으로 보여, 이미 구현된 회사소스에서 적용하기는 어렵고, 장난감 프로젝트에서나 고민해봐야겠습니다.

정확한 세미나에 대한 내용은 참조 주소에서 확인할 수 있습니다. (잘정리되어있습니다.)


참조