Infrastructure カテゴリ | フューチャー技術ブログ

非機能テストを記号接地する

2026-06-16T15:00:00.000Z

テスト連載2026 の3本目です。

はじめに

TIG（Technology Innovation Group）の清水です。

あなた今回非機能テストやってみない？と言われた。けどそれってなんだっけ、という人向けの記事です。「非機能テスト」と聞いてなんとなくイメージが浮かぶようになる、が記事の目標です。

そもそも　【非機能】　が分かりにくい

【非機能】という単語がそもそも分かりにくいです。

「キノウではナイもの」。なんだそれは。

絵だとこうです。うーむ分からん。

非機能は【構造】と捉えると分かりやすいです。

機能（サービス）を支える構造、ですね。

絵はこうです。さっきより多少いいでしょうか。

でも具体、のイメージはまだつきにくいです。

門限が決まっている　→ 性能要件

映画館の【券売機】を例に考えます。

予定時刻で映画が始まってしまう。

開始5分前に50人来て購入・発券するなら、1分あたり10人を捌く必要がある。券売機が2台なら、1台はその半分捌ければ良いです。

業務 門限から考えて、どれくらいのスピードが必要か です。

映画を楽しんでもらう・また来ようと思ってもらう を頂点として、券売機に求められる性能要件は何か、ですね。

本当の映画館では、ポップコーンを買ったりトイレに行ったりの時間もあります。始まるといっても予告編があり、人の流量をどう見立てるかが重要です。家族なら人数分まとめて発券するでしょう。web予約側は20分前締め切り・劇場では開始直前まで、という条件もあります。映画館によっては上映開始後でも購入可能で、考え方の違いが門限に現れています。1人でぽっかり時間空いた・映画見るぞというとき、上映開始後に購入できると確かに嬉しいです。

券売機の要求を処理するシステム側から考えるとき、日本全国で100館・1館に5台券売機があるなら、500台の券売機が同時要求してきます。お客さんから券売機いくらなんでも遅すぎだろと思われると、次は違う映画館に行ってしまうかも知れません。それより前に現場が混乱します。あーまた、とニュースになるでしょう。目も当てられません。ということで機能と非機能を絵にします。

非機能

ここではスピードを取り上げました。性能ですね。

空席確認から発券までに2時間かかったら、お客さんは違う映画館に行ってしまうでしょう。頑張って作った機能が全て台無しです。映画を楽しんでもらう・また来ようと思ってもらうというそもそもの話が、吹き飛んでしまいます。

非機能で転んで全てが台無しになるケースのイメージです。では何秒だったらOKなのか。処理量、同時性、画面フレームワーク特性、ネットワーク構成、排他制御、選択した各処理方式等含めて限界がある中で、経済合理性とバランスが取れ、構築期間を守ることができ、映画を楽しんでもらうを実現できるところが、目的地です。

応答が遅いと怒られる

「門限までに全部処理して！」以外に、画面レスポンスが遅くて怒られる、もあります。空席表示に10秒かかったら、まず「壊れてるな」と連打されます。普段みんなが使っているスマホアプリとの体感勝負になりやすいです。あまりに高性能を求めると、実現可能性に黄色信号が点るのと合わせて、費用にはねてきます。

一度にお客がいっぱいやってくる

人気アイドルグループの最終ツアー、となるとチケットサイトには一度に大勢のファンが押しかけます。想定を超えた要求がやってくると、システムはスローダウンし挙動が不安定になります。このような性質のシステムでは、性能破綻しないように流量制御機構を配備します。流量に合わせてシステムリソースを拡張する方式を採るケースもあります。「あなたは何番目」を見えるようにし、お客さんのイライラを鎮める工夫もするでしょう。あまりに大きな非機能（性能）要件から、新しい機能・アーキテクチャが必要になるケースです。全体が破綻しないように、システム挙動をいかに想定内・テスト範囲内に収めるか、が重要です。

全公演満席になるほどの人気グループであれば、チケットサイトが一時期ダウンしても、割当枚数は復旧後に販売できます。しかしサイト全体が重くなることで、他のコンサートや美術館チケットを買おうとしていたユーザーは競合サイトに流れるでしょう。流量制御機構を配備することで回避できます。

テストする

非機能要件定義で「この機能群を、こんなふうに支えてほしい」を確定します。その通りに動くかを、実際にやって証明するのが【非機能テスト】です。
ただ最後の最後にそもそもこれって。。。となると収拾がつかなくなります。このアーキテクチャで非機能要件が達成できるか、はアーキテクチャ決定時に確認する必要があります。これははじめての性能テストにも記載されています。

サービスに必要な非機能 = 機能を支える構造、は性能だけではありません。
代表的なものを普通のことばで表現するとこうです。

どれくらいのスピードを出したいか？
どれくらい伸縮させたいか？
どれくらいの止まりにくさにしたいか？
5年間サービス維持できそうか？
どれくらいの耐攻撃性にしたいか？

テストについて言えることがあります。

「その条件で 動かしたなら大丈夫」
「動かしていないなら、いざという時に動かなくても不思議はない」

そして非機能で転ぶと「特定機能の停止」にとどまらない全滅がありえます。熟慮し先を見ながら進めたいですね。

おわりに

非機能テストってなんだっけ、という方がなんとなくイメージを持てるように、記事を書きました。なんとなくイメージついたかも。。？という方は是非一歩踏み出してください。

すでに、ガイドライン公開したよ記事＆ ガイドライン本体が公開されています！

はじめての性能テストを公開しました
はじめての性能テスト

RFC 7807 から RFC 9457 で Web API のエラー表現で変わったこと

2026-06-10T15:00:00.000Z

はじめに

TIG（Technology Innovation Group）の真野です。

HTTP API のエラーレスポンスを標準化する仕様、RFC 7807 “Problem Details for HTTP APIs” は 2016 年 3 月に公開され、以降 Web API のエラー表現のデファクトとして広く参照されてきました。その RFC 7807 ですが、約 7 年後の 2023 年 7 月に RFC 9457 に置き換えられていたのはご存知でしょうか。

RFC 9457 は後方互換で、差分は思ったより少ないのです。それでも「何が変わって、なぜ変わったのか」を押さえておくと、これから Web API のエラー設計をする際に判断しやすくなるでしょう。本記事では両 RFC の概要と差分、そして今後の設計指針を整理します。

RFC 7807: Problem Details の標準化 (2016年)

RFC 7807 は 2016年3月に公開された Proposed Standard です。

API ごとにエラーの表現方法がバラバラで、クライアント側が毎回パース方法を変える必要があるという悩みを解決するために作られました。RFC 7807 は以下の 5 つのメンバと、application/problem+json というメディアタイプを定義しています。

メンバ	役割
`type`	問題の種類を識別する URI
`title`	人間向けの短い要約
`status`	HTTP ステータスコード
`detail`	問題の詳細説明
`instance`	特定の発生インスタンスを示す URI

サンプルとして、2 歳になる我が子に「早くお風呂に入ろう」とリクエストしたところ、「今はおもちゃで遊びたい」と 400 エラーで返された状況を problem details で表現してみます。なお、RFC 原文のサンプルは「残高不足」を扱っています。

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Language: ja

{
  "type": "https://example.com/probs/busy-with-toys",
  "title": "今はお風呂に入れません。",
  "detail": "今はおもちゃで遊びたい気分なので、もう少し待ってください。",
  "instance": "/children/myson/bath-requests/20260420-0730",
  "status": 400
}

この「共通フォーマットで機械可読なエラーを返す」というアイデアは普及し、多くのフレームワーク・ライブラリが対応しました。

RFC 7807 原文
日本語訳

RFC 9457: 7807 を置き換える改訂版 (2023年)

RFC 9457 は 2023年7月に公開された Proposed Standard です。RFC 7807 を obsolete（廃止）する位置づけになっています。

Abstract にはこう書かれています。

This document defines a “problem detail” to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807.
(Google翻訳)
この文書は、HTTP API 用の新しいエラー応答フォーマットを定義する必要性を回避するために、HTTP レスポンスコンテンツにエラーの機械可読な詳細情報を含めるための「問題の詳細」を定義します。この文書は RFC 7807 を廃止します。

「新しいフォーマットを定義するものではない」と明記されており、つまりフォーマットは 7807 と同じです。 完全な後方互換性が保たれている ため、7807 に準拠して実装したレスポンスはそのまま 9457 準拠として有効です。

RFC 9457 原文
日本語訳

変更点

RFC 9457 の Appendix D “Changes from RFC 7807” が挙げる変更点は3点です。

Section 4.2 で、共通の問題型 URI を登録する IANA レジストリを新設した
Section 3 で、複数の問題をどう扱うべきかを明確化した
Section 3.1.1 で、デリファレンスできない type URI の使用に関するガイダンスを追加した

加えて Section 5 の Security Considerations もやや強化されています。新しいフィールドの追加や、既存フィールドの削除は一切ありません。

改善点①: `type` URI のガイダンス明確化

7807 時代の課題

RFC 7807 は「type URI はデリファレンス可能である必要はない」と書いていました。しかし実装者からすると、

相対 URI を使ってよいのか？
存在しない URI を書いてよいのか？
人間向けのドキュメントはどこに置けばいいのか？

といった具体的な判断材料が不足しており、迷いやすい状態でした。結果として、各社で運用がバラけたわけです。

9457 での改善

RFC 9457 の Section 3.1.1 は以下の点を明確化しました。

type はあくまで識別子であり、HTTP で取得できなくてもよい
可能ならその URI に人間向けの説明（HTML）を置くことが望ましい
型固有の拡張メンバの仕様は、別途ドキュメント化すべき

これで、社内向け API で相対 URI や URN を type に使う設計が、公式にお墨付きを得た形です。

具体例

子どもが夕食前に「ゼリーを食べたい」とリクエストしたものの、「夕食前のおやつはダメ」ルールで却下された、というケースを例に見てみます。

❌ Before (7807 時代): 絶対 URI でないと不安で、存在しない URL をわざわざ書く。

{
  "type": "https://api.example.com/problems/snack-before-dinner",
  "title": "夕食前のおやつは食べられません",
  "detail": "夕食まであと 30 分です。ゼリーは夕食の後に食べましょう。",
  "status": 422
}

この URL を開いても 404 なのですが、それでも「絶対 URI にしておけば安全かな」と書きがちでした。

✅ After (9457): 相対 URI や URN を堂々と使える

{
  "type": "/problems/snack-before-dinner",
  "title": "夕食前のおやつは食べられません",
  "detail": "夕食まであと 30 分です。ゼリーは夕食の後に食べましょう。",
  "status": 422
}

URN でも OK です。

{
  "type": "urn:example:problems:snack-before-dinner",
  "title": "夕食前のおやつは食べられません",
  "detail": "夕食まであと 30 分です。ゼリーは夕食の後に食べましょう。",
  "status": 422
}

備考

「どんなドキュメントを、どこに、どの形式で置くか」まで踏み込んだ指針は RFC には書かれていません。そこは各組織の設計判断に委ねられています。

改善点②: 複数エラーの扱い

7807 時代の課題

フォームバリデーションのように「複数の問題を同時に返したい」場面に対する指針が、RFC 7807 にはありませんでした。結果、各フレームワーク・各社が独自拡張を持つことになりました。

Spring の invalid-params
JSON API 系の errors
独自の violations / issues など

命名も構造もバラバラで、相互運用性が弱かったわけです。

9457 での改善

RFC 9457 の Section 3 が、まず次の方針を示しました。

When a problem in an HTTP response has multiple problems, it is RECOMMENDED that a single problem be chosen to represent the response, preferring the most relevant or urgent problem.
(Google翻訳)
HTTPレスポンスに複数の問題が含まれている場合、レスポンスを代表する問題として、最も関連性が高い、または緊急性の高い問題を優先して選択することが推奨されます。

レスポンス全体としては単一の problem details を選ぶのが推奨、という方針です。そのうえで、関連する複数の問題を伝えたい場合は拡張メンバに含めればよいとし、Section 3.2 で errors 配列を拡張メンバの例として具体的に示しています。

朝の幼稚園準備で、検温忘れ・水筒が空・連絡帳未記入、名札がない靴下の利用という 4つのミスが一度に検出された、というケースを例にしてみます。

✅️具体例

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Language: ja

{
  "type": "/problems/kindergarten-preparation-failed",
  "title": "幼稚園の持ち物に不備があります",
  "errors": [
    { "detail": "朝の検温がまだ終わっていません", "pointer": "#/healthCheck/temperature" },
    { "detail": "水筒が空のままです", "pointer": "#/items/waterBottle" },
    { "detail": "連絡帳の家庭欄が未記入です", "pointer": "#/items/communicationNotebook" },
    { "detail": "名札がついていない靴下を履いています", "pointer": "#/clothing/socks" }
  ]
}

備考

ただし、errors 配列は規範化されているわけではなく、あくまで例示です。位置指定の手段（JSON Pointer か JSONPath か独自キー名か）も自由で、依然として実装者の裁量は広く残っています。

改善点③: 共通型レジストリの新設

7807 時代の課題

「Rate Limit 超過」「Quota 超過」のような、どの API でも共通で使えそうなエラー型でさえ、各社が独自の URI を定義していました。再利用と収束のための仕組みが仕様側になかったわけです。

9457 での改善

RFC 9457 の Section 4.2 で IANA に HTTP Problem Types レジストリが新設されました。登録テンプレートには以下の項目を含めます。

Type URI
Title
Recommended HTTP status code
Reference

登録方法

登録ポリシーは Specification Required で、RFC 8126 Section 4.6 に基づきます。簡単に言うと以下です。

登録したい問題型の仕様書（公開された安定したドキュメント）を用意する
上記テンプレートの項目を埋めて IANA に申請する
Designated Expert がレビューして承認・却下を判断する
審査では「定義の明確性」「RFC 9457 の要件適合性」「コミュニティからのフィードバック」が考慮される

ベンダー固有・アプリケーション固有・デプロイ固有の値は登録不可とされており、広く再利用できる共通型だけが対象です。

プレフィックスとして https://iana.org/assignments/http-problem-types# を使うことも可能ですが、RFC 自身も「この URI は解決可能でない場合がある」と書いており、あくまで識別子として使う位置づけです。

例示

子どもが 1 分間に 20 回「おかし食べたい」と連投してくる状況を想定します。API としては HTTP 共通の 429 Too Many Requests を返したいところですが、同じ 429 エラーでも実装ごとに type URI の付け方はバラバラでした。

❌ Before (7807 時代): 共通のエラーでも実装ごとに独自 URI を定義していた。

{
  "type": "https://a-family.example/problems/too-many-snack-requests",
  "title": "Too Many Requests",
  "status": 429
}

{
  "type": "https://b-family.example/problems/snack-request-cooldown",
  "title": "Too Many Requests",
  "status": 429
}

{
  "type": "urn:c-family:problems:snack-quota-exceeded",
  "title": "Too Many Requests",
  "status": 429
}

✅ After (9457): 共通型を IANA レジストリで共有できる仕組みが整った。

現状は about:blank のみ登録済みで、型に特別な意味を持たせない場合の標準値として使います。

{
  "type": "about:blank",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "おやつの要求が多すぎます。30 分後にまた声をかけてください。"
}

将来的に Rate Limit 超過のような汎用エラー型が IANA に登録されれば、複数の API 間で type を共通化できるようになるというのがレジストリ新設の狙いになります。

備考

2026年4月時点のレジストリに登録されているのは 3 件です。about:blank に加えて、https://iana.org/assignments/http-problem-types#date と #ohttp-key がありますが、後者 2 つはいずれも RFC 9458 Oblivious HTTP 由来で登録されたものです。汎用的な業務エラー型（Rate Limit 超過、バリデーションエラー等）が登録されているわけではありません。

改善点④: Security Considerations の補強

7807 時代の課題

RFC 7807 にもセキュリティ上の注意書きはありましたが、具体性に欠けていました。結果、detail フィールドにスタックトレースや内部パスがそのまま載る実装が散見される状態でした。

9457 での改善

RFC 9457 の Section 5 はより踏み込んだ記述になっています。

スタックダンプ・内部実装詳細の露出を避ける
instance に不透明でない（デバッグ性のある）URL を置くと、情報漏洩経路になりうる
クライアントは信頼できないソースから来た problem details を、安易にそのまま表示しない（XSS 観点）

具体例

冒頭のお風呂サンプルを引きずって、「子どもがお風呂に持ち込むおもちゃが電池式だったので業務ルールで弾いた」ケースをイメージしてみます。

❌ Before (悪い例): detail にスタックトレースをそのまま載せる。

{
  "type": "/errors/bath-preparation-failed",
  "title": "Bath preparation failed",
  "detail": "com.example.bathtime.exception.ToyNotWaterproofException: Battery-powered toy cannot be brought into the bathroom\n  at com.example.bathtime.validator.ToyWaterSafetyValidator.validate(ToyWaterSafetyValidator.java:58)\n  at com.example.bathtime.service.BathPreparationService.validateItems(BathPreparationService.java:34)\n  at com.example.bathtime.service.BathPreparationService.prepare(BathPreparationService.java:21)\n  at com.example.bathtime.controller.BathController.startBath(BathController.java:19)",
  "status": 422
}

パッケージ構成・例外クラス名・内部バリデータ構造まで透けて見えるため、攻撃者の下調べに使われかねません。

✅ After (良い例): 利用者向けは業務的な説明にとどめ、相関 ID で運用側から追跡可能にする。

{
  "type": "/errors/toy-not-waterproof",
  "title": "このおもちゃはお風呂に持ち込めません",
  "detail": "電池で動くおもちゃはお風呂場に持ち込めません。別のおもちゃを選んでください。",
  "instance": "/errors/trace/a1b2c3d4e5f6",
  "status": 422
}

instance には不透明な相関 ID（トレース ID 等）だけを入れ、サーバ側のログと突き合わせればデバッグできる運用にしておくのが定石です。

備考

「どこまで出してよいか」の線引きは、公開 API（B2C）か社内 API かで大きく変わります。最終的には設計者が文脈を踏まえて判断するしかなく、RFC としては「気をつけろ」以上のことは書けないものと思います。

フューチャーの Web API 設計ガイドラインでの扱い

私がフューチャーの Web API 設計ガイドラインの執筆に関わった関係で、ガイドライン側との対応関係にも触れておきます。

ガイドラインではエラーレスポンスを RFC 9457 準拠で推奨しており、主な整合点は以下の通りです。

type は相対パス URI を推奨（9457 Section 3.1.1 の「デリファレンス不可でよい」ガイダンスに相当）
複数エラーは errors 配列で表現し、件数が 1 件でも配列形式で統一
errors[].detail を必須、pointer を任意とする
エラー時の Content-Type は application/problem+json を推奨
B2C 公開 API では詳細情報を控え、内部 API では詳細を許容（9457 Section 5 Security Considerations と整合）

興味ある方は、ぜひガイドライン本体も読んでみてください。

まとめ

RFC 7807 から RFC 9457 で変わったことは、フォーマットとしてはゼロに等しく、本質的には「実務で迷いやすかった部分のガイダンスが整理された」という位置づけのアップデートです。

新規の Web API 設計では、まず RFC 9457 を読み、application/problem+json を返すところから始めれば良いと思いました。差分が少ないこと自体が、この仕様がもう十分に枯れていることを示しているようで、個人的には読んでいて心地よい RFC の更新でした。

はじめての性能テストを公開しました

2026-06-09T15:00:00.000Z

はじめに

TIG（Technology Innovation Group）の武田です。

はじめての性能テストという性能テストの入門ガイドラインを作成し、公開しました。
https://future-architect.github.io/arch-guidelines/documents/forPerformanceTest/performance_test.html

本ガイドラインは、性能テストの計画から実行、分析に至るまでの実践的なプロセスを一通りまとめたものとなります。次のような方を主な読み手として想定しています。

性能テストの経験がなく、何から手をつければよいかわからない方
これまでなんとなく性能テストを実施してきたが、考え方を体系的に整理したい方

ガイドライン作成のモチベーション

まずはじめに、性能テストは難しいです。私が難しいと考える理由は次の3点です。

技術的な視野の広さ
フロントエンドから、バックエンドアプリケーション、ミドルウェア、データベース、そしてインフラまで、システムの全体を捉えて性能を見ていく必要があります。性能目標を達成できないときに、どこにボトルネックがあるのか「あたり」をつけ、クイックに原因特定から改善まで進めるには、特定の技術領域に偏らない幅広い知識と視野が欠かせません。
業務ドメインの理解
テストシナリオやデータパターンは、技術だけで決められるものではありません。対象システムがどのように使われ、いつアクセスが集中するのかといった、ビジネスコンテキストを理解したうえで初めて定義できるものです。
多くの関係者の調整
性能テストは巻き込むべき関係者が多くなります。アプリケーションやインフラの開発者はもちろん、目標値や完了基準を合意するビジネスサイドの方々、テスト環境やクラウドの利用申請に関わる方々など、多くの人を巻き込みながら調整を進めるコミュニケーションが求められます。

こうした難しさゆえに、性能テストを計画段階からリードできる人は、どうしても一部のベテラン勢に限られてしまいがちです。経験則や暗黙知に支えられている部分も大きく、性能テストの経験が浅い若手やミドル層がリードするにはハードルが高いのが現状でした。

本ガイドラインは、こうした状況を少しでも変えたいという思いから作成しました。
性能テストの考え方や進め方を体系化することで、性能テスト未経験のエンジニアでも、計画からレポーティングまでを自信を持って推進できるようになることを目指しています。

ガイドラインのポイント紹介

全体としては、まず性能テストの前提となる知識（分類や性能指標などの考え方）を説明したうえで、計画 → 準備 → 実行 → チューニング → レポーティングという一連のステップに分けて論点や進め方を解説する構成になっています。

ここでは、その中でも特に重要なポイントをいくつか紹介します。

性能テストの分類

性能テストという言葉は解釈の揺れが大きく、負荷テストと同義に使われることもあれば、別物として区別されることもあります。本ガイドラインでは、性能に関するあらゆるテストを包括する概念として「性能テスト」を捉えたうえで、実施条件と目的に応じて5つに分類しています。

---
config:
  theme: neutral
  layout: dagre
  look: handDrawn
  flowchart:
    htmlLabels: true
    nodeSpacing: 30
    rankSpacing: 50
---
flowchart TB
    classDef nodeLabel min-width:240px;

    Root["性能テスト"]

    subgraph Layer2 [" "]
      direction LR
      Data["データ量・サイズに焦点"]
      Load["アクセス数に焦点"]
      Time["稼働時間に焦点"]
    end

    subgraph Layer3 [" "]
      direction LR
      Normal["想定内（通常・ピーク）の負荷"]
      Over["想定以上の限界負荷"]
      Sudden["突発的・大規模な負荷"]
    end

    subgraph Layer4 [" "]
      direction LR
      Volume["ボリュームテスト"]
      Rush["ラッシュテスト"]
      Stress["ストレステスト"]
      Spike["スパイクテスト"]
      Long["ロングランテスト"]
    end

    Root --> Data
    Root --> Load
    Root --> Time

    Data --> Volume
    Load --> Normal & Over & Sudden
    Time --> Long

    Normal --> Rush
    Over --> Stress
    Sudden --> Spike

    style Layer2 fill:none,stroke:none
    style Layer3 fill:none,stroke:none
    style Layer4 fill:none,stroke:none

性能目標の定め方

性能テストの大前提として性能要件をどう定めるかという点が重要です。本ガイドラインでは「スループット」「処理時間」「リソース使用率」のそれぞれについて、目標値の決め方を手厚く扱いました。

例えば処理時間については、目標値を平均値や最大値ではなくパーセンタイル値（例. 95パーセンタイルで500ms以内）として定義する理由を説明しています。あわせて、既存システムをベースラインとするアプローチや、TTFBのような業界標準の指標、IPAの非機能要求グレードを参考にした目標値の設定例まで、現場でそのまま使える形に落とし込んでいます。

性能テストの段取り

複数の種別をやみくもに実施するのではなく、ボリュームテスト → ラッシュテスト → ロングランテスト → ストレステストと観点を段階的に広げていく進め方を推奨しています。

テストの観点を「データ量」から「データ量 × 同時アクセス数」、そして「データ量 × 同時アクセス数 × 継続稼働時間」へと段階的に変化させていくことで、効率よくテストを積み上げられます。各テストには目的に対応した完了基準を定めており、「どうなったら次に進んでよいのか」がわかるようにしています。

テストツールの選定

負荷ツールやモニタリングツールの選び方も解説しています。負荷ツールについては、JMeter・k6・Gatling・Vegeta・AWS Distributed Load Testingといった代表的なツールを記述方法・実行効率・分散構成対応・習熟コストなどの観点で比較しました。

そのうえで、本ガイドラインでは k6 を推奨しています。テストをJavaScriptのコードとして書けるためバージョン管理やCI/CD連携と相性がよく、Go言語製で負荷生成の効率が高いことが主な理由です。

	JMeter	k6	Gatling	Vegeta	AWS DLT
