Trend of Web

VanillaJS

프레임워크를 되게 비관적으로 생각하는 사람들도 있다. DOM하는 데에는 편하지만, 굉장히 느림. 웹팩이 가장 유명한 번들링 툴인데, 그거만 해서 충분히 프로그래밍할 수 있다라고 보는게 vanilla js입니다.

대중적으로 쓰인다까지는 아니지만 눈여겨볼만한 변화이다. 유니티에서 발표한 자료에 따르면 실제 3D 렌더링 엔진을 굉장히 버벅거리지만 올릴 수 있는 수준이라고 작년에 이야기를 들었다.

실제 c++ 어플에 비해서 속도가 1/2밖에 차이가 안난다. 이런 바이트 코드를 컴파일해서 올릴 수 있는 기술이 웹 어셈블리이다.

굳이 적절한 건 아닌 것 같지만, 이런 프레임워크의 변화가 자바스크립트의 변화때문이라고 생각한다. 프레임워크가 개발을 편하게 해주는 것도 있긴 한데, 우리나라에서 제일 점유율이 높은 프레임워크를 이야기하자면 리액트를 이야기할 수 있다. (리액트 네이티브)

리액트의 경우에는 Virtual DOM을 사용한다. 6주부터 시작해서 Tree 기반으로 아래로 쭉 가는 형태로 작업을 하게 된다. 리액트 16 이전과 이후로 나뉘는데, 이러한 변화가 크진 않지만 약간 있다. 처음 할 때에는 state나 프롭스로 많이 관리했었다.

그 다음에는 Angular JS가 있다. 구글에서 만든 기술이고, 리액트에 비해서는 자주 사용되지 않지만 변화가 많다. 쓰기 복잡하지만 쓰는 곳은 꽤 있다. 배틀그라운드 로비도 Angular로 만들었다. 렌더링 툴의 가장 큰 변화는 Ivy가 런칭이 됐다는 점이다.

Angular Rendering : 한국에서는 jQuery만 쓰는 추세였다. 느리지만 개발 속도가 빠르다는 장점이 있다.

Tree-Shaking : 자바스크립트가 기본적으로 트리 구조의 DOM을 바꾸는 형태에서 착안해서 최근에 만들어진 기술

Vue.js

Svelte : Virtual DOM 형태로 하게 된다. 직접 컨트롤하는 방식으로 하게 되고, 렌더링 속도가 다른 세개에 비해서 빠르지만 변형하는 데에는 느리다.

Server Side Rendering

백엔드 개발자들이 프레임워크의 변화에 유의있게 반응하는 것은, 예전에는 서버 사이드 렌더링이 html로 반환을 했었는데, 최근에는…

풀스택개발자를 찾는 이유가 서버 개발자가 html을 다 짰어서 알았어야했는데.. 지금은 클라이언트에서 api 형태로 받아서 액션을 취하거나 화면에 그리는건 클라이언트가 한다. (현대 어플리케이션)

심지어 데스크탑 어플리케이션이나, CLI 창도 기본적으로 그렇다. 렌더링을 전문적으로 하는 서버만 따로 띄워서 처리를 하는 방식을 주로 차용하고 있다.

리액트, 앵귤러로 개발하시면 서버를 같이 끼워주기 때문에.

GraphQL

• 유용하다는 사람도 있고. Rest API의 단순한 형태를 더 쿼리 지향적으로 처리할 수 있게 도와준다. 이를 사용하게 되면 클라이언트에서 복잡한 형태의 URL을 전달할 수 있기 때문에 복잡한 표현을 할 수가 있다는 장점이 있다.

현재의 변화

• 기존에는 브라우저가 서버로부터 HTML을 받아 렌더링, 디스플레이하는 형태였다면 지금은 서버 사이드에선 API를 통해서 데이터를 전달하고 상태 관리 등이 오늘 날의 형태이다. (이런 식으로 프론트가 많이 변화하고 있다.)
• 일반적으로 왜 Json을 쓰는가? 이 변화에 맞춰서 바뀌고 있기 때문이다.

