1. 서론: 인덱스는 왜 중요한가?

데이터베이스의 성능은 곧 서비스의 응답 속도와 직결됩니다. 데이터가 수만 건일 때는 문제가 없다가, 수백만 건을 넘어서는 순간 웹 사이트가 느려지는 경험을 해보셨을 겁니다. 이때 가장 먼저 확인해야 할 것이 바로 **인덱스(Index)**입니다.

인덱스는 책의 맨 뒤에 있는 ‘색인’과 같습니다. 방대한 데이터 속에서 내가 원하는 정보를 찾기 위해 처음부터 끝까지 다 뒤지는 ‘Full Table Scan’을 방지하고, B-Tree 구조를 통해 원하는 위치로 즉시 점프하게 해줍니다.

2. 실무 사례: 500만 건의 주문 테이블 쿼리 최적화

상황: 쇼핑몰 프로젝트에서 특정 사용자의 최근 주문 내역을 조회하는 쿼리가 5초 이상 소요되고 있습니다.

서론

서비스 규모가 커지면 L4나 L7 로드 밸런서를 통해 여러 대의 WAS(Tomcat)를 운영하게 됩니다. 이때 사용자의 세션 정보가 특정 서버에만 남아있다면, 로드 밸런싱 과정에서 세션 끊김 현상이 발생합니다. 이를 해결하기 위해 서버 간 세션을 동기화하는 세션 클러스터링(Session Clustering) 설정이 필수적입니다.

1. Tomcat 기본 설정 (server.xml)

Tomcat은 멀티캐스트(Multicast) 방식을 이용한 자체 세션 복제 기능을 제공합니다. server.xml의 <Host> 태그 내부에 <Cluster> 설정을 추가합니다.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
         channelSendOptions="8">
    <Manager className="org.apache.catalina.ha.session.DeltaManager"
             expireSessionsOnShutdown="false"
             notifyListenersOnReplication="true"/>
    <Channel className="org.apache.catalina.tribes.group.GroupChannel">
        <Membership className="org.apache.catalina.tribes.membership.McastService"
                    address="228.0.0.4"
                    port="45564"
                    frequency="500"
                    dropTime="3000"/>
        <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                  address="auto"
                  port="4000"
                  autoBind="100"
                  selectorTimeout="5000"
                  maxThreads="6"/>
    </Channel>
</Cluster>

2. 애플리케이션 활성화 (web.xml)

클러스터링 대상이 되는 웹 애플리케이션의 WEB-INF/web.xml 파일에 반드시 다음 태그를 추가해야 합니다. 이 태그가 없으면 세션 복제가 작동하지 않습니다.

서론

Tomcat 기반의 Java 애플리케이션을 운영하다 보면 가장 빈번하게 발생하는 장애 중 하나가 바로 OutOfMemoryError입니다. 서버의 물리적 메모리가 충분하더라도 JVM에 할당된 메모리가 적절하지 않으면 서비스는 쉽게 멈출 수 있습니다. 이번 포스팅에서는 실무에서 필수적인 JVM 메모리 설정 파라미터를 정리합니다.

1. 힙 메모리(Heap Memory) 핵심 설정

힙 메모리는 객체가 생성되고 상주하는 공간입니다. 가장 중요한 두 가지 설정은 -Xms와 -Xmx입니다.

• -Xms: JVM이 시작될 때 할당하는 초기 힙 크기입니다.
• -Xmx: JVM이 가질 수 있는 최대 힙 크기입니다.

실무 권장 설정 (setenv.sh)

Tomcat의 bin/setenv.sh(윈도우는 setenv.bat) 파일을 생성하거나 수정하여 설정합니다.

서론

웹 서비스 운영 중 발생하는 문제의 80%는 로그 분석을 통해 해결됩니다. 특히 **접근 로그(Access Log)**는 누가, 언제, 어떤 페이지를 호출했고 얼마나 빨리 응답했는지를 기록하는 핵심 데이터입니다. Tomcat의 기본 설정을 넘어 실무에서 필요한 데이터들을 추출하는 커스텀 방법을 정리합니다.

1. 접근 로그 패턴 커스텀 (server.xml)

Tomcat의 server.xml 파일 내 <Valve> 설정을 통해 로그 패턴을 변경할 수 있습니다.

실무 추천 패턴

기본 패턴에는 가장 중요한 ‘처리 시간(Processing Time)‘이 빠져 있는 경우가 많습니다.

서론

웹 서비스의 보안(HTTPS)은 이제 선택이 아닌 필수입니다. Tomcat에서 SSL 인증서를 적용하는 방법은 인증서 형식(JKS, PKCS12 등)에 따라 설정 방식이 조금씩 다릅니다. 이번 포스팅에서는 인증서 적용부터 HTTP 요청을 HTTPS로 강제 전환하는 방법까지 정리합니다.

