AWS Lambdaデプロイツール lambroll v1をリリースしました

AWS Lambda用のデプロイツール、lambroll の v1.0 を2024年2月10日にリリースしたのでお知らせです。

github.com

リリースして早速ですが v1.0.0 には一部のフラグ名がv0と異なるというバグがあるので、v1.0.1 以降をご利用ください。

v0.x と v1 の変更点

リポジトリ にまとめてありますが、簡単に解説します。

非互換変更

lambroll archive zipのバイナリを、標準出力ではなくファイルに書き出します

デフォルトのファイル名 function.zip(--dest オプションで指定可能) に書き出すようになりました。

--dest - を指定することで、v0と同様に標準出力に書き出すことができます。

lambroll diff コマンドは、常に短縮型の unified 形式で出力します

--unified オプションは廃止されました。

新機能

Lambda Function URLのデプロイをサポート

ドキュメントはこちらです

function_url.json (.jsonnetも可) というファイルを例として以下のように用意して、lambroll deploy --function-url function_url.json としてやると、function自体のdeployが終わったあとに Function URL をデプロイします。必要な Lambda permission も同時に付与します。

{
  "Config": {
    "AuthType": "NONE"
  }
}

これは認証なしの一番単純な形式ですが、IAM認証やCORSの指定にも対応しています。Config, Permissions はそれぞれ、AWS SDK Go v2 の CreateFunctionUrlConfigInputAddPermissionInput に対応しています。

{
  "Config": {
   "AuthType": "AWS_IAM",
   "Qualifier": "current",
   "Cors": {
      "AllowOrigins": [
        "*"
      ],
      "AllowMethods": [
        "GET",
        "POST"
      ]
    },
  },
  "Permissions": [
    {
      "Principal": "0123456789012"
    },
    {
      "PrincipalOrgID": "o-123456789",
      "Principal": "*"
    }
  ]
}

備考

  • deploy --function-url が指定された場合のみ、Function URL デプロイを行います
    • オプションを指定しない場合は既存の Function URL のリソースが存在していても変更を行いません
  • lambroll init で既存 function を指定して設定ファイル化する場合、--function-url フラグを指定すると function_url.json の生成も行います
  • lambroll diff についても --function-url オプションが指定された場合のみ、Function URL についての変更差分を表示します

SSM テンプレート関数追加

{{ ssm "/path/to/parameter" }} という記法で、SSMパラメーターストアの値をテンプレート展開できるようになりました。

lambroll status コマンド追加

現在のfunctionの情報を出力します。--output json オプションでJSON形式での出力もできます。

$ lambroll status
+-----------------+-----------------------------------------------------------+
| FunctionName    | hello                                                     |
| FunctionArn     | arn:aws:lambda:ap-northeast-1:314472643515:function:hello |
| Version         | $LATEST                                                   |
| Runtime         | provided.al2023                                           |
| PackageType     | Zip                                                       |
| State           | Active                                                    |
| LastUpdateState | Successful                                                |
| FunctionURL     | https://xxxxxxxxxxxxxxx.lambda-url.ap-northeast-1.on.aws/ |
+-----------------+-----------------------------------------------------------+

lambroll render コマンド追加

lambroll render を実行すると、設定ファイル (function.json, .jsonnet) をレンダリングして標準出力に出力します。

環境変数 LAMBROLL_XXX をオプションとして受け入れます

例えばこれまで lambroll deploy --tfstate=s3://example/terraform.tfstate としていた場合、 LAMBROLL_TFSTATE=s3://example/terraform.tfstate という環境変数を設定することで、コマンドラインオプションでの指定を省略できます。

diffdeployコマンドに --ignore オプションを追加

--ignore で指定された function.json 内の要素について、diffdeploy 時に比較と更新を無視するようになりました。

例えば lambroll deploy --ignore ".Timeout, .Environment" と指定すると、TimeoutEnvironment の値はデプロイ実行時に無視されます。特定の値は更新したくないような場合に便利です。

