クラウド/インフラ

Raspberry Pi を遠隔地に何台もデプロイすると、いつも頭を悩ませるのが「文鎮化」と「OS アップデート」だ。SSH で 1 台ずつ繋いで作業するのは現実的ではなく、現地に出向くのはさらに困難だ。 balenaCloud は、まさにこの問題を解くために作られたマネージド IoT エッジプラットフォームだ。ひと言で言えば、IoT デバイスを Web サーバーのように運用管理できる仕組みだ。Raspberry Pi のような SBC（シングルボードコンピュータ）や産業用 PC を、クラウド経由でフリート単位に一括管理できる。 balenaCloud の仕組み — balenaOS と balenaEngine balenaCloud の最大の特徴は、アプリケーションを Docker コンテナとして動かす点にある。 コンポーネント 役割 balenaOS Raspberry Pi にインストールする専用の軽量 OS。OTA（Over-The-Air、ネットワーク経由の更新）に特化している balenaEngine Docker を IoT 向けに軽量化したコンテナエンジン 管理コンソール ブラウザで全拠点のデバイスを状態確認、ログ閲覧、再起動、アプリのデプロイ 開発者は手元の PC で書いたコードを balena push するだけで、世界中のフリートに一斉配信できる。Docker Compose 形式（docker-compose.yml）でマルチコンテナ構成を定義することも可能だ。 なぜ Raspberry Pi 運用で選ばれるのか 1. OTA 更新で「文鎮化」を防ぐ A/B パーティション balenaOS は A/B パーティション方式を採用している。デバイス内に OS が入る領域が 2 つあり、新しい OS は常に現在動いていない方のパーティションに書き込まれる。 ...

IoT システムや SaaS の提案書を書いていると、お客様から「このシステム、ちゃんと動くんですか?」と聞かれます。この質問にどう答えるか で、契約交渉の主導権が決まります。 「99.9% 動きます」と言い切れば SLA（契約）になり、下回ったら違約金。「目標値です」と言えば SLO（内部目標）で、未達でも返金義務はない。この 1 文字違いで法的拘束力が変わります。 本記事では、SRE（Site Reliability Engineering）業界で標準となっている SLI / SLO / SLA の 3 用語の 違いと使い分け を、提案書を書く立場から整理します。 3 用語の違い（要点） 略語 正式名 一言で 性格 SLI Service Level Indicator 計測する指標 データ SLO Service Level Objective 目指す目標 内部約束 SLA Service Level Agreement 契約上の保証 対外契約 順序は SLI → SLO → SLA で考えます。 SLI で「何を測るか」を決める（例: イベント検知から通知メール送信までの遅延時間） SLO で「目標値」を内部で握る（例: 95%ile が 60 秒以内） SLA で「契約条項」に格上げする（例: SLO 違反が月 3 件超えたら月額の 10% 返金） なぜ 3 つに分かれているのか Google SRE Book が提唱した「エラーバジェット」の考え方が背景にあります。 ...

HubSpot は API 認証の選択肢が多く、「結局どれを使えばいいのか」が混乱しがちです。特に Claude Code から HubSpot を操作したい場合、現在は 6 種類の認証手段が併存しています: 非公開アプリ（Private App） 旧 API キー（廃止済み） MCP 認証アプリ（HubSpot 公式 MCP Server） パーソナルアクセスキー（Personal Access Key） 開発者 API キー（Developer API Key） サービスキー（Service Key、新規 Beta） この記事では、それぞれの違い・推奨用途・Claude Code から使う場合の選び方を整理します。なお旧 API Key は廃止済みですが、参考情報として記事末尾で触れます（実質的な選択肢は 6 つです）。 結論を先に言うと: 用途で 2 軸に分かれます。 アドホックに自然言語で操作したい（営業・マーケが Claude Code から HubSpot を触る等） → 公式 MCP サーバー 本番運用・バッチ・Webhook など継続的なシステム統合 → REST API 直叩き + Service Key（新規）/ Private App（既存） 両者は競合ではなく補完関係で、実務では併用するのが現実解です。 早見表 認証方式 用途 スコープ トークン寿命 状態 Claude Code から使うなら HubSpot MCP Server（公式） AI エージェントから HubSpot 操作 アプリと同等 OAuth ベース ✅ 2025-2026 リリース ✅ 最も推奨（1 行で接続） Service Key（新） システム間データ連携 アカウント単位の細かい権限 永続 ✅ 2026-02-10 Public Beta ✅ Private App の後継、新規ならこれ Private App 単一アカウント向け統合 アプリ単位で細かく設定 永続 ⚠️ 維持されているが、新規は Service Key 推奨 ✅ シンプルな REST 呼び出し OAuth 2.0（Public App） Marketplace アプリ・複数アカウント scope ベース access 30 分・refresh で更新 ✅ 公式・現役（v3 が新版） △ 自前で OAuth フロー実装が必要 Personal Access Key（PAK） HubSpot CLI 認証 アカウントごと 永続（rotate 可能） ✅ 現役 △ CLI 経由の操作のみ Developer API Key Developer Account 内のアプリ管理 開発者アカウント全体 永続 ✅ 現役 △ アプリ管理用、CRM データには不向き 旧 API Key（参考） 単純な API 呼び出し アカウント全体 永続 ❌ 2022-11-30 廃止 ❌ 使えない 各認証方式の詳細 ① 旧 API Key（廃止済み、参考情報） HubSpot ポータルの「Integrations → API Key」から発行できたアカウント単位の単一キー。 ...

