Jins' Dev Inside

data에 대한 데이터를 말하는 것으로, 다른 데이터를 설명해준다.

 정보를 효율적으로 찾기 위해서 일정한 규칙에 따라 컨텐츠에 부여되는 데이터이다.

 데이터 자체를 좀더 적은 정보량으로 표현하기 위하여 만들어졌으며, 이는 인터넷에서 문서들을 찾기 위한 일종의 태그 역할을 수행하기도 한다.

 즉, 메타데이터를 기준으로 문서를 구분할 수 있는 일종의 Unique 한 Key 역할을 할 수 있으며 이로 인해 주로 분석이나 분류 목적으로 따로 쓰이기도 한다.

실무에서도 주로 서버를 구성할 때, 관리하는 데이터는 이 meta data가 되며, meta data를 이용한 참조 혹은 인덱스로 실제 데이터를 가리키는 데 사용한다.

메타 데이터의 쓰임새는 워낙 무궁무진하며 혹자는 메타 데이터에 대한 설계 능력이 data를 설계하는 중요한 역량이라고 말하기도 하더라.

* 실무에서도 많이 쓰이는 용어이기 때문에 간단하지만 알아둘 필요가 있다.

회사마다 사용하는 테스팅의 종류가 다를 수는 있으나, 여지껏 다니던 회사들에서 주로 사용하던 테스팅 방법 들을 정리해보았다.

회사마다 QA 팀이 갖추어져 있는 경우도 있고 스타트업의 경우 별도의 QA팀 없이 개발팀에 해당 책무가 주어지는 경우가 있다.

다음은 몇가지 테스팅의 종류들이다.

(1)   Sanity Testing : 새로운 버전이 주요 테스트를 수행하기 적합한지를 판단하기 위한 테스팅. 만약 사용 초기의 Crash 등으로 프로그램이 사용불가능하다면 시스템은 테스팅이 불가능하다. 즉, QA를 위한 테스트라 할 수 있다.

(2)    BlackBox Testing : 내부설계 및 구현은 고려하지 않고 요구사항과 기능성에만 기반한 테스팅을 수행한다.

(3)    WhiteBox Testing : 글래스박스 테스팅이라고도 하며, 내부로직에 대한 지식을 기반으로 코드구문, 분기, 조건 등에 대한 커버리지를 포함한다.

(4)    Unit Testing : 개발자에 의해 수행되며 소프트웨어 모듈 각각에 대한 세부적 테스팅

(5)    End to End Testing : 주로 네트워크, DB 연동, 시스템간 커넥션에 대한 테스팅이다.

(6)    Load Testing : 부하가 걸린 상황에서 시스템의 동작을 점검한다.

(7)    Stress Testing : 허용 범위를 초과하여 한계치를 측정하는 테스팅이다.

(8)    Alpha Testing : 개발 부서 내에서 만든 가상환경에서의 테스팅

(9)    Beta Testing : 상용화 릴리즈 이전 end user에 의해 완료되는 테스팅

(10)  Recovery Testing : 시스템의 회복을 테스팅한다.

(11) Smoke Testing : Sanity Test와 유사하게 테스트가 가능한지 여부를 판단한다. (연기가 나는지를 판단하는 작업) 여러 개의 스모크 테스트를 스위트라고 한다.

 * Sanity Test와 Smoke Test 의 차이는 기능 검사에 있다. Sanity Test가 새로 테스트 항목에 추가된 추가된 기능 / 수정된 버그 에 초점을 둔다면 Smoke Test 는 프로그램의 핵심적인 부분을 같이 검사한다. (즉, 새로운 기능추가가 기존의 핵심 기능에 영향을 안미치지는지 테스트 한다.)

또한, 같은 QA 이전의 테스팅이지만 주로 Smoke Test 는 개발팀 내에서 직접, Sanity Test 는 개발팀에서 기능 검사만 하고, QA팀으로 넘기는 경우가 많다.

(보다 자세한 비교는 다음 링크가 잘 설명해주고 있다.)

 - 참조 : https://www.guru99.com/smoke-sanity-testing.html

