나도아빠다
2k
2019-02-25 13:34:52 작성 2019-02-25 15:43:30 수정됨
21
2167

웹서버와 was이야기.


최근 첼시 경기들에 멘붕하고 삶의 의욕을 상실한 아빠다입니다..ㅠㅠㅠㅠㅠㅠㅠ

오래간만에 와도 web was질문이 꾸준하기에 제가 대충 알고있는 정보 주르륵 써봅니다.

물론 제 머릿속 이야기를 모바일로 대충 풀어내는거라 틀린부분도 많을테니 언능 태클들 부탁드립니다. 빨리 수정할수 있도록 말이죠..

---------------------------------------

프알못 아저씨의 옛날이야기

---------------------------------------

태초에 웹서버가 존재함 apache- php iis-asp..

그러다가 자바도 이런거 왜못해 하고 나온게 서블릿이었고, 서블릿이 발전해서 jsp가 됨.요놈을 처리하는 자바 서블릿컨테이너들이 솔솔 나옴.


복잡한 엔터프라이즈 환경에선 웹서버가 제공하는 인터프리터 언어들이나 단순한 j2se, jsp정도로는 그 큰규모 개발이 감당이 안돼기시작함


java EE- EJB가 슬금슬금 대형 si시장 잡아먹음

이 Java ee- ejb처리를 위해 was가 등장함. Was도 당연히 웹서버의 기본기능(분산처리 가상호스트 정적콘탠츠 제공) 다 갖고 있음.

Was는 기본적으로 웹컨테이너 자바서블릿컨테이너 ejb컨테이너 등 컨테이너 로 구분하여 기능을 제공해주고 필요한대로 쓰도록 함.


Ejb가 워낙에 덩치가 크고 동작하나하나가 무겁다보니 모든 처리를 was하나로 하기엔 부담스러워짐.. 그렇다거 was댓수를 늘리자니 비용이 압박임.


그래서 일반 사용자가 자주사용하는 정적인 페이지는 공짜고 가벼운 웹서버가 먼저 처리하고 끝내버리고, 실제로 백단의 무거운 로직이 필요한 경우에만 was,그중에서도 ejb컨테이너나 서블릿 컨테이너.. 호출하게함.


그러다보니 대규모 사이트의 경우 web - was구조가됨. 주목적은 접속자 분산을 통한 서버 부하를 줄여주는 용도.


같은식으로 발전했지요


그런데 요즘엔 저게 아예 안맞습니다. 

스프링이 등장한 이유도 애초에 탈 ejb였고(ejb2.0시절의 스텁 스켈레톤 지옥은 다신 겪고싶지않습니디..) 스프링은 was정도의 규모가 거의 필요없습니다. 톰캣같은 서블릿컨테이너만 해도 ejb급의 기능을 구현하는데 큰 지장은 없거든요.

그래서 사이즈가 제법 큰 경우에도 web-웹컨테이너 정도로 경량화 되서 사용되거나, 작은 서비스의 경우나 규모가 좀 커도 톰캣의 마개조를 통해 그냥 웹컨테이너로만 사용 되는 방향으로 많이 전환되었습니다. 핵심은 공짜+공짜 또는 그냥 공짜.


굳이 web-was를 고집하는 곳은 was자체가 제공하는 안전성 때문에 사용되는, 잠깐의 기능정지에도 치명적인 공공기관이나 금융권 같은 대형서비스들정도겠지요. 

공짜 서버가 할수없는 가장 큰 이슈인 서버가 문제 터졌을때 즉각적인 a/s문제를 연단위 계약으로 1년 365일 해결해 주니까요.


하지만 그나마도 aws의 등장으로 또 변하고있습니다.

Aws가 서비스로서 강력한 제일 큰 이유인 끊김없는 서비스(서버 소스 업데이트를 하건 사용자 폭주로 급히 스케일업을 하건 이미 돌고있는 서버는 일부러 죽이기전엔 죽지않는 방탄서비스!!) 로 인해 was가 가진 안정성부분을 웹컨테이너를 aws로 보내는거 하나로 해결해버릴 수 있게 되어버렸거든요.

----------------------------------
여기까지가 자바에 대한 이야기였습니다
왜 자바냐? 애초에 was라는 용어가 등장한 이유가 자바때문이었으니까요.


그러다보니 웹서버들도 자기살길 찾으려고 노력합니다. 
지원언어도 늘려주고, 직접 지원하지 않는 언어의 웹 어플리케이션은 proxy를 통해 연결할수있게 지원하는 등등, 그동안 쌓여왔던 웹서버의 기능을 다른 어떤 언어로도 쉽게 사용할 수 있도록 발전중이지요.

