はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富( @yannKazu1 )です。 VPC Flow Logs に、 VPC 内のサーバーがインターネット上の IP の 6379 番ポートと通信している 行が記録されているのを見つけました。6379 は Redis のポートなので、字面だけ読むと「インターネット側に Redis がいて、そこに繋ぎに行っているのか？」と読めてしまいます。 この記事では、このログをパケットのヘッダーとしてどう読むか、そしてそこから立てた仮説を Flow Logs だけでどう裏付けたかを書いていきます。 きっかけ VPC Flow Logs を眺めていたときのことです。 Redis のポートである 6379 に絞ってフィルタをかけたら、見慣れないパブリック IP が出てきました。 本記事の IP アドレスについて 実際の値は伏せ、すべてダミーに差し替えています。グローバル IP はドキュメント用に予約されている RFC 5737 のレンジ（ 192.0.2.0/24 、 198.51.100.0/24 、 203.0.113.0/24 ）、CGNAT 内部のアドレスは RFC 6598 の 100.64.0.0/10 、VPC 内と宅内のアドレスは RFC 1918 のプライベートレンジから適当な値を置いています。ENI ID と ISP 名も伏せました。 srcaddr dstaddr dstport action 10.0.1.100 203.0.113.45 6379 ACCEPT 10.0.1.100 は VPC 内のプライベート IP、 203.0.113.45 はインターネット上のパブリック IP です。つまりこの行をそのまま読むと、 VPC 内から外部の IP の 6379 番ポートへ通信している ことになります。 6379 は Redis のポートです。となると「知らないうちに外部の Redis に繋ぎに行っているのか？」「何かに乗っ取られて外のキャッシュにデータを投げているのか？」という絵が浮かんでくるログです。少なくとも、VPC 内で使っている Redis は VPC に閉じているはずなので、この行の存在自体が説明できない。思わず手が止まる 1 行だと思います。 パケットレベルで考えれば、当たり前だった ここで思い出すべきは、 Flow Logs がどのレイヤーの記録なのか です。 Flow Logs に残るのは L3/L4、つまり IP ヘッダーと TCP ヘッダーの中身だけです。入っているのは「送信元 IP / 送信元ポート / 宛先 IP / 宛先ポート」の 4 つ組といったメタ情報だけです。 この目で読み直すと、結論は簡単です。 この ENI が ALB のものだと仮定すると、クライアントの送信元ポートが 6379 なら、戻りのパケットはその 6379 宛になります （ALB であることは後述のログで確認しています）。改めて送信元・宛先のポートを両方一緒に出力してみると、内部側は 443 番でした。TCP は行きと戻りで送信元と宛先が入れ替わるだけなので、この行は 203.0.113.45:6379 → 10.0.1.100:443 の戻りと考えれば一目瞭然です。6379 を名乗っているのはクライアント側で、 6379 は宛先ポートでなく送信元ポート 。接続ごとに振られる使い捨ての番号で、Redis とは関係ありません。 しかもクライアントの送信元ポートは、端末から ALB に届くまでに何度も NAT で付け替えられます。そのどこかで 6379 が選ばれるのは、 十分にあり得るし、何も不思議ではないシナリオ です。 この流れを整理しておきます。 端末から ALB の ENI までに起きていること 一般ユーザーがブラウザでサイトを開いてから、そのパケットが ALB の ENI に届くまで、いくつもの機器を経由します。そしてそのたびにヘッダーが書き換えられます。 flowchart TD A["端末（スマホ・PC）<br/>src 192.168.1.5:51000<br/>dst 192.0.2.10:443"] B["宅内ルーター（NAT）<br/>src 100.64.12.7:40277<br/>dst 192.0.2.10:443"] C["ISP の CGNAT<br/>src 203.0.113.45:6379<br/>dst 192.0.2.10:443"] D["Internet Gateway<br/>src 203.0.113.45:6379<br/>dst 10.0.1.100:443"] E["ALB の ENI<br/>ここで Flow Logs に記録される"] A -->|"送信元を書き換え"| B B -->|"送信元を書き換え → 6379 が誕生"| C C -->|"宛先を書き換え"| D D --> E 各段階を順に見ていきます。 1. 端末 ブラウザが接続を開くとき、OS が送信元ポートを 1 つ払い出します。これは「この通信を識別するための整理番号」であって、サービスの種類とは無関係です。Linux なら 32768〜60999、Windows なら 49152〜65535 から選ばれます（設定で変更可能）。 宛先は DNS で引いた ALB のパブリック IP と 443 番です。 2. 宅内ルーター 家庭内のプライベート IP のままでは外に出られないので、ルーターが NAT で送信元を書き換えます。このとき送信元ポートも付け替えられます。 3. ISP の CGNAT ← ここで 6379 が生まれる IPv4 アドレスが枯渇しているため、ISP は複数の利用者で 1 つのグローバル IP を共有する構成を取ります。CGNAT と呼ばれる仕組みです。 同じグローバル IP を共有するので、「誰の通信か」はグローバル IP とポート番号の組み合わせで見分けることになり、ここでもう一度ポートが付け替えられます。しかも多数の利用者分をさばくため、 well-known ポート以外の広い範囲を、ポートのプールとして使う実装があります 。OS がエフェメラルポートとして使う 49152〜65535 の範囲に収まらず、登録済みポート帯の番号が払い出されることもあります。 そして今回、たまたま 6379 が払い出されました。この瞬間から、この通信はずっと「6379 番」を名乗って進むことになります。 4. Internet Gateway VPC の入口です。ここでは宛先側が書き換えられます。端末は ALB のパブリック IP 宛に送っていますが、VPC 内部ではプライベート IP に変換されます。 5. ALB の ENI 到着。この時点のヘッダーがそのまま Flow Logs の 1 行になります。そして ALB が返事を返すと、送信元と宛先が反転したもう 1 行が記録されます。 sequenceDiagram participant C as クライアント（CGNAT 通過後）<br/>203.0.113.45 participant E as ALB の ENI<br/>10.0.1.100 C->>E: 203.0.113.45:6379 → 10.0.1.100:443 Note over E: Flow Logs 1 行目（インバウンド） E->>C: 10.0.1.100:443 → 203.0.113.45:6379 Note over E: Flow Logs 2 行目（アウトバウンド） 最初に目に入ったのは、この 2 行目でした。 行きのパケットの送信元ポートが、そのまま戻りのパケットの宛先ポートになる。TCP としてはごく当たり前の挙動ですが、これをポート番号だけで「6379 宛の通信」と読んでしまうと、一気に怪しい通信に見えてきます。 ログで裏付ける とはいえ、ヘッダーの読み方だけでは「そう解釈できる」までです。ログで裏付けを取りました。確認したのは 2 点です。 対向のインバウンドフロー（ 外部:6379 → 内部:443 ）が同じ ENI・同じ時間帯に存在するか その ENI が ALB のものかどうか 対向フローは全件見つかった 該当した 3 件すべてに、ペアとなるインバウンドが存在しました。 方向 送信元 宛先 パケット バイト → リクエスト 203.0.113.45:6379 10.0.1.100:443 31 10,164 ← レスポンス 10.0.1.100:443 203.0.113.45:6379 39 18,401 → リクエスト 198.51.100.72:6379 10.0.3.200:443 4 285 ← レスポンス 10.0.3.200:443 198.51.100.72:6379 7 405 → リクエスト 198.51.100.72:6379 10.0.3.200:443 14 4,027 ← レスポンス 10.0.3.200:443 198.51.100.72:6379 16 7,670 4 つ組がきれいに反転していて、1 対 1 で対応しています。完全な TCP セッションのペアです。 通信は外から始まっている 。VPC 内部から外の 6379 に繋ぎに行ったわけではない、という有力な裏付けになりました。 ENI は ALB のものだった 該当した 2 つの ENI に流れている他のトラフィックを見てみると、すべてが 外部IP:エフェメラルポート → 10.0.x.x:443 の形でした。送信元は国内の大手 ISP ばかり。 要するに、これは ALB の ENI です。一般ユーザーが HTTPS でサイトを見に来ている入口そのものでした。 送信元 IP を引いてみる 念のため GeoIP で送信元を確認しました。 IP 種別 203.0.113.45 国内コンシューマー ISP（モバイル回線） 198.51.100.72 国内コンシューマー ISP（固定回線） どちらも一般家庭・モバイル向けの ISP です。攻撃の出所になりやすいデータセンターや VPS 事業者の IP ではありません。 ただし、WHOIS や GeoIP で分かるのは「どの ISP の、コンシューマー向けらしいレンジか」までです。 その IP が CGNAT の出口かどうかは、外から見て断定できません 。ここで言えるのは「一般利用者の回線から来ていると考えて矛盾がない」という裏付けです。 バイト数の傾向も HTTPS らしく、レスポンスのほうがリクエストより大きい（10,164 → 18,401）。Web ページを返しているなら自然な形です。 結論 何も起きていませんでした。 ISP の CGNAT が送信元ポートを付け替える際に、たまたま 6379 を割り当てただけ。それ以降その通信はずっと「6379 番」を名乗って進み、ALB がそこへ返事を返した、というだけの話でした。 そしてこれは「たまたま今日起きた珍事」ではなく、 仕組み上、アクセスがある限り起こり続ける現象 です。6379 に限った話でもなく、3306（MySQL）でも 5432（PostgreSQL）でも同じことが起きます。 この仕組みを知らないとハマる落とし穴 今回は調査で済みましたが、理解していないと実害が出るケースもあります。 NACL の outbound DENY で本番障害になる これが一番怖いパターンです。セキュリティ強化のつもりで NACL に outbound: 6379 DENY を入れていると、 たまたま送信元ポート 6379 を引いたユーザーだけサイトが見られない という障害になります。 しかも症状が最悪です。再現しない。特定の人だけ。時間が経つと（NAT のポートが変わると）直る。問い合わせを受けても「こちらでは再現しません」という回答になりやすい類の事象です。 セキュリティグループはステートフルなので戻りが自動で通り、この問題は起きません。ハマるのはステートレスな NACL のほうです。同じ理由で、ステートレスなファイアウォールや、ポートベースの ACL も同様に要注意です。 Flow Logs の限界を知らないと結論を出しすぎる Flow Logs は ENI 単位の記録なので、見えるのは「ENI に届いた時点のヘッダー」だけです。 flowchart LR A[端末] --> B[宅内ルーター] --> C[ISP の CGNAT] --> D[Internet Gateway] D --> E subgraph OBS["VPC Flow Logs が観測できる範囲"] E["ALB の ENI"] end 見える — 送信元/宛先の IP とポート、プロトコル、パケット数、バイト数、ACCEPT/REJECT、TCP フラグ（ tcp-flags 。SYN / SYN-ACK から接続を開始した向きも分かる） 見えない — 端末や宅内ルーターの実 IP（NAT で消えている）、ALB のパブリック IP（IGW が書き換えた後しか届かない）、通信の中身、パケット 1 つごとの TCP フラグ（ tcp-flags は集約単位のビットマスクなので、ACK や PSH は含まれない） 先ほど 5 段階で経路を追いましたが、Flow Logs に残るのは最後の 1 段階だけです。手前で何度 NAT されたかは記録に一切現れません。 なので今回証明できたのは「この通信は ALB 宛の正常な HTTPS である」ところまでです。その中身が正当かを問うなら、 見に行くべきログのレイヤーが変わります 。どのパスにリクエストが来て何を返したのかならアクセスログ、そのリクエストがシステムの中で何をしたのかならアプリケーションのログ。知りたいことがどのレイヤーの話なのかで、見るログを選ぶ必要があります。今回の論点は L3/L4 の話だったので、Flow Logs だけで決着がつきました。 おわりに 結果は空振りでしたが、ヘッダーの向きでついた見当を、対向フロー・ENI・送信元 IP で裏付けて「正常です」と言い切れたのは良かったと思います。 そしてその見当がついたのは、端末 → 宅内ルーター → CGNAT → Internet Gateway → ENI という流れと、各段で何が書き換わるのかが頭に入っていたからです。 どのレイヤーのログを見れば決着がつくのかを選べるかどうかは、経路の全体像を持っているかで決まる と実感しました。