백엔드의 변화

서버에서도 가장 큰 변화는,

옛날에는 PHP로 다 때려박아서 했었는데 지금은 여러 개의 서버로 구성되어 있다. 서버들의 집단? 서버들이 엄청나게 많이 모여있고 대규모 요청이 들어와도 스케일 아웃이 되게끔만 설정하면 잘 돌아가는 편이다.

지금의 백엔드 구조에서는 분산된 구조의 서버로만 이야기를 하게 된다. 분산 서버를 쓰게 되면 코딩이 더 어려워지겠지만, 반응속도가 빨라져서 분산서버를 도입함.

도커

대부분 도커를 쓴다. 대규모 서버 배포에 있어서 중요한 역할을 차지하는 도커.

대규모의 서버 군집이라는 표현을 썼었는데, 그러다보니 군집을 관리할 친구들이 필요해짐. 서버를 한 개 띄웠는데 사람이 계속 몰려와서 서버 전체가 부하 -> 서버를 빨리 늘려서 짝짝(?) 보내야하는 친구가 있을 수 있고. 이 시간에는 사람이 안 몰려서 서버를 끄고. 이런 기술이 필요하다.

-> Orchestration (우와…. 너무 신기하다)

가상의 클라우드 컨테이너들을 지휘하는.

도커와 같이 Go로 개발한 쿠버네티스, 스칼라로 개발한 마라폰? 마라톤?

와!!!

HTTP Server

Tomcat 등등. 앞단이나 뒷단에 놓여서 HTTP 관련 데이터를 처리한다.

Nginx (엔징스?)

분산된 서버 처리에 가장 잘 맞는다. 성능도 대규모 처리에선 async가 필수인데 그런 걸 지원하기 때문에 잘 맞는다고 볼 수 있다.

Database

접근이 쉽다는게 장점이라서 엄청나게 많은 데이터가 발생하게 된다. 네이버 뉴스란 댓글, 좋아요만 해도 엄청나게 많은 데이터들이 실시간으로 발생하게 되는데, 이 데이터를 처리하는 것이 데이터베이스의 핵심 화두이다.

• RDBMS : 통상 RDB와 RDB가 아닌 것으로 나눈다. B-Tree 계열의 자료구조로 구현되어 서치가 빠르고 대규모 인서트가 느리다. 구조상 키를 잡고 트랜잭션 걸기가 쉽다. 이게 B-Tree의 핵심. 강력한 트랜잭션을 보장할 수 있고. 릴레이션십을 보장할 수 있다. 레플리카(복제해서 빠른 처리를 유도하는 것)가 어려움.
  • SQL Server, Oracle, MySQL, PostgreSQL(클래스 기반 DB), DB2(쫌 옛날꺼), SYBASE, Maria DB