説明	Java製OSS負荷テストツール - 多機能で利用実績も多い	Go製OSS負荷テストツール - 省リソース、JSで記述しCI/CD統合に優れる	Scala製OSS負荷テストツール - コードで記述、HTMLレポートがリッチ	Go製OSS CLI負荷テストツール- HTTP特化、シンプルで手軽だが機能は限定的	AWSの分散負荷テストサービス - AWS上で大規模・サーバレス実行を自動化
記述方法	XML （GUIで生成）	JavaScript	Scala/Java/JavaScriptなど	設定ファイル/CLI引数	JMeter/k6/Locustに対応
GUI	あり	なし	なし	なし	あり
プロトコル	✅️ HTTP/SOAP/JDBCなど多数（拡張可）	⚠️ HTTP/WebSocket/gRPCなど（拡張可）	⚠️HTTP/WebSocket/gRPCなど（拡張可）	❌️ HTTP特化	✅️ 多くのプロトコルに対応
実行効率	⚠️ 低（OSスレッドベース）	✅️ 高	✅️ 高	✅️ 高	✅️高
シナリオ準備	✅️ GUI記録機能あり、直感的	✅️ コード記述、har-to-k6等あり	✅️ コード記述、レコーダーあり	✅️ 非常にシンプルな設定	✅️ JMeter・k6・Locustに対応
環境準備	⚠️ Javaインストール・設定必要	✅️ 単一バイナリ配置のみ	⚠️ Java/Scala環境設定必要	✅️ 単一バイナリ配置のみ	⚠️ 環境のデプロイが必要
分散構成対応	✅️ コントローラ/ワーカー方式	❌️ 手動での分散実行（k8s operatorあり）	❌️ 手動での分散実行	❌️ 手動での分散実行	✅️AWS Fargate
レポート	✅️ GUI表示、HTMLレポート、CSV/XML/JTL出力	✅️ 標準出力、JSON出力、CloudWatch連携	✅️ HTMLレポート自動生成	⚠️ 標準出力、CSV/JSON出力	✅️コンソール表示、CloudWatch連携
商用サービス	✅️ あり	✅️ あり（k6 Cloud）	✅️ あり（Gatling Enterprise）	❌️ なし	✅️
習熟コスト	⚠️ 独自GUIが複雑	✅️ シンプルで容易	⚠️ 独自DLSが複雑	✅️ シンプルで容易	⚠️ AWSインフラ知識が必要
GitHubスター数	9.1k	29.4k	6.8k	24.7k	-

チューニングポイント

テスト実行中に特定したボトルネックをどう解消していくか、代表的なチューニング観点を「アプリケーションサーバ / ランタイム」「アプリケーションロジック」「DBサーバ」「DBスキーマ / DBクエリ」の各レイヤに分けて紹介しています。スケーリングやコネクションプール、SQLの実行計画やインデックスの最適化など、現場でよくあるポイントを一通り網羅しています。

レポーティング

最後に、テストの結果をどう評価・報告するかをまとめています。種別（ボリューム / ラッシュ / ロングラン / ストレス）ごとに、性能指標・リソース使用状況・エラー内訳・最適なインフラ構成の検討結果といった、レポートに含めるべき観点を整理しました。性能テストは「測って終わり」ではなく、本番運用に耐えられること、そして残存リスクまでを説明できて初めて完了します。

このほかAPPENDIXとして、Core Web Vitalsを軸とした画面（フロントエンド）の性能テストや、計画時・実施後に使えるチェックリストも用意しています。

おわりに

性能テストは「とりあえず負荷をかけて終わり」ではなく、目的を定め、合否を判断し、ボトルネックを潰しながら本番運用に耐えられることを示していく一連のプロセスです。本ガイドラインが、性能テストにこれから取り組む方や、自分たちの進め方を見直したい方にとっての一助となれば幸いです。

ガイドラインはGitHubの future-architect/arch-guidelines で公開しており、Issueやプルリクエストでのフィードバックも歓迎しています。

3年ぶりWindows環境構築のリトライと答え合わせ

2026-06-02T15:00:00.000Z

本記事は、日本語 (JIS) 配列キーボードを使う Mac ユーザーが Windows 環境を組むケースを前提にしています。US 配列や、日本語入力を必要としない構成は対象外です。

はじめに

こんにちは。棚井です。

2023 年、私は Mac から Windows への移行を機に、Windows 環境構築の記事を書きました。当時の私は非開発部門に所属しており、Mac で慣れ親しんだテキスト入力の操作感を Windows で再現することが、業務の死活問題でした。この記事は予想以上に多くの方に読んでいただき、私の試行錯誤がそのまま誰かの助けになったことを嬉しく思っています。

2026 年の今、私はエンジニアとして再び Windows 環境を構築しています。ただし今回は、Mac から Windows に移行するわけではありません。Mac の隣に、Windows を 1 台増やすためです。

業務で Claude Code を本格的に使い始めて思ったのは、現代の生産性とは「個人がハンドリングできる AI エージェントの並列数」とも言えるのではないか、ということです。マネジメント理論の「スパン・オブ・コントロール」(1 人の管理者が統制を保ったまま直接マネジメントできる部下の数は 5〜10 人が上限とされます) と同じ問題が、AI エージェントとの関わりにも起き始めています。Claude Code を 1 つ動かしているうちは出力をレビューする余裕があります。2 つ並列でも何とかなります。3 つになるとコンテキストの切り替えで頭が疲弊し始めます。 あなたは、何体の AI エージェントを同時に動かせますか? という問いが、現代のエンジニアに突きつけられているわけです。

この記事を見直している 2026 年 5 月 29 日、Opus 4.8 が使えるようになり、/workflows で複数のエージェントをまとめて並列に動かせるようになりました。こうなると、ボトルネックは「自分が何体まで面倒を見られるか」から、使える「予算」のほうに移ってきた気がします。/effort で ultracode を選ぶと大量のエージェントが一斉に走り出しますが、その分トークンの使用量も一気に跳ね上がるからです。スパン・オブ・コントロールの上限は、人間の側ではなく財布の側に引き直されつつあるのかもしれません。

https://www.anthropic.com/news/claude-opus-4-8

並列数をさらに増やすために、私は物理的に PC を増やすという選択をしました。1 台の Mac で全てのタスクをこなすよりも、Mac の中ではセッションを切り替えつつ、ドメインが大きく異なるタスクは別 PC (Windows) に振り分ける方が、頭の切り替えの負担と PC の負荷の両方を分散できると判断したからです。どうせ環境を増やすなら、普段使っている Mac ではなく、2023 年にセットアップした Windows を再構築するほうが面白そうです。そう思って、改めて Windows の環境構築に着手しました。この 3 年で出てきた新しいものも取り入れようと、関連ツールを片っ端から探しました。

2026 年の Windows 環境構築

どのツールを使い、どう設定したかを順に書きます。順序は実際にインストールした順番に近い形にしてあります。読者の方が再現する際も、この順序で進めると手戻りが少ないと思います。

先に全体像を示します。

設定対象	使用ツール
物理キーのリマップ (Caps Lock → F13、Alt → Ctrl など)	SharpKeys
IME 切替 (無変換/変換キーで IME ON/OFF)	Microsoft IME
ランチャー (Ctrl + Space で起動)	PowerToys Command Palette
Mac 風のテキスト操作 (Caps Lock + H/F/B/P/N/A/E、zh/zj/zk/zl で矢印)	AutoHotkey v2
クリップボード履歴 / 拡張ペースト (Win + V、Win + Shift + V)	Windows 標準 + PowerToys Advanced Paste
ブラウザ (縦タブ + Workspaces)	Zen Browser

SharpKeys のキーリマップ設定

最初に物理キーボードのキー配置を決めます。Mac の指の動きを Windows で再現するための土台で、この後に入れるツールはこの配置を前提にしています。

SharpKeys は GitHub のリリースページから入手します。

.msi または .zip をダウンロードします。業務 PC で管理者権限がない、あるいはレジストリを汚したくない場合は、ZIP 版のポータブル運用が便利です。

起動後、メイン画面の Add ボタンを押してリマップを追加します。

私が登録した 5 項目は以下の通りです。

From	To	スキャンコード対応
Caps Lock	F13	00_3A → 00_64
半角/全角	1 !	00_29 → 00_02
Left Alt	Left Ctrl	00_38 → 00_1D
Right Alt	Right Ctrl	E0_38 → E0_1D
ひらがな/カタカナ	Right Ctrl	00_70 → E0_1D

それぞれのリマップの意図を補足します。Caps Lock → F13 は、後で入れる AutoHotfkey のホットキーのトリガとして使うためです。Left Alt / Right Alt → Ctrl は、Mac の Cmd の位置に Ctrl を持ってきて、ショートカットの指運びを Mac と揃えるための置き換えです。ひらがな/カタカナ → Right Ctrl は、ホームポジション右側からも Ctrl を取れるようにする補強です。半角/全角 → 1 ! は、IME 切替を変換/無変換キーに集約した結果、Mac のキーボードには存在しなくて誤入力しやすい半角/全角を「ただの 1 キー」に潰したかったからです。

5 項目を追加し終えたら、Write to Registry ボタンでレジストリに書き込みます。サインアウト → サインインで設定が反映されます。

Caps Lock を F13 にリマップした状態が、レジストリの Scancode Map レベルで有効になります。Windows のキーボードドライバが起動時に Scancode Map を読み込んで動くため、SharpKeys 自体は常駐しません。設定後は SharpKeys.exe を終了して構いません。

IME の設定

タスクバー右下の「あ」または「A」を右クリック → 設定 → キーとタッチのカスタマイズを開き、「各キー/キーの組み合わせに好みの機能を割り当てます」をオンにします。

無変換キーに IME オフ、変換キーに IME オンを割り当てます。Mac の英数キー/かなキーと同じ操作感が Windows で再現できる、最重要の設定です。

PowerToys のインストール

PowerToys は GitHub のリリースページから入手するのが確実です。

PowerToysUserSetup-x64.exe を選びます。User Setup 版は管理者権限不要で、%LOCALAPPDATA%\PowerToys にインストールされます。業務 PC でも導入のハードルが低い形式です。

PowerToys Command Palette のホットキー設定

PowerToys の左メニューから Command Palette を選択 → アクティブ化のショートカットを Ctrl + Space に変更します。

Mac で Raycast や Alfred を Cmd + Space で使っているなら、同じ感覚で起動できるようになります。

Ctrl + Space は Microsoft IME のデフォルトで IME ON/OFF と衝突する可能性があります。先に IME の設定で無変換/変換キーに IME 切替を割り当てておけば、Ctrl + Space を別用途に転用できます。

AutoHotkey v2 のインストールとスクリプト配置

AutoHotkey v2 を公式サイトから入手します。

公式インストーラを実行後、以下の内容で rekeymap.ahk を作成します。

#Requires AutoHotkey v2.0
#SingleInstance Force

; zh, zj, zk, zl で矢印文字
:*:zh::←
:*:zj::↓
:*:zk::↑
:*:zl::→

; F13 + キー で Mac 風のカーソル操作
F13 & H::Send "{Blind}{Backspace}"
F13 & F::Send "{Blind}{Right}"
F13 & B::Send "{Blind}{Left}"
F13 & P::Send "{Blind}{Up}"
F13 & N::Send "{Blind}{Down}"
F13 & A::Send "{Blind}{Home}"
F13 & E::Send "{Blind}{End}"

このファイルをダブルクリックで起動するとタスクトレイに緑の H アイコンが表示され、スクリプトが動作します。

Windows 起動時に自動実行させるには、Win + R で「ファイル名を指定して実行」を開き、shell:startup と入力してスタートアップフォルダを開きます。そこに rekeymap.ahk (または同ファイルへのショートカット) を配置すると、次回サインイン以降は自動でスクリプトが立ち上がるようになります。

このスクリプトの背景は、2023 年の記事に書いた以下の引用がすべてです。

Mac だと「Caps Lock + h, j, k, l」が、それぞれ「←、↓、↑、→」になりますし、「control + h, f, b, p, n, a, e」がそれぞれ「Backspace、→、←、↑、↓、Home、End」になります。Mac で身に染み込んだ指の動きを、Windows でも再現したい。これが私の出発点でした。

Windows に持ち込んでいる操作系は 2 つあります。1 つは Google 日本語入力の挙動です。Google 日本語入力では、ローマ字入力中に zh / zj / zk / zl をタイプすると即座に矢印文字 ← / ↓ / ↑ / → に変換されます。SNS やチャットで矢印を入れたいとき、Mac ではこの機能が当たり前のように動きます。Windows の Microsoft IME にはこの機能がないため、AutoHotkey のホットストリング機能で再現しています。:*:zh::← がその定義です。Google 日本語入力の変換とは違って IME の外でテキストを置き換える仕組みなので、日本語入力の途中ではなく直接入力のときに確実に効きます。

もう 1 つは Mac の Control キーによるカーソル操作です。Mac では Control + H で Backspace、Control + F/B/P/N で右/左/上/下のカーソル移動、Control + A/E で行頭/行末への移動ができます。Emacs キーバインドと呼ばれる体系で、テキスト入力をホームポジションから離れずに完結できます。Windows ではこれが標準で使えないため、AutoHotkey で F13 & H::Send "{Blind}{Backspace}" のような形で再現しています。

F13 をトリガキーに選んでいる理由は、Caps Lock の押しっぱなし問題を回避するためです。Caps Lock はトグルキーなので、AutoHotkey で修飾キーとして使うと、大文字ロックの誤発火やキーが解放されない現象が起こりやすくなります。SharpKeys でレジストリレベルに Caps Lock → F13 を書き込んでおけば、トグル動作を持たない F13 を安全なトリガとして使えます。

物理キーボードのキー配置 (SharpKeys)、トリガキーへのリマップ (SharpKeys)、ホットキー定義 (AutoHotkey) の 3 つが揃って、ようやくホームポジションを崩さずに文字を入力できるようになります。試行錯誤の詳細は 2023 年の記事に書いています。

クリップボード履歴の有効化

Win + I → システム → クリップボード → クリップボードの履歴を ON にします。これで Win + V を押すと過去 25 件のコピー履歴がポップアップ表示されます。

PowerToys Advanced Paste は別途 Win + Shift + V で起動します (筆者は起動キーを Ctrl + / に変更しています)。リッチテキストをプレーンテキストに変換してペースト、HTML をマークダウンに変換、などの機能が使えます。AI 連携 (OpenAI / Ollama / Foundry Local 等) も設定可能ですが、業務 PC では一旦オフのままで実用上問題ありません。

Zen Browser のインストール

Mac で Arc を使い続ける場合の、Windows 側のメインブラウザとして Zen Browser を採用します。

ダウンロードした .exe を実行 → ウィザードに従ってインストール。SmartScreen 警告が出た場合は「詳細情報」→「実行」で進めます。初回起動時の Welcome 画面で、レイアウトを Single Toolbar に設定するのが Arc に最も近い操作感になります。

Compact Mode を有効化 (設定 → Look and Feel) し、Workspaces を作業内容ごとに作成します。

Chrome で日常的に使っている主要な拡張機能は、たいてい Firefox Add-ons にも同等品が公開されています。Zen Browser は Firefox ベースなので、これらをそのまま導入できます。

設定後の構成

ここまでで、以下の構成が動いている状態になります。

物理キーボード (MX KEYS mini) で Mac の指の動きが再現できる
Caps Lock + H/F/B/P/N/A/E で Mac 風のテキスト操作 (Backspace、カーソル移動、行頭/行末)
zh/zj/zk/zl で矢印文字入力
Ctrl + Space で PowerToys Command Palette
Win + V でクリップボード履歴
Win + Shift + V で拡張ペースト (Advanced Paste)
Zen Browser で Arc 風の作業空間

ここまでの設定は、合計で 30 分程度で完了します。

3 年で変わったもの、変わらなかったもの

ここまで紹介してきた設定を、2023 年の構成と比較してみます。

カテゴリ	2023 年	2026 年	コンセプト
キーボード	Logicool MX KEYS mini KX700GR	同じ	維持
IME	Microsoft IME (無変換/変換キー設定)	同じ	維持
キーリマップ (低レイヤー)	Change Key	SharpKeys	維持 (Scancode Map 方式)
キーリマップ (高レイヤー)	AutoHotkey v2	AutoHotkey v2 (v1 は 2024/3 EOL)	維持
ランチャー	ueli	PowerToys Command Palette	維持 (Microsoft が公式追従)
ファイル検索	Everything	PowerToys Command Palette の拡張機能	維持 (機能が公式統合)
クリップボード	Win + V (標準)	Win + V + PowerToys Advanced Paste	維持 (機能が公式統合)
ブラウザ	Chrome	Mac: Arc / Windows: Zen Browser	Mac 環境構築で変化済み

Windows の環境構築という範囲で見れば、3 年間で起きた変化はほとんどありません。物理キーボード、IME 設定、AutoHotkey のスクリプトは、2023 年から動かしているものがそのまま動いています。入れ替えたツールも、変わったのはツール側の事情だけです。Change Key は 2012 年 4 月の v1.50 で更新が止まったので、保守が続いていて ARM64 版もある SharpKeys に乗り換えました。ランチャーやファイル検索、クリップボード履歴は、サードパーティの機能が PowerToys や OS 標準に取り込まれたので、公式版を使っているだけです。どれも提供形態が変わっただけで、私のやりたいことは何も変わっていません。

ブラウザだけは 2023 年と 2026 年で違うように見えますが、これは Windows の環境構築とは別の話です。2025 年 2 月に公開した Mac 環境構築の記事で書いた Chrome から Arc/Zen Browser への乗り換えを、Windows にも反映させた結果です。Arc は 2025 年 5 月 26 日にメンテナンスモードに入り、Windows 版は未完成のまま終わるので、Windows 側は Zen Browser を選んでいます。

ブラウザでも、同じことが起き始めています。2025 年に私は Arc の縦タブ、Workspaces、Compact Mode、Split View に衝撃を受けましたが、1 年後の 2026 年には Chrome でも縦タブが正式機能になりました。挑戦的なツールが先に面白い機能を作り、メジャーなツールが後追いで取り込んでいく。ueli から PowerToys Command Palette、Everything から PowerToys のファイル検索、これと同じ動きです。

個別のツールに執着し続けるのは、3 年スパンで見れば現実的ではありません。それよりも、自分が何のためにそのツールを使っているのかを書いておくほうが、長く役に立ちます。私の場合、それは「Mac の指の動きを Windows で再現したい」だけです。Control + H で Backspace を打てる、Control + F/B/P/N でカーソルを動かせる、Control + A/E で行頭・行末に飛べる、Google 日本語入力で zh/zj/zk/zl と打って矢印を入力できる。これらを Mac と同じ感覚で Windows でも使えれば、それで十分です。

ここは 3 年では陳腐化しませんでした。Windows の API も Mac の API も大きくは変わっていませんし、人間の指の動きはもっと変わりません。だからツールが何度入れ替わっても、指の動きを再現するという目的さえ書き留めておけば、毎回そこから組み直せます。これは 3 年経ってからようやく実感できたことです。

おわりに

業務で Claude Code を使うために増設した Windows 機は、3 年前にセットアップした Windows と、ほとんど同じ構成で動き始めました。並列で動かせる AI エージェントの数を増やしたい、というのが今回の動機でした。Mac の隣に Windows を置くというハードウェアの判断は新しかったものの、その Windows をどう設定するかについては、すでに 2023 年の私が答えを出していました。新しいツールを探したのに、3 年前の私の発想を超えるものは何も見つかりませんでした。

PC のキーボードに両手で入力するスタイルが変わらない限り、ホームポジションを崩さない設定へのこだわりは変わりません。ということは、3 年後、また Windows をセットアップする機会が来たら、私はまた同じことを書くのかもしれません。もしくは、そもそも「両手でキーボードに入力する」という前提を覆すような、とんでもないデバイスの登場が待ち遠しいです。

分散システム入門: 信頼性の低いネットワークを再現してみる

2026-04-26T15:00:00.000Z

春の入門祭り2026の4本目です。

はじめに

こんにちは、自宅サーバの運用って実質盆栽だよなって思い始めてる、盆栽未経験の内堀です。今回は自宅サーバでネットワークフォルトを再現してみたよというお話です。

分散システムを勉強していると「ノードが完全に死ぬよりも、中途半端に死んでいるほうが厄介」という話に必ず出会います。完全に死ねばクラスタが検知して切り離せますが、半分生きているとシステムからは正常に見えてしまい、悪さをし続けるからです。というわけで、分散システム入門の第一歩として、今回はこの「中途半端に死んだノード」を自宅サーバ上で再現してみます。具体的には、50%パケロスする設定をノードに仕込み（本記事ではゾンビノードと呼びます）、クラスタへの影響を測定します。

結論から書くと、3ノードのKubernetesクラスタで1ノードのネットワークだけ半壊させたところ、クラスタ全体のスループットが1/14、p99レイテンシが15倍に悪化しました。以下、この数字に至るまでの話を書いていきます。

実験の概要

構成

3ノード（home-lab-1, home-lab-2, home-lab-3）のk3sクラスタで、以下を用意します。

nginxのDeployment（replicas=3、各ノードに1Podずつ配置されるようtopologySpreadConstraintsで制約）
上記を束ねるClusterIP Service
計測用のデバッグPod（curlとohaが入ったalpineベース、control-planeで元々負荷の軽いhome-lab-1に固定）

実験の流れ

以下の3段階で計測し、それぞれを比較します。

ベースライン計測：パケットロスなしの状態で計測
半壊状態の計測：worker2（home-lab-3）のOS上で tc qdisc add ... netem loss 50% を実行し、パケットロス50%を発生させた状態で計測
完全停止状態の計測：worker2上で systemctl stop k3s-agent を実行し、Kubernetesから完全に切り離された状態で計測

各段階で、デバッグPodからService経由でnginxを叩いて挙動を観察します。具体的には、軽い疎通確認としてcurlを60回ループで回して各Podへの振り分けを見て、その後ohaで20000リクエスト投げてSuccess rate、RPS、レイテンシ分布を計測します。

実験

実験1：ベースラインの計測

まずはパケットロスなしの状態で計測します。比較対象になる数字を取るのが目的です。

Podが3ノードに1つずつ分散配置されていること、ServiceのEndpointsに3つのPod IPが揃っていることを確認します。

$ sudo kubectl -n zombie-exp get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE
nginx-84888755c4-l7xtn   1/1     Running   0          13h   10.42.2.82    home-lab-3
nginx-84888755c4-vf9zs   1/1     Running   0          20h   10.42.1.213   home-lab-2
nginx-84888755c4-z94f4   1/1     Running   0          20h   10.42.0.31    home-lab-1

$ sudo kubectl -n zombie-exp get endpoints nginx
NAME    ENDPOINTS                                    AGE
nginx   10.42.0.31:80,10.42.1.213:80,10.42.2.82:80   20h

3Pod、3ノードに分散、Endpointsに全部入っている状態。期待通りです。

疎通確認

デバッグPodからcurlを60回ループで回して、各Podにほぼ均等に振り分けられていることを見ます。nginxはpostStartで自分のhostname（=Pod名）をindex.htmlに書き込んでいるので、レスポンスを見ればどのPodが応答したかわかります。

$ sudo kubectl -n zombie-exp exec debug -- sh -c 'for i in $(seq 1 60); do curl -s --max-time 2 http://nginx.zombie-exp.svc.cluster.local/ || echo FAIL; done | sort | uniq -c'
    19 nginx-84888755c4-l7xtn
    19 nginx-84888755c4-vf9zs
    22 nginx-84888755c4-z94f4

19/19/22でほぼ均等。FAILは0件。

定量計測

ohaで20000リクエスト、コネクション並列度30、--disable-keepalive でリクエストごとにTCP接続を張り直す設定で計測します。keep-aliveを切っているのは、後段の半壊状態でTCPハンドシェイクのSYNパケットがロスする様子をはっきり見るためです（keep-aliveを有効にすると同じコネクションを使い回してしまい、ロスの影響が見えにくくなります）。

$ sudo kubectl -n zombie-exp exec debug -- oha -n 20000 -c 30 -t 2s --disable-keepalive http://nginx.zombie-exp.svc.cluster.local/

Summary:
  Success rate: 100.00%
  Requests/sec: 1620.8811

Response time distribution:
  50.00% in 2.0985 ms
  90.00% in 69.1044 ms
  99.00% in 108.9357 ms

Status code distribution:
  [200] 20000 responses

20000リクエスト全成功、1620RPS、p50が2ms、p99が109ms。自宅サーバの3ノードk3sクラスタとしてはこんなもんかなと思います。
これがベースラインの数字。以降、半壊と完全停止の結果はこれと比較していきます。

ちなみに、実行中は以下の画像のように、レイテンシ分布が更新されながら進んでいくのが見えます。

実験2：home-lab-3をゾンビノードにして計測

worker2（home-lab-3）にパケットロス50%を注入します。Linuxの tc コマンドの netem モジュールを使います。

$ ssh worker2 "sudo tc qdisc add dev eth0 root netem loss 50%"

これでeth0から出入りするパケットの50%がランダムに落ちるようになります。

Kubernetesから見たノードの状態

ここが今回の実験の核心です。50%のパケロスを発生させた直後の状態を見ます。

$ sudo kubectl get nodes
NAME         STATUS   ROLES           AGE   VERSION
home-lab-1   Ready    control-plane   73d   v1.34.3+k3s3
home-lab-2   Ready              73d   v1.34.3+k3s3
home-lab-3   Ready              73d   v1.34.3+k3s3

$ sudo kubectl -n zombie-exp get endpoints nginx
NAME    ENDPOINTS                                    AGE
nginx   10.42.0.31:80,10.42.1.213:80,10.42.2.82:80   20h

home-lab-3はReadyのまま。Endpointsからも外れていません。これがゾンビノードです。

なぜこうなるかというと、Kubernetesはkubeletがapiserverに対して定期的にハートビートを送ることでノードの生死を判定しています。50%のパケロスがあっても、TCPの再送機構によってハートビートはなんとか届くので、Kubernetesから見ればノードは正常稼働中ということになります。

疎通確認

次に、curlでの各Podへの振り分け状況を確認します。FAILが7件発生。home-lab-3上のPod（l7xtn）に振り分けられたリクエストは、半分くらいは2秒のタイムアウト内に応答が返ってきますが、半分くらいはパケロスによって失敗してFAIL扱いになります。

ベースラインではFAIL=0だったところに、いきなり12%が失敗するようになりました。「ノードはReady、でもユーザのリクエストは落ちる」が起きている状態です。

