「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？
こんにちは。馬場（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につながるバックストーリーでもあります。
