centra
d2149b6249
- Replace form_urlencoded with RFC 3986 compliant URI encoding - Implement aws_uri_encode() matching AWS SigV4 spec exactly - Unreserved chars (A-Z,a-z,0-9,-,_,.,~) not encoded - All other chars percent-encoded with uppercase hex - Preserve slashes in paths, encode in query params - Normalize empty paths to '/' per AWS spec - Fix test expectations (body hash, HMAC values) - Add comprehensive SigV4 signature determinism test This fixes the canonicalization mismatch that caused signature validation failures in T047. Auth can now be enabled for production. Refs: T058.S1
101 lines
8.4 KiB
Markdown
101 lines
8.4 KiB
Markdown
# Project Overview
|
||
これは、日本発のクラウド基盤を作るためのプロジェクトです。
|
||
OpenStackなどの既存の使いにくいクラウド基板の代替となり、ついでに基礎技術を各種ソフトウェアに転用できるようにする。
|
||
|
||
# Principal
|
||
Peer Aへ：**自分で戦略を**決めて良い！好きにやれ！
|
||
|
||
# Current Priorities
|
||
一通り実装を終わらせ、使いやすいプラットフォームと仕様が完成することを目標とする。
|
||
実装すべきもの：
|
||
1. クラスター管理用KVS（chainfire）
|
||
- これは、ライブラリとして作ることにする。単体でとりあえずKVSとして簡易的にも使えるという想定。
|
||
- Raft+Gossip。
|
||
2. IAM基盤（aegisという名前にしたい。）
|
||
- 様々な認証方法に対応しておいてほしい。
|
||
- あと、サービス感の認証もうまくやる必要がある。mTLSでやることになるだろう。IAMとしてやるのが正解かどうかはわからないが。
|
||
3. DBaaSのための高速KVS（FlareDB）
|
||
- そこそこクエリ効率の良いKVSを作り、その上にSQL互換レイヤーなどが乗れるようにする。
|
||
- 超高速である必要がある。
|
||
- 結果整合性モードと強整合性モードを両方載せられるようにしたい。
|
||
- Tsurugiのような高速なDBが参考になるかも知れない。
|
||
- DBaaSのためでもあるが、高速分散KVSということで、他のもののメタデータストアとして使えるべき。
|
||
- Chainfireとの棲み分けとしては、Chainfireは単体で使う時用と、大規模な場合はクラスター管理に集中させ、メタデータのストア（特に、サービ ス感の連携をするような場合は他のサービスのメタデータにアクセスしたくなるだろう。その時に、このKVSから読めれば良い。）はFlareDBにすると良 さそう。
|
||
4. VM基盤（PlasmaVMC）
|
||
- ちゃんとした抽象化をすることで、様々なVMを扱えるようにしたい（KVM,FireCracker,mvisorなどなど）
|
||
5. オブジェクトストレージ基盤（LightningSTOR）
|
||
- この基盤の標準的な感じの（ある程度共通化されており、使いやすい）APIと、S3互換なAPIがあると良いかも
|
||
- メタデータストアにFlareDBが使えるように当然なっているべき
|
||
6. DNS（FlashDNS）
|
||
- PowerDNSを100%完全に代替可能なようにしてほしい。
|
||
- Route53のようなサービスが作れるようにしたい。
|
||
- BINDも使いたくない。
|
||
- 逆引きDNSをやるためにとんでもない行数のBINDのファイルを書くというのがあり、バカバカしすぎるのでサブネットマスクみたいなものに対応すると良い。
|
||
- DNS All-Rounderという感じにしたい。
|
||
7. ロードバランサー（FiberLB）
|
||
- 超高速なロードバランサーとは名ばかりで、実体としてはBGPでやるので良いような気がしている。
|
||
- AWS ELBみたいなことをできるようにしたい。
|
||
- MaglevによるL4ロードバランシング
|
||
- BGP AnycastによるL2ロードバランシング
|
||
- L7ロードバランシング
|
||
- これらをいい感じにできると良い（既存のソフトウェアでできるかも？これは要確認。）
|
||
8. Kubernetesクラスタをいい感じにホストできるもの？
|
||
- k0sとかk3sとかが参考になるかも知れない。
|
||
9. これらをNixOS上で動くようにパッケージ化をしたりすると良い（Flake化？）。
|
||
- あと、Nixで設定できると良い。まあ設定ファイルを生成するだけなのでそれはできると思うが
|
||
10. Nixによるベアメタルプロビジョニング
|
||
11. オーバーレイネットワーク
|
||
- マルチテナントでもうまく動くためには、ユーザーの中でアクセスできるネットワークなど、考えなければいけないことが山ほどある。これを処理 するものも必要。
|
||
- とりあえずネットワーク部分自体の実装はOVNとかで良い。
|
||
12. オブザーバビリティコンポーネント（NightLight）
|
||
- メトリクスストアが必要
|
||
- VictoriaMetricsはmTLSが有料なので、作る必要がある
|
||
- 完全オープンソースでやりたいからね
|
||
- 最低限、Prometheus互換（PromQL）とスケーラビリティ、Push型というのは必須になる
|
||
- メトリクスのデータをどこに置くかは良く良く考えないといけない。スケーラビリティを考えるとS3互換ストレージの上に載せたいが…？
|
||
- あと、圧縮するかどうかなど
|
||
13. クレジット・クオータ管理（CreditService）
|
||
- プロジェクトごとのリソース使用量と課金を管理する「銀行」のようなサービス
|
||
- 各サービス（PlasmaVMCなど）からのリソース作成リクエストをインターセプトして残高確認（Admission Control）を行う
|
||
- NightLightから使用量メトリクスを収集して定期的に残高を引き落とす（Billing Batch）
|
||
|
||
# Recent Changes (2025-12-11)
|
||
- **Renaming**:
|
||
- `Nightlight` -> `NightLight` (監視・メトリクス)
|
||
- `PrismNET` -> `PrismNET` (ネットワーク)
|
||
- `PlasmaCloud` -> `PhotonCloud` (プロジェクト全体コードネーム)
|
||
- **Architecture Decision**:
|
||
- IAMにクオータ管理を持たせず、専用の `CreditService` を新設することを決定。
|
||
- `NightLight` を使用量計測のバックエンドとして活用する方針を策定。
|
||
|
||
# Next Steps
|
||
1. **CreditServiceの実装**:
|
||
- プロジェクトごとのWallet管理、残高管理機能
|
||
- gRPC APIによるAdmission Controlの実装
|
||
2. **NightLightの実装完了**:
|
||
- 永続化層とクエリエンジンの完成
|
||
- `CreditService` へのデータ提供機能の実装
|
||
3. **PlasmaVMCの改修**:
|
||
- `CreditService` と連携したリソース作成時のチェック処理追加
|
||
- プロジェクト単位のリソース総量制限の実装
|
||
|
||
# 守るべき事柄
|
||
1. Rustで書く。
|
||
2. 全部のソフトウェアにおいて、コードベースの構造や依存ライブラリ、仕様や使い方を揃えて、統一感があるようにする。
|
||
3. テスト可能なように作る。また、テストをちゃんと書く。スケーラブルかどうかや、実際に動くかどうかもテスト可能なように良く考えたうえで作る。
|
||
4. スケーラビリティに気をつけて書く。ボトルネックになる箇所はないか？と常に確認する。
|
||
5. 統一感ある仕様をちゃんと考える。（specificationsの中にmdで書いていってほしい。1ソフトウェアごとにフォルダを作り、その中に仕様を書く。 ）
|
||
6. 設定ファイルについても統一感ある仕様が必要。
|
||
7. マルチテナントに関して最初から考慮したうえで設計する（次の年にAWSやGCPでそのまま採用されてもおかしくないような性能や使いやすさが必要）。
|
||
8. ホームラボ用途も満たすようにしたい。
|
||
9. NixのFlakeで環境を作ったり固定したりすると良い。
|
||
10. 前方互換性は気にする必要がない（すでにある実装に縛られる必要はなく、両方を変更して良い）。v2とかv3とかそういうふうにバージョンを増やしていくのはやめてほしい。そうではなく、完璧な一つの実装を作ることに専念してほしい。
|
||
11. ライブラリは可能な限り最新版を使う。この先も長くメンテナンスされることを想定したい。
|
||
|
||
# 実戦テスト
|
||
全ての作ったコンポーネントについて、実践的なテストを作ってバグや仕様の悪い点を洗い出し、修正する。
|
||
NixやVM、コンテナなどあらゆるものを活用してよい。
|
||
これにより、実用レベルまで持っていくことが期待される。
|
||
実用的なアプリケーションを作ってみるとか、パフォーマンスを実際に高負荷な試験で確認するとか、そのレベルのものが求められている。
|
||
また、各コンポーネントごとのテストも行うべきだが、様々なものを組み合わせるテストも行うべきである。これも含まれる。
|
||
また、設定のやり方がちゃんと統一されているかなど、細かい点まで気を配ってやる必要がある。
|