$ sudo kubectl -n zombie-exp exec debug -- sh -c 'for i in $(seq 1 60); do curl -s --max-time 2 http://nginx.zombie-exp.svc.cluster.local/ || echo FAIL; done | sort | uniq -c'
      7 FAIL
     18 nginx-84888755c4-l7xtn
     18 nginx-84888755c4-vf9zs
     17 nginx-84888755c4-z94f4

定量計測

$ sudo kubectl -n zombie-exp exec debug -- oha -n 20000 -c 30 -t 2s --disable-keepalive http://nginx.zombie-exp.svc.cluster.local/

Summary:
  Success rate: 90.50%
  Total:        219.8244 sec
  Requests/sec: 90.9817

Response time distribution:
  50.00% in 0.0008 sec
  90.00% in 0.8245 sec
  99.00% in 1.6341 sec

Error distribution:
  [1899] timeout

数字を並べてみるとこんな感じ。

Success rateが90.5%に低下
1899件のタイムアウトエラー
RPSが1620→91と、ベースラインの5.6%まで激減
20000リクエスト消化に12秒だったのが、220秒
p99が109ms→1634msと、約15倍に悪化

正直、ここまで悪化するとは思っていませんでした。1台のゾンビノードが混ざったことで、クラスタ全体のスループットが18分の1まで落ち込みました。
面白いのがp50で、0.8msとベースラインの2.1msより速く見えます。これは「運よくロスに当たらず1発で通ったリクエスト」が半分弱あって、それらは普通に高速だからです。ロスに当たったリクエストはTCPの再送タイムアウト(初期RTOが1秒)に引っかかってp90以降で秒オーダーまでぶっ飛びます。「半分は普通に速い、半分は秒オーダーで遅い」という2山型(バイモーダル)の分布になっています。

実験3：home-lab-3を完全停止させて計測

最後に、worker2のk3s-agentを完全に止めて計測します。「ネットワーク半壊」と「ノード完全停止」のどちらがマシか、という比較が目的です。

Kubernetesから見たノードの状態

実験2ではhome-lab-3はReadyでしたが、今回はNotReadyになりました。

$ sudo kubectl get nodes
NAME         STATUS     ROLES           AGE   VERSION
home-lab-1   Ready      control-plane   73d   v1.34.3+k3s3
home-lab-2   Ready                73d   v1.34.3+k3s3
home-lab-3   NotReady             73d   v1.34.3+k3s3

PodとEndpointsの状態も確認します。

$ sudo kubectl -n zombie-exp get pod -o wide
NAME                     READY   STATUS        RESTARTS   AGE   IP            NODE
nginx-84888755c4-blc65   0/1     Pending       0          27s           
nginx-84888755c4-l7xtn   1/1     Terminating   1          14h   10.42.2.82    home-lab-3
nginx-84888755c4-vf9zs   1/1     Running       0          21h   10.42.1.213   home-lab-2
nginx-84888755c4-z94f4   1/1     Running       0          21h   10.42.0.31    home-lab-1

$ sudo kubectl -n zombie-exp get endpoints nginx
NAME    ENDPOINTS                      AGE
nginx   10.42.0.31:80,10.42.1.213:80   21h

home-lab-3上のPod（l7xtn）がTerminatingになり、EndpointsからもIP 10.42.2.82 が外れました。Service経由のトラフィックは健全な2Podだけに流れます。新しいPod（blc65）はPendingですが、各ノードに1Podまでの制約をかけているので置き場所がない、というだけで、Endpointsには影響しません。期待通りの挙動です。

疎通確認

curlで各Podへの振り分け状況を確認します。
FAIL=0。home-lab-3上のPod（l7xtn）はEndpointsから外れているので、振り分け先には現れません。健全な2Podだけで応答が返っています。

$ sudo kubectl -n zombie-exp exec debug -- sh -c 'for i in $(seq 1 60); do curl -s --max-time 2 http://nginx.zombie-exp.svc.cluster.local/ || echo FAIL; done | sort | uniq -c'
     34 nginx-84888755c4-vf9zs
     26 nginx-84888755c4-z94f4

定量計測

$ sudo kubectl -n zombie-exp exec debug -- oha -n 20000 -c 30 -t 2s --disable-keepalive http://nginx.zombie-exp.svc.cluster.local/

Summary:
  Success rate: 100.00%
  Requests/sec: 1267.3896

Response time distribution:
  50.00% in 1.9522 ms
  90.00% in 91.6390 ms
  99.00% in 193.9529 ms

Status code distribution:
  [200] 20000 responses

Success rateは100%に戻りました。RPSは1267で、ベースラインの78%程度。Pod数が3→2に減ったので、スループットは下がりましたが、それだけです。p99も194msとベースラインの109msから少し悪化していますが、実験2の1634msと比べれば誤差みたいなものです。
Kubernetesがhome-lab-3をNotReadyと判定し、Endpointsから自動で外してくれたおかげで、リクエストはちゃんと返ってきます。ゾンビノードが混ざっているときと比べると、随分と平和な数字です。

実験結果のまとめ

3つの実験結果を表にまとめます。

指標	ベースライン	ゾンビノードあり	完全停止
Success rate	100.00%	90.50%	100.00%
RPS	1620	91	1267
p50	2.1 ms	0.8 ms	1.9 ms
p90	69 ms	824 ms	92 ms
p99	109 ms	1634 ms	194 ms
timeout	0	1899	0
20000リクエスト消化時間	12 sec	220 sec	16 sec

ゾンビノードありと完全停止を並べてみると、こうです。

スループット:完全停止の1/14
p99:完全停止の8.4倍
Success rate:完全停止より9.5ポイント低下

ノードが「壊れている」という点はどちらも同じです。違うのは、Kubernetesがそれを検知できるかどうか。検知できれば勝手に退避してくれるけど、検知できなければ放置されたまま。たったそれだけの差で、結果がガラッと変わりました。

冒頭で書いた「中途半端に死んでるほうが厄介」を、実験を通して確認できました。

おわりに

今回はシンプルなHTTPリクエストのみを確認しましたが、これがDB接続のような状態を持つ処理であれば、コネクションを掴んだまま離さないリクエストがプールを食いつぶし、連鎖的な障害を招くことは容易に想像できます。

しかも厄介なことに、Kubernetes側の仕組みだけでは半壊状態を検知することが難しく、ノードがReadyである限り異常として処理されません。実際にネットワークフォルトを再現してみたことで、ゾンビノードが全体にどのような被害を及ぼすのか、解像度が上がりました。

それにしても、不調なのに「大丈夫です」と返すWorkerと、それを真に受けて普通に仕事を振り続けるControl plane。この関係はどこか見覚えがあって、なんだか親近感が湧くのは僕だけでしょうか。

自宅だと apt update ができなかった話（WSL2 + 社内VPN環境での名前解決の遅延）

2026-04-20T15:00:01.000Z

1. はじめに

こんにちは。HealthCare Innovation Group (HIG)の清水雄一郎です。
本記事は、春の入門祭り2026の1日目の記事です。

新年度・新チーム配属のこの季節、「開発環境のセットアップで丸一日溶かした」という経験をされている方も多いのではないでしょうか。特にエンタープライズ企業の「プロキシ・VPN配下」での開発環境構築は、ドキュメント通りに進めても謎のエラーに阻まれがちです。
プロキシに関しては、過去の記事¹²³もぜひご確認ください。

少し前（2026/01頃）に私が遭遇した事象は、WSL2環境で「自宅に帰るとapt updateできない」というものです。
当時を振り返ると、次のような状況でした。

オフィスに出社してネットワークに繋ぐと、apt update が成功する
自宅（無線/有線LAN&VPN接続中）だと、 apt update が失敗する
ただし、iPhoneのテザリング＋VPN の場合、apt update が成功する

結論から言うと、今回のケースではDNSの順序を変えることで解決しました。
その頃のSlackスレッドやGeminiとのチャット履歴を遡りつつ、体験記兼トラブルシューティングログとして残します。

2. 調査編: 泥沼のトラブルシューティング

2.0. 前提

本記事は、次の環境下で確認したものです。
※Windows側のバージョンは、事象発生時から少し変わっているかもしれません。

環境情報

S3エミュレーションでrustfsを使ってみたメモとPresigned URLの仕組み

2026-04-02T15:00:00.000Z

ちょっとしたオブジェクトストレージ前提のシステムのローカルテストでApache 2ライセンスのrustfsを使ってみました。おおむね簡単だったのですが、認証設定をしたり、presigned URLの発行だけちょっと手間がかかってしまったのでその対応とその過程で学んだことのメモです。

このあたり、minioがDockerイメージの配布をやめてメンテナンスモードになったり、LocalStackがユーザー登録必須になってCIで使いにくくなったりでにわかに話題になっていたところですね。

さくらんぼの技術備忘録: 手軽に使えるS3互換ストレージを求めて
minioがdockerイメージを配布しなくなったので新しいS3互換ストレージを探す

ちょっとしたウェブアプリのバックエンドのストレージとしてオブジェクトストレージが欲しくなったのですが、これまではminioをたまに使ったりしていたものの、別のものを検討するにあたり、docker composeで一緒に起動するという使い方で使いやすいものということで、いろいろ比べてrustfsを選んでみました。

compose.yamlでの利用方法

rustfsの公式イメージをそのまま使うだけです。一瞬で起動します。

デフォルトで9000ポートでAPIのエンドポイントを、9001で管理画面(RUSTFS_CONSOLE_ENABLEが必要)を公開します
複数ボリュームのレプリケーションとか色々複雑な機能もありますが、テスト用で可用性はいらなかったので1ボリュームにしています
起動時にはバケットができて欲しいところなので、amazon/aws-cliイメージを使って起動時にバケットを作るようにします

compose.yaml

services:
  rustfs:
    image: rustfs/rustfs:latest
    environment:
      RUSTFS_CONSOLE_ENABLE: "true"
      RUSTFS_ACCESS_KEY: rustfsadmin
      RUSTFS_SECRET_KEY: rustfsadmin
      RUSTFS_VOLUMES: /data/rustfs0
    volumes:
      - rustfs-data:/data
      - rustfs-logs:/logs
    ports:
      - "9000:9000"
      - "9001:9001"
    healthcheck:
      test: ["CMD", "sh", "-c", "curl -sS http://localhost:9000/ >/dev/null"]
      interval: 1s
      timeout: 5s
      retries: 20

  rustfs-init:
    image: amazon/aws-cli:2.31.15
    entrypoint: ["/bin/sh", "-c"]
    command:
      - |
        set -eu
        until aws --endpoint-url http://rustfs:9000 s3api list-buckets >/dev/null 2>&1; do
          sleep 2
        done
        for bucket in data-bucket log-bucket; do
          aws --endpoint-url http://rustfs:9000 s3api create-bucket --bucket "$$bucket" || true
        done
    environment:
      AWS_ACCESS_KEY_ID: rustfsadmin
      AWS_SECRET_ACCESS_KEY: rustfsadmin
      AWS_REGION: us-east-1
    depends_on:
      rustfs:
        condition: service_healthy

volumes:
  rustfs-data:
  rustfs-logs:

使い方を調べると、RUSTFS_ADDRESSなどの環境変数でアドレスを定義しているものなどもありますが、なくてもデフォルトで9000番（UIは9001番）ポートで開いたので省略しました。

管理画面は動作も軽快だしなかなか良いですね。今まで触ったことのあるウェブを使ったファイル管理画面の中では一番スピードが速くて体験が良いですね。

Presigned URL

これでAWS SDKを使ったデータの読み書きは問題ありませんでしたが、Presigned URLの発行で問題が発生しました。rustfsの問題というかDockerを使っているから起きた問題ですが、rustfsでは、Presigned URLで発行されるURLはリクエスト時のホスト情報をもとに作られます。Dockerの中からはhttp://rustfs:9000というドメインでアクセスしますが、外からはhttp://localhost:9000なので、発行されたURLのままではアクセスできないということが起きました。

これは発行時にクライアントを新規で作って、ホストをhttp://localhost:9000に設定してそれで発行し直す必要がありました。

goのサンプル

   // この環境変数があったらそのホストでURLを発行
endpoint := os.Getenv("RUNTASK_RUSTFS_OBJECT_PUBLIC_ENDPOINT")
if endpoint != "" {
	tempOptions := s.options
	tempOptions.Endpoint = endpoint
	tempClient, err := newS3Client(context.Background(), tempOptions)
	if err == nil {
		presigner := s3.NewPresignClient(tempClient)
		presigned, err := presigner.PresignGetObject(context.Background(), &s3.GetObjectInput{
			Bucket: aws.String(s.bucket),
			Key:    aws.String(key),
		}, func(opts *s3.PresignOptions) {
			opts.Expires = expiry
		})
		if err == nil {
			return presigned.URL, nil
		}
		// fallthrough to try using the existing client
	}
}
   // 設定がない場合は普通に発行
presigner := s3.NewPresignClient(s.client)
presigned, err := presigner.PresignGetObject(context.Background(), &s3.GetObjectInput{
	Bucket: aws.String(s.bucket),
	Key:    aws.String(key),
}, func(opts *s3.PresignOptions) {
	opts.Expires = expiry
})
if err != nil {
	return "", err
}
return presigned.URL, nil

Endpointを上書きしてしまったら逆にバックエンドのサーバーからrustfsに繋がらないからダメなのでは？と思い込んでましたが、このPresigned URLの発行はS3 APIを実際に叩いているわけではなく、SDKの中で発行しているらしい。

使う技術はその名の通り「署名」です。TLSは機密の秘匿化(外から読めない)、完全性保証(改竄検知)、認証(証明書によるサーバーの身元確認)などを行いますが、Presigned URLの場合はこのうちの完全性の保証をベースに、いつ誰が許可したのかの情報が後からわかるようにしています。

サービスにアクセスするのに使うURLに「誰が」というのを明らかにするキーIDと期限が付与されて、シークレットアクセスキーを使って署名されます。署名されているので期限や誰が、といった情報の改ざんは許しません。

クライアントはそのURLを使ってS3からファイルをダウンロードしたり、ファイルをアップロードします。S3(ここではrustfs)はその署名をみて、改竄されていないことの確認とともに、誰が署名したのかを確認します。ブラウザ自身はクレデンシャルを持っていなくても、その署名をもとにして認可制御が行われ、読み書きが成功するという流れです。

Endpointを書き換えたクライアントを一時的に作るという方針でも、実際にそのクライアントでS3にリクエストを投げることはなくてURLの発行にしか使わないので問題なく利用できるんですね。てっきり、一時的に利用可能なトークン的なURLとして発行されてサーバー側に情報を持っているのかと思いましたが、そんなことはないんですね。勉強になりました。

まとめ

S3以外もいろいろ必要となる場合は他のAWSエミュレータ（motoとかflociとか）の方が良いかもしれませんが、今回はS3だけが欲しかったのでrustfsを選んでみて使ってみたメモでした。

今まではminioを考えずに使っていましたが、今回別のものを検討してrustfsを使ってみました。seaweedfsとかも良さそうでしたが、filterとかたくさんコンテナが必要そうだったので1つで済むrustfsにしました。コンテナのメモリ消費90MBぐらいですね。動きも軽快なので今後も使ってみようと思いました。

実験して入門するKubernetes：Pod起動の裏側を追っていたら、どうしてもSchedulerを止めてみたくなった件

2026-03-24T15:00:00.000Z

はじめに

最近、コンテナオーケストレーションの技術領域に興味をもち、Kubernetesを触り始めました。早速自宅で飼ってるMiniPC（ホームサーバ）にArgoCDやLonghornを入れてみたものの、Deployment、Pod、Serviceなど初めましての概念ばかり。気づいたら、AIの指示通りにただコマンド打つマンになっていました。

このままではまずいと思い、Kubernetesの基礎的な挙動を追うことにしました。今回は、どのような流れでPodが作られているのかを実験し、そのアウトプットとしてこの記事にまとめています。

※実験にはMinikubeを使っています。初学者が調べながらまとめたものなので、誤りがあればご指摘ください。

Pod起動までの流れの概要

Podが起動するまでの流れを紹介します。複数のKubernetesコンポーネントが登場しますが、この記事のメインテーマではないため、用語は簡単な説明に留めます。詳細が気になる方は、既存の解説記事や公式ドキュメントをご参照ください。

kubectl run
  ↓
API Server → etcd（Podデータ保存、ノード未割り当て）
  ↓
Scheduler（最適なノードを割り当て）
  ↓
kubelet（コンテナイメージのPull・起動）
  ↓
podが起動

etcd：Kubernetesの全状態を保存するデータベース
API Server：全コンポーネントからのリクエスト受付と、状態変更の通知する窓口
Scheduler：Podをどのノードで動かすかを決定するスケジューラ
kubelet：各ノード上で実際にコンテナを起動・管理する実行エンジン

補足：kubectl runはPodを直接作成します。Deployment経由の場合は、Controller ManagerがDeploymentデータ → ReplicaSetデータ → Podデータと各種データを作成するステップが加わります。この記事では、簡略化のためkubectl runによる直接的な作成を追いかけます。

実験1：イベントログでPod作成の流れを確認する

最初の実験として、実際にkubectl runを実行し、出力されるイベントログを確認してみます。

% kubectl run log-test --image=nginx
pod/log-test created
% kubectl get events -w
LAST SEEN   TYPE     REASON      OBJECT         MESSAGE
23m         Normal   Scheduled   pod/log-test   Successfully assigned default/log-test to minikube
22m         Normal   Pulling     pod/log-test   Pulling image "nginx"
22m         Normal   Pulled      pod/log-test   Successfully pulled image "nginx" in 1.481s (1.481s including waiting). Image size: 180545980 bytes.
22m         Normal   Created     pod/log-test   Container created
22m         Normal   Started     pod/log-test   Container started

REASON列とMESSAGE列を見ると、まずScheduledでPodがノード（ここではminikube）に割り当てられ、その後にコンテナの立ち上げ処理が始まっていることがわかります。

さらにkubectl get events -o yaml とオプションを追加すると、各イベントがどのコンポーネントから出力されたのかを詳しく確認できます。

kubectl get events -o yaml の出力

クラウド世代のITコンサルタントが『Data Center』で物理インフラを体験してみた

2026-03-18T15:00:00.000Z

はじめに

製造エネルギーグループの片岡久人です。

『Data Center』というゲームがリリースされ、一部界隈で話題になっていたので、プレイした感想をお話できればと思います。

筆者は、普段ITコンサルタントとして、アプリケーション構築やアーキテクチャ設計に携わっていますが、ベースとなるのはGCPなどのクラウド環境がほとんどであり、いわゆるオンプレミス環境でのインフラ構築経験はありません。

ネットワークの理論的な知識は頭に入っているものの、実践的な経験はあまりないというのが現状でした（大学院生時代にシミュレーション用のサーバーラックを組み立てたことはあるのですが、当時は言われるままにネジ留めしていただけで、ITの知識はほぼ皆無でした）。

「普段クラウドでポチポチと構築しているリソースの裏側では、一体どんな物理的な作業が行われているのか？」

そんな知識の隙間を埋めるべく、Steamで配信されているインフラ構築シミュレーションゲーム『Data Center』をプレイしてみました。

『Data Center』とは？

一言で言えば、「何もない部屋にラックを立て、サーバーをマウントし、LANケーブルを繋いで顧客の要望（タスク）に応えていく」ゲームです。

現在デモ版が無料でプレイ可能です。

■ゲーム情報

Steam Store URL：https://store.steampowered.com/app/4376050/Data_Center_Demo/
開発元：Waseku
パブリッシャー：Waseku

次々と「このIPサブネットで、これくらいの計算リソース（IOPS）を用意してほしい」という案件が降ってくるので、それに対応するために、機材を発注し、構築していきます。

コンテナで届いた機材を台車で運び、ラックに組み込む。まさに「ゲームの中で仕事（作業）をする」感覚のゲームですが、好きな人にはたまらない没入感があります。

プレイの所感と学び：理論が「実体験」に変わる瞬間

実際にプレイしてみて、普段の業務ではあまり意識しない物理的なインフラ構築の工程を、ゲームの中で疑似的に体験できました。

① 物理的なネットワーク接続のリアル

クラウドなら数クリックで終わるネットワークの構築も、物理では当然「ケーブル」が必要です。
ゲーム内では、ケーブルリールからLANケーブルを引き出し、スイッチからサーバーへ1本ずつ繋いでいきます。

「配線の取り回し（綺麗にまとめないと後で大変なことになる）」や「サーバ種類ごとの配置場所の決定」など、物理ならではの制約を疑似体験できました。

② IPアドレス計算の手作業

応用情報の試験勉強で学んだIPアドレスやサブネットマスクの計算。知識としては知っていましたが、実際に顧客（タスク）の要件（/28 など）に合わせてIPアドレスを手動でポチポチと設定していく作業は新鮮でした。

「あの理論は、現場でこうやって使うためのものだったのか」と、知識が実体験として繋がった感覚がありました。現時点ではCUI（Linuxのターミナル画面など）を叩いて設定するような深さには達していませんが、もしかすると今後そんな要素が出てくるかもしれません（既に存在していたらすいません）。

「仮想化・コンテナ」の偉大さ

今回このゲームをプレイして一番の気付きだったのは、ビジネス視点や技術の歴史の変遷に対する腹落ち感です。

ゲーム中、顧客（タスク）が増えるごとに新しいサーバーを立て、それぞれに計算リソースを割り振り、ネットワーク（IP）を設定し、物理的な配線を繋ぎ変えるという泥臭い作業が発生します。

これを行っているうちに、「現実世界でも昔はこれを毎回人間が手作業でやっていたのか。それは無理があるし、限界が来るな」と感じました。

リソースが無駄に余っていても、物理的に繋がっていなければ他の顧客に使い回せない
構成変更のたびに、データセンターに行ってケーブルを挿し直さなければならない

この「物理的なインフラ管理の限界と苦労」を身をもって体験したことで、それを解決するために生まれた「仮想化」や「コンテナ化」、そして「クラウド（IaaS）」といった技術がいかに偉大で、ビジネスのスピードアップに不可欠なものだったかが、身をもって理解できました。

物理の不便さを知ることで、現在私たちが当たり前のように使っている抽象化された技術のありがたみと、その進化の必然性を強く再認識できたのは、ITコンサルタントとして大きな収穫でした。

おわりに

『Data Center』は、最初はひたすらサーバーを立ててLANを繋ぐという「作業ゲー」の側面が強いですが、インフラの裏側を知りたい、あるいはクラウド技術の成り立ちを逆接的に体感したいエンジニアには、気づきを与えてくれるゲームだと思いました。

普段クラウド上で何気なくプロビジョニングしているリソースの裏には、こうして稼働している物理サーバー群がある。その事実を想像できるようになっただけでも、今後のアーキテクチャ設計に少し深みが出せそうです。刺さる人には間違いなく刺さるゲームなので、気になった方はぜひプレイしてみてください。

メール設計ガイドラインを公開しました

2025-10-02T15:00:00.000Z

はじめに

こんにちは。TIG-DXの藤井です。

当社の有志メンバーの協力により、アーキテクチャ設計ガイドラインというものを作成・公開しています。

各分野におけるアーキテクチャ設計の指針となるべく作成されているガイドライン集ですが、この度、新たにメール設計ガイドラインを作成しました。

本記事では、このメール設計ガイドラインについて、内容にも触れつつご紹介をしていきます。

メール設計ガイドライン概要

皆さん、普段からメールは利用されているかと思います。その手軽さ・利用者の多さから、純粋なコミュニケーションツールとしてはもちろん、webシステムにおけるユーザ認証や、販促・各種取引など、多岐にわたって活用されています。

一方、実際にメールという通信手段がどのように実現されているのか・どういった技術が利用されているのか、等を意識することはあまり無いのではないでしょうか。
当然のことではありますが、メール送受信の裏側にはそれを実現しているシステムが存在しています。そういったシステムが正常に稼働しなくなった場合に生じる影響の大きさは、想像に難くないでしょう。

しかしながら、現実問題としてメールに関するシステムトラブルは決して珍しいものではありません。利用者・用途が多いだけに、その分トラブルが起きる余地も大きいのです。

本ガイドラインでは、メール送信を伴うシステムを構築する際に、どのようにシステムを設計すれば安定してメール送信を行うことができるか・ハマりどころは何か、といった内容を整理し、推奨事項に落とし込んでいます。一通り目を通すことで、システムにおけるメール設計の肝が理解できるようなガイドラインを目指して作成しています。

逆に、SMTPそのものの仕様等の、アーキテクチャ設計に直結しない内容については省略しています。メルマガなどの手動送信されるメールや、システム監視等におけるメール通知なども、部分的に参考にできるところはあるかと思いますが、基本的にはスコープ外としています。

あくまで、システムがユーザにメールを送信するためのシステム設計を対象としていることを前提に読んでいただければと思います。

コンテンツ紹介

大前提として考慮すべき要素から、メールを取り扱う上で必要な事柄まで幅広く盛り込んだ結果、公開済の他のガイドラインに見劣りしない分量となりました。

メールについて書くだけでそんな量を？と思われるかもしれませんが、実はそれだけ考慮しなければいけないことの量と質が求められるのが、メールという分野であると考えています。

とは言え、ここで全てをご紹介できないため、一部を抜粋の上、簡略化してお伝えしようと思います。興味を持って頂けた・より詳しく知りたい方は、ぜひメール設計ガイドラインをご覧ください。

なぜメール送信は難しいのか

いきなりガイドラインには（明示的には）記載していない内容なのですが、そもそも何故メールを送信することが難しいのでしょうか。送信プロトコルであるSMTPをはじめとして、技術自体はかなり古く、高度すぎるものではないはずです。

この問への回答は単純で、スパムメールが存在するせいです。メールの歴史は正当な送信者やプロバイダと、スパムメールを送信する悪質な送信者との戦いの歴史と言っても過言ではありません。

