<div id="readability-page-1" class="page"><div><p>개발자로 일하며 수 차례 서비스를 출시했지만 서비스 오픈은 언제나 설렌다. 정상적으로 작동할까? 장애가 발생하지 않을까? 걱정된다. 내가 그동안 봐온 서비스 장애는 오픈 전 체크 리스트 or 성능 테스트를 통해 해결할 수 있던 것들이었다.<br>생각나는대로 정리해봤다.</p>
<h3>로그 설정</h3>
<ol>
<li>로그 레벨<br>에러를 <code>INFO</code>레벨로 사용하지는 않았는가 확인한다. 그 반대 경우도 마찬가지다. 불필요한 <code>DEBUG</code>정보가 운영 환경에서 남도록 하지 않았는가 확인한다.</li>
<li>에러 로그<br>False 알람이 발생하지 않도록한다. 개발자가 정말 알아야 하는 (새벽에 slack으로 에러 알림을 받고 기상해서 바로 패치 후 hotfix로 내보내야 하는) 에러인 경우만 <code>ERROR</code>레벨을 사용한다.</li>
<li>로테이션<br>로그가 적절히 로테이션+삭제 되는지 확인한다. 이 설정을 빼먹을 경우 수 많은 로그 파일들이 불필요하게 disk 차지할 수 있다. 이러 문제는 서비스 배포 직후 알기 힘들며 먼 미래에 갑작스레 찾아온다.</li>
</ol>
<h3>서버&amp;리눅스</h3>
<ol>
<li><p>시간<br><code>date</code>명령어를 통해 timezone이 의도대로 (KST, UTC 등)되어있는가 확인한다. 이 설정이 UTC로 되어 있으면 애플리케이션에서 표시되는 시간이 한국시간 -9시간으로 될 수 있다.</p>
</li>
<li><p>호스트<br>가능하면 호스트네임을 예쁘게 설정하고 <code>/etc/hosts</code>에 ipv4, ipv6 loopback을 등록하여 불필요한 dns lookup을 피한다.</p>
<pre><code> ::1 myserver
 127.0.0.1 myserver</code></pre>
</li>
<li><p>튜닝<br>커널 파라메터 관련 튜닝 포인트를 찾는다. 이 부분을 확인하지 않을 경우 nginx -&gt; upstream 방식을 사용하는 구조에서 local port를 더 이상 생성하지 못해 에러가 발생할 수 있다.<br>ulimit 값을 확인한다. 그렇지 않을 경우 애플리케이션에서 thread를 많이 생성하거나 tcp socket 연결을 많이 생성하는 경우 문제가 발생할 수 있다. <a href="http://woowabros.github.io/experience/2018/04/17/linux-maxuserprocess-openfiles.html">관련링크</a></p>
</li>
<li><p>서비스 계정<br>애플리케이션용 서비스 계정을 생성하고 권한 관리를 확실하게 부여한다. 애플리케이션에서 권한이 없는 디렉토리에 CRUD하지 않는가 확인한다.</p>
</li>
<li><p>방화벽 설정<br>애플리케이션에서 외부로 or 외부에서 애플리케이션으로 통신하는 경우 방화벽에 막혀있지 않은가 확인한다. 특히 데이터베이스와 통신이 가능한지 확인한다.</p>
</li>
</ol>
<h3>데이터베이스</h3>
<ol>
<li><p>index<br>애플리케이션에서 실행할 쿼리에 index가 적절하게 만들어져 있는지 확인한다.</p>
</li>
<li><p>인코딩<br>collation, character등 설정이 옳바르게 되어있는가 확인한다. 이 설정에 따라 글자가 깨지거나, 정렬 쿼리, 이모지 등이 원하는대로 작동하지 않을 수 있다.</p>
<pre><code>SHOW VARIABLES LIKE '%cha%';
SHOW VARIABLES LIKE '%collation%';</code></pre>
</li>
<li><p>튜닝<br>데이터베이스 튜닝이 잘 되어있는지 확인한다. mysql을 사용하는경우 아래의 my.cnf 관련 파라메터를 중점적으로 확인해볼 수 있다.<br><code>innodb_buffer_pool_size, innodb_read_io_threads, innodb_write_io_threads, innodb_thread_concurency, innodb_log_buffer_size, innodb_log_file_size, query_cache_size, query_cache_type</code>등</p>
</li>
<li><p>에러 로그<br>당연한 얘기지만 DB가 뻗으면 애플리케이션 로그가 아니라 DB 로그를 확인 해야한다. DB 에러 로그가 없는 경우를 자주 봤다. 이러면 DB 이슈 발생시 확인할 수 있는 부분이 없다. 에러 쫓던 개 지붕 쳐다보게 된다. 반드시 error, dead lock 로그 등이 설정 되어있는지 확인한다.</p>
</li>
<li><p>slow 로그<br>1초 이내로 완료되지 않는 쿼리는 모두 확인하여 튜닝한다. 스노우볼이다. 제일 중요한 체크 포인트 이지만 초반에 ‘별거 아니겠지’했다가 나중에 가서 눈덩이 처럼 불어나는 에러를 목격 할 것이다.</p>
</li>
<li><p>바이너리 로그<br>slave서버가 없을지라도 가능하면 binlog를 생성 하도록 한다. 데이터 복구시 유용하게 사용할 수 있다. <a href="http://woowabros.github.io/experience/2018/05/28/billingjul.html">관련링크</a></p>
</li>
<li><p>외래키<br>정말 필요한가 확인한다. 데이터 정합성이 그다지 중요하지 않다면 외래키를 없애고 index를 별도로 생성 하는것도 방법이다.</p>
</li>
</ol>
</div></div>