노드, 루비온레일즈, 파이썬, go 등의 경우  빠르고경량화된 웹을 개발하기 좋습니다. 그러다보니 이런언어들은 ejb급의 was정도의 기능제공하는 미들웨어는 그리 많지 않아요. 
일반적으로 자체제공하는 라이브러리를 통해 적당히 웹서버 기능을 만들거나, 필요시 적당한 미들웨어를 가져다 쓰는식이지요. 마찬가지 접속자가 엄청날거같으면 웹서버로 앞에서 총알받이 하도록 구성도 가능하지만, 이런 경량 웹 프레임워크들은 클라우드의 힘을 믿고 서비스하는 경우가 더 많은거같습니다.


서버 사양이 딸리고 백단의 처리가 규모가 상당하여 서비스에 접속자가 많이 붙었을때 커버가 위험할경우, 제공해주는 서비스에서 스태틱 리소스의 비중이 클경우에는 여전히 웹서버를 앞쪽에 총알받이로 두는게 유효할겁니다.

백단처리가 가벼울경우에는..애초에 컨테이너 정도로도 처리는 충분하고, 필요하면 웹 컨테이너 댓수를 늘려버리는게 개발이건 유지보수건 편해 보입니다.

----------------------------------- 
어쩌다,차오주님 추가
요즘엔 ejb지원상관없이 정적인 컨텐츠 대신 어플리케이션을 돌리면 그냥 was로 부르고 있습니다.
그러고보니 제안서에도 딱히 구분없이 늘 써왔던거같네요.. 위의 이야기는 "옛날이야기"로 봐주시면 되겠습니다!!;)

용어가 이렇게 섞여버리니.. 세계 최초 was인증으로 먹고살던 투모 소프트만 점점더 불쌍해지는 기분이네요...