こんにちは。サイオステクノロジー OSS サポート担当 山本です。 今回は前回お話しした「TimescaleDB」について、簡単な検証を行ってみたいと思います。 ■ざっくりおさらい：TimescaleDB って？ TimescaleDB は、 Tiger Data 社 (旧 Timescale 社) による PostgreSQL の拡張機能 で、 超大規模データの集計処理に特化 した「 時系列データベース / 列指向データベース 」として振る舞う “hypertable” という特殊なテーブルを作成・管理する機能などを提供してくれます。 ■検証：TimescaleDB って実際に効果あるの？ さて、前回は TimescaleDB の概念についてお話ししましたが、今回は「 同じような処理を TimescaleDB と通常の PostgreSQL それぞれでやってみた場合、どれくらい差が出るのか？ 」を実際に試してみます。 ■TimescaleDB の導入と今回の検証方法について まず導入方法については、環境ごとにコマンド単位でまとめられている公式ドキュメントがありますので、こちらをご参照ください。 参考： Install self-hosted TimescaleDB – Tiger Data ※note： TimescaleDB が対応しているバージョンの PostgreSQL が必要 になります。上記ドキュメントには PostgreSQL 自体のインストール手順も含まれていますが、すでに（TimescaleDB 未対応の）別バージョンの PostgreSQL がインストールされている環境ではうまく動作しない可能性がありますのでご注意ください。 また、今回の検証は GitHub – timescale/timescaledb のクイックスタートガイド（Step 3〜5）をベースに行います。 ■【検証1】通常の PostgreSQL の場合 まずは TimescaleDB の機能を 使わない 通常の PostgreSQL での例から見ていきましょう。 検証用のデータベースを作成して接続し、念のため拡張機能の一覧を表示させて TimescaleDB が導入されていないことを確認します。 続いて、サンプルデータ格納用のテーブルを作成し、乱数を用いたサンプルデータの生成を行います。 [記録時間・センサー番号・温度・湿度・気圧] を持つサンプルデータを 7776001個生成できます。 （クイックスタート Step 3 & 4） クエリの実行時間の表示を有効にしたうえで、以下のクエリを実行してみます。 　・サンプルデータ数 (Step4：末尾のクエリ) 　・各センサーにおける7日間のサンプルデータ数と [温度・湿度・気圧] の平均値 (Step5：Query 1) 　・各センサーにおける最新データ (Step5：Query 4) ※ Step 5 の Query 2 & 3 は TimescaleDB 専用の拡張関数を使用するため、ここではスキップします。 実行結果は以下の通りでした。 　・データ数： 約 1.9 秒 　・7日間のデータ数/平均値： 約 2.5 秒 　・最新データ： 約 54 秒 （！） ■【検証2】TimescaleDB を使用した場合 次に、同じ処理を TimescaleDB を有効にした環境で試してみます。 データベースを作成して接続し、”CREATE EXTENSION” で TimescaleDB 拡張機能を有効化します。 続いて、サンプルデータ格納用のテーブル（Hypertable）を作成し、先ほどと同じく乱数を用いたサンプルデータの生成を行います。 生成後、（今回は検証のため）手動でデータの最適化（＝列指向型への変換・圧縮）を実行します。（クイックスタート Step 3 & 4） クエリの実行時間の表示を有効にしたうえで、先ほどと同じ以下のクエリを実行してみます。 　・サンプルデータ数 (Step4：末尾のクエリ) 　・各センサーにおける7日間のサンプルデータ数と [温度・湿度・気圧] の平均値 (Step5：Query 1) 　・各センサーにおける最新データ (Step5：Query 4) それぞれの結果は以下のようになりました。 　・データ数： 約 0.05 秒 　・7日間のデータ数/平均値： 約 0.05 秒 　・最新データ： 約 0.07 秒 さらに、TimescaleDB 独自の拡張関数（”time_bucket()” など）を活用することで、「1時間ごとの平均値」や「日次の平均値」などのような時間軸での柔軟な集計処理も極めて高速に行うことができます。 ■TimescaleDB あり/なしの差を比べてみる TimescaleDB あり/なしのクエリ実行結果を並べて整理してみましょう。 検証項目 通常の PostgreSQL TimescaleDB 全データ件数カウント 約 1.9 秒 約 0.05 秒 7日間の平均値集計 約 2.5 秒 約 0.05 秒 最新データの取得 約 54.0 秒 約 0.07 秒 ご覧のとおり、TimescaleDB を使用したほうが 圧倒的に高速 に処理できていることがわかります。 また、 ディスク使用量 についても確認しておきましょう。 2つのデータベースには、まったく同じコマンドで同数のサンプルデータを生成しましたが、その結果は… このとおり、TimescaleDB ありだと (なしの場合の比べて) ディスク使用量が半分ほど となりました。 (今回の検証では半分程度の圧縮率になりましたが、前回お話ししたとおり圧縮に都合のよいデータであれば “最大95％程度” の圧縮率になる可能性もあります) このように、 時系列データやログデータといった TimescaleDB に適した用途 であれば、TimescaleDB は 速度面でも容量面でも圧倒的なアドバンテージがある と言えます。 ■最後に 今回は TimescaleDB を実際の検証を通して確認してみました。 処理速度・ディスク容量の双方で、非常に強力な効果を発揮することがお分かりいただけたかと思います。 なお、今回は chunk の圧縮 (列指向方式への最適化) を手動で行ないましたが、この chunk の圧縮および削除はデフォルトでは自動実行されません。 これらを自動化する設定 (ポリシー設定) をはじめ、パフォーマンス向上のための設定 (chunk 分割条件など) が存在するため、実際の運用の際にはこれらの確認も忘れないようにしてください。 また、今回の検証はあくまで “TimescaleDB が得意とするシナリオ” での比較である点にはご注意ください。 前回お話ししたとおり、TimescaleDB は大規模データの蓄積・集計に特化しており、行単位での個別編集や削除といった操作は著しく苦手とするため、 決して万能なデータベースというわけではありません 。 しかし、要件がマッチするシステムであれば、ディスク消費量の削減やレスポンス改善に絶大な効果をもたらしてくれます。 時系列データの扱いに課題をお持ちの方は、ぜひ導入を検討してみてはいかがでしょうか。 前回記事： 時系列データベース「TimescaleDB」って何なんだ？ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post TimescaleDB って本当に早いのか？ first appeared on SIOS Tech Lab .

