クラウド/インフラ

AWS DMS Serverless Replication（CDC モード）が OOM（Out of Memory）で failed 状態になり、自動再起動の仕組みが検知できずに長期間停止していた問題について、根本原因と対策をまとめます。 構成 RDS (MySQL) → DMS Serverless (CDC) → S3 (Parquet) DMS Serverless Replication で全テーブルの CDC（Change Data Capture）を実行 S3 に Parquet 形式で日付パーティション付きで出力 EventBridge + Lambda で DMS 停止を検知し自動再起動する仕組みを構築済み 発生した事象 症状 prod 環境の DMS Serverless Replication が failed 状態で停止 エラーメッセージ: Replication out of memory. Stop Reason FATAL_ERROR Error Level FATAL CDC が完全に停止し、S3 へのデータ同期が止まっていた 発覚の経緯 手動確認で発見。自動再起動 Lambda の最終実行は約2ヶ月前で、それ以降は検知されていなかった。 根本原因 原因 1: EventBridge ルールのイベントパターンが不完全 自動再起動用の EventBridge ルールが REPLICATION_TASK_STOPPED のみを監視していた。 ...

AWS が「Agent Plugins for AWS」を公開しました。AI コーディングエージェント（Claude Code や Cursor など）に、AWS のアーキテクチャ設計からデプロイ実行までの能力を組み込むオープンソースのプラグインライブラリです。 Agent Plugins for AWS とは Agent Plugins for AWS は、AWS Labs が開発・公開したオープンソースプロジェクトです。コスト見積もり、Infrastructure as Code（IaC）の生成、デプロイといった AWS 固有のスキルセットを AI エージェントに追加できます。 プラグインは以下の要素で構成されています: Agent Skills: 複雑なタスクをステップバイステップで実行するワークフロー。デプロイやアーキテクチャ設計のベストプラクティスを手順として組み込んだもの MCP サーバー: 外部サービス、ドキュメント、料金データなどへのリアルタイム接続 Hooks: 開発者のアクションに対するバリデーションやガードレール deploy-on-aws プラグイン 現時点で提供されている主要プラグインが deploy-on-aws です。「deploy to AWS」と指示するだけで、以下の 5 ステップを自動実行します: コードベースの分析: アプリケーションの構成・依存関係を解析 AWS サービスの推奨: 最適な AWS サービスを理由付きで提案 コスト見積もり: 推奨構成の月額コストを試算 IaC の生成: CDK または CloudFormation でインフラコードを生成 デプロイ実行: ユーザーの確認後にデプロイ AWS によると、従来は数時間かかっていたデプロイフローが約 10 分で完了するとのことです。 Claude Code へのインストール Claude Code では、プラグインマーケットプレイス経由でインストールします: ...

きっかけ ある日、開発環境の Web アプリにアクセスしたら証明書の期限切れ警告が表示された。 確認してみると、ワイルドカード証明書 (*.dev.example.com) がちょうどその日に期限切れになっていた。さらにもう1つ古い証明書も半年前に失効済み。 Certificate Name: dev.example.com-0001 Domains: *.dev.example.com Expiry Date: 2026-03-17 (INVALID: EXPIRED) Certificate Name: dev.example.com Domains: *.dev.example.com dev.example.com Expiry Date: 2025-09-17 (INVALID: EXPIRED) 原因 certbot の renewal 設定を確認したところ、問題が見えた。 1 2 3 [renewalparams] authenticator = manual pref_challs = dns-01, authenticator が manual になっていた。 ワイルドカード証明書は DNS-01 チャレンジが必須だが、manual モードでは certbot が更新のたびに「この TXT レコードを DNS に追加してください」と対話的に聞いてくる。つまり 自動更新が不可能 な状態だった。 systemd timer (certbot.timer) は1日2回動いていたが、manual モードの証明書は自動更新をスキップされるため、期限切れまで放置されていた。 対応方針 2つの選択肢を検討した。 ...