先述の通り、メールは利用者が多く、その用途は多岐にわたります。そのため、全ての受信者に対して高いリテラシーを要求できず、またその手軽さから悪用のハードルも低くなっています。そのような状況を踏まえ、メールプロバイダは受信者を悪意ある送信者から守る必要があると考え、スパムであると判定したメールを受信者に届けず処分するという選択を取っています。しかしながら、そのようなスパム判定はもちろん機械的に行わざるを得ないため、（受信者にとっては）正当なメールもスパムメールであると判定してしまい、結果届かなくなるということが起こるのです。

（代表的なプロバイダの動向として、2024年に施行された、Gmailにおけるメール送信者のガイドラインがあります。Gmailが求めるガイドラインに準拠しない送信者からのメールはブロックする（可能性がある）としたもので、多くのシステムが準拠のための対応をすることになりました。）

そのため、（正当な）メール送信者側は、プロバイダに「これはスパムメールではない」と判断してもらうため、適切な対応をとる必要があります。

ドメイン認証

第一の手立てとして、送信者が送信元メールアドレスに記載されているドメインの所有者であることを確認する、ドメイン認証があります。ドメイン認証を1つも行っていない場合、ほとんどのケースでスパム認定がされてしまうため、必ず実施する必要があります。

スパムメールの送信者は、メールが正当なものであると誤認させるために、送信元メールアドレスのドメインを（社会的信頼のある企業などの）ドメインに書き換えてメールを送信することがあります。これはSMTPの仕様として認められており、極めて容易に実現できます。これをドメインのなりすましと呼びます。受信者がなりすまされたドメインのみを確認し、メールを信用してしまえば、フィッシング詐欺などの被害にあってしまう可能性があります。これを防ぐため、ドメインのなりすましを機械的に検知できる仕組みとしてドメイン認証が導入されました。

ここでは詳細は割愛しますが、SPF/DKIM/DMARCと呼ばれる3種の仕組みがあり、いずれも本来は名前解決に用いるDNSを活用した仕組みです。ドメイン認証が成功するメールを送信するためには、DNSに適切なレコードを登録できる人物 = ドメインの所有者でなくてはならない、というロジックで送信元の正当性を担保しています。

ただしこのドメイン認証は、スパムメールを防ぐための機構として完全なものではありません。

ガイドライン上ではTipsとして記載していますが、正規のドメインに酷似していたり、タイプミス等で誤入力しやすい、いわゆるドッペルゲンガードメインと呼ばれるドメインを保有している人物が当該ドメインを攻撃に利用した場合、ドメイン認証は通過してしまいます。ドメイン認証はあくまで、送信者がドメインを所有していることを保証するのみで、送信者自身の正当性を担保するものではないのです。（冒頭記載の通り、ドメイン認証すら通過しない送信者を不正と断じてしまえるため、完全に意味がないということはもちろんありません。）

レピュテーション

ドメイン認証の結果が必ずしも送信者の正当性を担保しないことを踏まえ、メールプロバイダは別の方針で送信者を評価し、ドメイン認証の結果と合わせてメールの取り扱いを判断しています。それがレピュテーションと呼ばれるもので、言葉通りメール送信者の「評判」を意味します。レピュテーションが十分な送信者からのメールは通常通り受信者に配信し、レピュテーションが低い送信者からのメールはスパムメールであると判断し処分してしまう、という単純な仕組みです。

そのため送信者としては、レピュテーションを向上し、高い状態を維持することが安定したメール送信のために取れる手立ての2つ目となります。このレピュテーションは主に、送信元のIPアドレスとドメインに対して評価されます。ドメイン認証の結果と合わせて見ると、レピュテーションが高いドメインの所有者が送信したメールであれば高い確率で正常に配信されることが期待されます。

このレピュテーションは、メールの送信状況や受信者のアクション（迷惑メール報告等）により、プロバイダごとに常に変動して管理がされるため、送信状況の監視・適切なコンテンツの作成が安定したメール配信に強く影響します。

自作メールサーバ vs メール送信SaaS

メール送信を実現する場合、大きく分けて「メールサーバを自作する」・「メール送信用のSaaSを利用する」の二方針に分類されますが、ガイドラインでは圧倒的にSaaSの利用を推奨しています。SaaSを利用することで、各種設定の簡易化・送信状況等の監視機能が利用可能となる・（IP）レピュテーションがある程度担保されている等のメリットを享受できるためです。

ここまでに記載したドメイン認証・レピュテーションの管理ともに、適切な設定・運用は容易ではありません。その一方で、設定誤りや運用ミスが有った場合の影響は極めて大きい（最悪の場合、一切のメールが宛先に届けられない）です。このようなリスクがSaaSの利用により極小化できるのです。

もちろん利用コストが生じることや、（レピュテーションを低下させる行動を繰り返したなどにより）SaaSの利用が停止されてしまうなどのリスクは存在しますが、それを補って余りあるメリットであると考えています。

コンテンツの工夫

レピュテーションには、受信者のアクション（迷惑メール報告等）が影響すると記載しました。つまり、受信者にとってスパムであるかのように映るメールを送信するとレピュテーションが下がり、結果としてメール未達などに繋がってしまいます。そのため、システム面のみならず、実際に送信されるメールの内容についても工夫が必要です。

ガイドラインでは、以下要素などが工夫すべきポイントとしています。

件名: 要件が正しく伝わり、優良誤認とならない範疇で簡潔にする。
本文: マルチパート配信とする。css等による装飾は過剰となりすぎないようにする。
送信者名: 送信者・目的が分かるものとする。
送信元メールアドレス: info, noreply等、メールの性質が伝わるアドレスにする。

トラブルシューティング

ここまでに記載したこと、およびガイドラインに記載したことに準拠していても、突然メールが届かない、といった事態が発生することは想定されます。これは送信者・プロバイダ・受信者という3者が関わる仕組みである以上、確実に回避できるものではありません。

メール送信が正常に行えないという状況自体、影響として大きなものですが、誤った対応や放置をしてしまうと状況は更に悪化してしまいます。

基本的には継続的な問題が確認された時点でメール送信機能は停止し、状況を把握した上で対処を開始することを推奨しています。ガイドラインには具体的な調査するべき内容等も記載しているので、合わせてご確認ください。

おわりに

先述の通り、メール送信を伴うシステムは一度構築したら終わりというものではなく、継続的な監視・適切な運用が必要なものとなっています。構築・運用方針を誤ってしまうと、最悪の場合メール配信が行えなくなってしまいます。

今回作成したガイドラインには、本記事では触れられなかった（量・質ともに）内容も多く記述されています。ぜひ通しでご覧いただき、安定したメールシステムの構築に活用いただければと思います。

最後になりますが、ガイドラインへのご意見や訂正PRなどは広く募集しております。目を通していただいて、疑問に思った点・誤り等ありましたらご意見いただけますと幸いです。

GitHub
ガイドライン一覧

今後も継続してガイドラインは作成していく予定です。既存・新規問わず、アーキテクチャ設計の一助となることを願っております。

TCP Proxyを作って面倒なProxy設定を一掃する～Rust製moproxyとnftablesによる透過プロキシ設定～

2025-09-03T15:00:00.000Z

夏の自由研究2025ブログ連載の8日目です。

はじめに

Technology Innovation Groupの神崎です。

セキュリティ上の理由などで、どうしてもProxyを使わざるを得ない環境下の時に、非常にハマりがちな設定のひとつとしてProxyの設定があります。これには理由があり、ProxyというのはOSレベルで適用するものではなく、利用するツール毎に設定する必要があり、各ツールのドキュメンテーションを読んで適切な設定をする必要があります。そのため利用したいツールすべてについて、適切な設定をしないと動かないという特徴があります。「新しく使い始めたCLIツールがプロキシに対応していなかった」「Dockerのpullがプロキシで失敗する」などあるあるではないかと思います。

また、Proxy機能はツール目線でいうとよく使われる機能ではないため、特に「枯れていない」ツールを利用する際は、そもそもドキュメンテーションがなかったり、Proxyの認証に関してバグがあったりなど、Proxyの設定のトラブルシューティングに非常に時間がかかることがあります（場合によってはツールのソースコードを追うようなことまで必要になります）。

これらは非常に時間がかかり、生産性を低下させることが多く、特にツールの選定やちょっと使ってみたい場合はそれ自体を諦める遠因となることさえあります。そのため、何かツールごとではなく、OSレベルで設定する方法があれば、快適に過ごせるのではないか？と思っていました。

TL;DR

解決策として、下記の構成を提案します。

moproxyを利用し、TCPパケットをHTTP CONNECTリクエストにくるんで、Proxyへ中継する
Linuxカーネルのパケットフィルタリング機能 ¹ であるnftablesを利用して、宛先ポートが80(HTTP)ないし443(HTTPS)へのパケットをmoproxyに転送する
- Well known portsではないポートへの通信は一旦ないものと想定する（必要に応じて個別に設定する）
各ツールでは、Proxyの設定は全く行わず、通常のProxyなしの設定を行い利用する

本記事ではその構成でなぜ動くのかを、HTTPのCONNECT仕様を深掘って解説した上で、具体的な設定例を示します。

※今回の記事ではWindows上のアプリケーションについては対象としていません。特にVPNクライアントが入っているケースを踏まえるとパケットがループしないようにうまく工夫をする必要がありますが、私自身がWindowsに明るくないので、Linuxのみの記述になります。すみません(多くのアプリケーションではインターネットオプションの設定を読みに行く形になるため、そこまで気にする機会はないかなと思います。~~だが、Invoke-WebRequest、おまえはゆるさん…~~)。

そもそもProxyとの通信は何をやっているのか

私が一から解説する必要はないと思いますので、詳しくはこのサイト(作って学ぶ「Https Man in The Middle Proxy」 in Go)を確認して貰いたいのですが、大きく分けると以下の2つのことをやっています。(HTTPSを前提とした場合)

HTTP CONNECTでProxyにHTTPS通信を始めたい旨を通知する(この情報を元にProxyは②のパケットを転送する)
ProxyにTCPパケットそのものを転送する

sequenceDiagram
    participant Browser as ブラウザ/ツールなど
    participant Proxy as Proxy
    participant Web as 接続先

    Note over Browser,Proxy: ①Proxyに通信を始めたい旨を通知する
    Browser->>+Proxy: HTTP CONNECT
    activate Browser
    Proxy->>Proxy: 認証
    Proxy->>-Browser: 200 or 407 RESPONSE

    Note over Browser,Proxy: ②パケット転送を開始する
    Browser->>+Proxy: TCPパケットの送信
    Proxy->>+Web: TCPパケットの転送
    Web->>Web: 返却
    Web->>-Proxy:
    opt
        Proxy->>Proxy: 復号化/再暗号化
    end
    Proxy->>-Browser:
    deactivate Browser

Proxyを「透過」させるのに必要な実装

前述した仕組みを踏まえると、HTTPS通信にてProxy処理を「透過的」に行うには、ブラウザ/ツールなどから何かしらの手段でTCPのパケットを横取りし、パケットを送信する前にProxyにCONNECTリクエストを送った上で、横取りしたTCPパケットを再送してあげればよいことになります。
（また、HTTP通信の場合でも、相手先のProxyの実装にもよりますが、同様にTCPパケットを転送することで透過的に扱うことができます）

Linux上では、だいたい以下のような設定をすることで上記を実現できます。

flowchart TB
Web[接続先]
Browser[ブラウザ/ツールなど] --> nftables
subgraph nftables
    direction TB
    decision1{内部IPへの通信か？}
    decision1 -->|No| decision2
    decision2{port 443 or 80への通信か?}
end
decision1 -->|Yes| Web
decision2 -->|Yes| moproxy
decision2 -->|No| Web
moproxy --> Web

moproxyの設定例

moproxyの設定例を示します。WSL2上のubuntuを前提に書いているため適宜読み替えて貰えればと思います。

今回はProxyがTLSの復号・再暗号化を行うので、必要な中間証明書をインストールします。
※信頼できる証明書をインストールするように注意してください！

sudo install -m 644 証明書パス.crt /usr/local/share/ca-certificates/internal_ca.crt
sudo update-ca-certificates

moproxyをインストールします。

TMPDIR=$(mktemp -d)
curl -fL -o "${TMPDIR}/moproxy.deb" 'https://github.com/sorz/moproxy/releases/download/v0.5.1/moproxy_0.5.1-1_amd64.deb'
sudo dpkg -i "${TMPDIR}/moproxy.deb"

下記ファイルを環境によって読み替えながら設置します。

# /etc/systemd/system/moproxy.service.d/override.conf
[Service]
EnvironmentFile=
EnvironmentFile=/etc/default/moproxy
ExecStart=
ExecStart=/usr/bin/moproxy --host $HOST --port $PORT --list /etc/moproxy/proxy.ini

# /etc/moproxy/proxy.ini; chmod 600 推奨
[server-1]
address=proxy.fqdn
protocol=http
http username = username
http password = passw0rd

# /etc/default/moproxy
HOST="::"
PORT="2080"

最後にsystemdを設定します。

sudo systemctl daemon-reload
systemctl is-enabled moproxy.service || sudo systemctl enable moproxy.service
sudo systemctl is-active moproxy.service && sudo systemctl restart moproxy.service || sudo systemctl start moproxy.service

上記にて、port 2080で待ち受けるサービスが作成されます。

nftablesでの設定例

nftables自体はカーネルの機能としてインストールされているため、systemd-unitファイルを用意します。
特にDockerを利用している場合は、デフォルトで用意されているnftables.serviceを使うと、Docker用のネットワーク設定がリセットされてしまうため、個別にnftコマンドを呼ぶようにします。

unitファイルは、nftコマンドを直接呼びdaemonが起動しないので、Type=oneshotを設定します。また、moproxy.serviceへの依存関係を持たせたいため、RemainAfterExit=yesをセットします。

nftables上では以下のルールを設定します。

proxyという名称の新規tableを作成
proxy tableにpreroutingのnat chainを追加 ※ルーティングされてきたパケット用、Dockerなど
proxy tableにoutputのnat chainを追加 ※ホストからのパケット用
内部IPの場合はacceptし何もしない (下記例だとクラスAアドレス)
tcpの宛先ポートが80,443の場合は、port 2080にパケットを転送する

# /usr/local/lib/systemd/system/nft-proxy.service
[Unit]
Description=nftables proxy
Wants=moproxy.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft add table proxy
ExecStart=/usr/sbin/nft add chain ip proxy prerouting '{type nat hook prerouting priority 10;}'
ExecStart=/usr/sbin/nft add chain ip proxy output '{type nat hook output priority 10;}'
ExecStart=/usr/sbin/nft add rule proxy output ip daddr 10.0.0.0-10.255.255.255 accept
# ExecStart=/usr/sbin/nft nft add rule proxy output ip daddr  accept
ExecStart=/usr/sbin/nft add rule proxy output tcp dport {80, 443} redirect to 2080
ExecStart=/usr/sbin/nft add rule proxy prerouting tcp dport {80, 443} redirect to 2080
ExecStop=/usr/sbin/nft flush table proxy

[Install]
WantedBy=multi-user.target

※今回はProxyサーバが80でも443でもないポートを利用していたので、特にループしていませんが、Proxyサーバが80か443を利用している場合は宛先IPによるacceptルールを追加する必要があります。

WSLでの設定例

WSL上で自動的にプロキシ設定しないよう、wsl.confを設定します。

# %USERPROFILE%\.wslconfig
[wsl2]
autoProxy = false
dnsTunneling = true

注意点

今回の構成では力業でTCPパケットを転送するということを行っているため、当然UDPを利用する通信(QUICやDNS)はProxyにリダイレクトされないです。

特にProxyへの除外先をIPではなくFQDN名で指定したいというニーズがある場合、この構成ではうまく動きません。moproxyの設定ファイルにはFQDN名でルール設定できるように見えますが、上記の構成ではmoproxy自体はTLSを復号しないため、FQDNを読む手段がなく動きません。(相手先のProxyがsocksv5などに対応していて、moproxyでCNIを読める設定にすれば可)

やはりProxyを使わざるを得ない環境では実現できる構成に制限がつくということかなと思います。

小ネタ

今回の設定では必要ないですが、Proxyへの認証時にはユーザー名やパスワードのURLエンコードが必要になるケースがあります。jqでは@uriを使うことでワンライナーでURLエンコードをやってくれるので、紹介しておきます。

# 例
PROXY_PASSWORD=$(systemd-ask-password --keyname=proxy.password "プロキシログイン用パスワードを入力してください: ")
PROXY_PASSWORD=$(echo "${PROXY_PASSWORD}" | jq -Rr @uri)
https_proxy="http://${PROXY_USERNAME}:${PROXY_PASSWORD}@${PROXY_URL}" curl -fL -o ...

さいごに

Proxyを介したコネクションはツールの実装によるところがあり、トラブルが起こりやすいですが、この方式であればツール側はProxyの存在を気にせずに通常通りのリクエストを行うことができます。実は、Rancher Desktopは内部で同じ仕組みを使っており、いい仕組みを考える人がいるもんだと感心をしました。

また、moproxyはRustで書いてあり、動作を理解するために今回初めてまともにRustのソースコードを読んだのですが、とてもよい勉強になりました。自分で一から書けるかは置いておいて、読むのに当たっては結構好きな言語かもしれないという発見もあったので、機会があれば自分で書いたりもできればと思います。（特にマイコン向けとかで低レイヤーの実装が必要になった際には挑戦してみたい気がします）

参考

先人たちも色々な工夫をされていたようなので、こちらも参考にしてみてください。

ProxyとDockerと新人社員と時々わたし
ローカルプロキシで認証プロキシの煩わしさを解消！

1.NATの作成や、FWのルール設定などのバックエンドとして機能する ↩

Software Design 2025年8月号「2038年問題を考える」を寄稿しました

2025-07-17T15:00:00.000Z

はじめに

こんにちは、2025年4月新卒入社、Cyber Security Innovation Group (CSIG) 所属の星名藍乃介（HOSHINA Rannosuke）です。

技術評論社様（以下敬称略）の Software Design 2025年8月号　特別企画「2038年問題を考える」に寄稿する機会をいただきました。

Software Design 2025年8月号は 2025年7月17日発売ですので、ぜひご覧いただければ幸いです。

今回は、「2038年問題を考える」コラムに寄稿させていただいたことへの思いと、入社4か月目というフレッシュな視点から執筆活動に対する思いについてお伝えできたらと思います。

Software Design とは

「Software Design」は、技術評論社が発行している、プログラミングやOS、Web技術など、ソフトウェア開発全般に関する情報を提供する月刊誌です。

プログラミングの具体的なテクニックから、OS、Web技術、データベース、ネットワーク、セキュリティといった幅広いITの基礎知識、さらには最新の開発手法やチームマネジメントに至るまで、多岐にわたるテーマを深く掘り下げて解説しています。

単なる情報の羅列ではなく、実際に現場で役立つ実践的なノウハウや、技術の背景にある設計思想、考え方に焦点を当てているのが大きな特徴です。

Software Design「2038年問題を考える」寄稿に対する思い

今回、Software Designという多くの方に愛読されている雑誌で2038年問題についてお伝えする機会をいただき、大変光栄に思っています。

このテーマは、私が大学時代から関心を持ち、その脅威を広く知ってもらいたいと活動を続けてきたものです。

2038年問題とは

2038年問題は、UNIXやC言語に関わるシステムにおいて2038年のある時刻以降の時刻を表現できなくなり、その結果として様々な不具合が生じうる問題です。

コラムでも一部の脅威性評価の結果に言及していますが、影響範囲はいまだ不明瞭な部分が多く、社会全体で協力して解決に取り組むべき重要な課題だと考えています。

寄稿の経緯

私はこの問題の深刻さを以前から認識しており、大学院当時から情報処理学会論文誌への投稿、カンファレンスや勉強会での登壇活動を通して、その脅威性の周知に努めてきました。

そして、こうした活動を続けてきた中で、大学院時代の担当教員である上原哲太郎先生から「Software Designで2038年問題について書いてみないか」とお声がけいただきました。上原先生との共著という形で、長年の思いが実を結び今回の執筆に至ったことを、大変嬉しく感じています。

寄稿内容

記事では、UNIX timeが広く普及した歴史的経緯、それゆえの影響範囲の広さ、それによる2038年問題対応の困難さ、C言語における影響と64bit化対応といったトピックをご紹介しています。

組み込み開発に携わるエンジニアの方々はもちろん、ソフトウェア開発に関わるすべての方にとって、問題の理解と今後の対策の一助となれば幸いです。

ぜひ手に取ってご覧ください。

業界貢献に対する思い

ここからは、私個人として業界貢献にどのような思いを抱いているのか、そして入社4ヶ月目の今、それをどのように育んでいきたいかをお話しできればと思います。

私は就職活動中、「会社に属してもソフトウェア業界全体と良い関係を築き、エンジニアリングが面白くあり続けてほしい」という思いがありました。

フューチャーの多くの社員が執筆活動、OSS貢献、ガイドライン公開などに積極的に取り組んでいることを知り、私自身の目指す方向性と合致すると感じました。

私がフューチャーに入社して感じたのは、 社会全体のIT基盤を支えることが、ひいては自社の事業成長にも繋がるという考えから、多くの社員が業界貢献を重視している 傾向があるということです。

例えば、技術書や技術雑誌への執筆・翻訳活動を通じて、多くの社員がその知見を広く社会に発信しています。

今回の Software Designへの寄稿もその一例ですし、過去には『Real World HTTP』や『実用 Go 言語』、『Webフロントエンド E2E テスト』といった書籍の執筆・翻訳にも携わっています。

また、社内で培った設計のノウハウをまとめたアーキテクチャ設計ガイドラインのように、自社の知見を外部へ公開し、広く役立ててもらう取り組みも行われています。

さらに、Vuls や Vue.jsといった、多くの開発者が利用するオープンソースプロジェクトへ積極的に貢献しているコントリビューターも数多くいます。

私個人としても、日々の開発で利用させてもらっている多くのOSSや書籍といった共有資産に、自分も何か貢献できたらという思い があります。

会社がこうした活動を推奨し支援してくれることで、業界全体の成長とフューチャー自身の事業発展という好循環が生まれていると実感しています。

当面は、今回のような技術誌への寄稿や社内での知見共有を通じて、学んだことを着実に発信していきたいです。

そしてこれから経験を積んでいく中で、カンファレンスでの登壇やOSSプロジェクトへの貢献といったことにも、いずれは挑戦できるよう、一歩ずつ成長していければと考えています。

自身の専門性を高めながら、微力ながらも業界の発展に貢献できるエンジニアになれたら嬉しいです。

2025年 8月号のみどころ個人的推し

『Software Design 2025年8月号』は、私が寄稿させていただいた「2038年問題」の特別企画以外にも、個人的に心惹かれる記事が盛りだくさんの号です。

特に注目したいのは、リファクタリングの適切な判断とビジネス価値に焦点を当てた特集です。この特集には、なんとミノ駆動さんや及川卓也さんをはじめとする著名なエンジニアの方々も寄稿されており、現場で培われた実践的な知見がたくさん詰まっています。

「2038年問題を考える」コラムはもちろんのこと、他の素晴らしい記事にも目を通していただけると嬉しいです。

おわりに

今回のSoftware Designへの寄稿は、入社4ヶ月目の私にとって非常に貴重な経験となりました。

学生時代からの「2038年問題」への取り組みが、このような形で世の中に発信する機会に繋がったこと、そして日頃から憧れていた執筆活動をスタートできたことを、心から嬉しく思っています。

この貴重な機会を与えてくださった技術評論社様には、深く感謝申し上げます。

今後もこの経験を糧に、精進してまいりますので、どうぞよろしくお願いいたします。

子育てDIY：YouTubeの視聴をご褒美に変えた話

2025-06-22T15:00:00.000Z

はじめに

子育てをする中で、意外にも本職の知識でDIYして役に立つことってありませんか？子どもの年齢や家庭でのデバイス・IT環境も千差万別ありますが、抽象化した悩みとしては2つに集約すると思います。

子どもが夢中になっている事を後押しするためにやる事
子どもが夢中になっている事を制限するためにやる事

私の話で言えば、1はマインクラフトのサーバ構築やマルチプレイ環境の構築が当てはまり、
2は本記事の主題の通り、YouTube視聴に制限をかけてご褒美にした話です。

具体的な悩み事

男の子はとにかくゲーム/YouTubeが大好き！放っておくと無限にやってしまいます！
- 私の家庭では、やること自体はもちろんいいんですが、生活や体調に支障をきたすレベルに過度に依存しないルールを設けています
- Nintendo Switchはみまもりアプリで時間の上限が設定できるのでそれで問題ありませんでした
問題はテレビ/DVD含めた映像媒体です。一度つけたら最後、そんなに見たいわけでもないのに宿題/夕ご飯/風呂/歯磨きなど、とにかく自分で進められない。親が促しても『今じゃない』とかいろいろ言い訳つけて、21時過ぎてあわてて寝る準備するなんて言う日も普通にありました
そこで、『それらの準備を終わらせたらYouTubeを見ても良い』『早ければ早いほど見える時間が増える』、というルールと、それを実現するITインフラを準備しました

フローチャート

まず、子どもがYouTubeを見ることが出来るフローチャートはこんな感じです
基本的には、生活の上で最低限やるべきことをやった後で、ご褒美的な位置づけに変えました

構成

構成に関しては、特に難しい要素はありません

Windows はいつの頃からか、pac ファイルはローカルを参照できなくなったので、github 上に pac を公開しています
後は Proxy コンテナを docker compose up するかどうかで Youtube を見えるかどうかを制御しています

Config 等

子どものPC側の設定など

子どものアカウント（標準ユーザ）にて、Pac ファイルの指定

管理者アカウントにて、プロキシの設定を変更出来ない設定
- gpedit.msc でグループポリシーエディタを起動
- プロキシの変更が出来ない というポリシーを有効にする

