ツー

日常の記録

CloudFront+lambda@edgeでオンデマンドで画像のリサイズしてくれるやつを作る

だいたいはAWSの公式ブログの通り。

上記に書いてなくてハマったことが2点。

bucket policyにGetObjectだけじゃなくてListObjectがないと403が出て混乱する

上記のAWSブログにあるやつを実装してみると404かどうかをチェックしてリサイズの処理を走らせている。

s3のファイルは GetObject だけしかしてないからそれだけ権限あればいいやろーーとs3のbucket policyにそういう設定をすると

data "aws_iam_policy_document" "bucket-policy" {
  statement {
    sid    = "1"
    effect = "Allow"
    actions = [
      "s3:GetObject"
    ]
    resources = [
      "arn:aws:s3:::${var.appid}",
    ]
    principals {
      type        = "AWS"
      identifiers = [aws_cloudfront_origin_access_identity.oai.iam_arn]
    }
  }
}

確実にないファイルを指定しているのにリサイズが動作しない。

なんでやと調べてみるとだいたいクラメソさんが用意してくれてる。たすかる。

ListObject がないとファイルあるかわからんとなって 404 じゃなくて 403 になるらしい。

というわけで下記のように修正。

data "aws_iam_policy_document" "bucket-policy" {
  statement {
    sid    = "1"
    effect = "Allow"
    actions = [
      "s3:GetObject",
      "s3:ListBucket"
    ]
    resources = [
      "arn:aws:s3:::${var.appid}",
      "arn:aws:s3:::${var.appid}/*"
    ]
    principals {
      type        = "AWS"
      identifiers = [aws_cloudfront_origin_access_identity.oai.iam_arn]
    }
  }
}

ちゃんと 404 が出るようになって、スクリプトも動くようになったのでOK。

CloudFormationでlambda@edgeを作ると関数が更新できない

lambda@edgeを使うには、普通にlambdaを作ったうえでCloudFrontのconfigにlambdaのARNを指定するという形になる。なおバージョンを指定しないとだめなので、lambdaを更新するたびにversionを作成してCloudFrontに登録しなおさないといけない。普通のlambdaみたいにdeployして適当に動かすみたいなのができない。

最初はlambda@edgeを作るのにserverless frameworkを使っていたが、lambdaを更新してもversionをアップデートしてCloudFrontを更新してくれない。

で、ドキュメントを見たら

Updates are not supported for this property.

サポートしてないんかい!!

というわけでterraformで書き直した。

terraformでlambdaというと地獄そのものみたいなイメージがあったけど、試してみたら今はそうでもなくなってたっぽい。

data "archive_file" "viewer-request" {
  type        = "zip"
  source_dir  = "../lambda/viewer-request/src"
  output_path = "../lambda/viewer-request/viewer-request.zip"
}

resource "aws_lambda_function" "viewer-request" {
  filename         = data.archive_file.viewer-request.output_path
  function_name    = "${var.appid}-viewer-request"
  role             = aws_iam_role.lambda.arn
  handler          = "handler.viewer_request"
  runtime          = "nodejs14.x"
  memory_size      = 128
  timeout          = 5
  source_code_hash = data.archive_file.viewer-request.output_base64sha256
  publish          = true
}

archive_file というのができてて、パスを指定すればよしなにzipファイルを作ってくれるやつなので terraform apply 以外にやることがなくて楽。ケースによるけどserverless frameworkよりも楽なのでは。

web上の記事ではlambdaの関数作成のみterraformで行って更新はlambrollなどで行うパターンはよく見る。会社等で属人性をなくすのであればそういうことも必要かもしれないけれど、lambda@edgeの関数はそうそう更新しないだろうし、terraformで一括管理でいい気がする。CIとかは必要になったら考えましょう。

まとめ

やっぱり実際やってみるといろいろハマりどころはある。

無限にたまったCloudWatch Logsの空のlogstreamを全部削除する

CloudWatch Logsのログ自体は、保持期間を指定できるのでデータは消えてくれるけど、データの入れ物であるlogstreamだけは空のものが延々と残り続けるので削除する。

コード

こういう時はさくっとできるserverless frameworkで。

service: lambda-delete-empty-logstream
frameworkVersion: '3'
provider:
  name: aws
  runtime: nodejs14.x
  stage: dev
  region: ap-northeast-1
  iam:
    role:
      statements:
        - Effect: "Allow"
          Action:
            - "logs:DescribeLogGroups"
            - "logs:DescribeLogStreams"
            - "logs:DeleteLogStream"
          Resource: "*"

