영상버전 : https://youtu.be/wT1aybuFV2c
인프라를 담당하시는 분들 중 현재 운영중인 구성이 최적인지 전문가의 조언을 들어보고 싶으신 분들이나 운영을 보다 효율적으로 할 수 없을까 고민이신 분들의 사례를 모집합니다.^^
무료로 집을 고쳐주는 방송같은 느낌으로 만들어볼 까 합니다.
현재 제가 하고 있는 일을 설명드리자면요..
새로운 경력이 필요 없어서 지금 현장은 금액보다는 쉬엄쉬엄할 수 있는 현장을 우선시 하고 있구요..
한국의 젊은 스타트업의 일본런칭을 지원하는 일을 하나 하구 있구요..
그리고 어제 지인이 소개해 준 된 한국 기업의 인프라 컨설팅을 하기 위한 정보 요청을 한 상태이네요..
아시는 분의 네트워크를 연결할 때 기술적인 접점을 분석해 주는 일도 하고 있습니다.
짬짬이 일본에 있거나 넘어오고 싶으신 분들의 커리어 싱담 등을 하고 있습니다.
거의 현재로선 돈이 되는 일들은 아니지만 제 나름대로의 투자를 현금이 아닌 경험과 시간을 투자하는 방식이지요.
요전번에 연락 주셨던 분들이랑 가끔 모여서 밥도 먹고 해야 하는데
제 성격이 사람을 끌고 다니는 성격이 아니다 보니 주체적으로 안하게 되네요..
시간 되시는 분들은 언제든 연락주시면 참여는 잘합니다! ^^
본론으로 들어가서
기존 인프라를 얼마나 비용 절감이 가능한지,
그리고 다양한 구성 방법 중에 왜 이렇게 쓰게 되었는지를 설명해서
실제 인프라 컨설턴트가 되고 싶어하시는 분들에게 도움이 되는 콘텐츠로
만들어 보려 합니다.
제 경험으로는 최대 95%이상 절감한 사례도 있으므로 인프라는 얼마나 아느냐가
비용에도 직결하게 되죠.
좀 더 자세한 설명이 필요한 경우 댓글을 달아 주시면
좀더 자세히 또는 따로 콘텐츠로 상세히 다룰 수 있게 해보겠습니다.
지금 현장은 sql과 안덱스 튜닝을 주로 다루었는데요..
이번 주도 내내 튜닝이었는데,
실제로 제 콘텐츠를 보시는 분들 중에 IT컨설턴트를 목표로 하시는 분들이 많기 때문에
그 분들에게 도움이 되도록 다양하게 다루는게 더 좋을 거 같아서 이번엔 다른 것을 말하려 합니다.
실무를 위주로 전달을 해드리기 때문에
그 동안 배우신 모든게 부정당하실 수 있습니다.
하지만, 이론과 실제가 왜 다른지에 대해서도 설명을 드리려고 하니
제가 선정한 것에 대한 질문을 더 주시면 더 자세히 알려드릴께요..
그리고 이번의 이 환경을 위해서는 이렇게 했지만,
이게 정도가 아닐 수도 있습니다.
단지 비용 효율화를 극대화 함으로서
리스크를 안고 비용 효율화를 하는 경우도 있구요,
안정성을 위해서 비용을 얼마든지 써도 되는 현장이라면
안정성에 최고수준으로 올려버리게 되는것이지요.
때문에 똑같은 환경이라 할지라도 이렇게 달라질 수 있다는 것을 알아 두시기 바랍니다.
이번에는
SSL을 이용한 부하분산이야기를 다루어 보겠습니다.
보통 SSL 인증서를 설치하는 위치는 서버 또는. LB또는 GLB, Application Gateway같은 네트워크 장치에 많이 두지요.
서버에 SSL을 설치하면 서버 대수가 늘어날 때마다 SSL갱신을 위해 모든 서버에 적용해야 하는 불편함이 있습니다.
요즘은 CI/CD를 이용한 자동 디플로이가 잘 되어 있다면 소스 디렉토리에 갱신된 SSL을 넣기만 하면 되는 편리함은 있지요.
네트워크 장비에 SSL을 넣게 되면 편리한 점은 네트워크 장치에 갱신하면 한번에 적용 된다는 장점.
그리고 네트워크 장비에서 서버 구간은 SSL통신을 하지 않아도 되기 떄문에 암호화된 정보를 서버까지 가져가서 통신하지 않아도 되기 때문에 부하가 줄어듭니다. 기본적으로 SSL통신 패킷량은 일반 패킷보다 2배 정도 커집니다.
서버에서 SSL전용 포트인 443을 사용하지 않아도 되기 때문에 하나의 서버에 여러 프로세스를 올려도 프론트에서 봤을 때는 SSL처리가 되는 것 처럼 보입니다.
이 때문에 서버 리소스를 더욱 효율적으로 사용할 수 있게 되지요.
서버에 SSL을 올려버리면 443포트를 점유해버리기 때문에 다른 프로세스는 SSL을 넣을 수 없게 됩니다.
물론 nginx같은 웹서버라면 멀티 호스트로 관리가 되므로 문제가 없지만,
게임이나 독자 프로세스를 올려버리게 되면 방법이 없게 되는 것이지요.
그렇게 해서
제가 현재 관리중인 agw를 보엳리겠습니다.
하나의 도메인에서 서비스하는 front, back두 개의 셋을
개발, 스테이징, 리얼의 세 개의 환경에서 사용하게 했는데요..
원래라면 각각의 agw를 설정해서 처리하는게 정석이라 배우셨을 겁니다.
하지만 스타트업이라면 되도록 인프라 비용을 줄이려고 하게 됩니다.
Application gateway는 부하분산 장치라서 1개당 월 3~40만원 정도하는 고가의 인스턴스가 사용됩니다.
때문에 하나의 agw에서 저 여섯개의 환경을 전부 사용할 수 있다면 좋지 않을까요?
그리고 application gateway는 L7이기 때문에 가능하지요.
만약 L4였다면 IP단위로 분류할 수 밖에 없기 때문에 불가능합니다.
또한 Front Door는 DNS베이스의 GSLB이기 때문에 분류는 가능하나 웹서비스 같은 표준 서비스만 분산이 가능하고 특수한 프로세스는 결국 Agw를 써야 하지요.
세 개의 환경에 프론트, 백 두 개의 프로세스라서 6개의 서브 도메인을 만들었습니다.
이 여섯개의 도메인에 모두 ssl을 넣는데요, application gateway에서 등록하겠습니다.
저건 프론트 도메인이기 때문에 리스너에서 사용하는 것이구요. .
이들의 실제 서버가 있는 도메인도 등록을 해야지요..
이번에는 서버 한대당 환경 하나로 서버 하나에 front, back 두 개의 프로세스가 있는 설정으로 해보겠습니다.
그럼 환경에 따른 서버를 도메인으로 매핑해야지요. IP로 해도 되지만, IP는 클라우드에서는 바뀔 위험이 있기 때문에 domain으로 하는 버릇을 들여두시는 것이 좋습니다.
그래서
svr-dev.littleworld.net
Svr-stg.littleworld.net
Svr-real.littleworld.net
이렇게 설정해 놓겠습니다.
보통 SSL증명서 중에 와일드카드는 서비스에 따라 다르지만 연간 50~100만원 정도 합니다.
하지만 스타트업의 경우 이 비용조차 아깝습니다.
그래서 3개월 마다 갱신을 해야 하지만 무료인 Let’s Encrypt를 사용합니다.
Let’s Encrypt에서 SSL등록은 아주 쉬우니 찾아서 해보시구요..
만약 어렵다면 막힌 곳을 알려주시면 해결 방법을 알려드릴께요..
이렇게 받은 SSL증명서를 저 모든 도메인에 등록 합니다.
우선 Agw에서 Listener, Backend, Backend Setting을 해주시구요..
거기서 Listener가 밖에서 들어오는 처리를 하기 때문에 SSL을 넣어주면 되지요.
설정이 되면 연결을 위한 Rule을 설정해주는데요..
하나의 Rule에 하나의 Listener와 Backeend를 사용합니다. Backend Setting은 공용이므로 동일 세팅이라면 같이 쉐어 하면 되지요.
이렇게 맞추어 주었으면 서버에서 확인을 해야 겠지요.
서버에서 프로세스는 프론트가 4000, 백엔드가 3000으로 설정하겠습니다.
설정이 다 되었으면 소통 테스트를 해야지요.
소통 확인 설정이 있는데,
소통 확인 설정을 하면
자동으로 설정 맵이 그려지고 체크를 하게 됩니다.
이렇게 하면 설정이 끝나구요…
무언가의 문제로 소통이 끊기면 여기서도 바로 알 수가 있지요.
이번에는 여기까지이구요..
유저 트래픽이 너무 많아진다면 agw를 분산해야 하구요..
Agw를 분산해서 뭉치는데 front door를 사용하기도 합니다.
이런 느낌으로 분산을 최소화 한 뒤에
규모에 따라서 어떤 덩어리를 추가하여 어떻게 다시 분산처리를 할지를 고민해서 설계하면
대규모 처리도 가능해지고
기존 환경의 최적화도 제안할 수 있을 것 같습니다.
환경 구성에 도움이 되셨길 바랍니다.
댓글
댓글 쓰기