ID:84718さん

プロジェクト経験概要 ADS-B航空機情報と音楽を24時間365日配信するYouTube Live基盤を個人で設計・開発・運用しています。 単に配信を継続するだけでなく、「視聴者が同じURLから継続して視聴できること」を主要な信頼性要件として設定しました。障害発生時の状態を観測し、障害箇所に応じて必要最小限の復旧を行う仕組みを構築しています。 チーム情報 個人開発、1名。 企画、要件定義、アーキテクチャ設計、実装、テスト、デプロイ、監視、障害解析、運用改善まで一貫して担当しています。 開発・実装内容A：同一URLを維持する配信・復旧基盤 【概要】 YouTube Liveへの24時間配信と、障害発生時の自動復旧機構を構築しました。 【どのような機能の開発・実装か】 FFmpegによる配信、ブラウザでのADS-B描画、音声処理、YouTubeの配信状態監視を行っています。 配信異常を検知した場合は、障害の種類に応じて段階的に復旧します。監視処理が直接YouTubeのbroadcastを作り直すのではなく、可能な限り現在の配信URLを維持したままdelivery側のみを復旧する設計としました。 【課題・問題点】 障害時に新しいYouTube Liveを作成すれば、内部的な復旧処理は単純になります。一方でURLが変わるため、既存のリンクや視聴者がそのまま配信へ戻れなくなります。 また、ネットワーク異常、FFmpeg異常、映像停止、ADS-Bデータ停止などをすべて同じ「配信障害」と扱って再起動すると、正常なコンポーネントまで巻き込み、障害を拡大する可能性があります。 【打ち手・使用した技術】 視聴者側の継続性を優先し、「同一YouTube Live URLの維持」を独立したSLIとして扱いました。 Pythonで監視・復旧ロジックを実装し、FFmpeg、RTMPS TCP状態、YouTube lifecycle、ADS-B source、映像、音声などを別のfault domainとして監視しています。 k3s上のworkloadについても、異常の種類に応じて復旧対象を限定しました。曖昧な観測結果だけではYouTube lifecycleを変更しない設計とし、監視と復旧権限を分離しています。 使用技術：Python、k3s/Kubernetes、FFmpeg、Prometheus、Loki、Grafana、YouTube API、Docker、Linux/systemd 【成果】 約80日間、同一のYouTube Live URLを維持しました。 保持している28日間の評価区間では、同一URL判定6,558/6,568件、99.848％を記録し、URL置換操作は0件でした。 開発・実装内容B：TCP stallの原因分析と観測系改善 【概要】 繰り返し発生していたRTMPSのTCP stallについて、再起動による対症療法だけで終わらせず、障害レイヤーを特定するための観測系を構築しました。 【どのような機能の開発・実装か】 RTMPSの送信状態に加え、YouTubeとは独立したCloudflare・Google向けTCP通信、既存TCP接続、新規TCP接続、default route、IPv4/IPv6状態などを記録するnetwork observerを実装しました。 【課題・問題点】 当初観測できたのは「YouTubeへの送信が止まった」という症状でした。 しかし、この情報だけではYouTube ingest障害、Google経路障害、DNS障害、NATセッション問題、WAN回線側の問題などを区別できません。 原因を誤認すると、ネットワーク障害に対してencoder設定を変更したり、正常なYouTube broadcastを再作成したりする可能性がありました。 【打ち手・使用した技術】 まず原因候補ごとに「その仮説が正しければ、どの通信が成功・失敗するか」を定義しました。 YouTubeだけが停止するのか、Google系全体なのか、Cloudflareを含めた外部通信全体なのかを比較しました。また既存TCPと新規TCPを分離して観測し、DNSを経由しないIP直接接続も使用しました。 その結果、YouTube、DNS単独、既存NATセッションのみといった仮説を反証し、WAN/session層まで原因候補を絞りました。 一方、60秒間隔のWAN observerでは短時間の状態遷移を取得できないケースがありました。常時高頻度化すると不要なログと負荷が増えるため、通常60秒、障害が発生しやすい時間帯は10秒、異常検知直後は5秒間隔で追加観測する方式へ変更しました。 使用技術：Python、Linux networking、TCP socket情報、IPv4/IPv6、systemd timer、Prometheus/Loki 【成果】 複数日にわたって同じ障害パターンを再現・観測し、YouTube固有の問題ではなくWAN/session/route層の障害として分類できる状態まで観測解像度を向上させました。 障害の所有範囲を証拠以上に断定せず、CPE側か通信事業者側かを未確定事項として残すことで、確認できていない原因を復旧ロジックへ混入させない運用としています。 開発・実装内容C：実行系・監視系・公開系の分離 【概要】 単一ホストに集中していた配信・監視機能を、役割の異なる複数ホストへ分離しました。 【課題・問題点】 配信処理と監視処理が同じ障害ドメインに存在すると、配信ホスト自体が停止した際に監視も同時に失われます。 一方、監視系へ強い復旧権限を与えすぎると、誤検知が配信系を破壊する可能性があります。また、Grafanaなどの内部監視系をそのままインターネットへ公開することも避ける必要がありました。 【打ち手・使用した技術】 ADS-B source・private observability、delivery runtime、public status publisherを3台のホストへ分離しました。 Prometheus、Loki、Grafanaなどの内部監視系はprivate network内に保持。公開情報についてはRaspberry Piが許可した情報だけを取得し、静的snapshotとしてGCSへ送信し、Cloudflare経由で公開しています。 公開側から自宅Grafanaや配信runtimeへ到達しない一方向の構成としました。 使用技術：k3s、Prometheus、Loki、Grafana、GCS、Cloudflare、Python、Linux