github に上がっているPac

Pacファイル

user.pac

function FindProxyForURL(url, host)
{
    // . が含まれない場合。つまりローカルドメイン
    if (isPlainHostName(host))
        return "DIRECT";

    // ローカルIP宛の通信は direct
    if (isInNet(host, "192.168.0.0", "255.255.0.0"))
        return "DIRECT";

    // ドメイン名に基づくproxyの設定 基本的には www.youtube.com を向ければ問題な
い
    if (shExpMatch(host, "youtube.com"))
        return "PROXY 192.168.11.64:10080";
    else if (shExpMatch(host, "*.youtube.com"))
        return "PROXY 192.168.11.64:10080";
    else if (shExpMatch(host, "youtu.be"))
        return "PROXY 192.168.11.64:10080";
    else if (shExpMatch(host, "youtubekids.com"))
        return "PROXY 192.168.11.64:10080";
    else if (shExpMatch(host, "*.youtubekids.com"))
        return "PROXY 192.168.11.64:10080";
    else if (shExpMatch(host, "*.netflix.com"))
        return "PROXY 192.168.11.64:10080";

    // どこにも合致しない場合は、諦めて direct 接続
    return "DIRECT";
}

親のPC側でやること

docker compose でプロキシを起動

compose.yaml

services:
  proxy:
    image: ubuntu/squid:latest
#    volumes: # マウントは特に要りませんでした、細かくホワイトリスト設定したい場合などは必要
#      - ./work:/work
#      - ./conf/squid.conf:/etc/squid/squid.conf
    ports:
      - "10080:3128"

後は、子どもの準備が整ったら、docker compose up をすると youtube.com にアクセスが出来る様になります

その他細かい話

YouTubeは、動画のストリーミング自体は、別の FQDN から行われているらしく、全量は調べられていません。なので動画を見ている途中でコンテナを落としても動画は見えてしまいます。でも、次の動画は見えない挙動になります
逆にこの仕様を逆手にとって、21:00にコンテナを落とすので、「その動画を最後まで見たら終わり」という整理にしています

あとがき

話としては以上です。非常に簡単な仕組みなので、技術として難しい要素はないですね
子どもアカウント側で、『Proxy の変更が出来ない』制御はいらないかもしれません。『Proxy を変更すると見える！』という事がわかるくらいの年齢なら、どっちかというと自制心を育てる何かの活動をすべきです
タブレットやスマホも同様にwifi設定する際に、PAC URL を指定できるので、同じ制御が可能です
- 可能ですが、SIMを入れて外で使いたい場合は、PACを外すか、PAC内で判別させるか、もう一歩複雑な処理を入れる必要があります
Chrome Cast など経由ではなく、TVで直接 Youtube を見る場合は… ちょっとわかりません
Youtube のチャネルによって制御したいケースは、試していませんが、Proxyで中間CA局を立てて、中間サーバ証明書をhttpsリクエストのたびに発行する、という設定をすればおそらく細かい制御も出来るとは思いますが、httpsのどのリクエストパラメータにチャネル名が入っているのか？などは確認できていません
嫁の反応は、基本的には自分のスマホが取り上げられなくなる事、PCのキー操作を覚える事などは肯定的です。ですが、マインクラフトのマシンガントーク実況のチャンネルの音量がとても大きく、そこは否定的です😂

初めてのPostman

2025-04-13T15:00:00.000Z

はじめに

春の入門祭り2025 1日目です。

Web API開発プラットフォームとして高い人気を誇るPostmanの入門記事です。

Postmanとは

PostmanはWeb API開発のあらゆる工程を支援するプラットフォームです。

この、Web API開発プラットフォームという用語は初見ではイメージがつきにくいかと思います。例えば、curl や VS Coode拡張の REST Client とどの程度違いがあるのか、 OpenAPI Specification などとの関連性は？などフワッとしてしまいます。

まず、競合？となりえそうな周辺のツールと比較すると輪郭が明確になるのではないかという仮説のもと作成したのが下表です。

フェーズ/機能	詳細	Postman	競合ツールの例
設計	API定義 (OpenAPI) 作成・編集・検証	✅ API Builder (OpenAPI v2, v3, v3.1対応)	Swagger Editor, Stoplight Studio, VS Code (拡張機能)
開発	モックサーバ	✅ Collectionから生成可能。動的レスポンス対応。	Prism, Mockoon, WireMock
	クライアントコード生成	✅ 主要言語向けの基本的なスニペット生成	OpenAPI Generator
	サーバスタブ生成	❌	OpenAPI Generator
実行・デバッグ	GUIクライアント (Desktop/Web)	✅ リクエスト送信、環境変数、認証、スクリプト(JS)実行など多機能	Insomnia, Thunder Client (VS Code拡張)
	CUIクライアント	✅ Postman CLI (Collection実行、CI連携), Newman	curl, HTTPie
テスト	機能テスト/E2Eテスト	✅ Collection Runner, スクリプトによるアサーション、データ駆動テスト、CI/CD連携	runn, Playwright (API Testing)
	パフォーマンステスト (負荷テスト)	✅ 基本的な負荷テスト (仮想ユーザー数制限あり ※プラン依存)	k6, Gatling, JMeter
	APIセキュリティテスト	⚠️ 基本的なテストは可能だが、専門的な脆弱性スキャンは限定的	OWASP ZAP, Burp Suite, 42Crunch
運用・管理	APIゲートウェイ	❌	AWS API Gateway, Kong
	APIカタログ/ディスカバリ	✅ Private/Public API Network (限定的)	Backstage, Port

これらの機能カバレッジを見ると、Postmanとしての主軸は「実行・デバック」を中心として、開発者体験を上げるように機能を追加していったのかなと推測できます（バイアスがかかった見方かもしれません）。

ただし、同じできることと言ってもPostmanは長年改善が続いているだけに、優れた仕組みになっているところも多いです。例えば、Web APIにリウクエスト送信ができるといっても、OAuth2認可の設定がPostmanでは容易に可能です。WebSocketや、少しレイヤが異なりますがGraphQLや最近MCPサーバでも注目度が高まっているJSON-RPCへの対応も、差別化要素です（Postmanはいずれも対応しています）。

PostmanのWeb APIクライアント機能について

私が初めてPostmanを触ったのはおそらく2015年あたりで、当時はデスクトップアプリケーションしか存在しなかった印象が強いです。しかし、2025年の現在、多くの実行環境でPostmanを利用できます。リッチな curl 的な位置づけで利用を始めようとすると、大体以下の3つのうちどれかから選ぶことができると思います。この進化具合に最初、驚きました。

ブラウザ
デスクトップアプリケーション
VS Code拡張

それぞれの使い分けですが、基本的には以下のように選択、使い分けすると良いでしょう。

ブラウザ
- デスクトップアプリケーショに比べ、一部、機能制約がある
- とはいえ、初見はアプリのインストール無しで試せるので非常に気持が楽。使い勝手をまず試すにお勧め
- 制約というのは、主にCORSなどで生じ、機能を開放するためには別途、リクエストを仲介するローカルでリバースプロキシのように動作するミニアプリケーションをインストールが必要で、結局インストールするのであれば..という気持ちになりがち
デスクトップアプリケーション
- 機能が最も豊富で、制約も少ないため公式としても推奨している。インストールが可能であれば、本格的に利用する場合に利用すると良い
VS Code拡張
- 主要なプロトコルはカバーしているものの、GraphQLなどまだ利用できない機能がある
- とはいえ、普段のエディタがVS Codeである場合、エディタの切り替えをしなくても済むという利点が大きく、Web開発が主体であれば適時取り入れておくと良さそう

PostmanのWebアプリ版が個人的に面白い!

さて、ここで注目したいのが、PostmanのWebアプリ版です。WebAPIアクセスは curl で十分じゃないかなと思われる方も多いと思います。そんな中、なるべくツールのインストールなどのセットアップや依存関係なしに利用できるブラウザ版は、利点が大きいと思います。

しかし、気になるのはその実現手段です。通常、PostmanにログインしてWebアプリ版を利用すると、postman.co のサブドメインがユーザーごとに割り当てられます。そうすると、別ドメインのWeb APIサーバ（ほぼ全てがこのケースでしょう）に対してリクエストを送ると、通常は単純リクエストではないと思われるため（≒ Content-Type:application/json を設定すると思われるため）、ブラウザ側がプリフライトリクエストを送信してしまいます。

もちろん、Web APIサーバ側がこれに対して、 postman.co のサブドメインに対して、適切にOPTIONSメソッドで許可してもらえれば回避できますが、それだと利便性が著しく低いです。しかし、PostmanのWebアプリはこれを巧みに回避しています。初めて動かした際に、なんでこれが疎通できるんだろう？と驚きました。

これを実現しているのが、「エージェント」という仕組みです。

Webアプリ版 Postmanエージェント

Postmanエージェントは、Webアプリのフッターをクリックすると、選択肢が表示されます。デフォルトでは「自動選択」になっているため、初心者の人は意識する必要がまず無いでしょう。

おそらく、自動選択で「クラウドエージェント」となっている方が多いと思います。これの仕組みですが、直接PostmanのWeb画面から、指定のリクエストを送るのではなく、Postman社のサーバを経由してAPIがリクエストされる仕組みなようです。

クラウドエージェントのサーバは postman.co のサブドメインと同一のエンドポイントであるため、CORSは発生しません。同時に、クラウドエージェントはブラウザではないため、本来のリクエスト先であるWeb APIサーバへのアクセスにCORSは発生しません。

この仕組みに気がつくと、「Cloud Agent Usage」の月毎の実行回数制限1000回の意味が分かります。

クラウドエージェントは、Postman側のサーバリソースを使用するため、少なくてもフリープランでは利用回数の上限があるという訳です。

しかし、簡易的に利用できるという意味ではクラウドエージェントの回数制限はほぼ気にする必要はなく、後述する回避方法もあるため中々考えられた仕組みに感じます。

クラウドエージェントの制約

クラウドエージェントは月1000回までという制約がありますが、他にもメジャーな制約があります。仕組み上、localhost やVPC内のプライベートなAPIへの接続はできません。

これは、クラウドエージェントが postman.co という外部環境に存在するため、原理的に回避しようがないでしょう（プライベートAPIの場合、クラウドエージェントが稼働する外部IPのインバウンドを開放することで、リクエストを到達させることも可能だと思いますが、セキュリティ上難しいことが多いでしょう）。

このような場合、Webアプリ版のPostmanではいくつかの対応方法があります。具体的にはエージェントを切り替えです。

デスクトップエージェントを利用する
インターセプターエージェントを利用する
ブラウザエージェントを利用する

デスクトップエージェント

デスクトップは先に述べたように、追加でインストールするミニアプリケーションです。リバースプロキシのように動作します。動作イメージとしては、下図のようにブラウザと同じPC上で動作し、WebAPIサーバへのリクエストを仲介します。

概念的には上図のような構成ですが、内部的にはもう少し複雑な作りなようです。

※画像は https://blog.postman.com/introducing-the-postman-agent-send-api-requests-from-your-browser-without-limits/ より

上記のブログ記事にて、Postmanエージェントは、WebSocketを使用したTCP接続を利用とあり、またサーバサイドのAgent Serviceを経由するともあるため、デスクトップエージェントがブラウザからリクエスト情報を受信するフローはもう少し複雑かもしれません。

なお、このデスクトップエージェントは、Safariには対応していないため、Safariには後述するインターセプターエージェントが有効です。

インターセプターエージェント

次に紹介するのは、インターセプターエージェントという、「ブラウザの拡張機能」を用いた仕組みです。ブラウザの拡張機能でリクエストをフックできる仕組みが存在し、それを用いてブラウザの拡張機能上で、リクエストをプロキシすることで、CORSを回避しているようです。

拡張機能場だと、ブラウザで動作するスクリプトより高い実行権限があるということから可能になっているのだと思います。Safariやデスクトップエージェントをインストールできないが、Chrome拡張であれば可能（このケースがあるか不明ですが）に有効でしょう。

なお、インターセプターエージェントは、自己署名証明書が使えない、クライアント証明書の使用も不可など、いくつか制約も存在します。

ブラウザエージェント

最後に紹介するブラウザエージェントですが、これはブラウザから直接リクエストを送信するモデルです。そのため、CORSが発生すると利用できません。 localhost などの開発サーバなど限定された場合など、追加でインストール無しで使えるため便利かもしれません。

ちなみに、プリフライトリクエストが発生しなさそうなGET要求の場合には、けっこう使えるのでは？と思いましたが、サーバ側がOPTIONSメソッドを明示的に許可する動作をしない限り利用できませんでした。

例えば、GitHub Pagesを活用して擬似REST APIサーバーを作る Qiita にある、JSONファイルは GitHub Pagesでホスティングされています。ここにあるJSONファイルに対してリクエストを投げると、CORSエラーになります。リクエストヘッダなどを追加していないため、単純リクエストになるかと思いましたが、プリフライトリクエストが飛んでしまいました。

なんでだろうとリクエストを確認すると、Postman-Token という項目がリクエストヘッダーに追加されていたためでした。

これにより、単純リクエストではなくなり、プリフライトリクエストが発行。GitHub PagesはOPTIONSメソッドを返さないので、おそらく405 Method Not Allowedになり失敗。CORSエラーとなるという具合だと思います。

また、gRPC、GraphQLリクエストの送信には対応していないため、制約も多いです。

このあたり、各エージェントの制約については公式ドキュメントにまとめられているので、チェックすると良いでしょう。

https://learning.postman.com/docs/getting-started/basics/about-postman-agent/

まとめ

PostmanのWeb版のエージェントの仕組みが色々考えられており、仕組みを理解しようとすると面白かったという話でした。

なお、最初からデスクトップ版をインストールできれば、例えばクラウドエージェントの1000回制約などもなくなりますし、あえてWeb版を使い続ける必要はないかもしれません。しかし、内部の構成を理解しておくと表面上の制約の理解度も高まり、トラブルシューティングにも強くなると思います。

それでは良いPostmanライフを。

最後まで読んでいただきありがとうございました。

新卒 2 年目社員の Software Design 寄稿

2024-12-26T15:00:00.000Z

こんにちは。 Technology Innovation Group（TIG）所属の小澤です。2022 年の 10 月にフューチャーに新卒で入社しました。最近は、新規 Web アプリ構築の全体アーキテクチャ設計や開発をしています。

技術評論社様（以下敬称略）の 『Software Design 2024 年 8 月号』 に記事を寄稿する機会をいただけましたので、その話をご紹介します。

新卒 2 年目の社員が雑誌へ寄稿というと、どのような流れで進むのか想像がつかないという方も多いと思います。この記事でその流れをご紹介し、興味のある方には、ぜひご自身でもチャレンジするきっかけにしていただければ幸いです。

はじめに: Software Design とは

技術評論社の『Software Design』は、IT エンジニア向けの月刊誌です。その時々のトレンドに合わせて、入門から実践まで様々な特集が組まれます。

最近は 2018 年 - 2023 年の各号のデータを 1 冊の価格で購入できる『Software Design 総集編』も発売されました。私自身も活用しており、まだ新卒からの経験年数が浅い身にとって、ここ数年の技術トレンドの変遷が一望できて面白いです。

フューチャーの社員と執筆活動

さて、フューチャーの社員の一部は、通常の業務とは別に執筆していることがよくあります。たとえば、

『Real World HTTP』（オライリー・ジャパン）
『実用 Go 言語』（オライリー・ジャパン）
『ソフトウェア設計のトレードオフと誤り』（オライリー・ジャパン）
『［入門］Web フロントエンド E2E テスト』（技術評論社）

などの書籍（初版発行日順）は、いずれもフューチャー社員が執筆や翻訳に関わっています。

そして、書籍だけでなく雑誌『Software Design』に寄稿する例も多数あります。今年 2024 年は 8 月、9 月、10 月の 3 か月連続でフューチャー社員が寄稿しました。私が担当したのは 8 月号です。

9 月号と 10 月号については、ぜひ担当社員のブログ記事をご覧ください。

Software Design 2024年9月号 Goのエラーハンドリングと向き合うベストな設計戦略を徹底解剖を寄稿しました
Software Design 2024年10月号受託開発における設計ドキュメントの課題と解決案作成・管理のヒントを探るへの寄稿

書籍や雑誌の執筆・寄稿に至る経緯は様々と聞いていますが、最近はこの技術ブログが端緒となるケースが多いように思います。出版社の方がブログ記事を見てくださり、それを拡充・発展させる形で企画を進めるという流れです。

Software Design 8月号寄稿の経緯

勉強会から技術ブログへ

私は 8 月号の 1 記事を担当させていただくことができましたが、そこに至った経緯もこの技術ブログに投稿した 2023 年の記事に始まります。

私は通常のプロジェクト業務とは別に、社内の「CCoE（Cloud Center of Excellence）」組織、すなわちクラウド活用を推進する組織の活動に参加しています。当時その中での 1 つの取り組みとして、幅広いクラウド技術の学びを共有する勉強会が行われていました。その勉強会で、私は近年注目を浴びている CDN エッジでのコード実行に関する入門的なまとめを発表しました。

それ以前は、現代の Web アプリケーション開発で CDN がよく利用されることは把握していましたが、CDN のしくみや CDN エッジでコード実行する意義や特殊性、具体的な方法などはあまり分かっていませんでした。そこを勉強し、自分の言葉で整理することで、できる範囲を増やしアーキテクチャ設計スキルを強化することが、この発表の目的の 1 つです。

この発表はマークダウン形式の資料にまとめていたので、そのまま技術ブログ記事にする提案をもらいます。そうして実際に投稿したのが「CDN 入門とエッジでのアプリケーション実行」です。

Software Design の特集へ

少し時間が経って 2024 年の前半、Software Design の編集者の方から、「技術ブログ記事を見たので、8 月号の特集を担当するのはどうか」という旨の大変貴重なご提案をいただきました。 8 月号のメイン特集は 2 本立てでその 1 つが全 3 章の「CDN エッジ」です。その第 1 章の入門記事を担当するご提案でした。ほかの章は別の担当の方が執筆します。

元の技術ブログ記事は、CDN の入門に始まり、 Web アプリと CDN の関係を復習し、Cloudflare Workers を例にエッジでのコード実行を実際に試して終わりという構成でしたが、8 月号特集ではハンズオンや実践例は後の章で行うということもあり、構成・目次を変更して内容を再整理することになります。

記事の再構成

Software Design の読者は、完全初心者という人は多くないので、元の記事の初歩的な内容は最小限に絞り、各 CDN サービスの紹介や違い、具体的なユースケースを拡充しました。編集者の方と何度かやり取りをして、より効果的な順序・内容となるようにブラッシュアップします。最終的な構成は次のようになりました。

第1章 CDNエッジとWebアプリの関係性

速習 Web アプリ … 特集の論点を理解するために必要な Web アプリの前提知識をリクエストのマッピングに注目して整理します。
Web アプリの実現形式 … サーバーサイドレンダリング（SSR）、クライアントサイドレンダリング（CSR）を解説し、Web アプリの動的な振る舞いと静的な振る舞いを整理します。
CDN と Web アプリ … SSR と CSR の合わせ技など、近年の Web フロンエンド事情を紹介し、各方式と CDN の関連性を見ます。
CDN のしくみ … CDN の基本的な構成要素を整理します。
ユーザーの近くのエッジロケーションに誘導するしくみ … CDN を実現する方式の一例として順を追って解説します。
CDN サービスの例 … CDN を提供するサービスの特徴を簡潔に紹介します。
CDN エッジでのコード実行 … エッジサーバーでコード実行ができるサービスの紹介と特徴、具体的なユースケースを解説します。
CDN の使い道 … 従来の用途から近年のエッジランタイムまで、CDN の役割を振り返り、どのような場面で CDN 関連の技術を活用できるか考えます。

興味を持った箇所があれば、ぜひお読みいただければ嬉しいです。

執筆のポイント

ここからは半分自分用の戒めなのですが、今後初めて書籍や雑誌記事を執筆するという方のためにも、個人的に感じた執筆のポイントを（良かった点と改善点を踏まえて）紹介します。

大枠から決める・量を稼いで後で減らす

今回は元のブログ記事があったので、完全にゼロからのスタートではありません。とはいえ、ブログ記事と雑誌特集では必要な内容も異なり、多くを新たに生み出す必要があります。

何もない、あるいは混沌とした状態から「最初の形」を生み出すことは、かなりの負荷がかかるものです。この負荷は、高難度な新しいソフトウェアの基盤部分を自分自身がリードして作らなければならないときの負荷に似ています。気にすべき点や盛り込みたい点がたくさん思いつき、それを全部回収したものを作ろうとすると途方もない考慮が必要になってしまうものです。

そこで大事になるのは、大枠（目次）をまず雑に決めて、その後はとにかく量を稼ぐこと、いったん進捗率 100%（ただし精度 30%）という状態にすばやく到達することだと感じます。

誤解のないように言っておくと、出版物の価値は量ではなく質で決まります。しかし、あくまで執筆時のテクニックとしては、まず量を稼ぐようにしなければ質を向上させるだけの進捗を生めない側面があります。

いったんの形を作ることで、量を稼ぐ自己ノルマから解消され、質を上げるための余裕が生まれます。
雑に進めることは不安を感じるのですが、後で精度を上げたり変更したりするのは、意外と簡単にできるので大丈夫です。
また、編集者の方とのやりとりで軌道修正が生じる可能性は十分あり得るので、大枠だけでも早めに合わせておくのが大切だと感じます。

とはいえ、これは理想であって、最初のステップに負荷がかかることには変わりはないので、現実的には行き詰ってしまいがちです。私自身も今後うまくできるとは正直断言できません。
しかし、少なくとも意識として、まず量を稼ぐべきだと自分に言い聞かせることで、既存箇所の改善に目が行ってしまうといった問題を、ある程度は抑制できるでしょう。

実務での利用経験が少ない場合も、個人で手を動かして試す

入門や解説系の文章を書くとき、どうしても実務での利用経験がなかったり、少なかったりするものを扱う必要が出てきます。私のように新卒からの年数が浅い人などは特にそうだと思います。

これは仕方のないことなのですが、他方で、試したことのないものを聞きかじりで紹介もできません。当たり前の主張になってしまいますが、文章を書く「前」に、個人開発でよいので手を動かして試し、実践を作っておくことが大切です。文章を書いた「後」のチェックだけだと微妙なのは、自分の経験に基づいた「自分の言葉」で文章を書くことができなくなるからです。自分の言葉で書かないと、どこかの説明のつぎはぎや、意味理解をしない AI の説明のようになってしまいます。

引用・参考元はメモしておく

基本的に自分の経験を通した自分の言葉で書くことは上で述べたことですが、他方で元の文章がある場合は、著作権法上の引用要件を満たすように、元の文章を改変せず明確に引用する必要があります。引用の必要はない場合でも、参考元の情報を示すことが重要な場面は多いでしょう。

そうした引用・参考元は、後から辿るのが大変になるので、法的なリスクを避ける意味でも、調査時にしっかりメモしておくことが大切です。

文章を書く行為に慣れておく

これは今回よかった点ですが、文章を書く行為に日々の業務で慣れておくことはとても役に立ちました。例えば、開発中のソフトウェアのドキュメントや説明資料を、ある程度まともな体裁で書いておくことです。近年のモダンな OSS やサービスのドキュメントは、読み手を意識したわかりやすい書籍のような文体が増えていると感じます。そのあたりを参考にして、業務のドキュメントをマークダウンや Web などの文章形式で書くことは良いトレーニングになりそうです。

普段から各トピックの考えをまとめておく、論じ慣れておく

先ほど「何もない、あるいは混沌とした状態から、最初の形を生み出すことは、かなりの負荷がかかる」と書きました。しかし今後目指していきたいのは、そもそも「何もない、あるいは混沌とした状態」をスタート地点にするのではなく、「ある程度考えがまとまった状態」を普段から用意しておく、ということです。

たとえば、私はこれまで Web アプリのしくみを何度も説明する機会があり、かなり「論じ慣れ」ていました。そのため今回の記事執筆でも、慣れた箇所はほぼ負荷なく文章を書くことができました。他方で、今回調査や実践から始めることとなった CDN エッジに関わる箇所は、負荷が高かったように思います。

このように、普段から考えが整理され、論じ慣れているトピックは、執筆負荷が低くなります。出版物を執筆するのだから当然といえば当然なのですが、いざ書くときに困らないよう、理解と考えを表明するアウトプットを定期的に出しておくことは重要だと感じます。

ベテランの執筆陣は、このあたりのベースの力がやはり強いのだと思います。私自身も（最近全然できていない）技術ブログへの投稿などを増やして鍛えていきたいところです。

おわりに

この記事では、「新卒 2 年目社員の Software Design 寄稿」について、その経緯と振り返りを行いました。

将来の自分が次の本や雑誌に挑戦するとき、この記事を見直した上で、良いものを作れればと思います。
また、技術書や雑誌の執筆に興味がある方にとって、イメージがより鮮明になり、挑戦する気持ちを後押しできれば幸いです。

Cloudflare Snippetsをやってみた

2024-06-13T15:00:00.000Z

こんにちは。Cloudflareの亀田治伸です。

動画・音楽配信システム構築、決済代行事業者、AWSエバンジェリストを経て現職(Cloudflare)となります。得意領域は、認証、暗号、ネットワークを中心としたセキュリティ、映像配信、開発手法に見る組織論、クラウドアーキテクチャ、プレゼンテーションなどです。

はじめに

Cloudflare Snippetsは新しいCloudflareのサービスであり2023年6月にクローズドアルファ版がリリースされ、2024 Develoer Weekでは無作為に抽出された5％のユーザーが利用可能になっていました。6月頭より全ユーザーが利用可能となったサービスです。

https://blog.cloudflare.com/ja-jp/cloudflare-snippets-alpha-ja-jp

