Jins' Dev Inside

 Python2 와 3 간에는 생각보다 backward compatibility 를 지원하지 않는 경우가 많은데,

가령 차이점으로는 다음과 같은 것들이 있다.

-      Python3 부터는 모든 변수가 객체(Object)로 처리된다.

-      Python3 에서는 xrange를 지원하지 않는다. Python2 의 xrange는 정해진 숫자만큼 object를 생성하는 lazy process 방식이고 looping 동작에서 memory efficient 를 갖는다. 그러나 3부터는 모두 range를 사용하며 대체가 불가능하다.

-      Python3 에서 연산은 자동 타입할당이 제공된다.

-      Python3 에서 print 문은 함수로써 동작하므로 괄호가 필수이다.

-      Python3 에서 기존 Python2 의 long이 Int로 통일되었다.

그 외에도 유니코드 및 에러 핸들링 부분에서 차이가 있으며, 자세한 건 다음 링크의 설명이 도움이 될 수 있다.

https://www.geeksforgeeks.org/important-differences-between-python-2-x-and-python-3-x-with-examples/

마이크로 서비스 아키텍처 (Micro Service Architecture) 란, 최근에 각광받고 있는 웹 기반 분산 서비스 시스템 아키텍처를 말하며, 이러한 아키텍처를 갖는 서비스 자체를 마이크로 서비스 (Micro Service) 라 한다.

앞선 포스팅에서 언급한 모놀리식(Monolithic) 아키텍처가 하나의 어플리케이션 또는 서비스가 여러개의 모듈이 결합된 강건한 형태의 아키텍처를 갖는다면, 마이크로 서비스 아키텍처는 반대로 독립된 각각의 모듈을 조립하여 만드는 하나의 서비스를 위한 아키텍처라고 볼 수 있다.