「Vercelを使えばそこそこ大規模なアプリケーションまでインフラエンジニア要らずにいけるのよな」——元Yahoo!エンジニアで YouTuber のしまぶー氏（@shimabu_it）のポストが話題になった。Vercel CEO の Guillermo Rauch 氏の投稿に対するコメントで、「しかも大抵の場合インフラエンジニアがAWSやGCPで構築したものより高機能、高可用性、高パフォーマンス」と踏み込んだ発言をしている。 Vercelが実現する「インフラレス」開発 Vercelは Next.js の開発元として知られるが、プラットフォームとしての本質は開発者からインフラの複雑さを隠蔽することにある。 Framework-defined Infrastructure（FdI） Vercelが推進する Framework-defined Infrastructure は、Infrastructure as Code（IaC）の進化形だ。 従来のIaCでは、開発者がTerraformやCloudFormationでインフラを明示的に定義する必要があった。FdIでは、フレームワークのコードからインフラ構成が自動的に導出される。 ビルド時にソースコードを解析し、開発者の意図を理解 必要なインフラ構成（Edge Functions、Serverless Functions、Static Assets、ISR設定など）を自動生成 開発者は「何を作るか」に集中し、「どこにデプロイするか」を考える必要がない Self-driving Infrastructure Vercelは Self-driving Infrastructure というコンセプトも掲げている。本番環境の運用を自律的に管理し、実世界のインサイトを基にアプリケーションコードの改善まで行うというビジョンだ。 6人のエンジニアで年間360億トークンを処理 Vercelの「インフラ不要」の主張を裏付ける事例として、Durable社のケースが象徴的だ。 6名のエンジニアチームで300万ビジネスをサポート 年間360億トークン（日次1.1億トークン）を処理 新しいAIエージェントを1日で本番環境に展開可能 自社ホスティング比で3〜4倍のコスト削減 創業者は「インフラ構築ではなくエージェント開発に注力できるようになった」と評価している。 インフラエンジニアは本当に不要になるのか？ しまぶー氏は以前から「インフラエンジニアは二極化する」と指摘している: 高待遇化: クラウドサービスの基盤自体を作れるエンジニア 活躍の場が減少: アプリケーションのインフラを構築する程度のエンジニア 「基盤自体を作れるエンジニア」とは、VercelやAWSのサービスそのものを開発・運用する側のスキルセットを指す。具体的には以下のような領域だ: 分散システム設計: AWS LambdaやVercel Edge Functionsの実行基盤を設計・構築するスキル コンテナランタイム/オーケストレーション: Kubernetesを「使う」のではなく「作る・拡張する」レベル ネットワーク基盤: CDN、ロードバランサ、DNSを大規模に設計・運用するスキル ストレージエンジン: 分散データベースやオブジェクトストレージの内部実装 コンパイラ/ランタイム: サーバーレスプラットフォームのビルドパイプラインや実行環境の開発 つまり「AWS上にアプリをデプロイする」のではなく「AWSのようなサービスを作る」側の人材であり、このレベルのエンジニアはプラットフォームの進化によってむしろ需要が高まっている。 Vercelの基盤は何で動いているのか 「基盤を作る」とは具体的にどのレベルなのか。Vercel自身の技術スタックを見ると、その深さがわかる。 Vercelは当初 AWS Fargate でビルド処理を実行していたが、プロビジョニングに90秒かかる問題があった。そこで2023年に独自のコンピュート基盤「Hive」を構築し、起動時間を5秒に短縮した。 Hiveの技術スタックは以下の通りだ: レイヤー 技術 物理基盤 ベアメタルサーバー（“Boxes”） VM隔離 Firecracker microVM + KVM ビルド基盤 Hive（独自コントロールプレーン） 関数実行 AWS Lambda、Edge Functions オーケストレーション Amazon EKS（一部）+ 独自制御 ストレージ/キュー Amazon S3、SQS ネットワーク Amazon Global Accelerator 注目すべきは、OpenShiftのような既存のKubernetesディストリビューションは使われていない点だ。Firecracker はAWSがLambdaとFargateのために開発したオープンソースのmicroVMで、約300ミリ秒でVMを起動できる。Vercelはこの Firecracker + KVM の上に独自のオーケストレーション層を構築している。 ...

BigQuery ARRAY/STRUCT で速度 3 倍・コスト 25% 削減 — JOIN を消す「データの持ち方」最適化 @yoshitake_l 氏が X で共有した、BigQuery のデータ構造変更による劇的な改善結果が注目を集めています。 BigQuery でデータの持ち方を変えるだけで、クエリ処理速度を 3 倍に、クエリコストを 25% 削減できたので共有。試したクエリは、1:N の 2 つのテーブルの N 側を集計し、1 側と JOIN するシンプルなもの。使ったのは、ARRAY と STRUCT というデータ構造です。 「データの持ち方を変えるだけ」で速度 3 倍・コスト 25% 削減。SQL のチューニングではなく、テーブル設計の変更でこの結果を得ています。本記事では、なぜ ARRAY/STRUCT が JOIN より高速でコストが低いのか、その技術的な仕組みと実践方法を解説します。 なぜ JOIN は遅くて高いのか BigQuery の分散処理とシャッフル BigQuery の課金と速度の問題を理解するには、まず分散処理の仕組みを知る必要があります。 BigQuery の JOIN 処理の流れ: 1. テーブル A を複数のスロット（ワーカーノード）に分散読み込み 2. テーブル B を複数のスロットに分散読み込み 3. JOIN キーに基づいて、データを適切なスロットに「再配置」 → これが「シャッフル」 4. 各スロットでマッチング処理を実行 5. 結果を統合 問題: ステップ 3 のシャッフルが最大のボトルネック ├── スロット間のネットワーク通信が発生 ├── 大量の中間データが移動 └── 通信待ちの間、スロットが遊休状態になる BigQuery のオンデマンド課金は「スキャンしたバイト数」に比例します。JOIN では両方のテーブルのキー列と必要列をすべてスキャンするため、スキャン量が増えます。さらに、JOIN に必要なシャッフル処理が実行時間を大幅に伸ばします。 ...

