이 때문에 두 센터 간의 Round trip 응답시간에 대한 제한은 있습니다. 두 센터의 스토리지는 항상 동기화 되며(Sync 방식), 한 쪽에서만 쓰기 실패가 되는 경우는 성공한 쪽에서 상대방 스토리지의 쓰기가 성공하도록 retry하는 메카니즘입니다. 따라서 싱크는 항상 맞도록 설계되어 있습니다.
위에서 언급해 주시는 설계 방식으로 정합성 보장률이 얼마나 되나요? 100% 정합성이 보장되는 건가요? 제 기억에 이렇게 싱크 맞추는 솔루션들이 고가였던것으로 알고 있어서 문의드립니다.
네 정합성 100% 보장하며, 솔루션 비용은 무상입니다.
[질문] 애플리케이션 개발 시에 보안 코딩(Secure Coding) 시에 컨테이너 기반으로 인해 발생되는 특별한 이슈나 제안이 있을까요?
코드에 의해서 특별히 발생되는 이슈 보다는 컨테이너 자체의 보안 관련 사항을 확인하시는 것이 좋을 것 같습니다.
https://www.synopsys.com/blogs/software-security/nist-application-container-security-guide/
https://docs.docker.com/engine/security/security/
GCP는 잠깐 사용해봤는데 guide는 잘되어 있던데 Azure도 빠른 이해를 위한 guide가 제공되나요?
사용경험상 GCP는 군던더기 없는 엔지니어링 기술이 장점인거 같구요, Azure는 윈도우 솔류션에 가장 적합하면서 리눅스 친화적 노력들이 군데군데 보인다라는게 장점인거 같아요, 특히 Azure는 8조에 인수한 Github가 큰 무기가 될거 같구요.
네, MS에서 Azure에서 운영되는 솔루션에 대해 기본적인 가이드를 제공하고 있읍니다. https://docs.microsoft.com/ko-kr/azure 를 통해 참조할 수 있읍니다.
[질문] Azure도 on-premise 기반에 구축이 가능한가요? 방법은요?
AzureStack 어플라이언스 제품을 활용하시면 on-premise에도 Azure환경과 거의 동일한 Private Cloud환경을 구현할 수 있습니다.
사용자 경험의 극대화 구현을 위한 APM 연관 상관분석 기능도 제공되나요?
APM이라면 어플리케이션 모니터링 관련된 내용을 말씀하시는 건가요?
네.
컨테이너 단위의 CPU, Memory 등의 리소스 사용에 대한 모니터링은 가능하지만, 어플리케이션 내부에 대한 모니터링은 기존에 WAS에 APM을 추가하는 것과 같은 방식으로 작업이 필요합니다. 다만, 아직 컨테이너환경을 지원하지 않는 APM이 있으므로 사용하고자 하는 APM이 컨테이너를 지원하는지 확인이 필요합니다.
디멘죤의 치수를 직접 지정을 하면 디멘죤 치수에 천단위가 기재가 안되는데 하는 방법이 있나요?
치수를 수정하시는 경우TEXT로 인식되어 천단위 표시는 되지 않습니다.
어떤 상황인지 확인은 못하지만 일반적으로 천단위 기재는 문제없이 진행할 수 있습니다. 다만, 치수는 객체와 연관되어, 객체 변경에 따라 같이 변경되도록 작성됩니다. 지금처럼 수동 입력시 연관관계가 깨져 이후 작업, 또는 다른 작업자에게 혼란을 야기할 수 있습니다. 수동입력을 할 수 있도록 가이드 드리거나 권장하지 않습니다.
[질문] Active - Active 일 경우 데이터 정합성 보장에 대해서 좀 더 자세해 말씀해 주세요. 특히 DR 경우 저장소 거리가 존재할 텐데, 만약에 한 쪽에서만 데이터 쓰기 실패를 하게 되면 둘 간의 싱크는 어떤 방식으로 맞추게 되는 건가요?