どうもー、おはようございます。マイクです。
今日も始まりました「zenncast」。
二千二十六年八月三十一日、月曜日の朝七時を回りました。みなさん、いかがお過ごしでしょうか。

この時間は、Zennに上がっているトレンドの記事の中から、気になる技術ネタや開発の現場のお話を、ラジオ感覚でゆるっと、でも中身はみっちりお届けしていきます。

今日はお便りコーナーはお休みで、そのぶん記事紹介をたっぷりめにいきたいと思います。

さて、きょう紹介する記事は、全部で五本です。
テーマとしては、マイクロサービスの認可設計、業務システムのアーキテクチャ、メールのなりすまし対策、GPUの電力チューニング、それからAWSセキュリティ設計のお話まで、かなり濃いラインナップになってます。

それじゃあ一つずつ、じっくり見ていきましょう。

。。。。

まず一つ目。
マイクロサービス間での「認可」をどうやって安全に引き回すか、という話です。

マイクロサービスって、一つのユーザーのリクエストが、裏側ではいくつものサービスを経由して処理されますよね。
問題になるのが、「最初のサービスでは『このユーザーは見ていい』とちゃんと判定したのに、その結果が後ろのサービスまでちゃんと伝わらない」という点なんです。

どうなるかというと、途中にいるサービスから見ると、「このリクエスト、本当に正しく認可されてるの？」っていうのが、結局は前のサービスからの“自己申告”に頼るしかない、という状況になりがちなんですね。
セキュリティ的には、これはちょっと怖い。

そこで、いま IETF で検討されている「Transaction Tokens」という仕組みが登場します。
これは、呼び出し元ユーザーの情報とか、「何のための処理なのか」といったリクエストの内容を、一時的にだけ有効な、署名付きのJWTトークンに詰めてしまおう、というアイデアなんです。

各サービスは、このトークンを受け取ったら自分で検証します。
「ちゃんと署名されてるか」「有効期限は切れていないか」などを確認することで、「このリクエストの認可の文脈は、信用していいものだ」と判断できるようにしよう、というわけですね。

この記事では、バクラクというサービスが、同じ課題に対して「Capability Assertion」という独自のトークンを実装している事例も紹介されています。
こちらは、「どのサービスが、どのユーザーについて、どのリソースIDを“閲覧可能”と判定したか」という情報を、短い寿命のトークンとして発行し、後続のサービスがそれを検証する仕組みです。

共通する設計方針としては、
・認可の文脈を、その場しのぎの自己申告ではなく、署名付きトークンとしてちゃんと伝搬させること。
・有効期限を短くして、扱う範囲も絞ること。
・「誰か」を表す認証の情報とは分けて、「何ができるか」という認可結果だけを運ぶこと。
このあたりがポイントになっています。

違いとして面白いのは、Transaction Tokens の方は、「処理内容そのものが途中で改ざんされないようにする」ところまで狙っているのに対して、Capability Assertion の方は、「すでに閲覧許可が出ているリソースIDの参照」に用途をきっちり絞っている、というところです。
より汎用的にトランザクション全体を守りにいくのか、それとも閲覧許可の伝達にフォーカスするのか、アプローチの違いが分かりやすくまとまっている記事でした。

。。。。

続いて二つ目。
これは、建築業向けの社内ERPを、TanStack Start、Hono、oRPC、Cloudflare Workers、PostgreSQL といった構成でスクラッチ開発したときの、設計の工夫についてのお話です。
キーワードは、「どこに境界を引くか」で大規模業務システムの保守性をどう確保するか、ですね。

建築業のERPって、EVMみたいな複雑な業務計算がたくさん出てきます。
この記事では、そういった複雑な計算ロジックを、データベースやサーバーには依存しない「純粋関数」として、契約パッケージにまとめています。

これをどう使うかというと、サーバー側の集計処理と、フロントエンド側の表示処理で、同じ実装を共有するんですね。
そうすると、一覧画面経由で見る指標と、詳細画面で見る指標が微妙にズレてしまう、なんてことを防ぎやすくなります。
別々の経路で計算しているのに数字が合わない、というのは業務システムあるあるなので、ここを「同じ実装を使う」という設計でつぶしているのがポイントです。

さらに、APIの契約も oRPC と Zod を使って独立したパッケージに切り出しています。
DTO、つまりAPIでやり取りするデータの型と、データベースのスキーマを分けることで、「DBにはあるけどAPIには出さない列」を扱いやすくしています。
このおかげで、Honoで書かれたAPI実装のリファクタリングと、API仕様そのものの変更を、型のレベルで分けて管理できるようにしているんですね。

