IT PROGRAM & 가상화폐 SINCE 2006

과속카메라 단속 기준

영진은정아빠 — Thu, 3 Jul 2025 16:20:43 +0900

시민들이 운전 중 가장 민감하게 반응하는 순간은 신호가 막 바뀌는 교차로에서 “노란불을 지나도 될까?” 하는 찰나, 그리고 과속카메라 앞에서 “조금 빨라도 괜찮겠지?”라고 생각할 때입니다.

그런데 실제로는 몇 km/h까지 과속이 허용되는지, 카메라가 인식하는 기준이 어떻게 되는지 정확히 아는 운전자는 많지 않습니다.

이 글에서는 도로교통법, 단속장비의 기술기준, 그리고 현장 운영 관행을 바탕으로, “속도와 신호 단속의 허용오차”를 설명합니다.

과속단속, 몇 km/h까지 허용되나?

법적 기준 자체는 단속 여지 없이 “1km/h라도 초과하면 위반”입니다. 하지만 현실적으로는 기술적 오차와 행정 실효성 문제로 인해 일정 범위 내의 초과는 ‘단속 유예’되는 관행이 존재합니다.

* 실제 허용오차 범위

과속카메라 기준 허용오차는 다음과 같습니다.

➤ 약 속도 제한 + 10% ± 약간의 여유

➤ 예 : 제한속도 100km/h 구간 → 최대 110~113km/h 정도까지는 단속 유예

* 관련 근거

「자동차 속도측정기 성능 기준」(국토교통부 고시)에 따라, 과속카메라의 측정 정확도는 ±3km/h로 규정되어 있음. 따라서 경찰청, 지자체는 제한속도의 약 10%까지 유예하도록 운영하는 사례가 많음 (관할청의 내부 지침에 따라 달라짐)

다만 단속 유예가 공식 면책은 아니며, 특정 캠페인 기간이나 사고 다발 구간에서는 1km/h 초과도 단속 대상이 될 수 있습니다.

신호 단속 카메라 – 노란불에 걸려도 위반일까?

많은 운전자가 노란불일 때 진입했는데 적발되었다고 주장하는 사례가 있습니다. 하지만 실제 신호 단속은 다음과 같은 방식으로 작동합니다.

* 신호 단속 작동 방식

- 적색 신호가 들어온 이후 교차로 정지선을 넘으면 적발

- 노란불일 때 진입한 경우는 적발되지 않음

- 단, 노란불 후 적색으로 바뀐 뒤 진입하면 적발 대상

* 기술적 조건

대부분의 신호 단속 카메라는 ‘적색 신호 후 0.3~0.5초 지연시간’을 설정하여, 급정지 회피나 신호전환 인지 지연을 고려함

고정식 카메라 설치 예시

복합단속카메라 : 신호와 속도 동시에 단속

최근 설치되는 고정식 카메라는 신호와 속도를 동시에 단속하는 복합단속장비(디지털 영상녹화장비)가 많습니다.

단속 조건	기준
신호위반	적색등 점등 후 정지선 통과
과속위반	제한속도 +10% 초과 (±3km/h 오차 고려)

단, 신호위반과 과속을 동시에 한 경우, 두 건 모두 단속될 수 있습니다.

실전 팁 : 단속 안되려면?

제한속도 +5km/h 이내로 운행 → 오차 포함해도 안전지대
신호등 ‘황색’일 때는 멈출 준비 → 적색 전 진입 여부가 관건
복합단속구간 표지 확인 → ‘단속카메라 있음’ 표지판 무시 금물

고정식 카메라의 단속원리

이동식 카메라 단속원리

한편, 많은 운전자분들께서 도로를 주행하시다 보면 가장 자주 접하게 되는 단속 경고 중 하나가 내비게이션을 통해 안내되는 “전방 500m 앞, 이동식 과속 단속구역입니다. 서행하십시오.”라는 음성 안내입니다.

현재 전국적으로 약 900여 곳에 이동식 단속구역이 설치되어 있으나, 실제로 단속 장비가 상시 운용되고 있는 곳은 그리 많지 않습니다.

허울뿐인 이동식 카메라 부스

실제로 경찰이 보유한 이동식 단속 장비는 약 300여 대 수준으로, 전체 단속 부스의 3분의 1 정도만 실제로 단속이 가능한 실정입니다. 이 중에는 정비 중이거나 야간에는 사용이 불가능한 장비도 다수 포함되어 있어, 실질적으로 단속이 이루어지는 경우는 제한적입니다.

또한, 투광기 등 보조장비의 부족과 단속 인력의 한계로 인해 야간 시간대에는 단속이 거의 이루어지지 않는 것이 현실입니다.

이로 인해 “단속도 안 하면서 겁만 준다”, “또 빈 부스에 속았다”는 불만이 운전자들 사이에서 꾸준히 제기되고 있습니다. 그럼에도 불구하고 경찰은 이러한 이동식 단속 부스 설치만으로도 과속을 억제하는 효과가 있다고 판단하고 있으며, 운전자들에게 심리적 경각심을 유도함으로써 교통사고 예방에 기여할 수 있을 것으로 기대하고 있습니다.

마무리하면서

과속카메라와 신호위반 단속은 단순히 '벌금 부과'를 위한 시스템이 아니라, 교통사고를 줄이고 도로 위 안전을 유지하기 위한 예방 중심의 공공기술 인프라입니다. 기술적으로 오차 허용 범위는 존재하지만, 법적으로는 1km/h 초과도 단속 대상이 될 수 있으며, 특히 사고 위험이 높은 지점이나 보호구역에서는 미세한 속도 초과도 정밀하게 포착됩니다.

또한, 최근엔 단속 기술도 급속히 고도화되고 있습니다. 고정식 및 이동식 단속 장비 외에도, 전국 주요 고속도로와 도시 간선도로에는 구간단속 시스템이 확대 설치되어 ‘캥거루 운전’이나 단속구간만 감속하는 얌체 운전까지 체계적으로 차단하고 있습니다.

더 나아가, 2020년대 이후 경찰청과 국토교통부는 암행순찰차·헬기·드론을 활용한 비가시적 단속체계를 적극 도입했습니다.

예를 들어, 600m 상공에서 차량 번호판까지 식별 가능한 고성능 카메라를 장착한 경찰헬기, 그리고 3천만 화소급 카메라를 탑재한 드론은 주요 고속도로의 병목지점과 지정차로 위반·끼어들기·갓길운행 등을 실시간으로 단속하고 있습니다.

속도로 법규 위반 단속에 나선 헬기와 드

이러한 공중 단속 시스템은 단속 사각지대를 최소화하고, 운전자의 인식 개선 및 교통법규 준수를 유도하는 데 매우 효과적인 것으로 평가받고 있습니다.