주절주절 말은 길었네요.. 여튼 언능 태클들 주셔요
0
1
  • 댓글 21

  • 맨시티가 결국 이겼어요😄

    (전 맨시티팬입니다)

    0
  • 어쩌다
    5k
    2019-02-25 13:39:03

    요즘은 톰켓을 was라 부르지요 태클입니다...ㅎㅎ

    0
  • 나도아빠다
    2k
    2019-02-25 13:39:54 작성 2019-02-25 13:44:26 수정됨
    잠만보/ 케파..아나... 쿠발놈 다음은 케발놈.. 체흐뒤론 첼시의 키퍼는 왜이렇게 막장 일변도인가요.. ㅠㅠㅠㅠ
    0
  • 나도아빠다
    2k
    2019-02-25 13:44:04 작성 2019-02-25 13:45:37 수정됨

    어쩌다/ 읭? 톰캣이 java EE지원 되나요? 애초에 was 인증 조건이 javaee지원 여부일텐데..?


    옛날부터 적당히 섞어서 말하곤 했는데.. 정확한 의미로는 톰캣은 옛날부터 웹컨테이너(was기능중에서 웹컨테이너 기능만 구현한)로 정의하는 걸로 알고있습니다..

    0
  • 나도아빠다
    2k
    2019-02-25 13:48:44
    차오주/ 용어가 많이 희석됐네요 ㅎㅎ 제우스만 점점 불쌍해지는 기분이..
    0
  • 어쩌다
    5k
    2019-02-25 13:51:28

    아빠다 님 말씀이 맞아요...

    그런데 요즈음 자꾸 짜장면 처럼 자장면이 표준어이던시절이 있던거랑 같은듯

    다들 was라 불러요...그런데 was가 web application server 니 끼워 마추면  톰켓도 was는 맞지요..ㅎㅎ

    0
  • 나도아빠다
    2k
    2019-02-25 13:54:26

    어쩌다/ 제가 아저씨다보니 꽉막혀서 그런거같습니다 ....ㅎㅎㅎ

    언능 글에 추가해뒀습니다!

    0
  • 어쩌다
    5k
    2019-02-25 14:00:02

    //아빠다

    저도 아저씨입니다...제가 더 많을거 같기도..ㅠㅠ

    다른이유가 아니라. 요즘은 아파치 + 톰켓 구조로 많이 사용하다보니

    아파치를 웹서버 톰켓을 와스로 기능분리를 할려고 일부러 그러는듯해요

    둘다 웹서버라고 하면 혼선이

    0
  • 나도아빠다
    2k
    2019-02-25 14:02:58

    어쩌다/ 웹컨테이너는 말이 좀 어렵긴하지요 역시...

    10년전이나 지금이나 톰캣은 그냥 was대우 받는거같습니다 ;)


    그러고보니 외국에선 어떻게 부르는지 궁금하네요.

    0
  • icewall
    2
    2019-02-25 14:16:27

    케파 종신!!

    0
  • 나도아빠다
    2k
    2019-02-25 14:18:50

    Icewall/ 케파 종신형! 언능 딴데로 치워버렸으면 좋겠..지민 그놈의 몸값..

    0
  • fender
    14k
    2019-02-25 14:29:09

    제가 알기로는 원래도 'WAS'는 서블릿 컨테이너를 포함한 의미로 사용했습니다. 그 중 EJB를 포함한 J2EE 표준을 준수하는 WAS를 '풀스택 컨테이너'라고 부르는 것이 일반적이었는데, 우리나라에서는 이런 저런 이유로 풀스택 컨테이너만을 'WAS'라고 부르는 것이 관행이 된 것 같습니다.

    제 생각에 풀스택 WAS의 인기와 몰락은 성능보다는 기업 시스템 아키텍쳐를 구축하는 방법의 추세 변화에 따른 것인 것 같습니다.

    이 부분에선 역시 국내와 외국의 인식 차이가 있는데, 우리나라의 경우 비즈니스 시스템의 핵심은 언제나 데이터베이스이고 그 위에 얹는 것은 그게 서블릿이건 EJB건 인터넷으로 값을 조회하고 입력하기 위한 중간 단계 쯤으로 생각하는 경향이 있습니다.

    반면 외국의 경우 '기업의 IT 시스템을 구축한다'는 것은 데이터베이스를 설계하는 것도 포함되지만 무엇보다 시스템의 API를 어떻게 만드느냐에 대한 문제를 핵심으로 보는데, 과거 EJB가 하던 역할은 바로 기업의 핵심 비즈니스를 구현하는 API를 구성하는 기본 단위였습니다.

    당시 인식으로, '좋은 시스템'이란 시스템의 모든 API가 동일한 언어, 동일한 표준으로 서로 유기적인 관계로 이어져있고, 스케줄링이나 메시징, 캐싱 서비스 같은 구현에 필요한 모든 기술은 어느 회사 제품을 쓰건 API가 구동되는 플랫폼에서 동일한 표준으로 API 측에 노출시키는 그런 형태의 아키텍쳐였습니다.

    또한 트랜잭션이나 보안, 분산처리 등은 비즈니스 개발자가 다루기 복잡한 기능 역시 모두 플랫폼이 표준 API를 통해 제공하는 개념입니다.

    문제는 그런 기술 표준들이 실무에 필요한 기능을 다 제공하지 못해 WAS 벤더가 제공하는 기능을 사용해서 J2EE 표준 WAS를 쓰면서 도리어 기술 종속이 발생하기도 하고, 스프링 같은 풀스택 WAS로 필요로 하지 않는 프레임워크도 인기를 얻고, 무엇보다 기술 환경이 J2EE 같은 단일 표준에 수직으로 쌓아 올리는 것 보다는 클라우드 환경에서 다양한 기술로 구현된 마이크로 서비스 같은 걸 느슨하게 연동하는 형태의 아키텍쳐가 더 인기를 끌게 된 것이 결정적이었습니다.

    정리하면, J2EE 깉은 시스템이 각광을 받은 건 성능이나 WAS만 제공하는 특별한 기능 때문이라기 보다는, 단일한 기업 시스템 표준 플랫폼이라는 이상이 공감대를 얻었던 때가 있었기 때문에, 그리고 지금 인기가 없어진 것은 그런 이상이 프로젝트 현실에서 이런 저런 문제점을 겪는 동안 마이크로 서비스나 서버리스 시스템 같은 보다 현 시점 기술 환경에 적합한 아키텍쳐가 주류가 되었기 때문인 것 같습니다.

    0
  • 나도아빠다
    2k
    2019-02-25 14:49:50 작성 2019-02-25 14:52:18 수정됨

    Fender/ 풀스택 컨테이너라는 용어는 처음 듣는지라.. 일단 검색좀해보고 어떻게 글 수정할지 확인해 봐야겠습니다. 구글검색으로는 안나오는군요 ㅠ

    일단 와스의 정의는 해외기준은 잘은 몰라서.. 일단 제우스가 javaee 인증을 받으면서 웹투비와 함께 판매할때 한국에 정의가 저렇게 된걸로 추정중입니다 ㅎㅎ

    애초에 was라는 개념이 없던시절, was는 java ee를 지원한다가 ibm, 투비 소프트 등 최초로 was라는 용어를 사용한 업체들을 통해서 기본 스펙화 되었던거고, was=Java ee지원 이라는 용어로 정착되었던걸로 보입니다. 

    영문 위키 기준으로는 말씀하신 풀스택 컨테이너가 java application server라고 정의되어있네요. 이쪽이 더 정확한 용어로 보입니다 ;-)


    이후의 내용들은 제 글 안에 적당히 녹여도 큰 지장없을것 같아서 어떻게 보강할지 고민중입니다. 

    제가 쓴 핵심역시 옛날처럼 ejb쓸일 없으니 비싸고 무거운 was를 쓸필요 없다.. 경량서버들은 웹서버도 필요없다 as도, 접속 몰리는문제고 아마존 느님 계시다.. 이제 공짜 쓰자! 가 핵심이니까요.


    0
  • 어쩌다
    5k
    2019-02-25 15:01:58

    공짜가 핵심이군요..

    참고로 어느 쇼핑몰 경우 톰켓 2-30 개로 서비스 합니다..ㅎㅎ

    0
  • ㅇㅈㅇ
    3k
    2019-02-25 15:14:18 작성 2019-02-25 15:20:23 수정됨

    서블릿이 발전해서 JSP가 되었다는 문장 어색해요. 

    서블릿에서 결과로 전송하는 페이지를 순수문자열로 처리하기에는 

    너무 불편하기에 해당 부분만 빼서 편하게 만든게 JSP인데,

    서블릿이 발전해서 JSP가 되었다는 문장은

    자바가 발전해서 애플릿이 되었다는거랑 다를게 없는 문장같습니다.


    이 뿐 아니라 같은 방식이 글 전반적으로 많이 있네요.

    JSP가 감당을 못해서 EJB가 등장하는 부분도 그렇고.. 

    EJB같은 프레임웍이 등장하려면

    그 비교 대상도 프레임웍내지는 POJO가 되야 할거같은데 

     EJB쓴다고 JSP를 안쓰는것도 아니고..


    저는 무슨 말을 하고 싶은지 대충 알겠는데 

    이제 시작하는 분들한테는 너무 혼란을 많이 줄거같아서 

    태클걸어요.

    1
  • 나도아빠다
    2k
    2019-02-25 15:24:06 작성 2019-02-25 15:40:06 수정됨

    ㅇㅈㅇ/ 음 전 awt가 발전해서 스윙이 되고 스윙이 javafx가 되었다 같은 의미로 사용한건데.. 좀 어색한가요?ㅎㅎ

    어떤말로 고치는게 나을지 알려주시면 넙죽 바꾸겠습니다!!

    그리고 ejb가 특정 프레임웍이랑 비교되는것 역시 어떤의미인지요.


    제가 알고있기론 ejb가 java ee를 래핑하는 거의 최초의 대형 프레임워크이고,(개별로 회사별로 클로즈드 스타일로 사용하던 라이브러리는 제외하고..)이것과 비교되는 비즈니스 프레임워크들은 ejb의 영향하에 또는 반발해서 나오기 시작한 것으로 알고있습니다.

    Ejb가 특정 프레임워크 대체는 아닌걸로 알고있습니다.

    제가 잘못알고있는거라면 그부분에 대해 자세한 설명을 좀 부탁드리겠습니다


    만약 서블릿 컨테이너용 프레임워크들(스트럿츠같은) 이야기라면, 위의 이야기는 was에 관한이야기라 애초에 서블릿 컨테이너용으로 나온 프레임워크들은 제외하였습니다. Was나 ejb보다 뒷세대이야기라 오히려 햇갈릴수도 있어서요..

    Was(제우스가 이야기하는)의 정의가 j2ee라는 가정하에 시작한 내용이라서..

    0
  • fender
    14k
    2019-02-25 16:12:27 작성 2019-02-25 16:19:52 수정됨

    딴지 거는 것 같아서 좀 그렇지만, 개념 정리 글과 그에 대한 답글이라기엔 조금 부정확한 내용들이 있습니다.

    EJB는 J2EE를 '래핑하는' 프레임워크가 아니라 반대로 J2EE가 EJB나 서블릿 등 단위 기술 명세를 포함하는 집합적 명세입니다. 또한 스트러츠 등은 EJB의 뒷세대에 나와 EJB와 경쟁하거나 하는 프레임워크가 아니라 EJB의 웹 프론트엔드로 흔하게 사용되던 프레임워크였습니다.

    좀 부연을 하자면, J2EE는 처음엔 웹 프레임워크를 포함하지 않았지만 '펫 스토어(PetStore)'라는 예제에 포함된 MVC 구조가 인기를 끌었고 비슷한 아이디어를 바탕으로 스트러츠 같은 독립적인 프레임워크가 등장했습니다.

    이후 J2EE의 공식적인 웹 프론트엔드 구현 프레임워크는 JSF가 되었지만 여전히 스트러츠, 스프링MVC 등이 인기를 끌었고 이런 저런 이유로 우리나라에선 JSF가 많이 쓰이지 않아 잘 알려지지 않았습니다.

    아마 'WAS'를 J2EE와 동일한 것으로, 그리고 서블릿 컨테이너는 그와 다른 무엇으로 생각하시는 것 같지만, 위에서 언급했듯이 'WAS'는 원래 포괄적 의미이고 J2EE 컨테이너/스펙은 서블릿 컨테이너/스펙을 포함하는 관계입니다.

    0
  • 나도아빠다
    2k
    2019-02-25 16:28:30 작성 2019-02-25 16:30:14 수정됨

    Fender / 이런딴지라면 언제든 환영합니다.

    제가 잘못알고있는 정보들은 빨리 갱신해야하니까요

    J2ee가 j2se상위 개념이고 j2ee명세를 만족하는 프레임워크로 ejb를 이해하고있었는데 제가 그부분을 오해하고있었던것같습니다


    스트럿츠나 jsf같은부분은 was랑은 좀 다른이야기라  제외했는데 마침 이야기 해주셔서 감사합니다. J2ee - ejb시절의 영향을 받은 현재 사용중인 프레임워크들이 꽤나 많이 있지요.

     제가알기로는 스트럿츠1이 ejb2.0시절에 등장한걸로 알고있어서 굳이 ejb의 뒷세대 라는 표현을 사용하였습니다. 제가 쓴 댓글만 보면 j2ee와 완전 별개로 보일수도 있을거같네요


    제가 쓴 글중에서 was와 서블릿 컨테이너 라는 말은 j2ee와 j2se로 바꿔야 더 정확하게 되지않을까 싶네요.

    아무래도 was = j2ee라고 가정하고 시작한게 무리수인부분이 좀 있지않나 싶습니다.

    0
  • 타키투스
    861
    2019-02-25 16:38:52

    근본적으로 둘다 같은 겁니다. WEB Server, Web Application Server.


    단지 기술 스펙으로 인한 분야가 다르게 발전해 온것 뿐이여서 각자의 영역이 존재할 뿐이지 다를바가 없어요. WAS 이전에는 그냥 Application Server 라고 있었지만 이것을 Web 이라는 미디어를 대상으로 서빙에 특화된게 Web Application Server  입니다. 


    문제는 Application Server 의 경우에 Application 을 제작하는 프로그래밍 언어에 종속적으로 발전되어 왔다는데 있습니다. 흔히 말하는 Java WAS 의 경우에는 Java 를기반으로 Application 를 제작할테고 .NET 은 C# 으로 하나요... PHP, Python 모두 Application Server 를 다 가지고 있지요. 이들이 Web 이라는 미디어를 대상으로 서빙을 할려면 당연히 HTTP 통신 프로토콜을 다루고 각종 기능들을 추가해서 뭔가를 만들어야 하는데 그게 WAS 가 되는거겠죠.


    사실 따지고 보면 JEE 스펙을 모두 구현한 서버들(Jboss EAP, WebLogic) 을 WAS 라고 하는것은 좀 안맞는거죠. Web 을 기반으로 서빙을 안할거면 저 서버들이 가치가 없는것도 아니고... 요새는 Web 을 기반으로 뭔가를 할거면 뭐하러 저런거 쓰냐~ 하는 말까지 나오니까.. 그냥 Web Container 구현체인 Tomcat 에 Spring 이면 OK 하는 분위기도 있고..


    스트럿츠나 Spring 이런것들은 JEE 스펙에서 EJB 의 영역을 Web Container 영역에서 구현할 수 있도록 해준거라고 알고 있습니다. 그러다보니 Web Container 구현체 서버만 있으면 EJB 따위야 필요가 없는거니까.. 단, Web 을 대상으로만 한정되는 제약이 있지만...

     

    0
  • 나도아빠다
    2k
    2019-02-25 20:37:09

    타키투스/감사합니다. Was라는 단어 선택따라 받아들이는게 엄청나게 달라지네요.

    일찍 수정하고싶었는데 업무가 많아서 수정이 쉽지않내요


    Fender님과 타키투스님 이야기 모아서 밤에 한번더 수정정리하겠습니다

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.