その他の変更

  • AWS SDK Go を v1 から v2 に更新しました
  • CLI flag parser を kingpin から kong に変更しました
  • リリースバイナリの生成を GoReleaser で行うようにしました
    • アーカイブのパッケージ構成が変わっています。独自のインストール用のscriptがある場合は修正が必要になる可能性があります
    • aqua をご利用の場合は aqua-registry v4.131.1 以降に更新をお願いします
    • CircleCI orb を利用している場合、fujiwara/lambroll@2.0.1 を使用してください
    • Github Actions では fujiwara/lambroll@v1 を使用してください

まとめ

Lambroll v1をリリースしました。目玉機能は Function URL のサポートです!

ドキュメントに書かれた以外の非互換変更は意図しないものの可能性が高いため、もし見つけたらissueなどで教えていただけると嬉しいです。

YAPC::Hiroshimaに参加して、登壇して、アフターイベントのキーノートをしてきました #yapcjapan #yayapc

blogを書くまでがYAPCということで、帰路の新幹線で書いています。

2024年2月9,10日に行われた YAPC::Hiroshima 2024 に参加し、応募したトークが採択されたので登壇し、翌11日に行われたYAPCアフターイベント YAYAPC::Hiroshima オフラインだからできる話 でキーノートを依頼していただいたのでスピーカーを務めてきました。

前回の YAPC::Kyoto 2023に参加しました #yapcjapan - 酒日記 はてな支店 ではトークを応募しないで参加したことに後悔したので、今回は応募して本編で40分、更にアフターイベントで40分と沢山発表させて頂きました…ありがとうございます。

YAPC::Japanになってから過去最大の参加者数、スポンサーも過去最高、初参加の人もたくさんということで、2006年のYAPCから参加している古参(老人)としても大変嬉しいです。

聞いたトークの感想

  • Introduce Hono v4!!!!
    • 今やスーパーハッカーという言葉がぴったりなyusukebe氏。中学生がプロジェクトに何人もいるのがとてもよい。サーバーサイドからWeb standardsで攻めていくというのがほんとわくわくしますね
  • キャッシュバスターズ
    • 実のところキャッシュなしでは現代のCPUもOSもまともに動かないわけで、キャッシュは麻薬ではなくパフォーマンスのためには必須の技術、ただ間違った使い方をする人が多いだけ、なのでバスターすべきは間違った使い方のほう
    • 結局あなたの実務の要件を見て適切にやれ、という話になっちゃうのが難しい(断言できない)ところですよね
    • 個人的にはキャッシュは「作る」のは簡単だけど「消す」ほうが100倍難しいから、消し方を考えてから作れ、という話をよくします
  • 入門EOL対応 ~SREが鉄板の流れ全部見せます編~
    • 年中EoL対応をやっている身として興味深く聞きました。「モチベーション高くやる」方法を意識的に実施しているのが素晴らしかったです
  • What You Like May Not Be for Someone オープンソースアクセシビリティ
    • 自分がこれまで関わっていたサービスは正直なところアクセシビリティにことを考えていないものが多かったなあと反省しきりですね。原理や規則に従っているかどうかも大事ですが、実際に支援技術を使って問題があるかないかを確認するのがもっと大事、という話を受け取りました
  • Go to Cloudflare Workers ~ 移行から 0.5 年以上運用する
    • 筋がよいので使いたい、けどまだまだ周辺が未成熟な技術を腕力でどうにかしていく、整備された道だけではなく自分で荒野を切り拓く話は大好きです。高速道路に乗ると快適ですけど、それだけじゃつまらないですからね
  • 経営・意思・エンジニアリング
    • 途中から、最後のほうだけ聞きました。自分の後ろで誰も責任を取ってくれないところでは最後は意思の力、そうですね…
  • 新任エンジニアリングマネージャーのための「ぼうけんのしょ
    • 目標設定が苦手という人が多い話、これは人から設定しろと言われた瞬間にやる気をなくすやつなので、内発的動機をいかに引き出すかなのかなと思って聞いていました。自分の場合、ランニングの目標は誰にいわれるでもないけど自分で作って、それに対する練習プランを立てたりしちゃいます
  • 非同期な開発体制を支えるドキュメント文化
    • ドキュメント、型があるのいいですね。守破離というか、型がないところにドキュメントを書くぞ!とという意気込みだけがあっても、試行錯誤に耐えられなくて爆発四散しがちです
  • 好きな技術《コト》で、生きていく技術
    • 人生の大半をどうせ仕事が占めるのであれば、どうせなら面白くやったほうが得、そのためにはという話。自分の場合、技術選定は実績があるやつを7,80%、新規で面白そうなのを2,30%ぐらいの配分を意識しています。実績は読めるので爆死しづらいし、新規でよいことは次に取り入れて悪いところは捨てて、を繰り返すことで代謝しつつ前に進めるのでは、という持論でやってます