データベースの選定も工夫があります。
CloudflareのD一ではなく、PostgreSQLとHyperdriveを選んでいます。
理由は、書き込みの並行性や、「ここは直列で処理したい」といった部分的な直列処理を、アドバイザリーロックでコントロールしたかったから。
さらに面白いのは、Hyperdriveのバインディングを二本用意している点です。

一本は「正しさ重視の通常接続」。
もう一本は、集計系の処理にだけ効かせる「キャッシュ付き接続」。
これをパス単位で使い分けることで、データの正確さを崩さずに、集計処理をうまく高速化している、というわけです。

モジュール同士の依存関係についても、「一方向にだけ流れるようにする」というルールを設けていて、CIやLintツールでそのルール違反を自動検出しています。
設計ドキュメントを読む人の善意に頼るんじゃなくて、ツールで機械的にアーキテクチャを守る、という姿勢ですね。

そしてこの記事のオチが面白くて、こうやって「UIや人間の開発者にとって扱いやすい境界」を丁寧に整えていった結果、そのまま Cloudflare Workers 上のAIエージェントの実装にも再利用できた、という話が出てきます。
Flue と Service Binding を使って、AIエージェントにERPを読ませるときも、新たなデータアクセス層を増やさずに済んだ。
AI時代においても、「境界の引き方」をちゃんと考えた設計が効いてくる、というのが印象的な事例でした。

。。。。

三つ目は、一気にテーマが変わって、メールのなりすまし対策のお話です。
出てくるのは、SPF、DKIM、DMARC という三つの仕組みですね。
名前は聞いたことあるけど、役割の違いがごちゃっとしている方も多いと思うので、それを整理してくれている記事です。

まず SPF。
これは、「このドメインのメールは、どのメールサーバーから送っていいのか」を、DNSに書いておく仕組みです。
受信側のサーバーは、メールを受け取ったときに、「この送信元サーバーは、DNS上でちゃんと許可されているか？」というのをチェックします。
つまり、SPFは「どこから送ったか」、送信元サーバーの正当性を見る仕組みなんですね。

次に DKIM。
こちらは、メールの本文やヘッダー情報に対して、送信側が秘密鍵でデジタル署名をします。
受信側は、DNSに公開されている公開鍵を取りにいって、その署名が正しいかを検証します。
これによって、「送ったあとに、内容が途中で書き換えられていないか？」を確認できる。
SPFが送信元サーバーを見ていたのに対して、DKIMは「メールそのもの」を見る仕組みです。

そして DMARC。
これは、「SPFやDKIMのチェックに失敗したメールをどう扱うか」を、ドメイン管理者側から宣言するための仕組みです。
たとえば、「何もしない」「迷惑メールとして扱う」「受信を拒否する」といった方針をDNSに書いておいて、受信側に伝えることができます。
さらに、表示上のFromドメインと、SPFやDKIMで確認したドメインがちゃんと一致しているかもチェックする、という役割があります。

まとめると、
・どこから送ったかを見るのが SPF。
・内容が改ざんされていないかを見るのが DKIM。
・チェックに失敗したとき、どうするかを決めるのが DMARC。

それぞれ別々の役目を持っていて、この三つをセットでちゃんと設定して、初めて「なりすましメール対策」として強く機能するんだ、ということが分かりやすく解説されていました。

。。。。

四つ目は、ハードウェア寄りの話題です。
最近の高性能GPU、特にRTX 五〇九〇クラスになってくると、発熱も消費電力もとんでもないレベルですよね。
寿命への影響とか、電源への負荷も気になるところです。

この記事では、そのRTX 五〇九〇の電力上限、いわゆるパワーリミットを、デフォルトの五百七十五ワットから、四百ワットまで下げたらどうなるか、という検証がされています。
対象は八種類の実タスクで、性能、消費電力、温度がどう変わるかを細かく計測しているのが特徴です。

結果として、パワーリミットを四百ワットに落としても、多くの学習系、画像生成系のタスクでは、性能低下はだいたい七パーセントから十一パーセントくらいに収まったそうです。
さらに、LLMの推論や XGBoost といったタスクでは、ほとんど性能が落ちない、という結果も出ています。

その一方で、ジョブ一回あたりに消費する電力量は、最大で二十三パーセント減少。
GPU内部でいちばん熱くなる「ホットスポット」の温度は、十四度も下がっています。
加えて、瞬間的な電力の揺れ、いわゆるスパイクも半分くらいになるなど、電力効率と温度、そして結果的に寿命の面でも、大きなメリットが確認された、ということです。

