自宅ネットワークのログ基盤を作っています。前回は Proxmox の非特権LXCで syslog 514番が開かない理由と対処法 で、rsyslog がネットワーク機器から syslog を受けるところまで作りました。

次は Loki を立てて S3 に流す番です。その前にログの保持期間を決めようとしたのですが、自分で書いた設計書が Loki の実装と噛み合っていないことに気づきました。

さらにコストを試算したら、収集対象から除外したものの根拠まで間違っていました。

この記事では、S3 バケットの設計をやり直した過程と、AWS CLI での構築手順を扱います。Loki のインストールは次の記事にします。

記事中の値について AWS アカウントIDは 000000000000、バケット名は example-loki-logs に置き換えています。ご自身の環境の値に読み替えてください。

先に用語を整理する

Loki の設計を考えるには、ログがどう保存されるかを知っている必要があります。私自身ここが曖昧なまま進めて混乱したので、先にまとめます。

チャンク

Loki は受け取ったログを1行ずつ S3 に書くわけではありません。メモリ上にまとめてから、ある程度の塊にして書き出します。

この塊が チャンク です。「ログ何百行かをまとめて圧縮した、S3 上の1ファイル」と思ってください。

flush

メモリ上の塊を確定させて S3 に書き出す操作です。日本語にすれば「書き出し」。タイミングは3つあります。

自宅のようにログ量が少ない環境では、サイズに到達せず時間切れで flush されるのがほとんどです。 ここが後のコスト試算に効いてきます。

WAL

Write Ahead Log（先行書き込みログ）の略で、データベースでよく使われる仕組みです。

メモリ上で塊を作っている最中に Loki が落ちたら、まだ flush していないログは消えてしまいます。最大で2時間分です。

そこで、受け取ったログをメモリに積むのと同時に、ローカルディスクにも素早く書き留めておきます。これが WAL です。落ちても再起動時に読み直せば復旧できます。

flush が成功すれば、その分の WAL は不要になって捨てられます。つまり WAL に溜まるのは「まだ S3 に行っていない分」だけなので、数百MB程度で頭打ちになります。

キャッシュ

検索時に S3 から取ってきたインデックスやチャンクを、ローカルに一時保存しておく領域です。同じ範囲をもう一度検索するとき、S3 に取りに行かずに済みます。

消えても困らないのがキャッシュです。 なくなれば S3 から取り直すだけなので、TTL を設定して自動的に破棄させます。

ストリーム

Loki は各ログ行に「ラベル」という札を付けて保存します。このラベルのセット全体が1つのストリームです。

host だけ違っても分かれ、job だけ違っても分かれます。ラベルの種類を増やすと、ストリーム数は掛け算で増えます。 10ホスト × 3ジョブなら30ストリームです。

チャンクはストリームごとに別々に作られます。 30ストリームあれば、時間切れ flush のたびに30個のオブジェクトが生まれます。「ラベルを増やしすぎるな」と言われるのはこのためです。

TSDB とインデックス

S3 にチャンクだけ置いても検索できません。「host=A のログはどのチャンクに入っているか」を引くための索引が要ります。それが インデックス です。

TSDB（Time Series DataBase）は、そのインデックスの形式の名前です。Prometheus で使われている形式を Loki が採用したもので、Loki 3.x での推奨形式です。

インデックスはチャンクとは別に、定期的に S3 へアップロードされます。この担当部品を index shipper と呼びます。

内部の役割分担

Loki は1プロセスで動いていますが、中は役割ごとに分かれています。ログや設定にこれらの名前が出てくるので、押さえておくと読めるようになります。

メモリを食うのは ingester と querier です。 ingester は flush 前のチャンクを抱え、querier は検索時にチャンクを展開します。

最初に書いていた設計

自宅ネットワーク基本設計書 には、こう書いていました。

一見それらしく見えます。ローカルに2週間置いて、古いものは S3 に逃がす。よくある構成に思えました。

これが間違いでした。

何が噛み合っていないのか

Loki のオブジェクトストアを S3 にすると、チャンクは flush された時点で S3 に書き込まれます。ローカルに残るのは WAL とキャッシュだけです。

つまり「一定期間ローカルに保持した後、S3 へ移す」という段階的な移動はそもそも発生しません。

前回の記事で LXC のディスクを16GBにしたとき、内訳をこう見積もっていました。