결국 단속 기준을 회피하려는 정보 탐색보다 중요한 것은, ‘속도제한은 곧 생명 보호의 기준’이라는 원칙적 인식입니다.

속도를 지키는 것은 단속 회피가 아닌, 나 자신과 타인의 안전을 지키는 첫 걸음임을 기억해야 합니다.

#과속카메라 #신호위반 #단속기준 #속도초과 #운전자정보 #교통안전 #도로교통법 #복합단속카메라 #운전팁 #운전자상식 #황색신호 #정지선단속 #단속오차 #교차로주의 #자동차단속

출처 : https://blog.naver.com/gulgomi/223898208191

'서머타임' 오는 일요일, 11월 3일 해제

영진은정아빠 — Wed, 19 Feb 2020 11:13:44 +0900

올해 서머타임(Daylight Saving Time·DST: 일광절약시간제)이 오는 일요일, 11월 3일 오전 2시 해제된다. 3일 오전 2시를 1시로 한시간 뒤로 돌리면 된다. 이를 보통 Fall Back(서머타임 시작은 Spring Forward)이라 한다.

이에 따라 뉴욕, 워싱턴DC 등 미 동부지역과 한국의 시차는 13시간에서 14시간으로, LA등 서부는 16시간에서 17시간으로 각각 늘어난다. 즉 미국 동부시간 11월 3일 오전 7시는 한국시간으로는 14시간 빠른 3일 오후 9시가 된다. 서머타임 해제 후 미국 다른 지역과 한국의 시차를 보면 △시카고 등 미국 중부지역 15시간 △덴버 등 산악지역 16시간 등이다.

다만 하와이와 사모아, 괌, 푸에르토리코, 미국령 버진 아일랜드, 애리조나주 등은 서머타임을 적용하지 않아 이에 해당되지 않는다.

미국에서는 연방정부의 허가를 받으면 서머타임을 도입하지 않을 수도, 일년 내내 도입할 수도 있다. 현재 7개주-Alabama, Arkansas, Florida, Nevada, Oregon, Tennessee and Washington- 는 영구 서머타임(permanent DST) 도입을 의결하고 연방정부의 승인을 기다리고 있다. 반면, 텍사스는 서머타임없이 기준시를 유지하는 안을 고려하고 있다.

서머타임 제도는 낮이 길어지는 여름철에 표준시를 한 시간 앞당겨 에너지를 절약하고 경제활동을 촉진한다는 취지로 세계 70여 개국에서 시행 중이다. 1차 세계대전 당시 연료를 아끼기 위해 도입된 서머타임제는 2차 세계대전 이후 폐지됐다가 미국에선 1967년, 유럽에선 1996년부터 다시 시행됐다.

미국과 캐나다 등 북미지역의 서머타임제는 매년 3월 둘째주 일요일 오전 2시부터 11월 첫 번째 일요일 오전 2시까지 시행된다.