배치 작업을 할때, 이용할 수 있는 도구는 많지만 개인적으로 가장 손꼽는 프로그램은 Linux 에서 기본적으로 제공해주는 크론탭(Crontab) 이라고 생각한다. 사용하기도 쉽고 강력한 스케줄링 기능을 할 수 있다.

다음은 크론탭의 사용방법이다.

- crontab -e : 크론탭 편집기 실행. VI 가 기본으로 실행된다.

- crontab -i : 크론탭의 내용 조회

- 크론탭 작성 방법

*                *                    *                *                *

분(0-59)       시간(0-23)       일(1-31)       월(1-12)       요일(0-7)

- 매분 실행

* * * * * /home/script/test.sh

- 특정 시간 실행

# 매주 월요일 오전 5시에 test.sh 실행

0 5 * * 5 /home/script/test.sh

- 반복 실행

# 매일 매시간 0분, 20분, 40분에 test.sh 실행

0, 20, 40 * * * * /home/script/test.sh

- 범위 실행

# 매일 1시 10분 부터 30분까지 매분 test.sh 실행

10-30 1 * * * /home/script/test.sh

* 크론탭은 한줄에 한 명령어만 작성해야 하며 #을 통해 주석을 달 수 있다.

또한 실행하는 쉘에 Redirection (>) 을 연결함으로써 출력을 리다이렉트할 수 있으며 이를 통해 로깅이 가능하다.

TCP/IP 전송제어 프로토콜은 신뢰성에 초점을 맞추고 데이터가 신뢰성있게 올바른 순서로 유실되지 않게 빨리 전송할 수 있도록 설계된 프로토콜이다.

 Java에서 모든 클래스의 부모 클래스인 Object 클래스는 toString을 비롯해 equals 와 hashCode라는 메서드를 갖고 있다.

즉, 모든 클래스는 toString 과, equals, hashCode 를 갖고 있다고 볼 수 있으며 이는 자바 객체들의 특징이라고 할 수 있다.

여기에서 헷갈리는 부분이 equals와 hashCode 의 차이이며, 아래는 그 내용을 정리한 글이다.

 Equals는 두 객체의 내용이 같은지 동등성(equality)을 비교하며 hashCode는 두 객체가 같은 객체인지 동일성(identity)을 비교하는 역할을 한다.

 즉 hashCode를 사용하면 두 객체의 참조 비교를 하며 완전히 같은지를 판단한다.

 참고로 Java의 Map은 put 당시의 hashCode를 기록하므로 hashCode함수를 오버라이딩하여 구현할 시 중간에 값의 변경으로 hashCode가 변경되지 않도록 유의해야 한다.

 다음은 hashCode() 와 관련해서 정의된 규약이다.

-      equals()로 비교시 두개의 오브젝트가 같다면 hashCode() 값도 같아야 한다.

-      Equals()로 비교시 false라면 hashCode() 값은 같을수도 다를수도 있다. 성능을 위해서는 hashCode() 값이 다른 것이 낫다.

-      hashCode() 값이 같다고 해서 equals()가 true인 것은 아니다. 해싱 알고리즘 문제로 같은 해시값이 나올 수 있다.

: 다음은 equals() 와 관련된 규약이다.

-      Reflexive : Object는 그 자신과 항상 equals해야 한다.

-      Symmetric : a.equals(b) 일때 b.equals(a) 는 성립해야 한다.

-      Transitive : a.equals(b) 이고 b.equals(c) 라면 c.equals(a) 는 성립한다.

-      Consistent : equals의 호출은 객체가 변하지 않는 이상 항상 같은 결과를 반환해야 한다.

-      Null comparison : null과의 equals 비교는 NPE가 아닌 false를 반환해야 한다.

위 내용은 다음 블로그를 많이 참조 하였다. 