このときすでに「ローカルには WAL とキャッシュしか残らない」と書いています。構成は正しく理解していたのに、保持期間の記述だけが古い認識のまま残っていたわけです。

設計書を後追いで更新していると、こういう食い違いが生まれます。書いた時点では別々の項目だったものが、実装が進むと矛盾する。気づけたのは、実際に設定値を決めようとしたからでした。

正しい書き方

保持期間は、ローカルの保存期間ではなく Loki が検索可能な期間として定義し直します。

実装としては2箇所に設定が要ります。

• Loki の compactor に指示する retention_period
• S3 のライフサイクルの Expiration

この2つが揃って初めて「保持期間」が成立します。

では何日にするのか

費用対効果を考えようとして試算してみました。結論から言うと、費用は判断材料になりませんでした。

※ 2026年9月時点、東京リージョンの料金で試算しています。最新の価格は AWS の料金ページ をご確認ください。

ログ量の前提

ストレージ費用

東京リージョンの S3 標準は、最初の50TBまで 0.025 USD/GB・月です。

1年保持しても、月に0.4円です。

リクエスト費用

S3 は「置いている量」だけでなく、API を呼んだ回数でも課金されます。これがリクエスト費用です。

この規模では、こちらの方が支配的でした。

PUT・COPY・POST・LIST は 0.0047 USD/1,000リクエスト、GET その他は 0.00037 USD/1,000リクエストです。

保管料 $0.003 に対してリクエスト料 $0.036。10倍以上の差がありました。

「ログを長く持つとお金がかかる」という直感は保管量の話ですが、この規模ではそもそも回数の方が効いていたわけです。

データ転送

Loki は自宅にあるので、検索のたびにチャンクを S3 から取得します。それでも月100GBの無料枠にはまったく届きません。

総額

月10円未満、年間でも100円程度でした。保持期間を14日から1年に伸ばしても、増えるのは月0.4円です。

コストで決められないなら、何で決めるのか

基準を「どこまで遡れれば障害調査とセキュリティ監視が成立するか」に置き直しました。

考えたのは以下です。

• 発生から発覚までに時間があく事象を追えること
• 季節性のある事象（空調、電力、特定の曜日に起きる何か）を比較できること

半年あれば足りると判断し、180日にしました。

Loki 側の retention_period は 170日にします。S3 のライフサイクルより10日短くするためです。

なぜ Loki 側を短くするのか

ここは理屈を追わないと納得しにくいところなので、順を追って書きます。

Loki の検索は2段階です。

1. インデックスを引いて「どのチャンクを読むか」を決める
2. そのチャンクを S3 から取得する

一方、S3 のライフサイクルは Loki の事情を知りません。180日経ったオブジェクトを機械的に消します。このときインデックスは消しません。 インデックスは別のオブジェクトで、作成日も違うからです。

もし S3 が先に消すと、こうなります。

1. S3 が180日経ったチャンクを削除する
2. Loki のインデックスには、そのチャンクの情報が残ったまま
3. 検索すると、インデックスが「このチャンクを読め」と指示する
4. 取りに行くと、存在しない
5. エラーになる

インデックスと実体の整合が崩れるわけです。

これを避けるため、Loki 側を170日にして先に消させます。compactor はインデックスとチャンクの整合を保って削除するので、この問題が起きません。

S3 のライフサイクルは、compactor が取りこぼしたものを後から拾う保険として残す。そういう役割分担にしました。

除外の根拠も間違っていた

設計書にはもうひとつ、こう書いていました。

ファイアウォールの転送トラフィックログは対象外とする。容量が大きく、本環境の目的（障害調査・セキュリティ監視）に対して費用対効果が低いため。

試算すると、これも成り立ちません。

仮にトラフィックログを全部入れて50万行/日（生125MB/日）にしても、1年保持で4.4GB、月16円程度です。費用対効果を理由にできる水準ではありませんでした。

ただし、除外の判断自体が間違いかというと、そうではありません。理由が違っていたのです。

本当の制約はローカル資源でした。

• 16GBのディスクに WAL とチャンクキャッシュが載り切るか
• 4GBのメモリで querier が耐えられるか
• LogQL の全文検索が実用速度で返るか

S3 は安いが、自宅の LXC は安くない。 設計書の根拠を「S3費用」から「ローカル資源とクエリ性能」に書き換えました。