• NoSQL : 레플리카가 쉽다. SQL이 없고 함수 기반으로 처리하고 특정 쿼리 패턴을 갖게 된다. RS..덴..트리? 컬럼 단위라서 인서트가 빠르다.. 레플리카같은 작업이 빠르다
  • Key-value store : RAM에 저장 캐싱 디비.. redis..
  • DocumentDB : MongoDB 파일철 저장하는 것처럼. 정규화가 아니라 역정규화 패턴을 통해서 최대한 깔끔하게 쓰는 게 목적이다. json 형태의 key-value로 되어있어 이해하기가 매우 편하다. join이 근데 불가능함. join을 안해서 데이터를 어떻게 역정규화할 지가 핵심 포인트임. (Trello는 MongoDB가 메인 DB임…)
  • Column DB : Key-value 형태 다음으로 많이 쓰임. H-BASE(hadoop)나 카산드라(로그 조회). join이 없고 column형태로 저장, 근데 insert가 빠름. -> 네이버 댓글 감정을 Column DB로 저장
  • Graph DB : RDB에서는 그래프 형태로 저장하기가 힘든데, 가령 친구 관계에서 내가 알 수도 있는 친구를 저장하는 데에 쓴다. Vertex, Edge로 이루어진다.
  • AMPQ : 서버-서버 데이터 처리를 어떻게 처리할 것인가? 백엔드만 쓰는 기술은 아닌데, 성능이 굉장히 빠른 운영체제에서도 많이 쓰는 방법인데, 메세지 큐라는 특정 태스크 저장 큐에 데이터를 넣고 큐에 데이터가 들어있다는 이벤트를 발생시켜서 이를 처리할 수 있는 다른 작업자에게 알려주는 방식. 보통 커맨드큐, 이벤트큐는 만들어서 사용하고 백엔드에서는 AMPQ라는 메세지 큐를 사용한다. (레비던트, 카프카) 대규모 서버간의 명확한 통신을 하지 않고 메세지를 전달하는 큐를 통해 이벤트를 받아 처리할 수 있게 도와줌
  • Message 기반 프로그래밍 : 분산된 서버에서는 메세지 기반 프로그래밍이 중요함. 어떤 서버가 어떤 처리를 할지를 명확하게 명시를 할 수가 없음… 일이 들어올 때마다 바로 넘겨줘야해서 그런 비동기 메세지?를 처리하는 사람이 필요. 이게 필요하다면 카프카를 추천한다.
  • gRPC : RPC라는 기술은 ipc 통신규약의 일종. HTTP를 안씀. HTTP의 한계점은 너무 쉬움. 구조도 너무 쉽고 전달할 수 있는 데이터도 얼마 안된다. HTTP 메소드 4개로는 너무 처리가 안된다. 이를 위해 조금 더 복잡한 통식인 RPC를 처리함. (Remote Procedure Call) 클라이언트가 루비라면 루비가 C++ 함수를 호출할 수 있게 해줌. 만들어서 보통 사용을 해야하는데 운영체제도 알아야하고 내부 기술도 잘 알아야해서 복잡함. 누가 한 명 만들어놓고 쓰자 해서 만들어둔 놈이 구글이고 그게 gRPC임.
    • HTTP는 blocking이 되기 때문에 non-blocking 기술이 필요하다. 그게 gRPC. 그래서 아주 유용함.
    • HTTP는 json과 통신함. gRPC는 Protobuf를 사용해서 통신을 하고, 일반적으로 사람이 편하게 읽을 수 있는 데이터는 속도가 느리다. 바이너리 데이터는 읽을 순 없지만 컴퓨터가 처리하기엔 빠르다. gPRC는 그래서 Protobuf랑 많이 처리한다. IDL? gRPC 웹 1.0 버전이 나옴.
  • Event-Driven System : 서로 간의 역할이 다르기 때문에 어떻게 관리해야하는가에 대한… 이벤트 기반의 시스템으로 메세지 큐같은걸 써서 서버간 서버를 컨트롤.. 일을 시킬 수 있는 방식으로 변화하고 있다.
    • Service discovery : 이 서버가 죽었는지 살았는지를 기록해두는 상치. UTC나 리본? 유레카? 같은걸 쓴다. 클라이언트는 Hadoop, 카프카가 쓰는 기술인 ZooKeeper를 쓴다.
  • API Gateway : 서버 군집에 들어가기 전 첫번째 관문. 프론트 서버라고도 부른다. 어떤 요청이 왔을 때 해당 요청을 처리할 서버를 찾아줄 수도 있고, 로그를 남긴다거나 로드밸런싱을 한다던가, 인증(SSH 인증, JWT Token 권한처리), 캐싱 등의 역할을 할 수 있다.
    • 이를 HTTP로 사용하는 방식이 리버스 프록시
  • Circuit Breaker
  • Distribute Database
  • 디스코드, 알리바바 등 대규모 처리 하는. 마이크로소프트 아키텍처라는 이름으로 굉장히 많이 풀리고 있다. 서버를 분산하면 어떻게 해야 할것인가? 단순하게는 HTTP 처리로는 쉽지만, 너무 아쉬운 점이 많다 라는게 핵심.