호돌맨의 블로그

JuHyun Lee

개발자로 일하며 수 차례 서비스를 출시했지만 서비스 오픈은 언제나 설렌다. 정상적으로 작동할까? 장애가 발생하지 않을까? 걱정된다. 내가 그동안 봐온 서비스 장애는 오픈 전 체크 리스트 or 성능 테스트를 통해 해결할 수 있던 것들이었다.
생각나는대로 정리해봤다.
로그 설정
로그 레벨
에러를 INFO레벨로 사용하지는 않았는가 확인한다. 그 반대 경우도 마찬가지다. 불필요한 DEBUG정보가 운영 환경에서 남도록 하지 않았는가 확인한다.
에러 로그
False 알람이 발생하지 않도록한다. 개발자가 정말 알아야 하는 (새벽에 slack으로 에러 알림을 받고 기상해서 바로 패치 후 hotfix로 내보내야 하는) 에러인 경우만 ERROR레벨을 사용한다.
로테이션
로그가 적절히 로테이션+삭제 되는지 확인한다. 이 설정을 빼먹을 경우 수 많은 로그 파일들이 불필요하게 disk 차지할 수 있다. 이러 문제는 서비스 배포 직후 알기 힘들며 먼 미래에 갑작스레 찾아온다.
서버&리눅스
시간
date명령어를 통해 timezone이 의도대로 (KST, UTC 등)되어있는가 확인한다. 이 설정이 UTC로 되어 있으면 애플리케이션에서 표시되는 시간이 한국시간 -9시간으로 될 수 있다.
호스트
가능하면 호스트네임을 예쁘게 설정하고 /etc/hosts에 ipv4, ipv6 loopback을 등록하여 불필요한 dns lookup을 피한다.
 ::1 myserver
 127.0.0.1 myserver
튜닝
커널 파라메터 관련 튜닝 포인트를 찾는다. 이 부분을 확인하지 않을 경우 nginx -> upstream 방식을 사용하는 구조에서 local port를 더 이상 생성하지 못해 에러가 발생할 수 있다.
ulimit 값을 확인한다. 그렇지 않을 경우 애플리케이션에서 thread를 많이 생성하거나 tcp socket 연결을 많이 생성하는 경우 문제가 발생할 수 있다. 관련링크
서비스 계정
애플리케이션용 서비스 계정을 생성하고 권한 관리를 확실하게 부여한다. 애플리케이션에서 권한이 없는 디렉토리에 CRUD하지 않는가 확인한다.
방화벽 설정
애플리케이션에서 외부로 or 외부에서 애플리케이션으로 통신하는 경우 방화벽에 막혀있지 않은가 확인한다. 특히 데이터베이스와 통신이 가능한지 확인한다.
데이터베이스
index
애플리케이션에서 실행할 쿼리에 index가 적절하게 만들어져 있는지 확인한다.
인코딩
collation, character등 설정이 옳바르게 되어있는가 확인한다. 이 설정에 따라 글자가 깨지거나, 정렬 쿼리, 이모지 등이 원하는대로 작동하지 않을 수 있다.
SHOW VARIABLES LIKE '%cha%';
SHOW VARIABLES LIKE '%collation%';
튜닝
데이터베이스 튜닝이 잘 되어있는지 확인한다. mysql을 사용하는경우 아래의 my.cnf 관련 파라메터를 중점적으로 확인해볼 수 있다.
innodb_buffer_pool_size, innodb_read_io_threads, innodb_write_io_threads, innodb_thread_concurency, innodb_log_buffer_size, innodb_log_file_size, query_cache_size, query_cache_type등
에러 로그
당연한 얘기지만 DB가 뻗으면 애플리케이션 로그가 아니라 DB 로그를 확인 해야한다. DB 에러 로그가 없는 경우를 자주 봤다. 이러면 DB 이슈 발생시 확인할 수 있는 부분이 없다. 에러 쫓던 개 지붕 쳐다보게 된다. 반드시 error, dead lock 로그 등이 설정 되어있는지 확인한다.
slow 로그
1초 이내로 완료되지 않는 쿼리는 모두 확인하여 튜닝한다. 스노우볼이다. 제일 중요한 체크 포인트 이지만 초반에 ‘별거 아니겠지’했다가 나중에 가서 눈덩이 처럼 불어나는 에러를 목격 할 것이다.
바이너리 로그
slave서버가 없을지라도 가능하면 binlog를 생성 하도록 한다. 데이터 복구시 유용하게 사용할 수 있다. 관련링크
외래키
정말 필요한가 확인한다. 데이터 정합성이 그다지 중요하지 않다면 외래키를 없애고 index를 별도로 생성 하는것도 방법이다.

웹 서비스 출시 전 확인사항

댓글