キーノート

1998年に仕事を始めて、会社の先輩に「とほほ」という凄いページがあるからそこで勉強するといいよ、といわれてそこで学びつつ、ラウンジ(掲示板)で数年常連をやったりしていた身としては、とほほさんにはキャリアの最初からお世話になりっぱなしでした。

淡々とやっていることを紹介しているだけなのに超人にしか聞こえない、息をするように、という言葉そのものでしたね…

自分のトーク

speakerdeck.com

作ってから5年(前身のmirageからだと10年近く)、ずっと仕事で便利に使っているミドルウェアの話でした。懇親会で話を聞くと、まだまだ検証環境が固定でn個あるのでそれの奪い合いになってます、みたいな現場も多いみたいですね。そういう環境に、何かのヒントになれば幸いです。

SREやインフラ領域だと既存のソフトウェアをどう使うかという話になりがちですが、使うだけではなく書くことで、ソフトウェアの力で解決できるところはしていきましょう、というメッセージでもあります。

懇親会

5年ぶりの懇親会、大変楽しかったです!

懇親会のYAPCビールと舟盛り

アフターイベント YAYAPC

YAPC本編は前夜祭と本編1日ですが、今回はアフターイベントYAYAPCが企画されました。公開されるイベントというのはどうしても公開可能な事例しか選ばれない(それはそう)なので、広く公開するにはためらわれるけど面白い話、限定のイベントです。そして、そのイベントのキーノートをkobakenさんに依頼して頂いたので、僭越ながら務めさせて頂きました。

当然イベントの内容はここで公開できないんですが、みなさんそれぞれの現場でそれぞれの戦いをしているんですよね。生き様だなあ、と思いました。めちゃくちゃ楽しかったです。またやりたい、というかやるなら個人でもスポンサーしたいです。

キーノートのスライドはこれもまた公開できないのですが、最後の1ページだけ載せておきますね。

YAYAPCキーノートのスライド(最終ページ)

おまけ

広島滞在中の走行距離は合計22.3kmでした

Mackerelと連携する外形監視エージェントmaprobeにOtel metrics送信機能を追加した

この記事はMackerel Advent Calendar 2023 12月19日分の記事です。

Mackerelと連携する外形監視エージェント、maprobeというOSSを5年ほど前に作って、ずっと使っています。今回は maprobe v0.7.0で Otel (OpenTelemetry) metrics を送信する機能を追加したというお話です。

github.com

maprobeについては以下の記事もどうぞ。 sfujiwara.hatenablog.com

3行でまとめ

  • maprobeはMackerelに登録されているホスト情報を取得して、そのホストに対してping, TCP, HTTPによる外形監視とmackerel-pluginの実行によるメトリック取得を定期的に実行するエージェントです
  • maprobe v0.7.0 では外形監視の結果とpluginの実行結果を、Mackerelのホストメトリックとしてだけではなく、OpenTelemetry Metricsとしても送信できるようになりました
  • 既存pluginや自作pluginによるメトリック取得を、シームレスにOpenTelemetry metricsに移行することができます

設定方法

ここでは例として、Mackerelの「service=prd」「role=redis」のホストに対して、mackerel-plugin-redis によるメトリック取得をする例を載せます。