• Two Phase Commint : 서버가 분산되어있다보니까 DB의 트랜잭션을 보장하기 어려워짐. DB가 여러개고 이 데이터들을 다 유지해야하는데 어떻게 할 것인가? 이걸 무식하게 해결하는걸 Two Phase Commit이라고 한다. 이건 DB에 lock을 한다.
  • 처리가 굉장히 명확하고 쉽지만 속도가 느리다.
• Saga Patterns : 이벤트를 발행시켜서, 이벤트가 트랜잭션의 키가 되어서 처리가 끝날 때까지는 보지 않는다. 과거의 버전으로 처리할 수 있게 하는 거임. 더티라이트? 한 처리가 다른 서버의 처리에 영향을 미치지 않기 때문에 이방법을 주로 사용한다.
• 빅데이터쪽 유용한 변화 : Data Warehouse. 대규모 읽기만 가능하게끔 설계. 로그 데이터를 분석해야 한다, 머신러닝, 딥러닝을 하게 되면 뭐 필요한 그런거.
• 아파치, 스파크를 많이 쓰는데 Data Streaming 기술이 중요해짐. 대표적인게 아파치 플링크. 한국에서도 대규모 프로젝트나 고성능 데이터 스트리밍이 필요한 곳에서는 아파치 플랭크? 를 자주 사용한다.

JVM

JVM Garbage Collector

• JVM이 왜 계속 변하고 있냐면, 멀티 플랫폼에서의 처리를 고려하지 않으면 레퍼런스 카운트가 가장 빠르다는 c Python의 연구 결과가 있습니다. 왜 계속 바뀌냐? 가비지 컬렉터 알고리즘이 왜 계속 바뀌는거냐? 하면 멀티 코어에서의 처리를 더 효율적으로 하려고.
• 기본적으로 Keep Allocator의 처리..를.. Young Generation과 Old Generation을…
• Young : 금방 해체될 개체들 -> 가득 차면 처리할 게 많으니까 비운다. 전체 메모리를 돌지 않아도 처리를 할 수 있다. 그래서 자바는 Heap을 사용법에 나눠서 이런 식으로 사용하게 된다. unuse된거 메모리 알리고, paging이 일어나서 메모리 곳곳에 구멍이 나서 캐시라인을 다 무너뜨리니까 compacktaion을 한 번 한다.
• Old : 오래동안 살아남을 것 같은 개체들
• 이 과정이 일어나려면 Stop the world를 한다. 모든 프로세스를 잠깐 멈추고, 컬렉터의 기능을 정상화시키는 것이 가장 큰 목적이다. Garbage COllector을 잘 알아야 하는 이유 : 서버가 멈추면 안되니까.
• 클라이언트는 멈출 수 있는데 서버는 멈추면 안됩니다. Garbage Collector를 잘 알아야한다.

• 객체 생성하는 것에도 주의해야 하는 이유가 이거임.

• 가비지 컬렉션을 어떻게 처리할 것인지?

  • Serial GC : 굉장히 노멀한 처리 방식. Mark - Sweep - Compaction : 멀티 코어에서 느림
  • Throughput Collector

  • CMS : 명시적인 동작을 하려고 하는 시도

  • Race Condition 때문에 실패할 수 있음? 자바 파일 이후로는 되게 잘 안쓰는 것으로 알고 있다. CMS같은 경우에는 멀티 코어를 돌리기 시작했다.

• G1 Collector : 멀티 스레드 자원.. Heap.. Full DC..? application과 generation간의 관계..? old generation의 크기를 늘리면..?

• 세렌도어를 쓸 수 없는 상황이라면 G1 GC를 쓸 것이다.

• GC Tuning이 어플리케이션 성능 향상에서 중요하다.