[MySQL, MariaDB] Redo log 속도Insert (innodb_flush_log_at_trx_commit

영진은정아빠 — Tue, 10 Sep 2019 10:17:00 +0900

innodb_flush_log_at_trx_commit

MySQL, MariaDB에서 사용되는 Redo log 옵션(innodb_flush_log_at_trx_commit)에 대해 알아본다.

Redo log의 기록 옵션은 총 3가지로 innodb_flush_log_at_trx_commit 옵션에 의해 결정된다.

innodb_flush_log_at_trx_commit 는 커밋 로그에 대하여 Disk Flush를 언제 발생 시킬지에 대한 옵션이다.
기본값은 1로 설정이 되어있고 1은 트랜젝션이 발생할 때마다 디스크에 플러시가 발생한다.
2로 설정하면 1초마다 디스크로 플러시가 발생하게되고, 그만큼 io가 줄어들기때문에 성능 향상을 기대할 수 있다.
(단 장애시 1초 정도의 트랜젝션은 유실될 수 있다.)

1. innodb_flush_log_at_trx_commit 0

: 1초 간격으로 Disk에 Flush(저장)

: 트랜잭션(commit, rollback)에 관계없이 1초 간격으로 disk에 기록하므로, disk 쓰기 요청이 많은 편이며, 1초 간격이라는 의미로 데이터의 안정성이 보장되는 편(1초내외)

2. innodb_flush_log_at_trx_commit 1 (default)

: 트랜잭션 시(commit, rollback) 로그 파일과 데이터 파일에 기록로그 버퍼는 각 트랜젝션이 실행될 때마다 로그 파일에 기록되고 로그 파일에서 디스크 연산에 대한 플러시가 실행된다.

3. innodb_flush_log_at_trx_commit 2

: 트랜잭션 시(commit, rollback) 로그 파일에만 기록, 매초 데이터 파일에 기록

* 위에서 언급된 1초 간격의 Flush는 프로세스 스케쥴링에 따라 차이가 발생할 수 있다.

성능 차이는 1이 가능 느리지만, 데이터 보장에 대한 설정은 1이 가장 좋다.

성능을 우선으로 생각하는 시스템의 경우 0, 2 옵션을 추천.

[CentOS 7] MongoDB(몽고DB) 설치 가이드

영진은정아빠 — Thu, 29 Aug 2019 09:23:18 +0900

몽고DB

CentOS 7 몽고DB 설치 가이드

몽고DB는 크로스 플랫폼 도큐먼트 지향 데이터베이스 시스템이다. NoSQL 데이터베이스로 분류되는 몽고DB는 JSON과 같은 동적 스키마형 도큐먼트들을 선호함에 따라 전통적인 테이블 기반 관계형 데이터베이스 구조의 사용을 삼간다.

[출처 : 위치백과]

* 설치되는 몽고DB 버전은 4.2버전을 기준으로 한다.

1. CentOS YUM 리파지토리(repository) 추가하기

몽고DB는 CentOS에 기본 리파지토리에 포함되어 있지 않다. 리파지토리 파일을 생성하기 위해 아래 내용을 입력하여 파일을 생성한다.

경로 : /etc/yum.repos.d/mongodb-org.repo

$[mongo@localhost ~]# sudo vi /etc/yum.repos.d/mongodb-org.repo

[mongodb-org-4.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

리파지토리 등록확인

$[mongo@localhost ~]# yum repolist

. . .
repo id                          repo name
base/7/x86_64                    CentOS-7 - Base
mongodb-org-3.2/7/x86_64         MongoDB Repository
. . .

2. 몽고DB 설치하기

YUM 리파지토리에 등록을 완료하였으므로 설치는 YUM을 이용해서 설치한다.

$[mongo@localhost ~]# sudo yum install mongodb-org

위의 yum install mongodb-org 커멘드를 이용해 설치가 완료 된다.

3. 몽고DB 시작, 종료, 상태 확인

- 시작

$[mongo@localhost ~]# sudo systemctl start mongod

- 종료

$[mongo@localhost ~]# sudo systemctl stop mongod

- 상태 확인

$[mongo@localhost ~]# sudo systemctl status mongod

4. 몽고DB 로그 확인

- 몽고DB 실행 로그는 아래 경로에서 확인 가능하다.

경로 : /var/log/mongodb/mongod.log

$[mongo@localhost ~]# tail /var/log/mongodb/mongod.log

이상으로 CentOS 7에서 MongoDB(몽고DB) 설치를 마친다.

Java, max user processes, open files

영진은정아빠 — Thu, 25 Apr 2019 15:10:19 +0900

올해 사내 블로그 포스팅 주제로 Linux의 open files, max user processes 설정에 대해 정리하게 되었습니다.

계기는 단순했습니다.
팀에서 서버 작업하던 중 쓰레드와 관련해서 문제가 발생했는데요.
제가 진행하던 일이 아니라서 옆에서 해결하는 과정을 지켜봤습니다.
부끄럽게도 전혀 모르는 내용이 오고 갔습니다.
복기가 필요하단 생각에 정리를 진행 하던 중, 이왕 하는김에 회사 블로그에 올리면 좀 더 자세히 공부하지 않을까 하는 마음에 선택하게 되었습니다.

(퀄리티는 에피타이저, 마음만은 메인 디쉬로 가겠습니다!)

여기에서 사용된 코드는 실제 회사에서 사용한 코드는 아니며, 포스팅을 위해 최대한 유사하게 만들어진 별도의 샘플 코드임을 먼저 말씀드립니다.

1. Max user processes

Linux에는 OS 레벨에서의 제한 설정이 있습니다.
보통 이를 ulimit (user limit) 이란 명령어로 확인하는데요.
2가지 옵션으로 대부분 확인합니다.

ulimit -a
- soft ulimit
ulimit -aH
- hard ulimit

톰캣을 이용해서 서버 운영 도중, 다음과 같이 OutOfMemoryError가 발생했다고 가정하겠습니다.

더이상 쓰레드를 생성할 수 없다는 에러인데요.
뭐가 문제였는지 하나씩 확인해보겠습니다.
맨 처음 서버를 할당 받은 초기 상태 그대로라 ulimit -a는 아래와 같습니다.

화면을 보시면 open files 와 max user processes의 값이 1024로 동일하게 잡혀있습니다.
쓰레드 생성에 문제가 발생한거라 max user processes가 문제인것 같지만, 확신할 수 없으니 테스트 환경을 구축해서 실험해보겠습니다.

테스트용 서버는 AWS EC2의 t2.micro입니다.
t2.micro로 생성후 ulimit -a로 확인해보겠습니다.

t2.micro는 기본 설정이 open files가 1024, max user processes가 3902로 잡혀있다는 것을 알 수 있습니다.

자 그럼 간단하게 추측할 수 있는 것이, 현재 설정에서 1024 <= 동시에 생성가능한 쓰레드수 <= 3902라면 max user processes가 부족해서 발생한 문제임을 알 수 있겠죠?
이를 확인하기 위해 간단한 스프링부트 프로젝트를 생성하겠습니다.

코드는 간단합니다. /4000으로 HTTP 요청이 오면 비동기로 4천개의 쓰레드를 동시에 생성하고, 20분간 유지합니다.

프로젝트를 테스트용 EC2에 배포하고 curl과 tail -f nohup으로 확인해보겠습니다.

사진속을 보시면 3855번째에서 unable to create new native thread 에러 메세지가 발생했습니다.
즉, open file 제한인 1024개를 초과해서 쓰레드가 생성된 것입니다!
max user processes만큼만 쓰레드가 생성된것을 확인할 수 있습니다.

Linux에서는 프로세스와 쓰레드를 동일하게 봅니다.

2. Open files

두번째로 위에 있던 open files 값은 어떤 값을 가리키는지 알아보겠습니다.
open files에 관해 검색을 해보면 이 값이 프로세스가 가질 수 있는 소켓 포함 파일 개수를 나타낸다는 것을 알 수 있습니다.

자 그럼 소켓을 open files 값 보다 많이 만들면 어떻게 되는지 테스트 해보겠습니다.
테스트 방법은 간단합니다.

RestTemplate로 다른 서버로 API요청 (소켓 생성)을 보내고, 해당 서버에서는 20분간 응답을 대기 시킵니다.
위 요청을 동시에 1100개를 보냅니다.
open files의 제한이 1024개이기 때문에 1100개가 발송되기전에 open files 관련된 에러가 발생하면 실험 성공!
- Java, Spring을 실행시키면 기본적으로 몇개의 file이 오픈됩니다.
- 이를 계산하면서 하기가 애매하니, 1100개를 보내면 기본 open된 파일 + 추가 생성된 파일을 합쳐서 1024개가 넘어가는 시점에 에러가 발생한다는 계산입니다.

API 요청을 받아, 20분간 대기시켜줄 서버로 ec2를 한대 더 생성합니다.

테스트에 사용한 코드는 다음과 같습니다.

요청을 보낼 메소드

RestTemplate 타임아웃이 먼저 나면 안되기 때문에 타임아웃을 30분으로 지정합니다.

요청을 받을 메소드

자 그리고 동시에 1100개의 요청을 보낼수 있도록 간단한 비동기 요청 스크립트를 만듭니다.

(실제 운영환경에선 Ngrinder등을 통해서 하겠지만, 여기선 간단한 테스트이니 스크립트로 대체합니다.)

준비가 다 되었으니 한번 테스트를 진행해보겠습니다!

…..

테스트를 진행하자마자 바로 에러가 발생했습니다.
로그를 확인해보니

단순 쓰레드 생성과 달리, EC2의 서버 메모리가 먼저 부족해져서 EC2 사양을 높여서 다시 실험하겠습니다.

(t2.micro는 메모리가 1GB인지라, t2.large (8GB) 로 변경합니다.)

업데이트된 EC2의 ulimit은 아래와 같습니다.

AWS EC2의 사양을 올릴수록 max user processes가 적절한 값으로 증가하는 것을 확인할 수 있습니다.
이를 통해 알 수 있는 것은, AWS EC2를 사용하실 경우 max user processes AWS 내부에서 인스턴스 사양에 맞게 적절한 값을 세팅해주니, 굳이 저희가 손댈필요는 없다는 것입니다.

자 그럼 다시 한번 테스트를 해보겠습니다.
테스트용 서버에 프로젝트를 배포하고, 해당 프로젝트가 생성한 open file count를 아래 명령어로 확인합니다.

ls -l /proc/$PID/fd | wc -l

PID를 찾고,

생성된 open file 리스트를 확인할 수 있습니다.
준비가 다 되었으니, 1100개 요청을 보내는 스크립트를 실행해봅니다!

엇?
결과가 뭔가 이상합니다.
분명 open files의 값은 1024개로 되어있는데 1330개가 열려있다고 나오다니요.

이상하다는 생각에 스크립트를 몇번 더 실행합니다.
(한번 실행때마다 1100개의 요청이 간다고 생각하시면 됩니다.)

2번을 추가로 더 실행해서 3300개의 요청이 갔음에도 에러없이 처리되고 있습니다.
언제 터지는지 확인하기 위해 추가로 더 요청해봅니다 (총 4400개가 갑니다.)

드디어 Open File 에러가 발생했습니다!
보시면 4097개까지만 열린채로 에러가 발생한 것을 알 수 있는데요.
이전 요청이 3532개를 생성했으니 추가로 1100개를 요청하면 4600개 이상이 생성되어야하는데 왜 4097개까지만 생성된 것인지 궁금합니다.

혹시나 하는 마음에 ulimit -aH로 soft가 아닌, hard옵션을 확인해봅니다.

오?
마침 딱 4096개 입니다!
프로세스별 open file은 soft 값이 아닌 hard 값까지 생성가능한게 아닐까? 라는 추측이 됩니다.
검증하기 위해 hard의 open files를 5120개로 증가시킵니다.
(soft 옵션은 그대로 1024개 입니다.)

자 그리고 다시 요청을 진행해보겠습니다.
이번에 4096개가 넘는 요청이 가능해진다면 soft가 아닌, hard 값까지 생성 가능하다는걸 알수있겠죠?

예상대로 4000개가 넘는 API 요청 (4635)이 가능해졌습니다!

실제로 ulimit -a로 확인할 수 있는 soft 값으로 소켓 생성이 제한되지는 않는다는 것을 알 수 있습니다.
결국 소켓 생성 제한은 hard 옵션에 따라간다 라는 이야기가 됩니다….

이 글을 마무리하려던중, 깜짝 놀랄 이야기를 들었습니다.

파이썬은 안그러는데요?

추가

제보를 해주신 배민찬의 모 선임님과 함께 확인을 해봤습니다.
soft limit으로 1024, hard limit으로 4096인걸 확인하고, 파이썬 스크립트로 file을 임의로 열어봅니다.

여기서 3개를 빼야하는 이유는 stdin, stdout, stderr의 표준 입/출력이 포함됐기 때문입니다.

1021개에서 1개를 더 추가하니 바로 Too many open files Error가 발생합니다!
헉? soft 옵션이 파이썬에서 잘 적용된걸까요?

진짜 그런지 한번 더 확인해봅니다.
open files soft 값을 2000으로 증가시킨후 다시 1997개가 넘는 file을 open 해봅니다.

여기서도 마찬가지로 1997개 이상 file open시에 바로 Too many open files Error가 발생합니다.

왜 파이썬은 soft옵션까지만 file이 오픈되고, Java에선 hard 옵션까지 file이 오픈되는건지 이상했습니다.

이상하단 생각에 strace로 JVM 로그를 확인해보니!

이렇게 setrlimit으로 limit을 업데이트하는 로그가 찍혀있습니다!

왜 이런 로그가 발생했는지 오라클 Java 옵션을 찾아봤습니다.
문서에는 MaxFDLimit 라는 옵션이 있었는데요, 뭔가 file limit과 관련돼 보입니다.

이 옵션이 뭔지 찾아보니 openjdk 코드에서 이 옵션이 true일 경우 setrlimit 으로 limit을 증가시키는 것을 확인할 수 있습니다.

그리고 설치된 Java의 MaxFDLimit 기본값이 true임을 확인할 수 있습니다.

즉, 리눅스 OS 환경에서는 JDK 실행시 자동으로 limit 사이즈를 증가시켜준다는 것을 알 수 있습니다.

결론

위 2개의 실험으로 얻은 결론입니다.

Java에서 동시에 생성 가능한 쓰레드 수는 max user processes를 따라간다.
Java에서 소켓 통신(HTTP API, JDBC 커넥션 등)은 open file 옵션을 따라간다.
- 단, JDK 내부 코드상에서 hard limit 값이 soft limit에 update된다.

참고로 Tomcat은 8 버전부터 기본 Connector 방식을 NIO로 사용합니다.
(7 버전까지는 BIO)
그러다보니 maxConnections은 10,000, maxThreads는 200이 기본값입니다.
(BIO에서는 둘의 값이 동일해야 합니다)
이번 테스트에서 사용되는 connection 수가 1만을 넘지 않기 때문에 기본옵션으로 진행했습니다.

번외) limit 옵션 설정방법

보통 soft limit과 hard limit을 다르게 설정하진 않습니다.
둘의 값을 동일하게 적용하는데요.
서버의 open files, max user processes등 옵션을 permanent (영구) 적용하기 위해선 /etc/security/limits.conf 을 수정하면 됩니다.

맨 앞의 *가 있는 자리는 사용자 계정을 나타냅니다.
ec2-user로 지정하시면 ec2-user 계정에서만 옵션이 적용되는데요.
이미지처럼 *로 지정하시면 모든 사용자 계정에 옵션이 적용됩니다.

이렇게 적용후, 다시 접속해서 확인해보시면!

옵션이 잘 적용되어있음을 확인할 수 있습니다.

마무리

제가 준비한 내용은 여기까지입니다.
좋은 기회로 그 동안 막연하게 알고 있던 max user processes, open file를 제대로 정리해볼 수 있었습니다.

부족함이 많은 글임에도 끝까지 읽어주셔서 감사합니다.
다음에도 이와 같이 기본적인 내용이지만, 프로젝트에서 도움을 받는 일이 발생한다면 잘 정리해서 공유드리겠습니다.
그럼, 다음에 또 뵙겠습니다.
감사합니다!

(사용된 모든 짤은 레진코믹스의 레바툰입니다.)

참고

Google Cloud의 Speech API 사용해보기

영진은정아빠 — Thu, 13 Sep 2018 17:41:16 +0900

Google Cloud의 Speech API 사용해보기

아래 내용은 https://jungwoon.github.io/google%20cloud/2018/01/17/Speech-Api/ 사이트가 출처 입니다.

이번에는 구글의 Speech API를 한번 정리해보도록 하겠습니다.

Speech API는 구글의 머신러닝 기술을 이용하여 음성을 분석해주는 기술입니다.

크게 아래와 같은 기능들을 이용할 수 있습니다.

오디오를 텍스트로 변경
노이즈 켄슬링
스트리밍 제공
전 세계 80가지 이상의 언어와 방언을 인식

자세한 부분은 공식 문서를 확인해주세요

사전 준비

이제 개발을 하기 전에 필요한 사전 설정부분에 대해서 설명 드립니다.

Cloud Translation API 사용 허용해주기

먼저 Cloud Translation API의 사용 설정을 해줍니다.

Google Cloud Console에서 아래와 같이 speech로 검색을 해줍니다.

아래와 같이 나오면 사용 설정을 눌러서 API를 Enable 해줍니다.

gcloud sdk 설치 후 인증받기

우선 Google Cloud SDK(=gcloud) 설치하기를 참고하여 gcloud 설치를 먼저 해줍니다

그 다음 gcloud auth login을 터미널에 입력을 해줍니다

그럼 아래와 같이 브라우저가 뜨면서 구글 계정을 선택하는 화면이 나오는데, 해당 프로젝트 계정을 클릭합니다

그럼 다음과 같이 권한 요청이 나오는데, 허용을 누릅니다

서비스 계정키를 다운 받아서 .bashrc에 등록하기 및 사용설정하기

GCP 서비스를 이용하기 위한 서비스 계정 키를 얻기 위해 Google Cloud Console에서 메뉴 - API 및 서비스 - 서비스 계정을 누릅니다

아래와 같이 나오면 우측에 메뉴를 누르고 키 만들기를 누릅니다

그럼 아래와 같이 JSON 또는 P12를 선택하라고 하는데 여기서는 JSON을 선택하고 생성 버튼을 누릅니다

그럼 자동으로 Local로 다운로드 받아지게 됩니다

(한번밖에 다운로드 되지 않기 때문에 잘 보관해야 합니다)

그 다음 vi ~/.bashrc를 입력을 합니다. (다른 쉘을 쓰면 거기에 맞는걸 열어줍니다)

아래의 105번 라인과 같이 위에서 다운받은 서비스 계정 키의 경로를 GOOGLE_APPLICATION_CREDENTIALS에 넣어줍니다

## Google Cloud
export GOOGLE_CLOUD_SDK_PATH=/Users/jungwoon/google-cloud-sdk
export PATH=$PATH:$GOOGLE_CLOUD_SDK_PATH/bin
export GOOGLE_APPLICATION_CREDENTIALS=/Users/jungwoon/GoogleCredential/bigquerybyjw.json

그 다음 터미널에서 $ gcloud auth application-default login을 해주어야 합니다.

그럼 아래와 같이 나오는데 여기서 Y를 눌러서 진행을 합니다.

그 다음 브로우저가 열리면서 어떤 계정에 연결을 할건지에 대해서 나오는데, 연결하고자 하는 계정을 클릭합니다.

마지막으로 아래와 같은 화면에서 허용을 해주어야 사용할 수 있게 됩니다.

실습

진행은 JAVA로 진행하려고 하고, 먼저 Client Library를 가져오는 방법에 대해서 봐보도록 하겠습니다.

Maven 설정

<dependency>
  <groupId>com.google.cloud</groupId>
  <artifactId>google-cloud-speech</artifactId>
  <version>0.32.0-alpha</version>
</dependency>

Gradle 설정

compile 'com.google.cloud:google-cloud-speech:0.32.0-alpha'

실습

소스 자체가 크게 어렵지는 않기 때문에, 소스내의 주석을 통해서 설명을 하도록 하겠습니다.

크게 1분 이하의 오디오 파일을 분석하는 소스와 1분 이상의 오디오 파일을 분석하는 소스로 구분하였습니다.

import com.google.cloud.speech.v1.*;
import com.google.protobuf.ByteString;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.List;

public class SpeechApiTest {
    public static void main(String[] args) {
        String filePath = "./audio.raw";

        recognitionSpeech(filePath);
    }
    
    // 1분 미만의 오디오 파일일때
    public static void recognitionSpeech(String filePath) {

        try {
            SpeechClient speech = SpeechClient.create(); // Client 생성
            
            // 오디오 파일에 대한 설정부분
            RecognitionConfig config = RecognitionConfig.newBuilder()
                    .setEncoding(RecognitionConfig.AudioEncoding.LINEAR16)
                    .setSampleRateHertz(16000)
                    .setLanguageCode("en-US")
                    .build();

            RecognitionAudio audio = getRecognitionAudio(filePath); // Audio 파일에 대한 RecognitionAudio 인스턴스 생성
            RecognizeResponse response = speech.recognize(config, audio); // 요청에 대한 응답
            List<SpeechRecognitionResult> results = response.getResultsList(); // 응답 결과들

            for (SpeechRecognitionResult result: results) {
                SpeechRecognitionAlternative alternative = result.getAlternativesList().get(0);
                System.out.printf("Transcription: %s%n", alternative.getTranscript());
            }

            speech.close();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }

    // Local 이나 Remote이거나 구분해서 RecognitionAudio 만들어 주는 부분
    public static RecognitionAudio getRecognitionAudio(String filePath) throws IOException {
        RecognitionAudio recognitionAudio;

        // 파일이 GCS에 있는 경우
        if (filePath.startsWith("gs://")) {
            recognitionAudio = RecognitionAudio.newBuilder()
                    .setUri(filePath)
                    .build();
        }
        else { // 파일이 로컬에 있는 경우
            Path path = Paths.get(filePath);
            byte[] data = Files.readAllBytes(path);
            ByteString audioBytes = ByteString.copyFrom(data);

            recognitionAudio = RecognitionAudio.newBuilder()
                    .setContent(audioBytes)
                    .build();
        }

        return recognitionAudio;
    }

}

결과


Transcription: how old is the Brooklyn Bridge

소스

import com.google.api.gax.longrunning.OperationFuture;
import com.google.cloud.speech.v1.*;
import com.google.protobuf.ByteString;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.List;

public class SpeechApiTest {
    public static void main(String[] args) {
        String filePath = "gs://myfiles-byjw/vr.flac";

        longRecognitionSpeech(filePath);
    }

    // 1분 이상의 오디오 파일일때, (** GCS에 올려서 이용해야 함)
    public static void longRecognitionSpeech(String filePath) {

        try {
            SpeechClient speech = SpeechClient.create();


            // 오디오 파일에 대한 설정부분
            RecognitionConfig config = RecognitionConfig.newBuilder()
                    .setEncoding(RecognitionConfig.AudioEncoding.FLAC)
                    .setSampleRateHertz(16000)
                    .setLanguageCode("en-US")
                    .build();

            RecognitionAudio audio = getRecognitionAudio(filePath); // Audio 파일에 대한 RecognitionAudio 인스턴스 생성

            // Non-Blocking 으로 호출을 하며 긴 파일 일때는 LongRunningRecognizeResponse를 사용함
            OperationFuture<LongRunningRecognizeResponse, LongRunningRecognizeMetadata> response =
                    speech.longRunningRecognizeAsync(config, audio);

            while (!response.isDone()) {
                System.out.println("Waiting for response...");
                Thread.sleep(10000);
            }

            List<SpeechRecognitionResult> results = response.get().getResultsList();

            for (SpeechRecognitionResult result: results) {
                SpeechRecognitionAlternative alternative = result.getAlternativesList().get(0);
                System.out.printf("Transcription: %s\n",alternative.getTranscript());
            }
            speech.close();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }

    // Local 이나 Remote이거나 구분해서 RecognitionAudio 만들어 주는 부분
    public static RecognitionAudio getRecognitionAudio(String filePath) throws IOException {
        RecognitionAudio recognitionAudio;

        // 파일이 GCS에 있는 경우
        if (filePath.startsWith("gs://")) {
            recognitionAudio = RecognitionAudio.newBuilder()
                    .setUri(filePath)
                    .build();
        }
        else { // 파일이 로컬에 있는 경우
            Path path = Paths.get(filePath);
            byte[] data = Files.readAllBytes(path);
            ByteString audioBytes = ByteString.copyFrom(data);

            recognitionAudio = RecognitionAudio.newBuilder()
                    .setContent(audioBytes)
                    .build();
        }

        return recognitionAudio;
    }

}

결과

Waiting for response...
Waiting for response...
Waiting for response...
Waiting for response...
Waiting for response...
Waiting for response...
Transcription: it's okay so what am I doing here why am I here at GDC talking about VR video it's because I believe my favorite games I love games I believe in games my favorite games are the ones that are all about the stories I love narrative game design I love narrative based games and I think that when it comes to telling stories in VR bring together capturing the world with narrative based games and narrative based game design is going to unlock some of the killer apps and killer stories of the medium
Transcription: so I'm really here looking for people who are interested in telling us or two stories that a

웹 취약점 (RSA 알고리즘) 로그인 아이디, 패스워드 암호화

영진은정아빠 — Wed, 12 Sep 2018 09:12:15 +0900

웹 취약점 (RSA 알고리즘) 로그인 아이디, 패스워드 암호화

해커로 부터 웹 사이트를 방어하는 일은 생각보다 까다롭고 귀찮은 작업입니다.

HTTPS를 적용한다고 하더라도 인증서 교환 방식, Proxy 방식등 여러 기법들을 이용해서 해커는 사용자의 중요한 정보(패스워드, 계좌번호, 개인정보 등)를 훔쳐가게 됩니다.

여기서 다룰 내용은 완벽하게 해커가 해킹을 하지 못하게 한다기 보다는 해커가 중요정보를 가져가는 행위를 조금더 복잡하고 어렵게 하기 위한 방법입니다.

결국, 암호화라는 방식도 언젠가는 복호화가 되기 마련입니다.(키가 업더라도...) 단, 복호화에 들어가는 시간이 얼마나 걸리냐의 문제겠지요.

RSA는 비대칭 방식으로 암호화 하여 공개키(공개된 키)와, 개인키를 이용한 암호화 방식입니다.

사용자가 로그인 시 아이디, 패스워드를 RSA공개키로 암호화해서, 중간에 패킷 스니핑, 패킷 덤프를 하더라도 사용자가 입력한 아이디, 패스워드를 해석이 불가능 하게 만드는 방법 입니다.

[구현 흐름도]

1) 서버 -> 서버측에서 RSA 공개키와 개인키(비밀키)를 생성하여, 개인키는 세션에 저장하고 공개키는 자바스크립트 로그인 폼이 있는 페이지로 출력한다.
2) 클라이언트 -> 로그인폼은 자바스크립트가 실행되지 않는 환경에서는 발행(submit)이 되면 안된다.
3) 클라이언트 -> 로그인폼에 사용자의 ID와 비밀번호를 넣고 발행을 누르면 자바스크립트가 이를 가로챈다.
1. 4) 클라이언트 -> 사용자 ID를 RSA로 암호화하여 화면에 안보이는 새로운 폼에 저장한다.
2. 5) 클라이언트 -> 비밀번호를 RSA로 암호화하여 화면에 안보이는 새로운 폼에 저장한다.
3. 6) 서버 -> 이제 화면에 안보이는 해당 폼을 서버로 발행한다.
7) 서버 -> 서버측에서 세션에 저장된 RSA개인키로 암호화된 사용자ID와 비밀번호를 복호화한다.
8) 서버 -> 데이터베이스/혹은 기타 저장소에 저장된 사용자 ID와 비밀번호가 일치하는지 확인한다.