1. SSL 인증서 적용 (server.xml)

최신 Tomcat 버전에서는 .p12(PKCS12) 형식을 권장합니다. server.xml의 <Connector> 부분을 다음과 같이 설정합니다.

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true">
    <SSLHostConfig>
        <Certificate certificateKeystoreFile="conf/certificate.p12"
                     certificateKeystorePassword="your_password"
                     type="RSA" />
    </SSLHostConfig>
</Connector>

2. HTTP to HTTPS 자동 리다이렉트

사용자가 http://로 접속해도 자동으로 https://로 전환되도록 설정해야 합니다.

서론

대규모 트래픽이 발생하는 환경에서 WAS(Tomcat)가 응답하지 않거나 속도가 급격히 느려진다면, 가장 먼저 의심해야 할 곳은 쓰레드 풀(Thread Pool) 설정입니다. Tomcat의 server.xml에서 설정하는 세 가지 핵심 파라미터의 관계를 정확히 이해해야 서비스 장애를 예방할 수 있습니다.

Tomcat 요청 처리의 3단계 레이어

1. acceptCount (대기열 크기)

모든 쓰레드가 사용 중일 때, 운영체제(OS) 수준에서 요청을 대기시킬 큐의 크기입니다. 이 큐마저 가득 차면 클라이언트는 Connection Refused 에러를 받게 됩니다.

• 실무 팁: 너무 크게 설정하면 클라이언트는 타임아웃에 걸릴 때까지 하염없이 기다리게 되므로 적절한 제한이 필요합니다.

2. maxConnections (최대 연결 수)

Tomcat이 동시에 유지할 수 있는 최대 네트워크 연결 수입니다. 쓰레드 수보다 훨씬 크게 설정하여(NIO 방식), 실제 처리 중이지 않은 연결도 잠시 붙들어 둘 수 있습니다.

서론

사용자가 요청을 보냈을 때 이메일 발송, 리포트 생성, 외부 API 호출 등 시간이 오래 걸리는 작업이 포함되어 있다면 응답 속도가 느려질 수밖에 없습니다. 이럴 때 **비동기 처리(Asynchronous Processing)**를 도입하면, 핵심 로직만 즉시 응답하고 무거운 작업은 백그라운드에서 실행하여 사용자 경험을 크게 향상시킬 수 있습니다.

@Async 활성화 및 설정

Spring Boot에서 비동기 기능을 사용하려면 먼저 @EnableAsync 설정을 추가해야 합니다.

1. 비동기 설정 클래스

기본 ThreadPool 대신 커스텀 설정을 통해 안정성을 확보하는 것이 좋습니다.

서론

운영 중인 서버가 갑자기 멈췄을 때, 원인을 찾아보면 로그 파일이 디스크 용량을 모두 차지해버린 경우가 의외로 많습니다. 특히 트래픽이 몰리는 서비스라면 로그 파일 크기는 순식간에 수십 GB를 넘어섭니다. 이번 포스팅에서는 리눅스 표준 도구인 logrotate를 사용하여 주요 서버들(Nginx, Apache, Tomcat)의 로그를 서비스 중단 없이 관리하는 방법을 정리합니다.

logrotate란?

logrotate는 리눅스 시스템에서 로그 파일을 주기적으로 순환(Rotation), 압축(Compression), 삭제(Removal)해주는 시스템 유틸리티입니다. 이를 통해 오래된 로그를 보관하면서도 현재 디스크 사용량을 일정하게 유지할 수 있습니다.

서론

현대 웹 아키텍처에서 백엔드 WAS(Tomcat, Spring Boot 등)를 외부에 직접 노출하는 것은 보안과 성능 면에서 권장되지 않습니다. Nginx를 앞단에 두어 **리버스 프록시(Reverse Proxy)**로 활용하면 보안 강화는 물론, **로드 밸런싱(Load Balancing)**을 통해 시스템의 가용성을 획기적으로 높일 수 있습니다.

리버스 프록시 설정 (Reverse Proxy)

리버스 프록시는 클라이언트의 요청을 대신 받아 백엔드 서버로 전달하는 역할을 합니다. 이를 통해 백엔드 서버의 IP를 숨기고 SSL 종단점(SSL Termination) 역할을 수행할 수 있습니다.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_servers; # 로드 밸런서 그룹 지정
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

로드 밸런싱 설정 (Load Balancing)

upstream 블록을 사용하여 여러 대의 백엔드 서버로 부하를 분산할 수 있습니다.