「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？
こんにちは。馬場（netmarkjp：Bluesky/X）です。
わたしは「#ばばさん通信ダイジェスト」として、BlueskyやThreadsに毎日少しずつ、賛否を問わず話題になった／なりそうなものを共有しています（Bluesky検索）。
これらをベースに、特にクラウド／インフラ／SRE／オブザーバビリティ／運用等のキーワードに関する話題を中心にお届けします。
オブザーバビリティ基盤に広がる国内処理の選択肢
New Relicの日本リージョンの一般提供開始が同社のブログで発表されました。
いままでは、「競合には日本リージョンがあるのに」というシーンがありました。データレジデンシーの要件・要求が厳しい業界やシステムに選択肢が増えそうです。
New Relicの日本リージョンは、AWSの東京リージョンでホストされているそうです。
ポイントは、AI機能を利用する際に、メトリクス・ログ・トレースなどのテレメトリーデータの移動が国内で閉じるように設計されている点です。日本リージョンではAI処理もリージョン内で処理するとのことです。
国内にデータを閉じたはずが、利用する機能によってデータがするっと国外に出ていたということがなくなるのであれば、安心でうれしいですね。
大規模なPostgreSQLはどのようにつくられてきたか
DB PaaS提供会社であるPlanetScaleのブログで、PostgreSQLのシャーディングの歴史が解説されています。
ここで扱っているシャーディングは、大規模なデータベースを実現するための技法のひとつです。業界がPostgreSQLで大規模なデータベースをどのように実現してきたのかをたどることができます。
データベースはデータの実体を扱うので、大規模化するにはデータをどこにどう置き、どう取り出すかという具体的な話を扱います。だからこそ、すごく興味深く、面白いです。利用者からは魔法のように見える仕組みも、裏では素朴で実直な仕組みを組み合わせて実現されています。それらの組み合わせが、特にスケーリングやパフォーマンスにおける効果、あるいは制約事項につながっていることが実感できます。
シャーディングは技法としては水平分割で、テーブルのデータの保持や扱いを複数のデータベースサーバーで分担することで、ひとつあたりが担当するデータ量を減らし、規模拡大に対する性能悪化の程度を制御します。大量のデータを、データがすごく増えてもそれなりの所要時間で扱えるようにする方向性です。
あのSkypeの裏ではPostgreSQLが動いていたのですが、当時のMySQLの勢いと比べると、あまり注目されていなかったように記憶しています。当時PostgreSQL関係のOSSコミュニティに縁が強かった筆者は、認知が広がっていないことを残念に感じた記憶があります。
なお、このブログエントリーは、PlanetScaleの新プロダクトであるNekiにつながるバックストーリーでもあります。
OSS開発の持続性を支える事業のかたち
DuckDBの開発元であるDuckLabsが、AWSの傘下に入ることが発表されました。
DuckDBやDuckLake、各種拡張機能はDuckDB Foundationの管理のもと、引き続きMIT LicenseのOSSとして公開されます。ロードマップ、ライセンス、ガバナンスモデルにも変更はないとされています。
DuckDBはデータ分析に非常に便利で、個人的にも活用しています。OSSは継続するということで、資金面での開発の持続性が強化されるのはうれしいニュースです。
OSSプロダクトの開発元の買収話で、もうひとつ気になったニュースがありました。
Tailwind開発元のTailwind LabsがShopifyの傘下に入ることがアナウンスされました。
Tailwind Labsといえば、今年の初めに、AIコーディングエージェントの台頭等による収益性の低下から、事業継続が難しくなっていると話題になりました。
Tailwind CSSをはじめとするOSSプロジェクトはMIT Licenseのまま引き続き提供され、チームもShopifyの支援を受けながら継続して開発・メンテナンスを担うとしています。こちらも資金面での開発の持続性が強化されるのはうれしいニュースです。
いずれも資金面の持続性は強化されましたが、事業価値が低いと見なされればやはり事業終了はなくもないわけで、お世話になっているもの、使っているものは、暗にではなく明に有形の支援をできるだけしていくのが重要ですね。
AIが変える技術選定の制約条件
Shopifyのエンジニアリングブログで、スマートフォンアプリの開発をReact Nativeから完全ネイティブのSwift/Kotlinへ再移行することが発表されました。
すでにShopifyに複数あるアプリの中でも人気の高い「Shop」アプリで実証しており、PoCから本番品質のアプリ再構築まで12週間で完了したそうです。
React Nativeを採用した背景は、iOS/Androidの2系統に対してほぼ同じスマートフォンアプリを開発する二重の負担を避けることが大きな目的でした。しかし現在はAIエージェントがこの二重の負担の大半を担うため、2系統を維持するうえで大きなネックではなくなったと判断したそうです。
これまで手が回らなかった最適化が、AIの力でできるようになるのはうれしいですね。
Shopifyに数あるアプリのうち最大規模の「Shopify」アプリはまだ移行中で、今年後半にリリース予定とのこと。引き続き楽しみです。
基盤技術の引き出しが拓く課題解決の可能性
モノタロウのテックブログで、ZFSのスナップショット機能やクローン機能を活用してDBブランチを実現する技法が紹介されています。
いまはクラウドサービス全盛ですから、ZFSというファイルシステムレベルでの工夫で課題解決する事例は比較的珍しく、見てうれしくなりました。課題解決に最適な技法を適切に利用できる引き出しがあり、それを実現まで持っていけるのは、エンジニアとして素晴らしいですね。
DBブランチは、PlanetScaleやNeonで提供されている便利な機能です。なお、ここではDBブランチと呼んでいますが、きちんと整理された名称ではないかもしれません。ここでいうDBブランチは、既存のデータベースのスキーマとデータを、ある時点で完全に分岐させることを指します。
これはDBMSのトランザクション分離の話ではなく、データベースに保存されているデータ一式をまるごともうひとつ別につくるイメージです。これができると、データベースのある時点を対象としたデータ処理の検証を気軽に実施できます。これはGitでのソースコードのブランチ作成を想像すると近いと思います。なお、筆者が知る限りデータのマージはできず、一部プロダクトではスキーマのマージはプルリクエストのような形で間接的にできるようです。
データ一式をまるごと分岐させるわけですから、データベースのアプリケーションプログラムの世界ではなく、データを保存しているストレージの世界で実現してもよいわけです。
ZFSはファイルシステムとボリューム管理を統合したストレージ技術の名前です。WindowsではNTFSやFAT32、macOSではHFS+やAPFS、LinuxではBtrfsやext4がよく知られています。ZFSはファイルシステムレベルの機能として、スナップショットとクローン、コピーオンライト（Copy on Write）を持ちます。
スナップショットは、ある瞬間に保存されているデータ一式を保持し、あとから取り出せるようにする技術です。ZFSではスナップショットの取得は大量のデータのコピーを伴わないので、短時間で取得が完了します。
そしてスナップショットとして取得したデータ一式をクローン、つまり複製します。クローンした直後のデータ一式は、元のデータと全部一緒です。なので、わざわざ同じ値を別のデータとしてコピーしなくても、同じ値だと分かっているのであれば同じデータを見ておけばよいわけです。
クローンの元側と新側があり、データの書き換えが発生したときに、その部分についてのみクローン元とは違う新しいデータをつくり、以降はそれを使えばよいわけです。この「書き込む時までコピー作成を遅延する」技法がコピーオンライトです。
これらの仕組みにより、スナップショットを取得してからクローンを作成し、利用を開始できるようになるまでの時間が非常に短くなります。また、スナップショット取得とクローンによるデータ量、つまり利用するディスク容量を大幅に削減できます。
クラウドの可用性を支える海底ケーブルの多様性
AWSのブログで日本とアメリカを結ぶ新たな太平洋横断海底ケーブル「Sta’O’Nuk」が発表されました。
2029年の運用開始を予定しており、これによりAWS Global Networkの太平洋横断の通信容量が420Tbps追加される計画です。日米間通信の可用性を高めるために、日本・アメリカ双方で既存の陸揚げ地点やケーブル経路が集中している場所を避けるよう設計されているとのことです。アメリカ側はワシントン州で、日本側は未公表です。
Submarine Cable Mapを見ると、登録されている海底ケーブルが地図上で確認できます。「Sta’O’Nuk」もすでに登録されていますが、日本側の陸揚げ地点は未定となっています。
Submarine Cable Mapで日本の様子を見ると、既存の海底ケーブルの陸揚げ地点は房総半島近辺と志摩半島近辺に集中しており、次いで茨城にあることがわかります。
もし現地近辺にお立ち寄りの際は、こっそり設備を探してみると面白いかもしれません。
オブザーバビリティの持続性を支える統計的な考え方
Grafana Labsのデベロッパーアドボケイトである山口さんが、2026年におけるオブザーバビリティのコスト増大の要因と、テレメトリーサンプリングの重要性について、ご自身のブログで解説しています。
前回の「も読」『AI時代も、コツコツ直すほうが、結局は安く済むかもしれない──AIによる技術的負債の継続的自律解消など8選』で紹介した書籍に絡む内容です。
情報システムのオブザーバビリティは、情報システムの信頼性や持続性を実現するために不可欠です。そのうえで、適切な費用対効果が求められます。山口さんは、全量保存が可能ならそれが最良としつつ、全量保存が不可能になったときに、全量保存か全く無しかの二択にならない現実的な選択肢として、サンプリングを挙げています。
オブザーバビリティは扱うデータの量と種類の多寡が主な費用変動要因になりますから、サンプリングで量を減らすことはコストに効きます。全量検査ではなく標本を抽出して検査するのがサンプリングであり、その技法はオブザーバビリティに限らず広く一般に利用されている統計的手法です。そしてサンプリングの精度は数学的な理論に支えられています。つまり適切な期待値を設定でき、かつ説明可能です。つまりオブザーバビリティには統計学が効くのですね。
適切なサンプリングによって、あまり精度を落とさず、有用な結果を得る意思決定はエンジニアの腕の見せ所ですね。
山口さんのテレメトリーサンプリングの話に興味が湧いたらこちらのブログエントリーもぜひ読んでみてください。
注目・期待の書籍
『ソフトウェアエンジニアリングの基礎 - O'Reilly Japan』
Nathaniel Schutta、Dan Vega 著、村上 列 訳
ソフトウェアエンジニアとして成長するために必要なのは、アルゴリズムやプログラミングの知識だけではありません。学校のカリキュラムやブートキャンプでは教わらない、キャリア形成に直結する実践的なスキルこそが差を生みます。
実際の開発現場では、技術的負債を抱えた既存のシステムを保守・改善し、ソフトウェアを適切に設計・テストして品質を保ちながら安定してリリースするとともに、チームやステークホルダーと円滑にコミュニケーションを図る力が求められます。本書は、そうした現場で必要となる知識とスキルを、実践的かつ幅広く解説します。
ソフトウェアエンジニアリングとは何かという基本的な問いから、ソフトウェアアーキテクチャとその設計を左右する要因、技術的負債を踏まえたコードベースの読解とリファクタリング、効果的なテストスイートの構築、信頼性と再現性の高いデプロイ、コミュニケーションをはじめとするソフトスキルまでを取り上げます。さらに、複数の選択肢を適切に評価し、目の前の問題や状況に合った解決策やツールを選び抜くための考え方も身につけます。
これからソフトウェア開発の仕事を始める人はもちろん、プログラミングの経験を土台に、キャリア形成を意識しながらより広い視野と実務力を備えたエンジニアを目指す開発者のための実践ガイドです。
『OpenTelemetry eBPF Instrumentationの舞台裏』
Yoshi Yamaguchi 著
Go Conference 2026の登壇「OpenTelemetry eBPF Instrumentationの舞台裏」の解説資料です。eBPFによるゼロコード計装は「言語を問わず動く」と語られますが、Goバイナリへの関数レベルの計装は他言語にない4つの難所を抱えています。なぜ難しいのかを、CPUとメモリの仕組みという初歩から積み上げて、OBIの実装コードまで手元で確かめながら読める構成にしました。
おわりに
直近の話題から、わたしが気になったものを中心にお送りしました。
Blameless&Keep Constructiveで、Humility Respect Trust溢れるご意見・ご感想、誤りの指摘などいただけると幸いです。
さて、最近はこのコーナーで毎回トラコン（ICTSC: ICTトラブルシューティングコンテスト）の情報を紹介しています。
ICTSCはネットワーク・サーバー・ミドルウェア等の情報通信インフラを主な対象領域としたトラブルシューティングのコンテストです。参加はチーム戦で、本戦ではチームごとに論理的な演習環境と物理機器がアサインされ、物理機器を含めたトラブルシューティングも出題されます。
このICTSCは参加者が学生、運営も学生という珍しいイベントです。運営する学生たちを社会人の実行委員が支える形で10年以上運営してきています。最近は一次予選・二次予選・本戦があり、本戦では予選を勝ち上がった学生たちと運営でおよそ100名の「情報通信インフラに興味があり、行動力と相応の技術力を持つ」学生が集います。
ICTトラブルシューティングコンテスト2026では2026年9月19日に一次予選が開催されました。
参加いただいた皆さん、お疲れさまでした。ご参加いただきありがとうございました。開催にご協力いただいている協賛のみなさま、運営委員・実行委員のみなさま、いつもありがとうございます。引き続きよろしくお願いいたします。
二次予選に出場できるのは、一次予選の得点上位30チームとなります。本当は参加希望のみなさん全員に本戦の実機に触れ取り組んでいただきたいのですが、機材・場所・電力等諸々の都合があり叶いません。参加者のみなさまは一次予選・二次予選を経て本戦となります。本戦等でお会いできることを楽しみにしております。
ICTSCは完全ボランティアの任意団体でして、今年度からわたしが会長を務めることになったので、一生懸命宣伝しています。若者や入門者を育て裾野を広げることは、業界の持続に不可欠だと思って続けております。
また協賛は引き続き募集しています。賛同いただける方・ご協力いただける方はぜひお声掛けくださいませ。
ではでは。