저는 위에 방식과 sha256 해시 알고리즘을 이용해서 DB에 저장되는 패스워드 엮시 단방향 해시 값으로 저장을 했습니다.

데이터베이스(DB) 해킹 시 사용자의 패스워드를 알아볼 수 없도록 단방향 해시를 적용한 것입니다.

[준비물]

RSA.zip

[소스]

1) 로그인 화면 (세션을 이용하여 공개키의 문자열을 개인키로 저장 합니다)

@RequestMapping(value = "/login.do", method = RequestMethod.GET)

@Description("로그인 페이지")

public String login(Locale locale, Model model, final HttpServletResponse response, final HttpServletRequest request, final HttpSession session) throws Exception {

KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA");

generator.initialize(2048);

KeyPair keyPair = generator.genKeyPair();

KeyFactory keyFactory = KeyFactory.getInstance("RSA");

PublicKey publicKey = keyPair.getPublic();

PrivateKey privateKey = keyPair.getPrivate();

// 세션에 공개키의 문자열을 키로하여 개인키를 저장한다.

session.setAttribute("_RSA_WEB_Key_", privateKey);

// 공개키를 문자열로 변환하여 JavaScript RSA 라이브러리 넘겨준다.

RSAPublicKeySpec publicSpec = keyFactory.getKeySpec(publicKey, RSAPublicKeySpec.class);

String publicKeyModulus = publicSpec.getModulus().toString(16);

String publicKeyExponent = publicSpec.getPublicExponent().toString(16);

request.setAttribute("publicKeyModulus", publicKeyModulus);

request.setAttribute("publicKeyExponent", publicKeyExponent);

return "/login";

}

