하루 데이터 적재량의 규모가 적절한지 궁금합니다

Ask Question
, ,
1

안녕하세요,

현재 OpenTelemetry, Loki, Tempo 를 통해 수집한 log와 trace 를 Azure Storage Account Blob storage 에 저장하고 있습니다. (loki와 tempo 저장소가 storage account 입니다.) 이 서비스들을 이용하여 적재하고 있는 데이터가 24시간에 대략 200GB 정도인데, 이게 적절한 양인지 아니면 한 번 최적화를 거쳐야 할 양인지 가늠이 어려워 질문드립니다. ㅠ

서비스 규모는 아직은 크지 않으나, iot 데이터를 다루고 있어서 사용자의 트래픽보다 기기 트래픽이 조금 있는 편이고, msa구조로 기기 트래픽을 처리하는 특정 마이크로서비스들이 로그와 트레이스를 많이 찍어내는 편입니다. 연결된 기기대수는 대략 3만대정도입니다.

제미나이와 챗지피티에 질문해보긴 했으나 필드에 계신 실무자분들께 듣는게 더 정확할 것 같아 여쭤봅니다..

Please delete the above guidance before posting your question. (위 안내 문구는 글 작성 전에 삭제하신 후 질문을 남겨주세요. )

| This is a space where knowledge is not merely consumed, but respected, sovereign, and connected—shared together with cloud industry professionals (Bros).|
| 지식이 소비되지 않고 존중·주권보장·연결되는 공간으로 클라우드 현업 전문가(Bro)와 함께 공유하고 있습니다. |

2 Likes
2

안녕하세요, 저도 IoT 데이터를 다루고 있는 입장이라 반갑네요 ㅎㅎ

질문주신 내용을 보면 단순히 ‘적절한가?’ 에 대해서 해소가 필요하신건가요?
만약 현재 문제를 겪지 않고 있고, 단순 궁금증이라고 하시면 적절하다의 기준은 없습니다.

때문에 지금 설명해주신 내용만으로는 최적화가 필요한지 알 수가 없고, 최적화가 가능한지 파악하시는것이 좋지 않을까 싶습니다.
최적화가 가능한지 알아두기만 해도 이후 조치가 필요할때 큰 도움이 됩니다.

최적화가 필요한 경우

당장 생각나는 케이스는 아래와 같습니다.
만약 아래의 증상이 있다면 최적화 방안을 빠르게 마련하셔야 합니다.

  • 운영중인 머신의 리소스가 자주 부족하여 OOM 등의 문제가 생긴다
  • 로그 조회와 같은 액션을 취할 때 마다 성능이 느려서 매우 오래걸리거나, 응답이 오지 않는 경우가 있다

외에도 더 많은 최적화 시그널이 있을건데 저의 최적화 트리거는 ‘운영/이용에 지장을 주는가’ 입니다.

최적화 방안

최적화 방안을 모색하려면 다음과 같은 선택지가 있습니다.

  1. 데이터의 양을 두고 적절한가를 따지기 보다 불필요한 데이터가 저장되고 있지는 않은지 확인해야 합니다.
  2. 모든 데이터가 영원히 필요하지 않을수 있습니다. 데이터를 분류할 수 있어야 하고, 데이터를 얼마나 보관해야 하는지 life cycle을 결정하고 정리하는것을 자동화 해야 합니다. (기준만 명확하다면 수동으로 하시는것도 문제는 없습니다)
    1. 삭제 뿐만 아니라 자주 조회하지 않는 경우 Cold storage 로 이동하는 등의 조치로 비용 최적화도 고려해야 합니다.
    2. 외에도 압축하여 저장하던가, 조회 성능이 조금 느리지만 Serialize 하여 저장하는 등의 옵션을 제공하는 도구도 있습니다.
  3. 변화를 꾸준히 추적하고 대응해야 합니다.
    1. 갑자기 저장되는 로그가 많아진다면 트랜잭션 당 로그 양이 늘어난건지, 트랜잭션 자체가 늘어난건지 확인하고, 필요하면 로그 저장 기준을 더 구체화 하던가 개발팀에 요청하여 로깅 방식을 개선하는 등의 조치를 취할수 있겠습니다
  4. 불필요한 설정이나 부가 기능 활성화 등으로 인해 낭비되는 리소스가 있는지 검토해야 합니다.
  5. 마지막으로, 너무 최적화가 잘 되어있다면 과도하게 리소스가 할당되지는 않는지 CPU/Memory P50, P95, P99 등의 지표를 확인하고 적정 값으로 설정해주시면 되겠습니다.
2 Likes
3

용량보다는 가용 가능한 비용 내에서 효율적으로 저장하고 쿼리하는게 관건일 것 같습니다.

제가 생각하는 실행할 법한 액티비티는,

  • 로그를 잘 정제해서 적재
    • 레이블을 잘 정립하고 카디널리티를 낮게 유지하면, 그만큼 인덱스를 잘 타고 읽어들이는 chunk도 줄어들겠어요.
    • 로그 본문 자체를 줄이는 건 참 쉽지 않아서.. 비용 압박이 크다면 info 이상만 Loki로 전송하고, debug 이하는 로컬이나 서버에서 확인하라고 개발팀에 요청해볼 거 같습니다.
  • Loki/Tempo 테넌트별로 리텐션 조정
    • 짧은 기간만 적재해도 괜찮다는 팀도 있으니, 장애 대응을 위해 필요한 적재 기간과 적재 비용을 생각하여 조정하는 것도 방법이네요.
    • 위와 연계되어 debug 이하는 짧은 리텐션을 가지는 테넌트에 적재되도록 파이프라인을 추가할 수도 있겠어요.
  • Compactor 주기 조정
    • Compaction 할 때도 비용이 들기 때문에, blob으로 넘어간 데이터를 자주 검색하지 않는다면 인터벌을 늘리는 것도 좋을 거 같습니다.
  • Local/Blob 스토리지 간의 기간 조정
    • Local 스토리지는 용량당 비용이 비싸지만 쿼리시 비용이 들지 않고, Blob은 싸지만 쿼리 및 Compaction에도 비용이 들기 때문에
    • 자주 검색하는 기간은 Local에만 유지하도록 하는 것도 좋겠네요.
2 Likes