2023년도 하반기 다우기술 신입 채용 프로세스 과정 중 하나로 약 한 달 동안 인프라운영 팀에서 인턴생활을 하게 되었다. 두 번째 인턴이라 저번보다는 덜 떨려서 그런지 출근이나 회사 생활도 빠르게 적응했던 것 같다. 인턴의 위치이기 때문에 실무와 관련된 업무는 받지 않았지만 대신 인프라 운영팀에서도 활발히 사용하고 있는 IaC 인프라 자동화 도구를 사용하는 과제가 주어졌다. 정확한 과제 주제는 밝히지 않겠지만 가상머신 위에서 인프라 구축 및 구성하는 과제였다. 과제를 위해서 개인적으로 사용할 수 있는 VMware IP 대역대, VCenter, ESXi 환경이 주어졌다. 3주간 진행되지만 나머지 일주일 동안은 PPT 제작 및 발표 연습으로 인해 거의 2주 안으로 과제를 완성하겠다는 목표로 삼았었다. 첫날부터 어떻게 과제를 진행해갈 것인지에 대해 일정을 짜고 하루하루 내가 어떤 결과물을 냈는지 스스로 Notion에 작성해나갔었는데 지금 보니까 이 때의 나 좀 열심히 살았던 거 같아서 기분 좋았다. ㅋㅋㅋ 인턴십 후기는 여기까지 하고 3주 동안 스스로 학습했던 내용과 이후 심화적으로 공부했던 내용을 적어보려한다.
1. DNS 서버의 라운드로빈 형식으로 웹서버의 완벽한 이중화가 이루어질까?
초반 웹서버의 이중화를 하나의 DNS 서버 역할을 하는 VM을 생성하여 특정 도메인으로 접속 시 두 개의 웹서버 ip로 트래픽이 전달되게끔 하였다. 이후 DNS 서버가 잘 동작하는 것을 보여드리기 위해 새로운 Client 서버를 생성 후 nslookup 도메인 주소를 통해 두 개의 웹서버 ip가 반환하는 결과를 발표하였다. 하지만 중간 점검 때 "이렇게 했을 때 만약 한 개의 웹서버가 고장나면 어떻게 되나?"란 질문을 받았었는데 이후 생각해보니 트래픽만 두 갈래로 이동할 뿐 모든 사용자들이 정상적인 서비스를 제공받을 순 없겠다는 생각이 들었다. 그래서 최종적으로는 DNS 서버를 제거하고 HAProxy의 healthcheck 기능을 더해 장애가 난 웹서버로는 트래픽이 흘러가지 않게끔하여 더욱 안정성 있는 웹서버 이중화를 구성하였다.
2. Apache httpd web server 와 tomcat 을 연동 방식 (mod_jk VS mod_proxy VS mod_proxy_ajp)
1) mod_jk
장점
- mod_jk 를 많이 사용하므로 관련 자료가 많음
- JkMount 옵션을 이용하면 URL 이나 컨텐츠별로 유연한 설정이 가능 (이미지는 웹서버, 서블릿은 톰캣)
단점
- 별도의 모듈 설치 필요
- 설정이 어려움
- 톰캣 전용
2) mod_proxy
장점
- 별도 모듈 설치가 필요없고(apache 기본 모듈) 설정이 간편
- 특정 WAS에 의존적이지 않으므로 모든 WAS에 적용 가능
단점
- URL 별 유연한 설정이 어려움 (ProxyPassMatch 사용 필요)
3) mod_proxy_ajp
장점
- 별도 모듈 설치가 필요없고 (apache 기본 모듈) 설정이 간편
- 특정 WAS에 의존적이지 않으므로 모든 WAS에 적용 가능
단점
- URL 별 유연한 설정이 어려움 (ProxyPassMatch 사용 필요)
(+) 현재는 mod_jk 보다는 mod_proxy 를 사용하는 것이 설정도 간단하고 nginx 같은 차세대 웹 서버로 이전하기가 쉬워 mod_proxy 사용을 권장한다고 한다.
3. 서비스의 장애는 어떤 트래픽이나 로그로 판단할 것인가
모니터링 프로세스에서 웹서버의 장애 감지 triger를 port 80 down 으로 설정하였다. 하지만 서비스 작동 포트만으로는 웹서버의 모니터링을 구축했다고는 할 수 없었다. 비록 모니터링을 구성하는데 시간이 부족했다는 점도 컸지만 다시 생각해보니 포트 다운만으로 서비스 동작 성공 여부를 판단하려했던 내 자신도 좀 부끄럽다. ㅋㅋㅋ 여러 블로그들을 찾아보니 server-status 모듈을 사용하여 현재 웹서버 상황을 확인하고 telegraf와 같은 오픈소스를 활용하여 웹서버 상황 데이터들을 지속적으로 전달하고 수집하는 모니터링 프로세스들이 있었다. 만약 다음에 모니터링 프로세스 구축한다면 서비스 로그에 더욱 집중할 것이며 특히 에러 로그에 대한 트리거를 설정하여 좀 더 세부적인 서버 상황을 파악할 수 있도록 할 것이다.
이렇게 과제 점검 시간에 받았던 사원님들의 피드백으로 받은 질문들 중 내가 가장 버벅거리면서 대답했던 부분들에 대해 작성해보았다. 이후에는 온프레미스 환경이 아닌 클라우드 환경에서 비슷한 인프라를 구축한다는 과제가 주어진다면 어떤 서비스들을 사용하여 인프라 아키텍처를 설계할 것인지 구상해본 바이다.
1) 전체 인프라 구상도
먼저 서비스의 고가용성을 위해 Multiple Origins 설계를 CDN 원본 장애에 대한 대처방안으로 생각보았다. 또한 모든 기업에서 서비스 배포 이전 테스트를 위한 검증계 환경과 실제 서비스가 작동되는 운영계 환경이 구분되어 있는 것을 Staging VPC 와 Production VPC로 나누었다. 이 두 VPC의 리소스 통신을 위해서 AWS Transit Gateway Peering을 설정해주며 온프레미스의 Customer gateway와는 AWS Direct Connect와 같은 전용선을 포함한 다양한 방법의 VPN Connection을 생각해보았다. 보안적은 측면으로는 AWS CloudFront의 OAI 기능을 사용하여 직접적인 S3 Bucket의 퍼블릭 액세스를 차단하였으며 AWS WAF를 함께 사용하여 악성 트래픽을 차단할 수 있도록 하였다. 추가적으로는 AWS Shield Advanced를 사용하여 공격 자동 대응 및 실시간 모니터링/알림을 통해 더욱 인프라의 안정성을 향상시킬 수 있는 방법을 구상해보았다.
2) 세부 인프라 구상도
다음으로는 클라우드 환경에서 가장 기본적인 3-tier 아키텍처를 구성도를 생각해보았다. 카카오 클라우드 양성과정 프로그램을 진행할 때 AWS에서 구축했던 경험에서 나아가 DB의 복제 부분과 Redis Cache의 사용을 추가해서 적어보았다. 다중 AZ와 ALB & Auto Scaling Group 구성으로 WEB, WAS 서버의 고가용성 고려하였다. 또한 DB 구성에서는 Active-Standby 방식으로 자동 복구 및 일관성을 유지하게끔 하였으며, 레거시 시스템에서의 DB와는 AWS DMS를 사용하여 Data Migration 및 실시간 복제를 생각해보았다.
아직 현업 경험이 없어서 기업 인프라 시스템이 이런 형태로 구성되어 있을지는 모르겠지만 이때까지 배운 내용을 바탕으로 스스로 구상해보았다. 빨리 취업해서 실제 인프라 설계 및 운영을 배워나가고 싶다. 취뽀하는 그날까지 화이팅