Also available in: English

Aurora DSQL が re:Invent 2024 で披露されてから 1.5 年程度たちました。DynamoDB 程度の手軽さで SQL を喋る RDBMS が利用できる上に、DynamoDB を含む purpose-built databases にありがちな設計の難しさがない、という点でかなり便利なデータベースサービスになっています。ただ、それだけ経つのにまだあまり世の中に事例が出回っていません。

それもそのはず、SQL は喋れるものの、そのランタイムの手軽さを実現するために vanilla な PostgreSQL とは異なり、より DynamoDB のようなデータベースに近い挙動で提供されていて、それがトレードオフとして存在します。別の言い方をすると PostgreSQL とはあくまでプロトコル互換であって、挙動まで互換ではありません。その関係で既存の PostgreSQL アプリケーションをそのまま移行しづらい点がネックとなっている気がしています。その点においては Neon のような他の PostgreSQL 互換サーバーレス DB の方が、価格モデルが異なるものの有利と言えます。

本稿では実際に Rails で Aurora DSQL をデータベースとして採用し、昨年末から新規にシステムを開発してきた中で、現状の困難なポイントと対処方法を紹介します。

GitHub Actions などで ID token を取ってきてクラウドにログインさせる, package の trusted publishing をする, というのは一般的になってきた。多くは Workload Identity Federation などと呼ばれ、近年はついに AWS も公式で ID token の発行をサポートするようになったし、各種クラウドプロバイダで受入れおよび払出しにだいたい対応しきったといって良いんじゃないだろうか。

GitHub Actions で利用する例は世の中に溢れているが、たとえば AWS や Google Cloud 間での利用や、Terraform での設定方法などはあんまりまとまっていない印象がある。そのため本稿では自分の身の回りで必要な、ID token をベースとしたクラウドプロバイダ間の ID フェデレーション方法、特にそれぞれのクラウドプロバイダでの概念、受け入れや発行に必要な Terraform での設定、また使い方についてまとめてみる。

Rack で利用できる汎用認証ミドルウェアである OmniAuth を活用した OAuth 2 認可サーバー & OIDC ID プロバイダ sorah/himari を結構前に作った。今回 MCP サーバーの認証を作る機会があり Himari からアクセストークンを出すことにしたため、MCP で必要な機能を追加で Himari へ実装したのでそれを紹介する。

Jxck に声をかけてもらって様々な技術カンファレンス主催者たちで執筆した「カンファレンス開催ノウハウ」が公開されました。

• 「カンファレンス開催ノウハウ」を公開します | blog.jxck.io

100% 執筆したのは Wi-Fi の章、あといくつかの章でもわたしの文章がちらほらと入っています。特定カンファレンスでの経験にバイアスがかかった話ではありますが基本的には私見です。どうぞご活用ください。