다른 리전에 읽기복제본을 생성해야 될 때가 있다. 대충 추려보면 다음과 같은 경우.
- 다른 리전에 데이터를 읽기만 하는 워크로드가 있는 경우
- 다른 리전에 DR 용으로 데이터를 보관하는 경우
그럴때 RDS의 읽기복제본 생성 기능은 매우 간편하고 효과적이다. 파라미터 그룹을 만진다든지 하는 설정을 해줄 필요 없이 대상 리전에 서브넷 그룹만 잘 설정 되어 있으면 콘솔에서 클릭 몇번으로 복제본을 생성할 수 있다.
AWS RDS mysql - 다른 리전에 읽기복제본 생성: 버전이슈
[EC2 - T3] T3 인스턴스 출시!!!!!!!
대박사건. EC2 인스턴스 타입 중 작은타입을 지원하고, 테스트용, 혹은 작은규모의 로직을 돌리기에 적합하던 t타입의 인스턴스 중 3세대가 나왔다. 이전 세대인 t2 타입은 2014년에 처음 나왔고 2016년에 다양한 사이즈들이 추가됐다.
그러니깐, 4년만에 t타입의 새로운 세대가 나온 것.
당연히 t2 타입보다 성능은 올라가고, 가격은 떨어졌다. 버지니아 기준으로 가격은 10%정도 저렴하다.
아쉽게도 서울리전은 아직 지원이 안됨.
**사실 cpu 성능보다 더 기대가 되는것은 네트워크 성능.** m4에서 m5로 업그레이드가 됐을 때 cpu 성능도 증가했지만, 기본 네트워크성능이 많이 향상되었다.(관련글: [EC2 인스턴스의 타입별 대역폭을 살펴보자](https://blog.wisen.co.kr/?p=7751))
마찬가지로 t2에서 t3로 업그레이드 되면서 기본 네트워크 성능이 향상될 것으로 보인다.
(low to moderate -> up to 5 Gigabit)
이전 t2 인스턴스의 한계라면 cpu 성능이나 불안정성도 한 몫했지만 단순 웹서버로 사용하기에 아쉬웠던 점은 아무래도 네트워크 성능. 작은규모의 웹사이트의 경우 m5.large 정도의 스펙이 불필요하지만 네트워크 성능 때문에 어쩔 수 없이 m5를 선택하기도 했다. 만약 t3에서 네트워크 성능이 일정 기준치 이상으로 향상되었다면 t3 타입은 꽤 매력적인 인스턴스 타입이 될 것 같다.
정확한 사양은 더 테스트해봐야 알겠지만, 어쨌든 좋은소식임에는 분명하다.
참고: https://aws.amazon.com/ko/blogs/aws/new-t3-instances-burstable-cost-effective-performance/
[EC2 - Windows Server] AD가 join되어 있을 때 인스턴스 복제하기
AWS 상에서 Windows 서버를 복제하는 일은 Linux 서버를 복제하는 것보다 까다롭다. Linux 서버의 경우 ami만 생성하면 되지만, Windows 서버의 경우 ami 생성 후 다시 그 ami를 통해 인스턴스를 실행하면 여러가지 에러를 맞닥트리게 된다. 특히 AD Domain에 접속되어 있는 윈도우즈 서버를 그대로 ami를 떠서 복제한 경우 제대로 인스턴스가 실행되지 않는다. AD에 조인되어 있는 경우 컴퓨터의 sid 등을 통해 도메인의 멤버인지 확인하는데 ami로 복제하게 되면 이런 값들이 중복이 되서 충돌이 생기기 때문이다. 이런 경우 Sysprep 이라는 작업을 통해 시스템에 관한 정보를 초기화 한 후 ami를 생성해야한다.
대략적인 순서는 다음과 같다.
- 네트워크 설정 초기화 (ip, dns 모두 자동)
- sysprep
- ami 생성
- ami 복제 (선택사항)
- 해당 ami로 인스턴스 실행
- AD join
여기서 주의해야할 것은 sysprep 과정에서 시스템이 초기화된다는 것이다. sysprep은 시스템에 관련된 정보들을 초기화한다. 예를들어 sid, 도메인 정보 등이 초기화된다.
따라서 무작정 sysprep을 돌렸다간 해당 인스턴스를 복구 불가능한 상태로 만들수도 있다.
[ActiveDirectory] DC 구성시 허용해야 하는 포트
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 포트는 몇번 포트로 통신하는거지? 그걸 알아야 여는 포트를 최소화 할수 있는데…
RDS(MySQL, MariaDB) - Multi-AZ / Read Replica (읽기전용 복제본) 관련 정리
AWS RDS에는 가용성과 확장성을 위해 multi-az 라는 기능과 read replica라는 기능을 지원한다. 비슷하지만 다른 특징들을 갖고 있어 간단하게 정리해둔다.
