🦆

AWS CloudShell に DuckDB を入れて、ALB のログを見てみた

2024/12/02に公開

概要

最近、DuckDB に関する情報を目にすることが多いので、自分も遊んでみたって感じです。がーがー🦆
とくに、どこでも使えるんで、AWS CloudShell でも使ってみた話です。くわくわ🦆

DuckDB とは?

もうすでに知っている人が多いかもですし、すでに色んな方が紹介していますが、自分なりにおすすめポイント 2 つを紹介します。[1]

おすすめポイント1:ポータビリティー

Windows、Mac、Linux 問わず、どこでも使えます。
加えて、主要なプログラミング言語に対して、API が用意されていることも嬉しいポイントですね。

自分は、Java でさっくりとローカルで開発するときに、実装に集中したくて、とりあえず永続化まわりやサンプルデータとかは適当でいいんよなーってときは DuckDB をとりあえずの代用先として使います。
Java であれば API が提供されているので、リポジトリークラスの実装をその API を使って、一時的な実装を作っておき、あとで取り替えたりもできます。

おすすめポイント2:各種フォーマットへのカバー

公式ドキュメントを見てのとおり、
CSV だけでなく、JSON、Parquet など様々なフォーマットでインポートすることができます。

またデータのインポートだけでなく、CLI での表示出力のフォーマットも様々な形式をサポートしています。

参考:CLI のアウトプットフォーマット設定について

本題:今回なにしたん?

ここからが本題です!
ポータビリティーのところで書いた通り、様々なプラットフォームで扱えるということで、
日頃使っている AWS CloudShell でも DuckDB が使えるのか試してみました。

実践:CloudShell で DuckDB を動かすには?

AWS 管理コンソールにログインしーの。

AWS CloudShell を開いてーの。

以下のコマンドを入力しーの。[2]

curl -LO https://github.com/duckdb/duckdb/releases/download/v1.1.3/duckdb_cli-linux-amd64.zip
unzip duckdb_cli-linux-amd64.zip 
chmod +x duckdb // ここの権限の変更は必要に応じてですが、基本は不要なはず。
./duckdb

するとーーー、

CloudShell で DuckDB の導入上のコマンド実施した結果

これだけです。本当に簡単ですね。
ダウンロードファイルのサイズも小さいので時間はほとんどかからず、すぐに DuckDB を CloudShell 上で実行できます。

試しに、簡単な CSV ファイルを用意して、インポートさせて SQL を実行させたのが以下です。

フォーマットが決まっている CSV ファイルであれば簡単に読み込ませられます。

応用:実際に ALB(Application Load Balancer) のログを DuckDB で触ってみる

ここからは、自分の使い方の一つである ALB のログを CloudShell 上の DuckDB で操作することについて紹介します![3]

まずはじめに:ALB ログの取得

まず、ALB のログを取ってくる必要があります。
CloudShell では、AWS CLI がすでに導入されているので、AWS CLI で ALB のログが入っている S3 から取得します。

AWS CLI で S3 から取得するコマンドのフォーマットは以下です。

aws s3 cp s3://<バケット名>/<ファイルパス> <ローカル保存先>

つづいて:DuckDB でテーブル化する

ここについては、先人の知恵がすでにあります!
参考先としては以下です!こちらも目を通していただけるとわかりやすいですね。

すでに、ALB のログを手元にコピーしているので、
以下のコマンドで、テーブルを作って、データをインポートします。