Glacier に移せば安くなる、と思っていた

当初は当然のように「古いログは Glacier に落とせばいい」と考えていました。安いクラスに移すほど得をするはずだ、と。

計算すると逆でした。

Glacier への移行は 0.0571 USD/1,000リクエストです。月3,600オブジェクトを移行すると $0.21/月。保管料そのもの（$0.003）の70倍になります。

加えて Glacier 系には 128KBの最小課金サイズがあります。Loki が生成するチャンクは数十KBなので、128KBとして課金され、容量まで水増しされます。

さらに、Glacier Flexible Retrieval 以降のクラスは復元しないと読めません。検索可能であることを保持期間の定義にした以上、要件と矛盾します。

よくよく考えてみると、これは気づきでした。「安いクラスに移せば得をする」という前提は、小さいオブジェクトが大量にある構成では成立しない。 単価だけ見て判断していたら、確実に間違えていたところです。

ここで注意したいのは、「規模が小さいから Glacier が向かない」わけではないことです。

同じ自宅環境でも、日次バックアップを数GBのファイルで置くなら Glacier は有効です。オブジェクトが少なく大きいので、移行リクエストも最小課金サイズも問題になりません。

Loki が不利なのは、時間切れで小さいチャンクを量産する構造だからです。ログ量が少ないほどチャンクが小さくなるので、皮肉なことに規模が小さいほど Glacier との相性が悪くなります。

判断の分かれ目は「データ量」ではなく「オブジェクトの数と、1個あたりのサイズ」でした。

構築

ここから実際の手順です。AWS CLI で進めます。コンソールでも同じ設定ができますが、CLI にすると設定値をそのまま記録に残せます。

命名規則

既存の AWS リソースは、以下の規則で命名していました。

<用途>-<環境>-<リソース種別>-<役割>

S3 バケットもこれに揃えます。先頭を「サービス名」ではなく「用途」としているのは、製品名を入れると差し替えたときに名前が嘘になるからです。

変数の定義

BUCKET=example-loki-logs
REGION=ap-northeast-1

以降で同じ値を何度も使うので変数にします。打ち間違えたときに空文字として一斉に失敗するので、かえって発見が早くなります。

名前が空いているか確認

S3 のバケット名は全世界で一意です。 アカウント内で一意なのではありません。

EC2 のインスタンス名は自分のアカウント内で重複していなければよかったので、これは S3 特有の制約です。

aws s3api head-bucket --bucket ${BUCKET}

返るエラーで状態が判別できます。

403 は「アクセス拒否」ですが、拒否されたということはそのバケットが実在するということです。存在しないものにはアクセス権の判定自体が発生しません。

裏を返すと、ある名前が使われているかどうかは、権限のない第三者からでも推測できます。バケット名に推測されたくない情報を入れるべきではない理由がこれです。

バケットの作成

aws s3api create-bucket \
  --bucket ${BUCKET} \
  --region ${REGION} \
  --create-bucket-configuration LocationConstraint=${REGION}

{
    "Location": "http://example-loki-logs.s3.amazonaws.com/",
    "BucketArn": "arn:aws:s3:::example-loki-logs"
}

--create-bucket-configuration LocationConstraint は省略できません。 S3 の API は歴史的な経緯でバージニア北部を特別扱いしており、これを省くと --region を指定していてもバージニア北部に作られる場合があります。

リージョンは後から変更できないので、作成直後に確認します。

aws s3api get-bucket-location --bucket ${BUCKET}

パブリックアクセスを全ブロック

aws s3api put-public-access-block \
  --bucket ${BUCKET} \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

4つのフラグは、それぞれこういう意味です。

「これから設定させない」系が2つと、「すでにあるものを効かなくする」系が2つ。 それが ACL とバケットポリシーの両方に用意されている、という構造です。

すべて true にしておけば、後で自分が誤って公開設定を入れても効きません。自分の誤操作に対するガードレールです。

暗号化

aws s3api put-bucket-encryption \
  --bucket ${BUCKET} \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"},
      "BucketKeyEnabled": true
    }]
  }'

SSE-KMS ではなく SSE-S3（AES256）にしています。 KMS は API リクエスト単位で課金されるため、Loki のように小さいオブジェクトを大量に書く用途では、KMS の方が S3 本体より高くつきます。バケットキーで緩和はできますが、自宅のログにそこまでの要件はありません。

