채니의 mimimimamimimo 블로그

 

개발하는 소프트웨어의 구조를 먼저 파악하자!

 

참고자료

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

https://d2.naver.com/helloworld/819776

---

프론트엔드

 

반응형 웹?

반응: 자극에 의하여 어떤 현상이 일어남/그냥 이쁜게 아니다!

-> 같은 서비스를 디바이스 환경에 맞춰서 적절한 반응이 일어남

 

미디어 쿼리-서버랑 클라이언트는 아무것도 안함. 웹브라우저가 css코드를 읽고

해당 디바이스에 맞춰서 비율 바꿈.

 

이런 느낌~~? 하나의 파일에서 분기처리를 해서 구현한다!

 

good: 한 개의 파일에서 분기처리 가능

bad:레아아웃 복잡해지면 유지보수 어렵고 성능저하

 

적응형 웹은 분기처리 아니고 파일 여러개를 만들어서 서버,클라이언트에서 디바이스 체크 후

맞는 파일 불러와서 구현한다.(서비스 복잡할 때 좋음)

 

good:해상도별 최적의 성능 

bad:유지보수 어렵고 개발비용 많이 듬

 

전략-대응범위

계속 분기하면 끝도 없으니 대응 범위(디바이스,브라우저 범위) 정해야 함.

하위호환범위도 정해야 함(오래된 브라우저..)

->오래된 브라우저는 레이아웃 깨져도 되느냐?가 아니라 최소한의 UI를 보장하는 것!

->브라우저는 한 파일에서 동작하도록~

->안내메시지 사용

 

전략-큰화면->작은화면 구현?작은화면->큰화면 구현?

모바일이 위주면 후자가 될 수도 있는거!

 

 

전략-레이아웃 방식

플루이드 그리드-컬럼 넓이 값을 화면크기에 맞춰서 바꿈(상대단위 %em사용) //성능이슈 작다고 함

(컨텐츠 적어서 빈공간 많아질수 있으면 최대크기 제한가능)

 

컬럼 드랍-플루이드 그리드 했을때 가독성 떨어진다면, 폭 좁아질때 텍스트를 밑으로 내려버리는 방법

 

레이아웃 쉬프터-화면이 변할때마다 새로운 레이아웃을 제공함. 

 

섬네일 리스트-크기에 따라 보여주는 한줄에 보여주는 섬네일 갯수를 조정

 

+폰트&이미지리사이징(과도한 조정은 성능저하..) 

특히 아이콘 같은건 크기따라 리사이징 하기 어려워서 이미지를 애초에 여러개 만들어둔다.

(태블릿용,pc용..)

 

+플리킹-해상도 변경되면 고려, 터치기반이므로 pc화면에서 좌우버튼 노출..성능별로

 

//여기까지 다 반응형 웹이다!

 

[구축 순서] 폭-계층hierachy-상호작용-밀도

폭-컬럼 비율 좌측 본문 어느정도로 분배할건지 정하는 것. 해상도마다 그 비율 어떻게 다르게 할건지 정함

계층-화면 크기 줄이면 계층이 어떻게 변하는지 정하는 것. 

상호작용-햄버거라고도 부른다! 화면 작이지면 하나의 메뉴로 압축된다

밀도-화면이 작아지면 답답해질수 있기 때문에 컨텐츠를 제거하거나 크기 조절.

 

사진크기가 작아졌다! 

 

+Responsive Pattern(반응형 웹 템플릿 많이 있음)

+스타벅스 스타일 가이드 참고해서 만들면 짱!

 

 

 

 

 

---

백엔드

뒤에서 데이터 처리하는 것. 

but! 쌓이는 데이터가 기하급수적으로 증가하고 있기 때문에 그것을 어떻게 견디는 구조를 만드는지가 주하다. 

 

사용하는 기술

운영체제-centOS,ubuntu,Window,Mac

언어-Java(고이느라 자바로 점점 바뀜..노하우가 자바로 쌓이니까)

개발환경-이클립스(공짜니까), 인텔리제이(다양한 환경 세팅을 도와줌,선호도 좋음,깃배포도 잘됨)

빌드툴(자바에서 바로 컴파일 하지는 않는다!왜??라이브러리 같은거 추가제거 할 때 신경 안쓰기 위해서)-아파치앤트,메이븐(디펜던시 관리 쉬움),그래들

버전관리툴(코드공유,협업을 위해서)-svn(공통저장소 하나만 있음)->git(각자 저장소가 있어서 코드리뷰 가능)

지속적인 통합(CI,로컬에서만 빌드하는게 아니라 개발자들이 각자 빌드하고 나중에 한꺼번에 빌드할 때 필요): 공통 레포지토리에 각자 코드 올림, CI서버에서 머지코드 가져와서 빌드해본다, 테스트코드 돌려본다, 정적분석 주기적으로 한다(널포인트 익셉션 발생할거 같다.등등..) 

/ex/ a가 커밋한걸로 ci서버에서 빌드했는데 실패하면 담당자들이랑 분석해보는거.

  ㄴ툴:젠킨스,허드슨

 

 