probes:
  - service: prd
    role: redis
    attributes:
      host.name: '{{ Host.Name }}'
      instance.type: '{{ index .Host.Meta.Cloud.MetaData "cache-node-type" }}'
    command:
      command:
        - mackerel-plugin-redis
        - -host={{.Host.CustomIdentifier}}
        - -config-command=

destination:
  mackerel:
    enabled: false
  otel:
    enabled: true
    endpoint: otlp.mackerelio.com:4317

maprobeは service=prd, role=redis のホストをMackerelから取得し、その全てのホストに対してpluginを実行します。pluginの実行対象 (-host=の値) には、Goのtext/template記法でホストの情報を取りだして展開することができます。{{ .Host.CustomIdentifier }} に具体的なRedis(ここではElastiCache Redis)のnode DNS名が入っているため、今回はそれを指定しています。

通常、pluginで取得したメトリックはMackerelの対象ホストのホストメトリックとして送信されますが、v0.7.0 から増えた destination という設定を追加することで、任意の OpenTelemetry Collector に対して gRPC を使って送信することができるようになりました。

ここで指定している otlp.mackerelio.com:4317 は、現在絶賛βテスト中の、Mackerelが開発中のOpenTelemetry metrics endpointです。Mackerelが提供しているendpointだけではなく、任意のendpointを指定できます。

mackerel.io

また、Otel Metricsの特徴としてメトリックに任意の属性(attribute)を付与できる点があります。 maprobeはデフォルトで host.idservice.name という属性をメトリックに付与しますが、追加で任意のattributeを含めることが可能です。

    attributes:
      instance.type: '{{ index .Host.Meta.Cloud.MetaData "cache-node-type" }}'

この設定例では、ホストのメタデータに含まれる cache-node-type(いわゆるインスタンスタイプ)を追加しています。

取得した結果

ということで、Mackerelに送信されたOtel metricsをクエリグラフ機能によって描画したものがこちらです。

クエリグラフ

maprobeで指定した属性がメトリックに付与されていることが分かります。この属性を利用して、特定の属性を持つメトリックだけ描画したり、特定の属性のメトリックを合計/平均などの演算をして柔軟にグラフを描画できますね。

どのように使うのか

Otel metricsは、特定の監視ツールによらない汎用的なメトリック取得を可能にしてくれます。また、Mackerelの従来の機能では実現できないような、柔軟なグラフ描画も可能になります。

しかし、従来からMackerelをご利用中の皆様は、既存pluginや自作pluginによって現在のモニタリングを構築していることでしょう。それらを全て別の手段によって取得したOtel metricsに置き換えるのは大変ですし、取得方法や項目が変われば監視自体の継続性にも問題が出てきます。

maprobeによって既存pluiginによって取得した値をOtel metricsとして送信することで、既存の監視項目やノウハウを引き継ぎつつ、新たにOtel metricsによる柔軟なグラフ描画(や、現在はまだありませんがアラート)に移行できるかと思います。どうぞご利用ください。

Mackerel OpenTelemetry metric機能の正式公開が待ち遠しいですね!

unbufferでAmazon ECS Execを端末以外から実行する

検索で引っかかるように書いておきます。

ECS Exec (ecspresso exec, ecsta exec, aws ecs execute-commandなど)を端末以外の環境 (例えばJenkinsやGitHub ActionsなどのCI/CD環境) から実行すると、session-manager-pluginが "Cannot perform start session: EOF" でエラーになります。

これは session-manager-plugin が端末(tty)を割り当てられていることを期待しているためです。

expect パッケージに含まれる unbuffer コマンドでwrapして実行して疑似端末を与えると、端末以外からも実行できるようになります。

$ unbuffer aws ecs excute-command ...

github.com

ecspresso MeetUpを開催していただきました

自分が開発しているAmazon ECSデプロイツール ecspresso のmeet upを、JAWS-UGコンテナ支部のイベントとして開催していただきました。