インシデント対応入門 — 「バグ修正」で終わらせない組織レジリエンスの高め方 @MacopeninSUTABA 氏のポストが、SRE Lounge Hiroshima #1 で発表されたスライド資料『インシデント対応入門』を紹介しています。 『インシデント対応入門』が、全エンジニア・PMに刺さる。単なる「バグ修正」で終わらせない、組織としてのレジリエンスの高め方を徹底解説している。 著者の gr1m0h 氏は、インシデントマネジメント SaaS「Waroom」を開発する Topotal 社のソフトウェアエンジニア兼 SRE です。このスライドは閲覧数 5,600 を超え、エンジニアやPMの間で広く共有されています。本記事では、スライドの内容を軸に、インシデント対応の5つのフェーズとその実践方法を掘り下げます。 なぜ「バグ修正」では不十分なのか 障害が起きたとき、コードを直して「修正完了」で終わりにしていないでしょうか。しかし、同じ種類のインシデントが繰り返し発生する組織は少なくありません。その原因は、インシデント対応を「技術的な修正」だけで完結させてしまうことにあります。 gr1m0h 氏のスライドが提示するのは、インシデント対応を5つのフェーズで捉えるフレームワークです。修正は全体のプロセスの一部に過ぎず、準備・検知・振り返り・恒久対応まで含めた組織的な取り組みが必要です。 5つのフェーズで捉えるインシデント対応 フェーズ1: 準備 インシデントが発生する前の体制整備です。「準備がないと『どうする？』から始まる」という指摘は、多くの現場で実感があるのではないでしょうか。 具体的に準備すべき項目は以下の通りです。 緊急度基準の策定: インシデントの重大度（SEV）を定義する 連絡ルールの文書化: 誰が、誰に、どの手段で連絡するかを明文化する 手順書の作成: 初動対応の手順を事前に整備する 監視設定: アラートの閾値やエスカレーション条件を設定する SEV（重大度）レベルの定義例 スライドでは4段階の重大度レベルが紹介されています。 レベル 状態 対応の緊急度 SEV1 サービス全体が停止 即座に全員招集 SEV2 主要機能の障害 速やかに対応チーム編成 SEV3 一部機能の劣化 営業時間内に対応 SEV4 軽微な問題 通常優先度で対応 重要なのは、この基準が事前に合意されていることです。インシデント発生時に「これはSEV1なのか2なのか」を議論している時間はありません。 フェーズ2: 検知・初動 「『様子見』している間にも被害は広がる」というスライドの指摘は、初動の遅れがインシデントの影響を拡大させる現実を端的に表しています。 検知・初動で行うべきことは以下の4つです。 状況確認: 何が起きているかを把握する 影響範囲の特定: どのユーザー・機能に影響しているかを確認する 緊急度の判定: SEV レベルを判断する 関係者への連絡: 定められたルールに従ってエスカレーションする フェーズ3: 対応・復旧 対応フェーズで最も重要な原則は、指揮と作業の分離です。 ...

CloudFront → ALB → Django 構成で API レスポンスの URL スキームが http:// になる問題と解決策 はじめに AWS の CloudFront + ALB + ECS Fargate で Django REST Framework (DRF) の API サーバーを運用していたところ、API レスポンスに含まれる URL が http:// で返されるという問題に遭遇しました。本記事では原因の調査過程と、最終的な解決策を紹介します。 構成 Client (HTTPS) ↓ CloudFront (SSL終端, us-east-1) ↓ HTTP ALB (HTTP:80のみ受付, ap-northeast-1) ↓ HTTP ECS Fargate (Gunicorn + Uvicorn, port 9000) ↓ Django REST Framework CloudFront がSSLを終端し、ALB へは HTTP で転送する構成です。 問題 DRF の API ルート (/api/rest/) にアクセスすると、レスポンスに含まれる URL がすべて http:// になっていました。 ...

