Studio BASA

#13 데이터관리, 로그규칙 데이터는 연/월/일 의 기준과 용량으로 구분 할 수 있고, 이 외에 장기, 단기 보관으로 구분 될 수 있다. 한번에 생성될때 파일의 크기가 1GB 가 넘어 조회 시에도 지연이 생기거나 파일의 수량이 많아져 조회에도 지연이 생기는 경우가 생길 수 있다. 용량이 대용량으로 Storage 의 수용량이 넘어갈때 압축을 하거나 증량 혹은 삭제를 하게 되는데 이의 규칙을 정하는것은 매우 중요하다고 할 수 있다. 불필요 파일과 로그 그리고 WAS의 GC 대용량 로그등으로 원치 않는 순간에 대용량으로 스토리지를 사용하게 되는 경우가 있다. 도커 혹은 가상 서버 사용시, 이미지가 대량 생산되어 문제가 될 수 도있다. 이로 인해 데이터의 관리가 중요해지는데, 디스크 생성의 기준을 /연/월/일/..

#12 방화벽, 로드벨런스 방화벽은 White List, Black List 로 관리되며, Routing이 없는 Bridge Mode (L2), Routing이 가능한 Routing Mode (L3) 가 있다. 그 외에도 실제 Switch 기능이 있기때문에 Protocol 이나, VPN, L7스위치와 같은 어플리케이션 처리가 되기도 한다. 기능은 많지만 F/W, IPS, IDS 등 으로 구분된다. 추가로 DDOS 방어용 장비들도 존재한다. 그림의 노란색 부분은 방화벽으로 접근하는 설정을 얘기하며 주로 Router 혹은 방화벽의 Routing Table 를 기준으로 작동하게 된다. 파란색 부분은 방화벽을 통과하여 외부로 접근하게 되며, 주로 서버의 직접적인 IP Address 가 아닌 NAT IP Addr..

#11 연동구성 연동은 내부와 외부의 연동이 존재하고, 내부의경우 서버와 서버, 그리고 클러스터링과 Public - Private 의 연동으로 볼 수 있고, 외부연동은 외부에서 서버로의 요청과 내부에서 외부로의 연동이 있다. AA 를 통해 서버내부 인스턴스간 연동표는 나오지만 해당 인스턴스가 어떤 포트를 사용하고, 어떤 VIP 나 한서버에서 여러 인스턴스를 사용한다면 규칙을 부여하여, 포트간의 충돌이나 다른 인스턴스로 접근해 지속적으로 통신오류와 에러를 발생할수 있기때문에 많은 확장성과 독립성을 계산해야 한다. 서비스의 전체 내부연동관계를 그림으로 표현하면 다음과 같다. 서비스의 전체 연동을 기준으로 내부연동은 외부에서 요청으로 처음 들어오는 WEB Service와 서비스 처리 연동 WAS , 그리고 서..

#10 배포 구성 개발기 부터 상용장비까지 구성이 완료 되었다면, 배포와 배포에따른 연동구성을 봐야 한다. 배포는 개인 단말에서 개발이 된것을 개발기에서 확인하고, Staging 혹은 TestBad 에서 테스트와 성능 확인후, 상용에 최종적으로 반영하게 되는데 이때, 한개의 소스를 통한 배포가 되어야 한다. 개발과 테스트, 그리고 상용이 배포버전이 다르거나 배포소스가 다르다면 장애가 발생할 수 있는 포인트가 된다. 배포의 정확성과 자동, 그리고 검증을 위해 SVN, git, genkins 등 여러 방법이 사용될 수 있고 이를통해 효과적이고 최소한의 노력으로 배포가 가능하게 된다. 만약 개인이 일일이 배포를 하게될 경우가 있지만 해당 작업의 경우 버전관리와 백업등의 문제가 발생할 수도 있고, 실수를 할 경..

#9 테스트 구성 테스트의 구성은 성능 혹은 상용서비스로 올라가기 위해 구성되는 구간으로 Staging 혹은 Testbad등으로 불리기도 한다. 간혹 클라우드나 거대규모 서비스의 경우 상용과 동일한 구성으로 도메인 체인지 혹은 LB체인지로 배포나 이벤트운영을 하는경우가 있다. 때문에 운영기와 개발기 사이에 있는 테스트 구성은 매우 중요하다. 심지어 연동부분과 구성이 운영장비와 상이해 테스트 구성까지 연동에 이상이 없지만 운영장비에 적용하자마자 장애가 나는 경우가 많다. 테스트 시에는 외부 연동과 내부 연동등 여러부분이 있어 많은 장애 포인트를 갖고 있지만 대신 테스트임을 감안해서 이에 대비되어있는 상황을 구성해야겠다. 기본은 개발기와 같으나 상용과 대비해서 최소한의 구성을 테스트 장비에 적용한다. 최소한..