参加された皆様、発表して頂いた8名の皆様、企画、運営してくださったJAWS-UGコンテナ支部の皆様、本当にありがとうございました!

皆様のecspresso愛を感じて、作者冥利に尽きるイベントでした。ecspresso共々、今後ともよろしくお願いします。

jawsug-container.connpass.com

経緯とか

AWS Dev Day 2023 Tokyoの発表 でecspressoをご利用の皆様を紹介したくて名前を出してもいいよという会社さんを募ったところ、思いもよらず多くの反応をもらいました。これだけ多くの人に使ってもらえてるならmeet upぐらいできるんじゃないかな? と思って気軽につぶやいたのですが、それをみていたJAWS-UGコンテナ支部のかたが企画をしてくださった……という経緯でした。

自分のプロダクト(OSS)で単独のイベントを開いてもらった上に8人もの人に話してもらえるという、これはなかなかできない経験でしたね…

ところで当日は48名の現地参加者のうち懇親会参加が29名という大宴会になってしまい、懇親会は当日まで何も決まっていなかったので「居酒屋北海道に断られる」という実績を解除してしまいました。受け入れてもらった ひものや(目黒店)様もありがとうございました。

発表資料

公開されているものを当日の発表順に並べておきます。ecspresso自体の話はいっぱいしてもらえると思ったので、自分はecspressoそのものというよりはそういうソフトウェアを作るときになにをどう考えているか、という話をしました。

speakerdeck.com

junkyard.song.mu

speakerdeck.com

speakerdeck.com

speakerdeck.com

www.docswell.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

録画アーカイブ

www.youtube.com

Go実装のAWS Lambda関数をCLIで動かせるライブラリを書いた

最初に3行でまとめ

  • GoでAWS Lambdaのハンドラを実装した場合に、手元から同じ処理を実行したり開発中の動作確認のため、CLIコマンドとしても実行できると便利です
  • そのための、とてもシンプルなwrapperライブラリを書きました lamblocal といいます
  • 環境変数を読み込めるCLI flag parserと組み合わせるといいかんじです

github.com

Lambdaを実装する言語

最近、自分はAWS Lambdaの関数をGoで書くことがほとんどです。

個別のランタイムがある言語で書くとランタイムのバージョンアップやEoL対応が必要になって面倒だったりしますが、Goで書いてシングルバイナリをbootstrapという名前でzipに含めてカスタムランタイム(provided.al2) で動かすとそういう煩わしさがありません。ARM対応もビルド時に環境変数を指定するだけなので極めて簡単です。

GoでLambda関数を書くためには、aws/aws-lambda-goを使って以下のようにします。

package main

import (
    "github.com/aws/aws-lambda-go/lambda"
)

func hello() (string, error) {
    return "Hello λ!", nil
}

func main() {
    // Make the handler available for Remote Procedure Call by AWS Lambda
    lambda.Start(hello)
}

これを go build -o bootstrap main.go としてLinux向けにビルドしてやると 1、Lambdaのハンドラとして動作します。アーキテクチャはLambdaの設定により、GOARCH=amd64またはarm64です。

Lambda関数を手元でも動かしたい

デバッグや開発中の動作確認のため、手元でこのハンドラを実行したいことがあります。また、lambdaとして便利な関数は、手元でも単体のコマンドとして実行できると便利な場面が結構あったりします。

公式には、AWS SAM CLIを使うことでローカル実行ができたりするようですが、ここでは触れません。

Goで書かれたLambda関数ハンドラをLambdaでもそれ以外の環境でも実行できるコマンド(バイナリ)にするためには、以下のようにすればよいのです。

  1. 実行時に環境がLambda上かどうかを判別する
  2. Lambda上であれば lambda.Start() にハンドラを渡して実行する
  3. そうでない場合、ハンドラの関数に適当な入出力を与えて実行する

実行時の環境がLambda上であることは、環境変数から次のようにして判別できます。2

  • AWS_EXECUTION_ENVAWS_Lambdaで始まっていること (言語別ランタイムの場合)

