인프런 커뮤니티 질문&답변
작성한 질문수
마이크로서비스
작성
·
204
0
1. 수업에서 accountapp 외 3가지 앱으로 나눠서 도커 컨테이너 돌리는 것이 마이크로서비스가 맞나요??
2. 맞다면, 마이크로서비스로 적합한 서비스가 있고 그렇지 않은 서비스가 있다고 하더라구요. 지금 이 핀터레스트 프로젝트는 마이크로서비스에 적합한 어플리케이션인지 궁금합니다.
3. 그리고 앱을 나누는 기준 또한 처음에 설계할 때 힘들더라구요.. 앱들 사이에 반드시 독립적이어야 하는건지 그 앱들 사이에 뭔가 필요에 의해 호출이 필요한 상황도 발생할 수 있을 것 같은데, 마이크로서비스를 구현할 때 앱을 나누는 기준을 이해하기 좋은 자료가 있을까요?
4. 서비스를 설명할 때 클라우드 기반 서비스 이렇게 말하는게 있더라구요. 클라우드 기반 서비스라는 것이 이처럼 여러 컨테이너로 앱을 구성해서 클라우드를 통해 내결함성있는 서비스를 말하는건가요?? 아니면 클라우드 서비스(예를 들어, aws lambda)를 사용해서 클라우드 기반 서비스라고 하는건가요?
이 질문을 하고 싶은 이유는 제가 수행한 프로젝트가 최근에 클라우드의 이점을 활용하지 못했다는 평을 받아서인데요.
저는 로컬에서 데이터베이스나 mqtt broker 등을 구축하지 않고 단순히 ec2안에 제가 자체적으로 설치해서 외부 컴퓨팅 자원을 빌려쓴다는 의미에서 클라우드 기반 프로젝트라고 제가 명명했거든요. 근데 아는 분이 이건 그냥 로컬에서 한거나 다름없다고 IDC에서 하는 작업하고 똑같은 작업을 한거라 클라우드를 활용했다는 이점이 없는 작업이었다고, 클라우드 기반 프로젝트라 한다면 CI/CD를 구축한다거나 컨테이너로 구축해서 오케스트레이션을 해야 한다고 의견을 주셨습니다. 제가 면접에 가서 클라우드를 학습했다고 말할 때 어필하려면 어떻게 개선시켜야할까요??
답변 3
0
0
안녕하세요.
질문 확인했습니다.
죄송합니다.
답변내용이 조금 길어질것 같아서 짧은 질문 답변드리고
그 이후에 답변드린다는게 제가 답변드리는 것을 까먹어버렸네요 ㅠㅠ
살짝 강좌 외적인 내용이라 완벽한 답변은 드리지 못할 수 있지만,
어느정도 참고하실 수 있을 정도의 답변은 되지 않을까 싶습니다.
답변드리겠습니다.
1. 수업에서 accountapp 외 3가지 앱으로 나눠서 도커 컨테이너 돌리는 것이 마이크로서비스가 맞나요??
- 마이크로서비스는 소규모의 독립적인 서비스로 구성된 아키텍처라고 볼 수 있습니다.
그런데, 이 소규모의 독립적인 서비스라는 단어에서 약간 모호함이 있다고 볼 수 있죠.
저희는 강좌에서 django / nginx / mariadb 와 같은 서비스를 분리했지만,
정말 더욱 더 서비스를 작게 쪼개서 서비스하고자 한다면,
django 내의 서비스들도 계정기능 / 게시글 기능 / 댓글 기능 등등 으로 나누어 서비스 하는 것도 가능하겠죠.
소규모 서비스라는 단어에 약간의 모호함이 있긴 해도,
저희가 구축한 서비스가 마이크로 서비스라고 부르기에 크게 부족한 내용은 없다고 생각합니다.
2. 맞다면, 마이크로서비스로 적합한 서비스가 있고 그렇지 않은 서비스가 있다고 하더라구요. 지금 이 핀터레스트 프로젝트는 마이크로서비스에 적합한 어플리케이션인지 궁금합니다.
- 마이크로 서비스에 적합한 서비스 라는 것은 아무래도 클라우드의 장점을 살릴 수 있는 서비스를 말하는 것이 아닐까 생각합니다.
일단 클라우드의 가장 뛰어난 장점중에 하나는 유연성입니다.
서비스를 제공하는 도중 평소와 달리 트래픽이 많이 발생할때,
마이크로서비스아키텍처 및 클라우드 기반으로 만든 서비스는 간단하게 클라우드 인프라 제공자로부터 자원을 더 할당받아
서버가 자원이 부족해 다운되거나 하는 상황은 쉽게 방지할 수 있겠죠.
하지만 직접 서버 컴퓨터를 구입하고 관리하는 입장이라면,
이런 유연한 서비스 확장 정책이 힘듭니다.
트래픽이 증가한다면, 서비스에 접속하는 순서에 따라 Queue 를 만들고
순차적으로 요청을 처리하는 정도의 방식이 최선의 대처겠죠.
그런 의미에서, 마이크로 서비스에 적합한 서비스 라는 것은
제 생각으로는, 의도하지 못한 트래픽이 많이 발생 가능한 서비스가 되지 않을까 싶습니다.
반대로 적합하지 않은 서비스는
트래픽이 꾸준히 안정적으로 유지되는 서비스가 아닐까 생각하구요.
제 개인적으로 이렇게 나누어 보기는 했지만,
교과서적으로 마이크로서비스에 적합한 서비스와 아닌 서비스를 칼같이 나누는 것은 한계가 있습니다.
결국 서비스를 구축하는 개발자 및 팀에서 자체 서비스의 성격 및 패턴에 따라 판단해야 될 문제죠.
3. 그리고 앱을 나누는 기준 또한 처음에 설계할 때 힘들더라구요.. 앱들 사이에 반드시 독립적이어야 하는건지 그 앱들 사이에 뭔가 필요에 의해 호출이 필요한 상황도 발생할 수 있을 것 같은데, 마이크로서비스를 구현할 때 앱을 나누는 기준을 이해하기 좋은 자료가 있을까요?
- 이 질문은 저도 명확히 나누어 드리기 힘들다는 말씀을 드립니다.
말씀하신 것처럼 앱들 사이에 필요에 따라 호출이 필요한 상황이 발생 할 수도 있을지 모르기 때문에,
본인이나 팀이 구성하고자 하는 서비스의 내부 구조에 따라 판단을 해야 하는 문제입니다.
정확하게 마이크로 서비스에 대한 기준은 아닙니다만,
'Two scoops of django' 와 같은 책에서도 앱을 분리하는 기준에 대한 언급이 나옵니다.
그런데 해당 내용도,
정확하게 어떻게 나누어야 한다! 라는 정확한 기준보다는
앱 하나에 웬만하면 최소한의 기능만 포함하는 것이 좋다 라는 방향성 제시정도만 하는 것을 볼 수 있습니다.
마이크로 서비스도 마찬가지입니다.
웬만하면 최소한의 기능만 포함하는 것이 좋다! 라는 방향성을 염두에 두고,
서비스 구축을 진행하시면 되지 않을까 싶습니다.
4. 서비스를 설명할 때 클라우드 기반 서비스 이렇게 말하는게 있더라구요. 클라우드 기반 서비스라는 것이 이처럼 여러 컨테이너로 앱을 구성해서 클라우드를 통해 내결함성있는 서비스를 말하는건가요?? 아니면 클라우드 서비스(예를 들어, aws lambda)를 사용해서 클라우드 기반 서비스라고 하는건가요?
- 위의 답변 내용과 어느정도 맞닿아 있는 내용같습니다.
최근 대체적으로 클라우드 기반 서비스 라는 것은 마이크로 서비스 아키텍처의 장점을 이용하는 서비스라고 이해해도 무방할 정도로 마이크로 서비스의 영향력이 커졌습니다.
이는 서비스 시에 발생할 수 있는 의도치 못한 상황에 대처할 수 있는 유연한 스케일링이 가능한 서비스라고 생각 할 수 있을것 같아요.
물론 AWS 에서 인스턴스를 빌린 후에,
마이크로서비스아키텍처 구성을 하지 않고도 클라우드 기반 서비스 라고 말은 할 수 있겠지만,
해당 서비스는 클라우드 서비스라고 하기에는 클라우드 장점을 살리지 못하는거죠.
물리서버를 직접 구입해서 운영하는것과 전혀 차이가 없는 상태이니까요.
제가 면접에 가서 클라우드를 학습했다고 말할 때 어필하려면 어떻게 개선시켜야할까요??
- 마지막 내용에 답변을 드리자면,
결과적으로 답변 내용과 연결되는 것 같아요.
모든 스택을 한 인스턴스에 넣는 것이 아니라,
마이크로 서비스로 분리, 서비스 한 이후,
오케스트레이션을 통해 유연하게 스케일링이 가능하도록 구현까지 해보셨다면
어느정도 경험을 해보았다! 라고 말할 정도가 되지 않을까 생각합니다.
많이 부족한 내용같아 보이긴 하는데,
도움이 되셨길 바랍니다.
좋은 하루 보내시구요!
감사합니다-
0