서론
수십대의 인스턴스가 동작하는 AWS EC2 운영환경에서 aws ec2 describe-instances --region ap-northeast-2 와 같은 명령어로 유의미한 값을 얻어내는것은 쉽지않다.
당장 EC2 인스턴스 1개만 있을 때 describe-instances 명령을 사용해도 수십줄의 output이 나온다.
→ 그래서 EC2 Instance 정보 중에서 자신이 원하는 값들만 편한 형태로 보기 위해서 --query와 --filter 옵션을 사용한다.
이전 포스팅에서 AWS CLI의 query와 filter에 대한 간단한 예시와 함께 다중조건 입력에 대해 정리한적이 있다. 그 포스팅에서 마지막에 query와 filter의 차이점에 대해 간단하게 고민하고 넘어간 후에 다시 이 차이에 대해서 공부하게 되었다.
Query 와 Filter
이전 포스팅에서 내린 결론은 filter는 전처리, query는 후처리의 느낌이 강하다고 적었다.
그 이유는 --query 가 aws cli에서 제공하는 전역 옵션과 출력형식 때문이였는데,
•
--filter는 주어진 filter 값을 명령어를 출력하는 과정에서 계산하고 필터링된 값만 출력하는 느낌이고
--query는 Linux에서 ifconfig | grep inet 과 같은 느낌이였다. 그러니까 앞에 명령을 실행한 다음 우리한테 보여줄 때 inet이라는 값의 라인만 보여주는 것 처럼말이다.
•
filter와 query의 출력 결과가 다르다. query의 JSON 형태의 결과값을 보면 aws describe-instances 명령어의 형태와 JSON 구조가 달랐다.
놀랍게도 실제로 AWS 공식 Document의 설명이 내생각과 비슷했다.
Filter
•
서버 측 필터링은 API에서 지원되며, 일반적으로 --filter 매개 변수를 사용하여 구현합니다. 이 서비스는 대량 데이터 세트에 대한 HTTP 응답 시간을 단축할 수 있는 일치하는 결과만 반환합니다.
◦
즉 --filter를 사용한 명령어의 결과는 AWS에서 응답을 할 때 Filtering 된 결과를 반환한다. 서버에서 처리후에 응답하는 것이기 때문에 HTTP 응답 시간 단축에 대한 이점도 자연스럽게 이해가 됐다.
◦
aws ec2 명령어의 --filter를 기준으로 설명하기 때문에 계속 filter를 말하지만 서비스에 따라서 filters, filter-log-events 등 조금씩 다른 모습을 보인다.
◦
API 기반의 필터링이라는 말은 곧 AWS에서 미리 정의해놓은 API만 호출이 가능하다는 말이므로 기능에 제한이 있을 '수' 있다는 말도 이해가 된다.
Query
•
클라이언트 측 필터링은 AWS CLI 매개 변수를 사용하여 --query 클라이언트에서 지원됩니다. 이 매개 변수에는 서버 측 필터링에 없을 수 있는 기능이 있습니다.
◦
--query를 사용한 명령어의 결과는 AWS에서 전체 결과를 응답받은 후 Client 측에서 --query 결과를 출력한다. Query가 서버측 Filtering에 없는 기능이 있을 수 있다는 것 또한 당연한 결과인 것 같다.
◦
--query는 JMESPath를 기반으로 제공되는 전역옵션이기 때문에 사용법에 따라서 무궁무진한 쿼리가 가능하다.
◦
심지어 전체 결과를 응답받은 상태에서 쿼리하기 때문에, 연속된 2개의 옵션도 쿼리가 가능할 것이다.(or, and없이, 쓰는 경우는 없을 것 같지만 자유도의 관점에서)
느낀점
•
내 경험상 결국 요구조건이 많아지거나 복잡한 쿼리를 실행할 때에는 결국 query와 filter를 모두 사용했다...
•
--filter 옵션이 Server Side Filtering을 통해 응답시간을 줄여주기 때문에, query와 filter 둘 다 구현할 수 있는 필터조건에는 --filter 옵션이 더 효율적이다.