페이스북에 리뷰왕 김리뷰라는 페이지가 있다. 갖가지 리뷰들이 올라오고 요새 올라오는 카드뉴스식의 리뷰를 선도한(…?) 페이지이다. 그 김리뷰가 리뷰리퍼블릭이라는 서비스를 만들었다. 사용자들이 리뷰를 작성해서 올리고 양질의 리뷰를 올릴수록 그 보상이 작성자에게 돌아가게끔 하겠다는 취지로 만들었다고 한다. 어쨋든 겉으로 보이는 형태는 조그만한 커뮤니티 앱이다. 어떻게 보면 sns같기도 하고. 어쨋든 그런 조그마한 커뮤니티 앱이 월 100만원 가량의 유지비가 나온다는 소식을 들었다. 서비스 유지비용이 월 100만원씩 나온다면 도저히 수지타산이 안나온다. 곧 망할 것 같았다.
새로운 테마를 적용했다.
원래의 계획은 minima 테마를 커스터마이징 하는 것이었지만,
그냥 테마를 적용하기로 했다.
역시 세상은 넓고 이미 만들어 놓은 좋은 것도 많다. 공부하는 차원에서 만들어보려고 했는데, 굳이 jekyll을 깊게 파면서까지 이걸 커스터마이징할 이유가 없었다. 그래도 꾸역꾸역 기능하나정도 추가하는건 어렵지 않을것 같아서, 다른 jekyll 활용 예를 참고하려고 했고 참고하려고 하니 마음에 드는 테마 하나를 발견했다.
이번에 적용한 테마는 Swiss
이 테마를 적용한 이유는 간단하다.
한 마디로 minima 테마에서 카테고리 별로 정리해주는 기능만 딱 하나 추가되고, 디자인이 예쁘게 정리된 내가 찾던 바로 그 테마인 것이다. 그리고 무엇보다도 다른 기능이 없는 게 중요했다. 다른 다양한 기능이 있다고 해도 내가 쓸 생각이 없기 때문에 기능은 최소의 기능만 있는게 좋다. 그래야 관리도 되고 나중에 커스터마이징 할 때도 코드를 보기가 편하다. 블로그 테마가 계속 마음에 걸렸는데 이걸로 일단 한 동안은 유지할 수 있을 것 같다.
대박사건. EC2 인스턴스 타입 중 작은타입을 지원하고, 테스트용, 혹은 작은규모의 로직을 돌리기에 적합하던 t타입의 인스턴스 중 3세대가 나왔다. 이전 세대인 t2 타입은 2014년에 처음 나왔고 2016년에 다양한 사이즈들이 추가됐다.
그러니깐, 4년만에 t타입의 새로운 세대가 나온 것.
당연히 t2 타입보다 성능은 올라가고, 가격은 떨어졌다. 버지니아 기준으로 가격은 10%정도 저렴하다.
아쉽게도 서울리전은 아직 지원이 안됨.
마찬가지로 t2에서 t3로 업그레이드 되면서 기본 네트워크 성능이 향상될 것으로 보인다.
(low to moderate -> up to 5 Gigabit)
정확한 사양은 더 테스트해봐야 알겠지만, 어쨌든 좋은소식임에는 분명하다.
참고: https://aws.amazon.com/ko/blogs/aws/new-t3-instances-burstable-cost-effective-performance/
AWS 상에서 Windows 서버를 복제하는 일은 Linux 서버를 복제하는 것보다 까다롭다. Linux 서버의 경우 ami만 생성하면 되지만, Windows 서버의 경우 ami 생성 후 다시 그 ami를 통해 인스턴스를 실행하면 여러가지 에러를 맞닥트리게 된다. 특히 AD Domain에 접속되어 있는 윈도우즈 서버를 그대로 ami를 떠서 복제한 경우 제대로 인스턴스가 실행되지 않는다. AD에 조인되어 있는 경우 컴퓨터의 sid 등을 통해 도메인의 멤버인지 확인하는데 ami로 복제하게 되면 이런 값들이 중복이 되서 충돌이 생기기 때문이다. 이런 경우 Sysprep 이라는 작업을 통해 시스템에 관한 정보를 초기화 한 후 ami를 생성해야한다.
대략적인 순서는 다음과 같다.
여기서 주의해야할 것은 sysprep 과정에서 시스템이 초기화된다는 것이다. sysprep은 시스템에 관련된 정보들을 초기화한다. 예를들어 sid, 도메인 정보 등이 초기화된다.
따라서 무작정 sysprep을 돌렸다간 해당 인스턴스를 복구 불가능한 상태로 만들수도 있다.
Active Directory 글을 보고 AWS 상에서 AD를 구성하는 것을 테스트해보고 있다. 하지만 이 글은 AWS의 인프라를 기준으로 작성되어 있지 한다. 여기저기 찾아봤으나 aws 상에서 AD를 구성하는 예제가 많지 않다. 사실 쉽게 AWS에서 quickstart로 나와있어서 굳이 구성 예제가 필요하지 않았던 것 같다. 그래도 사정상 테스트를 해야했기에… 일단은 부딪혀보기로 했다.
첫번재 AD를 만드는 데에는 아무 문제가 없었으나 두번째 AD를 만드는 과정에서 문제가 생겼다. example.com 으로 도메인을 만들었는데 두번째 윈도우 서버에서 그 도메인을 찾지를 못한다. nslookup으로 질의해보니 dns가 응답하지 않는다. 뭐가 문제인지 모르겠다. tcp 포트도 다 열려있는데… 그래서 그냥 모든 트래픽을 허용해버렸다. 된다.
모든 트래픽을 열어주는건 찜찜해서 dns가 어떤 포트를 쓰는지 궁금해졌다. 뒤져보니 나랑 비슷한 질문을 한 글을 발견했다. (질문: NSLookup, how to set to TCP from UDP?)
결론: 그냥 udp 53 포트를 열어주면 되는 문제였다… 질문을 열어보면 dns는 주로 udp 53 포트를 사용하고 512 byte가 넘을때만 tcp를 사용한다고 친절하고 내공있는 답변이 적혀있다. 세상은 넓고 고수는 많다. 어쨌든 AWS 상에서 수동으로 AD를 구성하고, 이전하는 것 까지 테스트를 해보고 긴 포스트를 올려볼 예정이다. 물론, 예정일 뿐이다.
위키피디아에 DNS 항목에도 다음과 같이 적혀있다.
DNS primarily uses the User Datagram Protocol (UDP) on port number 53 to serve requests.[3] DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. When the length of the answer exceeds 512 bytes and both client and server support EDNS, larger UDP packets are used. Otherwise, the query is sent again using the Transmission Control Protocol (TCP). TCP is also used for tasks such as zone transfers. Some resolver implementations use TCP for all queries.
(지금보니 그 고수의 댓글은 위키피디아에서 그냥 퍼온 것…) 그런데, TCP 포트는 몇번 포트로 통신하는거지? 그걸 알아야 여는 포트를 최소화 할수 있는데…
여러 호스트를 이용하는 도커가 swarm을 이룰경우 서로 통신을 하려면 네트웍이 필요하다. 이때 각각 다른 호스트에서 생성된 컨테이너 사이에 네트워크를 생성해주는 것이 바로 overlay 네트워크 이다.
각각의 호스트에서 쓰고있는 네트워크와 상관없이 컨테이너 끼리의 사설망을 따로 만들어줌.
예를들어 각각의 호스트 A가 10.0.0.3 B가 10.0.0.5 라는 사설 ip를 사용하고 있을때 overlay network로 전혀 다른 사설대역 192.168.0.0/24를 만들 수 있다. Docker Swarm 을 구성해놓은 상태에서 새로운 서비스를 생성할 때, 네트워크를 미리 만들어 둔 overlay 네트워크를 지정하면 overlay 네트워크를 사용하는 컨테이너가 각각 올라가고 해당 서브넷 내의 ip를 할당받는다.
앞의 포스트에 이어 overlay network를 테스트해보다가 bandwidth가 궁금해졌다. 아무래도 네트워크 레이어를 하나 더 만드는 것이니 네트워크 성능이 노드들 끼리의 통신보다는 안 좋을 것이라 예상됐다. 찾아보니 예전 docker에서는 많게는 50% 정도까지 성능저하가 있었던 것 같다.
테스트 환경: AWS EC2 t2.medium <-> t2.small
테스트 방법: iperf3 을 사용했다.
set search_path to abc_schema
: 스키마 설정.
describe table_a; / \d+ table_a
: describe 하면 해당 테이블에 관련된 인덱스 까지 다 나와서 좋다. jdbc를 통한 클라이언트에서는 describe가 작동하지만 psql에서는 뒤의 명령어를 써야한다.
drop index indexname;
: 인덱스를 날려버린다.
alter table postgre_c drop constraint postgre_c_pkey;
: Primary key는 drop index 명령어로 안날아가서 이렇게 날려야 한다.
ALTER TABLE distributors ADD PRIMARY KEY (dist_id);
: primary key 추가할땐 이렇게.
create index idx1 on table1 (column1)
: 인덱스 추가는 이렇게
truncate table_a;
: 테이블을 날려버릴땐 이렇게. 자동으로 vacuum까지 된다.
이 포스트는 계속 업데이트 될 예정입니다.
ps -ef | grep python
: 실행중인 프로세스 중 python을 포함한 프로세스를 보여준다
ls -lh
: ls 명령어에 h 옵션을 붙이면 용량을 친절하게 표기해준다(mb, gb 등의 단위로 )
top
: 실행중인 프로세스 중에 리소스를 많이 사용하는 프로세스들을 보여준다.
sudo su
: 슈퍼유저로 전환
df -h
: 디스크별로 사용량을 보여준다. 앞서 말한 것처럼 h 옵션을 붙여주면 사람이 알아보기 편하게 바꿔준다.
cat [파일이름]
: 간단하지만 정말 많이 씀
tail -10 [파일이름] / tail -10f [파일이름]
: 뒤에서 부터 읽을때 많이 씀
rm -rf
: 앞뒤 생각없이 싹다 지울 때 -rf 옵션을 붙인다.
nohup
: 세션이 끊겨도 계속 지속되야하는 작업이 필요할때 쓴다.
AWS RDS에는 가용성과 확장성을 위해 multi-az 라는 기능과 read replica라는 기능을 지원한다. 비슷하지만 다른 특징들을 갖고 있어 간단하게 정리해둔다.
Update your browser to view this website correctly. Update my browser now