2) 로그인 화면 (javascript) 순서를 정확히 맞춰야 함. (RSA.zip 파일 참조)

<script type="text/javascript" src="<c:url value="/resources/js/jsbn.js"/>"></script>

<script type="text/javascript" src="<c:url value="/resources/js/rsa.js"/>"></script>

<script type="text/javascript" src="<c:url value="/resources/js/prng4.js"/>"></script>

<script type="text/javascript" src="<c:url value="/resources/js/rng.js"/>"></script>

3) 로그인 화면 (html)

<label for="username">사용자ID : <input type="text" id="username" size="16"/></label>
            <label for="password">비밀번호 : <input type="password" id="password" size="16" /></label>
            <input type="hidden" id="rsaPublicKeyModulus" value="<%=publicKeyModulus%>" />
            <input type="hidden" id="rsaPublicKeyExponent" value="<%=publicKeyExponent%>" />
            <a href="<%=request.getContextPath()%>/loginFailure.jsp" onclick="validateEncryptedForm(); return false;">로그인</a>

        <form id="securedLoginForm" name="securedLoginForm" action="<%=request.getContextPath()%>/login" method="post" style="display: none;">
            <input type="hidden" name="securedUsername" id="securedUsername" value="" />
            <input type="hidden" name="securedPassword" id="securedPassword" value="" />