Cloudflare Snippets とは

Cloudflare の CDN/WAF はルールという機能を提供しています。変換ルール、キャッシュルール、オリジンルール、コンフィグルール、リダイレクトルール等多くの機能が存在しており簡単にHTTPベース通信の挙動を制御させることができます。

SnippetsはCloudflare Workersのプラットフォームを流用することで、ルールとして新しくJavaScriptの断片（これをSnippetsと呼びます）を実行させることができるようになりました。

Cloudflare Workers との違い

Cloudflare Workers はWeb Workershttps://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers という技術を活用しており通信にJavaScriptの処理を割り込ませることができます。

ただし専用ドメインが割り当てられるためアプリケーション、もしくはDNSでCNAMEやAレコードを設定する必要がある等の変更伴います。一方SnippetsはそのままCDN/WAFとして動作するのでより簡単に処理を割り込ませることができます。

また常に起動するWorkersと異なり、ルールエンジンと連携することで特定の条件に合致したときのみ起動、といった制御が可能です。

この性質により、1つ処理を1つのSnippetsとして分割しておくことで、1つの通信に複数のSnippetsを起動させる、ということも可能です。

また、Workersと異なり、最大実行時間は5msで最大メモリは2MB、パッケージの合計サイズは32KBと小さいのも特徴です。

さっそくやってみる

ではやってみましょう。

https://zenn.dev/kameoncloud/articles/6dec28de015f6f
https://future-architect.github.io/articles/20230427a/

等を参考にCDN経由のサイトを立てます。

マネジメントコンソールからRules→Snippetsをクリックします。
Create a Snippetをクリックします。

デフォルトで提供されるサンプルSnippetをそのままデプロイするためConfigure to add Snippet ruleをクリックします。
次にSnippet機能を制御するルールを作成します。

こうすることでクライアントが日本からの通信のみSnippetを起動させるということができます。
Configure to create snippet→Save and deploy snippetとボタンを押せば完了です。
サイトにアクセスすると以下のようにHeaderが付与されていれることがわかります。

デフォルトコードは以下です。

snippet.js

// Enter Snippet code below

export default {
    async fetch(request) {
        const response = await fetch(request);

        // Clone the response so that it's no longer immutable
        const newResponse = new Response(response.body, response);

        // Add a custom header with a value
        newResponse.headers.append(
            "x-snippets-hello",
            "Hello from Cloudflare Snippets"
        );

        // Delete headers
        newResponse.headers.delete("x-header-to-delete");
        newResponse.headers.delete("x-header2-to-delete");

        // Adjust the value for an existing header
        newResponse.headers.set("x-header-to-change", "NewValue");
        return newResponse;
    },
};

まとめ

いかがでしたでしょうか。

Cloudflareは他にもHTTPレイヤーを中心として様々な通信を処理する機能を提供しています。

https://zenn.dev/kameoncloud

でその機能を試してまとめているので興味のある方はぜひご覧ください。

Cloudflare R2 + NextCloudで作る自分専用クラウドストレージのススメ

2024-06-02T15:00:00.000Z

Cloudflare連載の4つ目です。

はじめに

みなさんこんにちは、TIG所属の大岩潤矢( @920OJ )です。

Cloudflareのサービス、Cloudflare R2と、NextCloudを利用した自分専用クラウドストレージの構築について紹介します。

Cloudflare R2とは

Cloudflare R2とは、Cloudflareが提供するオブジェクトストレージサービスです。誤解を恐れず簡単に言ってしまえば、Amazon S3のCloudflare版、という表現が当てはまると思います。

https://www.cloudflare.com/ja-jp/developer-platform/r2/

料金体系

Cloudflare R2の大きな特徴は、データ転送量が無料であることから、他社サービスに比べてコストを抑えて利用できることが挙げられます。以下にCloudflare R2の料金体系を整理します。

種別	月間無料枠	有料(月額)
ストレージ(データの保存)	10GB	1GB あたり 0.015 USD
クラスAの操作(状態の変更)	100万操作	100万操作あたり 4.50 USD
クラスBの操作(既存状態の読取)	1,000万操作	100万操作あたり 0.36 USD
転送(エグレス)	無制限	-

詳細はCloudflare R2の公式ガイドもご確認ください。

https://developers.cloudflare.com/r2/pricing/

例えば保存しているデータが10GB以内である場合、ずっと無料のまま使い続ける事ができます。転送量に課金は発生しないので、どれだけ転送しても（1,000万回以上操作しない限りは）無料です。

一方ストレージの課金は「ピークストレージの平均」という概念で計算されるため、注意が必要です。これは日割りで保存しているデータ量を計算するもので、月の最終日の保存量に対する課金ではありません。

A GB-month is calculated by averaging the peak storage per day over a billing period (30 days)

例えばある月の1日〜15日までは100GBを保存していたが、データを削除して16日〜30日は1GBまで減らした場合、以下の計算式で課金料が決定します。

100GB * 15/30 month + 1GB * 15/30 month = 50.5 GB-month
(50.5GB-month - 10GB 無料枠) * 0.015 USD = 0.6075 USD

Amazon S3とも比較してみましょう。微妙に料金体系は異なりますが、先程の表に当てはめてみると以下のようになります。

種別	月間無料枠	有料(月額)
ストレージ(最初の50TB)	5GB	1GB あたり 0.025 USD
PUT, COPY, POST, LIST操作	2,000操作	100万操作あたり 4.7 USD
GET, SELECT操作	20,000操作	100万操作あたり 0.37 USD
転送(最初の1TB)	100GB	1GBあたり0.114 USD

先ほど計算した同様のケースをAmazon S3で計算してみると以下のようになります。約2倍ほど高いようです。

100GB * 15/30 month + 1GB * 15/30 month = 50.5 GB-month
(50.5GB-month - 5GB 無料枠) * 0.025 USD = 1.1375 USD

NextCloudとは

オープンソースで開発されているNextCloudというセルフホスト型のストレージソフトウェアを利用し、自分専用のクラウドストレージを作成します。

https://nextcloud.com/

かつてownCloudというソフトウェアからフォークされたもので、ownCloudと比べるとチャットやビデオ会議機能が追加されているようです。

NextCloudでは基本的にNextCloudがインストールされたマシンのストレージをデータの保存場所としますが、「External Storage Support」というアプリ(プラグイン)をインストールすることで、各種外部ストレージサービスを保存場所に設定できます。

対応している外部ストレージサービスは以下のとおりです。

Amazon S3
FTP
NextCloud
OpenStack Object Storage
SFTP
WebDAV
ローカル

なぜCloudflare R2とNextcloudを組み合わせると良いのか？

今回は、NextCloudからCloudflare R2へ接続することにより、容量無制限かつ低コストの自分専用オンラインクラウドストレージを実現してみようと思います。

先述の通り、NextCloudでは外部ストレージとしてAmaon S3が利用できます。さらに、Cloudflare R2はAmazon S3のAPIと互換性があるため、NextCloudのバックエンドとしてCloudflare R2が利用できるという算段です。

この構成を使うのではなく、一般的なクラウドストレージサービス(Google Drive, iCloud等)で良いのでは？という声が聞こえてくるかもしれません。しかし、これには無視できない絶妙なコスト差が発生します。

以下は一般的なクラウドストレージサービスの料金比較です。

	Google Drive	OneDrive	iCloud	Dropbox
無料枠	15GB	5GB	5GB	2GB
50GB	なし	なし	130円/月	なし
100GB	250円/月	203.3円/月	なし	なし
200GB	380円/月	なし	400円/月	なし
1TB	なし	1,241.7円/月	なし	なし
2TB	1,300円/月	なし	1,300円/月	1,500円

一般的なクラウドストレージサービスでは、「使った分だけ課金する」従量課金ではなく、あらかじめ使いたい分のストレージ代金を毎月払っていくことになります。そして、往々にして各社用意しているプランは200GBから2TBまでの間が飛んでおり、例えば201GBのファイルを保存したい場合にでも2TB分の料金を払わざるを得ません。

ここで嬉しいのがCloudflare R2です。Cloudflare R2では従量課金であり、201GB保存した場合でも201GB分の料金を払うだけで済みます。計算すると2.865 USDで、1USD = 160円換算だと458.4円です。Google Driveでは1,300円払わなければならないところが、この方法だと458円で収まりました。

ちなみにCloudflare R2でのストレージ課金額が1,300円を超えるのはCloudflareに合計551.67GB以上のファイルを保存した場合です。(1USD = 160円換算の場合なので、円高になればより多くのファイルを保存できます)

つまり、保存したいファイルの総量が551.67GBに達する前まではこの方法のほうがおトクといえるでしょう。(2024年6月現在)

また、2TBを超える場合など既存のクラウドストレージの提供するプランを超えてしまっているときなども良い選択肢になるでしょう。一方で、同様のサービスにWasabiというオブジェクトストレージサービスがあります。こちらはCloudflare R2よりも安い1TB6.99USDで運用できるので、比較検討してみるのもよいでしょう。

https://wasabi.com/pricing

セットアップ

ここからは、実際にCloudflare R2とNextCloudを利用して自分専用のクラウドストレージを構築する方法について、ハンズオンの形で紹介します。

今回はプロジェクトの後輩にRaspberry Piを布教する目的も兼ねて、手持ちのRaspberry Pi 3 Model BにNextCloudをインストールします。大学生時代に4台まとめ買いして家に転がっていたものです。

事前にIPアドレスを固定し、SSH接続できるようにしてあります。この方法は本題からそれてしまうので、割愛します。

（もしセットアップにDockerが使えるのであれば、Dockerを使ったほうが何倍も楽にスタートできるのでおすすめです。今回のようにDockerを動かすにはスペック不足であったり、何らかの原因によってインストール出来ない場合にのみ、以下の方法で実施しましょう）。

MariaDB・nginx・PHP環境のインストール

インストールを始める前に、パッケージを最新化しておきます。

sudo apt update
sudo apt upgrade

データベースにはMariaDBを利用します。

sudo apt install mariadb-server

mysql_secure_installation コマンドでMariaDBのセットアップを実施します。自分は以下のようにセットしました。

Switch to unix_socket authentication → No
Change the root password? → Yes
Remove anonymous users? → Yes
Disallow root login remotely? → No
Remove test database and access to it? → Yes
Reload privilege tables now? → Yes

$ sudo mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
haven't set the root password yet, you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password or using the unix_socket ensures that nobody
can log into the MariaDB root user without the proper authorisation.

You already have your root account protected, so you can safely answer 'n'.

Switch to unix_socket authentication [Y/n] n
 ... skipping.

You already have your root account protected, so you can safely answer 'n'.

Change the root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] n
 ... skipping.

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!

mysql -u root -p でログインできるか確かめておきましょう。

$ mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 38
Server version: 10.11.6-MariaDB-0+deb12u1 Debian 12

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

ログインできたら、以下のSQLを実行してNextCloud用のデータベースとユーザを作成しておきましょう。

CREATE DATABASE nextcloud;
CREATE USER nextcloud IDENTIFIED BY '任意のパスワード';
GRANT ALL ON nextcloud.* TO nextcloud;

Webサーバはnginxをインストールします。Apacheでも良いですが、メモリがカツカツなので、個人的にはnginxをおすすめします。

sudo apt install nginx

インストールできたら、systemctlコマンドで自動起動を有効化しておきます。

sudo systemctl enable nginx

ブラウザからRaspberry piのIPアドレス宛にアクセスし、nginxのデフォルトページが表示されたらOKです。

続いてPHPをインストールします。デフォルトではPHP 8.2がインストールされるようだったので、リポジトリを追加してPHP 8.3をインストールします。以下コマンドを実行し、 php8.3 と php8.3-fpm 、それから各種モジュールをインストールします。

sudo wget -qO /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
sudo apt update
sudo apt install php8.3 php8.3-fpm php-mysql php-gd php-common php-xml php-json php-intl php-pear php-imagick php-dev php-mbstring php-zip php-soap php-bz2 php-bcmath php-gmp php-apcu php-curl

php8.3-fpm も同様にsystemctlコマンドで自動起動するようにしましょう。

sudo systemctl enable php8.3-fpm

/etc/nginx/sites-enabled/default を編集し、PHPを有効化しておきます。また、NextCloudに必要なリライトルール等もここに記載します。

location ~ \.php(?:$|/) {
        include snippets/fastcgi-php.conf;
        rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|.+\/richdocumentscode(_arm64)?\/proxy) /index.php$request_uri;

        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        set $path_info $fastcgi_path_info;

        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

今回は必要最低限のリライトルールを記載しましたが、本来は以下の公式ドキュメントにあるように、色々設定する必要がありそうです。本番運用する場合は設定しておきましょう。

https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html

ついでにPHPの設定を変えておきましょう。自分の場合セットアップがタイムアウトで落ちるようでしたので、タイムアウト時間を30秒から10分に伸ばしておきます。/etc/php/8.3/php-fpm/php.ini を編集します。

php.ini

max_execution_time = 600

NextCloudのインストール

続いてNextCloudのインストールを実施します。

sudo chown -R www-data:www-data /var/www/html
cd /var/www/html
wget https://download.nextcloud.com/server/installer/setup-nextcloud.php

ファイルを配置したら、http://(Raspberry PiのIPアドレス)/setup-nextcloud.php にアクセスします。PHPが正しくセットアップされていればSetup Wizardが表示されるので、「Next」を押下します。

今回は /var/www/html 配下にそのままインストールするため . を入力して「Next」を押下。

インストールが終了したら、「Next」を押下します。

続いて、 http://(Raspberry PiのIPアドレス)/index.php にアクセスし、管理者情報を入力します。

データベース情報の部分は、先述したSQLを実行した場合は、データベース名・ユーザ名ともに nextcloud になります。

ようやくインストール完了です。

Cloudflare R2バケットの作成

いよいよ本題です。Cloudflareの管理画面にアクセスし、R2バケットを作成します。

管理画面へログインし、左のメニューよりR2へ進み、「Create bucket」ボタンを押下します。

任意の名前を入力し「Create bucket」を押下します。

続いてAPIトークンを発行します。R2メニューの右上「Manage R2 API Tokens」に進みます（ユーザプロフィールから発行できるユーザトークンとはまた別なので注意）

「Create API Token」を押下します。

今回は閲覧だけでなく編集も行うため、最上位権限である「Admin Read & Write」を選択し、新規作成します。

最後にキーが払い出されます。以下の値をコピーしておきましょう。

Token
Access Key ID
Secret Access Key
Endpoint

接続設定

再度NextCloud側に戻り、接続設定を行います。

先述の通り、デフォルトでは外部ストレージ機能は有効化されていません。S3(Cloudflare R2)へ接続するため、Appsから有効化する必要があります。

右上のユーザアイコン→アプリ→注目のアプリへ進み、「External storage support」を有効化します。

その後設定画面に進み、「外部ストレージ」メニューからR2の設定を追加します。先ほど控えたR2のアクセスキー等を以下のように入力します。

最後にチェックマークをクリックし、左側に緑マークが点灯すれば設定完了です！

使ってみる

ホーム画面に戻ってみると、先ほど設定した「R2」フォルダが増えています。

実際にファイルをアップロードしてみましょう。ファイルをドラッグ&ドロップすると……

無事アップロードできました！

Cloudflare R2側にも反映されているようです。

おわりに

NextCloudのバックエンドとしてCloudflare R2を用いることにより、ある条件下ではおトクに自分専用のクラウドストレージを構築できました。ぜひ自宅に使っていないラズパイやミニPCが転がっている方、既存クラウドストレージサービスの見直しをしている方は、ぜひ構築してみてください！

以上、Cloudflare R2 + NextCloudで作る自分専用クラウドストレージのススメでした。

CloudflareでWebサイトのメンテナンスイン/アウトを実装

2024-05-30T15:00:00.000Z

Cloudflare連載4日目の記事です。

はじめに

TIG DXチームの小林弘樹です。

近年、CloudflareをCDNやDNSで活用しているシステムが増えている印象があります。宮崎さんの記事でもCloudflareを採用した事例が紹介されています。

CloudflareをCDNやDNSに利用しているサービスにおいて、CDNレイヤでメンテナンスイン/アウトを実装する方法を書いてみます。

概要

やりたいこと

Cloudflare上にメンテナンスページ（htmlファイル）をデプロイする
運用保守拠点からのアクセスはオリジンにアクセスさせ、その他一般ユーザーからのアクセスはメンテナンスページにリダイレクトさせる
Cloudflare APIを利用して、メンテナンスイン/アウトを自動化する

利用サービス

Cloudflare R2
Cloudflare Rules(Single Redirects)

ドメイン取得・管理

今回の構成はCloudflare上でドメインを管理していることが前提となります。
Cloudflareでドメインを取得したり、取得済みのドメインをCloudflareに移管する方法については、詳しくわかりやすい情報が多く公開されているため他の記事を参照してください。

Cloudflare R2設定

バケット構築

まずはバケットを作ります。
2024/05現在では凝った設定はできないため、ただ箱のみとなります。

resource "cloudflare_r2_bucket" "maintenance" {
  account_id = local.account_id
  name       = "maintenance-r2"
}

パブリックアクセス設定

Cloudflare R2の設定画面からパブリックアクセス設定の「ドメインに接続」をクリックし、Cloudflareで管理しているドメインを利用して任意のドメインを入力します。

ステータスがアクティブになったら完了です。

htmlファイルアップロード

メンテナンスページ（htmlファイル）のデプロイは自動化したいため、APIでのアップロードを行います。

Cloudflare R2のAPIは、制約は多いですがAWS S3 APIと互換性があるため、AWS CLIやAWS SDKなどと同様に実行できます。

今回はAWS CLIで実行します。

まずは、APIトークンを発行する必要があります。

Cloudflare R2の概要画面から「R2 APIトークンの管理」をクリックし、「APIトークンを作成する」をクリックします。

オブジェクトの書き込み権限を付与して作成します。
また、バケットはメンテナンスページ用のバケットに特定しておきましょう。

作成完了すると以下の情報が表示されるため控えておきます。

アクセスキーID
シークレットアクセスキー
エンドポイント

aws configureでアクセスキーとシークレットアクセスキーを設定し、以下のコマンドを実行します。

$HTML_PATHはアップロードしたいhtmlファイルのパス、$R2_BUCKET_NAMEはバケット名、$R2_ENDPOINTはエンドポイントに適宜修正してください。

aws s3 cp $HTML_PATH s3://$R2_BUCKET_NAME --endpoint-url https://$R2_ENDPOINT --region apac

リダイレクトルール設定

許可IPリスト作成

まずメンテンナンス中でもアクセスを許可したい運用保守拠点のIPアドレスリストを作成します。

下記のリストはTerraformからでも作れますが、著者が検証した限りでは何も変更を加えていないのにも関わらずapplyをする度にリソースが作り直されるという現象が起き、正しく設定されているのかがわかりづらく運用上困るため手動構築としています。

アカウント管理のリスト管理画面から、「リストを作成する」をクリックして作成します。

リスト作成後、許可したいIPアドレスを追加したら完了です。

リダイレクトルール作成

作成したIPリスト以外のIPリストからのアクセスはメンテナンスページにリダイレクトするように設定します。

localsで設定しているところは適宜修正してください。注意事項としては、ルールはrulesetという単位で作成され、リダイレクトルール全体で1つのrulesetである必要があります。

つまり、既に他のリダイレクトルールが存在していると作成できなかったり、後から別のリダイレクトルールを追加しようとするとrulesetごと更新になったりする点に注意が必要です。

resource "cloudflare_ruleset" "single_redirects" {
  kind    = "zone"
  zone_id = local.zone_id
  name    = "Redirect Rules"
  phase   = "http_request_dynamic_redirect"

  rules {
    action = "redirect"
    action_parameters {
      from_value {
        status_code = 302
        target_url {
          value = local.maintenance_page_url
        }
      }
    }
    expression  = "(not ip.src in $allow_ips_maintenance and http.request.full_uri ne \"${local.maintenance_page_url}\")"
    description = "Redirect from outside the maintenance location"
    enabled     = false
  }
}

なぜリダイレクトルールか

Cloudflareでこのようなリダイレクトを行いたいときには、他に以下の手段があります。

Cloudflare Rules(Page Rules)
Cloudflare Workers

このうちPage Rulesは最近非推奨となり、廃止されることが予定されています。

Workersはより細かく柔軟に設定が可能ですが、今回のような単純なリダイレクト制御の場合はそこまでは不要であるため、よりシンプルなリダイレクトルールを採用しています。

自動化設定

自動化についてはGitHub Actionsなどを想定してはしていますが、特定のサービスに依存はしないためコマンドのみ記載します。

APIトークン作成

まずはAPIで色々と実行するためにAPIトークンを作成します。

プロフィールのAPIトークン画面から「トークンを作成する」をクリックします。

権限は動的リダイレクトの編集権限とキャッシュパージの実行権限が必要です。

また後述するルールセットIDの調査のためにルールセットの読み取り権限も付けておきます。

その他は極力必要最小権限となるように設定しましょう。

作成が完了したらトークンの値を控えておきます。

メンテナンスイン

以下のコマンドでメンテナンスインを実現できます。

# R2バケットにメンテナンスページをアップロード
aws s3 cp $HTML_PATH s3://$R2_BUCKET_NAME --endpoint-url https://$R2_ENDPOINT --region apac

# リダイレクトルールを有効化
curl -X PATCH https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets/$RULESET_ID/rules/$RULE_ID \
    -H "Authorization:Bearer $API_TOKEN" \
    -H "Content-Type:application/json" \
    -d '{"description":"Redirect from outside the maintenance location","action":"redirect","action_parameters":{"from_value":{"status_code":302,"target_url":{"value": "$MAINTENANCE_PAGE_URL"}}},"expression":"(not ip.src in $allow_ips_maintenance and http.request.full_uri ne \"$MAINTENANCE_PAGE_URL\")","enabled":true}'

# キャッシュパージ
curl -X POST https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache \
    -H "Authorization:Bearer $API_TOKEN" \
    -H "Content-Type:application/json" \
    -d '{"purge_everything":true}'

メンテナンスアウト

以下のコマンドでメンテナンスアウトを実現できます。

# リダイレクトルールを無効化
curl -X PATCH https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets/$RULESET_ID/rules/$RULE_ID \
    -H "Authorization:Bearer $API_TOKEN" \
    -H "Content-Type:application/json" \
    -d '{"description":"Redirect from outside the maintenance location","action":"redirect","action_parameters":{"from_value":{"status_code":302,"target_url":{"value": "$MAINTENANCE_PAGE_URL"}}},"expression":"(not ip.src in $allow_ips_maintenance and http.request.full_uri ne \"$MAINTENANCE_PAGE_URL\")","enabled":false}'

# R2バケットのメンテナンスページ削除 ※デプロイ中は常時アクセス可能となっているため削除しておきます
aws s3 rm s3://$R2_BUCKET_NAME/$HTML_PATH --endpoint-url https://$R2_ENDPOINT --region apac

# キャッシュパージ
curl -X POST https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache \
    -H "Authorization:Bearer $API_TOKEN" \
    -H "Content-Type:application/json" \
    -d '{"purge_everything":true}'

【補足】ルールセットID（&ルールID）の確認方法

著者が調べた限りでは、画面上で簡単にルールセットIDを確認する方法がありませんでしたので、Cloudflare APIを利用して確認しています。

ルールIDについては、作成したルール詳細を画面で表示するとURL末尾に入っていますが、一応同様に記載します。

# ルールセットIDの確認
curl -X GET https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets \
    -H "Authorization: Bearer $API_TOKEN" \
    -H "Content-Type:application/json"

# ルールIDの確認
curl -X GET https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets/$RULESET_ID \
    -H "Authorization: Bearer $API_TOKEN" \
    -H "Content-Type:application/json"

さいごに

Cloudflare R2とリダイレクトルールを利用してメンテナンスイン/アウトを実装できました。

少しでもCloudflareを利用している方の参考になれば幸いです。

Cloudflare採用のアーキテクチャ選定

2024-05-28T15:00:00.000Z

Cloudflare連載3日目の記事です。

はじめに

こんにちは、TIGの宮崎将太です。

これまで個人/業務ともにあまりCloudflareを使用してきませんでした。クラウド前提で仕事をしていると、各クラウドプロバイダーが提供するCDNやWAFがあり、その部分だけ外部サービスを採用するメリットを見いだせなかったことが最大の理由です。

しかし、とある事情からCloudflare採用に至るケースが発生したので、その動機と比較検討内容を記事にしておこうと思います。

どんなアーキテクチャでCloudflareを採用したのか？

結論ですが、ハイブリッドクラウド構成でのCDN/WAFとしてCloudflareを採用しました。

構成は少しぼかしますが、メインのサービス提供はAWS、認証機能の提供のみAzureを使用しています。想定するユースケースにおいてコストメリットもあるため基本的なクラウド環境にはAWSを使用しているのですが、ある特定のケースでは認証領域においてAzureの方が機能的/コスト的優位であり、ハイブリッド構成を取っています。

Cloudflareに期待する役割はCDN、WAF（ついでにDNS）であり、各サービスへのゲートウェイとして機能しています。

取りうるアーキテクチャの比較

さて、これだけ見るといろいろと突っ込みどころがあるかと思います。

前提として、Azureの認証サービス側はWAF機能を賄ってくれなく、別途WAFと連携する必要があります。

もちろん、だとしてもやたらと採用サービスを増やすのは得策ではなく、各クラウドサービスで対応できるのであれば当然そちらの方がベターです。

CDN、WAF、DNSはAWS/Azure単体でカバーもできるので、考えられる以下3案を比較してみます。

AWSとAzureをそれぞれ独立させて管理する
AWSかAzureをゲートウェイとし、もう片方のクラウドにルーティングさせる
Cloudflareをゲートウェイとし、それぞれのクラウドにルーティングさせる