ここでも「小さいオブジェクトが大量にある」という条件が判断を決めています。

バージョニングは無効のまま

新規バケットはデフォルトで無効設定なので、設定ではなく確認です。

aws s3api get-bucket-versioning --bucket ${BUCKET}

何も出力されなければ無効です。

これは確認する価値があります。 バージョニングが有効だと、compactor が削除しても削除マーカーが付くだけで実体が残ります。retention を設定しているのにストレージが単調増加する、という状態になります。

有効にする場合は NoncurrentVersionExpiration をセットで入れてください。

ライフサイクル

cat > lifecycle.json <<'EOF'
{
  "Rules": [
    {
      "ID": "expire-loki-objects-180d",
      "Status": "Enabled",
      "Filter": {"Prefix": ""},
      "Expiration": {"Days": 180}
    },
    {
      "ID": "abort-incomplete-multipart",
      "Status": "Enabled",
      "Filter": {"Prefix": ""},
      "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}
    }
  ]
}
EOF

aws s3api put-bucket-lifecycle-configuration \
  --bucket ${BUCKET} \
  --lifecycle-configuration file://lifecycle.json

Filter の Prefix を空文字にしているのは、バケット全体を対象にするという意味です。Loki は内部でプレフィックスを使い分けますが、どちらも同じ180日で消してよいので絞る必要がありません。

2つ目のルールは見落としやすい項目です。マルチパートアップロードが途中で失敗すると、送信済みのパートが残ります。 これは完了していないのでオブジェクトとして存在せず、aws s3 ls にもコンソールにも出てきません。それなのにストレージ料金は発生し続けます。

Loki のチャンクは小さいのでマルチパートを使う場面はほぼありませんが、見えない課金は気づいたときに何年分も溜まっているのが常なので、入れておきます。

適用すると、こんな応答が返りました。

{
    "TransitionDefaultMinimumObjectSize": "all_storage_classes_128K"
}

「128KB未満のオブジェクトは階層移行の対象にしない」という既定値の通知です。今回は階層移行ルールを入れていないので作用しませんが、小さいオブジェクトを Glacier に移すと損をするので AWS 自身がデフォルトで外すようになった、という経緯が透けて見えます。移行をやめた判断がここでも裏付けられました。

IAM

ポリシー