</form>

위 html처럼 작업 해도 되고, 저의 경우 Ajax 방식을 이요해서 별도의 form 처리는 하지 않았습니다.

4) 로그인 버튼 클릭 시(submit)

function validateEncryptedForm() {

중요한 부분은 bold 처리된 부분입니다. 사용자가 입력한 아이디, 패스워드 부분을 RSA로 암호화 해서 form submit 하는 부분 입니다.

5) 암호화된 아이디, 패스워드 복호화(java)

protected void processRequest(HttpServletRequest request, HttpServletResponse response)

            throws ServletException, IOException {
        String securedUsername = request.getParameter("securedUsername");
        String securedPassword = request.getParameter("securedPassword");

        HttpSession session = request.getSession();
        PrivateKey privateKey = (PrivateKey) session.getAttribute("__rsaPrivateKey__");
        session.removeAttribute("__rsaPrivateKey__"); // 키의 재사용을 막는다. 항상 새로운 키를 받도록 강제.

        if (privateKey == null) {
            throw new RuntimeException("암호화 비밀키 정보를 찾을 수 없습니다.");
        }
        try {
            String username = decryptRsa(privateKey, securedUsername);
            String password = decryptRsa(privateKey, securedPassword);
            request.setAttribute("username", username);
            request.setAttribute("password", password);
            request.getRequestDispatcher("/WEB-INF/views/login.jsp").forward(request, response);
        } catch (Exception ex) {
            throw new ServletException(ex.getMessage(), ex);
        }
    }

    private String decryptRsa(PrivateKey privateKey, String securedValue) throws Exception {
        System.out.println("will decrypt : " + securedValue);
        Cipher cipher = Cipher.getInstance("RSA");
        byte[] encryptedBytes = hexToByteArray(securedValue);
        cipher.init(Cipher.DECRYPT_MODE, privateKey);
        byte[] decryptedBytes = cipher.doFinal(encryptedBytes);
        String decryptedValue = new String(decryptedBytes, "utf-8"); // 문자 인코딩 주의.
        return decryptedValue;
    }

    /**
     * 16진 문자열을 byte 배열로 변환한다.
     */
    public static byte[] hexToByteArray(String hex) {
        if (hex == null || hex.length() % 2 != 0) {
            return new byte[]{};
        }

        byte[] bytes = new byte[hex.length() / 2];
        for (int i = 0; i < hex.length(); i += 2) {
            byte value = (byte)Integer.parseInt(hex.substring(i, i + 2), 16);
            bytes[(int) Math.floor(i / 2)] = value;
        }
        return bytes;
    }

