HARUMI

Architecture

プラットフォームの仕組み

アプリケーションが動く仕組み、変更が届く経路、知識を残しアクセスを制限する方法を示します。

日付付きのインフラ観測

利用できません

01 / PLATFORM

公開リクエストから稼働アプリケーションまで

Kubernetes クラスタ、明示された公開経路、Kafka 通信、クラスタの外から監視するオブザーバー、GitOps の配信経路を示します。図は関係だけを示し、アドレスやアクセス詳細は含みません。

01 / DELIVERY LOOP

要求から実行証拠まで

矢印は引き継ぎではなく gate。証明に失敗したら観測へ戻る。

  1. 01 / 要求

    求められる成果を確認する

    実際の状態、正本、公開区分、重大なリスク、そして失敗を検出できる検査を確認する。

    現状の証拠

  2. 02 / 計画

    変更前に完了を定義する

    単純でない作業は、範囲・順序付き検査・停止条件を備えた計画として保存し、読み戻す。

    Plan ID + チェックリスト

  3. 03 / 正本

    一つの正本を変更する

    意味の通る最小のコード・設定・内容変更に、実行可能な検査と失敗例を同梱する。

    diff + ローカル検査

  4. 04 / パイプライン

    ビルド・スキャン・証明

    GitLab CI がアプリをコンパイルし、不変イメージを構築・スキャンして、昇格前に供給網の証拠を残す。

    pipeline + image digest

  5. 05 / GITOPS

    リリースを宣言する

    別のタグ更新コミットが望ましい状態を更新し、Argo CD が同期する。手作業の実行状態は正本にならない。

    GitOps revision

  6. 06 / 実行状態

    対象のデプロイを証明する

    Argo の revision、workload image、rollout health、実際の利用経路が同じリリースを示す必要がある。

    SHA + 経路の読み戻し

実行状態の読み戻しが、次の観測になる。

02 / KNOWLEDGE LOOP

正本を重複させずに残す

AI はループを補助するが、何を残すかは証拠と維持された正本が決める。

07 / RETAIN

結果を分類する

運用事実、再利用する振る舞い、公開証拠——または意図的な非公開。

正本ドキュメント

検証済みの運用事実、標準、SOP。

AI MEMORY

再利用する振る舞いと正本への案内だけ。第二の正本にはしない。

公開プロジェクション

二言語でレビューされ、永続的かつ安全に編集された証拠だけが本サイトに届く。

生成された知識は別の編集面にならない。不一致は元の正本で直す。

03 / SECURITY ENVELOPE

階層化した境界と明示的な所有者

公開図が示すのは control class と trust boundary。機微な topology や復旧 shortcut は示さない。

  1. 01

    CLOUDFLARE 管理のエッジ

    Proxy DNS · TLS · DDoS 防御 · WAF · 非公開画面の Access

    公開エッジは計測と drift review の対象。「provider-managed」は無管理を意味しない。

  2. 02

    HARUMI ROUTING 境界

    明示的な公開 route · 内部 service path · 境界間 grant

    内部通信は内部に留める。公開 hostname を cluster 内 service path にしない。

  3. 03

    KUBERNETES WORKLOAD 境界

    Namespace · service account · RBAC · security context · policy audit

    最小権限は enforcement 前に範囲を限定する。広範な拒否には証拠・失敗試験・rollback が必要。

  4. 04

    DATA / SECRET 境界

    Secret 参照 · 暗号化経路 · 状態分離 · backup / restore 証拠

    認証情報と非公開記録は、公開 content・image・log・生成 knowledge に入れない。

04 / RUNTIME TOPOLOGY

構成一覧ではなく、依存関係

この公開図は、運用上の座標を公開せず、役割の分類と相関する領域だけを示す。

PUBLIC BOUNDARY

公開エッジ

リクエスト入口

ROUTING BOUNDARY

ゲートウェイ

明示的な経路

KUBERNETES PLATFORM

CORRELATED RUNTIME CORE

  • 制御の正本
  • 通信基盤 + 経路制御
  • 共有状態

SEPARATE ROLE

計算処理の役割

ワークロード容量

RECOVERY CONTRACT

  1. 正本
  2. 復元の証明
  3. 実行状態の読み戻し

復旧が証明されて初めて、その境界は独立していると言える。

関係性だけを示す図。address、service inventory、access detail は意図的に省略する。replica を増やすだけでは共有依存は解消しない。

05 / OPERATIONAL FEEDBACK

Signal を統制された作業へ戻す

検知・operator action・scheduler truth・resource evidence を、別々の正本を崩さずに接続する。

運用フィードバックと検証の詳細

ARCHITECTURE WORKBENCH

非公開の modeling workspace が、レビュー済みのシステム関係を version 管理可能な ArchiMate artifact にする。browser access は管理された network boundary 内に留め、公開ページには編集・レビュー済みの projection だけを届ける。

MESSAGE CENTER

型付けされた内部 event を永続的な運用記録へ変換。Browser push は privacy-safe な projection であり、ledger ではない。

ALERTMANAGER ROUTING

Prometheus が検知し、Alertmanager が group・inhibit・receiver recovery 中の retry を担当。occurrence の事実と人の acknowledgement は分離する。

SCHEDULE REGISTRY

native scheduler を正本のまま維持し、読み取り専用 registry が failed・missed・stale・duration anomaly と recovery を永続的な運用記録へ変換する。

PRODUCT FEEDBACK PATH

利用者が書いた feedback をアプリが保存して受付番号を返し、その後 internal event topic へ中継する。browser が broker に触れることはなく、受付番号は「確実に保存した」であって「届いた」ではない。運用記録は restricted 扱いで、通知が本文を運ぶことはない。

RESOURCE OBSERVATIONS

運用 workspace は固定 1h/24h/7d trend、正確な比較 table、鮮度、欠測状態を保持。Kafka は broker の health と allowlist 済み lag 経路を追加し、metric は cluster 内だけに保つ。

障害は、永続記録と source state が一致して初めて次の Plan input になる。

06 / ASSURANCE CONTRACT

「完了」が証明すべきこと

正本
各事実に一つの維持責任者
Identity
人と workload のアクセスを分離
供給網
source・build・scan・release revision を追跡可能に
変更安全性
observe → audit → scoped enforcement → broad enforcement
復旧
stateful change には復旧定義と読み戻しが必要
完了
repository・runtime・Plan・永続記録が一致

観測した実行状態、delivery の証拠、維持された文書、次の開始状態が一致して初めて architecture は閉じる。