ㄴ위는 테스트 커버리지다! (어느 부분이 테스트 코드가 부족하다 등의 내용을 표시)

 

배포는 dev,staget,real 순으로 된다.

 

 

 

dev    crud 정도를 직접 입력할 수 있는 곳에서 돌려봄

stage 리얼서버와 동일한 cpu,메모리 환경 구성해서 돌려봄

기능 테스트까지 다 해보고

real 서버에 올림!

 

 

기능이 크고 규모가 크면 서버 100대씩 쓰기도 한다. 

하나하나 컴파일해서 톰캣 띄우고 하면 답이 없기 때문에

사내자동배포 시스템이 있음~~(원클릭)->dev stage real중에서 어디 배포할건지 조정해줌

 

"사용자 로컬에서 개발하고 배포서버에 요청하면 배포서버에서 공용레포지토리에 코드를 가져오고 각 배포환경에 보내준다"

 

웹서비스 구조(=서버 구성, 컴포넌트 구성)

 

웹서비스에서 컴포넌트란? ( https://imcreator.tistory.com/7 ,  https://imcreator.tistory.com/7)

 

 

하나의 서버가 10개의 클라이언트에게 정보를 제공할 때, 모듈은 2개를 가지지만 컴포넌트는 11개가 된다.

컴포넌트: 런타임 개체를 참조, 즉 객체라고 볼 수 있음. 독립적으로 배포될 수 있는 단위

모듈: 기능 중심으로 나뉘어질 수 있는 단위.

 

 

컴포넌트가 모여서 모듈을 이룰 수도 있고, 모듈이 이루어져서 컴포넌트를 이룰 수 있음.

 

 

웹서버에서 로드 밸런싱 일어나서

웹서버:WAS=' 1:1~다' 로 이루어짐

웹서버:정적페이지//얘만 브라우저(클라이언트)와 소통한다//네트워크프로그래밍 필요

was:동적파일 //비즈니스로직(서블릿의 실행흐름) 담겨있다//멀티쓰레딩 필요

캐시서버:게시판랭킹10위같은건 디비 자꾸 접근하면 부하 크니까 캐시서버 사용,.

배치서버(배치:일괄처리):사용자요청 받아서 10위같은거 받는거 말고,사내에서 뭐가 잘팔리는지 수익률,이런걸 데이터 정제해서 저장해두는곳. 

ㄴ스프링배치 굉장히 고도화 되어있어서 잘 사용한다.

+스프링: 위의 전과정을 할 수 있도록 지원해주는 라이브러리 집합소(툴로있음 STS Spring Tool Suite->여기서 비즈니스 로직 짤 수 있다):

비즈니스로직서버:네이버의 BLOC서버: 다양한 프로토콜 제공, 비즈니스 로직만 담고있는 컨테이너 플랫폼. 

 

네이버는 was로 톰캣 주로 쓴다. 

톰캣은 http만 반환하지만 BLOC은 다음과 같이 제공한다.

 

이런 복잡한걸 한눈에 볼 수 있는 모니터링 서버 개발하자는 의견 나왔음!

 

 

데이터 요청시 원하는 프로토콜로 요청하면 알아서 매핑해서 갖다줌.

 

 

 

 

http계속 맺고 끊기 싫어서 사내프로토콜을 tcp기반으로 따로 만들어서 쓰는중이다. 

각 서비스마다 선호하는 프로토콜 다름~

 

학생 개발자들이 오픈 api 쓰는거처럼

네이버는 여러 기업들에게 api를 제공하고 있다.

+api: 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스.

+인터페이스: 서로 다른 장치에서 정보를 주고받을 수 있게 해주는 경계면

->즉, api라고하면 네이버장치와 삼성장치의 사이에서 네이버가 쌓아오고 정제한 정보를

삼성이 파라미터 던져주고 받게 끔 해주는 연결고리. 구현된 프로그램.

 

 

데이터베이스(오라클,몽고디비...다양하게 쓰고있다)

뭔말인지 모르겠네

샤딩이나 파티셔닝으로 좀 나눈다.

여러 사람이 같은 블로그 보는 경우?

->캐시서버,검색플랫폼,키밸류 씀

 

 

테스트 (단위테스트)+(기능테스트)+(부하테스트//ngrinder)

 

모니터링 (장애가 발생하면 담당자에게 문자감)

 

트러블슈팅->자동화 툴 없음!!없을 것!!<-도와주는건 있음(제니퍼 apm툴..덤프파일 보기 쉽게 되어있음) //네이버-Hello world에 삽질결론 많이 있으니 참고

 

특히..데이터가 계속 많아지기 때문에 원래는 되던게 안될수도 있다

대표적으로 이런 문제들 생김.. ->막기 위해서 IDC,Raid,로그수집시스템,서버증설바로할수있는 시스템,큐브리드(RDBMS),하둡 사용..

 

 

마지막!!!오픈소스!!!굉장히 선호한다!!!트렌디하니까~~

 

 

 

 

 

 

 

---

 

그 다음 요즘엔 웹어플리케이션 구조가 사용되고 있다. C/S구조에서 가장 큰 문제점은 매우 빠르게 변화하는 시대에 로직도 매우 빈번히 업데이트가 되어야 하는데, UI로직과 비즈니스 로직이 클라이언트에 있기 때문에 클라이언트에 있는 프로그램들을 서버측 데이터로직이 바뀔때마다 업데이트를 해줘야 한다. 이것이 매우 귀찮고 제대로 이루어지지도 않을 수 있기 때문에 아예 그냥 서버단에 UI로직 비즈니스 로직 데이터 처리 로직 등을 모두 놓겠다는 것이다.

 

정확히 말하면 웹어플리케이션 서버에 UI로직과 비즈니스 로직이 들어 있고, DMBS는 데이터 처리 로직을 담당하며, 웹 서버는 단순히 클라이언트의 요청을 받고, 웹 어플리케이션 서버를 멀티 쓰레딩 환경에서 실행시키는 중계자 역할만을 하게 된다.

또한 클라이언트는 웹서버가 내어준 응답을 단순히 화면에 뿌려주는 역할만 하는 어찌보면 메인프레임 시대의 단말기와 비슷한 기능을 하게 된다.

 

다시말해서, 서버단에 굉장히 여러개의 서버를 만들어 놓고 분산 처리를 하는 것이다. 이렇게 될 경우 매우 빠르게 변하는 요즘 같은 시대에 로직이 변하더라도 서버쪽만 바꿔주면 되기 때문에 적합하다고 할 수 있다.

 

웹 어플리케이션 서버에 배포된 자바로 구현된 웹 어플리케이션을 서블릿이라고 한다. 

 

 

출처: https://simsimjae.tistory.com/216 [104%]

 

 

1.PC와 서버 간의 데이터 전송은 웹브라우저와 웹서버간의 네트워크 프로그래밍으로 자동으로 이루어지기 때문에 개발자들은 더이상 직접적인 네트워크 프로그래밍을 신경쓰지 않아도 된다.

 

2.웹서버가 자동으로 웹어플리케이션서버를 멀티 쓰레딩 환경에서 작동하게 끔 해주기 때문에, 개발자가 이부분을 직접적으로 신경쓰지 않아도 된다.

 

개발자는 단순히 비즈니스 로직과 UI로직 데이터 처리 로직 딱 이 3부분만 구현하면 웹어플리케이션을 만들수 있게끔 편의가 제공 된것이다.

 

 

출처: https://simsimjae.tistory.com/216 [104%]

---

 

 

 

웹서버와 WAS의 차이?(https://victorydntmd.tistory.com/121)

웹서버: 정적인 컨텐츠를 제공(html,css,js) //아파치 //꺼내주기만 하는 창고라고 할 수 있다

WAS: 동적인 컨텐츠를 제공(DB조회, 로직 처리)  //톰캣  

하지만! 대부분의 was는 정적인 컨텐츠를 제공하기 때문에 웹 서버 없이 was만 존재 가능.

즈 , was는 웹서버를 포함하는 개념이다.

 

 

->그럴거면 웹서버를 굳이 앞에 두는 이유는??

1.정적인 문서만 처리하는 경우 서버의 부담을 줄일 수 있다. 

2.was의 환경설정 파일을 외부에 노출시키지 않도록 하기 위해서.(was접근포트와 웹서버 접근포트는 다르다)

 

로드밸런싱이란?

서버의 부하를 분산시키기 위해 가상 IP를 통해 여러 서버에 접속하도록 분배하는 기능. 

 

 

클라~브라우저+~웹서버~포트포워딩~WAS(톰캣:DB조회하는 로직있음)~커넥션 풀~DB

 

 

+서버를 증설한다?

예를 들어서, 로그인페이지(html)를 웹서버에서 주면 서블릿파일(톰캣 커넥션풀 코드 포함//원래 개발자가 우분투에서 이걸 직접 만듬)가 was에서 동작하는데, 이떄 html(정적)과 서블릿(동적)페이지를 연결할 때 스프링프레임워크(툴있음) 써서 연결하는거다. 트래픽이 몰려서 터질수 있으면 물리적 was를 몇 대 늘리고 로그인서블릿파일을 늘린 was에 배포후,

 포트포워딩으로 웹서버와 was를 로드밸런싱해준다. 그리고 db관점에서 자신에게 접근할 수 있는 커넥션을 풀에서 눌려주는 것.

 

*이클립스IDE는 jvm실행의 입출력을 GUI로 보여주는 것 뿐이다.

 

 

플랫폼: 개발환경, 웹서비스 만들면 jvm이 플랫폼임

플랫폼을 간략히 정의해 보면 소프트웨어를 실행할 수 있는 기반으로 볼 수 있다. 

라이브러리: 코드들의 집합(차로 치면 와이퍼,전조등..) 특정기능을 api로 호출해서 이용

프레임워크:라이브러리의 집합(소형차를 위한 자동차 프레임) 틀을 만들어두는 것

 

 

---