결론적으론, 세션에 개인키를 저장하는 방식의 RSA 암호화 기법을 사용하므로 세션 해킹 기법을 이용한다면, 위에 언급한 RSA 방식도 안전하진 못하지만 세션 해킹 기법을 막기위한 token 기법과 동시에 적용 한다면, 만족한 형태의 보안 처리가 될 것 같다.

CC인증을 하기 위해서 위에 내용은 필수이므로, 반드시 로그인 처리 시 적용을 해야 한다.

메이븐(MAVEN) RPM 플러그인으로 RPM 생성하기

영진은정아빠 — Fri, 7 Sep 2018 15:23:05 +0900

메이븐(MAVEN) RPM 플러그인으로 RPM 생성하기

최근 수행한 프로젝트에서 스프링부트로 만든 어플리케이션의 최종 빌드 모습은 다음과 같았다.

myapp.war
myapp-run.sh
conf/application.properties

myapp을 yum으로 설치해야 한다는 요구사항이 생겨서 위 파일들을 rpm 파일로 만들어야 할 일이 생겼다. 다행히 메이븐의 rpm-maven-plugin 플러그인을 사용하면 쉽게 rpm 파일을 만들 수 있다.

* 참고로, rpm-maven-plugin은 rpmbuild를 사용하므로 rpmbuild를 먼저 설치해야 rpm-maven-plugin이 올바르게 동작한다.

rpm-maven-plugin 설정 예제

다음은 rpm-maven-plugin의 설정 예제이다.

<build>

<groupId>org.codehaus.mojo</groupId>

<artifactId>rpm-maven-plugin</artifactId>

<goals>

</goals>

</execution>

</executions>

<group>Development</group>

<description>Maven Recipe: RPM Package.</description>

<version>${project.version}</version>

<autoRequires>false</autoRequires>

<scriptFile>src/main/package/rpm/preinstall.sh</scriptFile>

</preinstallScriptlet>

<directory>/usr/local/myapp</directory>

<location>${project.basedir}/target/myapp-${project.version}.war</location>

</source>

</sources>

</mapping>

<directory>/usr/local/myapp</directory>

<location>${project.basedir}/bin/myapp-run.sh</location>

</source>

</sources>

</mapping>

<directory>/usr/local/myapp/conf</directory>

<location>${project.basedir}/conf</location>

</source>

</sources>

</mapping>

</mappings>

</configuration>

</plugin>

</plugins>

</build>

<mapping>에서 각 요소는 다음을 의미한다.

<directory> : 파일 복사 위치. RPM 설치 과정에서 생성한다.
<filemode> : 파일의 권한 모드
<sources> : 해당 복사 위치에 넣을 대상

예를 들어, /usr/local/myapp 폴더가 존재하지 않으면 이 폴더를 생성하고, myapp-버전.war 파일을 이 폴더에 복사한다. 또한, 같은 위치에 myapp-run.sh 파일을 755 모드로 복사한다. 별도로 모드를 지정하지 않은 경우 <defaultDirmode>와 <defaultFilemode>에서 지정한 모드를 사용한다. 비슷하게 소유 계정과 그룹을 지정하지 지정하지 않으면 <defaultUsername>와 <defaultGroupname>에서 지정한 계정과 그룹을 사용한다.

설치 전에 필요한 계정을 생성하거나 기존에 이미 설치된 파일의 경로를 변경하는 등의 작업이 필요할 경우 <preinstallScriptlet>을 이용해서 해당 작업을 실행할 스크립트를 지정한다.

메이븐 명령어

이제 RPM 생성을 위한 메이븐 명령어를 실행할 차례다. "rpm:rpm" 골을 이용해서 메이븐을 실행하면 된다.

mvn clean package rpm:rpm