(http://anster.tistory.com/160, http://iilii.egloos.com/4000476)

 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이 허용되지않는 관계가 생겨날 수도 있기 때문에 알아둘법한 지식이다.

 Linux 서버 관리를 하다가 가장 자주 마주치는 것 중 하나가 서버의 포트 및 방화벽 문제라고 할 수 있는데 삽질하면서 알아낸 바를 적는다.

 : 리눅스에서 열린 포트를 확인 하는 방법

 - netstat -tnlp : 상태를 인 아웃 port 정보를 포함해서 볼 수 있다.

 : CentOS, Fedora 등의 리눅스에서 포트 방화벽을 확인 하는 방법

-    iptables –-list

-    iptables -L(리스팅) -v(자세히)

 : Ubuntu 에서 포트 방화벽을 확인하는 방법

-    sudo ufw status

 : Ubuntu 에서 포트 방화벽을 활성화 / 비활성화 하는 방법

-    sudo ufw enable

-    sudo ufw disable

 : CentOS, Fedora 등의 리눅스에서 포트를 추가하는 방법

-    iptables -I INPUT 1 -p tcp –-dport 80 -j ACCEPT  (80 번 Input 포트를 1번으로 추가)

-    iptables -I OUTPUT 2 -p tcp –-dport 8080 -j ACCEPT     (8080번 Output 포트를 2번으로 추가)

 : Ubuntu 에서 포트를 추가하는 방법

-    sudo ufw allow <port>/<optional: protocol> (sudo ufw allow 443/tcp)

 : CentOS, Fedora 등의 리눅스에서 포트 예외를 제거하는 방법

-    iptables -D INPUT 2   (INPUT 2번째 규칙 제거)

 : Ubuntu 에서 포트를 제거하는 방법

-    sudo ufw deny <port>/<optional: protocol>

 : Iptables 를 이용한 포트포워딩

-    iptables -t nat -A PREROUTING -p tcp -m tcp –dport 80 -j REDIRECT –to-ports 8080

-    iptables -t filter -A FORWARD -p tcp -m tcp –dport 80 -j ACCEPT

 * 이 글을 정리할 때를 돌아보자면 클라우드 VM에서 자체 방화벽을 잘못 건드려서 2차 참사를 유발한 케이스였다, 당시 사내 플랫폼은 유일한 게이트웨이에서 리눅스 서버에 접속할 수 있도록 허용되어 있었는데, 이 부분이 기존 사내 플랫폼 방화벽에 WhiteList로 등록되어있지 않은 상태에서 방화벽을 걸어버려서, 인스턴스 하나를 날린 참사가 일어났었다... ㅡㅡ 

방화벽 설정은 각별히 주의하자.

 DHCP란 Dynamic Host Configuration Protocol 의 약자로, 호스트의 동적 설정을 위한 프로토콜이다.

 장치들이 동적으로 적절한 IP주소들을 찾을 수 있도록 고안된 프로토콜로 2014년 기준 IPv4 네트워크의 표준이 되었다고 한다.

 TCP/IP 통신을 실행하기 위한 설정 정보의 할당을 관리하며 그를 위해 네트워크 관리자들이 IP 주소를 중앙에서 관리하고 할당할 수 있게 제공한다.

 OSI 상위 계층의 프로토콜들은 DHCP를 통해 결정지어진 IP 주소를 기반으로 인터넷을 이용하게 된다.

 인터넷에 접근 시 DHCP를 사용하지 않는 경우에는 컴퓨터마다 IP가 수작업으로 입력되어야 하며 다른 네트워크로 편입 시 IP 주소를 새로 받아야 한다. DHCP는 이를 자동으로 할당하게 끔 해준다.

(1)  DHCP Discover : 단말이 DHCP 서버를 찾기 위해 동일 Subnet 상에 브로드캐스트.

(2)  DHCP Offer : DHCP 서버가 단말로 단말에 할당할 IP, Gateway IP 등 네트워크 정보를 송신

(3)  DHCP Request : 단말이 DHCP 들 중 자신이 사용할 DHCP 서버를 선택하고 해당 서버에 자신이 사용할 네트워크 정보를 요청

(4)  DHCP ACK : 선택된 DHCP 서버가 단말로 네트워크 정보를 송신 -> 인터넷 가능

본 내용은 위키에도 잘 정리되어있으니, 좀 더 공부하고자 한다면 참고하면 좋다.

(https://ko.wikipedia.org/wiki/%EB%8F%99%EC%A0%81_%ED%98%B8%EC%8A%A4%ED%8A%B8_%EA%B5%AC%EC%84%B1_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C)