プロジェクト経験概要 SREのインシデント調査を支援するAI分析基盤「Ops Evidence Synthesis（OES）」を個人で設計・実装しました。 LLMにログを渡して原因を推測させるのではなく、証拠を固定し、複数モデルの分析結果、反証、不足証拠を整理した上で、最終判断を人間へ戻すことを目的としています。 チーム情報 個人開発、1名。 課題設定、アーキテクチャ設計、Python実装、AI連携、テスト、GCPインフラ構築、Terraform、Cloud Runへの公開まで担当しました。 開発・実装内容A：AIへ渡す証拠とデータ境界の設計 【概要】 実運用ログをAIで分析しつつ、raw logや機密情報を外部へ出さないためのEvidence Pipelineを実装しました。 【どのような機能の開発・実装か】 raw logとsource codeはローカルに保持し、sanitization後のEvidence ItemだけをAI分析へ渡します。 システムの意味やログの解釈についてもAIだけで決定せず、人間が内容を確認・承認したOperational Profileを作成し、分析対象のEvidence BundleとともにSHAで固定する仕組みを実装しました。 【課題・問題点】 LLMによる障害解析では、入力したログやコードの境界が曖昧になると、どの情報を根拠に回答したのか後から確認できません。 また、分析途中で追加情報が暗黙に混入すると、同じ入力から同じ判断過程を再現できなくなります。 【打ち手・使用した技術】 「AIの精度を上げる」前に、「何を根拠としてAIに判断させたのかを固定する」方針を採用しました。 raw dataをローカルでsanitizationし、Evidence Itemへ変換。承認済みProfile、Evidence Bundle、model provenanceをSHAで固定しました。 承認後はsource contextへ再アクセスできない境界も設け、分析途中で証拠条件が変化しないようにしました。 使用技術：Python、SHA-256、JSON Schema、GCS、PostgreSQL、Cloud Run 開発・実装内容B：複数AIによる分析と誤判定防止 【概要】 複数AIが同一証拠を分析し、その結果を比較・検証するincident review pipelineを実装しました。 【どのような機能の開発・実装か】 各AIに同一のEvidence Bundleを入力し、回答にEvidence IDを付与させます。 その後、引用が実際の証拠と対応しているかを検証し、supporting evidence、counter-evidence、missing evidence、モデル間の不一致を保持したままreviewを生成します。 【課題・問題点】 複数AIが同じ原因を回答した場合、多数決で正しいと判断する実装も可能です。 しかし、全モデルが同じ誤った仮説を生成する可能性があり、「5モデルが同意した」という事実は原因を証明するものではありません。 特に障害対応では、誤った原因確定が不要な設定変更や別障害を引き起こす可能性があります。 【打ち手・使用した技術】 モデル間の一致度を「原因である確率」として扱わない設計にしました。 AIは原因を確定する役割ではなく、証拠、反証、不足証拠、次に確認すべき項目を整理する役割としました。 引用検証を行い、Evidence IDに存在しない根拠を使用した回答を検出します。また、証拠不足やモデル間の不一致を消さずにreviewへ残します。 最終的なcause promotionや運用操作はhuman gateを通過しなければ実行できない設計としました。 使用技術：Python、Gemini、Vertex AI、構造化JSON、citation validation、PostgreSQL 【成果】 実際のstream_v3ログ45,000行を入力した評価では、45,000件を再sanitizationし、1,036件のEvidence Itemを生成しました。 5/5 providerからschema-validな分析結果を取得しましたが、自動的に原因確定した項目は0件とし、6件をValidation Targetとして人間の確認対象に残しました。 「AIが答えを出すシステム」ではなく、「AIが判断に必要な証拠を整理し、証拠以上の判断をしないシステム」として動作させています。 開発・実装内容C：GCP上での安全な公開・再現環境 【概要】 開発環境だけでなく、第三者が実際の分析結果と判断過程を確認できる公開環境をGCP上に構築しました。 【課題・問題点】 公開デモで任意のログやURLを入力可能にすると、機密情報の送信、プロンプトコスト増加、不正利用などのリスクがあります。 一方、事前計算した静的画面だけでは、実際にAI処理が動作することを確認できません。 【打ち手・使用した技術】 公開reviewは事前計算した結果をread-onlyで表示し、モデル実行コストを発生させず確認できるようにしました。 別途Fast GCP Reviewを用意し、固定された2,000行のsanitized sampleのみを入力可能にすることで、実際のモデル実行も確認できる構成としました。任意ファイル、URL、ログ入力は受け付けません。 Cloud Build、Artifact Registry、digest固定したCloud Run revision、smoke testを用いてbuild・release経路を構成し、TerraformではCloud Run Job、Cloud SQL、BigQuery、Secret Manager、monitoringなどのproduction構成をコード化しました。 使用技術：Google Cloud Run、GCS、Cloud Build、Artifact Registry、Terraform、Cloud SQL/PostgreSQL、BigQuery、Secret Manager、Python

