パスワードの保存は、ソフトウェアの世界で「本当に正しい答え」が存在する数少ない領域のひとつです。その答えはすでに公開されていて、継続的に更新されていて、しかも無料で読めます。それにもかかわらず、これほど繰り返し間違えられている領域も珍しくありません。理由は単純で、いま間違いとされている答えのほとんどが、かつてはたしかに正しかったからです。そして正しかった時期を過ぎたあとも、誰もその判断を見直しませんでした。 失敗の中身が奇抜であることは、まずありません。2012年に妥当だった助言に沿って2016年に組まれた仕組みが、いまも動き続け、いまもログインを受け付けている。それだけの話です。そのハッシュ処理を書いた本人が会社を去って以来、誰も...
バックエンド開発
バックエンド開発に関する記事、ガイド、チュートリアル。開発者や企業向けの実践的な情報をまとめています。
技術ドキュメントは、いつも決まった、そして予測のつくかたちで失敗します。誰かが二週間ほどの落ち着いた時期に大量に書き上げ、そのあいだにシステムのほうが変わり、誰も更新せず、一年も経てば、その文書は自信たっぷりに間違ったことを述べている状態になります。そこから先は、何もないよりも悪い状態です。書いてあることを信じた読み手が、すでに成り立たなくなった情報にもとづいて手を動かしてしまうからです。 これに対するよくある反応は、もっと書こうという号令です。ところがそれは同じ失敗を早めるだけで終わります。役に立つ反応は、書く量を減らし、そのうえで何を書くのかを選ぶことです。ここでの制約は書く手間ではありません。書いたあとに保守し続ける手間のほう...
稼働率SLAは約束のように見えて、実際には返金規定のように振る舞います。提供側はそれを知っています。契約する側は知らないことが多く、可用性を買ったつもりでサービスレベル契約に署名しますが、実際に買っているのは、可用性が得られなかったときに受け取れるわずかな割引です。 それが必ずしも悪い取引だというわけではありません。ただ、多くの人が結んでいるつもりの取引とは別の取引であり、その違いはシステムが止まって、契約には何と書いてあるのかと誰かが尋ねた瞬間に効いてきます。 スリーナインは完璧に近く聞こえますが、月に43分の停止を許容します。 フォーナインが許容するのは4分です。平日の午後に43分の障害を吸収できる事業なら、99.9%で十分であ...
小規模なチームにおける災害復旧は、たいていの場合、誰も開いたことのないドキュメントの中の一行で終わっています。バックアップは有効になっています、という一文です。その記述自体は事実ですが、何かの答えになっているわけではありません。実際に障害が起きたときに戻ってくるデータがどれだけ古いものなのか、復元にどれくらいの時間がかかるのか、そしてこれまでに誰か一人でも最後まで復元をやり切ったことがあるのか、そのどれについても何ひとつ語っていないからです。 バックアップを持っているという状態と、実際に復旧できるという状態のあいだには、はっきりとした隔たりがあります。ほとんどの障害が本格的なインシデントへ変わるのは、まさにその隔たりの中でのことで...
API のバージョン管理をめぐる議論は、たいてい間違った側から始まります。バージョン番号をどこに置くか、という話です。実のところ、それはこの主題のなかでもっとも結果を左右しない決定です。本当に重要なのは、そもそもどの変更が新しいバージョンを必要とするのかであり、ほとんどのチームはここを、油断する方向に読み違えます。純粋な追加にすぎないと信じたものを出荷し、どこかのクライアントが壊れるのです。 使える考え方はこうです。あなたの API は、呼び出す側が何を当てにしてよいかについての約束にほかなりません。まっとうな呼び出し側が当てにしていたものを無効にしてしまうなら、その変更は破壊的です。そして呼び出し側は、ドキュメントが明示的に許して...
データベース性能の改善作業は、たいてい誰かが「もっと大きなインスタンスにしよう」と言い出すところから始まり、そしてたいていは、ページを開くたびにひとつのクエリが400万行を順次スキャンしていた、という発見で終わります。制約はもともとハードウェアではありませんでした。制約は実行計画のほうにあったのです。 この筋書きは十分に繰り返し起きるので、既定の仮説としてはっきり言葉にしておく価値があります。アプリケーションが遅く、そのうえデータベースが忙しいのなら、原因はほぼ必ず、ごく少数の特定のクエリであって、処理能力全体の不足ではありません。そしてサーバーを大きくする対処は、テーブルがふたたび育つのに必要な時間のぶんだけ、問題を覆い隠してくれ...
Cloudflare Queues は、サーバーレスアプリケーションが遅かれ早かれ必ず突き当たる問題を解決します。すなわち、ユーザーを待たせるべきではない処理を引き起こすリクエストが届く、という問題です。確認メールの送信、アップロードされた画像のリサイズ、レコードを外部サービスへ同期する処理。従来型のサーバーであれば、そうした仕事はバックグラウンドのワーカープロセスに渡せば済みます。ところが Workers には、渡す相手となるプロセスそのものが存在しません。 よく使われる回避策は、見た目よりもたちが悪いものばかりです。処理をリクエストの中でそのまま実行すれば、ユーザーはメール配信事業者の応答を待たされることになります。...
Cloudflare Hyperdriveは、きわめて具体的で、まったく華やかさのない問題のために存在しています。200の都市で走っているWorkerが、たった一つの都市に置かれた一つのPostgresデータベースと会話すると、そのデータベースのすぐ隣に座っているサーバーから同じクエリを投げた場合よりも遅くなります。少し遅い、という話ではありません。多くの場合は数倍遅く、しかもその理由は、クエリがどう書かれているかとはまったく関係がありません。 サーバーレスのアプリケーションが重たく感じられたとき、最初に働く直感は、クエリプランナーのせいにするか、インデックスをもう一本足すかのどちらかです。しかしリージョンに置かれたデータベースと会...
Cloudflare Workers と AWS Lambda はどちらもサーバーレスのコンピュートプラットフォームですが、出発点が異なります。Lambda は巨大な AWS エコシステム内で確立されたサーバーレスの標準であり、Workers は低遅延とグローバル分散のために作られたエッジネイティブです。2026 年にはどちらも優れており、正しい選択はワークロードと既存のスタックによって決まります。本ガイドでは、本当に重要な観点で Cloudflare Workers vs AWS Lambda を比較します。 TL;DR Workers は軽量な V8 isolates 上でエッジで実行され、cold start がほぼゼロで、既...
Cloudflare Workers を使えば、サーバーを管理することなく、ユーザーの近くのエッジでバックエンドコードを実行できます。APIにとって、ほぼゼロのコールドスタート、グローバルな分散、そして密接に統合されたストレージという組み合わせは、2026年においてWorkersを魅力的なプラットフォームにしています。このガイドでは、Cloudflare Workers APIがどのように構成され、従来のバックエンドと何が違うのかを説明します。 要点（TL;DR） Cloudflare WorkersはあなたのコードをエッジのCloudflareグローバルネットワーク上で実行するため、リクエストはユーザーの近くで、ほぼゼロのコールド...