ただし注意点もあって、VRAM、つまりビデオメモリの温度は、電力制限だけではほとんど下がらないんですね。
コア側が冷えてファンの回転数が落ちるぶん、相対的にはVRAMが熱くなりやすい。
なので、「VRAMを守りたい」という観点では、パワーリミットを下げるだけじゃ足りなくて、ファン設定を少し強めに振る必要がある、と指摘されています。

全体の結論としては、「とにかく一秒でも早く終わらせたい」という時間最優先のケースを除けば、RTX 五〇九〇は四百から四百五十ワットくらいで運用するのが、性能と電力、そして温度のバランス的に現実的じゃないか、という話でした。
GPUの運用コストやデータセンターの安定運用を考えている方には、かなり参考になりそうな内容ですね。

。。。。

そして五つ目。
最後は、AWSセキュリティ設計の実践例です。
大手製造業向けのSaaSを提供している、小規模なスタートアップの事例なんですが、顧客からの厳しい要件に応えるために、どういうセキュリティの仕組みを作ったのか、というのが詳しくまとまっています。

まずログイン周り。
基本のログインは社内のアイディーピー経由で行いますが、本当に強い権限を使いたいときには、いきなりフル権限を渡さないようにしています。
具体的には、Slackから申請して、かつ時間制限付きで権限を付与することで、「一つの認証突破だけでは、いきなりフル権限を取られない」ように、仕組みを二重化しているんですね。

AWSアカウントの構成も、用途ごとに分かれています。
管理用、ログ保管用、セキュリティ監視用、そして実際のワークロード用、といった形でアカウントを分離。
CloudTrail や Config は全アカウントで有効化して、ログはS三のオブジェクトロックや、サービスコントロールポリシーを使って、「消せないログ」として集中管理しています。

GuardDuty や Security Hub といった検知系サービスのアラートは、専用のアカウントに集約。
さらに、重要度に応じてSlackの通知を分けることで、運用担当者がアラートに疲れてしまわないようにしています。
ただ鳴らすだけじゃなくて、「運用として回せるか」という視点が入っているのが実践的ですね。

非常時用には、「Break Glass」用のIAMユーザーも用意されています。
これはアイディーピーに依存しない、いざというときのバックドア的なアカウントですが、使われたら即通知が飛ぶようになっていて、MFAも必須。
逆に、ルートアカウントは通常は封印しておいて、集中管理の機能を使って普段は触れないようにしています。

そして全体の構成は、Terraformでコードとして管理しています。
権限設定、監視の有効化、ログの保全といった仕組みが、自動で各アカウントに適用されるようにしておくことで、少人数のチームでも、人力でのチェックに頼らずにセキュリティを維持できるようにする。
まさに「仕組みで守る」ことを目指した設計になっていました。

。。。。

というわけで、きょうの「zenncast」、駆け足で振り返っていきます。

まず一つ目では、マイクロサービス間で認可の文脈をどう安全に引き回すかということで、IETFのTransaction Tokensと、バクラクのCapability Assertionを紹介しました。
二つ目は、建築業向けERPを TanStack Start や Hono、PostgreSQL などで作った事例から、「どこに境界を引くか」で保守性を高める設計と、その結果AIエージェントにも流用できた、というお話。
三つ目は、SPF、DKIM、DMARCそれぞれの役割を整理しながら、「どこから送ったか」「内容が改ざんされていないか」「失敗時にどう扱うか」をセットで考える、メールのなりすまし対策の話でした。
四つ目は、RTX 五〇九〇の電力上限を四百ワットに下げたときの性能と温度の変化を実測したレポート。七から十一パーセントの性能低下で、電力と温度が大きく改善した一方、VRAMは別途ケアが必要、というポイントがありましたね。
そして最後五つ目は、大手製造業向けSaaSのスタートアップが、アカウントの分離、ログの保全、Break Glassアカウント、Terraformによるコード化で、「少人数でも運用可能なAWSセキュリティ」を作っている、というお話でした。

気になる記事があれば、このあとショーノートに詳しい情報を載せておくので、ぜひチェックしてみてください。

この番組「zenncast」では、感想や質問もいつでも募集しています。
「こんなテーマを扱ってほしい」「ここもっと詳しく聞きたい」などなど、気軽にメッセージを送っていただけると、マイクがとても喜びます。

それでは、そろそろお時間です。
お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。
きょうも良い一日をお過ごしください。