CREATE TABLE alb_log AS
SELECT *
FROM read_csv(
    '[ログファイルパス]',
    columns={
        'type': 'VARCHAR',
        'timestamp': 'TIMESTAMP',
        'elb': 'VARCHAR',
        'client_ip_port': 'VARCHAR',
        'target_ip_port': 'VARCHAR',
        'request_processing_time': 'DOUBLE',
        'target_processing_time': 'DOUBLE',
        'response_processing_time': 'DOUBLE',
        'elb_status_code': 'INTEGER',
        'target_status_code': 'VARCHAR',
        'received_bytes': 'BIGINT',
        'sent_bytes': 'BIGINT',
        'request': 'VARCHAR',
        'user_agent': 'VARCHAR',
        'ssl_cipher': 'VARCHAR',
        'ssl_protocol': 'VARCHAR',
        'target_group_arn': 'VARCHAR',
        'trace_id': 'VARCHAR',
        'domain_name': 'VARCHAR',
        'chosen_cert_arn': 'VARCHAR',
        'matched_rule_priority': 'VARCHAR',
        'request_creation_time': 'TIMESTAMP',
        'actions_executed': 'VARCHAR',
        'redirect_url': 'VARCHAR',
        'error_reason': 'VARCHAR',
        'target_port_list': 'VARCHAR',
        'target_status_code_list': 'VARCHAR',
        'classification': 'VARCHAR',
        'classification_reason': 'VARCHAR',
        'conn_trace_id': 'VARCHAR'
    },
    delim=' ',
    quote='"',
    escape='"',
    header=False,
    auto_detect=False
);

これで、データのインポートができます。(楽ちん!)

また、勘がいい方はお気づきかもですが、ALB のログは基本 gzip 圧縮されています。
しかし、上記のインポートにおいては、gzip 解凍せずにそのまま突っ込んでインポートができます!(楽ちん!2 回目)

データ探索

最後、簡単な例になりますが、ログをインポートしたテーブルに対して、SQL 形式で調査・探索する例を紹介します。[4]

IP アドレスごとの件数

SELECT 
    SPLIT_PART(client_ip_port, ':', 1) AS ip_address, 
    COUNT(*) AS count 
FROM
    alb_log
GROUP BY 
    ip_address
ORDER BY
    count DESC;

アクセス数が多いリクエスト元を出すときに使いますね。

分単位での合計リクエスト数の多い IP アドレスの確認

SELECT 
    strftime(timestamp, '%x %H:%M') AS yyyymmddHHMM, 
    SPLIT_PART(client_ip_port, ':', 1) AS ip_address, 
    COUNT(*) AS count 
FROM
    alb_log
GROUP BY 
    yyyymmddHHMM, 
    ip_address
ORDER BY 
    count DESC,
    yyyymmddHHMM ASC,
    ip_address ASC;

これも、先の例に分単位をかけ合わせたものです。
たとえば、(D)DoS のように短時間で急なアクセスが多いときにどこからリクエスト来ているかを調査するときに見ますね。

5XX エラーの抽出

SELECT 
    type, 
    timestamp, 
    client_ip_port, 
    elb_status_code, 
    target_status_code, 
    request 
FROM
    alb_log 
WHERE
    elb_status_code >= 500;

これも、何か問題があったときの調査で、5XX エラーの調査で使ったりしますね。

さいごに

今回、DuckDB を AWS CloudShell で使うことを試してみました。
導入も簡単で、ローカル環境に依存しない形で使うことができるので、作業端末(Windows や Mac)に依らず、安定した使い方ができるのはいい点ですね。

また、ローカルの DuckDB でもいいですが、ALB のログをローカルにダウンロードするのはめんどくさい[5]ので、今回のように CloudShell を使って、ブラウザ(管理コンソール)に閉じた操作でできるのは個人的にはおすすめです。[6]

今回は、ALB のログを触ってみましたが、他にも使える点はあるので、それは別の記事で書きたいと思います。

参考

脚注
  1. 何番煎じでもいい!自分の煎じ方が、そこにある! ↩︎

  2. トツギーノ。 ↩︎

  3. 一般的には、Athena を使うのがよくある話かなと思いますが、DuckDB でとりあえず見てみたいときはこっちのほうが楽です。(少なくとも自分は。) ↩︎

  4. 他にこんなのあるよとかアイデアあれば、コメント貰えると嬉しいです。 ↩︎

  5. GUI でも、CUI でも、画面操作の手間やクレデンシャルの管理などがめんどくさいと思っている。 ↩︎

  6. AWS CLI で S3 から cp コマンド叩くときに、ワイルドカードを使うと日付フォルダ全部を丸ごと取れるので、より楽ができます。 ↩︎

BABY JOB  テックブログ

Discussion