cat > loki-s3-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BucketLevel",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::${BUCKET}"
    },
    {
      "Sid": "ObjectLevel",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::${BUCKET}/*"
    }
  ]
}
EOF

ここだけヒアドキュメントの EOF をクォートしていません。 lifecycle.json では <<'EOF' としましたが、こちらは ${BUCKET} を実際のバケット名に展開したいので、あえて外しています。作成後に cat して展開されているか確認してください。

ステートメントを2つに分けているのが要点です。

s3:ListBucket はバケットそのものに対する操作なので、リソースはバケットの ARN。s3:GetObject などはバケット内のオブジェクトに対する操作なので、末尾に /* が付きます。

ここを間違えると「一覧は取れるが読めない」「読めるが一覧が取れない」という中途半端な状態になり、原因が分かりにくいエラーになります。

権限は Loki の動作に必要なものだけです。冒頭で整理した部品と対応させると、こうなります。

DeleteObject を外すと retention が機能しません。 compactor が削除に失敗し続け、実質 S3 のライフサイクル任せになります。

バケットの作成・削除、ポリシー変更、他のバケットへのアクセスは一切許可していません。この鍵が漏れても、被害はこのバケットの中身に限定されます。

aws iam create-policy \
  --policy-name LokiS3Access \
  --policy-document file://loki-s3-policy.json

ユーザー

aws iam create-user --user-name loki-<ホスト名>

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

aws iam attach-user-policy \
  --user-name loki-<ホスト名> \
  --policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/LokiS3Access

ユーザー名にホスト名を入れています。 将来サーバーが増えたとき、どの鍵がどこで使われているかを名前から追えるようにするためです。鍵を無効化するときに、何が止まるかが判断できます。

バケットは AWS 側の命名規則、IAM ユーザーはオンプレのホスト名に紐づける、という使い分けです。

アクセスキー

aws iam create-access-key --user-name loki-<ホスト名>

SecretAccessKey はこの一度しか表示されません。 再取得はできず、失くしたら作り直しです。

疎通確認は「通らないこと」も確認する

作った鍵で、Loki が実際に行う操作を試します。

AWS_ACCESS_KEY_ID='AKIA...' \
AWS_SECRET_ACCESS_KEY='...' \
AWS_DEFAULT_REGION=ap-northeast-1 \
aws s3 ls s3://example-loki-logs/

コマンドの前に VAR=value を並べると、そのコマンドの実行中だけ環境変数が有効になります。シェルの設定には残らないので、確認用として安全です。

書き込みと削除も試します。

echo test > /tmp/loki-test.txt
aws s3 cp /tmp/loki-test.txt s3://example-loki-logs/test.txt
aws s3 rm s3://example-loki-logs/test.txt

ここで大事なのは、通らないべきものが通らない確認です。

aws s3 ls

これはバケット一覧の取得で、s3:ListAllMyBuckets が必要です。ポリシーに含めていないので、AccessDenied で弾かれるのが正しい挙動です。

ここが通ってしまうなら、意図より広い権限が付いています。 同じアカウントには他のワークロードのバケットもあるので、それが見えないことを確認して初めて「絞れている」と言えます。

なお、現在どの権限で実行しているかは以下で確認できます。

aws sts get-caller-identity

私はこれを忘れ、管理者権限のまま疎通確認をして「成功した」と勘違いしかけました。 管理者なら通って当然なので、ポリシーの検証にはなっていません。

ハマりどころ

行継続が全角の ¥ になっていた

aws s3api create-bucket ¥

aws: [ERROR]: An error occurred (ParamValidation): the following arguments are required: --bucket

半角の \ でないとシェルは行継続と解釈しません。1行目だけが実行されて引数不足になります。日本語キーボードで起きやすい現象です。

\ の直後に空白があっても効きません。 行末の最後の1文字である必要があるので、見えないスペースが紛れているとハマります。

$ が & になっていた

aws s3api get-bucket-location --bucket &{BUCKET}

[1] 282
bash: {BUCKET}: command not found

& はコマンド末尾に付くとバックグラウンド実行の指示になります。--bucket までをバックグラウンドで走らせ、残りを別コマンドとして解釈しました。[1] 282 はジョブ番号とプロセスIDです。

エラーの発生源を見分ける

aws: [ERROR]: An error occurred (ParamValidation): Parameter validation failed:
Unknown parameter ... "SSEAlgorythm", must be one of: SSEAlgorithm, KMSMasterKeyID

SSEAlgorithm を打ち間違えたときのものです。

ParamValidation は、AWS に到達する前に CLI 側で弾かれたという意味です。 ネットワークも権限も関係なく、何度実行しても副作用はありません。

これに対して AccessDenied や NoSuchBucket は AWS 側から返ったもので、実際に API が呼ばれています。

どちらなのかを最初に見分けると、調べる方向が決まります。 ParamValidation ならコマンドの書式だけ見ればよく、コンソールを確認しに行く必要はありません。

AWS CLI は must be one of: の形で候補を出してくれるので、タイプミスの修正はエラーメッセージだけで完結することがほとんどです。

まとめ

今回いちばんの収穫は、コストを試算したら設計の前提が2つとも崩れたことでした。

保持期間を「オンプレ2週間、以降S3」と書いたのは、段階的なストレージ活用という一般論に引っ張られたからです。トラフィックログを「費用対効果が低い」として除外したのも、計算せずに書いた一文でした。

どちらも、数字を出せば5分で分かることを、数字を出さずに書いていたわけです。設計書は「なぜこの構成にしたか」を残すためのものなので、根拠が推測のままでは役目を果たしません。

そして、除外の判断自体は正しかったというのが面白いところです。結論が合っていても、根拠が違えば、状況が変わったときに判断を更新できません。 S3 が安いから除外したのなら S3 が値下げされれば再検討すべきですが、実際の制約はローカルのディスクとメモリなので、判断が変わるのは LXC を増強したときです。

次は Loki を非特権LXCに入れて、実際にこのバケットに書き込むところを扱います。
設定ファイルの各項目が何を意味しているのか、retention_period や GOMEMLIMIT をなぜその値にしたのかを含めて書く予定です。

＼ 最新情報をチェック ／

@AdmonTechLab