プロジェクト経験概要 ADS-B受信環境のハードウェア変更が、本当に受信性能を改善したのかを統計的に評価するための分析基盤「ARENA」を個人で設計・開発しました。 アンテナ、SDR、ケーブルなどの変更前後で受信件数を単純比較するのではなく、航空交通量や時間帯などの外部要因と、機材変更による効果を可能な限り分離して判断できる仕組みを目的としています。 チーム情報 個人開発、1名。 評価方法の設計、統計モデル選定、データパイプライン、Python実装、テスト、Docker化、CI、分析結果の検証方法まで担当しています。 開発・実装内容A：ハードウェア変更効果の統計評価 【概要】 ADS-B受信機材を変更した際の性能差を、複数の統計手法から検証する評価pipelineを実装しました。 【どのような機能の開発・実装か】 受信データを距離帯や期間ごとに集計し、Bayesian Negative Binomial GLM、頻度論Negative Binomial GLM、Mann-Whitney U検定、change-point detection、OpenSkyデータによる正規化など、異なる前提を持つ複数手法で分析します。 【課題・問題点】 例えばSDRを交換した翌日に受信件数が20％増えたとしても、それだけでは機材変更の効果とは判断できません。 航空機数は時間帯、曜日、季節などによって変動します。また、ADS-Bのカウントデータは分散が大きく、疎な距離帯や突発的にデータが集中する期間もあります。 単純な平均値のBefore/After比較では、これらの外部要因を機材の性能向上と誤認する可能性があります。 【打ち手・使用した技術】 カウントデータの性質を考慮し、Poissonだけでなく過分散を扱えるNegative Binomialモデルを中心に評価しました。 一方、単一モデルの仮定に結論を依存させることも避けるため、Bayesian NB-GLM、頻度論NB-GLM、ノンパラメトリック検定、change-point、外部データによる正規化、距離帯別評価を併用しました。 「最も高度なモデルの結果を正解とする」のではなく、異なる前提を持つ分析結果がどこで一致し、どこで不一致になるかを確認して判断する設計としています。 使用技術：Python、NumPyro、JAX、PyMC、statsmodels、pandas 開発・実装内容B：再現可能なデータ・証拠pipeline 【概要】 統計結果だけを保存するのではなく、「どの入力から、どの処理を経て、その結果になったか」を後から確認できるartifact pipelineを構築しました。 【課題・問題点】 分析コードを変更したり、入力データを追加したりすると、以前生成したグラフや数値がどの条件から生成されたものか分からなくなる可能性があります。 その状態では、分析結果に疑問が生じても再検証できません。 【打ち手・使用した技術】 解析処理を9段階のpipelineとして分離しました。 各stageの出力から、人間が確認するグラフやreportだけでなく、下流処理用のartifact bundleも生成します。 artifactにはSHA-256によるcontent identity、schema validation、provenance/lineageを持たせ、分析結果から入力データまで追跡できる構成としました。 また、一部stageが失敗しても原因を確認できるようfailure-resilient executionとappend-only audit logを採用しています。 使用技術：Python、SHA-256、JSON Schema、SQLite、pandas 開発・実装内容C：複数モデル・AIによる分析結果の統合 【概要】 統計pipelineの出力を複数AIへ提示し、各モデルが生成した主張を比較・レビューするsynthesis layerを実装しました。 【課題・問題点】 大量の統計結果を人間だけで横断確認するには時間がかかります。 一方で、LLMに「どの変更が有効だったか」を直接判断させると、モデルが統計結果を誤読したり、複数モデルの多数決が誤った結論を強化したりする可能性があります。 【打ち手・使用した技術】 LLMを最終判断者ではなく、仮説・論点の抽出器として使用しました。 複数AIの回答をstructured JSONとして取り込み、claim単位に分解。support、counter-evidence、caveat、validation targetを別々に保持し、モデル間の一致・不一致をreviewできるようにしました。 単純なweighted ensemble scoreには統合せず、異なるモデルが異なる判断をした場合は、その不一致自体を情報として残します。 SQLiteではproposition層とclaim層を分離し、元のモデル回答を保持しながら統合判断を管理できる構成にしています。 使用技術：Python、SQLite、structured JSON、複数LLM 開発・実装内容D：テスト・実行環境の再現性確保 【概要】 分析者のローカル環境に依存しない検証経路を整備しました。 【課題・問題点】 統計pipelineは依存ライブラリや実行環境の差によって結果や動作が変化する可能性があります。また、分析コードの変更によって過去の処理が壊れても、手動確認だけでは検出が難しくなります。 【打ち手・使用した技術】 CLIからvalidation、dry-run、artifact verification、synthesis smoke testを実行できるようにしました。 Docker Composeによるtest、validation、synthesis smoke環境を用意し、GitHub Actionsではlint、test matrix、coverage、smoke test、Docker testを自動実行しています。 使用技術：Docker、Docker Compose、GitHub Actions、pytest、Python 【成果】 統計解析、artifact生成、AI向けevidence生成、claim synthesisまでを1つの再現可能なpipelineとして構成しました。 特定の統計モデルやAIの回答だけを正解として扱わず、入力データ、統計結果、モデル判断、それぞれの不確実性を追跡できる評価基盤としています。