(참조(모놀리식 아키텍처) : http://jins-dev.tistory.com/entry/%EC%A0%84%ED%86%B5%EC%9D%98-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%AA%A8%EB%8D%B8-%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9DMonolithic-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98?category=760149)

즉, Software 설계 시에 Loose Coupling 을 위하여 고려되는 "모듈화" 의 개념이 Web API 를 이용하여 서비스 레벨로 확장된 것으로 이해하면 편하다.

이는 오래된 개념이며, 최근에 클라우드 시스템 및 도커 등의 발달로 인해 보다 손쉬운 구현이 가능해지면서 대세로 자리잡고 있다.

마이크로 서비스 아키텍처는 작은 서비스들의 컬렉션으로 구성된다. 각각의 작은 서비스 단위들은 단일 비즈니스 기능을 구현할 수 있어야 한다.

 마이크로 서비스 아키텍처에서 서비스는 작고 독립적이며 느슨하게 결합되어 있다. 각 서비스는 작은 개발 팀이 관리할 수 있는 개별 코드 베이스이다. 서비스들을 독립적으로 배포할 수 있으며 팀이 전체 응용 프로그램을 다시 빌드한 후 재배치하지 않고도 기존 서비스를 업데이트 할 수 있다. 

서비스는 해당 데이터 또는 외부 상태를 유지해야하고 이는 별도의 데이터 레이어를 갖는 기존의 모델과 다른점이다. 각 서비스들은 API를 사용하여 통신하고, 구현 내용은 감춰진다. 각 서비스들은 동일한 기술 스택, 라이브러리 또는 프레임워크를 공유할 필요가 없다.

 마이크로 서비스 아키텍처는 노드 간의 서비스들을 관리할 수 있는 특징적인 구성요소를 지닌다. 또한 서비스 목록을 조회하거나 클라이언트로부터 들어오는 API의 진입점을 별도 인터페이스의 게이트웨이로 분리하는 특징을 지닌다. 이는 API 서버일수도, 어드민 형태의 웹페이지일 수도 있다.

 마이크로 서비스 아키텍처가 사용되는 경우는 빠른 릴리즈 개발 속도가 요구되거나 고확장성이 필요한 복합적인 프로그램, 많은 하위도메인을 가진 거대한 프로그램 또는 소규모 개발 팀으로 구성된 조직에 유용하다. 이는 다음과 같은 이점들로 인해 기인한다.

-      독립배포 : 전체 프로그램을 다시 배포하지 않고도 업데이트가 가능하다. 이에 따라 버그 수정 및 릴리즈 관리가 용이하고 위험부담이 덜하다.

-      독립개발 : 독립적인 개발팀들에 의해 개발될 수 있다.

-      집중화된 소규모팀 : 팀이 각 서비스에만 집중할 수 있다.

-      결함격리 : 한 서비스가 다운되더라도 전체 서비스에 영향을 미치지 않는다.

-      혼합기술스택 : 각 서비스에 적합한 기술을 선택하여 조합할 수 있다.

-      세분화된 확장성 : 서비스를 독립적으로 확장할 수 있다. 이에 따라 리소스의 유연한 운용이 가능하다.

 위와 같은 장점을 갖고 있음에도 아직 마이크로 서비스 아키텍처는 모놀리식 아키텍처에 비해 복잡하며 독립된 구조로 인해 통합적인 유지 관리가 어려워질 수 있다. 가령 에러가 난 서비스의 권한이 다른 팀에 있다면, 그 부분의 보수를 위해서 우리가 직접 수정하는 것이 아닌 커뮤니케이션이 필요하게 된다.

또한 서비스 구성에 있어 네트워크 정체 및 통신에 신경을 써줘야 하며 데이터 일관성 및 버전 관리가 중요해진다. 그리고 프로젝트 진행에 있어 팀원들이 이루는 문화가 중요해진다. 이러한 기조에서 알맞은 개발 문화가 개발자가 운영까지 담당하는 DevOps(데브옵스) 문화라 할 수 있다.

 RDB에서 관계를 맺는데 있어서 식별관계(Identifying Relationship)와 비식별관계(Non-Identifying Reltationship)가 존재한다.

정확히는 RDBMS에서 나누는 관계가 아닌 ER Diagram 상에서 논리상 나누는 개념이며... 굉장히 헷갈린다.

 Identifying Relationship 은 부모 테이블의 기본키 또는 복합키가 자식 테이블의 기본키 또는 복합키의 구성원으로 전이되며, 관계는 서로 종속되게 된다.

 예를 들어서 B라는 테이블의 FK가 child 로 A 테이블의 PK를 참조한다면 Identifying Relationship에서 B테이블은 A 테이블에 종속이 되어서 A값이 없으면 B값은 홀로 의미를 갖지 못하는 관계가 된다. 아래의 테이블을 보자

<학생 정보를 기록하는 TableA 와 학생 성적을 관리하는 TableB>

위의 테이블에서 tableA는 학생들의 정보를 기록하는 테이블이고, tableB는 학생들의 과목별 성적을 기록하는 테이블이 된다.

TableA와 TableB는 똑같이 studentId를 PK로 갖고 있으며, TableB 에서 studentId 가 없다면 TableB는 독립적으로 존재할 수 없는 정보가 된다. 이때, 우리는 학생의 성적은 학생에게 종속되어 있다는 사실을 기반으로 생각하기 때문이다. 이러한 Strong coupling 에 대한 관계가 Identifying Relationship 이다. 

 반면에 Non-Identifying Relationship 은 자식 테이블의 일반 속성(Attribute) 그룹의 구성원으로 전이되는 비식별관계로, 부모는 자식의 부분적인 정보만을 표현함을 의미한다. 위의 예에서 Non-Identifying Relationship 의 경우 B테이블의 값은 A와 FK의 관계를 맺고 있긴 하지만 독립적으로 존재할 수 있어야 한다.(즉, FK가 B테이블의 PK가 되어선 안된다.) 이제 위의 테이블을 Non-identifying 한 관계로 바꾸어보자.

 이해를 돕기 위해 좀 더 편한 예시를 들어보자, 가령 책과 독자와 같은 정보의 경우는 Non-Identifying 관계이며, 독자가 없어도 책은 존재할 수가 있다. 하지만 저자와 책의 경우는 저자가 없는 책이 있을 수 없으므로 Identifying 관계라고 할 수 있다.

 * 관련되어 헷갈린 개념으로 Optional 과 Mandatory라는 개념이 있다. 이는 Non-identifying Relationship에 적용되는 내용으로, 참조하는 Foreign Key가 Null이 될 수 있는가에 대한 내용이다. 가령 위의 예시에서 어떤 학생이 어떤 과목의 시험성적도 갖고 있지 않다면 subjectId는 NULL이 될 수 있다. 학생의 성적 기록이 없기 때문이다. 이 때를 Optional 하다고 하며, NULL이 허용이 안되는 상황, 모든 학생이 입학시험은 적어도 봐야한다고 하면 subjectId는 NULL이 될 수 없다. 이 때를 Mandatory 하다고 한다.

서두에 언급했듯이 이는 ERD 를 그릴때 고려되는 개념이기 때문에 어떻게보면 추상적인 개념이라고 할 수 있다. 실무에서 ERD를 그릴 때 모른다면 실수로 잘못된 커플링을 갖거나 NULL이 허용되는 상황에서 NULL이 허용되지않는 관계가 생겨날 수도 있기 때문에 알아둘법한 지식이다.