別サービスとしては当社にて採用実績のあるCloudflareとAkamaiを比較しましたが、Akamaiはコスト面で圧倒的に劣る（その分機能は豊富ですが）ので今回の比較からは除外します。

比較の前提として、CDN/WAFには以下の要素を求めます。

IP制限、リージョン制限等の一般的なアクセス制限機能
WAF保護ルールの継続的なアップデート
※その他機能はあれば尚良しで加点

上記を前提とした場合それぞれのクラウドでの採用サービス候補は以下とし、参考のため基本的な料金を載せておきます。

AWS: CloudFront + AWS WAF
- CloudFront 基本料金: なし, データ転送料(エッジ): 10TBまで0.114USD/月, データ転送料(オリジン): 0.060USD月, リクエスト料: 0.009USD/月
- AWS WAF 基本料金: なし, Web ACL: 5USD/月, ルール1件あたり: 1USD/月, リクエスト100万件あたり: USD 0.6USD/月, マネージドルール: ものにより5USD~30USD/月程度
  - マネージドルールの利用料にも寄りますが、100USD/月程度と過程します。
Azure: AzureFrontDoor Premium
- 基本料金: 330USD/月、データ転送量: 0.115USD/GB (エッジからクライアント) 0.06USD/GB (エッジから配信元)
Cloudflare: Cloudflare Businessプラン
- 料金: 250USD/月, データ量による従量課金: なし

（1）AWSとAzureをそれぞれ独立させて管理する

AWSではCloudFront/AWS WAF、AzureではAzureFrontDoorを採用し、それぞれ独立したシステムとするパターンです。
まずはこのパターンを考えたくなると思います。

他パターンと比較すると可用性ではAWS/Azureで独立しているので、何かしら障害が起きた場合でも相互に影響することはなく、余計な心配をする必要はありません。

ただし、同じCDN/WAFという機能にそれぞれコストを支払うことになるのと、機能的にもルールのメンテナンスに不安が残るのが痛いところ。ルールメンテナンスにWAFCharmなど外部サービスを組み合わせる手もありますが、その場合はAWS/Azureで2つライセンスが必要になるので、更にコストがかさみます（WAFCharmは2023年の料金改定で1ライセンスあたり十数万/月となりました。）

また、メンテナンスイン/アウトなどをCDNレイヤで実施する場合はAWS/Azureそれぞれで操作が必要になり、管理が煩雑になりがちです。

（2）AWSかAzureをゲートウェイとし、もう片方のクラウドにルーティングさせる

（1）を考えた時に、CDN/WAFのコスト/運用を圧縮しようと思うと片方のクラウドをゲートウェイ化する案も考えられます。

一見あり得る構成かと思ましたが、実際に検証をしてみたところ、少なくともCloudFrontからAzure認証サービスへのルーティングはAzure側がエラーステータスを返却してしまい、テクニカルサポートに相談をしても他クラウドプロバイダーとの連携はサポート外と言われてしまいました（これ自体は言われてみれば当然かと思います）。

仮に一時的に問題が解決したとしても継続的なサービス提供には不安が残るため、採用は見送りました。もちろん採用サービスによっては技術的制約が無い場合はあり、そのケースではこちらの案も取り得るかと思います。

ただし、その場合でも（1）同様WAFルールセットの更新に不安は残り、外部サービスで補強しようとすると結局（3）の方が安価になる可能性はあります。

（3）Cloudflareをゲートウェイとし、それぞれのクラウドにルーティングさせる

最後に件のCloudflareをゲートウェイとするパターンです。

CloudflareのWAFはCloudflare社が管理するマネージドルールの定期的なアップデートがある他、機械学習によって自動的にルールのアップデートがなされます。

また、ゼロトラストやCloudflare Workersなどの機能もあり、CDN/WAF/エッジとしての機能は比較的豊富です。ハイブリッドクラウド構成の場合はドメインを一箇所で管理できるメリットもあります。

Cloudfront/AWS WAFと比較すると多少値が張りますが、構成によってはクラウドプロバイダーそれぞれでコストを支払うよりも安上がりになります。

また、BusinessプランではSLA100％であり、この構成にした事による可用性減は発生しません。

まとめ

比較検討表を記載します。

（3）のパターンではCloudflare以外にも候補がある可能性はありえますが、各クラウドプロバイダーとの連携がサポートされている点は大きく評価できるかと思います。

表には記載していませんが、GoogleCloudとの連携もサポートされており、様々なケースの使用が期待できそうです。

	AWSとAzureをそれぞれ独立させて管理する	AWSかAzureをゲートウェイとし、もう片方のクラウドにルーティングさせる	Cloudflareをゲートウェイとし、それぞれのクラウドにルーティングさせる
概要	AWSではCloudFront/AWS WAF、AzureではAzureFrontDoorを採用し、それぞれ独立したシステムとする。	例えばCloudFrontのオリジンとしてAzureを登録する。もしくはAzureFrontDoorの配信元としてAWSを登録する。	CloudflareをCDN/WAFとして使用し、AWS/Azureにルーティングさせる。
機能	△ CloudFront/AzureFrontDoorともにマネージドルールのアップデートはあるものの、頻度に不安があり、しばしばWAFCharmなどでルールセット更新を自動化することがある。	△ AWSとAzureをそれぞれ独立させて管理するパターンと同等。	◯ Cloudflareが管理するルールによって、先進のゼロデイ脆弱性保護が得られる。また、WAF機械学習によりルールセットが補完される。リスト型攻撃のチェックによりアカウント乗っ取りを監視/ブロックする。その他ゼロトラストやCloudflare Workersなどの機能もあり、CDN/WAF/エッジとしての機能は比較的豊富。ドメインを一箇所で管理できるメリットもある。
可用性	◯ AWS/Azureで独立しているので、何かしら障害が起きた場合でも相互に影響することはない。	△ ゲートウェイとなっているサービスに障害が発生するともう片方のサービスにもアクセスできなくなってしまうので、（1）と比較すると可用性は落ちる。 ※CloudFrontは99.9％のSLAを維持する努力をするとあるが、保証するものではない。 AzureFrontDoorは99.99％のSLAが保証されている。	◯ Cloudflare BusinessプランであればSLA100％が保証されるので、この構成を取った事による可用性ダウンはなし。
コスト	△ AWS/AzureそれぞれでCDN/WAF料金を支払うことになるので、その分コスト増になる。	◯ AWS/Azureどちらかにコストを集約することができる。	◯ Cloudflareにコストを集約することができる。 BusinessプランではAWS/Azure併用よりも安価である。
運用	△ 例えばメンテナンスイン/アウトさせる場合、それぞれのクラウドでオペレーションが必要であり、運用保守者からすると習熟コストが高い。	◯ AWS/Azureどちらかに運用を集約することができる。	◯ Cloudflare自体の習熟は必要となるが、運用作業自体はCloudflareに集約することができる。また、CDN/WAFとしてのCloudflareは比較的習得し易い仕様である。
技術的制約/サポート	◯ AWS/Azureで独立しているので、構築の上での技術的制約は無い。テクニカルサポートに回答を断られることはない。	△ 検証した限りではCloudFrontのオリジンとしてAzure認証サービスを登録した場合、Azure側でエラーが発生してしまい回避させることが不可であった。他クラウドとの連携ということもあり、トラブルに際する問い合わせもたらい回しにされがち。	◯ Cloudflareが各クラウドプロバイダーとの連携を案内しており、技術的な制約はなし。 https://www.cloudflare.com/ja-jp/multi-cloud/aws/ https://www.cloudflare.com/ja-jp/multi-cloud/azure/ またクラウドプロバイダー側もCloudflareを連携パートナーとして案内している。
総評	コストと運用がネック。また、WAFルールセットの更新に不安が残る。	採用サービスによっては技術的制約が無い場合があり、そのケースでは採用し得る。 WAFルールセットの更新頻度には不安が残る。	コストメリットが高く、ハイブリッドクラウド構成では十分に採用し得る。

さいごに

クラウド化が進む昨今ですが、徐々にそれぞれのクラウドプロバイダーに得意/不得意が見えてきています。

もちろん各プロバイダーは不得意を補う動きもするでしょうが、ITサービスの対応領域が拡大する昨今、基本的には強みを伸ばしていく戦略を取るのではないでしょうか。

そうなった場合、Cloudflareのような領域特化のクラウドサービスを組み合わせていくことも増えていくかと思いますので、同じような検討をする方の参考になれば幸いです。

Cloudflare連載を始めます & WorkersにPythonをデプロイして動かしてみる

2024-05-26T15:00:00.000Z

ロゴは https://www.cloudflare.com/ja-jp/press-kit/ より引用

こんにちは。TIGの伊藤です。

Cloudflare連載の第1日目とインデックス記事です。

Cloudflare連載を始めます

CDNやインターネットセキュリティを中心としたサービスプロバイダーであるCloudflareを題材とした連載を開催します。Cloudflareについては技術ブログではこれまで、個人の寄稿で数記事上がっていましたが、連載という形にするのは今回が初めてです。

Cloudflareとは

Cloudflareは、公式では以下の様に書かれていました。

Cloudflareは、インターネット上で運営されている最大のネットワークの1つです。ユーザーは、Webサイトやサービスのセキュリティとパフォーマンスを向上させる目的でCloudflareサービスを利用しています。

上記の様にCloudflare自体でもサービスを持ちつつ、既存のシステムのセキュリティ、パフォーマンスを向上することを目的としているサービス群です。
AWSなどのパブリッククラウドではリージョン、ゾーンという概念がありますが、Cloudflareでは全てエッジネットワークにて構築されており、ユーザが接続する時は一番近い接続点に繋ぎにいき、Cloudflareのサービス、その裏の他のクラウドに接続などをしています。

連載日程

今回は初めての連載ということもあり、5人が参加してくれました。内容は初めて触った系の記事もありますが、わずかながら社内の知見も公開されるようなので、ぜひ楽しみにお待ちください。

日付	寄稿者	タイトル・ネタ
5/27	伊藤太斉	WorkersにPythonをデプロイして動かしてみる
5/28	真野隼記	Cloudflare D1 を触ってみる
5/29	宮崎将太	Cloudflare採用のアーキテクチャ選定
5/30	大岩潤矢	Cloudflare R2 + NextCloudで作る自分専用クラウドストレージのススメ
5/31	小林弘樹	CloudflareでWebサイトのメンテナンスイン/アウトを実装

※公開順、日程は変わる可能性がございますが、ご了承ください。

Cloudflare WorkersでPythonを使いたい

今から約1ヶ月前、2024/04/02にCLoudflareのアナウンスより、Workersにオープンベータという形でPythonが利用できるようになりました。

https://blog.cloudflare.com/python-workers

本記事の結論をいきなり出しますが、PythonをWorkersで利用するにはオープンベータということもあり、まだまだ制限がありました。ただ、WorkersでPythonを使う、ということに対しては最低限であれば動くというのが分かりました。
個人的には、これまでWorkersのアーキテクチャからJavaScriptのみをサポートしていたこともあり、ちょっととっつきづらい部分もありましたが、まだ自分に馴染みのあるPythonが使えるようになったことで言語選択の幅が出たことは喜ばしいことですね。
さて、早速動かせるところまでは動かしてみましょう。

必要なもの

事前準備は以下のコマンドでwranglerコマンドを利用できるようにしておきましょう。

npm install wrangler --save-dev

コマンドを利用してWorkersにPythonをデプロイする

はじめにPythonのプロジェクトを作成しましょう。以下のコマンドから作成します。

npm create cloudflare@latest

In which directory do you want to create your application?
dir ./cf-python # 作成するディレクトリ名を記載

What type of application do you want to create?
type "Hello World" Worker (Python) # PythonのWorkersプロジェクトを作成

Do you want to use git for version control?
yes git # Gitのバージョンコントロールをするか

Do you want to deploy your application?
yes deploy via `npm run deploy` # Workersに初期プロジェクトをデプロイするか

# ここでブラウザ側で認証が走り、認証後デプロイされる

デプロイまで完了すると、以下の画面に遷移します。

この時デプロイされているソースコードは./src/entry.pyに格納されています。

from js import Response

async def on_fetch(request, env):
    return Response.new("Hello World!")

ここまででの作業でPythonのアプリケーションが動く様になったので、次はPythonのパッケージを入れて試してみます。

Pythonのパッケージのサポート

2024/04/02時点でWorkersがサポートしているPythonのパッケージですが、公式のPackagesのページに記載があります。しかし、

Python Workers are in open beta.
You can currently only use built-in packages in local development. Support for deploying packages with a requirements.txt file is coming soon.

と書いてある様にPythonの標準パッケージは使えるものの、外部のパッケージについては現時点ではデプロイできない状態です。実際に試してみましたが、エラーとなり、その文面にもまだサポートされていないことが書かれていました。

fastapi

# 実行コマンド
wrangler deploy
 ⛅️ wrangler 3.57.1
-------------------
▲ [WARNING] The entrypoint src/entry.py defines a Python worker, support for Python workers is currently experimental.


Attaching additional modules:
┌─────────┬────────────────────┬──────┐
│ Name    │ Type               │ Size │
├─────────┼────────────────────┼──────┤
│ fastapi │ python-requirement │      │
└─────────┴────────────────────┴──────┘
Total Upload: 0.06 KiB / gzip: 0.07 KiB

✘ [ERROR] A request to the Cloudflare API (/accounts/xxxxxxxxxxxxxxxx/workers/scripts/yyyyyyyyy) failed.

  You cannot yet deploy Python Workers that depend on packages defined in
  requirements.txt. Support for Python packages is coming soon. [code: 10021]

  If you think this is a bug, please open an issue at:
  https://github.com/cloudflare/workers-sdk/issues/new/choose

実際に色々動かしてみたかったところではありますが、ネイティブでもっと動かせる時が来たらさらに試してみようと思います。

まとめ

Cloudflare連載のインデックス記事とWorkersでPythonがオープンベータで使えるようになったのでできるところまで試してみた記事でした。

私が他の記事を見てみた時の違いは、npm createコマンドを実行した時に、テンプレでPythonが選べる様になっていたので、わずかながらGAになる様に進んでいそうにも見えました。今後のリリースにも期待ですね！

本日からあと4記事ほど続くCloudflare連載ですが、ぜひ他の記事も読んでみてください！

Real World HTTPの第3版ができあがりました

2024-05-12T15:00:00.000Z

https://www.oreilly.co.jp/books/9784814400669/

ひとえに読者の皆さんが買ってくれたおかげで、Real World HTTPを改訂し、このたび3版を上梓しました。ありがとうございます。2016年ごろから書き始めて、2017年に初版を出版したので、執筆段階からすると8年ほど経過しているのですが、これだけ長くこの本に関わり続けられるというのは、本書を買ってくださるみなさまのおかげです。

今回は、ひさびさに無料のミニ版も更新しました。本日、このブログと同時にリリースしました。よりミニ版が学習コンテンツとして使いやすくなるように、そもそもブラウザってどんな動きをするの？というイントロの章をミニ版とオリジナル版に追加しました。

また、オリジナル版だけになりますが、HTTPが単なるブラウザとの通信を超えてプラットフォーム API化していっている流れに合わせて、既存のOpenSocialの話を独立させて、auさんにも取材させていただいてスーパーアプリの話を入れました。本当は他にも内容を教えてくれたけど会社NGが出て、内容は反映したけどお名前を紹介できなかったスーパーアプリもあったりしました。そんな感じで出せない内容もあったのですが、書いていていろいろ刺激を受けることができて楽しかったです（会社がわからない形で文には混ぜてあります）。

あとは、読書会とかで「どこまで読んだ？」がわかりやすいように、この技術ブログを参考に章の最初にアイキャッチ画像をつけるなどしました。その中で何社か問い合わせを（編集の瀧澤さんがして）許諾を取るなどもやりました。一応、著作権がある某章の画像はSNS等にあげないようにお願いします。2章じゃない方。

AI時代の本のあり方

AI時代になって新しいサービスが雨後の筍の如くリリースされる日々です。最近リリースされたGoogle Gemini Proだと無料でも扱えるトークン数が多くなって、PDFを丸ごと読み込ませるというのがやりやすい時代になりました。おそらく、きっとそのうち、生成AIに要約させたんだろうな、と思われるような読書感想ブログがポツポツ出てくるのだろうな、という気がしています。

先日知り合いから聞いたのは、入力のバリデーションにassertを使った同僚がいた、みたいな話でした。assertはいろんな言語が持っている機能ですが、基本的にあり得ない状況に陥った時にシステムを止めるブレーカーのようなものです。そんでもって、開発中はいいのですが、本番環境になるとassertは取り除かれて動かなくなり、バリデーションが一切存在しないプログラムとして本番稼働することになります。

こういう実際の失敗談を集めた、実装でやってしまうかもしれないミスを先回りして「こういうことやっちゃダメだよ」みたいなのを集めた、親父の小言集としてもっと発展させていきたいな、と思って書いています。これはこのReal World HTTPに限らず、Goならわかるシステムプログラミングでも、（増刷があるなら）実用Goでも、他の翻訳書の脚注部分でもやっていきたいと思っています。

そもそも失敗系の話、あるいは時代が変わって今では不要や非推奨になった機能の話なんかは生成AIに聞いても理解が浅いなと思うことも多いですし、僕のこめた目次より小さい粒度のこだわりの話も、おそらくAIの要約では省かれてしまう部分かなと思います。もちろん、トークンの中には入っているはずなので聞けば出てくるのでしょうけど、人が読むと得られるが、生成AIで楽しようとするとスルーされて得られない情報、みたいな感じになるんじゃないかなと。そういう感じで「AIではなく人間が頑張ることで価値」が得られる演出は今後本を書く上では意識してみようかと思いました。

もちろん、AIを使わないメリットの話だけをするつもりはありません。前書きにも書きましたが、そのうちやってもいいかもと思っていたGo以外のサンプルなんかはAIにお任せすれば一発です。本書ではおそらく読者にしつこいと思われている（かもしれない）ぐらいcurlのコマンドを紹介していますが、curlコマンドって生成AIにHTTPリクエストの情報を構造化して伝えるにはすごい有用なんですよね。ここからRust版のサンプル作って、とか、自分の環境にあわせた読書法というのがやりやすくなりました。クライアントコードだけではなく、このリクエストを受けるサーバーコードを作らせるのも一瞬です。あと、本書はページ数を収めるために（これでも）、機能の概要しか紹介できていない項目もたくさんあります。そういうのは「もっと詳しく教えて」「もっと詳しい解説が書かれているページを教えて」みたいに問い合わせると、より深く理解できると思います。

そのようなAI時代の読書体験がしやすい書籍になっているのでは、と思いますので、ウェブとかHTTPとか興味はないが、新しい体験をぜひしてみたいという人も一人10冊ぐらい買っていただけるとよいのではないかと思います。

今後の発展

内容としては大きなところはだいぶ落ち着いたかな、と思います。というのも、初版の時にはまだHTTP/2が策定されたばかりで、HTTP/3はRFCにはなっていなかったものの、その前身のgQUICは存在していましたし、その要素技術のTLS 1.3も策定中でした。2版では策定されたばかりのTLS 1.3を取り上げ、今回はRFC化したHTTP/3を取り上げることができたので、そう言う意味では初版で見えていた未来に辿り着いた、と言う感じはあります。

ウェブの新しい技術として出てくるものは、流行るか流行らないのかがわからないものが数多くあります。SPDYみたいな約束された未来みたいなものは当初から扱っていましたが、本書では基本的に「すでに普及したもの」に限定しています。過去の版では流行ると思って紹介したけど、今回削った内容もぽつぽつあったりします。

技術的にはWebTransportみたいな、本書ではまだ概要しか触れていないものとか、まだまだ書きたい内容はこれからも出てくるはずです。もともと本書を書く動機となったのは、ウェブサービスのプログラミングをしていて、そのなかで疑問に思って調べた細かくちらばっていた情報をまとめたい、というところからでした。僕自身は初版を書き終えた時点でウェブサービスを作る上で（HTTPの知識不足で）困ることはだいぶ減りましたが、仕事の中でいろいろな人の相談に乗っていて「あ、こういうところでつまづいていたのか」といった内容がどんどんネタ帳に溜まってきて、改訂のタイミングで盛り込む、という感じで版を重ねています。実施、今回増えた内容も、決して新しいから増えたというものだけではありません。

自分自身も別にHTTPの専門家ではないとはずっと思っていますし、ブラウザ実装者の人とかが書いてくれたらいいなー、でも出ないから仕方なく自分で書くか、みたいな気持ちはずっとあったのですが、先日編集の瀧澤さんから「一連のやり取りをみていて、改めてリアルワールドのHTTPに関する本を渋川さんが書かれてる意味がわかる気がする」と言うコメントを（まったく違う文脈の中で）いただきました。

一次資料を読め、一次資料が絶対だ、というのはIT業界ではいろいろなところで聞く言葉ではあります。この本は一次資料ではありません。ほとんどの内容はRFCを読めば書いてありますが、実際にコードを書いていて、周りの若者がハマった内容とか、そういうのを拾い上げて、これから学習していく自分よりも若い人たちが楽して多くの経験が得られる知識の高速道路本にしていきたいという気持ちは持ち続けています。

書籍を読んだら、その感想をブログにして欲しい、みたいな話はよく出版ブログでは見ますが、前述のような方向性で今後も発展させていきたいので、本書の場合は読んでしばらくしたあとに「あー、これが書いてあって役にたったわー」みたいなSNSのつぶやきもありがたいです。あるいは、若者にウェブ技術を教えていて、前述のassertとか、今回追加したredirect/rewriteの話とか、若者がこんな誤解をしていた！みたいな話も大好物です。Real World HTTPという書名付きでつぶやいてもらえたら拾いに行きます。

No.1

オライリーには数多くの本がありますが、日本語書き下ろしで3版まで進んでいるのは現在のところ、Sphinxをはじめよう第3版と、本書のみになります。もちろん、英語原著で改版の回数が多い本とか、増刷の回数とか、もろもろだともっと上の本もありますし、続巻スタイルだとゼロから作るDeep Learningシリーズパイセンが圧倒的です。それでも、まあとりあえず（日本語書き下ろしでの改版数がオライリーで）トップタイで日本一、単著だと堂々の日本一ということになります(分野を小さくして一位を作り出すという姑息な手法はビジネス書的なテクでありますが)。どちらの本も編集者は瀧澤さんです。書籍だけでなく、仕事もそうですが、一緒に関われてよかったと思ってもらえるような実績を周りの人には残せたらな、と思っていたので、これも今回良かったな、と個人的に思っている点です。読者の皆さんには関係のない話ではありますが。

One More Thing…

もう一冊、並行して書いていたPlaywrightのWebフロントエンドのE2Eテスト本も予約を開始しています。知り合いのテスト系の有名な方々にもレビューしてもらったり、こちらも良い経験ができました。こちらの詳細はまた別途他のメンバーが書いてくれると思います。

シェルスクリプトで固定長ファイルに区切り文字を入れてCSVに変換する

2024-04-24T15:00:00.000Z

春の入門連載の12本目です。

はじめに

こんにちは。新卒2年目の山下です。

最近ちょっとした作業でシェルスクリプトを触る機会が増え、「固定長ファイルをCSVに変換する」といったややマニアックな文字列操作をすることがありました。

せっかくの機会ですので、利用コマンドやオプションをまとめました。

本編

環境

Red Hat Enterprise Linux release 8.5 (Ootpa)
※利用する環境によってはマルチバイト文字を扱う際の挙動が異なる可能性があります。

利用するファイル

例として、固定長Shift_JIS（SJIS）のファイルを可変調UTF-8に変換します。

入力の固定長ファイルは次の条件のものを想定しています。

下記エスケープが必要な文字が含まれない
- 改行コード（\nや\rなど）
- カンマ（,）
- クォート（”）

変換前

文字コード：SJIS
レコード長：10Byte
カラム長：2Byte（全カラム固定）
※上記エスケープ文字や特殊文字の一部には対応出来ません

hoge.txt

$ cat hoge.txt
ｱｲｳｴｵｶｷｸケ01234567８ｻｼｽｾｿﾀﾁﾂテabcdefghア

変換後

文字コード：UTF-8
CSV

result.csv

$ cat result.csv
ｱｲ,ｳｴ,ｵｶ,ｷｸ,ケ
01,23,45,67,８
ｻｼ,ｽｾ,ｿﾀ,ﾁﾂ,テ
ab,cd,ef,gh,ア

（1）文字コードの変更

はじめに、Bashで適切に文字を読み込めるよう、文字コードを変換します。

iconvコマンドを利用し-fで指定した文字コードを-tで指定した文字コードに変換し標準出力できます。

変換前のファイル

$ cat hoge.txt #-- SJISをUTF-8と解釈して出力しているため文字化けしている
���������P01234567�W�������eabcdefgh�A

iconvで文字コードを変換後のファイル

$ iconv -f SJIS -t UTF8 hoge.txt >> hogehoge.txt #--リダイレクトすることでhogehoge.txtに出力
ｱｲｳｴｵｶｷｸケ01234567８ｻｼｽｾｿﾀﾁﾂテabcdefghア

（2）改行付与

fold

最も基本的な改行付与のコマンドはfoldコマンドです。

指定した値で改行を増やし標準出力します。

fold -option filepath

オプション	概要
-b	バイト数で数える
-w	幅で数える

バイト数区切りで改行付与する場合

-bで指定したバイト数単位で改行が付与されます。

今回の例の場合、前段で文字コード変換（SJIS→UTF-8）をしたため、
半角カナSJIS：1Byteや全角文字SJIS：2ByteのほとんどはUTF-8：3ByteにByte数が変更されるため、カラムずれがおきています。

（現環境では文字の途中で改行コードが挿入されることはなく、10Byteを超える場合は手前の文字までが1行となっています）。