または

  • AWS_LAMBDA_RUNTIME_API が設定されていること (カスタムランタイムの場合)

Lambdaでは入出力はランタイム側で処理されますが、それ以外の環境では標準入出力を使えばよいでしょう。

簡単にやるためのライブラリを書いた

github.com

ということで、これを簡単にやるためのlamblocalというライブラリを書きました。実装を見ると分かりますが、本当にシンプルなものです。使用例は次の通りです。lambda.Start()の代わりにlamblocal.Run()を呼ぶだけです。

これで作ったバイナリは、Lambda上ではLambda関数として、そうでない環境では単体コマンドとして実行できます。

package main

import (
        "context"

        "github.com/aws/aws-lambda-go/events"
        "github.com/fujiwara/lamblocal"
)

func handler(ctx context.Context, payload events.CloudWatchEvent) (string, error) {
        return payload.ID, nil
}

func main() {
        lamblocal.Run(context.TODO(), handler)
}

handlerの第2引数(paload)は標準入力から受け付けた内容をJSONとして解釈して任意の型で渡せるようになっているので、型に応じた適当なJSONを喰わせてください。関数の出力は、任意の型をJSONとしてencodeして標準出力に出力されます。

$ echo '{"id":"xxx"}' | go run main.go
"xxx"

payloadがない関数(第2引数を _ にする)の場合は実行開始後、標準入力を閉じてください(端末からCtrl-Dを入力)。

// payloadがない関数
func handler(ctx context.Context, _ interface{}) (string, error) {
        return "OK", nil
}

なおlamblocal.Run()ジェネリクスを使っていて、func Run[T any, U any](ctx context.Context, fn func(context.Context, T) (U, error)) という型になっています。payloadと戻り値には任意の型(any)を扱えますが、jsonとしてUnmarshal/Marshalできる型であることを前提としています。

ハンドラとして渡せる関数のインターフェースは func(context.Context, any) (any, error) のみです。

lambda.Start()ではあらゆる型(interface{})を引数に取って実行時に型チェックを行う作りになっていて、ビルドはできていても実行できない関数を作ってしまうことが稀にありました。lamblocalでは型を絞ることでその可能性を減らしています。

設定値などの管理方法

Lambdaでは、環境変数で設定値などを渡すのが前提です。CLIでも同様に環境変数を使ってもよいのですが、コマンドライン引数として渡せると便利ですよね。

ここでは応用例として、alecthomas/kong というコマンドラインパーサーと組み合わせる例を紹介します。

kongでは、コマンドライン引数をstructとして定義し、structのタグでデフォルト値やどの環境変数から値を読み取るかを定義できます。

type CLI struct {
        Foo     string `help:"This is Foo." default:"foo" env:"FOO"`
}

このように定義すると、CLI.Fooの値は デフォルト値が foo環境変数 FOO=bar が設定されていれば barコマンドライン引数 --foo=baz が与えられた場合には baz、となります。つまり適当なデフォルト値を設定した上で、Lambda上で実行される場合は環境変数から、CLIとして実行する場合は引数から上書きできますし、その値が何かという説明も明示的にhelpとして記述できます。

環境変数のみで処理しようとすると得てしてコード内にos.Getenv()が散在したりしますが、このようにまとめておくことで設定値を適切に管理できますね。

具体的な例はリポジトリexamples/kongにありますが、次のようになります。

package main

import (
        "context"

        "github.com/alecthomas/kong"
        "github.com/fujiwara/lamblocal"
)

type CLI struct {
        Foo     string `help:"Foo." default:"foo" env:"FOO"`
}

func (c *CLI) Handler(ctx context.Context, _ interface{}) (string, error) {
         // c.Foo はデフォルト値、環境変数、コマンドライン引数から設定された状態になっている
        return "OK", nil
}

func main() {
        var c CLI
        kong.Parse(&c)
        lamblocal.Run(context.TODO(), c.Handler)
}

まとめ