RPM 파일은 target/rpm/myapp/RPMS/noarch/myapp-버전-0.noarch.rpm 경로에 생긴다.

Apache Solr 쿼리

영진은정아빠 — Thu, 9 Aug 2018 17:41:15 +0900

Apache Solr 쿼리

검색 쿼리 parameter

sort - 정렬과 관련된 파라미터

[Example]

parameter	description
sort=score desc	정확도를 높은데서 낮은데로 정렬한다.
sort=price asc	price필드를 오름차순 정렬
sort=inStock desc, price asc	inStock필드를 내림차순 정렬한 후 price 필드를 오름차순 정렬한다.

start - 검색된 결과값중 몇번째일지 ( default : 0)

row - 결과값을 얼마나 출력할지

[Example]

parameter	description
start=0&rows10	첫번쨰 문서부터 총 10개의 문서를 출력한다.

fq (Filter Query) - 검색된 결과중 또 한번 쿼리에 부합하는 검색 결과를 찾는다. AND문과 다른점은 score(정확도)값에 영향을 주지 않는 것이다.

[Example]

만약 title 이라는 필드에 대해 실적으로 검색을 하여 두개의 문서가 나왔다고 하면

request )

[url]/select?q=title:실적

result )

1) "title": "실적 악화보다 더 무서운 '담합 낙인'..건설사 신음"

2) "title": "1분기 항공여객 실적 2437만명, 전년 동기比 12.4%↑"

request )

[url]/select?q=title:실적&fq=title:건설사

result )

1) "title": "실적 악화보다 더 무서운 '담합 낙인'..건설사 신음"

정확도에 영향을 끼치지 않고 메인쿼리와 독립되게 캐시되어있어 속도향상에도 영향을 준다고 한다.

fl (Field List) : 결과값의 필드를 제한을 둔다.

[Example]

parameter	description
id name price	id, name, price 필드의 값만 리턴
id,name,price	id, name, price 필드의 값만 리턴
id name,price	id, name, price 필드의 값만 리턴
id score	id필드 정확도 값만 리턴
*	정확도 제외한 전체 필드 리턴
* score	전체 필드와 정확도 리턴
[exaplain]	검색결과에 대한 정확도 등의 정보가 리턴

그리고 사용자 정의를 통해 결과필드를 커스터마이징 할 수 있는데 결과값을 필드나 함수등을 이용하여 변경할 수 있다.

[Example]

request)

fl=id,sales_price:price,secret_sauce:prod(price,popularity),why_score:[explain style=nl]

response)

"response":{"numFound":2,"start":0,"docs":[ { "id":"6H500F0", "secret_sauce":2100.0, "sales_price":350.0, "why_score":{ "match":true, "value":1.052226, "description":"weight(features:cache in 2) [DefaultSimilarity], result of:", "details":[{

....

debug

debug=query : 오직 쿼리의 디버그 정보만 반환

debug=timing: 쿼리를 처리하는데 걸린시간에 대한 정보를 반환

debug=results: 검색결과에 대한 정확도정보를 반환한다. (fl=[explain] 같은)

debug=all: 위의 모든 디버깅 정보를 반환한다.

wt (Response Writer)

Reference에는 이런것들이 있다고 하는데 안되는게 몇개 있다

csv	CSVResponseWriter
json	JSONResponseWriter
php	PHPResponseWriter
phps	PHPSSerializedResponseWriter
python	PythonResponseWriter
ruby	RubyResponseWriter
smile	SmileResponseWriter
velocity	VelocityResponseWriter
xml	XMLResponseWriter
xslt	XSLTResponseWriter

[Example]

wt=json

Linux에서 자바 어플리케이션 서버 실행 쉘(Shell) 스크립트

영진은정아빠 — Tue, 7 Aug 2018 11:09:42 +0900

Linux에서 자바 어플리케이션 서버 실행 쉘(Shell) 스크립트

JAVA로 작성한 jar파일을 데몬으로 돌려야할 때 필요한 쉘 스크립트 정리

기본적으로 java -jar 를 이용해 jar파일을 실행하는 것을 서비스 운영 모드로 동작하게 해주는(관리 측면 효율성) 쉘 스크립트이다.


#!/bin/sh
SERVICE_NAME=서비스명
PATH_TO_JAR=실행할 JAR 파일 path.jar
PID_PATH_NAME=./서비스명.pid
JAVA_OPT="-Xms2048m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m"
case $1 in
    start)
        echo "Starting $SERVICE_NAME ..."
        if [ ! -f $PID_PATH_NAME ]; then
            nohup java -jar $JAVA_OPT $PATH_TO_JAR >> /dev/null &
                        echo $! > $PID_PATH_NAME
            echo "$SERVICE_NAME started ..."
        else
            echo "$SERVICE_NAME is already running ..."
        fi
    ;;
    stop)
        if [ -f $PID_PATH_NAME ]; then
            PID=$(cat $PID_PATH_NAME);
            echo "$SERVICE_NAME stoping ..."
            kill $PID;
            echo "$SERVICE_NAME stopped ..."
            rm $PID_PATH_NAME
        else
            echo "$SERVICE_NAME is not running ..."
        fi
    ;;
    restart)
        if [ -f $PID_PATH_NAME ]; then
            PID=$(cat $PID_PATH_NAME);
            echo "$SERVICE_NAME stopping ...";
            kill $PID;
            echo "$SERVICE_NAME stopped ...";
            rm $PID_PATH_NAME
            echo "$SERVICE_NAME starting ..."
            nohup java -jar $JAVA_OPT $PATH_TO_JAR >> /dev/null &
                        echo $! > $PID_PATH_NAME
            echo "$SERVICE_NAME started ..."
        else
            echo "$SERVICE_NAME is not running ..."
        fi
    ;;
esac

이렇게 쉘 파일을 작성하고

run.sh 라고 작성을 했다면

./run.sh start

./run.sh restart

./run.sh stop

으로 서버를 시작/재시작/중지 시킬 수 있다

(물론 실행하기 위해선 실행권한을 파일에 부여를 해야 한다)

run.sh 로 가정했을 때

root 권한을 받은 뒤

chmod 755 run.sh

명령어로 해당 쉘 스크립트에 실행 권한을 부여할 수 있다.

해당 프로세스 PID 정보는 PID_PATH_NAME 에 저장이 되며

JAVA_OPT 에 JVM 옵션을 지정할 수 있다.

현재 시작/재시작 시 /dev/null로 리다이렉트를 하고 있는데, 이를 log파일 이름으로 바꾸게 되면 현재 데몬 실행을 하는 로그를 남기게 된다.

nohup java -jar -Dspring.profiles.active=prod $JAVA_OPT $PATH_TO_JAR >> daemon.log 와 같이 고치면 daemon.log에 현재 실행 로그가 남는다.