코드를 작성하는 것은 정말 재미있는 일이다.
아주 작은 기능을 담당하는 작은 조각 하나를 만든다.
그런 조각을 2~3개 더 만들어 그것들끼리 연결을 지어놓는다.
이렇게 해 놓으면 꽤 많은 기능을 처리해낸다.
작은 조각 하나하나는 아주 단순한 몇 가지 기능만 할 뿐인데, 그런 것들이 2~3개만 모여도 꽤 다양한 기능을 해낸다.
2~3개의 조각이 모인 그것을 또 여러 개 만들어본다.
그리고 그것들이 상호 작용하게 한다.
서로 연결을 지어주는 것만으로, 훨씬 더 많은 기능을 담당하게 되었다.
2020-04-29 팝잇(popit)에 기고한 글 ⤴️
이 글은 적당히 갖춰나간 운영 환경의 후속 글이다. 이전 글에서는 서비스의 외형적인 모습을 소개했다면, 이번 글에서는 그것을 가능하게 했던 내부의 문화를 소개한다.
MSAMicro Service Architecture
이 삽질을 3년이나 하고 나서야 뼛속까지 알게 되었다. 이건 기술의 문제가 아니었다. 문화였고 일하는 방식이었다. 익스트림 프로그래밍Extreme Programming, 이하 XP이 소개된 지는 이미 20년이 넘었지만, 계속해서 XP를 얘기하는 이유는 MSAMicro Service Architecture는 일하는 방식과 떼어서 얘기할 수 없기 때문이다. 아주 많은 작은 서비스들에게 역할과 책임을 부여하고, 그 서비스들이 상호 작용하며 만들어낸 서로 공존하는 상태.
2020-04-15 팝잇(popit)에 기고한 글 ⤴️
2016년, 중국 패션 리테일 영역의 클라우드 서비스 회사가 되겠다는 야심 찬 희망을 품고 아기 발걸음1을 시작했고, 2020년 현재 아래와 같은 구성을 갖추었다. 처음부터 이런 구성을 그려놓고 차근차근 갖춰 나간 것은 아니었다. 2016년 봄, 알리(Ali) 클라우드에 3대의 리눅스 서버를 구매해서 1대에 대충 스테이징 환경과 각종 관리 툴을 세팅하고 2대 서버에 운영을 위한 최소한의 구성만 갖춘 채 첫 번째 기능을 출시했다. 매번 필요할 때마다 점진적으로 아키텍처를 개선해 나갔고, 4년이 지난 지금 꽤 그럴싸한(?
Go에는 다른 대중적인 언어와 다른 개념들이 좀 있다.
클래스를 과감히 빼버렸고 (그래서 상속이 없다) Exception이란 것도 없다 (예외 상황 자체를 허용하지 않겠다는 의지인가? 멋있어 보일진 몰라도 솔직히 불편하다. ㅠㅠ 궁시렁 궁시렁…) 고루틴과 채널을 이용한 병행처리 모델도 친숙한 개념은 아니다 여기에 한 가지 더 보태자면, Context란 녀석이다.
처음 얘기한 세 가지는 Go 언어를 사용해서 뭔가를 만들려면 반드시 알아야 할 개념이기 때문에 Go 언어를 처음 접하는 대부분의 사람들은 시간을 할애해서 이 부분에 대해 공부를 한다.
중국 이커머스 최대 행사인 쐉쓰이(双十一)때 11월11일 0시가 되자마자 매출이 급상승함과 동시에 이벤트가 미친듯이 순식간에 몰려드는 것을 보고, 일 년 전 밤을 지새우며 O2O 시스템을 Event driven 방식으로 바꾸느라 고생했던 순간이 떠올랐다.
쐉쓰이의 분위기는 동료가 쓴 글인 개발자가 바라본 중국 쇼핑 축제 쐉쓰이(광군제)에 생생하게 나타나 있다. 실제 당일날 MongoDB 인덱스 문제, 디스크 부족으로 인한 kafka 서버 장애, 등 몇몇 문제가 발생하기도 했지만, 고객에게는 문제없이 서비스가 제공되었고1, 쐉쓰이(双十一)는 무사히 지나갔다.
이번 글에서는 쐉쓰이(双十一)를 버틸 수 있었던 요소 중 하나였던 Event driven 방식을 소개하려고 한다.
Go My Way는 Go 언어로 웹 어플리케이션을 작성할 때 선호하는 나만의 방식을 3편에 걸쳐서 소개하는 글이다. 이전 글은 읽지 않았다면 아래 링크를 참조하기 바란다.
Go My Way #1 - 웹 프레임워크 Go My Way #2 - 데이터베이스, 로깅 Go My Way #3 - 트레이싱 번외 - gomobile 이번 글에서는 트레이싱에 대해 소개하겠다.
이 글을 작성하는 지금 현재 우리 회사는 클라우드 상에 50여 개의 마이크로 서비스가 서로 얽혀서 동작하고 있다. 사용자의 한 번의 클릭이 실제로는 여러 마이크로 서비스들을 거치고 거쳐서 최종 결과를 고객에게 보여준다.
Go My Way는 Go 언어로 웹 어플리케이션을 작성할 때 선호하는 나만의 방식을 3편에 걸쳐서 소개하는 글이다. 이전 글은 읽지 않았다면 아래 링크를 참조하기 바란다.
Go My Way #1 - 웹 프레임워크 Go My Way #2 - 데이터베이스, 로깅 Go My Way #3 - Configuration, Tracing, etc. 번외 - gomobile 이번 글에서는 데이터베이스와 로깅에 대해 소개하겠다.
데이터베이스 다른 언어에서 주로 사용하던 ORM(루비의 active record, 닷넷의 entityframework, 자바의 JPA, 등)을 생각한다면 Go의 DB 관련 패키지들은 대부분 2% 20% 이상 부족하다.
루비의 Ruby on Rails, 자바의 Spring, 파이썬의 Django, 노드의 Express. 대부분의 인기 있는 언어는 메인 프레임워크가 있다. 그래서 고민 없이 그 언어에 맞는 메인 프레임워크를 사용한다. 하지만 Go는 이런 게 없다. Go는 많은 기능을 하나의 프레임워크에 담아놓는 방식보다, 상황에 맞게 필요한 패키지를 조합한 마이크로 프레임워크를 만들어 사용하는 것을 권장한다. 익숙해지면 이것이 편하지만, Go를 처음 접하는 사람들에게 어떤 패키지를 사용해야 할지 선택하는 것은 여간 어려운 일이 아니다.
Go 언어를 접한 지 3년이 되었고, 지난 1년 동안은 아주 적극적으로 Go 언어를 사용했다.
사내 세미나 전 생각 정리를 위한 글
회고 올해 4월부터 micro-service를 지향하면서 일을 해 왔다. 사실 별로 커 보이지도 않는 기능들을 다양한 서비스로 나누고, 여러 팀에서 나누어 개발을 해 왔다. 기능적으로 본다면, 샵링크(중국 5000여개 매장의 판매 업무를 총괄하는 시스템)와는 비교도 되지 않을 정도로 작고, 그룹웨어보다도 훨씬 작은 싸이즈이다. 그 큰 시스템도 하나의 서비스로 잘 돌아가고 있는데 POS를 통해 위챗 쿠폰을 사용할 수 있게 하자는 단순한 요구를 위해 OO개의 팀에서 OO개의 서비스를 만들었다.
http://blog.remotty.com에 게시한 글을 Go 언어에 대해 발행한 글을 수집하는 차원에서 이곳으로 옮겨왔다.
서비스를 만들때 비정상적으로 서비스가 종료되지 않고 안전하게 실행되도록 하는 것은 아주 중요하다(Resilency). 이번 포스트에서는 Resilency를 유지하면서 서비스를 작성하는 여러가지 방법에 대해서 소개하겠다. 오늘 소개하는 글은 지난 7월에 덴버에서 열린 GopherCon 2015에서 Blake Caldwell라는 사람이 발표한 내용을 기반으로 몇가지 설명을 곁들여서 작성한 것이다. (https://sourcegraph.com/blog/live/gophercon2015/123664481750)
사실 어떤 사람들에게는 쉬운 내용일 수 있다. 당연한 얘기를 하는 것일수도 있고… 하지만 기본을 탄탄히 하자는 의미에서, 그리고 지난 7월 덴버에서 열린 GopherCon 2015에서도 발표되었던 내용이니 한번 읽어보면 좋을 것 같다.