GoでAWS Lambdaのハンドラを実装した場合に、手元から同じ処理を実行したり開発中の動作確認のため、CLIコマンドとしても実行できる、とてもシンプルなwrapperライブラリを書きました。

小物ですが便利なので、どうぞご利用ください。


  1. 確実にシングルバイナリにするためにCGO_ENABLED=0 も指定しましょう。ビルド環境がLinuxの場合、指定しないとlibcへの依存が発生するため、Lambdaに持っていったときにglibcのバージョンの差異で動かないことがあります。
  2. AWS Lambda 環境変数の使用 - AWS Lambda

YAPC::Kyoto 2023に参加しました #yapcjapan

blogを書くまでがYAPCということで、4年ぶりにオフライン開催されたhttps://yapcjapan.org/2023kyoto/:YAPC::Kyoto 2023に参加してきました。

YAPCは以前から年に1回の同窓会的な雰囲気があったのですが、今回は4年ぶりなので懐かしい顔がいっぱいでした。自分のようなベテランにはおなじみの顔だけではなく、初めての人も結構来ていたようで、コミュニティが世代を超えて広がっていく様子が感じられてよかったです。

自分の場合、参加したYAPCは喋ることのほうが多かったのですが、なんとなく若手に遠慮して(最近やったPerlネタもないし…)プロポーザルを出さなかったのはちょっと後悔しています。やっぱりカンファレンスは喋ってなんぼですからね。歳を取ってもまだまだ現役エンジニアなので、次はちゃんと出します。

カヤックブースではおみくじと絵馬を実施しました

聞いたトークとプチ感想

  • 小さく始め、長く続けるOSS開発と貢献
    • 人によってコードの個性というか味わいが違うみたいなの、ソムリエぽい
  • ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス
    • 普段はAmazon SQSを使ってるんですが、指定時刻発火できるjob queueがたまに欲しくて導入も楽そう(MySQLは既にシステムにあることが多い)なので使ってみようかな
  • ORM - Object-relational mapping
    • アーキテクチャの4分類から既存のシステムとORMを分析して導入するものを決める、導入の進め方も合理的なあたり流石
  • 日常業務のカイゼンで図る開発チームへの貢献
    • Q「改善点に気が付くためには」A「自分がイラッときたことをメモっておく」
  • あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで
    • 本人曰く「今までお世話になった人が後ろにいっぱいいて授業参観」
    • ベストトークおめでとうございます
  • qron: Cloud Native Cron Alternativeの今
    • いろいろわかりみが多かった話
    • 「OpenAPI微妙」「AWSのマネージドシステムを組み合わせて使うと同僚にも触ってもらいにくい」
    • ECSのところをLambda Function URLにしたらTerraform一発構築までいけないかな…?
  • デプロイ今昔物語 〜CGIからサーバーレスまで〜
    • デモがメイン。25年の歴史を一気に辿って現代まで来る様子がライブ感あってオフラインならでは
  • DNS権威サービスへのDDoSとハイパフォーマンスなベンチマーカ
    • 「Webアプリケーションなら攻撃を受けきりなさいと言われないけどDNSサーバーは言われる」つらい
    • ランダムなヒットしない名前の解決でバックエンドに負荷を掛けないために、Bloomfilterを使えたりしないかな (自分がぱっと思いつくぐらいのことなので検索したら当然見つかりました)
  • llsとcachectlから学ぶ、Goでシステムプログラミングをする方法
    • ファイルが多すぎてlsが返ってこないレベルのディレクトリ、それを乗り越えるのが技術力
  • 様々な環境へコマンドラインツールを提供する上での苦労とその対策
    • これがリアルワールド
    • 本体はGoで書いて、plugin機構は決まったフォーマットのstdin/stdoutで連携する外部コマンドを実行する方向はないかな?
  • LT
    • 悪いこと(語弊がある)を楽しそうにしている人がいた
  • キーノート
    • 世代が全く一緒なので懐かしさしかない…いい話でした

おまけ

京都滞在中の走行距離は26.5kmでした。

#yapcramen