Rust 배워야하지 않을까요? 정보
Rust 배워야하지 않을까요?본문
전 php 로 한 20년 넘개 개발하고 입니다.
php의 장점은 로직을 그대로 반영한 직관적인 개발 정도가 될 것 같습니다.
그런데 업계 에서는 이런 쉬운 점 때문에, 약간 저가로 통용되기도 합니다.
열일하는 실력을 공급자가 많다는 이유로 저가로 오해 받고 있습니다.
그래서 이번에 신분세탁할 수 있는 기회로서 떠오르는 언어인 rust 공부를 권합니다.
최근에 나오는 언어는 쉽습니다.
php 보던 실력이면, 다 할 수 있습니다.
아마도 객체지향이 마이크로서비스로 대체되어가는 분위기 때문에
최근에 나오는 서비스는 속도를 최상으로 올리고 자원을 최적화하면서
싱글턴으로 개발하는게 유행입니다.
jwt 같은 것으로 회원을 별도로 빼주고 서비스 관심사별로 나누어서 연결해주는 방식이
오히려 프로그램을 더욱 쉽게 해주고 있습니다.
예전 기억을 공유하시는 분들이 있을까?
일본 에니메이션인 철인28호를 본기억에 철인28호의 장점으로 이야기된
엔진이 손과 발에 각각 분리되어 있어서 하나가 고장나도
멈추지 않고 계속 사울수 있는 시스템 이게 바로 마이크로 서비스와 비슷한 기능입니다.
한가지 서비스가 죽어도 전체 서비스에는 영향 없이 유지될 수 있는,
반대로 하나의 서비스에 계속 새로운 서비스를 유연하게 더할 수 있는 시스템이
마이크로서비스 msa 입니다.
이러한 경향으로 최근 웹서버 서버사이드 언어는 싱글턴으로 쉽게 만들어집니다.
얼마나 좋은 기회입니까?
엔터프라이즈급 서비스를 객체지향으로 만들지 않고 싱글턴으로 만드는게 유행이라니.
그래서 최근 유행했던 go 해볼까 잠깐 공부를 했었습니다.
go 은 php 만큼 쉽습니다.
그런데, 기왕하려면, 지난 20년간의 서러움을 극복할 좋은 언어로...
조금만 더 노력해서,
RUST를 공부합시다.
장점 딱한가지만 말해보겠습니다.
1. 메모리 관리를 자체 방법론으로 해결함.
이 기술이 얼마나 좋은지 저수준의 언어를 싹스리할 기세 입니다.
앞으로 예상컨데, OS, IOT, 자동차 등 하드웨어 커널 수준의 개발도 rust로 변경될 기세입니다.
효과
1. 에러가 없습니다. 그래서 멈추지 않습니다.
고속으로 움직이는 자동차, 우주로 쏘아올리면 다시는 접속하기 힘든 에러가 없어야하는 우주로켓 이나 인공위성
2. 메모리 에러 따로 없어서 에러 누수 없음
보안에 좋습니다. 메모리 누수 해킹 완전 차단됩니다.
3. 메모리 관리 프로그램이 없어서 메모리 관리에 드는 비용이 없습니다.
- 자바나, go lang 은 가비지컬랙션 같은 메모리 정리하는 프로그램이 도는데, 이때 자원을 사용하나보니 속도가 느려집니다.
4. 속도가 빠릅니다.
- 초당 60만회 결과를 뱉어 냅니다.
5. 특유의 메모리 관리로 멀티 스레드도 쉽게 구현됩니다.
ps. 전자정부 프레임 워크도 Rust 버전 나오지 않을까 싶습니다.
2
댓글 6개
MSA 로 운영하려면 관리할것도 많이 생기고 대규모아닌이상 인력이 적으면
모놀리딕이 낫습니다
https://news.hada.io/topic?id=7839
▲
전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것"
"Monolith > apps > services > microservices"
첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음
둘째, 단계가 중요함
5-50인 회사라면 그냥 Monolith로 가세요
1만명 회사라면, 위의 모든 것들을 다 가지고 있을 것. 근데 예전과 달라진 생각들을 얘기해보자면..
먼저 정의(Definition) 부터
monolith - xyz.com
apps - abc.xyz.com
services - 앱/모노리스를 지원, 핵심 인프라, 핵심 컴플라이언스 기능, 앱팀에서 작성하지 않을 수 있음(인프라에서 유지관리)
microserivces - 몇백라인의 코드, 대부분 일회성, 라이브러리 또는 SDK 일수/있어야(could/should) 함
윗글 링크내용의 msa 우려사항
#1 (특이하게 IT출신 CEO가 이끌지 않는 한) 인프라는 항상 우선순위에서 밀려남(get the short end of priority stick)
#2 서비스가 너무 많으면 일반적으로 소유권 문제 및 경계 문제가 생김
#3 수많은 마이크로서비스를 처리하기 위해 더 많은 도구를 도입함
#4 가장 중요한 것은 라이브러리나 SDK가 되었어야할 각 마이크로서비스들이 프로덕션에 위험을 초래함
금융관련서비스 한게 있었는데 금감원에서 개인정보관련으로
감사나오더니 코스콤클라우드에 뭐 들어보지도 못한 자바관련 솔루션쓰라면서 난리치더라고요
너무 과하게 나가셨네요. 그 CTO 분은..
제가 말씀드린 마이크로 서비스는 위의 기준으로 보면 apps 정도가 될 것 같습니다.
하기사 라이브러리도 서로 분리된 서비스에서도 공동으로 사용할 수 있으니 이를 마이크로 서비스로 구분하여 상호 재활용이 가능하게 한다?
역시 OS 만들던 회사는 스케일이 남다르군요.
제가 생각하고 말씀드린 마이크로 서비스는 요정도 입니다.
회원인증 서비스, 게시판 서비스, 쇼핑몰 서비스 요렇게 나누고
개발을해서 회원인증을 기준으로 각 게시판, 쇼핑몰에 접속해서 별도로 구현해서 합친다.
그래서 쇼핑몰이 죽어도 게시판은 살아서 사용 가능하다. 뭐 이정도.
그리고 점차 컨텐츠몰 붙이고, 서비스 하나하나씩 추가...
서비스를 수십게 붙이면, 별도의 관리 규칙이 있어야겠죠.
그런데, 마이크로서비스는 독립적으로 개발 가능하다는거,
언어가 달라도 되고, 상호 소통하는 커뮤니케이션도 다양하고
하나가 고장 났다고 전체 서비스가 정지될 일도 없고,
메인 개념을 잘 생각해보시고 구현을 생각해보세요.
장점이 더 많습니다.
여러 사례가 있지만, 유연한 사고에서 나온만큼 다양한 방법과 시도가 존재하는데,
각시도들이 가진 문제의 총량이 모든 문제의 동시적 발현은 아닐 겁니다.
위 CTO처럼 라이브러리 단위까지 마이크로 해서 발생한 문제를
마이크로 서비스의 보편적인 문제로 보기에는 마이크로 서비스의 유형이 너무 다양하네요.
광이의 서비스로 보면, 프론트를 spa로 분리하는 것도 마이크로 서비스로 볼 수도 있을것 같거든요. 하나는 앱으로 하나는 웹으로 그리고 api 서버 로그인 파이어베이스 쓰고, SAAS 서비스 이용해서 각 부분별로 나누어서 적용하는 것 뭐 이런게 마이크로 서비스 아닌가요?
객체지양언어 하나로 모두 담아 넣는게 좋다, 작은조직에서는 더욱 드렇다?
그건 백번 양보해도 아닌듯
@임종필 님이 팁이나 러스트 관해서 지식 공유 남겨주시면 좋을것같아요 ㅎㅎ