#8 개발 구성 개발의 구성은 서버와 네트워크에서 본다면 가장 간단하고, 최소로 구성을 하면 되지만, 개발의 용의성까지 계산한다면 많이 달라 질 수 있다. 다만 여기서는 자동 배포와 검증 그리고 도커에대해서는 빼고, 실제 장비의 구성에대해서 위주로 보겠다. 개발장비는 최소한으로 구성을 하고 기본적인 테스트와 연동을 목표로 한다. 물론 테스트 장비가 없을경우에는 개발장비에서 테스트까지 이루어 지므로 환경에따라 구성한다. 여기서는 개발장비 -> 테스트장비 -> 운영장비 순으로 배포가 될 수 있게 구성하겠다. 가상장비로 모두 구성되어있을때는 배포와 운영이 달라질 수 있는데, 도커의 적극적인 활용이나 혹은 개발기에서 모든 개발과 테스트 완료 후, 해당 장비들과 운영장비를 스위칭하는 방식으로 운영이 될 수도 있지..

#7 성능치 반영도 전체 시스템 구성도를 그렸다면 의문스러운점이 많이 있을것이다. 무슨 근거로 서버와 네트워크 장비들, 그리고 소프트웨어의 수량과 성능을 정하고 설계한 것일까 하는 것일 텐데, 예를 들자면 Tomcat 으로 처리하고자 하는 것이 계속 늘어나고 각 처리를 요하는 예상 클라이언트의 수를 고려하지 않았기 때문이다. 또한 처리될 양의 계산또한 고려되지 않았고 처리의 방법도 고려되지 않았다. 여기서는 예상 성능치를 반대로 서버에서 얼마나 처리 할수 있는지를 확인하고 필요 요건을 감안해 설계도를 재 작성 해보겠다. WEB 서버에서는 클라이언트들의 요청을 최초로 받아서 요청하는 페이지와 처리를 각 WAS 서버의 Port 로 보내게 되는 간단한 모듈만 작동하지만 성능의 과다가 예상 되고 있고 세션을 기..

#6 전체 시스템 구성도 서버, 네트워크, 소프트웨어의 구성을 완성 했다면, 실제 환경 구성을 위한 전체 시스템 구성도를 그려야 한다. 위의 그림은 간단하게 논리적으로 본 전체 시스템을 본 구성인데, 외부와 연동되는 구역인 Public에는 웹서버 2기, 외부와 직접적으로 연동되지않는 와스서버 2기, 모니터링서버 1기, 내부 DNS서버 1기, DB서버 2기 만 있는 모습으로, 여기에 서버별 소프트웨어가 웹서버에는 HTTPD, 와스서버에는 tomcat 2개씩, 모니터서버에는 모니터링 프로그램인 Zabbix 서버, Scouter 서버, DNS서버에는 named 를 구성한다. 위의 그림에 실제로 구성이 가능한지 모든 부분을 하나로 합쳐서 완성한 후, 스토리지와 기타 네트워크 라인을 구성하고 각 소프트웨어를 서버..

#5 소프트웨어 구성도 소프트웨어는 OS 부터 그 위에 구성되는 유틸리티와 Daemon, WEB, WAS 등등을 말한다. 우리가 컴퓨터를 사게 되면, 윈도우나 리눅스를 설치해서 사용하듯이 서버도 윈도우나 리눅스를 설치해서 사용하게 된다. 물론 가상서버의경우도 OS를 지정해서 생성되게 된다. 물론 우리가 새로운 컴퓨터를 샀을때, 사용할 소프트웨어를 정리하고 위치와 파일의 사용 용량을 걱정하지는 않지만, 서버는 24시간 7일 1년을 사용하기 때문에 위치와 사용할 소프트웨어 그리고 관리를 위한 스크립트까지 전부 기록하고 정리해야한다. 서버안에 들어가는 소프트웨어와 소프트웨어들간의 연동을 보면 위의 그림과 같은데, 서버 안에는 제일 먼저 서버 OS 와 그 위에 각종 유틸리티, 그리고 모니터링 소프트웨어와 배치잡..

#4 서버 구성도 서버는 흔히 사용하는 물리 서버와 가상 서버가 있다. 하지만 결국 가상서버도 물리서버로 이루어져 있고, 관리와 구성에 따라 종류가 나뉘게 된다. 서버의 OS 에 따라서도 나뉘기도 하고, 성능과 구성에 따라 많은 구성이 바뀐다. 흔히 말해 CPU 를 2장을 쓸지 1장을 쓸지와 Disk를 RAID 카드를 이용해 안정성과 속도를 보장하는지 그리고 네트워크 카드의 속도를 1G 이상으로 사용할지 등과 그래픽카드의 사용여부 등을 위해 박스를 바꿔야 할 수도 있다. 최근에는 머신런닝등의 사용으로 그래픽카드가 실장되는 4U 이상 크기의 서버도 많이 쓰이고 있다. AI 서비스를 위해 그래픽 카드를 실장할때는 OS 의 선택도 주로 Ubuntu 를 사용하게 된다. 이번에는 WEB, WAS, DB 의 단순구..