functions:
  main:
    handler: handler.main
    description: Delete old and empty logstream
    timeout: 300
    events:
      - schedule: rate(1 day)

resources:
  Description: Delete old and empty logstream
'use strict';

const AWS = require('aws-sdk');
const Logs = new AWS.CloudWatchLogs();

// rate limit is 5 calls/sec. so sleep 200sec
// https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html
const sleep = () => new Promise((resolve) => setTimeout(resolve, 200));

module.exports.main = async (event) => {
    const now = Date.now();
    const threshold = 7 * 60 * 60 * 24 * 1000;

    let cnt = 0;
    let groups;
    groups = await Logs.describeLogGroups({}).promise();

    while (1) {
        for (const log of groups.logGroups) {
            let streams;
            streams = await Logs.describeLogStreams({ logGroupName: log.logGroupName }).promise();

            while (1) {
                for (const stream of streams.logStreams) {
                    if (stream.storedBytes === 0 && (now - stream.lastEventTimestamp) > threshold) {
                        console.log("DELETE", ++cnt, log.logGroupName, stream.logStreamName);
                        await Logs.deleteLogStream({ logGroupName: log.logGroupName, logStreamName: stream.logStreamName }).promise();
                        await sleep();
                    }
                }

                if (streams.nextToken) {
                    console.log("FETCH stream");
                    streams = await Logs.describeLogStreams({ logGroupName: log.logGroupName, nextToken: streams.nextToken }).promise();
                    await sleep();
                } else {
                    break;
                }
            }
        }

        if (groups.nextToken) {
            console.log("FETCH group");
            groups = await Logs.describeLogGroups({ nextToken }).promise();
        } else {
            break;
        }
    }

    return "OK";
};

実行結果

ドキュメントを確認したところ、logstream一覧や削除のAPIは秒間5回が限度らしい

なので1callごとに200msのsleepを入れるようにした。

lambdaの実行時間上限値の300秒に設定して実行してみたら、logstreamを1000個くらい消したあとタイムアウトして終了する。だーーっと流して一斉に消してもいいけれど、急いでるものでもないし一日に一回だけ流す設定にしてみた。いつか消せるものは全部消えてくれるでしょう。たぶんまた増えるだろうし、一日一回のバッチ処理で徐々に消せばいいかなという感じ。

作った後にEventBridgeでログを消えた瞬間にlogstreamを消すやつ作れそうじゃね?とも思ったが、暇があったらまた調べようと思う。

Ninja250 エンジンオイル交換

だいたい3000km走ったので交換。

yamalube sportはrs4gpと比べるとそんなに美味しそうな色じゃない。でもハチミツっぽいかも。

エンジンオイルの交換

  • 2022/03/12 → 2022/05/14 約2ヶ月
  • 57391km → 60628km 3237km
  • rs4gp → yamalube sports
  • フィルターエレメントも交換
  • 給油量 2.3L

メモ

  • 今回は2ヶ月で交換だったので割と早めのペース。
  • ふと気になってyamalube sportsにしてみた。
    • 高速をバリバリ走るとかならともかく、下道しか走らんのであればそんなに高いもの入れなくても良くね?の算段。
    • 次交換の時にダメだったとか言ってそうな気もするけど一回やってみるやつ。
  • チェーンにオイル刺しも含めて作業時間45分。
  • そろそろ買ってから4万キロくらいになろうとしているけど、まだまだチェーンは大丈夫らしい。
    • 趣味がチェーンオイル刺しってくらいには頻繁にやってるのが結構効いてるっぽい。
    • バイクの部品の中でそこそこ交換費用が掛かるもののうち、自分のメンテで寿命を延ばせる部品だと思うのでこれからも続けていく。

雑記を始めて約一年

割と続いたね。

件数

書き始め宣言が5/21。約一年で153件。

数だけ見るとめっちゃ書いてるなという感じがするが、すげぇ頑張って書いたというわけではなく、あくまで調べごとや考え事のまとめた結果であるので無理したという感じではなかったので意外だった。

2.3日に一個記事は書いてる計算になる。すごい。

実際にはしばらく書かなかったり、一日にまとめて投稿したりとばらつきがあるが、それでも平均で週に二個は何か書いてたらしい。すごいね。

傾向

推しのこと、沼津のことで1/3、バイクとツーリングのことで1/3くらいの感じ。実際の生活感もそんな感じ。