$ fold -b10 hogehoge.txt
ｱｲｳ
ｴｵｶ
ｷｸケ0
1234567８
ｻｼｽ
ｾｿﾀ
ﾁﾂテa
bcdefghア

文字列幅区切りで改行付与する場合

文字列幅は全角：2、 半角：1でカウントされます。

SJISの半角文字は1文字:1Byte、全角:2Byteため、文字列幅基準で改行付与することでUTF-8に変換した後でも想定するレコード長で区切ることが出来ました。

$ fold -w10 hogehoge.txt
ｱｲｳｴｵｶｷｸケ
01234567８
ｻｼｽｾｿﾀﾁﾂテ
abcdefghア

文字数区切りで改行付与する場合

参考程度ですが、文字数区切りで改行を付与する方法も記載します。

grep -oを利用して.に当てはまる文字を1文字ずつ出力し、指定の文字数で改行を付与しています。

$ for char in $(grep -o . hogehoge.txt) ; do echo -n $char; count=$(( count + 1 )); if [ $count -eq 9 ]; then echo ""; count=0; fi; done
ｱｲｳｴｵｶｷｸケ
01234567８
ｻｼｽｾｿﾀﾁﾂテ
abcdefghア

（3）カラム区切り文字の挿入

次に区切り文字を挿入してカラムを分割します。

カラム単位で個別区切り

sedコマンドの-eオプションを利用して指定した文字数で個別に,（カンマ）を挿入する方法です。

$ while read line ;do echo $line | sed -e 's/./&,/8' -e 's/./&,/6' -e 's/./&,/4' -e 's/./&,/2' ; done < hogehoge.txt
ｱｲ,ｳｴ,ｵｶ,ｷｸ,ケ
01,23,45,67,８
ｻｼ,ｽｾ,ｿﾀ,ﾁﾂ,テ
ab,cd,ef,gh,ア

正規表現を利用した文字数区切り

文字列を1文字ずつループしながら下記処理を実行しています。

全半角を識別
半角文字の場合は2文字、全角文字の場合は1文字間隔で区切り文字,（カンマ）を挿入
行の末尾で改行

while read line
do
  count=0
  for ((i=0; i<${#line}; i++)); do
    char="${line:$i:1}"
    if [[ ${#line} = $(( i + 1 )) ]]; then
      echo $char
      continue
    fi
    if [[ -n $(echo $char | grep -P "[ｦ-ﾝ]") ]] || [[ -n $(echo $char | grep -E "[0-9A-Za-z]") ]]; then #ASCII or 半角カナは2文字カウントしたらカンマを挿入
        count=$((count + 1))
      if [[ $count = 2 ]]; then
        echo -n "$char,"
        count=0
      else
        echo -n $char
      fi
    else
      echo -n "$char,"
    fi
  done
done < hogehoge.txt > result.csv

------ 結果 ------
ｱｲ,ｳｴ,ｵｶ,ｷｸ,ケ
01,23,45,67,８
ｻｼ,ｽｾ,ｿﾀ,ﾁﾂ,テ
ab,cd,ef,gh,ア

ようやくCSVに変換することが出来ました。

まとめ

Bashの標準機能のみで全半角混在の文字列をキレイに分割することは少し難しいですが、簡単なレイアウトであれば上記を流用することでカラム分割が可能になりました。

また、今回調べる中で利用するバージョンやディストリビューションによって挙動が異なる事を知りました。

例えばfoldコマンドを使った改行をUbuntuで試すと、下記のように文字化けが起こります（マルチバイト文字の扱いが異なることが原因のようです）。

Description: Ubuntu 22.04.2 LTS

$ fold -w10 hogehoge.txt
ｱｲｳ�
��ｵｶ�
�ｸｹｺ
0123456789
ｻｼｽ�
��ｿﾀ�
�ﾂﾃﾄ
abcdefghij

今回の手法は汎用的に利用できるものでは無いかも知れませんが、マルチバイト文字のByte数が変わると分割や文字カウント方法が少し複雑になり単純計算できない事も多くまとまった内容は少ないです。参考になることがあれば嬉しいです。

参考

https://future-architect.github.io/articles/20210329/
https://www.gnu.org/software/grep/manual/grep.html
https://gihyo.jp/book/2017/978-4-7741-8694-8

アイキャッチ画像は磯の香り - No: 29069589｜写真AC を利用させていただきました。

Systemdにおけるservice unitの起動フロー入門

2024-04-11T15:00:00.000Z

春の入門連載2024 の4本目です。

はじめに

こんにちは、最近寒暖差が激しくて体調崩しがちなTIGの森です。

入門向け記事としてLinuxの systemd における service unit の起動と停止のフローについて説明します。

service unit とは

service unit とは systemd の設定単位の1つで、Linuxにおけるサービスの振る舞いを定義する設定をまとめたものです。主にデーモンやその他のシステムプロセスといった、起動や停止を含む管理をします。

サービス起動の大まかな流れ

サービスの起動のおおまかな流れを説明します。

ここでは話を簡単にするため、Typeディレクティブ(後述)がデフォルトの simple に指定されているとします。

サービス起動の流れ

systemctl start [サービス名].serviceを実行すると、systemdは指定されたservice unitを起動する
systemdはservice unitの設定ファイル(.service)を確認し、サービスが有効かどうかなどを調べる
systemdがfork()を実行し、成功した時点でservice unitがactiveになる。この新しく生成されたプロセスはサービスを起動するためのプロセスとなる
この新しいプロセスが必要な環境設定（環境変数の設定など）を行った後、ExecStartで指定されたプログラムをexecve()で実行する
サービスのプログラムが実行され、サービスが開始する

以上がざっとした流れです。もちろんLinuxにおけるサービス管理全てを網羅しているということではありません。初期化だけを実施するiptablesなどの例外もあります。

サービス起動・終了時の前後の処理に関して

サービス実行の主要なコマンドの前に環境変数の設定や通信路の準備や初期化などを実施する場合、ExecStartの前処理として実行されるExecStartPreや、activeとなった時点で実行されるExecStartPost、また終了時に実行されるExecStopPostなどのディレクトリが用意されています。

サービス起動・終了に関連するディレクティブは下記です。

名称	概要
`ExecStartPre`	依存関係を満たすためのリソースの確保、前段処理を実施する
`ExecStart`	環境変数を読み込み、サービス処理のプログラムを実行する
`ExecStartPost`	`active`になる前のタイミングで実施する後処理を実施する
`ExecStop`	サービス停止のプログラムを実施する
`ExecStopPost`	サービス終了後の後処理を実施する。`inactive`になる前の実施する
`ExecReload`	サービスのリロードを実施する

サンプル

例として、ExecStartPreで実際にどのような前処理が実施できるか試してみましょう。

EC2のインスタンスのメタデータから自身のリージョンを取得し、それをサービスから呼び出して出力させます。

手順

環境変数の設定ファイル/etc/environmentに下記の行を追加して、デフォルトのリージョンを指定
/etc/environment
Region=default

ExecStartPreで叩かれる事によって自分のリージョンを取得するシェル/etc/setEnvConf.shを作成

/etc/setEnvConf.sh

#!/bin/bash

REGION=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//')
sudo sed -i "/^Region=/c\Region=$REGION" /etc/environment

/etc/systemd/system配下にtest.serviceを作成

test.service

 [Unit]
Description=Test Service
After=network.target

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=/bin/bash /etc/setEnvConf.sh
ExecStart=/bin/bash -c 'echo "The region of this instance is ${Region}" > /tmp/output.txt'

[Install]
WantedBy=multi-user.target

サービスファイルを読み込んで起動

sudo systemctl daemon-reload
sudo systemctl start test

以上が手順になります。
サービスが無事起動したら/tmp/output.txtを見てみましょう。

/tmp/output.txt

The region of this instance is ap-northeast-1

ちゃんと自身のインスタンスのリージョンが取得できています。

災対環境などでAMIからインスタンスを起動する時に自身のリージョンを取得して、処理に繋げる際などに応用できるでしょう。

注意点

今回は触れませんでしたがunit がactiveやinactiveになるタイミングは Type ディレクティブの指定によって微妙に変化します。

この記事ではデフォルトのsimpleを用いていますが、これは代表プロセスがfork()の実行に成功したときにactiveになります。つまり、ExecStartが失敗しようがその前段階の環境変数の設定やExecStartPreができていればactiveにはなってくれるということです。

一方で明示的にTypeをexecに指定した場合、ExecStartで指定したプログラムからexecve()の実行が成功したときにactiveになります。他にも様々な Type ディレクティブがありますが、active になるタイミングがいつなのかはしっかり意識して前処置や後処理を運用していくことが運用上求められるでしょう。

まとめ

システムを安定させる上で重要なのは、サービスがactiveになるタイミングやその前後の処理の流れを正確に理解することです。

また、[Unit]セクションにAfterを記述し、異なるサービス間で起動順序を制御することも一般的です。したがって、これらの順序をより一層意識した運用が求められるでしょう。

全文検索エンジンMeilisearchを試す

2024-04-10T15:00:00.000Z

はじめに

こんにちは、TIGの岸本卓也です。春の入門連載2024 の3番目です。

ある静的サイトジェネレーターで生成された膨大なドキュメントの検索において、全文検索機能はあるものの以下の課題を感じることがありました。

探したいものがヒットしないことがある
どこがヒットしているのか謎なものが検索結果に含まれることがある
クライアントサイドで動くため、ページ読み込み時に数十MBと大きいことも多いインデックスファイルをダウンロードするため、ページの読み込み完了が遅い原因になっている

検索にヒットしない場合は、欲しい情報がありそうなページをリンクから辿って個別に探すしかないのです。しかしこれは手間です。

このような課題を解決すべく新たな全文検索エンジンを探す中でMeilisearchという製品を見つけました。Meilisearchは日本語の検索においても良さそうでかつ手軽に試せたので、試した内容を紹介します。

Meilisearchとは

公式サイトのトップページやドキュメントの概説ページによると、検索の応答が早く、すぐに使い始められる、というのが大きな特徴のようです。機能はRESTful APIで提供され、Blogやドキュメントサイトの検索のほか、ECサイトにおける検索への組み込みといったユースケースがあるそうです。

多くの特徴が挙げられていますが、中でも以下のように日本語のサポートが明示されているのは安心感があります。

Comprehensive language support: Optimized support for Chinese, Japanese, Hebrew, and languages using the Latin alphabet
包括的な言語サポート: 中国語、日本語、ヘブライ語、およびラテン文字を使用する言語の最適化されたサポート(by Google翻訳)

日本で活動されている @mosuka (Minoru OSUKA) さんをはじめとしたOSSコミッターの皆さまにより日本語処理が改善されているようです。

試用環境

当記事は以下の環境で実施しました。

EC2インスタンス: t3.small
Meilisearchバージョン: v1.7.1 (prototype-japanese-10)

セットアップ

公式ドキュメントの Installationページではインストール方法が複数提示されています。ここでは、日本語向けの公式ビルドバイナリが簡単に使えるDockerイメージの方法で構築します。

日本語向けのビルドバイナリを含むDockerイメージはDocker Hubのこちらで配布されています。Meilisearchのバージョンとイメージタグの対応関係はこちらのPull request に記載されています。

今回は、現時点の最新版であるv1.7.1に対応したDockerイメージを使ってみます。公式の手順通り、pullして…

docker pull getmeili/meilisearch:prototype-japanese-10

development モードでコンテナを起動します。

docker run -it --rm \
    -p 7700:7700 \
    -e MEILI_ENV='development' \
    -e MEILI_MASTER_KEY='aSampleMasterKey' \
    -v $(pwd)/meili_data:/meili_data \
    getmeili/meilisearch:prototype-japanese-10

上記で指定しているオプションの内、Meilisearch特有のものは次の目的で指定しています。

-e MEILI_ENV='development': development モードにします。Meilisearchにはインデックスの確認などのために search preview という簡易的なGUIフロントエンドが備わっています。以降の手順でもインデックスの確認にsearch previewを使いますが、セキュリティ上の理由で development モードでしか使えません。
-e MEILI_MASTER_KEY='aSampleMasterKey': Master key を指定します。master keyを指定しない場合でも development モードでは自動的にキーが生成されて起動できますが、キーを固定するために指定します。master keyは 16バイト以上の長さが必要です。
-v $(pwd)/meili_data:/meili_data: Dockerコンテナのワーキングディレクトリに作られるデータを永続化するために指定します。

これでMeilisearchが起動しsearch previewも使えるようになっているため、ブラウザで http://:7700 にアクセスしてsearch previewを表示してみます。APIキーの入力を求められるので、コンテナ起動時に指定した aSampleMasterKey を入力して [Go] します。

まだインデックスを作成していないので何も検索できませんが、これでMeilisearchを使う準備は整いました。

インデックス作成

試しに当ブログサイトのインデックスを作成してみます。

基本的にはAPIを叩いてインデックスにドキュメントを登録します (cf. ドキュメントを登録するAPIのリファレンス) が、webサイトのスクレイピングツールである docs-scraper が公式に提供されているのでこれを使ってみます。このツールはwebサイトをクローリングしてインデックスを作成してくれるので、設定さえ用意すれば汎用的に使えそうです。なお、docs-scraperのREADMEには…

🚨 IMPORTANT NOTICE: Reduced Maintenance & Support 🚨

とあるのでメンテナンスは限定的なようですが、ひとまず使えました。

docs-scraperによるスクレイピング

設定ファイルのリファレンスは READMEのこちらに記載があり、設定の具体例は README記載の例や公式ドキュメント向けの設定ファイルが参考になります。また、
meilisearch/docs-scraperは algolia/docsearch-scraper のフォークなので、AlgoliaのConfig Filesページの説明もある程度参考になります。

以降の手順の具体例はそのまま実行はしないようお願いします。 webサイトのクローリングに伴うアクセスは攻撃とみなされる可能性があります (cf. 岡崎市立中央図書館事件)。

当ブログサイトをスクレイピングするのに次のように設定してみました。設定のキモは後述しますが、docs-scraperの大まか動作としては start_urls を起点にこのドメインの範囲内でタグを辿ってクローリングします。

docs-scraper.config.json

ローカルでGoのHTTP/3サーバーを立てて接続テストを行う

2023-09-26T15:00:00.000Z

Go 1.21ではcrypto/tlsパッケージでQUIC関連の更新が少しありましたが、QUICそのものは入りませんでした。QUICとかHTTP/3周りをどうするかはいろいろ議論があり、次のことが決定しています。

最終的にはnet/quicが作られる
ただし、APIの安定化のために、まずは準標準パッケージとして golang.org/x/net/quicを作っていく
github.com/quic-go/quic-go という実装はあるが、それをそのまま取り込むことはしない

ということで、もう少ししばらくかかりそうです。

といっても、HTTP/3のリクエストをエンドのアプリケーションサーバーが直接受けることはおそらく稀で、CDNとか、最前面にたつエンドポイントがHTTP/2やHTTP/3をしゃべって、その裏はHTTP/1.1(非TLS)が多いと思いますし、より固くしようとしてもmTLSでHTTP/2じゃないですかね。もともとHTTP/3の強みはエラー率の高い回線でも速度が落ちにくいことなので、回線品質の安定したデータセンターとかクラウド内部はHTTP/3にしてもうまみがあまりないといえるので、そんな悲観的になることもないかな、と思います。

とはいえ、HTTP/3に触ってみたい方もいるかと思うので試してみました。

上記の議論の中でも出てきた github.com/quic-go/quic-go は、このパッケージの作者のMarten SeemannはIETFのQUICワーキンググループの初期からのメンバーでもあり、このパッケージ自身もIETFの他のQUICエージェントとの相互接続テストを行っており、品質はばっちりだと思われます。なのでこれを試してみます。

quic-goでのHTTPサーバー

Goの標準ライブラリのサーバー実装と似たようなAPIでサーバーをたてられます。ハンドラ周りはnet/httpのhttp.Handlerインターフェースそのものなので、いろんなフレームワークをそのまま上で動かせます。

package main

import (
   "fmt"
   "log"
   "net/http"

   "github.com/quic-go/quic-go/http3"
)

func main() {
   mux := http.NewServeMux()
   mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
       fmt.Fprintf(w, "Hello, %s", r.Proto)
   })

   log.Println("start at https://localhost:8443")
   log.Println(http3.ListenAndServe("0.0.0.0:8443", "localhost.pem", "localhost-key.pem", mux))
}

Goを書いたことがある人にはおなじみですね？ HTTP/2と同じく、TLS必須なので証明書を作成する必要があります。こちらは参考情報がいろいろあるので、お好きな文献などを参考に作ってみてください。Real World HTTPでも紹介しています。

localhostのホスト名で証明書を作ったので、localhost:8443でアクセスするとバッチリ表示されます。Safariでアクセスしてみると、すぐに表示されて案外簡単？と思いつつ、ここから深くなってきます。

quic-goの内部ではサーバーが2つ起動する

http3パッケージにはListenAndServeQUIC()という関数もあります。どう違うのでしょうか？最初はこちらで実装してみたのですが動かず、上記のListenAndServe()にしたら動きました。

こちらの方は内部的には、こんな感じのコードと同じような動きになります。よくよくみると、HTTP/2のサーバーも起動していますね。Alt-Svcフィールドを付与しています。

QUICはUDPですが、現在のブラウザはまずTCPでサーバーアクセスしに行きます。しかし、HTTP/3のみのサーバーがたっていても、そこにはTCPのサーバーはいません。そのため、HTTP/2のサーバーを裏でたてて、そのレスポンスの Alt-Svcフィールドを返し「こちらでHTTP/3のサーバーがいるよ」とブラウザをHTTP/3の方に誘導しているというわけです。

package main

import (
   "context"
   "fmt"
   "log"
   "net/http"
   "os"
   "os/signal"
   "sync"

   "github.com/quic-go/quic-go/http3"
)

func main() {
   mux := http.NewServeMux()
   mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
       w.Header().Add("Alt-Svc", `h3=":8443"; ma=2592000`)
       fmt.Fprintf(w, "Hello via %s", r.Proto)
   })

   ctx, close := signal.NotifyContext(context.Background(), os.Interrupt)
   defer close()

   h2server := &http.Server{
       Addr:    "0.0.0.0:8443",
       Handler: mux,
   }
   h3server := &http3.Server{
       Addr:    "0.0.0.0:8443",
      Handler: mux,
   }

   wg := &sync.WaitGroup{}
   wg.Add(2)

   go func() {
       log.Println("start at http/2 server at (TCP)https://localhost:8443")
       log.Println(h2server.ListenAndServeTLS("localhost.pem", "localhost-key.pem"))
       wg.Done()
   }()

   go func() {
       log.Println("start at http/3 server at (UDP)https://localhost:8443")
       log.Println(h3server.ListenAndServeTLS("localhost.pem", "localhost-key.pem"))
       wg.Done()
   }()

   <-ctx.Done()
   h2server.Shutdown(ctx)
   h3server.Close()
}

プロトコル選択

HTTP/3ではいくつかの箇所でプロトコル選択をさせるようになっています。

DNSのHTTPSレコード
TLSのハンドシェイクのALPN(Application-Layer Protocol Negotiation)
上記で紹介したAlt-Svcフィールド

上から順番に実行されます。DNSであれば、最初のサーバーアクセスの前に情報を得ることができます。TLSのハンドシェイクはTCP/UDPを決めた後に行えるため、最初のTCPのアクセスの空撃ちは必要です。Alt-Svcフィールドのタイミングはさらに遅く、一度HTTP/2のサーバーがリクエストを処理するまで、ブラウザはHTTP/3のサーバーの存在を知ることはできません。

個人的には103 Early HintsでAlt-Svcフィールドを返せば僅かばかりAlt-Svcをレスポンスで返すよりも効率的かな、と思いましたが、103 Early Hintsはサンプル見てもプリロードの用途しか見ませんね。

CoreDNSをたててみた

さて、上記のHTTP/3サーバーですが、Safariからはばっちり3の方につながるのですが、ChromeとFirefoxは2ばかり。たまに開発者ツールを開いてリロードしたタイミングだけ3でつながったりといまいち安定しません。そんな中、Twitter(X)で、まえかわさんという方から、HTTPSレコードでばっちりいけるというお話を伺い、ちょっと試してみることにしました。

allt-svcに加えてHTTPSレコードをつけたらchromeは確実に3でfirefoxは半々ぐらいの確率になりますね
自分も壊れてるのかと思いました
— まえかわ (@kiwithe2027) September 17, 2023

ちなみに、現在出ているSoftware Design 2023年10月号がたまたまHTTP/3特集でしたが、HTTPSレコードはCDN上の設定で付与していました。

今回あつかったCoreDNSは、CNCFの傘下にいるプロジェクトで、Kubernetesでもよく使われています。もっとも、その理由がetcdでエントリーの管理ができて、そちらの情報を元に情報を返せるため管理が楽、というところがあるのだと思いますが、今回はetcdは使いません。

こちらをみながらmacOSでやってみた例になりますが、サービスの起動部分以外はポータブルなはずです。hnakamurさんがWindowsでサービス化するラッパーを作られているのでこちらに変えればWindowsでも動くかと思います。

# インストール
$ brew install coredns

# 起動
$ sudo brew services start coredns

http3.testというホスト名だけ特別扱いしてHTTPSレコードをつけてあげたいので、/opt/homebrew/etc/coredns/Corefileファイルを次のようにしました。

/opt/homebrew/etc/coredns/Corefile

. {
    forward . 8.8.8.8
    log
    errors
}

http3.test {
  file /Users/shibu/.config/coredns/test
  log
  errors
}

上記の設定からインポートされる自分のホーム以下に追加の設定ファイル(/Users/shibu/.config/coredns/test)をおきます。こんな感じにしてみました。

$ORIGIN test.
$TTL 1m

@                 IN  SOA     ns.test. admin.test. (
                                   2020010510     ; Serial
                                   1m             ; Refresh
                                   2m             ; Retry
                                   4m             ; Expire
                                   1m)            ; Minimum TTL
@                 IN  A       127.0.0.1
@                 IN  NS      test.
ns                IN  CNAME   @


http3   IN A     	127.0.0.1
        IN AAAA  	::1
        IN		HTTPS 1 . alpn=h3 port=8443

# 再起動
$ sudo brew services restart coredns

最後にネットワーク設定でDNSに127.0.0.1を追加してあげれば完了です。

これでSafariでアクセスしてみると、無事に https://http3.testというURLでアクセスできました。HTTPSレコードはプロトコル以外にもポートを設定できるのでポート番号を省略できるようになります。いいですね。

しかし、実はChromeとFirefox、EdgeはこのDNSサーバーを見に行ってくれませんでした。昔はDNS設定があったと思いますが、いまはDNS over HTTPSのみです。ChromeでHTTP/3に繋ぎたくてCoreDNSを入れてみたのですが、ここはうまく行っていません。DNS over HTTPSをCoreDNSで建ててみてもそこにアクセスしてくれなかったり、設定を拒否されたり。ここはぼちぼちやっていこうと思います。dnsmasqを入れた時はアクセスはしてくれたものの、HTTPSレコードの追加が分からずCoreDNSでやりましたが、別の方法も試そうかと。

まとめ

というわけで、HTTP/3のサーバーを起動してブラウザでアクセスしてみました。Safariからはうまくつながりました。しかし、実際に試す時間の90％はDNS周りを操作する時間だったりして、ちょっと敷居が高い気がしました。

将来的にはもう開発体験がちょっと改善されたらいいな、と思いました。

Infrastructure カテゴリ | フューチャー技術ブログ

非機能テストを記号接地する

はじめに

そもそも 【非機能】 が分かりにくい

門限が決まっている → 性能要件

応答が遅いと怒られる

一度にお客がいっぱいやってくる

テストする

おわりに

RFC 7807 から RFC 9457 で Web API のエラー表現で変わったこと

はじめに

RFC 7807: Problem Details の標準化 (2016年)

RFC 9457: 7807 を置き換える改訂版 (2023年)

変更点

改善点①: type URI のガイダンス明確化

7807 時代の課題

9457 での改善

具体例

備考

改善点②: 複数エラーの扱い

7807 時代の課題

9457 での改善

備考

改善点③: 共通型レジストリの新設

7807 時代の課題

9457 での改善

登録方法

例示

備考

改善点④: Security Considerations の補強

7807 時代の課題

9457 での改善

具体例

備考

フューチャーの Web API 設計ガイドラインでの扱い

まとめ

はじめての性能テストを公開しました

はじめに

ガイドライン作成のモチベーション

ガイドラインのポイント紹介

性能テストの分類

性能目標の定め方

性能テストの段取り

テストツールの選定

チューニングポイント

レポーティング

おわりに

3年ぶりWindows環境構築のリトライと答え合わせ

はじめに

2026 年の Windows 環境構築

SharpKeys のキーリマップ設定

IME の設定

PowerToys のインストール

PowerToys Command Palette のホットキー設定

AutoHotkey v2 のインストールとスクリプト配置

クリップボード履歴の有効化

Zen Browser のインストール

設定後の構成

3 年で変わったもの、変わらなかったもの

おわりに

分散システム入門: 信頼性の低いネットワークを再現してみる

はじめに

実験の概要

構成

実験の流れ

実験

実験1：ベースラインの計測

疎通確認

定量計測

実験2：home-lab-3をゾンビノードにして計測

Kubernetesから見たノードの状態

疎通確認

定量計測

実験3：home-lab-3を完全停止させて計測

Kubernetesから見たノードの状態

疎通確認

定量計測

実験結果のまとめ

おわりに

自宅だと apt update ができなかった話（WSL2 + 社内VPN環境での名前解決の遅延）

そもそも　【非機能】　が分かりにくい

門限が決まっている　→ 性能要件

改善点①: `type` URI のガイダンス明確化

TCP Proxyを作って面倒なProxy設定を一掃する～Rust製moproxyとnftablesによる透過プロキシ設定～