前回の記事で「Apprise + 自作 Web サービスで OnCall 相当を組む」例を示しました。この記事ではよくある誤解を整理し、シフト管理を含めた自作 OnCall スタックの現実的な選択肢を深掘りします。 まずは Apprise の正しい位置付けを確認 Apprise は名前から「シフト管理ができそう」と誤解されがちですが、実際の役割は明確に分かれています。 正しい位置付け: Apprise は 「通知の超便利ハブ」 — 1 つのコードで Slack / メール / SMS / LINE / Telegram など 100 種類以上の通知先に統一インタフェースで送る シフト管理機能（カレンダー、ローテーション、当番判定）は持たない 「シフト管理に Apprise を使う」とは、シフトロジックは別のライブラリ / DB / カレンダーで持ち、通知配信だけ Apprise に任せるという意味 つまり Apprise は「組んだシフトを確実に届ける道具」であり、「シフトを組む道具」ではありません。前回記事のコード例で get_policy_for_now() を Python で書いていたのは、まさにこの「シフト判定ロジックを自作」の実装です。 シフト管理を「自作する場合」に組み合わせる Python ライブラリ シフトロジックを自分で書くなら、以下のライブラリが Apprise と相性が良い。 1. PyShift（point85/PyShift） — 古典的なシフトローテ point85/PyShift は、Java 版の Shift ライブラリを Python に移植したもの。PyPI では PyWorkShift として配布されています。 ...

前回の記事で「サーバー監視の王道スタック」として Prometheus + Loki + Grafana + Alloy を整理しました。アラート設計のセクションで触れた Grafana OnCall について、改めて単独で深掘りします。 ただし重要な注意点があります — Grafana OnCall OSS（grafana/oncall リポジトリ）は 2026 年 3 月 24 日にアーカイブされました。後継は **Grafana Cloud IRM（Incident Response Management）**で、OnCall と Incident の両アプリが 1 つに統合されています。 「Grafana OnCall を新規導入したい」「既存環境を移行すべきか」という人に向けて、何が終わって、何が始まったのかを整理します。 Grafana OnCall とは何だったのか Grafana OnCall は 「アラートが鳴った後の対応フロー」を管理するツールでした。 Prometheus / Loki / Grafana が「異常を検知する」までを担当 Grafana OnCall は「鳴ったアラートを誰に・どうやって届け、どう対応するか」を管理 PagerDuty や Opsgenie の OSS 互換ツールとして、Grafana エコシステムの中で重要なポジションを占めていました。 主な機能（当時） アラートの集約とルーティング — 複数の監視システムからのアラートを統合、内容に応じてチームへ振り分け オンコールシフト管理 — 担当者のカレンダー（シフト表）に従って当番者にだけ通知 エスカレーションポリシー — 一定時間応答がなければ次の担当者へ自動エスカレーション ChatOps 連携 — Slack / Telegram 上でアラート確認・対応開始（Acknowledge）・解決（Resolve）が完結 柔軟な通知手段 — Slack / Microsoft Teams / SMS / 自動音声通話（電話）/ モバイルプッシュ IaC 対応 — Terraform プロバイダで設定をコード管理可能 連携先（インテグレーション） カテゴリ 代表的な連携先 監視・アラート検知 Grafana, Prometheus (Alertmanager), Datadog, Zabbix, AWS CloudWatch, New Relic 通知・コミュニケーション Slack, Microsoft Teams, Telegram, SMS, 自動音声通話 OSS 版で自社サーバーに構築することも、Grafana Cloud のマネージドサービスとして利用することも可能でした。 ...

