ニュースから、自分の思い込みに気づく

テクノロジーと社会のニュースを、やさしい言葉で解きほぐすメディア。読み終えたとき、自分の見方が少し変わる記事を届けます。

Tag

#バックエンド開発

小さなヘビが小さな瓶にぴったり収まり、ネコ型のお世話係がリボン付きのメダルを手渡している、Pythonが軽量な実行環境に正式対応したことを表すイラスト。

Cloudflare、Pythonを速さで勝負 引き換えに使えるパッケージは選別制に

Cloudflareが、Python Workersをベータ版から正式サービスに移した。Pythonは、これまでJavaScript Workersを動かしてきたのと同じ基盤で、本番環境向けの実行環境として使えるようになった。単なる呼び名の変更ではない。正式サービスにするというのは、事業としての約束でもある。安定して使えること、サポートが受けられること、Pythonがこのプラットフォームの主役級の言語であり続けることを意味する。もっと面白いのは、そこに至った道筋のほうだ。

-- いいね数
続きを読む
Abstract visualization of a complex microservices network topology showing interconnected nodes with flowing data streams, representing Netflix's real-time service dependency mapping at scale

Netflix がリアルタイムサービスマップをスケールさせた方法

Netflix のサービストポロジーは、サービス同士のつながりをリアルタイムで見せる仕組みとして生まれた。もともとは概念実証、いわば試作品だった。ところが本番環境に載せてみると話が変わってくる。数千のマイクロサービスが毎秒数百万もの依存関係イベントを吐き出す。この規模で動かした瞬間、設計の土台にあった弱さが表に出てきた。

-- いいね数
続きを読む
Split-screen technical illustration comparing epoll and io_uring Linux I/O architectures, showing traditional event-driven network structure versus modern ring buffer design with flowing data paths

I/O多重化アーキテクチャが重要である理由

epollとio_uringの選択は、アプリケーションのスケーラビリティ特性に直接影響を与える構造的な決定を表しています。Linux 2.5.44カーネル(2002年)で導入されたepollは、select(2)のO(n)ファイルディスクリプタスキャンをイベント駆動型通知メカニズムに置き換えることで、C10K問題に対処しました。本番Linux環境ではいまなお支配的なI/O多重化インターフェースです。

-- いいね数
続きを読む
Three interconnected geometric nodes representing a sequential AI development workflow, with symbols for planning, code generation, and evaluation connected by directional arrows

3エージェント・アーキテクチャ:計画、生成、評価の機能的分離

Anthropicの3エージェント・ハーネスは、単一型のAIコーディング・アシスタントで通常は混在している3つの操作を機能的に分離することで、自律的なAI開発を再構成しています。その3つの操作とは、計画、生成、評価です。これらの機能を以下のように定義します。分離の理論的根拠: 長時間実行されるAIワークフロー(ここでは4時間を超える開発セッションと定義)は、統一されたシステムにおいて文書化された劣化パターンを示します。

-- いいね数
続きを読む
Isometric view of a database table with solid blue rows representing active records and semi-transparent gray rows representing soft-deleted records, with subtle complexity indicators like connection lines spreading from the deleted rows

ソフトデリートをデフォルト戦略として再考すべき理由

ソフトデリート—レコードを削除するのではなく削除済みとしてマークする—は、アプリケーション設計において反射的な選択肢となっている。その魅力は明快だ:コンプライアンス、監査証跡、復旧シナリオのためにデータを保存する。しかし、この利便性は、システムがスケールするにつれて複雑化する重大な運用上の摩擦を隠している。主張: ソフトデリートは、文書化されたシステム要件と規制上の義務に紐づいた明示的なコストベネフィット分析なしに、デフォルトのアーキテクチャ選択であるべきではない。

-- いいね数
続きを読む
Split-screen illustration showing a transparent red cube with disappearing data particles on the left representing Redis's volatile memory, contrasted with a solid blue database vault on the right representing persistent storage, symbolizing the transition from Redis to more durable queue systems

Redis、愛しているけど、SolidQueueに乗り換えます

Redisは、永続的なジョブキューシステムとしてではなく、低レイテンシアクセスパターンに最適化されたインメモリデータ構造ストアとして設計されました(Redis作成者Salvatore Sanfilippo、2009年)。Redisは永続化メカニズム(Append-Only File(AOF)とRDBスナップショット)を提供していますが、これらはオプションであり、明示的な設定が必要です。重要なことに、両方のメカニズムはデータ損失の可能性がある時間枠を導入します。

-- いいね数
続きを読む
TOPへ