CDC AWS環境で実現するには、主に以下の2つの方法が主流です。 AWS DMS (Database Migration Service) の利用 (実績が豊富で柔軟性が高い) Amazon RDS ゼロ ETL 統合 (最もシンプルで最新の選択肢) それぞれの構成と特徴を詳しく解説します。 1. AWS DMS (Database Migration Service) を利用した構成 AWS DMSは、データベース間のデータ移行や継続的なレプリケーション（CDC）を行うための専用サービスです。 構成の概要 RDS for MySQLの設定: MySQLの**バイナリログ（Binlog）**を有効にし、フォーマットをROWに設定します。DMSはこれを読み取って変更を追跡します。（CDCの必須設定） AWS DMS コンポーネント: レプリケーションインスタンス: データ移行（レプリケーション）を実行する専用のEC2インスタンスです。ソースとターゲットの間でデータを読み書きし、マッピングや変換を行います。 ソースエンドポイント: RDS for MySQLへの接続情報を定義します。 ターゲットエンドポイント: Amazon Redshiftへの接続情報を定義します。 移行タスク: CDC（継続的レプリケーション）を定義するコア設定です。どのテーブルを移行するか、フルロード後にCDCを継続するかなどを指定します。 データフロー: RDS for MySQLで変更（UPDATE/INSERT/DELETE）が発生すると、その変更がBinlogに記録されます。 DMSのレプリケーションインスタンスがBinlogを継続的に読み取ります。 DMSは変更データをRedshiftに適した形式に変換し、Redshiftクラスターに書き込みます（通常はS3経由でCOPYコマンドを使用）。 メリット・デメリット 項目 メリット デメリット 柔軟性 非常に高く、多種多様なデータベースに対応。テーブルやスキーマのフィルタリング、データ変換（トランスフォーメーション）も可能。 コスト レプリケーションインスタンスの料金が継続的に発生する。 運用 インスタンスの管理（サイズ選定、冗長性など）や、Binlogの保持期間の管理が必要。 安定性 実績が豊富で安定しているが、タスク設定やインスタンスサイズによってはチューニングが必要になる場合がある。 2. Amazon RDS ゼロ ETL 統合 (推奨) これは、2023年以降に登場した新しい機能で、最もシンプルかつ管理負担の少ないCDCの方法です。現時点ではAurora MySQLからRedshiftへの統合が中心ですが、RDS for MySQLへの対応も進んでいます。 ...

supabase https://supabase.com/ 飛躍的に伸びているBaaS「Supabase」の概要と所感 PostgREST https://docs.postgrest.org/en/v12/ AWS https://github.com/supabase-community/supabase-on-aws Terraform: https://supabase.com/docs/guides/deployment/terraform PostGraphile https://www.graphile.org/postgraphile/

AWS Device Farm AWS Device Farmとは？利点と利用方法も紹介します！ AWS Device Farmとは？実機を使ったモバイルアプリのテストについて解説 AWS Device Farmは、実際のモバイルデバイスやデスクトップブラウザを使用してアプリケーションをテストするサービスです。以下のような仕組みで動作しています： 実機デバイスの使用: AWS Device Farmは、エミュレーターやシミュレーターではなく、実際のスマートフォンやタブレットを使用します。 これにより、メモリ使用量、CPU負荷、位置情報、メーカーやキャリアによるファームウェアの違いなど、実際の使用環境に近い条件でテストが可能です 1 2。 リモートアクセス: 開発者はAWSのクラウド上にあるこれらの実機デバイスにリモートでアクセスし、アプリケーションをインストールしてテストを実行します。 これにより、物理的なデバイスを手元に用意する必要がなくなります 1 2。 自動化と手動テスト: Device Farmは、AppiumやEspressoなどのオープンソースのテストフレームワークを使用して自動テストを実行できます。 また、リモートアクセスを利用して手動でのテストも可能です 1 2。 テスト結果の収集と分析: テストの実行中に、動画、ログ、パフォーマンスデータなどが収集され、これらのデータを分析することで、アプリケーションの問題点を迅速に特定し、修正することができます 1 2。 スケーラビリティ: 複数のデバイスやブラウザで同時にテストを実行できるため、テストスイートの実行時間を短縮し、効率的にテストを進めることができます 1 2。 このように、AWS Device Farmは実際のデバイスを使用して、より現実に即したテスト環境を提供し、アプリケーションの品質向上を支援しています。