TIL: 2017.11.17.

Development / Css / TIL / SQLAlchemy / Redis / Aerospike / Flexbox

  1. Python SQLAlchemy 사용시, create_engine()으로 반환받은 engine 객체에 직접 .execute()하는 것은 Anti-pattern. 각각의 .execute() 마다 DB Pool에서 connection을 가져다 쓸 뿐만 아니라, 사용 후 Transaction을 마무리하기 위해 무조건 rollback 혹은 commit을 해야되기 때문에 굉장히 많은 리소스를 사용하게 됨. (아무것도 안하는 SELECT ~ 쿼리에 대해서도 Pool 반환 전에 전 트랜잭션이 깨끗함을 보장하기 위해 rollback을 수행해야함.) 반드시 engine.connect()해서 반환 받은 객체를 사용하자. 아니면 .begin()해서 트랜잭션을 유지하던지!123

  2. 마찬가지로 SQLAlchemy에서 ORM을 사용하는 경우, 모든 작업 전 SHOW CREATE TABLE ~ 문을 실행하는데, 이 역시 매우 큰 cost임. 따라서 성능이 중요한 작업에 대해서는 최대한 ORM 사용을 지양해야 할 것 같다.

  3. Redis 사용시 자꾸 ResponseError: OOM command not allowed when used memory > ‘maxmemory’.가 발생하길래 도무지 기존에 알고 있던 상식으로는 이해가 되지 않았는데(왜냐하면, Memcached나 Redis 같은 캐시 솔루션들은, 당연히 LRU든 뭐든 지정된 페이지 교체 알고리즘에 의해서 메모리가 꽉차면 오래된 데이터를 날리고 신규 데이터를 넣을 것이라고 생각했기 때문에) maxmemory-policy 옵션에 따라 그 처리가 달라질 수 있다는 사실을 알았다. 안정성을 위해 TTL이 있는 데이터만 날린다는 것이다!456 기존에 volatile-lru로 되어있던 옵션을 allkeys-lru로 변경하여 해결하였다. 자세한 내용은 각주 참조.

  4. Aerospike에서 secondary index 생성 중에 신규 클러스터를 올려 같이 연결하면, 생성 중이던 secondary index가 모두 삭제되는(!) 현상을 발견했다. 버그일까?

  5. Aerospike에는 TTL이 지난 문서를 expire 시키는 것과 더불어 eviction 이라는 것이 있었는데 이것이 무엇인가 궁금해하고 있던 찰나에, 저장된 object 들이 갑자기 마구마구 삭제되는 현상을 발견하였다. 알아보니 클러스터에 메모리가 HWM(High Water Mark) 상태에 돌입하게 되면, TTL이 있는 문서 중 수명이 제일 짧은 애들 부터 퇴거(evict) 시킨다는 것이다.7 '메모리가 터져서 장애가 발생하는 것 보다는 이게 낫다'라는 판단에 의해서라는데 충분히 수긍되었다. 이전까지는 모든 object에 TTL이 없었어서 HWM 상태가 계속 지속되었음에도 불구하고 eviction이 발생하지 않았던 것이다. (나는 여태 HWM도 그냥 경고 차원에서만 있는 줄 알았다.) Redis에서 당했던걸 여기서 또 당했다!(근데 Redis는 뭔가 당연히 휘발된다고 생각했는데 안되서 놀란 것이고, Aerospike는 당연히 영구 보관될 것이라고 생각했는데 휘발되서 놀란 것이다. 것 참.) 여튼 일단 새로운 클러스터를 만들어 메모리 부족 상태도 좀 해소시켜주고, HWM의 수위도 안전한 범위 내에서 좀 상승 시켜주었다.

  6. 회사에서는 최신 프론트엔드 기술을 집약하여 개발이 진행됨에도 불구하고, 나는 부끄러울 정도로 90년대 HTML + CSS 기술에 머물러있다. 맨날 백엔드만 개발하는 나에게 특히나 아직도 해결하지 못한 난제는 flexbox에 관한 것이었는데, K님이 알려주신 링크를 보고 진리를 깨달았다. 배워야 산다!

  7. 여하둥둥 오늘은 NewRelic의 승리!


Share on : Twitter, Facebook or Google+