Amazon プライムデー 2026 はプライム会員限定で、2026 年 6 月 23 日から 26 日まで開催され、35 を超えるカテゴリーで数百万件のお得な情報が提供されました。 AWS がどのようにプライムデー ( 2016年 、 2017年 、 2019年 、 2020年 、 2021年 、 2022年 、 2023年 、 2024年 、 2025年 ) を支えてきたかをご紹介する毎年恒例の取り組みの一環として、お客様の素晴らしいショッピング体験を実現した AWS のサービスと、トップクラスの実績を記録したメトリクスをご紹介します。 数値で見るプライムデー 2026 例年通り、プライムデーは AWS によって支えられています。最も興味深いメトリクスと、驚異的なメトリクスをいくつか紹介します。 Amazon Elastic Compute Cloud (Amazon EC2) と AWS Graviton – Amazon プライムデー 2026 の開催中、AWS Graviton は Amazon.com が使用する Amazon EC2 コンピューティングの最大 49% を担いました。 Amazon Elastic Block Store (Amazon EBS) – プライムデー 2026 の開催中、当社の高性能ブロックストレージサービスである Amazon EBS の I/O オペレーションはピーク時に 24.8 兆回に達し、1 日あたりのデータ量は 1 エクサバイトを超えました。 AWS Lambda – AWS Lambda は、プライムデー 2026 の開催中、1 日あたり 2.3 兆件を超える呼び出しを処理しました。 Amazon Elastic Container Service (ECS) および Fargate – プライムデー 2026 の開催中、Amazon ECS は AWS Fargate 上で 1 日平均 1 億 5,830 万件のタスクを起動しました。これは、前年のプライムデーにおける平均から 47.7% 増加した数値です。 Amazon CloudFront – Amazon CloudFront は、プライムデー 2026 のグローバル開催中 2.1 兆件を超える HTTP リクエストを処理しました。これは、リクエスト総数が 2025 年のプライムデーと比較して 5% 増加した数です。 Amazon DynamoDB – フルマネージドのサーバーレス分散型 NoSQL データベースである Amazon DynamoDB は、Alexa、Amazon.com のサイト、すべての Amazon フルフィルメントセンターなど、トラフィック量の多い複数の Amazon のプロパティとシステムを支えています。2026 年 6 月 23 日から 6 月 26 日まで開催されたプライムデー 2026 の期間中、DynamoDB は 59 兆件を超えるリクエストを処理しました。DynamoDB は、1 桁ミリ秒のレスポンスを提供し、ピーク時には 1 秒あたり 1 億 9,200 万件のリクエストを処理しながら、高可用性を維持しました。 Amazon Aurora – プライムデーでは、PostgreSQL、MySQL、DSQL 向けにグローバル規模で高いパフォーマンスと可用性を実現するために構築されたリレーショナルデータベース管理システム (RDBMS) である Amazon Aurora が、数千億件のトランザクションを処理し、5,491 テラバイトのデータを格納し、1,194 テラバイトのデータを転送しました。 Amazon ElastiCache – プライムデーの開催中、Amazon ElastiCache が、ピーク時には 1 日あたり 2,300 兆件を超えるリクエスト、1 分間に 2.1 兆件を超えるリクエストを処理しました。 Amazon Kinesis Data Streams – フルマネージドサーバーレスデータストリーミングサービスである Amazon Kinesis Data Streams は、プライムデー 2026 の開催中に、ピーク時には 1 秒あたり 9 億 8,800 万件のレコードを処理しました。 Amazon Simple Notification Service (SNS) – アプリケーション間およびアプリケーション対人通信用のフルマネージドパブ/サブメッセージングサービスである Amazon SNS は、プライムデー 2026 の開催中、1 日あたり 5 兆通のメッセージを配信しました。 Amazon Simple Queue Service (Amazon SQS) – マイクロサービス、分散システム、サーバーレスアプリケーション向けのフルマネージドメッセージキューイングサービスのである Amazon SQS は、プライムデー 2026 の開催中、ピーク時に 1 秒あたり 2 億 1,300 万件のメッセージを受信しました。 AWS CloudTrail – AWS CloudTrail は、ガバナンス、コンプライアンス、およびオペレーション監査のために、1 日あたり数十億件の API アクティビティイベントを処理しています。プライムデー 2026 の開催中、その件数はわずか 4 日間で 3.6 兆件に急増し、プライムデー 2025 と比較して 44% 増加しました。 AWS CloudWatch – Amazon CloudWatch は、プライムデー 2026 の開催中、1 日あたり 2.15 千兆件を超えるメトリクス観測データを処理しました。 Amazon GuardDuty – プライムデー 2026 の開催中に、Amazon GuardDuty は、1 時間あたり平均 14.08 兆件のログイベントをモニタリングしました。これは、昨年のプライムデーと比較すると 59% の増加です。 AWS Fault Injection Service (FIS) – 当社は、プライムデーにおいて Amazon.com が高可用性を維持できるようにするため、44,000 件を超える AWS FIS 実験を実施しました。これは、2025 年に実施した数の 6 倍超です。 スケールするための準備 同様のビジネスクリティカルなイベント、製品のリリース、移行の準備をしている場合は、 AWS Countdown Premium を活用することをお勧めします。小売業界の繁忙期から主要なスポーツイベント、選挙、医療保険の加入期間に至るまで、最も重要な時期に完璧な体験を提供できるよう支援します。当社のエキスパートが、セキュリティとパフォーマンスを維持しながら大量のトラフィックの急増に対処できるよう、インフラストラクチャの管理を支援します。お客様のチームと連携し、インフラストラクチャの拡張、需要の急増時のコストの最適化、セキュリティ対策の強化、リアルタイムの需要の監視を行います。詳細については、 ビジネスクリティカルイベントに関する AWS Countdown Premium をご覧ください。 2027 年も、どのような記録が破られるか本当に楽しみです! — Channy 原文は こちら です。