イベントレポも最初のうちは死ぬほど単語が出てこなかったけど、最近は小一時間でまぁまぁだいたい思ってることは書けるようになってきた。

バイクにおいても、趣味であるとツーリングやいろんな用品をいろんなことを片っ端から試していって、記録を書いていった結果がこんな感じになってた。

よかったこと

テキストをある程度の速度で出力できるようになってくると、そもそもインプットの段階からアウトプットに使うための情報整理が始まるような脳の動き方をするので、何かを試そうという時の行動がめっちゃ早くなった。

ブログを書き始めたころは、まず材料を集めてきて一か所に集めてどうしようかなと悩んでいる感じだったが、最近は材料を手にした瞬間からこれはここに使えそう、これはこっちだという情報整理が9割くらいの精度で出来るようになって、文章を書くのはほぼまとめるだけという感じになってる。

労働においてもあんまり得意でなかった文章が割と早く書けるようになってきているのでいいことしかない。

まとめ

みんなももっとテキストを書こう。今始めるのが一番早い。

GWは結局遠出しなかったので最終日に無茶苦茶走ってきた

at 2022/05/05

むしゃくしゃしてやった。くっそ疲れた。

以下GWの混雑のメモとして。

奥多摩周遊道路

  • 0700自宅出発
  • (芝公園→首都高→中央道→八王子)
  • 0900セブンあきる野戸倉(朝ごはん)
  • (所々でちょくちょく休憩)
  • 1010 三頭橋(休憩)
  • 1030 出発

やっぱりワインディングを走ってると生きてることを実感する。

途中の新滝山街道ねずみ取りスポットに無限にパトカーと白バイがいたし、奥多摩周遊道路もパトカーと白バイが周遊しててGWを感じる。奥多摩周遊道路自体は混んでなかったけど、パトカーがめっちゃペースカーしてくるので途中でちょくちょくと休憩してやり過ごしてたので普段より時間はかかった。

大菩薩ライン

  • 1200 道の駅富士川(昼ごはん)
  • 1230 出発

くっそ長そうに見えて割と1時間ちょっとくらいの大菩薩ライン。自然が豊かなのでどの季節に行ってもたのしい。

意外に交通量はそんなに多くなく快適に走れた。

道の駅富士川で昼ごはん。とりもつ定食。

こういうのつい買いたくなる。

身延みち

  • 1400 NEOPASA清水(クシタニカフェでおやつ)
  • 1430 出発

身延みちも季節ごとに結構風景が違うし、結構走りごたえのある道なのでたのしい。ほんのりゆるキャン成分を摂取できるのもいい。

清水あたりで休憩を取りたいと思ってたんだけどなんかあったっけと考えてたら

そうだこの前行ったクシタニのカフェがあったわ

やっぱコーヒーがうめぇ。

NEOPASAは高速道路からも一般道からもアクセス出来るので高速に乗らなくても普通に利用できるやつ。

ここらへんから疲れてくるのでなんかシューズでも買おうかと思ったけどさすがにやめといた。でもこのツーリングルートにクシタニのショップに行けるという工程が突っ込めることがわかったので、普通に店に行くのとツーリングの半々の目的で行くのは全然アリだなと思った。

沼津

  • 1440 新東名 新清水IC
  • 1500 新東名 長泉沼津IC
  • 1540 松月(買い物と休憩)
  • 1630 出発

R1静岡区間の一般道バイパスでもいいかなと思ったけど、この前名古屋まで走った際にマジで表定120kmが出せるということがわかったので使うことにした。

なんで沼津に寄ったかといえば、松月さんの柏餅を買いたかったので。

なお曜どらも買えたらいいなと思ったけど売り切れてた。知ってた。

いつ来ても三津浜の景色はきれい。沼津市民になったらこれを気軽に見に行けるんか??と割と考えちゃう感じである。ちかちゃんちの子になりたい。

夕飯と帰宅

  • (伊豆縦貫→三島塚原→箱根上り)
  • 1730 アネスト岩田スカイラウンジ(トイレ休憩とルート確認)
  • (県道732 箱根旧道→西湘バイパス)
  • 1840 西湘PA(トイレ休憩)
  • 1910 上州屋(夕ごはん)
  • 1940 出発
  • (横浜新道→首都高→臨海副都心→R357)
  • 2145 帰宅

箱根新道が泥のように混んでたのでターンパイクで行くかと思ったら