サーバー監視は「死活監視 + リソース監視」の時代から、「メトリクス + ログ + トレース」を 1 つの画面で相関分析するオブザーバビリティの時代に移りました。クラウドネイティブ環境では、Grafana Labs の OSS スタック（Prometheus + Loki + Grafana + Alloy）が、コスト・自由度・運用ノウハウの蓄積において事実上の王道になっています。 この記事では、なぜこの組み合わせが現代の標準なのか、各コンポーネントがどう役割分担しているのか、そして最小構成から本番運用までの全体像を整理します。 なぜこの構成が「王道」なのか サーバー監視の選択肢は大きく分けて 3 系統あります。 カテゴリ 代表例 特徴 OSS スタック（Grafana Labs） Prometheus + Loki + Grafana + Alloy 無料、自由度高、運用責任は自分で OSS スタック（Elastic） Elasticsearch + Logstash + Kibana + Beats 全文検索が強力、コストとリソース消費が大 SaaS Datadog、New Relic、Grafana Cloud 楽だが高価、データ主権がない このうち Prometheus + Loki + Grafana + Alloy が王道とされる理由: ...

2026年4月7日、AWSがAmazon S3 Filesを一般提供（GA）しました。S3バケットをNFS v4.1/v4.2のファイルシステムとしてマウントできる機能で、EC2・EKS・ECS・Lambdaのいずれからでも利用できます。 本記事は、ikenyal氏のZenn記事「S3 Filesで消えるアーキテクチャ層、生まれるアーキテクチャ」を参照しながら、S3 Filesが既存のアーキテクチャにどう影響するかを整理します。「何が設定できるか」ではなく「何が不要になり、何が可能になるか」にフォーカスします。 S3 Filesが解こうとしている問題 たとえば、MLチームが学習データの前処理をする場面を考えましょう。元データはS3に置いてあり、pandasで読み込んで加工したい場面です。 pd.read_csv("s3://my-bucket/data.csv") と書けますが、内部ではboto3がGETリクエストを発行してメモリに読み込んでいます。手元の open("./data.csv") とは根本的に異なるI/Oモデルです。 規模が大きくなると、これは「パイプラインのアーキテクチャ課題」になります。 S3からEFS/EBSにコピー → 処理 → 結果をS3に書き戻す この「中間のコピー層」は本来やりたい処理ではなく、ストレージのI/Oモデルの違いを埋めるためだけに存在しています。 S3 Filesはこのギャップそのものを解消します。アプリケーションからS3のデータはローカルのディレクトリに見えます。 1 2 3 # S3 Filesを使うと pd.read_csv("/mnt/s3files/data.csv") # S3のオブジェクトが読まれる df.to_csv("/mnt/s3files/result.csv") # 変更が自動的にS3にコミットされる FUSEベースのツールとの違い 「S3をマウントできる」と聞いて、Mountpoint for Amazon S3やgcsfuseを思い浮かべる方も多いでしょう。S3 Filesは内部構造がまったく異なります。 FUSEベースのツールは、S3 APIの上にファイルシステムの振る舞いを「エミュレーション」するアプローチです。ファイルの一部だけを書き換えるような操作がサポートされず、空ディレクトリの扱いに不整合が出ることもあります。 S3 Filesはエミュレーションではなく、EFS（Elastic File System）という本物のNFSファイルシステムをS3に接続しています。二つの異なるシステムが共存し、その間に明示的な同期レイヤーがある構造です。 「stage and commit」モデル ファイルシステム上での変更は即座にS3に反映されるのではなく、約60秒ごとにまとめてS3へPUTされます（「commit」）。逆に、S3側でオブジェクトが更新された場合は通常数十秒以内にファイルシステム側に反映されます。 これは明確なトレードオフです。「リアルタイムに同期される共有ファイルシステム」ではなく、「数十秒の遅延を許容する代わりに、ファイルとオブジェクトの両方のセマンティクスを壊さない」設計です。 消えるアーキテクチャ層 1. S3 → EFS/EBSのステージングパイプライン 100GBの学習データを処理する場合、従来の手順は： S3からEBSにダウンロード（数分かかる） データを処理する 結果をS3にアップロード EBSボリュームをクリーンアップ やりたい処理は2番だけです。S3 Filesでは、S3プレフィックスをマウントするだけで処理スクリプトはそのまま /mnt/s3files/ のファイルを読み書きします。ダウンロード・アップロード・クリーンアップのステップが消えます。 ...

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つの選択肢を検討した。 ...