通行止め!なんでや!!

なんかトラックが大破してたらしい。怖。

文面を見るにだいぶ派手にやっちゃったやつなんだと思う。

バイクで走ってても若干怖さを感じるあの急勾配を荷物をたくさん積んだトラックで走ったら恐怖しかないと思うんだけど、まぁその通り。

箱根の道はどこもクソ混んでて空いてる道はないかと探してたら、県道732の箱根旧道が空いてたのでそっちに行った。R1との合流で15分くらい詰まったけど、箱根新道の1時間半に比べたらかなりマシなのでこっちでよかった。

渋滞に巻き込まれて遅くなってたので、家でご飯は諦めていつもの通り上州屋へ。

今回はハンバーグ定食。相変わらず罪の味がする。

まとめ

走行距離約550km。さすがに疲れた。

箱根みたいな観光地周辺は抜けるのに苦労したけど、それ以外の高速とかは言うほど混んでなかった。まだGWが続いてるからかもしれない。

こういう人が動く連休は人のいない山を走るに限る。

Ninja250 リアのブレーキパッド交換

at 2022/05/03

ブレーキパッドの交換

  • 2021/05/30 → 2022/05/03 約1年
  • 45687km → 59910km 約14000km

使用限界マークを割とぶち抜いてたね。予約の際に店員さんに確認してもらった時も割とヤバめと言われた。ほんとブレーキパッドの確認忘れがち。

ビフォー

アフター

感覚的には一年点検ごとに交換したほうがいいかなと言った感じっぽい。

次はディスクを交換したほうがいいかもと言われた。

費用

  • ブレーキパッド代(デイトナ赤パッド) 3850円
  • 工賃 2200円

もっとするかと思ってたのでとっとと変えておけば良かったね。

最近のナップスは飛び込み受付が無理っぽい

バイクの消耗品交換はスケジュールの合間を見つつ予約するのが面倒でなにかと先延ばしにしがち。

ふと予定が空いた週末、ナップスに朝一で行って空いてます??と聞くと午後二くらいまでに作業ができることが多かったので割と愛用してた。

だがどこもかしこもバイクが売ってない空前のバイクブームな昨今、相応にバイクの整備の需要も増えているのは当たり前なようで、朝一に行っても「無理です」とはっきり言われた。11月に行った時は「1日待ってればどっかで差し込めるかもしれません、保証はできませんが」と言われてまだ可能性はあったのでここ半年くらいでまた情勢が変わったっぽい。

まぁちゃんと予約していきましょうねという感じ。4/24の朝一に店舗に行って最短で5/3の15時と言われたのでやっぱバイクブームすごいわ。

まとめ

今度はタイヤがスリップサインまで1mmくらい。つらい。

SNSとSQSでpub-subな仕組みを構築するための検討

SNSトピックに {"command":"mail.send", param:{"name":"moge"}} みたいなのを投げるとjob queueが動くみたいなのを作りたかったので検討。

SNS -> SQS -> Lambda みたいな構成。

SNSの上限

https://docs.aws.amazon.com/ja_jp/general/latest/gr/sns.html

  • メッセージを送信するAPIはpublish
    • 標準topic 東京リージョンは秒間1500call、バージニアは秒間30000call
    • FIFO topicは秒間300callかメッセージのデータ総量が秒間10MBのどちらか

SQSの上限

https://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html

  • メッセージをqueueするAPIはSendMessage
    • 標準 queueはほぼ無制限。かっこいい
    • FIFO queueは秒間300call。
      • SendMessageで送った場合は秒間300メッセージ
      • SendMessageBatchで10個まとめて送れば秒間3000メッセージ
    • スループットFIFO queueの10倍の性能が出る
      • SendMessageで送った場合は秒間3000メッセージ
      • SendMessageBatchで10個まとめて送れば秒間30000メッセージ
      • 価格表では高スループットで別途価格が増えるとは書いてないので、単純に処理が増えた分のapi call分だけ料金がかかるという感じっぽい?

システム要件との比較

今のシステムは秒で300リクエストを飛ぶことはないので、FIFOのtopic、queueで問題なさそう。

FIFOから標準queueとか、us-east-1に移行とかすればスループットを稼げるが、秒間300callを超えるような規模感になっている時点で現在のインフラが耐えられないので変えないとダメだと思う。よってその時になってから考えればいいし、その時はkinesisとか使えばいいかなという感じ。

まとめ

いける